From d32af528c6ed356a8d03b7bfd68a4c5220560484 Mon Sep 17 00:00:00 2001 From: Dmitry Anoshin Date: Thu, 7 Mar 2024 14:44:13 -0800 Subject: [PATCH] Remove deprecated obsreport/obsreporttest package --- .chloggen/remove-obsreport.yaml | 20 +++++ obsreport/doc.go | 105 ------------------------ obsreport/obsreporttest/deprecated.go | 29 ------- obsreport/obsreporttest/package_test.go | 14 ---- 4 files changed, 20 insertions(+), 148 deletions(-) create mode 100755 .chloggen/remove-obsreport.yaml delete mode 100644 obsreport/doc.go delete mode 100644 obsreport/obsreporttest/deprecated.go delete mode 100644 obsreport/obsreporttest/package_test.go diff --git a/.chloggen/remove-obsreport.yaml b/.chloggen/remove-obsreport.yaml new file mode 100755 index 00000000000..6be1a2dbbf5 --- /dev/null +++ b/.chloggen/remove-obsreport.yaml @@ -0,0 +1,20 @@ +# Use this changelog template to create an entry for release notes. + +# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix' +change_type: breaking + +# The name of the component, or a single word describing the area of concern, (e.g. otlpreceiver) +component: obsreport + +# A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`). +note: Remove deprecated obsreport/obsreporttest package. + +# One or more tracking issues or pull requests related to the change +issues: [9724] + +# Optional: The change log or logs in which this entry should be included. +# e.g. '[user]' or '[user, api]' +# Include 'user' if the change is relevant to end users. +# Include 'api' if there is a change to a library API. +# Default: '[user]' +change_logs: [api] diff --git a/obsreport/doc.go b/obsreport/doc.go deleted file mode 100644 index ca75b9ac670..00000000000 --- a/obsreport/doc.go +++ /dev/null @@ -1,105 +0,0 @@ -// Copyright The OpenTelemetry Authors -// SPDX-License-Identifier: Apache-2.0 - -// 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: -// -// `/` -// -// As a label the metric should have at least `{=""}` where -// `` 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: -// -// `//` -// -// 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",...}` -package obsreport // import "go.opentelemetry.io/collector/obsreport" diff --git a/obsreport/obsreporttest/deprecated.go b/obsreport/obsreporttest/deprecated.go deleted file mode 100644 index b822191ee4e..00000000000 --- a/obsreport/obsreporttest/deprecated.go +++ /dev/null @@ -1,29 +0,0 @@ -// Copyright The OpenTelemetry Authors -// SPDX-License-Identifier: Apache-2.0 - -package obsreporttest // import "go.opentelemetry.io/collector/obsreport/obsreporttest" - -import ( - "go.opentelemetry.io/collector/component" - "go.opentelemetry.io/collector/component/componenttest" -) - -// Deprecated: [0.93.0] Use componenttest.TestTelemetry instead -type TestTelemetry = componenttest.TestTelemetry - -// SetupTelemetry does setup the testing environment to check the metrics recorded by receivers, producers or exporters. -// The caller must pass the ID of the component that intends to test, so the CreateSettings and Check methods will use. -// The caller should defer a call to Shutdown the returned TestTelemetry. -// -// Deprecated: [0.93.0] Use componenttest.SetupTelemetry instead -func SetupTelemetry(id component.ID) (TestTelemetry, error) { - return componenttest.SetupTelemetry(id) -} - -// CheckScraperMetrics checks that for the current exported values for metrics scraper metrics match given values. -// When this function is called it is required to also call SetupTelemetry as first thing. -// -// Deprecated: [0.93.0] Use TestTelemetry.CheckScraperMetrics instead -func CheckScraperMetrics(tts TestTelemetry, receiver component.ID, scraper component.ID, scrapedMetricPoints, erroredMetricPoints int64) error { - return tts.CheckScraperMetrics(receiver, scraper, scrapedMetricPoints, erroredMetricPoints) -} diff --git a/obsreport/obsreporttest/package_test.go b/obsreport/obsreporttest/package_test.go deleted file mode 100644 index 97b3f7f9210..00000000000 --- a/obsreport/obsreporttest/package_test.go +++ /dev/null @@ -1,14 +0,0 @@ -// Copyright The OpenTelemetry Authors -// SPDX-License-Identifier: Apache-2.0 - -package obsreporttest - -import ( - "testing" - - "go.uber.org/goleak" -) - -func TestMain(m *testing.M) { - goleak.VerifyTestMain(m) -}