These were only used by the memory limiter processor and were never
automatically calculated by the processorhelper. It's better to move
them to processor specific metrics that can be managed within the
component itself.
---------
Signed-off-by: Alex Boten <223565+codeboten@users.noreply.github.com>
This updating the existing metric points that were recently added to use
signal as an attribute instead of separating the metric name. It follows
the suggestions in [otep
259](https://github.com/open-telemetry/oteps/pull/259) for the metric
and attribute names.
Putting this in draft to get some feedback from @djaglowski before
moving forward with this change
---------
Signed-off-by: Alex Boten <223565+codeboten@users.noreply.github.com>
`[Logs|Traces|Metrics]Inserted` was not used in the core/contrib repos,
marking them as deprecated.
---------
Signed-off-by: Alex Boten <223565+codeboten@users.noreply.github.com>
This is replaced by a LeveledMeterProvider method on the struct instead.
This
reduces the complexity from the view of component authors, in that
there's no need
to check the level before invoking the meter to record a metric.
Closes
https://github.com/open-telemetry/opentelemetry-collector/issues/9510
---------
Signed-off-by: Alex Boten <223565+codeboten@users.noreply.github.com>
Co-authored-by: Tyler Helmuth <12352919+TylerHelmuth@users.noreply.github.com>
This PR removes the `recordData` method, which I believe is an unhelpful
abstraction for reporting internal processor metrics.
The drawbacks of the function are minor, but briefly:
1. Recording any metric requires passing in zeros for _all other
metrics_. This is cumbersome to extend because any new metric requires
updating the call to `recordData` for all metrics. It's also fragile
because if we have more than a few metrics it is easy to position the
intended metric incorrectly.
2. Every metric describes one data type, which is passed into
`recordData` but then just used as a switch to get back to code that is
specific to that data type.
3. Every call to `recordData` instantiates N variables, where N is the
number of metrics for each data type.
All of this seems unnecessary as we can just report each metric in one
unambiguous line of code.
#### Link to tracking issue
Resolves#10353
#### Testing
Added equivalent testing to other processor metrics (accepted, refused,
dropped).
#### Documentation
Metric documentation is autogenerated.
#### Open Question
My initial implementation includes a breaking change to
`componenttest.TestTelemetry` which is public facing API. If we want to
avoid an immediate breaking change in this test package, I would propose
the following, which I can submit in a prerequisite PR:
1. Deprecate all `TestTelemetry.Check*` methods.
2. Replace with more granular `TestTelemetry.CheckOneSpecificMetric`
methods.
This deprecates CreateSettings in favour of Settings.
NewNopCreateSettings is also being deprecated in favour of
NewNopSettings
Part of #9428
---------
Signed-off-by: Alex Boten <223565+codeboten@users.noreply.github.com>
This cleans up the need to have a level in the ObsReport struct. Added
test to validate the change as none existed before
---------
Signed-off-by: Alex Boten <223565+codeboten@users.noreply.github.com>
This updates the processor helper to use mdatagen for its internal
telemetry.
---------
Signed-off-by: Alex Boten <223565+codeboten@users.noreply.github.com>
This is addressing an issue w/ the names of the metrics generated by the
Collector for its internal metrics. Note that this change only impacts
users that emit telemetry using OTLP, which is currently still in
experimental support. The prometheus metrics already replaced `/` with
`_`.
Fixes#9774
---------
Signed-off-by: Alex Boten <223565+codeboten@users.noreply.github.com>
These deprecated methods/structs have been moved to processorhelper:
- `obsreport.BuildProcessorCustomMetricName` ->
`processorhelper.BuildCustomMetricName`
- `obsreport.Processor` -> `processorhelper.ObsReport`
- `obsreport.ProcessorSettings` -> `processorhelper.ObsReportSettings`
- `obsreport.NewProcessor` -> `processorhelper.NewObsReport`
Same as the change for the exporter, no functional changes just moving
code over to the
new location.
~Follows
https://github.com/open-telemetry/opentelemetry-collector/pull/8493~
---------
Signed-off-by: Alex Boten <aboten@lightstep.com>
Bogdan Drutu
VihasMakwana
Tyler Helmuth
Alex Boten
Daniel Jaglowski
Dmitrii Anoshin
Alex Boten