mohsen_hassani/LedgerLine
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Correct OTLP metrics/logs behaviour to 404, and start Phase 2

Browse Source 
Alloy only registers an OTLP/HTTP route for a signal with an output, so
POST /v1/metrics and /v1/logs return 404 rather than being accepted and
silently dropped (verified live against otlp.vione.cloud). Fix the claim
everywhere it appeared. Also mark Phase 2 in progress.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Movses Aslanyan
2026-10-12 20:09:38 +03:30
co-authored by Claude Opus 5.5
parent 7719ef5fcf
commit 995c93982a
8 changed files with 29 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/roadmap/intro.md
+6 -4
View File
@@ -231,10 +231,12 @@ otelcol.receiver.otlp "default" {
}
```
There is **no `metrics` output and no `logs` output**. OTLP metrics and OTLP logs
your app sends are accepted and then **silently discarded** — no error, no warning,
just nothing arriving in Grafana. This is the single most likely thing to eat an
evening.
There is **no `metrics` output and no `logs` output**, and Alloy only registers
an OTLP/HTTP route for a signal that has one. So OTLP metrics and OTLP logs your
app sends get a **404** from `/v1/metrics` and `/v1/logs` (verified live
2026-10-12). The only evidence is an export error in your app's own logs, which
is easy to miss. Nothing shows up in Alloy, Prometheus or Loki; data just never
arrives in Grafana. This is the single most likely thing to eat an evening.
The diagram confirms this is deliberate: the OTLP input is labelled "spans +
resource attrs", and metrics are drawn as a separate `/metrics` Prometheus-exposition