Telemetry for Runtime Metrics

Telemetry for Runtime Metrics

Arxo correlates runtime trace data with the static call graph to produce traffic-weighted metrics: runtime centrality, traffic hotspots, critical path analysis, code/runtime drift detection, and PII-flow prioritization.

Overview

• Data flow: Trace data → parser → span-to-code mapping → derived index → metric plugins
• Metrics enabled: centrality, traffic_hotspot, critical_path, runtime_drift, sensitive_data_flow, test_coverage (optional)

Use the Runtime preset or enable these metrics explicitly.

Supported Trace Formats

Format	format value	Source	Notes
OTLP JSON	otel_json	OpenTelemetry exporters	resourceSpans → scopeSpans → spans
Zipkin JSON v2	zipkin_json	Zipkin, OpenTelemetry→Zipkin	Single span or array of spans
Jaeger JSON	jaeger_json	Jaeger Query API	{ "data": [ { "traceID", "spans": [...] } ] } or single trace

Configuration

Add a telemetry block under data in your config (see Configuration):

data:
  telemetry:
    source_path: ./telemetry/traces.json   # file or directory of .json
    format: otel_json                      # otel_json | zipkin_json | jaeger_json
    service_name: my-service               # optional filter
    time_window:                            # optional time filter
      start: "2024-01-01T00:00:00Z"
      end: "2024-01-07T23:59:59Z"

metrics:
  - id: centrality
    enabled: true
  - id: traffic_hotspot
    enabled: true
  - id: critical_path
    enabled: true
  - id: runtime_drift
    enabled: true
  - id: sensitive_data_flow   # optional: prioritizes PII violations on hot paths
    enabled: true
  - id: test_coverage          # optional: prioritizes undertested modules on hot paths
    enabled: true

Collecting Trace Data

1. Instrument your service with OpenTelemetry, Zipkin, or Jaeger.
2. Export traces as JSON (file or directory of .json files).
3. Set data.telemetry.source_path to the file or directory.
4. Set data.telemetry.format to match your exporter: otel_json, zipkin_json, or jaeger_json.
5. Optionally set time_window and service_name to filter traces.

Span-to-Code Mapping

For Arxo to map spans to call graph nodes, traces should include:

• code.filepath or code.file_path in span attributes/tags – file path for the span
• Span name / operationName – matched to call graph node IDs (file paths or function names)

Without these, spans may end up in runtime_drift.unmapped_span_count.

Metric Interpretations

Metric	Key values	Meaning
centrality (with telemetry)	centrality.function.traffic_weighted_betweenness_max, centrality.function.high_traffic_hub_count	Nodes central in the call graph and heavily used at runtime
traffic_hotspot	traffic_hotspot.count, traffic_hotspot.max_score	Code that is frequently changed, heavily used, and latency-sensitive
critical_path	critical_path.max_latency_ms, critical_path.bottleneck_count	Longest latency paths and bottlenecks
runtime_drift	runtime_drift.dead_code_count, runtime_drift.unmapped_span_count	Dead code (static nodes never executed) and unmapped runtime spans
sensitive_data_flow	runtime_exposed_violation_count, highest_runtime_exposure	PII/sensitive data flow violations on exercised paths; violations on hot paths listed first
test_coverage	runtime_exposed_untested_count	Undertested critical modules that are on hot paths; list ordered with high-traffic undertested first

Use Cases

• Refactoring: Prioritize high-traffic hubs and traffic hotspots
• Performance: Focus on critical path and bottleneck nodes
• Cleanup: Use drift metrics to find dead code and unmapped production paths
• Validation: Compare static structure with runtime behavior
• Security: With sensitive_data_flow, prioritize PII flow violations on paths actually exercised in production
• Testing: With test_coverage, prioritize testing on undertested modules that carry production traffic