{"version":"https://jsonfeed.org/version/1.1","title":"The Rocketgraph Blog","home_page_url":"https://blog.rocketlog.io/blog","feed_url":"https://blog.rocketlog.io/feed.json","description":"Observability at scale, cheaply — with AI that triages issues for you.","icon":"https://blog.rocketlog.io/icon.svg","language":"en","items":[{"id":"https://blog.rocketlog.io/blog/zero-code-opentelemetry-instrumentation","url":"https://blog.rocketlog.io/blog/zero-code-opentelemetry-instrumentation","title":"Zero-Code OpenTelemetry: Instrumenting a Real Distributed System","summary":"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.","content_text":"**TL;DR**\n\nWe 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.\n\nThe 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.\n\nSo we built one on purpose.\n\n## Instrument something that already works\n\nMost 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 hundreds of customers and passed a load test with its ledger proven consistent under concurrency **before a single span existed**.\n\n**300** — simulated customers, hundreds of concurrent transfers, ledger reconciled to zero — before any telemetry\n\nThat order matters. Telemetry from a system that was correct and load-tested first is trustworthy precisely because the thing being observed stands on its own. It is not a demo wired to look good in a dashboard.\n\n## The architecture\n\nFathom splits into two tiers on two hosts, so a transfer crosses the network — a real topology, not localhost.\n\n| Service | Tier | Responsibility |\n| --- | --- | --- |\n| `edge-gateway` | edge | Public API; verifies the token, routes every request |\n| `auth-service` | edge | Signup / login, issues and verifies JWTs |\n| `payments-service` | edge | Orchestrates a transfer end to end |\n| `accounts-service` | core | Account lifecycle and balances |\n| `ledger-service` | core | Double-entry postings — the money system of record |\n| `fraud-service` | core | Risk score; declines a share of transfers |\n\nA single transfer flows `gateway → auth → payments → fraud → ledger`, moving money atomically. That is the path we want telemetry to make visible.\n\n## Zero-code instrumentation, in three steps\n\nNo spans in the code. No providers to wire. No instrumentation module to import. Three moves, none of which touch a service's business logic.\n\n### 1. Install the distro and bootstrap the instrumentors\n\n`opentelemetry-bootstrap` inspects the environment and installs an instrumentor for every library it finds — Flask, `requests`, psycopg2, redis — so you never hand-pick them.\n\n```shell\npip install opentelemetry-distro opentelemetry-exporter-otlp-proto-http\nopentelemetry-bootstrap -a install\n```\n\n### 2. Run the app under the wrapper\n\nPrefix the start command with `opentelemetry-instrument`. That is the only difference from running it uninstrumented.\n\n```shell\nopentelemetry-instrument gunicorn --chdir services/$SERVICE --bind 0.0.0.0:$PORT app:app\n```\n\n### 3. Point it at your backend with environment variables\n\n```shell\nOTEL_SERVICE_NAME=ledger-service\nOTEL_RESOURCE_ATTRIBUTES=service.namespace=fathom\nOTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf\nOTEL_EXPORTER_OTLP_ENDPOINT=https://ingress.rocketgraph.app\nOTEL_EXPORTER_OTLP_HEADERS=Authorization=Bearer%20$API_KEY\nOTEL_TRACES_EXPORTER=otlp\nOTEL_METRICS_EXPORTER=otlp\nOTEL_LOGS_EXPORTER=otlp\nOTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED=true\n```\n\nThat is the whole integration. Every service's code is unchanged — not even an import.\n\n> \nThe reason six independent services become one trace is the `requests` instrumentor: it injects a W3C `traceparent` header on every outbound call, and the instrumented server on the other end continues the same trace. You write zero context-passing code. This is [OpenTelemetry](https://opentelemetry.io/)'s propagation model doing the work.\n\n## The gotcha: logs need a log level\n\nTraces and metrics appeared immediately. Logs did not — and this is where most people conclude, wrongly, that they need a custom log bridge. They don't.\n\nThe wrapper already attaches an exporting handler to the root logger. The catch is subtler: **Python's root logger defaults to `WARNING`, so `INFO` business logs are dropped before the handler ever sees them.** One line fixes it, no bridge required:\n\n```python\nimport logging\nlogging.getLogger(\"fathom\").setLevel(logging.INFO)   # once, in shared config\n```\n\nScope it to your own logger namespace so you export your business events without dragging in noisy third-party `INFO` chatter. Once the level is right, the services just log normally and the records flow — each one already carrying the active `trace_id`.\n\n```python\nlog.info(\"transfer declined by fraud: user=%s amount_minor=%d score=%s\", user_id, amount, score)\n```\n\n> \nAuto-instrumentation *exports* logs and correlates them to traces; it cannot *invent* them. If your services never call the logging API, there is nothing to ship. \"Turn on logs\" is really two things: enable the exporter, and give it something to export.\n\n## What lands in the backend\n\nThe same load test — hundreds of concurrent transfers — now produces a fully connected picture, three signals wide:\n\n| Signal | What you get | Code changed |\n| --- | --- | --- |\n| Traces | One connected trace per transfer, across both hosts; SQL spans included | None |\n| Metrics | HTTP RED — rate, errors, duration — per service and route | None |\n| Logs | Business events (`transfer posted`, `fraud declined`), each carrying its `trace_id` | One shared line + the log calls you'd write anyway |\n\n**1 trace** — spans gateway → auth → payments → fraud → ledger across two hosts, from a single transfer\n\nClick a declined transfer's trace and its logs are one query away — `fraud declined … score=82` sitting exactly where the span shows the decision. That correlation is the entire point of shipping all three signals to one place: [traces tell you where, logs tell you why](/blog/ai-incident-triage-explained).\n\n## Where Rocketgraph fits\n\nFathom is our reference application, and it exports over plain [OpenTelemetry](https://opentelemetry.io/) (OTLP/HTTP) — the same path any customer's own services use. Nothing about the instrumentation is Rocketgraph-specific; that is deliberate. You instrument once, with open standards, and point the endpoint wherever you like.\n\n[Rocketgraph](/about) is where that telemetry becomes cheap to keep and fast to search: OTLP in, object-storage economics underneath, usage-based pricing with no per-host fees, and AI agents that [triage issues automatically](/blog/ai-incident-triage-explained). If you are weighing options, our [cost comparison of Datadog alternatives](/blog/datadog-alternatives-2026-cost-comparison) is written to be useful even if you never send us a byte.","date_published":"2026-08-28T09:00:00Z","date_modified":"2026-08-28T09:00:00Z","authors":[{"name":"Kaushik Varanasi","url":"https://blog.rocketlog.io/authors/kaushik"}],"tags":["OpenTelemetry","Instrumentation","Architecture"]},{"id":"https://blog.rocketlog.io/blog/observability-at-scale-cheaply","url":"https://blog.rocketlog.io/blog/observability-at-scale-cheaply","title":"Observability at Scale, Cheaply: The 2026 Cost Playbook","summary":"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.","content_text":"**TL;DR**\n\nObservability 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.\n\nThe 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.\n\nThis post is the playbook we wish we'd had earlier: why costs explode, which levers actually move the bill, and where AI fits.\n\n## Why do observability costs explode at scale?\n\nThree forces compound:\n\n| Force | What happens | Why the bill grows |\n| --- | --- | --- |\n| 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 |\n| [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 |\n| Everything lands in hot storage | Full-text log indexes and unsampled traces sit on expensive, always-on infrastructure | You pay query-ready prices for data with a near-zero query rate |\n\nAdd per-host pricing on top and the failure mode is clear: your observability bill tracks your infrastructure footprint, not the value you get from the data.\n\n## Lever 1: control cardinality at the source\n\nHigh-cardinality labels — user IDs, container IDs, request IDs — are the single most common cause of surprise bills. The fixes are unglamorous and effective:\n\n- Drop or hash labels you never filter by. Do it in the collector, before data leaves your network.\n- Pre-aggregate where dashboards only ever show aggregates.\n- Put a budget on new metrics: series count is a resource, like CPU.\n\n> \nA useful habit: every metric label must answer \"what question does this let us ask?\" If nobody can name the question, the label is a cost with no customer.\n\n## Lever 2: sample traces at the tail, not the head\n\n[Tail-based sampling](/glossary#tail-based-sampling) waits until a trace completes, then keeps the interesting ones — errors, outliers, rare paths — and samples the boring ones down. You keep the debugging value of \"every failed request has a trace\" without storing millions of identical healthy ones.\n\nThe [OpenTelemetry Collector](https://opentelemetry.io/docs/collector/) ships a tail-sampling processor, so this is a config change, not a rewrite.\n\n## Lever 3: tier your storage — object storage holds the long tail\n\nThis is the big one. Most telemetry is written once and read never; it exists for the 2 a.m. incident three weeks from now. Architecture should reflect that:\n\n- A small hot tier for live dashboards, alerting, and the last day or two of high-resolution data.\n- Object storage in open columnar formats for everything else, queried on demand.\n\nObject storage runs in the low cents per GB-month — a fraction of the cost of index-backed storage — which is why [object-storage observability](/glossary#object-storage-observability) is the architectural bet behind most of the credible \"cheap at scale\" platforms, Rocketgraph included. Retention stops being the thing you ration.\n\n## Lever 4: standardize on OpenTelemetry\n\n[OpenTelemetry](https://opentelemetry.io/) keeps your instrumentation portable. That matters for cost twice: you can actually leave a vendor whose pricing turned hostile, and vendors know it — OTel-instrumented customers negotiate from strength. Proprietary agents are a switching cost you install voluntarily.\n\n## Lever 5: count the human hours — then compress them\n\nTool spend is only half the ledger. The other half is engineer time: every hour of [MTTR](/glossary#mttr) across a multi-person incident is payroll, and diagnosis — not mitigation — is where most of that time goes.\n\nThis is where [AI incident triage](/blog/ai-incident-triage-explained) changes the math. An agent that clusters the alert storm, correlates the spike with the 14:32 deploy, and hands the on-call a ranked list of probable causes with evidence attached is compressing the most expensive minutes in engineering. It also changes tooling economics: if AI does the first pass of correlation, you don't need every engineer fluent in a $70-per-seat query UI.\n\n## What this looks like in practice\n\nA reference shape for a team running a few hundred services:\n\n```yaml\n# otel-collector: the cost controls live here\nprocessors:\n  filter/drop-noisy-labels:\n    metrics:\n      exclude:\n        match_type: regexp\n        metric_names: [\"debug_.*\"]\n  tail_sampling:\n    policies:\n      - name: keep-errors\n        type: status_code\n        status_code: { status_codes: [ERROR] }\n      - name: keep-slow\n        type: latency\n        latency: { threshold_ms: 800 }\n      - name: sample-the-rest\n        type: probabilistic\n        probabilistic: { sampling_percentage: 5 }\nexporters:\n  otlp:\n    endpoint: ingest.rocketgraph.app:4317 # or any OTLP backend\n```\n\nHot tier for today, object storage for history, sampling policies you can read in one screen — and an AI agent doing the first pass when something breaks.\n\n## Where Rocketgraph fits\n\n[Rocketgraph](/about) is our attempt to make this architecture the default rather than a platform-team project: OTLP in, object-storage economics underneath, usage-based pricing with no per-host fees, and AI agents that [triage issues automatically](/blog/ai-incident-triage-explained). If you're comparing options, our [cost comparison of Datadog alternatives](/blog/datadog-alternatives-2026-cost-comparison) is written to be useful even if you never touch Rocketgraph.","date_published":"2026-07-14T09:00:00Z","date_modified":"2026-07-14T09:00:00Z","authors":[{"name":"Kaushik Varanasi","url":"https://blog.rocketlog.io/authors/kaushik"}],"tags":["Cost engineering","Observability at scale","Architecture"]},{"id":"https://blog.rocketlog.io/blog/ai-incident-triage-explained","url":"https://blog.rocketlog.io/blog/ai-incident-triage-explained","title":"AI Incident Triage, Explained: How AI Agents Cut MTTR","summary":"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.","content_text":"**TL;DR**\n\nAI 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.\"\n\n**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.\n\n## Where incident time actually goes\n\nIncident 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.\n\nThat diagnostic gap is where [MTTR](/glossary#mttr) lives, it is staffed by your most senior engineers, and it happens at the worst possible times. It is also, structurally, a correlation problem over large volumes of telemetry — which is exactly the kind of work agents are good at.\n\n## What an AI triage agent actually does\n\nA serious implementation does four jobs, in order:\n\n1. **Cluster.** Collapse the alert storm into issues. Forty alerts from one database failover should page one human once, with one title. This alone kills most [alert fatigue](/glossary#alert-fatigue).\n2. **Correlate.** Line the issue up against recent deploys, config changes, and feature flags, and traverse the service graph: the checkout service is slow *because* payments is slow *because* its connection pool is exhausted.\n3. **Rank.** Produce a short list of probable root causes, each with the evidence attached — the trace exemplars, the log lines, the deploy diff — and an explicit confidence level.\n4. **Draft.** Write the incident summary as it develops: timeline, impact, current hypothesis. Nobody should reconstruct a timeline at the postmortem from Slack scrollback.\n\n## What it cannot do (and how to keep it honest)\n\nAn agent that guesses confidently is worse than no agent. Two design rules make triage trustworthy:\n\n- **Every claim links to raw telemetry.** \"Probable cause: connection pool exhaustion\" must come with the graph and the log lines that support it. If the evidence doesn't convince a human in thirty seconds, the ranking is theater.\n- **Humans confirm; agents propose.** Triage output is a hypothesis list, not an action. Mitigation stays behind human judgment, and every triage run is auditable after the fact — including the wrong ones.\n\n> \nWhen evaluating vendors, ask to see a triage the agent got wrong and how that was surfaced to the team. A vendor who can't show you a miss is showing you a demo, not a product.\n\n## How to evaluate an AI triage tool\n\nA practical checklist:\n\n| Question | What good looks like |\n| --- | --- |\n| Does it see changes, not just telemetry? | Deploys, config, and flags are first-class inputs |\n| Is evidence attached to every hypothesis? | One click from claim to raw signal |\n| Does it cluster before it pages? | One incident, one page, one title |\n| Is it auditable? | Full triage transcript, including misses |\n| Does it work with your instrumentation? | Native [OpenTelemetry](/glossary#opentelemetry), no proprietary agents |\n\n## How Rocketgraph implements this\n\n[Rocketgraph's](/about) triage agents run on the same object-storage telemetry lake the rest of the platform uses, so correlation isn't limited to a hot window. When an issue opens, the agent clusters alerts, diffs against the change feed, walks the trace graph, and posts a ranked hypothesis list with evidence links — typically before the page lands. Engineers confirm or override, and every run is stored as an auditable transcript.\n\nThe cost angle matters too: triage minutes are the most expensive minutes in engineering, and [cheap observability at scale](/blog/observability-at-scale-cheaply) is only cheap if it counts human time in the bill.","date_published":"2026-07-07T09:00:00Z","date_modified":"2026-07-14T09:00:00Z","authors":[{"name":"Kaushik Varanasi","url":"https://blog.rocketlog.io/authors/kaushik"}],"tags":["AI triage","Incident response","MTTR"]},{"id":"https://blog.rocketlog.io/blog/datadog-alternatives-2026-cost-comparison","url":"https://blog.rocketlog.io/blog/datadog-alternatives-2026-cost-comparison","title":"Datadog Alternatives in 2026: An Honest Cost Comparison for Teams at Scale","summary":"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.","content_text":"**TL;DR**\n\nIf 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.\n\nDatadog 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.\n\nWe 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.\n\n## How the alternatives actually differ\n\nThe market splits by pricing model more than by feature list. As of mid-2026 (verify current pricing before deciding — models and prices change):\n\n| Platform | Pricing model | Strongest when | Watch out for |\n| --- | --- | --- | --- |\n| [Datadog](https://www.datadoghq.com/pricing/) | Per host + per custom-metric series + per GB indexed | You want one polished suite and budget is secondary | Costs compound across 20+ SKUs; cardinality bills surprise almost everyone |\n| [New Relic](https://newrelic.com/pricing) | Per GB ingested + per user | Consolidated ingest-based billing appeals | Per-user fees add up for wide teams; egress of data is still yours to manage |\n| [Grafana Cloud](https://grafana.com/pricing/) | Usage-based per signal | Metrics-heavy, OSS-aligned teams | High cardinality still costs; self-managed pieces cost engineer time |\n| [Honeycomb](https://www.honeycomb.io/pricing) | Per event | Deep trace-first debugging of complex systems | Event pricing needs sampling discipline; less of a metrics suite |\n| Self-hosted (Prometheus/Loki/Tempo or ClickHouse-based) | Infra + engineer time | You have a real platform team and predictable workloads | The observability stack becomes something you get paged for |\n| [Rocketgraph](/about) | Usage-based; telemetry on object storage; no per-host fees | Large fleets, long retention, teams that want AI to do first-pass triage | Young platform; smaller integration catalog than Datadog's |\n\n> \nCompare pricing models, not list prices. List prices change and discounts expire; a per-host model will always track your fleet, and a per-series model will always track your cardinality. Structure outlives negotiation.\n\n## The three cost traps to model before you choose\n\n- **Custom metrics cardinality.** If your services emit labels like `customer_id`, per-series pricing turns them into a tax. Ask every vendor: what does one metric with 100k label combinations cost?\n- **Indexed everything.** Full-text indexing of all logs and spans means paying query-ready prices for data you'll read approximately never. Prefer platforms that tier to [object storage](/glossary#object-storage-observability) and query on demand.\n- **The human line item.** Self-hosting looks free until you count platform-engineer time; expensive suites look costly until AI triage cuts your [MTTR](/glossary#mttr). Count both directions honestly — our [cost playbook](/blog/observability-at-scale-cheaply) has the framework.\n\n## Migrate the smart way: OpenTelemetry first\n\nThe lowest-risk path off any vendor is the same:\n\n1. Re-instrument with [OpenTelemetry](https://opentelemetry.io/) (or front your agents with an OTel Collector).\n2. Dual-ship telemetry to the old and new backend from the collector.\n3. Rebuild the dashboards and alerts you actually use — most teams find they use fewer than they think.\n4. Cut over when the new stack has caught a real incident, then cancel.\n\nOnce you're OTel-native, backends compete for you on price and product every year — which is exactly the position to be in.\n\n## Where Rocketgraph honestly fits\n\nPick [Rocketgraph](/about) when your bill is dominated by fleet size, retention, or cardinality, and when [AI-run first-pass triage](/blog/ai-incident-triage-explained) would meaningfully cut your incident hours. Stick with an incumbent if you depend on a long tail of niche integrations, or hold off on any young platform if your compliance process needs a decade of vendor history. We'd rather you pick right than pick us.","date_published":"2026-06-29T09:00:00Z","date_modified":"2026-07-14T09:00:00Z","authors":[{"name":"Kaushik Varanasi","url":"https://blog.rocketlog.io/authors/kaushik"}],"tags":["Cost engineering","Comparisons","Datadog alternative"]},{"id":"https://blog.rocketlog.io/blog/what-is-rocketgraph","url":"https://blog.rocketlog.io/blog/what-is-rocketgraph","title":"What Is Rocketgraph? Architecture, Pricing Model, and AI Triage, Explained","summary":"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.","content_text":"**TL;DR**\n\nRocketgraph 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.\n\n**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.\n\n## The architecture in one diagram's worth of words\n\nTelemetry 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.\n\nThree consequences fall out of this design:\n\n- **Retention stops being rationed.** Keeping 13 months of traces costs object-storage prices, not hot-index prices.\n- **Cost tracks usage, not fleet size.** A thousand small hosts emitting modest telemetry cost less than fifty hosts emitting a firehose — as it should be.\n- **Triage sees history.** \"Is this normal for a Monday?\" is answerable, because last quarter's Mondays are still queryable.\n\n## Why the pricing model is the product\n\nObservability pricing fails teams in predictable ways: per-host fees tax fleet growth, per-series fees tax [cardinality](/glossary#cardinality), per-seat fees tax collaboration. Rocketgraph charges for two things — ingest and query — and nothing else. The design goal is simple: your bill should grow when you get more value, not when you autoscale.\n\nThe full reasoning (and the levers that keep any stack cheap, ours included) is in our [cost playbook for observability at scale](/blog/observability-at-scale-cheaply).\n\n## What the AI triage agents do\n\nWhen an anomaly or alert fires, a Rocketgraph agent:\n\n1. **Clusters** related alerts into a single issue with one title, so one failure pages one human once.\n2. **Correlates** the issue against the change feed — deploys, config flips, feature flags — and walks the trace graph across services.\n3. **Ranks** probable root causes, each with evidence attached: trace exemplars, log excerpts, the deploy diff, and an explicit confidence level.\n4. **Drafts** the incident summary and keeps the timeline current through mitigation.\n\nAgents propose; humans confirm. Every triage run is stored as an auditable transcript — including the misses, because an agent you can't audit is an agent you can't trust.\n\n## Getting data in: five minutes with OpenTelemetry\n\nIf you already run an OTel Collector, onboarding is an exporter block:\n\n```yaml\nexporters:\n  otlp/rocketgraph:\n    endpoint: ingest.rocketgraph.app:4317\n    headers:\n      x-rocketgraph-key: ${ROCKETGRAPH_API_KEY}\n\nservice:\n  pipelines:\n    traces:\n      exporters: [otlp/rocketgraph]\n    metrics:\n      exporters: [otlp/rocketgraph]\n    logs:\n      exporters: [otlp/rocketgraph]\n```\n\nNo proprietary agent, nothing to install on hosts, and dual-shipping alongside your current vendor is the recommended way to evaluate — see the [migration path](/blog/datadog-alternatives-2026-cost-comparison) for the step-by-step.\n\n## Who Rocketgraph is for (and not for)\n\nIt's built for teams whose observability bill is scaling faster than traffic, who want long retention without rationing, and who'd rather have AI do the first pass of incident correlation. It's not the right pick if you need a decade-old vendor for procurement, or a long tail of niche integrations on day one — we say so plainly in our [comparison post](/blog/datadog-alternatives-2026-cost-comparison).\n\nQuestions the docs don't answer: [hello@rocketgraph.app](mailto:hello@rocketgraph.app).","date_published":"2026-06-22T09:00:00Z","date_modified":"2026-07-14T09:00:00Z","authors":[{"name":"Kaushik Varanasi","url":"https://blog.rocketlog.io/authors/kaushik"}],"tags":["Rocketgraph","Architecture","AI triage"]}]}