Merge branch 'pratik/otel-phase8-log-correlation' into pratik/otel-phase9-metric-gap-fill

# Conflicts:
#	docker/telemetry/docker-compose.yml

OpenTelemetryPlan/09-data-collection-reference.md

@@ -747,7 +747,7 @@ Phase 8 injects OTel trace context into xrpld's `Logs::format()` output, enablin
 Example:
 
 ```
-2024-01-15T10:30:45.123Z LedgerMaster:NFO trace_id=abc123def456789012345678abcdef01 span_id=0123456789abcdef Validated ledger 42
+2024-Jan-15 10:30:45.123456 UTC LedgerMaster:NFO trace_id=abc123def456789012345678abcdef01 span_id=0123456789abcdef Validated ledger 42
 ```
 
 - **`trace_id=<hex32>`** — 32-character lowercase hex trace identifier. Links to the distributed trace in Tempo/Jaeger.
@@ -784,7 +784,7 @@ Bidirectional linking between logs and traces is configured via Grafana datasour
 
 ### Loki Backend
 
-Grafana Loki (v2.9.0) serves as the log storage backend. It receives log entries from the OTel Collector's `loki` exporter via the push API at `http://loki:3100/loki/api/v1/push`.
+Grafana Loki (v3.4.2) serves as the log storage backend. It receives log entries from the OTel Collector's `otlphttp/loki` exporter via the native OTLP endpoint at `http://loki:3100/otlp`.
 
 ### LogQL Query Examples
 

OpenTelemetryPlan/Phase8_taskList.md

@@ -76,7 +76,7 @@
   - Add Loki service:
     ```yaml
     loki:
-      image: grafana/loki:2.9.0
+      image: grafana/loki:3.4.2
       ports:
         - "3100:3100"
       command: -config.file=/etc/loki/local-config.yaml
@@ -127,10 +127,8 @@
   - Add Loki exporter:
     ```yaml
     exporters:
-      otlp/loki:
-        endpoint: loki:3100
-        tls:
-          insecure: true
+      otlphttp/loki:
+        endpoint: http://loki:3100/otlp
     ```
 
 - Mount xrpld's log directory into the collector container via docker-compose volume

docker/telemetry/TESTING.md

@@ -491,7 +491,7 @@ Expected: log lines with `trace_id=<32hex> span_id=<16hex>` between the
 severity code and the message. Example:
 
 ```
