-
Notifications
You must be signed in to change notification settings - Fork 773
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
Add PeriodicExporterOptions for console exporter #2648
Conversation
|
// limitations under the License. | ||
// </copyright> | ||
|
||
public class PeriodicExporterOptions |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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:
- Rename to
PeriodicExportingMetricReaderOptions
- Rename to
PeriodicMetricReaderOptions
- 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?
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Renamed Simple
to Manual
.
There was a problem hiding this comment.
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 🤷♂️
There was a problem hiding this comment.
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:
- Any alternate name
- Or pick among the existing Basic, Simple, Manual
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OnDemand?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about AdHoc?
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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....
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
- What should be the default exporting period - I think we don't know at this moment.
- What is the behavior during exit.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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)
…e-lee/opentelemetry-dotnet into reese-lee/periodic-exporter-options
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
Codecov Report
@@ 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
|
Fixes #2575.
MetricReaderExportType
as a means to allow users to configure periodic vs non-periodic metric readers.PeriodicExporterOptions
similar to theBatchExporterOptions
for tracing.ConsoleExporter
. If we like this approach, then we can apply this to the OTLP exporter as well.TODO: