Metrics and logs describe different views of a system. A metric is a numeric measurement organized as a time series, such as requests, memory use, or a distribution of request duration. A log is a record of an event, such as a rejected request or a completed job, with context that may explain what happened. Neither signal is inherently better for alerting or investigation: choose the one whose observation boundary, detail, and completeness match the question. OpenTelemetry's signal overview also describes traces: records of an instrumented request's path through a distributed system.
For example, an error-rate metric can show that failures increased across one service. A structured log can identify the affected operation, version, and failure class. A trace, when separately instrumented and available, can show which span in a particular request path failed. You can investigate with one signal, but useful correlation requires stable fields and a clear account of what each signal actually captured.
Metrics, logs, and traces: the data shapes
The important distinction is not “numbers versus text.” Logs may contain numbers, and metrics may carry descriptive attributes. The difference is the record model and the question it can answer.
Metrics measure values over time
A metric stream combines a measurement with identifying attributes and time. The OpenTelemetry Metrics Data Model includes sums, gauges, and histograms:
- A monotonic counter or sum records accumulated events, such as eligible requests or failures. For a rate from cumulative points, calculate the increase over a defined interval and account for resets; do not mistake a cumulative total for the interval's traffic. OpenTelemetry also supports delta and non-monotonic sums, so check the instrument's temporality and meaning before calculating a rate.
- A gauge records a sampled value, such as current queue depth. A missed sample or scrape is not automatically a zero.
- A histogram records a distribution, such as request duration. Its buckets can support threshold-compliance and quantile analysis, but the chosen buckets, aggregation, and observation boundary affect the answer.
Attributes such as service, environment, region, or route let you segment a measurement. They also determine the number of distinct time series. Putting a request ID, user email, or other unbounded value into a metric label can create a new series for each value, increasing storage and query work. Prometheus instrumentation guidance and metric naming guidance recommend thinking deliberately about label cardinality. Metrics are not automatically low-cardinality; their design makes that a choice.
Logs record events with context
A log event can carry an event timestamp, observed timestamp, severity, message or body, resource identity, and attributes. The OpenTelemetry Logs Data Model distinguishes Timestamp, when the event occurred according to its producer, from ObservedTimestamp, when it was observed by the collection system. That distinction matters when clocks drift or delivery is delayed.
Consider a deliberately sanitized example:
{
"timestamp": "2026-09-16T14:02:31Z",
"severity": "ERROR",
"event_name": "checkout_authorization_failed",
"service": "checkout-api",
"environment": "production",
"version": "v42",
"route": "/checkout",
"request_id": "req-7c9f",
"failure_class": "dependency_unavailable"
}
This record is useful because its fields are defined and bounded. It deliberately omits a payment credential, request body, session token, and customer identity. A log is not safe merely because it is structured: OWASP's Logging Cheat Sheet calls for excluding or sanitizing secrets and sensitive data, restricting access, and defending against log injection.
Logs can support both search and alerts. A log alert may be appropriate for a distinctive event or failure class. But a missing event is harder to interpret: no matching row may mean the event did not happen, the producer never emitted it, the collector dropped it, the query missed it, or retention expired. A critical absence check needs an explicit heartbeat or independent monitor with known delivery semantics.
Traces show an instrumented request path
Traces represent spans connected across operations and services. They are useful for locating where an instrumented request spent time or failed, especially across dependencies. They are not a replacement for aggregate service-level measurements or every event record. A request_id in a log is not automatically a trace ID, and a trace ID should be emitted only when actual trace context exists. Trace sampling can leave a valid request without a retained trace. OpenTelemetry's signal definitions keep these boundaries separate.
Choose the signal by the question
The same service may need all three signals, but each operational question has a natural starting point. These are starting points, not rigid ownership rules.
Is the service meeting a user-impact target?
Use measurements defined over the same population of eligible operations. For request error rate, count failed and total eligible requests at the same observation boundary, over the same window. For latency, define which requests qualify and whether the target is a duration threshold or a distribution percentile. A high-level metric or a carefully validated derived series usually makes the trend and denominator visible; retained log events can then explain individual failures.
Suppose the same API edge observes 10,000 eligible requests in an illustrative interval: 17 failed and 9,983 succeeded. The error rate is 17 / 10,000 = 0.17%. That arithmetic is meaningful only if both counts use the same definition of eligible request and there are no missing, duplicated, or sampled observations on one side. A query counting ERROR logs divided by all requests from a separate gateway may silently mix populations. Google's SLO alerting guidance likewise makes the observed traffic and low-traffic behavior central to alert design.
Is a host, process, or queue approaching a limit?
Sampled gauges and rate or histogram series are useful for current saturation, growth, and distributions. A queue-depth metric may reveal a sustained backlog; logs can add the reason a worker stopped making progress. Neither proves that customers were harmed without a user-facing or business-outcome signal. Segment by stable service, environment, and deployment version, but avoid creating a series for each job or request unless there is a deliberate bounded design.
What happened to one request or job?
Start with a log or trace when you have an exact request ID, job ID, or failure marker. A metric aggregated by route cannot reconstruct one event's attributes. In logs, search a bounded time window and the known service and environment before broad text searches. Check the first error in context, the events before it, and the final business outcome. If a trace exists, follow its instrumented spans; then verify the corresponding log rows rather than inferring the entire cause from one span status.
An ERROR level is evidence that a producer classified an event as an error, not proof of user impact. Conversely, a job may exit successfully while producing stale or incomplete data. Treat severity and technical exit status as clues, and validate the outcome that matters.
Is the question about audit or forensics?
An event-level record with actor or system identity, action, result, time, and protected provenance is generally more useful than an aggregate count. But logging a record does not itself prove integrity, authorization, completeness, or regulatory compliance. Define what must be recorded, how access is audited, how long records are retained, how deletion and legal holds work, and how missing records are detected. Keep sensitive fields out where possible, and limit access to what the investigation requires. OWASP's logging guidance covers data exclusion, protection, and disposal.
Has an expected event stopped arriving?
Do not turn “zero matching logs” into a confident health verdict. If the requirement is a completion every interval, emit a success checkpoint or heartbeat and evaluate its freshness in a system that explicitly handles missing data. An external black-box probe can cover failures in the telemetry path itself. During low traffic, a ratio can fluctuate on a tiny denominator or be undefined; define minimum-volume or absolute-count behavior rather than treating missing data as healthy. Logs can corroborate the last known completion, but an ordinary keyword match is not a dead-man switch.
Where metrics and logs overlap
The common shortcut “metrics alert, logs explain” hides important cases. A specific authorization failure log may be the best alert input. A metric broken down by route and release may reveal that only one code path regressed. Metrics can help diagnose; logs can alert.
You can also derive a count or histogram from logs. That does not make the resulting series a native metric emitted by the application. To use a log-derived series for an SLO or a critical alert, verify that the source emits one record for each eligible event, the collector does not drop or duplicate records in ways that change the result, the parsing and timestamp rules are stable, and the denominator is drawn from the same population. Sampling, debug filters, outages, retries, and late arrivals can each distort the calculation. Preserve the distinction between event time and observed time when choosing the window.
Conversely, an application metric can be accompanied by a representative log event when a threshold is crossed. That event may speed investigation, but it will not provide a complete list of all affected requests unless the logging contract explicitly guarantees it.
Neither signal has a universal cost or retention advantage. Metric cardinality, collection interval, histogram buckets, log volume, indexed fields, compression, query patterns, sampling, and retention rules all change the bill and usefulness. Decide based on required questions and measured volume. Keep needed audit and error evidence while reducing noisy records at the source; do not assume that indiscriminate sampling is safe for rare failures.
Correlate without creating a data or privacy problem
Use stable, bounded dimensions common to the relevant sources: service, environment, version or release, route or operation, and a consistent time range. A request or job ID can connect specific log events; it usually should not become a metric label. Optional trace and span IDs can join logs to separately instrumented traces, but only when context exists and propagation crosses trusted boundaries deliberately.
Keep timestamps in a documented format and timezone, and retain both event and observed time when available. Clock skew, buffering, ingestion delay, and retries can make an apparent sequence misleading. Sort by the most appropriate timestamp, inspect nearby events, and do not infer causality from timestamp order alone. Duplicated records and restarted producers can also make a count look larger than the number of real operations.
For logs, allowlist useful context. Avoid passwords, access tokens, cookies, full request or response bodies, payment data, and raw customer identifiers. Sanitize untrusted text to prevent forged lines or delimiter injection. Limit retained data and reader permissions according to its purpose. These controls matter just as much when an AI tool or agent queries records as when a human searches them.
A practical investigation using both signals
Begin at the boundary where the symptom is observed. If a user-facing error-rate or duration series changes, record its service, environment, route, region, release, and time window. Check the denominator and traffic level before treating a ratio as significant. Compare with independent observations, such as an external probe, service outcome, or another telemetry path; a single broken collector can create a false picture.
Next, search the corresponding logs within a bounded time range and the same dimensions. Look for the first divergence from a comparable successful operation, recent deployment markers, and the affected failure class. Open raw rows around the event instead of relying only on a facet count. Follow an instrumented trace if one exists, but verify the claimed failure against logs and actual service behavior.
Sometimes the workflow starts in reverse. A customer reports one request ID or a scheduled job emits a failure event before any aggregate signal moves. Search the exact log record, identify the affected service and version, then ask whether the failure is isolated or visible in a relevant metric. This avoids dismissing a real low-volume incident just because a fleet-wide graph looks flat.
After a change, validate at the original observation boundary: the affected operation succeeds, error and latency behavior return to the expected range, and the relevant log records agree. Do not equate a quiet error log with recovery if the source stopped sending events.
Instrumentation checklist
Start with the service's user-visible operations and the decisions responders must make. For each operation:
- Define the eligible population and event boundary for request count, failure count, and duration. Use stable metric attributes and document units, aggregation, and resets.
- Emit structured, secret-safe events for outcomes that need explanation. Include event time, service, environment, version, operation, stable failure class, and a bounded correlation ID when useful.
- Decide whether tracing is warranted for the distributed path. Propagate only validated context and record trace/span IDs in logs when they are actually present.
- Test missing traffic, collector outage, duplicates, delayed records, clock skew, schema changes, and low-volume behavior. Record how alerts and queries behave under each condition.
- Review volume and cardinality with real measurements. Trim unneeded fields and debug noise without losing evidence needed for investigation, security, or legal obligations.
The OpenTelemetry log model provides a useful vocabulary for timestamps, severity, body, resource, and attributes. The Prometheus naming guidance helps keep metric units and label sets understandable. Neither specification selects your service's user-impact boundary for you.
Where Fluxtail fits
Fluxtail is a paid Starter/Pro, logs-focused service, not a native metrics, tracing, APM, or SLO-computation platform. Once a supported source and collector deliver log records to a named stream, its search and filters, Live Tail, and log alerts can help inspect received events. Field-based searches depend on what the source and receiver actually map. Fluxtail cannot show records that were never emitted, delivered, or retained.
The Stream API exposes retained logs with logs:read and log-count histograms and facets with analytics:read. Its histogram counts stored events in time buckets; it does not create a native application latency histogram from an arbitrary numeric log field or prove that all eligible requests were captured. Built-in AI chat and the hosted MCP server are separate investigation interfaces. MCP access is bound to the authorized account through OAuth/PKCE; use bounded queries, inspect underlying rows, and confirm proposed changes explicitly. An agent's summary is not a substitute for source evidence.
If your metrics identify an affected service and time window, Fluxtail can be the focused log-search surface for that part of the investigation. Keep the metrics or SLO system responsible for its own computations, and use separately instrumented tracing when a request path is the missing evidence. See log management best practices for designing the event pipeline and protecting its data.
The decision in one sentence
Use metrics for defined measurements over time, logs for event-level evidence, and traces for an instrumented request path. Then test the boundaries between them: population, timing, completeness, identity, and permissions. A signal is useful only when those boundaries are clear enough to support the decision you are making.