-2024-01-15T10:30:45.123Z RPCHandler:NFO trace_id=abc123def456789012345678abcdef01 span_id=0123456789abcdef Calling server_info
+2024-Jan-15 10:30:45.123456 UTC RPCHandler:NFO trace_id=abc123def456789012345678abcdef01 span_id=0123456789abcdef Calling server_info
 ```
 
 Lines emitted outside of an active span (background tasks, startup) will

docker/telemetry/docker-compose.yml

@@ -36,7 +36,7 @@ services:
     volumes:
       # Mount collector pipeline config (receivers → processors → exporters)
       - ./otel-collector-config.yaml:/etc/otel-collector-config.yaml:ro
-      # Phase 8: Mount rippled log directories for filelog receiver.
+      # Mount rippled log directories for filelog receiver.
       # User-run xrpld writes to /var/log/xrpld/<network>/debug.log.
       # Integration test still writes to /tmp/xrpld-integration/.
       # Both are mounted read-only so the collector can tail debug.log files.
@@ -63,7 +63,7 @@ services:
     networks:
       - xrpld-telemetry
 
-  # Phase 8: Grafana Loki for centralized log ingestion and log-trace
+  # Grafana Loki for centralized log ingestion and log-trace
   # correlation. Loki 3.x supports native OTLP ingestion, so the OTel
   # Collector exports via otlphttp to Loki's /otlp endpoint.
   # Query logs via Grafana Explore -> Loki at http://localhost:3000.

docker/telemetry/grafana/provisioning/datasources/loki.yaml

@@ -1,12 +1,8 @@
 # Grafana Loki data source provisioning for rippled log-trace correlation.
 #
-# Phase 8: Log-Trace Correlation and Centralized Log Ingestion
-#
 # 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.
-#
-# See: OpenTelemetryPlan/Phase8_taskList.md (Tasks 8.2, 8.4)
 
 apiVersion: 1
 

docker/telemetry/grafana/provisioning/datasources/tempo.yaml

@@ -5,10 +5,10 @@
 #
 # Search filters provide pre-configured dropdowns in the Explore UI.
 # Each phase adds filters for the span attributes it introduces.
-# Phase 1b (infra): Base filters — node identity, service, span name, status.
-# Phase 2 (RPC):    RPC command, status, role filters.
-# Phase 3 (TX):     Transaction hash, local/peer origin, status.
-# Phase 4 (Cons):   Consensus mode, round, ledger sequence, close time.
+# Base filters — node identity, service, span name, status.
+# RPC command, status, role filters.
+# Transaction hash, local/peer origin, status.
+# Consensus mode, round, ledger sequence, close time.
 
 apiVersion: 1
 
@@ -26,14 +26,14 @@ datasources:
       # Prometheus service is added to docker-compose.yml.
       serviceMap:
         datasourceUid: prometheus
-      # Phase 8: Trace-to-log correlation — enables one-click navigation
+      # Trace-to-log correlation — enables one-click navigation
       # from a Tempo trace to the corresponding Loki log lines. Filters
       # by trace_id so only logs from the same trace are shown.
       tracesToLogs:
         datasourceUid: loki
         filterByTraceID: true
         filterBySpanID: false
-        tags: ["partition", "severity"]
+        tags: []
       tracesToMetrics:
         datasourceUid: prometheus
         spanStartTimeShift: "-1h"
@@ -100,7 +100,7 @@ datasources:
             operator: ">"
             scope: intrinsic
             type: dynamic
-          # Phase 2: RPC tracing filters
+          # RPC tracing filters
           - id: rpc-command
             tag: command
             operator: "="
@@ -116,7 +116,7 @@ datasources:
             operator: "="
             scope: span
             type: dynamic
-          # Phase 3: Transaction tracing filters
+          # Transaction tracing filters
           - id: tx-hash
             tag: tx_hash
             operator: "="
@@ -137,8 +137,8 @@ datasources:
             tag: tx_type
             operator: "="
             scope: span
-            type: static
-          # Phase 4: Consensus tracing filters
+            type: dynamic
+          # Consensus tracing filters
           - id: consensus-mode
             tag: consensus_mode
             operator: "="
@@ -200,7 +200,7 @@ datasources:
             operator: "="
             scope: span
             type: static
-          # Phase 3/4: Additional transaction and queue filters
+          # Additional transaction and queue filters
           - id: tx-path
             tag: path
             operator: "="

docker/telemetry/integration-test.sh

@@ -73,7 +73,7 @@ check_span() {
     fi
 }
 
-# Phase 8: Verify trace_id injection in xrpld log output.
+# Verify trace_id injection in xrpld log output.
 # Greps all node debug.log files for the "trace_id=<hex> span_id=<hex>"
 # pattern that Logs::format() injects when an active OTel span exists.
 # Also cross-checks that a trace_id found in logs matches a trace in Tempo.
@@ -563,7 +563,7 @@ check_span "peer.validation.receive"
 # Step 9b: Verify log-trace correlation (Phase 8)
 # ---------------------------------------------------------------------------
 log ""
-log "--- Phase 8: Log-Trace Correlation ---"
+log "--- Log-Trace Correlation ---"
 check_log_correlation
 
 # ---------------------------------------------------------------------------

docker/telemetry/otel-collector-config.yaml

@@ -14,7 +14,7 @@
 # metrics pipelines. Metrics are exported to Prometheus alongside
 # span-derived metrics.
 #
-# Phase 8: The filelog receiver tails xrpld's debug.log files under
+# The filelog receiver tails xrpld's debug.log files under
 # /var/log/rippled/ (mounted from the host). A regex_parser operator
 # extracts timestamp, partition, severity, and optional trace_id/span_id
 # fields injected by Logs::format(). Parsed logs are exported to Grafana
@@ -31,7 +31,7 @@ receivers:
         endpoint: 0.0.0.0:4317
       http:
         endpoint: 0.0.0.0:4318
-  # Phase 8: Filelog receiver tails xrpld debug.log files for log-trace
+  # Filelog receiver tails xrpld debug.log files for log-trace
   # correlation. Extracts structured fields (timestamp, partition, severity,
   # trace_id, span_id, message) via regex. The trace_id and span_id are
   # optional — only present when the log was emitted within an active span.
@@ -166,7 +166,7 @@ exporters:
     endpoint: tempo:4317
     tls:
       insecure: true
-  # Phase 8: Export logs to Grafana Loki via OTLP/HTTP. Loki 3.x supports
+  # Export logs to Grafana Loki via OTLP/HTTP. Loki 3.x supports
   # native OTLP ingestion on its /otlp endpoint, replacing the removed
   # loki exporter (dropped in otel-collector-contrib v0.147.0).
   otlphttp/loki:
@@ -191,7 +191,7 @@ service:
       receivers: [otlp, spanmetrics]
       processors: [resource/tier, resource/stripsdk, batch]
       exporters: [prometheus]
-    # Phase 8: Log pipeline ingests xrpld debug.log via filelog receiver,
+    # Log pipeline ingests xrpld debug.log via filelog receiver,
     # batches entries, and exports to Loki for log-trace correlation.
     logs:
       receivers: [filelog]

docs/telemetry-runbook.md

@@ -1022,7 +1022,7 @@ docker compose -f docker/telemetry/docker-compose.yml logs grafana | grep -i ale
 When xrpld is built with `telemetry=ON`, log lines emitted within an active OpenTelemetry span automatically include `trace_id` and `span_id` fields:
 
 ```
-2024-01-15T10:30:45.123Z LedgerMaster:NFO trace_id=abc123def456789012345678abcdef01 span_id=0123456789abcdef Validated ledger 42
+2024-Jan-15 10:30:45.123456 UTC LedgerMaster:NFO trace_id=abc123def456789012345678abcdef01 span_id=0123456789abcdef Validated ledger 42
 ```
 
 This enables bidirectional navigation between logs and traces in Grafana:

src/xrpld/consensus/DisputedTx.h

@@ -65,20 +65,6 @@ public:
         return ourVote_;
     }
 
-    //! Number of peers voting to include the transaction.
-    [[nodiscard]] int
-    getYays() const
-    {
-        return yays_;
-    }
-
-    //! Number of peers voting to exclude the transaction.
-    [[nodiscard]] int
-    getNays() const
-    {
-        return nays_;
-    }
-
     //! Are we and our peers "stalled" where we probably won't change
     //! our vote?
     [[nodiscard]] bool
@@ -195,6 +181,20 @@ public:
     [[nodiscard]] json::Value
     getJson() const;
 
+    //! Number of peers voting yes.
+    [[nodiscard]] int
+    getYays() const
+    {
+        return yays_;
+    }
+
+    //! Number of peers voting no.
+    [[nodiscard]] int
+    getNays() const
+    {
+        return nays_;
+    }
+
 private:
     int yays_{0};   //< Number of yes votes
     int nays_{0};   //< Number of no votes