Metric stdout exporter to print timestamp in human readable format

[cijothomas]

Addresses #1191 for metrics.

Changes

Update stdout metric exporter to write timestamp in human readable format.
Writes timestamp in human-friendly format as well. The existing unix_ns format is kept as-is.

Example outout with this PR:
"startTime":"2023-08-08 00:02:41.404","time":"2023-08-08 00:02:41.404"

{"resourceMetrics":{"resource":{"attributes":[{"key":"service.name","value":{"stringValue":"metrics-basic-example"}}]},"scopeMetrics":[{"scope":{"name":"mylibraryname"},"metrics":[{"name":"my_counter","sum":{"dataPoints":[{"attributes":{"mykey1":{"stringValue":"myvalue1"},"mykey2":{"stringValue":"myvalue2"}},"startTime":"2023-08-08 00:02:41.404","time":"2023-08-08 00:02:41.404","value":10}],"aggregationTemporality":2,"isMonotonic":true}},{"name":"my_observable_counter","description":"My observable counter example description","unit":"myunit","sum":{"dataPoints":[{"attributes":{"mykey1":{"stringValue":"myvalue1"},"mykey2":{"stringValue":"myvalue2"}},"startTime":"2023-08-08 00:02:41.404","time":"2023-08-08 00:02:41.404","value":100}],"aggregationTemporality":2,"isMonotonic":true}},{"name":"my_updown_counter","sum":{"dataPoints":[{"attributes":{"mykey1":{"stringValue":"myvalue1"},"mykey2":{"stringValue":"myvalue2"}},"startTime":"2023-08-08 00:02:41.404","time":"2023-08-08 00:02:41.404","value":-10}],"aggregationTemporality":2,"isMonotonic":false}},{"name":"my_observable_updown_counter","description":"My observable updown counter example description","unit":"myunit","sum":{"dataPoints":[{"attributes":{"mykey1":{"stringValue":"myvalue1"},"mykey2":{"stringValue":"myvalue2"}},"startTime":"2023-08-08 00:02:41.404","time":"2023-08-08 00:02:41.404","value":100}],"aggregationTemporality":2,"isMonotonic":false}},{"name":"my_histogram","description":"My histogram example description","histogram":{"dataPoints":[{"attributes":{"mykey1":{"stringValue":"myvalue1"},"mykey2":{"stringValue":"myvalue2"}},"startTime":"2023-08-08 00:02:41.404","time":"2023-08-08 00:02:41.404","count":1,"explicitBounds":[0.0,5.0,10.0,25.0,50.0,75.0,100.0,250.0,500.0,750.0,1000.0,2500.0,5000.0,7500.0,10000.0],"bucketCounts":[0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0],"min":10.5,"max":10.5,"sum":10.5,"exemplars":[],"flags":0}],"aggregationTemporality":2}},{"name":"my_gauge","description":"A gauge set to 1.0","unit":"myunit","gauge":{"dataPoints":[{"attributes":{"mykey1":{"stringValue":"myvalue1"},"mykey2":{"stringValue":"myvalue2"}},"startTime":null,"time":"2023-08-08 00:02:41.404","value":1.0}]}}]}]}}

before this PR:
"startTimeUnixNano":1691453709811505677,"timeUnixNano":1691453709811786077

{"resourceMetrics":{"resource":{"attributes":[{"key":"service.name","value":{"stringValue":"metrics-basic-example"}}]},"scopeMetrics":[{"scope":{"name":"mylibraryname"},"metrics":[{"name":"my_counter","sum":{"dataPoints":[{"attributes":{"mykey1":{"stringValue":"myvalue1"},"mykey2":{"stringValue":"myvalue2"}},"startTimeUnixNano":1691453709811505677,"timeUnixNano":1691453709811786077,"value":10}],"aggregationTemporality":2,"isMonotonic":true}},{"name":"my_observable_counter","description":"My observable counter example description","unit":"myunit","sum":{"dataPoints":[{"attributes":{"mykey1":{"stringValue":"myvalue1"},"mykey2":{"stringValue":"myvalue2"}},"startTimeUnixNano":1691453709811553801,"timeUnixNano":1691453709811792600,"value":100}],"aggregationTemporality":2,"isMonotonic":true}},{"name":"my_updown_counter","sum":{"dataPoints":[{"attributes":{"mykey1":{"stringValue":"myvalue1"},"mykey2":{"stringValue":"myvalue2"}},"startTimeUnixNano":1691453709811602840,"timeUnixNano":1691453709811796162,"value":-10}],"aggregationTemporality":2,"isMonotonic":false}},{"name":"my_observable_updown_counter","description":"My observable updown counter example description","unit":"myunit","sum":{"dataPoints":[{"attributes":{"mykey1":{"stringValue":"myvalue1"},"mykey2":{"stringValue":"myvalue2"}},"startTimeUnixNano":1691453709811621802,"timeUnixNano":1691453709811798675,"value":100}],"aggregationTemporality":2,"isMonotonic":false}},{"name":"my_histogram","description":"My histogram example description","histogram":{"dataPoints":[{"attributes":{"mykey1":{"stringValue":"myvalue1"},"mykey2":{"stringValue":"myvalue2"}},"startTimeUnixNano":1691453709811643797,"timeUnixNano":1691453709811801235,"count":1,"explicitBounds":[0.0,5.0,10.0,25.0,50.0,75.0,100.0,250.0,500.0,750.0,1000.0,2500.0,5000.0,7500.0,10000.0],"bucketCounts":[0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0],"min":10.5,"max":10.5,"sum":10.5,"exemplars":[],"flags":0}],"aggregationTemporality":2}},{"name":"my_gauge","description":"A gauge set to 1.0","unit":"myunit","gauge":{"dataPoints":[{"attributes":{"mykey1":{"stringValue":"myvalue1"},"mykey2":{"stringValue":"myvalue2"}},"startTimeUnixNano":null,"timeUnixNano":1691453709811778357,"value":1.0}]}}]}]}}

