Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add PeriodicExporterOptions for console exporter #2648

Merged

Conversation

reese-lee
Copy link
Member

@reese-lee reese-lee commented Nov 20, 2021

Fixes #2575.

  • Proposes MetricReaderExportType as a means to allow users to configure periodic vs non-periodic metric readers.
  • Adds PeriodicExporterOptions similar to the BatchExporterOptions for tracing.
  • Applies these things to the ConsoleExporter. If we like this approach, then we can apply this to the OTLP exporter as well.

TODO:

  • Document all public API
  • Update CHANGELOG

@reese-lee reese-lee requested a review from a team November 20, 2021 01:31
@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Nov 20, 2021

CLA Signed

The committers are authorized under a signed CLA.

// limitations under the License.
// </copyright>

public class PeriodicExporterOptions
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might be misleading, it is actual options for reader, not exporter?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed the name is not quite right here. It was in part inspired by this section of the spec titled Periodic exporting MetricReader.

Few ideas:

  1. Rename to PeriodicExportingMetricReaderOptions
  2. Rename to PeriodicMetricReaderOptions
  3. Do away with the options class and just keep the interval as a top-level property of the console options.

I think I like one of the rename options because the class kind of mimics what we have in tracing plus we should probably expand these options in the future with ExportTimeoutMilliseconds.

Do folks like any of these options?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For now, we opted to rename PeriodExporterOptions to PeriodicExportingMetricReaderOptions.

{
public enum MetricReaderExportType
{
Simple,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure if I can suggest a better name, but simple doesn't convey the behavior...(For tracing, we could use Simple, as spec defined it).
Manual? Basic?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, I'm not a fan of Simple here either. I think Manual conveys behavior best.

I was tempted to consider the terms Push vs. Pull, but those are terms that primarily describe metric exporters not metric readers... if this is true, then I say let's go with Manual.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Renamed Simple to Manual.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know if Manual is a good name, there are cases (e.g. during dispose) it flushes automatically. My gut feeling is Basic > Simple > Manual. Not a blocking comment though, as I'm always struggling and bad at naming 🤷‍♂️

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know if Manual is a good name, there are cases (e.g. during dispose) it flushes automatically

Well..the dispose is a manual action, as user has to explicitly call it (.Dispose, or use using statement/block to let c# do it)

I'll merge to unblock progress, and will do a quick vote in todays SIG meeting:

  1. Any alternate name
  2. Or pick among the existing Basic, Simple, Manual

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OnDemand?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about AdHoc?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Disordered 🤣

/// Gets or sets the metric export interval in milliseconds. The default value is <c>Timeout.Infinite</c>.
/// </summary>
public int MetricExportIntervalMilliseconds { get; set; } = Timeout.Infinite;
public MetricReaderExportType MetricReaderExportType { get; set; } = MetricReaderExportType.Simple;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@reyang @alanwest Can you share your thoughts on making the default as Periodic?
One thing I have observed is, users are used to seeing traces/logs from ConsoleExporter, by just doing AddConsoleExporter. However, for Metrics, it won't work. There is nothing in the spec which says ConsoleExporter should be paired with a periodic exporting reader, but I think it makes sense to pair it with PeriodicExportingReader by default, to have similar experience as traces/logs.

This example: https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/examples/AspNetCore/Startup.cs#L137, won't work as is, and most folks will be puzzled as to why Metrics are not showing up....

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do agree that it makes sense for the console exporter to default to periodic. I think the general expectation is that info piped to stdout is emitted automatically vs invoking a collect or flush.

Also, my understanding is the console exporter is primarily useful in testing/troubleshooting scenarios. I think this is especially true for metrics, so seeing a quick validation things are alive and working with the single line AddConsoleExporter() is a plus.

That said, I think when we take on the work to support additional output formats, I think the usefulness of the console exporter may expand beyond testing scenarios. In those cases I think folks will be fine configuring the exporter how they need it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the challenges are:

  1. What should be the default exporting period - I think we don't know at this moment.
  2. What is the behavior during exit.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we borrow that we do for OTLP Metric exporter?
Same default export interval as OTLP.

The behavior during exit - not sure I follow the specifics here. We do the usual shutdown/dispose right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we borrow that we do for OTLP Metric exporter? Same default export interval as OTLP.

You could. The question is why do you think Console and OTLP should have the same default interval?

I think there should be a concrete usage scenario and we need to think about the design. For example, if the expectation is to use it for interactive output, the refresh rate should be <= 0.3s (based on the common study from interactive UI, and that's the reason why in the Stress test I picked 0.2s delay for each refresh).

There are many issues with the current Console exporter. For example if there are both trace and metrics exporter, and folks would want to see Exemplar which connects traces and metrics, the output will be mixed up because the lack of synchronization on the outputs.

My gut feeling is that by making it outputs periodically without understanding the usage scenario and without a good design, is probably going to make the current situation worse.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I defer to @reyang's judgment on not yet understanding the usage scenario. I've definitely not thought deep about either interactivity nor metric's relationship to tracing.

That said, if we continue to default to non-periodic, perhaps we update the ASP.NET Core example to use periodic to help guide folks?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That said, if we continue to default to non-periodic, perhaps we update the ASP.NET Core example to use periodic to help guide folks?

Either we use periodic console exporter (and gather feedback about the default interval), or use Prometheus exporter. (the current console metrics exporter has a bug that it only outputs to stdout rather than leveraging the abstraction here)

Copy link
Member

@reyang reyang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@codecov
Copy link

codecov bot commented Nov 23, 2021

Codecov Report

Merging #2648 (7502e65) into main (bc0e8af) will decrease coverage by 0.00%.
The diff coverage is 0.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #2648      +/-   ##
==========================================
- Coverage   82.25%   82.24%   -0.01%     
==========================================
  Files         247      248       +1     
  Lines        8691     8692       +1     
==========================================
  Hits         7149     7149              
- Misses       1542     1543       +1     
Impacted Files Coverage Δ
...ry/Metrics/PeriodicExportingMetricReaderOptions.cs 0.00% <0.00%> (ø)

@cijothomas cijothomas merged commit cb4beda into open-telemetry:main Nov 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Is TimeSpan.Infinite the best default aggregation default for console exporter?
6 participants