Skip to main content

Log Monitoring — Overview

Logs in CodeXray are a first-class signal, not an afterthought. They're automatically collected from every service and host you monitor, clustered into recurring patterns on the node itself, and correlated with the RED metrics, traces, and deployments of the services that emitted them.

More than a log viewer

Traditional log tools are search engines over raw lines. CodeXray treats logs as one of four telemetry types — alongside metrics, traces, and profiles — and wires them into the same incident workflow. A spike in errors on a RED chart is one click away from the log pattern that caused it.

How Logs Reach CodeXray​

CodeXray ingests logs through two complementary channels — and you can use either, or both together for the same service.

1. Container Logs — via the Node Agent (automatic, no app changes)​

The CodeXray Node Agent discovers container logs automatically on every host and streams them into the backend. It captures whatever your containers write to stdout / stderr, no matter which container runtime or logging driver you use:

  • Docker — JSON file driver
  • Containerd — CRI log format
  • journald — systemd-managed logs
  • File-based — /var/log/* on the host

No configuration on your side. Drop the agent on a node and its container logs appear in the UI within minutes. This is the widest safety net — it covers even logs emitted before your app's own logger is initialised (startup errors, crashes, language-runtime output).

2. Application Logs — via the OpenTelemetry SDK​

If your services are instrumented with the OpenTelemetry SDK, you can emit logs via OTLP (gRPC or HTTP) straight to the CodeXray collector. These arrive already structured — severity, attributes, and critically the trace context (trace_id, span_id) are preserved — so every application log line can be pivoted straight to its originating trace.

Both at once is a valid setup

A service can use both sources. Container Logs catch everything the host sees; Application Logs carry rich trace-linked context. In the UI, a Source selector lets investigators toggle between the two views for that service. See Log Sources — Container vs Application for the runtime UX.

Why Pattern Extraction Matters​

Raw logs scale with traffic. If your service doubles, so does your log bill. That's usually fine for debugging, but expensive and noisy at production scale.

The Node Agent solves this by clustering logs on the node itself before shipping them. Instead of sending every "user 42 hit /api/orders", "user 43 hit /api/orders", "user 44 hit /api/orders", it recognises them as one pattern and ships that pattern plus a count.

Benefits:

  • Dramatic cost reduction — log ingest volume drops by orders of magnitude
  • Clearer investigation — during an incident you see the shape of what's happening, not the noise
  • Exact correlation — every raw log carries a pattern.hash attribute that links it back to its cluster, so you can always pivot between one example and all matching logs

You don't have to choose between raw and aggregated views — CodeXray keeps both.

What's in a Log Record​

Every log line CodeXray stores carries:

FieldWhat it tells you
MessageThe log line itself
SeverityInfo / Warning / Error / Unknown
TimestampEvent time
service.nameWhich service produced it
container.id / host.id / host.nameExactly where it came from
pattern.hashThe cluster this log belongs to — used to pivot to similar messages
trace_id / span_id (if emitted)Link to the trace/span that generated the log

Those last two attributes are what make CodeXray's log-to-trace correlation feel seamless: click a log, jump to its trace, or the other way around.

Where Logs Surface in the UI​

Logs have a dedicated Logs tab inside every application view. That's the primary entry point — logs scoped to the service you're investigating, with all the time-range selection, filters, and context you'd expect.

Inside the Logs tab, you can toggle between two views:

  • List View — raw log entries, paginated, searchable. What you reach for when you want to see exactly what happened.
  • Patterns View — clustered patterns with frequency sparklines and % of total volume. What you reach for when you want to understand what's actually going on.

Both views share the same severity filters, time range, and search query.

Flow Diagram​

The Container Logs path does the heavy lifting for infrastructure visibility — the Node Agent discovers logs, extracts patterns on the host, and ships a compact representation to the backend. The Application Logs path bypasses pattern extraction and preserves OTel structure end-to-end. Both land in the same store, and the UI's Source selector decides which one to show at query time.

Next Steps​