Files
rippled/docker/telemetry/grafana/provisioning/datasources/loki.yaml
Pratik Mankawde 6a2570e26e Merge branch 'pratik/otel-phase8-log-correlation' into pratik/otel-phase9-metric-gap-fill
# Conflicts:
#	docker/telemetry/docker-compose.yml
2026-07-07 20:00:36 +01:00

36 lines
1.6 KiB
YAML

# Grafana Loki data source provisioning for rippled log-trace correlation.
#
# Loki ingests rippled logs via OTel Collector's filelog receiver.
# The derivedFields config links trace_id values in log lines back to
# Tempo traces, enabling one-click log-to-trace navigation in Grafana.
apiVersion: 1
datasources:
- name: Loki
type: loki
access: proxy
url: http://loki:3100
uid: loki
jsonData:
derivedFields:
# Trace ID is an OTel-issued 32-hex value emitted by Logs::format()
# as `trace_id=...`. Grafana treats the captured value as a Tempo
# trace ID, opening the trace directly via Tempo's trace-by-id API.
- datasourceUid: tempo
matcherRegex: "trace_id=(\\w+)"
name: TraceID
url: "$${__value.raw}"
# 64-char uppercase hex tokens in log bodies are XRPL ledger
# hashes (or tx hashes). They are NOT OTel trace IDs and cannot
# be resolved via the trace-by-id endpoint. Build a Grafana
# Explore deep-link that runs TraceQL on the span attribute
# `xrpl.consensus.ledger_id` — set on `consensus.round` spans to
# the full prev_ledger hash. This finds the round span whose
# first 16 bytes were folded into the OTel trace_id by
# SpanGuard::hashSpan().
- matcherRegex: "\\b([A-F0-9]{64})\\b"
name: ConsensusLedgerHash
urlDisplayLabel: "Search Tempo"
url: '/explore?schemaVersion=1&orgId=1&panes={"tempo":{"datasource":"tempo","queries":[{"refId":"A","queryType":"traceql","query":"{.xrpl.consensus.ledger_id=\"$${__value.raw}\"}"}],"range":{"from":"now-1h","to":"now"}}}'