Signal reference
Use the right signal.
Traces explain individual operations. Metrics describe observations over time. Logs preserve recorded events. Export each signal deliberately, then relate the evidence.
On this page
What Lantern accepts
| Signal | Ingestion and investigation |
|---|---|
| Traces | OTLP/HTTP Protobuf at /v1/traces. Search and summarize spans, inspect parent/child traces, discover attributes and compare cohorts. |
| Metrics | OTLP/HTTP Protobuf at /v1/metrics. Gauges, sums, explicit and exponential histograms, and summaries with semantic query operations. |
| Logs | OTLP/HTTP Protobuf at /v1/logs. Discover fields, stream matching records and summarize by severity, service, body or exported attributes. |
All three use the ingest origin and ingestion key. Lantern supports gzip. Each signal still needs its own working SDK exporter or Collector pipeline. Exporting traces does not automatically export logs or resource metrics.
Choose a metric operation
First discover names with list_metrics. Select an operation compatible with the metric’s kind and temporality; unsupported or ambiguous combinations fail explicitly.
| Operation | Meaning |
|---|---|
raw | Recorded observations per original series, including explicit missing markers. |
latest | The last observation in the selected window per series. |
increase | Observed first-to-last increase of a monotonic cumulative sum, accounting for supported reset evidence. |
rate | That observed increase divided by elapsed seconds. No extrapolation to unobserved time. |
delta_sum | Sum of non-overlapping delta intervals wholly inside the selected window. |
distribution | Latest original explicit or exponential histogram point per series. |
summary | Latest original summary point per series, retaining that series’ quantiles. |
Exact integers are decimal strings and rates can be rational strings. A missing value is not zero. Summary quantiles remain per series; averaging them does not produce a global percentile. The metric API does not implement PromQL, histogram quantile estimation or cross-series histogram merging.
Metric aggregation rejects truncated inputs. Refine the time window or use a discovered series_key if the query exceeds a bound; do not substitute a partial aggregate.
Connect logs to a trace
Instrument your logging bridge to export OTLP records, with service/resource attributes and the active trace and span IDs where available. A raw stdout line or a trace ID buried only in free text does not automatically become structured trace context.
Use list_log_fields, query_logs and stream_logs to inspect available data. Error summaries count severity ERROR and above. Log records have no span duration. Stream bodies longer than 4 KiB and long attribute strings are previews.
When a record carries a structured trace_id, open that trace in the same time window. A trace can still have no matching logs because logging was disabled, context was absent or export/retention left a gap.
Host, pod and process metrics
CPU, memory, filesystem and network observations require metric instrumentation or a receiver that collects them. They are not derived from span duration.
The current Hosts page reads kubeletstats-style node and pod metrics such as k8s.node.cpu.usage, k8s.node.memory.working_set and k8s.pod.memory.working_set, grouped by Kubernetes resource identity.
To populate it, configure an appropriate per-node Collector distribution with kubeletstats, Kubernetes permissions, a reachable kubelet endpoint and valid TLS trust; export its metric pipeline to Lantern. Installing that receiver and its RBAC is an infrastructure task beyond changing an ingestion URL.
Process or runtime memory metrics likewise need a runtime SDK, process receiver or another exporter. Discover the exported names in Metrics rather than assuming a particular memory metric exists.
Coverage and retention
Use a common time window, service and resource identity when comparing signals. Keep sampling, missing values, incomplete flags and export delays visible. Matching timestamps are a starting point for an investigation.
The current public pilot uses seven-day telemetry retention. Readiness is not coverage: get_status checks the backend, while observed services, metric names and log records show what actually arrived. Its accepted-attempt counters can include retries and reset on restart.
For a practical first investigation, follow the MCP workflow or inspect a known trace in the browser.