Open source · Apache-2.0
Your logs are mostly sugar.
Diet Telemetry finds the empty calories — health checks, DEBUG noise, dead metrics — and hands you a diff you approve. It runs on your machine and reads only.
SCROLL TO READ THE LABEL · OR DRAG THE CAN
The problem
You are paying to store noise.
Health checks that always pass. DEBUG lines from last quarter. Request IDs used as metric labels. Emails sitting in plaintext. None of it is queried. All of it is billed.
| { | ||
| "level": | "DEBUG" | ← noise |
| "msg": | "GET /healthz 200 OK" | ← noise |
| "user_email": | "a@corp.com" | ← PII |
| "request_id": | "a1b2c3d4…" | ← cardinality |
| "service": | "checkout" | |
| "service.name": | "checkout-api" | ← naming drift |
| } | ||
× 9,000 / minute
13 checks
Deterministic. No model in the loop.
All thirteen run on every analysis. These six turn up in almost every account we have looked at.
Health Check Spam
Endpoints like /health, /healthz, /ready, /live that always return 200 and generate thousands of log lines per hour with zero signal value.
DEBUG / TRACE Noise
Log lines matching repeated message fingerprints from debug statements left in production. They pad your bill and tell you nothing.
PII Fields
Email addresses, API keys, bearer tokens, and session IDs detected in log fields using pattern matching. No ML required.
High-Cardinality Labels
Fields like request_id, trace_id, or user_id used as metric tags or label values. They explode your series count and your bill.
Unreferenced Metrics
Metrics with zero references across all dashboards, alerts, and queries in your account. You are paying to store them and never looking at them.
Naming Drift
The same concept expressed three different ways: service, service.name, app. Inconsistent naming breaks queries and makes on-call harder.
Duplicate Log Streams
The same log line arriving from multiple sources or agents. Common after migrations where the old agent was never turned off.
Excessive Sampling Rate
Traces sampled at 100% for high-volume, low-value paths like static asset serving or health checks.
Stale Dashboards
Dashboards not viewed in 90+ days that still drive metric retention and indexing costs.
Alert Without Runbook
Alerts that fire but have no runbook link, no owner, and no recent acknowledgement history.
Over-Tagged Resources
Resources with 20+ labels where most are never used in queries. Tag cardinality has a real cost.
Log Flood Events
Burst events where a single service emits 10x its normal log volume, often from a retry loop or misconfigured logger.
Orphaned Instrumentation
Custom metrics or spans referencing services or endpoints that no longer exist in your infrastructure.
How Diet Telemetry works
01 / 03
Connect
One command, or the same analyzer as an MCP server in your editor. Start with no credentials.
01 / 03
Connect
One command, or the same analyzer as an MCP server in your editor. Start with no credentials.
02 / 03
Analyze
Read-only API calls. The analyzer runs on your machine and nothing is sent anywhere.
03 / 03
Review
A Markdown report, an OTel draft, and a Last9 policy. Delete what you disagree with.
SAMPLE-REPORT.MD
Read-only MCP tools. There is no write implementation — not disabled, not implemented.
OAuth tokens stay on localhost. The web server binds to loopback.
Every finding is pattern matching and heuristics. No model, no surprises.
Every output is a draft. You review the diff, and you decide what to apply.
Questions
Before you run it.
What is Diet Telemetry?
Diet Telemetry is an open-source analyzer that finds waste in observability data. It runs thirteen deterministic checks against your logs, metrics, and traces, then outputs a Markdown report, an OpenTelemetry Collector config, and a Last9 policy file. It uses read-only API calls, runs on your machine, and applies nothing without your approval.
Does Diet Telemetry send my data anywhere?
No. The analyzer runs on your machine and makes read-only API calls to your existing observability vendor. Nothing is uploaded to Last9 or to any third party. The OAuth token stays on localhost, and the local web server binds to the loopback interface.
Does it use an LLM?
No. All thirteen checks are pattern matching and heuristics — regular expressions for PII fields, reference counting for unused metrics, fingerprinting for repeated log lines. The same input produces the same output every time. There is no model in the loop and no inference cost.
Can it delete or change my telemetry configuration?
No. The MCP tools are read-only, and there is no write implementation — not disabled behind a flag, but absent from the codebase. The output is a diff that you review and apply yourself.
Which observability vendors does it support?
Datadog and Last9 today, through their read APIs. A bundled sample dataset lets you run the full analysis with no credentials at all, if you want to see the output before connecting an account.
What does it actually produce?
Three files: a Markdown report listing every finding, an OpenTelemetry Collector OTTL config that drops the noise, and a Last9 policy file. You delete whatever you disagree with before applying any of it.
What does it cost?
Nothing. Diet Telemetry is open source under Apache-2.0 and runs entirely on your own machine.