liveBook · Manning

Signal

As explained in Logs and Telemetry

A signal is an observability event category encompassing logs, metrics, and traces.

A signal is a category of observability data. Logs, metrics, and traces are handled as related event types, allowing one event-driven pipeline to capture and distribute operational information as it arrives. section 3.6.7 section 1.1

The three signal types serve different operational purposes:

  • Logs are application messages or log-file lines describing what happened; they range from unstructured text to structured, self-describing events. section 3.6.7 section 1.1
  • Metrics are labeled measurements, such as CPU use or transactions processed per minute, for resource and business monitoring. section 3.6.7 section 1.1
  • Traces record linked activity at important execution points, often for a transaction. Spans mark significant start and end activities and can nest into a hierarchy; trace baggage can carry transaction metadata. section 3.6.7 section 1.1

Traces become especially useful when an end-to-end process crosses services and servers. Trace identifiers travel through application components, making distributed activity easier to follow; a trace may be retained until a transaction finishes or an error occurs. Logs and metrics were traditionally handled with separate tools, while cloud-native and microservice environments increased the need for traces. section 3.6.7 section 1.1

Listing 3.10 OTel input example: otel-consumer.conf
[SERVICE]
  flush 1
  log_level debug

[INPUT]                 #1
  #use this for Logs
  name opentelemetry
  listen 127.0.0.1
  port 4318

[INPUT]                   #2
  # use this for Traces
  name opentelemetry
  listen 127.0.0.1
  raw_traces true         #3
  port 4317

[INPUT]                 #4
# use this for metrics
  name opentelemetry
  listen 127.0.0.1
  port 4316

[OUTPUT]
  match *
  name stdout

This Fluent Bit configuration creates separate OpenTelemetry inputs for logs, raw traces, and metrics on localhost ports 4318, 4317, and 4316, then sends matched events to standard output. section 3.6.7

Treating these types as signals does not make them interchangeable: logs report messages, metrics provide measurements, and traces preserve relationships across execution. A single capture and distribution tool can nevertheless process all three near real time for monitoring and investigation. section 3.6.7 section 1.1

How Logs and Telemetry covers it

How deep it goes
Defines each signal and explains trace spans, nesting, baggage, and distributed relationships without detailing signal schemas.
Examples
Configures three OpenTelemetry inputs for logs, raw traces, and metrics, routing all matched events to standard output.
What it assumes
Introduces logs, metrics, and traces from zero while assuming interest in monitoring distributed applications.
What you can do after
Operate/configure it through separate OpenTelemetry inputs that receive logs, traces, and metrics on designated ports.
How it connects
Connects signals with OpenTelemetry, Fluent Bit, logs, metrics, traces, spans, Kubernetes, and microservices.

Also explained in

Compare how 10 books explain signal →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Logs and Telemetry. The section links point to the parts of the book it draws on.