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
CLAUDE.md
+8 -3
View File
@@ -55,8 +55,12 @@ them against the live system rather than assuming — they were read from the co
at one point in time and the user may have since extended them.
1. **Alloy's OTLP receiver only forwards traces.** Its `output` block declares
`traces` and nothing else. OTLP **metrics and logs are accepted and silently
discarded** — no error anywhere. This is deliberate: the platform's own diagram
`traces` and nothing else. OTLP **metrics and logs are rejected**: Alloy only
registers an OTLP/HTTP route for a signal that has an output, so
`POST /v1/metrics` and `POST /v1/logs` return **404** while `/v1/traces`
returns 200 (verified live 2026-10-12; gRPC is cluster-internal and untested).
The failure is visible only in the sender's own export-error logs — nothing
shows up in Alloy, Prometheus or Loki. This is deliberate: the platform's own diagram
labels the OTLP input "spans + resource attrs" and draws app metrics as a
separate `/metrics` Prometheus-exposition input. Never tell the user their OTLP
metrics "should be arriving"; check Prometheus or the Alloy UI first.
@@ -424,7 +428,8 @@ Things a well-meaning assistant does wrong here:
exporter pipelines. A correct-looking Collector config is a wrong answer here.
- **Adding `spanmetrics` or `servicegraph` connectors.** Tempo's metrics-generator
already does this.
- **Assuming OTLP metrics or logs arrive.** Alloy drops both silently. Verify in
- **Assuming OTLP metrics or logs arrive.** Alloy 404s both over OTLP/HTTP, and
the only trace of that is an export error in the app's logs. Verify in
Prometheus / Loki before claiming anything works.
- **Emitting `otelTraceID` instead of lowercase `trace_id`.** Breaks the provisioned
Loki derived field with no visible error.