<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>The Rocketgraph Blog</title>
    <link>https://blog.rocketlog.io/blog</link>
    <atom:link href="https://blog.rocketlog.io/rss.xml" rel="self" type="application/rss+xml"/>
    <description>Observability at scale, cheaply — with AI that triages issues for you.</description>
    <language>en-us</language>
    <lastBuildDate>Fri, 28 Aug 2026 02:11:58 GMT</lastBuildDate>
    <item>
      <title>Zero-Code OpenTelemetry: Instrumenting a Real Distributed System</title>
      <link>https://blog.rocketlog.io/blog/zero-code-opentelemetry-instrumentation</link>
      <guid isPermaLink="true">https://blog.rocketlog.io/blog/zero-code-opentelemetry-instrumentation</guid>
      <pubDate>Fri, 28 Aug 2026 09:00:00 GMT</pubDate>
      <description>You can add full distributed tracing, metrics, and logs to a Python microservices app without touching application code — install the OpenTelemetry distro, bootstrap the instrumentors, and run each service under the opentelemetry-instrument wrapper. Here is exactly how we did it for Fathom, a nine-service bank, plus the one gotcha that keeps logs from showing up.</description>
      <content:encoded><![CDATA[**TL;DR**

We built Fathom — a nine-service bank that moves real money across two hosts — and load-tested it before adding any telemetry. Then we instrumented all of it with zero application-code changes: install the OpenTelemetry distro, `opentelemetry-bootstrap -a install`, run under `opentelemetry-instrument`, and configure with environment variables. Result: one connected trace per transfer across both hosts, HTTP metrics, and trace-correlated logs — with the one caveat that logs need the right log level to flow.

The fastest way to get traces, metrics, and logs out of a Python microservices app is to change none of its code. OpenTelemetry's zero-code auto-instrumentation does exactly that — and the seam only becomes visible when you apply it to a system that was genuinely built without observability in mind.

So we built one on purpose.

## Instrument something that already works

Most instrumentation tutorials start with an app that was born instrumented, so you never see the join. We did it the other way. **Fathom** is a real distributed system — a customer-facing edge tier on one machine, a core-banking tier with a double-entry ledger on another, plus Postgres. It signed up…]]></content:encoded>
      <category>OpenTelemetry</category>
      <category>Instrumentation</category>
      <category>Architecture</category>
    </item>
    <item>
      <title>Observability at Scale, Cheaply: The 2026 Cost Playbook</title>
      <link>https://blog.rocketlog.io/blog/observability-at-scale-cheaply</link>
      <guid isPermaLink="true">https://blog.rocketlog.io/blog/observability-at-scale-cheaply</guid>
      <pubDate>Tue, 14 Jul 2026 09:00:00 GMT</pubDate>
      <description>The cheapest way to run observability at scale is to stop paying hot-index prices for cold data: control cardinality, sample at the tail, land telemetry in object storage, and let AI do the first pass of triage. Here is the playbook, with the math.</description>
      <content:encoded><![CDATA[**TL;DR**

Observability gets expensive for structural reasons, and the fix is structural too: cap cardinality at the source, tail-sample traces, move the long tail of telemetry to object storage, stay portable with OpenTelemetry, and compress incident diagnosis with AI triage. Discounts are temporary; architecture is permanent.

The cheapest way to run observability at scale is to stop paying hot-index prices for data you almost never query. That single sentence explains most observability bill shock — and most of the fix.

This post is the playbook we wish we'd had earlier: why costs explode, which levers actually move the bill, and where AI fits.

## Why do observability costs explode at scale?

Three forces compound:

| Force | What happens | Why the bill grows |
| --- | --- | --- |
| Telemetry outgrows traffic | Each new service emits metrics, logs, and traces about its interactions with every other service | Data volume grows super-linearly with request volume |
| [Cardinality](/glossary#cardinality) multiplies series | One metric × labels like `pod`, `region`, `customer_id` becomes millions of time series | Most vendors price custom metrics per series |
| Everything lands in…]]></content:encoded>
      <category>Cost engineering</category>
      <category>Observability at scale</category>
      <category>Architecture</category>
    </item>
    <item>
      <title>AI Incident Triage, Explained: How AI Agents Cut MTTR</title>
      <link>https://blog.rocketlog.io/blog/ai-incident-triage-explained</link>
      <guid isPermaLink="true">https://blog.rocketlog.io/blog/ai-incident-triage-explained</guid>
      <pubDate>Tue, 07 Jul 2026 09:00:00 GMT</pubDate>
      <description>AI incident triage is the use of AI agents to do the first phase of incident response automatically: cluster alerts, correlate telemetry with deploys, rank probable root causes, and draft the incident summary before a human is paged. Here is how it works and how to evaluate it.</description>
      <content:encoded><![CDATA[**TL;DR**

AI incident triage automates the worst part of being paged: figuring out what is actually going on. A good agent clusters the alert storm, correlates signals with recent changes, ranks probable causes with evidence attached, and drafts the summary — so the human starts at "confirm and mitigate" instead of "stare at dashboards."

**AI incident triage** is the use of AI agents to do the first phase of incident response automatically. Before a human looks at anything, the agent has clustered related alerts into one issue, correlated metrics, logs, traces, and deploys, ranked probable root causes, and drafted a summary. The on-call engineer starts from a hypothesis, not from zero.

## Where incident time actually goes

Incident response has four phases: detect, diagnose, mitigate, resolve. Detection is largely solved — alerts fire fast. Mitigation is usually quick once you know what to do. The expensive middle is diagnosis: which of the 40 alerts is the cause and which are symptoms, what changed at 14:32, why is this service slow when its own metrics look healthy.

That diagnostic gap is where [MTTR](/glossary#mttr) lives, it is staffed by your most senior engineers, and it …]]></content:encoded>
      <category>AI triage</category>
      <category>Incident response</category>
      <category>MTTR</category>
    </item>
    <item>
      <title>Datadog Alternatives in 2026: An Honest Cost Comparison for Teams at Scale</title>
      <link>https://blog.rocketlog.io/blog/datadog-alternatives-2026-cost-comparison</link>
      <guid isPermaLink="true">https://blog.rocketlog.io/blog/datadog-alternatives-2026-cost-comparison</guid>
      <pubDate>Mon, 29 Jun 2026 09:00:00 GMT</pubDate>
      <description>A fair comparison of Datadog alternatives for teams whose observability bill is scaling faster than their traffic: Grafana Cloud, Honeycomb, New Relic, self-hosted stacks, and Rocketgraph — by pricing model, strengths, and watch-outs.</description>
      <content:encoded><![CDATA[**TL;DR**

If your Datadog bill is growing faster than your traffic, the problem is the pricing model, not your usage. The credible alternatives in 2026: usage-priced object-storage platforms (including Rocketgraph), event-priced Honeycomb, Grafana Cloud, or self-hosting — after you've moved to OpenTelemetry so switching is a routing change, not a rewrite.

Datadog is genuinely good software — that part is not in dispute. The dispute is the bill: per-host fees, per-series custom metrics, and per-GB indexed logs compound so that spend grows faster than infrastructure for most teams. This comparison is for the moment the renewal quote arrives.

We build [Rocketgraph](/about), so we have a horse in this race. The comparison below is written to be useful anyway — including the rows where we tell you not to pick us.

## How the alternatives actually differ

The market splits by pricing model more than by feature list. As of mid-2026 (verify current pricing before deciding — models and prices change):

| Platform | Pricing model | Strongest when | Watch out for |
| --- | --- | --- | --- |
| [Datadog](https://www.datadoghq.com/pricing/) | Per host + per custom-metric series + per GB index…]]></content:encoded>
      <category>Cost engineering</category>
      <category>Comparisons</category>
      <category>Datadog alternative</category>
    </item>
    <item>
      <title>What Is Rocketgraph? Architecture, Pricing Model, and AI Triage, Explained</title>
      <link>https://blog.rocketlog.io/blog/what-is-rocketgraph</link>
      <guid isPermaLink="true">https://blog.rocketlog.io/blog/what-is-rocketgraph</guid>
      <pubDate>Mon, 22 Jun 2026 09:00:00 GMT</pubDate>
      <description>Rocketgraph is an observability platform that delivers metrics, logs, and traces at scale on object-storage economics, with AI agents that triage issues automatically. This is the technical explainer: how the architecture works, why it stays cheap, and what the AI actually does.</description>
      <content:encoded><![CDATA[**TL;DR**

Rocketgraph ingests metrics, logs, and traces over OpenTelemetry into an object-storage telemetry lake, queries it with on-demand compute, and runs AI agents on top that triage issues automatically. Usage-based pricing, no per-host fees, long retention by default.

**Rocketgraph is an observability platform that delivers metrics, logs, and traces at scale on object-storage economics, with AI agents that triage issues automatically.** This post is the technical explainer behind that sentence.

## The architecture in one diagram's worth of words

Telemetry arrives over [OTLP](https://opentelemetry.io/docs/specs/otlp/), passes through a streaming tier that powers live dashboards and alerting, and lands in object storage in open columnar formats. Query engines spin up against that lake on demand and disappear when idle. The [AI triage layer](/blog/ai-incident-triage-explained) sits on top with access to everything — including months-old baselines, because retention is cheap when it lives in object storage.

Three consequences fall out of this design:

- **Retention stops being rationed.** Keeping 13 months of traces costs object-storage prices, not hot-index prices.
- **Cost…]]></content:encoded>
      <category>Rocketgraph</category>
      <category>Architecture</category>
      <category>AI triage</category>
    </item>
  </channel>
</rss>