[exporter/debug] make normal verbosity output one line per telemetry item

[andrzej-stencel]

🚧 WORK IS IN PROGRESS 🚧

Description:

The Debug exporter's behavior of normal verbosity used to be the same as for basic verbosity, which is to output only one line of text for each telemetry batch.

This changes the behavior of normal verbosity to output one line of text for each telemetry item - log record, metric data point, or span. This is a good middle ground between basic (one line per telemetry batch) and detailed (multiple lines per telemetry item).

Note that this change only applies to the Debug exporter; the deprecated Logging exporter keeps old behavior.

I've marked this change as breaking, but I'm not sure if we want to consider changes in Debug exporter's format as breaking changes?

While this PR is in progress, any suggestions on the formatting are welcome. Especially for spans, which I don't have a lot of experience with.

Here's the current output for logs:

2024-01-17T10:26:16.206+0100    info    LogsExporter    {"kind": "exporter", "data_type": "logs", "name": "debug", "resource logs": 1, "log records": 4}
2024-01-17T10:26:16.206+0100    info    2023-12-26 07:01:00 [INFO] Wednesday is the first day of work log.file.name=logs.log
2023-12-27 07:02:00 [INFO] this week log.file.name=logs.log
2023-12-28 08:03:00 [INFO] Thursday on the other hand log.file.name=logs.log
2023-12-29 08:04:00 [INFO] is the hump day this week log.file.name=logs.log
        {"kind": "exporter", "data_type": "logs", "name": "debug"}
2024-01-17T10:26:16.907+0100    info    MetricsExporter {"kind": "exporter", "data_type": "metrics", "name": "debug", "resource metrics": 1, "metrics": 1, "data points": 6}
2024-01-17T10:26:16.907+0100    info    system.memory.usage{host.name=astencel-dell,os.type=linux,state=used} 8133419008
system.memory.usage{host.name=astencel-dell,os.type=linux,state=free} 35915481088
system.memory.usage{host.name=astencel-dell,os.type=linux,state=buffered} 3183996928
system.memory.usage{host.name=astencel-dell,os.type=linux,state=cached} 19891683328
system.memory.usage{host.name=astencel-dell,os.type=linux,state=slab_reclaimable} 1632342016
system.memory.usage{host.name=astencel-dell,os.type=linux,state=slab_unreclaimable} 395616256
        {"kind": "exporter", "data_type": "metrics", "name": "debug"}
2024-01-17T10:26:19.063+0100    info    TracesExporter  {"kind": "exporter", "data_type": "traces", "name": "debug", "resource spans": 1, "spans": 2}
2024-01-17T10:26:19.063+0100    info    okey-dokey 018cc8084d9dc027631383b2339d0c6f d0e10c82f11db9bb
lets-go 018cc8084d9dc027631383b2339d0c6f b68f1c079383a98b
        {"kind": "exporter", "data_type": "traces", "name": "debug"}

Notes:

I don't love the fact that each output from the Debug exporter is prefixed with the timestamp and info level string, and suffixed by some more text like {"kind": "exporter", "data_type": "logs", "name": "debug"}. This makes the output inconsistent.

I also believe the Debug exporter should send its output to stdout by default and not to stderr where all collector logs are sent. I believe Debug exporter's output is functionally different from collector logs and belongs to stdout, as this is what the user expects to see as the collector's output, having configured the Debug exporter.

Link to tracking Issue:

• [exporter/debug] change behavior of "normal" verbosity to be different from "basic" #7806

Testing:

TODO add tests specifying the behavior

Documentation:

TODO update Debug exporter's README to describe the format

Next steps:

(As a future separate PR) I believe it would be beneficial for users to be able to configure the output format - for example:

• output.attributes whether or not to include records' attributes. They're probably essential for metrics, but for logs - it depends on the nature of the logs. For some users, attributes may be essential; for others, they only obscure the output.
• output.trace_id, output.span_id whether or not to include trace ID, span ID - probably essential for traces, but not necessarily for logs.
• output.timestamp whether or not to include timestamp - again some users might find them useful, others might want to remove them for clarity
• etc.

[codecov]

Codecov Report

Attention: Patch coverage is 75.00000% with 50 lines in your changes are missing coverage. Please review.

Project coverage is 90.69%. Comparing base (c6d1482) to head (7ccbfe7).
Report is 1 commits behind head on main.

❗ Current head 7ccbfe7 differs from pull request most recent head c726577. Consider uploading reports for the commit c726577 to get more accurate results

Files	Patch %	Lines
exporter/debugexporter/exporter.go	23.80%	46 Missing and 2 partials ⚠️
exporter/debugexporter/internal/normal/metrics.go	97.22%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9298      +/-   ##
==========================================
- Coverage   91.31%   90.69%   -0.62%     
==========================================
  Files         357      351       -6     
  Lines       19202    18509     -693     
==========================================
- Hits        17534    16787     -747     
- Misses       1340     1394      +54     
  Partials      328      328              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 14 days.