ESP log exporters for all signals #122

Parent

#15

What to build

The ESP log exporter for all four signals, as specified in the parent issue. An engineer enables one Kconfig option, passes a MakeEspLog*Exporter() factory to the existing setup call, and sees every span, log record, metric data point and profile as an ordinary ESP-IDF log line, filtered by tag and level like any other component's output. The traces, logs, metrics and profiles examples switch to it and show it working in QEMU.

The parent spec's "Implementation Decisions" and "Testing Decisions" sections are the reference for format, tags, levels, filtering and lifecycle.

If this does not fit one session, split it at a signal boundary: traces and profiles first (shared formatting, Kconfig option, header), then log records and metrics.

Acceptance criteria

Configuration and API

• ESP_OPENTELEMETRY_EXPORTER_ESP_LOG is in "Exporters to compile in", default n.
• MakeEspLogSpanExporter(), MakeEspLogLogRecordExporter() and MakeEspLogMetricExporter() exist only when their signal is enabled; MakeEspLogProfilesExporter() is not gated on a signal.
• The public header exposes only the factories. Its comment points to the logs setup header and the ESP log bridge header, and documents that bridged lines print twice when both are enabled.

Output

• One ESP_LOGx line per item. Labels, fields, order and value formatting mirror the SDK's Ostream exporter, including resource and instrumentation scope on every item, written as label: value joined by , with nested attributes in braces.
• Each span event and each span link prints on its own line carrying the span's span_id.
• Metrics print one line per data point, repeating instrument fields, resource and scope; sum, histogram and last-value points all render.
• Profiles print the raw JSON document on one line with no begin/end markers.
• Lines are never truncated.

Tags, levels, filtering

• Tags: otel.span, otel.log, otel.metric, otel.profile.
• Spans print at INFO, or WARN when status is Error. Metric data points and profiles print at INFO. Log records map TRACE→V, DEBUG→D, INFO→I, WARN→W, ERROR/FATAL→E.
• An item that esp_log would not print, whether filtered at compile time or runtime, is skipped before formatting, and Export() still reports success.
• A log record with a log.tag attribute is also skipped when that tag's runtime level would hide it; a record without log.tag is filtered by otel.log alone.

Lifecycle

• ForceFlush() returns true immediately; after Shutdown(), Export() returns failure and prints nothing.

Examples and tests (fixed-string matches in each example's QEMU test)

• traces: switched to the ESP log exporter; adds a span event and an Error-status span. The test checks an otel.span INFO line with the example's service.name, an event line with the same span_id, and the Error span at WARN.
• logs: switched; adds a DEBUG record and a bridged ESP_LOGx under a tag whose runtime level hides it. The test checks the INFO record's otel.log line and the absence of both filtered records.
• metrics: switched; the test checks an otel.metric INFO line containing iterations.
• profiles: switched; the test checks an otel.profile INFO line.
• All CI jobs pass.

Docs

• README exporter table lists the ESP log exporter.
• README tested-features table has "Tested (QEMU)" rows for the ESP log exporters, and marks OStreamSpanExporter, OStreamMetricExporter and OStreamLogRecordExporter "Not tested".
• Example READMEs describe the ESP log exporter instead of the Ostream exporters.

Blocked by

• Move JTAG exporters to factory functions and rename console to ostream #121