Documentation ¶
Overview ¶
Package obsreport provides unified and consistent observability signals ( metrics, tracing, etc) for components of the OpenTelemetry collector.
The function Configure is used to control which signals are going to be generated. It provides functions for the typical operations of receivers, processors, and exporters.
Receivers should use the respective start and end according to the data type being received, ie.:
Traces receive operations should use the pair: StartTracesOp/EndTracesOp
Metrics receive operations should use the pair: StartMetricsOp/EndMetricsOp
Logs receive operations should use the pair: StartLogsOp/EndLogsOp
Similar for exporters:
Traces export operations should use the pair: StartTracesOp/EndTracesOp
Metrics export operations should use the pair: StartMetricsOp/EndMetricsOp
Metrics export operations should use the pair: StartLogsOp/EndLogsOp
The package is capable of generating legacy metrics by using the observability package allowing a controlled transition from legacy to the new metrics. The goal is to eventually remove the legacy metrics and use only the new metrics.
The main differences regarding the legacy metrics are:
1. "Amount of metric data" is measured as metric points (ie.: a single value in time), contrast it with number of time series used legacy. Number of metric data points is a more general concept regarding various metric formats.
2. Exporters measure the number of items, ie.: number of spans or metric points, that were sent and the ones for which the attempt to send failed. For more information about this see Notes below about reporting data loss.
3. All measurements of "amount of data" used in the new metrics for receivers and exporters should reflect their native formats, not the internal format used in the Collector. This is to facilitate reconciliation between Collector, client and backend. For instance: certain metric formats do not provide direct support for histograms and have predefined conventions to represent those, this conversion may end with a different number of time series and data points than the internal Collector format.
Notes:
* Data loss should be recorded only when the component itself remove the data from the pipeline. Legacy metrics for receivers used "dropped" in their names but these could be non-zero under normal operations and reflected no actual data loss when exporters with "sending_queue" are used. New metrics were renamed to avoid this misunderstanding. Here are the general recommendations to report data loss:
Receivers reporting errors to clients typically result in the client re-sending the same data so it is more correct to report "receive errors", not actual data loss.
Exporters need to report individual failures to send data, but on typical production pipelines processors usually take care of retries, so these should be reported as "send errors".
Data "filtered out" should have its own metrics and not be confused with dropped data.
Naming Convention for New Metrics ¶
Common Metrics: Metrics shared by different components should follow the convention below:
`<component>/<metric_name>`
As a label the metric should have at least `{<component>="<name>"}` where `<name>` is the name used in the configuration for the instance of the component, eg.:
`receiver/accepted_spans{receiver="otlp",...}` `exporter/sent_spans{exporter="otlp/prod",...}`
Component Specific Metrics: These metrics are implemented by specific components, eg.: batch processor. The general pattern is the same as the common metrics but with the addition of the component type (as it appears in the configuration) before the actual metric:
`<component>/<type>/<metric_name>`
Even metrics exclusive to a single type should follow the conventions above and also include the type (as written in the configuration) as part of the metric name since there could be multiple instances of the same type in different pipelines, eg.:
`processor/batch/batch_size_trigger_send{processor="batch/dev",...}`
Index ¶
- func BuildProcessorCustomMetricName(configType, metric string) stringdeprecated
- func NewExporter(cfg ExporterSettings) (*exporterhelper.ObsReport, error)deprecated
- type Exporterdeprecated
- type ExporterSettingsdeprecated
- type Processordeprecated
- type ProcessorSettingsdeprecated
- type Receiverdeprecated
- type ReceiverSettingsdeprecated
- type Scraperdeprecated
- type ScraperSettingsdeprecated
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func BuildProcessorCustomMetricName
deprecated
BuildProcessorCustomMetricName is used to be build a metric name following the standards used in the Collector. The configType should be the same value used to identify the type on the config.
Deprecated: [0.86.0] Use processorhelper.BuildCustomMetricName instead.
func NewExporter
deprecated
added in
v0.23.0
func NewExporter(cfg ExporterSettings) (*exporterhelper.ObsReport, error)
NewExporter creates a new Exporter.
Deprecated: [0.86.0] Use exporterhelper.New instead.
Types ¶
type Exporter
deprecated
added in
v0.23.0
type Exporter = exporterhelper.ObsReport
Exporter is a helper to add observability to an exporter.
Deprecated: [0.86.0] Use exporterhelper.ObsReport instead.
type ExporterSettings
deprecated
added in
v0.24.0
type ExporterSettings = exporterhelper.ObsReportSettings
ExporterSettings are settings for creating an Exporter.
Deprecated: [0.86.0] Use exporterhelper.ObsReportSettings instead.
type Processor
deprecated
added in
v0.23.0
type Processor = processorhelper.ObsReport
Processor is a helper to add observability to a processor.
Deprecated: [0.86.0] Use processorhelper.ObsReport instead.
func NewProcessor
deprecated
added in
v0.23.0
func NewProcessor(cfg ProcessorSettings) (*Processor, error)
NewProcessor creates a new Processor.
Deprecated: [0.86.0] Use processorhelper.NewObsReport instead.
type ProcessorSettings
deprecated
added in
v0.23.0
type ProcessorSettings = processorhelper.ObsReportSettings
ProcessorSettings is a helper to add observability to a processor.
Deprecated: [0.86.0] Use processorhelper.ObsReportSettings instead.
type Receiver
deprecated
added in
v0.28.0
type Receiver = receiverhelper.ObsReport
Receiver is a helper to add observability to a receiver.
Deprecated: [0.86.0] Use receiverhelper.ObsReport instead.
func NewReceiver
deprecated
added in
v0.28.0
func NewReceiver(cfg ReceiverSettings) (*Receiver, error)
NewReceiver creates a new Receiver.
Deprecated: [0.86.0] Use receiverhelper.NewObsReport instead.
type ReceiverSettings
deprecated
added in
v0.28.0
type ReceiverSettings = receiverhelper.ObsReportSettings
ReceiverSettings are settings for creating an Receiver.
Deprecated: [0.86.0] Use receiverhelper.ObsReportSettings instead.
type Scraper
deprecated
added in
v0.29.0
type Scraper = scraperhelper.ObsReport
Scraper is a helper to add observability to a scraper.
Deprecated: [0.86.0] Use scraperhelper.ObsReport instead.
func NewScraper
deprecated
added in
v0.29.0
func NewScraper(cfg ScraperSettings) (*Scraper, error)
NewScraper creates a new Scraper.
Deprecated: [0.86.0] Use scraperhelper.NewObsReport instead.
type ScraperSettings
deprecated
added in
v0.29.0
type ScraperSettings = scraperhelper.ObsReportSettings
ScraperSettings are settings for creating a Scraper.
Deprecated: [0.86.0] Use scraperhelper.ObsReportSettings instead.