Merge requirement checklist

• CONTRIBUTING guidelines followed
• Unit tests added/updated (if applicable)
• Appropriate CHANGELOG.md files updated for non-trivial, user-facing changes
• Changes in public API reviewed (if applicable)

[codecov]

Codecov Report

Patch coverage: 23.4% and no project coverage change.

Comparison is base (7607ad3) 49.6% compared to head (1472f58) 49.7%.
Report is 5 commits behind head on main.

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #1192   +/-   ##
=====================================
  Coverage   49.6%   49.7%           
=====================================
  Files        164     172    +8     
  Lines      20653   20713   +60     
=====================================
+ Hits       10258   10304   +46     
- Misses     10395   10409   +14     

Files Changed	Coverage Δ
opentelemetry-otlp/src/exporter/grpcio/logs.rs	0.0% <0.0%> (ø)
opentelemetry-otlp/src/exporter/grpcio/mod.rs	35.4% <0.0%> (ø)
opentelemetry-otlp/src/exporter/grpcio/trace.rs	0.0% <0.0%> (ø)
opentelemetry-otlp/src/exporter/http/logs.rs	0.0% <0.0%> (ø)
opentelemetry-otlp/src/exporter/http/metrics.rs	0.0% <0.0%> (ø)
opentelemetry-otlp/src/exporter/http/mod.rs	0.0% <0.0%> (ø)
opentelemetry-otlp/src/exporter/http/trace.rs	0.0% <0.0%> (ø)
opentelemetry-otlp/src/exporter/tonic/logs.rs	0.0% <0.0%> (ø)
opentelemetry-otlp/src/exporter/tonic/metrics.rs	0.0% <0.0%> (ø)
opentelemetry-otlp/src/lib.rs	32.2% <ø> (ø)
... and 12 more

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

[jtescher]

Hm maybe this should be based on features? the convenient thing about the current output is it matches the file-exporter, and otlp protobuf json encodings so the common case json format is what you may expect.

[cijothomas]

Hm maybe this should be based on features? the convenient thing about the current output is it matches the file-exporter, and otlp protobuf json encodings so the common case json format is what you may expect.

The file exporter and the json/protobuf are intended for machine consumption, so it makes sense for them to follow the specified format. The stdout exporter is purely for users to learn/debug OpenTelemetry, and not meant for production use. This stdout exporter is more like the "log" exporter in OTel Collector: https://github.com/open-telemetry/opentelemetry-collector/blob/main/exporter/loggingexporter/internal/otlptext/traces.go#L42

I will propose the following:

1. Make it clear that stdout is intended only for educational purposes, and there is no guarantee that the output format will remain same overtime. (Also emit a warning note in the stdout exporter so folks will see it, as suggested during SIG call on 8/8/23).
2. Make a OTLP Exporter (new one, or enhance existing ones), which can send data to file or stdout, following the linked specs. This may be used in Production and the output shape follows the spec and is predictable.

Thoughts on above?

[lalitb]

+ 1 for documenting the purpose of stdout clearly.

Another thought would be, as stdout exporter is purely for users to learn/debug OpenTelemetry, and not meant for production use - it allows us to extend it for better debugging. So we can also keep the exiting epoch representation, and add new field for human readable format. Sometime, for debugging purpose, customers may want to configure both stdout, and production exporter and compare the contents to validate the production exporter export values. Or else, keeping it on feature based as @jtescher suggested also works.

[jtescher]

Yeah agree that it's about debugging (mostly local) and not production. What I've seen people use it for most is debugging other exports or other integration issues, in which case I think it's mostly around having a second exporter to compare what you expect to see, in which case a json format for what you'd most expect the data to look like for machines and a human readable version like what go has which is more multi-line log oriented and likely not json at all both make sense to me.

[cijothomas]

Thanks for the feedbacks. I do see some value in keeping the unix_nano format.
I will modify the PR so that ts is emitted in both machine and human-friendly formats. I think that'll be a good balance for now.

[cijothomas]

@jtescher modified the PR to keep the existing format, and added user-friendly time as an additional field. Could you review/merge?

[jtescher]

Looks good thanks @cijothomas