Skip to content
Merged
Show file tree
Hide file tree
Changes from 5 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 29 additions & 0 deletions .chloggen/codeboten_use-period.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
# 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: service

# A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`).
note: emit internal collector metrics with . instead of / with OTLP export

# One or more tracking issues or pull requests related to the change
issues: [9774]

# (Optional) One or more lines of additional information to render under the primary note.
# These lines will be padded with 2 spaces and then inserted directly into the document.
# Use pipe (|) for multiline entries.
subtext: |
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 `_`
and they will do the same with `.`.

# 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: []
20 changes: 10 additions & 10 deletions exporter/exporterhelper/obsexporter.go
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ import (
)

const (
exporterScope = obsmetrics.Scope + obsmetrics.NameSep + obsmetrics.ExporterKey
exporterScope = obsmetrics.Scope + obsmetrics.SpanNameSep + obsmetrics.ExporterKey
)

// ObsReport is a helper to add observability to an exporter.
Expand Down Expand Up @@ -78,55 +78,55 @@ func (or *ObsReport) createOtelMetrics(cfg ObsReportSettings) error {
var errors, err error

or.sentSpans, err = meter.Int64Counter(
obsmetrics.ExporterPrefix+obsmetrics.SentSpansKey,
obsmetrics.ExporterMetricPrefix+obsmetrics.SentSpansKey,
metric.WithDescription("Number of spans successfully sent to destination."),
metric.WithUnit("1"))
errors = multierr.Append(errors, err)

or.failedToSendSpans, err = meter.Int64Counter(
obsmetrics.ExporterPrefix+obsmetrics.FailedToSendSpansKey,
obsmetrics.ExporterMetricPrefix+obsmetrics.FailedToSendSpansKey,
metric.WithDescription("Number of spans in failed attempts to send to destination."),
metric.WithUnit("1"))
errors = multierr.Append(errors, err)

or.failedToEnqueueSpans, err = meter.Int64Counter(
obsmetrics.ExporterPrefix+obsmetrics.FailedToEnqueueSpansKey,
obsmetrics.ExporterMetricPrefix+obsmetrics.FailedToEnqueueSpansKey,
metric.WithDescription("Number of spans failed to be added to the sending queue."),
metric.WithUnit("1"))
errors = multierr.Append(errors, err)

or.sentMetricPoints, err = meter.Int64Counter(
obsmetrics.ExporterPrefix+obsmetrics.SentMetricPointsKey,
obsmetrics.ExporterMetricPrefix+obsmetrics.SentMetricPointsKey,
metric.WithDescription("Number of metric points successfully sent to destination."),
metric.WithUnit("1"))
errors = multierr.Append(errors, err)

or.failedToSendMetricPoints, err = meter.Int64Counter(
obsmetrics.ExporterPrefix+obsmetrics.FailedToSendMetricPointsKey,
obsmetrics.ExporterMetricPrefix+obsmetrics.FailedToSendMetricPointsKey,
metric.WithDescription("Number of metric points in failed attempts to send to destination."),
metric.WithUnit("1"))
errors = multierr.Append(errors, err)

or.failedToEnqueueMetricPoints, err = meter.Int64Counter(
obsmetrics.ExporterPrefix+obsmetrics.FailedToEnqueueMetricPointsKey,
obsmetrics.ExporterMetricPrefix+obsmetrics.FailedToEnqueueMetricPointsKey,
metric.WithDescription("Number of metric points failed to be added to the sending queue."),
metric.WithUnit("1"))
errors = multierr.Append(errors, err)

or.sentLogRecords, err = meter.Int64Counter(
obsmetrics.ExporterPrefix+obsmetrics.SentLogRecordsKey,
obsmetrics.ExporterMetricPrefix+obsmetrics.SentLogRecordsKey,
metric.WithDescription("Number of log record successfully sent to destination."),
metric.WithUnit("1"))
errors = multierr.Append(errors, err)

or.failedToSendLogRecords, err = meter.Int64Counter(
obsmetrics.ExporterPrefix+obsmetrics.FailedToSendLogRecordsKey,
obsmetrics.ExporterMetricPrefix+obsmetrics.FailedToSendLogRecordsKey,
metric.WithDescription("Number of log records in failed attempts to send to destination."),
metric.WithUnit("1"))
errors = multierr.Append(errors, err)

or.failedToEnqueueLogRecords, err = meter.Int64Counter(
obsmetrics.ExporterPrefix+obsmetrics.FailedToEnqueueLogRecordsKey,
obsmetrics.ExporterMetricPrefix+obsmetrics.FailedToEnqueueLogRecordsKey,
metric.WithDescription("Number of log records failed to be added to the sending queue."),
metric.WithUnit("1"))
errors = multierr.Append(errors, err)
Expand Down
9 changes: 5 additions & 4 deletions internal/obsreportconfig/obsmetrics/obs_exporter.go
Original file line number Diff line number Diff line change
Expand Up @@ -30,8 +30,9 @@ const (
)

var (
ExporterPrefix = ExporterKey + NameSep
ExportTraceDataOperationSuffix = NameSep + "traces"
ExportMetricsOperationSuffix = NameSep + "metrics"
ExportLogsOperationSuffix = NameSep + "logs"
ExporterPrefix = ExporterKey + SpanNameSep
ExporterMetricPrefix = ExporterKey + MetricNameSep
ExportTraceDataOperationSuffix = SpanNameSep + "traces"
ExportMetricsOperationSuffix = SpanNameSep + "metrics"
ExportLogsOperationSuffix = SpanNameSep + "logs"
)
2 changes: 1 addition & 1 deletion internal/obsreportconfig/obsmetrics/obs_processor.go
Original file line number Diff line number Diff line change
Expand Up @@ -18,5 +18,5 @@ const (
)

var (
ProcessorPrefix = ProcessorKey + NameSep
ProcessorMetricPrefix = ProcessorKey + MetricNameSep
)
9 changes: 5 additions & 4 deletions internal/obsreportconfig/obsmetrics/obs_receiver.go
Original file line number Diff line number Diff line change
Expand Up @@ -30,8 +30,9 @@ const (
)

var (
ReceiverPrefix = ReceiverKey + NameSep
ReceiveTraceDataOperationSuffix = NameSep + "TraceDataReceived"
ReceiverMetricsOperationSuffix = NameSep + "MetricsReceived"
ReceiverLogsOperationSuffix = NameSep + "LogsReceived"
ReceiverPrefix = ReceiverKey + SpanNameSep
ReceiverMetricPrefix = ReceiverKey + MetricNameSep
ReceiveTraceDataOperationSuffix = SpanNameSep + "TraceDataReceived"
ReceiverMetricsOperationSuffix = SpanNameSep + "MetricsReceived"
ReceiverLogsOperationSuffix = SpanNameSep + "LogsReceived"
)
5 changes: 3 additions & 2 deletions internal/obsreportconfig/obsmetrics/obs_scraper.go
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,7 @@ const (
)

const (
ScraperPrefix = ScraperKey + NameSep
ScraperMetricsOperationSuffix = NameSep + "MetricsScraped"
ScraperPrefix = ScraperKey + SpanNameSep
ScraperMetricPrefix = ScraperKey + MetricNameSep
ScraperMetricsOperationSuffix = SpanNameSep + "MetricsScraped"
)
5 changes: 3 additions & 2 deletions internal/obsreportconfig/obsmetrics/obsmetrics.go
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,7 @@
package obsmetrics // import "go.opentelemetry.io/collector/internal/obsreportconfig/obsmetrics"

const (
NameSep = "/"
Scope = "go.opentelemetry.io/collector/obsreport"
SpanNameSep = "/"
MetricNameSep = "."
Copy link
Member

Choose a reason for hiding this comment

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

This won't be a breaking change for end users who scrape the metrics with prometheus right? But it will be a breaking change for anyone using the otel go sdk to emit metrics right? I am worried about breaking end-user telemetry in a single release, should we add a feature gate?

Copy link
Member

Choose a reason for hiding this comment

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

Isn't OTel Go SDK support under a feature gate already?

Copy link
Member

Choose a reason for hiding this comment

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

Ya, but I'm always worried changing telemetry names bc of the impact to alerting. I believe our policy for alpha/beta feature gates is that we can change the feature without a breaking change. If we chose to do that we could make the release notes super clear and discoverable what we broke.

Copy link
Contributor

Choose a reason for hiding this comment

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

+1 to tyler's concern here. By making the separator here a . instead of a _ we would then create three possibilities for users today:

otelcol.process_uptime # the metric for process uptime after this pr merges for users emitting otlp
otelcol_process_uptime # the metric for process uptime after this pr merges for users scraping via prometheus
process_uptime # the metric for process uptime prior to this merges for users emitting otlp

Rather than creating a third potential for this metric name, if the separator were _ we would simply have this state:

otelcol_process_uptime # after this change, no matter if a user is sending OTLP or Prometheus
process_uptime # the metric for process uptime prior to this merges for users emitting otlp

Creating a third state disincentivizes users from sending OTLP (because it would break their dashboards/alerts) or upgrading their collector further for the same reason.

We already do not follow the conventions mentioned here, see naming for time and utilization. Prometheus currently rules the metric world for metric naming, independently of the recommendations made by our own semantic convention today. Given that, I think for legacy conversions we should always be opting for not breaking users by following the existing convention. We should reconsider this once semantic convention exists for not only metric naming recommendations (when to use a . or a _), but also for pipeline monitoring.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right the problem is see with using _, is that today, changing a collector from emitting metrics using prometheus to OTLP has a problem with metrics we don't control.

As an example, the metric for grpc instrumentation changes from

otelcol_rpc_server_requests_per_rpc

to:

rpc.server.responses_per_rpc

This is because the prometheus metric replaces . with _ (as it does for other collector metrics /). Replacing the separator with _ instead of . means users will still have to contend with a broken metric, it's just not clear which metrics will be broken to them, as they may not know what constitutes an instrumentation metric vs a collector metric. I opted to go with . as it at least aligns with the opentelemetry semantic convention.

Copy link
Member

Choose a reason for hiding this comment

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

Creating a third state disincentivizes users from sending OTLP (because it would break their dashboards/alerts) or upgrading their collector further for the same reason.

It is true that breaking the name is going to disincentivize users, but I don't think we want to hold ourselves to prometheus naming standards when OTel has its own naming standard.

I can see an argument for waiting until more semantic conventions are stabilized before doing the breaking change to require only 1 breaking change for our end users.

I am ok keeping this change behind the useOtelWithSDKConfigurationForInternalTelemetry since it is still alpha.

Copy link
Contributor

Choose a reason for hiding this comment

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

yeah my other concern is that by changing the convention for the collector's own metrics, we actually invalidate any documents for stable/beta components that mention existing metrics. these documents mention the important metrics for various components, none mentioning that these are "prometheus convention" but rather that they are the important metrics for monitoring your collector. By creating a dual state, all of these documents would need to be edited as part of this change and then edited again upon guidance from the OTEP.

Similarly, I would argue that by not keeping the metrics consistent we are introducing a bug to the collector – we would not be able to make the useOtelWithSDKConfigurationForInternalTelemetry flag beta because then anyone emitting metrics via OTLP would see incorrect metric names for components like the batch processor.

Copy link
Member

Choose a reason for hiding this comment

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

@codeboten is there a world where we handle switch to the OTEL SDK in 2 steps:

  1. Get the useOtelWithSDKConfigurationForInternalTelemetry to Stable without breaking the emitted metric names:
    • this gets us off the prometheus receivers/opencensus dependency and aligned with the project the collector is a part of.
  2. Redo the metric names to meet OTel stable metric conventions.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

so i see two problems and maybe it's easier to reason with a decision to move forward if we think about them separately.

1. Metrics controlled by the collector

These are the metrics that come from instruments instantiated in the collector itself. An example of such a metric is processor/batch/metadata_cardinality. This metric in the prometheus export is generated with the otelcol_ prefix and all the / are replaced with _ resulting in a metric named: otelcol_processor_batch_metadata_cardinality.

These metrics are currently being emitted one way via the prometheus export, and another via OTLP export:

otelcol_processor_batch_metadata_cardinality # prometheus metric
processor/batch/metadata_cardinality # otlp metric

After this change, it would be emitted like (which aligns more closely to otel conventions):

processor.batch.metadata_cardinality

The alternative would be to emit this as

processor_batch_metadata_cardinality

Ignoring the missing prefix as that's done in a separate change, this would remain consistent with the prometheus naming that exists today.

2. Metrics generated by instrumentation

These are metrics we don't control as they're the result of instrumentation libraries for which we have limited control (outside of using views). These metrics currently look like this:

otelcol_rpc_server_requests_per_rpc # prometheus metric
rpc.server.requests_per_rpc # otlp metric

After this change, nothing changes in the metric itself, as there is no configuration for the separator or prefix for the OTLP exporter.

My proposal was to align both the 1 & 2 more closely to prevent users having some of their metrics continue to work but not all of them. I thought that putting this behind an experimental flag would allow users to make a change across all the metrics generated by the collector at the same time, reducing the chance that only some of their metrics work.

That being said, I can also see the benefit from having the metrics under the collector's control not change multiple times. But as an end-user, it may not be clear why only instrumentation library metrics changed but not all of them.

I'm happy to discuss this at tomorrow's SIG call if it makes sense @jaronoff97 @TylerHelmuth

Copy link
Member

Choose a reason for hiding this comment

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

Ya let's discuss some more at the SIG

Scope = "go.opentelemetry.io/collector/obsreport"
)
28 changes: 14 additions & 14 deletions processor/processorhelper/obsreport.go
Original file line number Diff line number Diff line change
Expand Up @@ -19,21 +19,21 @@ import (
)

var (
processorScope = obsmetrics.Scope + obsmetrics.NameSep + obsmetrics.ProcessorKey
processorScope = obsmetrics.Scope + obsmetrics.SpanNameSep + obsmetrics.ProcessorKey
)

// BuildCustomMetricName 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.
func BuildCustomMetricName(configType, metric string) string {
componentPrefix := obsmetrics.ProcessorPrefix
if !strings.HasSuffix(componentPrefix, obsmetrics.NameSep) {
componentPrefix += obsmetrics.NameSep
componentPrefix := obsmetrics.ProcessorMetricPrefix
if !strings.HasSuffix(componentPrefix, obsmetrics.MetricNameSep) {
componentPrefix += obsmetrics.MetricNameSep
}
if configType == "" {
return componentPrefix
}
return componentPrefix + configType + obsmetrics.NameSep + metric
return componentPrefix + configType + obsmetrics.MetricNameSep + metric
}

// ObsReport is a helper to add observability to a processor.
Expand Down Expand Up @@ -87,63 +87,63 @@ func (or *ObsReport) createOtelMetrics(cfg ObsReportSettings) error {
var errors, err error

or.acceptedSpansCounter, err = meter.Int64Counter(
obsmetrics.ProcessorPrefix+obsmetrics.AcceptedSpansKey,
obsmetrics.ProcessorMetricPrefix+obsmetrics.AcceptedSpansKey,
metric.WithDescription("Number of spans successfully pushed into the next component in the pipeline."),
metric.WithUnit("1"),
)
errors = multierr.Append(errors, err)

or.refusedSpansCounter, err = meter.Int64Counter(
obsmetrics.ProcessorPrefix+obsmetrics.RefusedSpansKey,
obsmetrics.ProcessorMetricPrefix+obsmetrics.RefusedSpansKey,
metric.WithDescription("Number of spans that were rejected by the next component in the pipeline."),
metric.WithUnit("1"),
)
errors = multierr.Append(errors, err)

or.droppedSpansCounter, err = meter.Int64Counter(
obsmetrics.ProcessorPrefix+obsmetrics.DroppedSpansKey,
obsmetrics.ProcessorMetricPrefix+obsmetrics.DroppedSpansKey,
metric.WithDescription("Number of spans that were dropped."),
metric.WithUnit("1"),
)
errors = multierr.Append(errors, err)

or.acceptedMetricPointsCounter, err = meter.Int64Counter(
obsmetrics.ProcessorPrefix+obsmetrics.AcceptedMetricPointsKey,
obsmetrics.ProcessorMetricPrefix+obsmetrics.AcceptedMetricPointsKey,
metric.WithDescription("Number of metric points successfully pushed into the next component in the pipeline."),
metric.WithUnit("1"),
)
errors = multierr.Append(errors, err)

or.refusedMetricPointsCounter, err = meter.Int64Counter(
obsmetrics.ProcessorPrefix+obsmetrics.RefusedMetricPointsKey,
obsmetrics.ProcessorMetricPrefix+obsmetrics.RefusedMetricPointsKey,
metric.WithDescription("Number of metric points that were rejected by the next component in the pipeline."),
metric.WithUnit("1"),
)
errors = multierr.Append(errors, err)

or.droppedMetricPointsCounter, err = meter.Int64Counter(
obsmetrics.ProcessorPrefix+obsmetrics.DroppedMetricPointsKey,
obsmetrics.ProcessorMetricPrefix+obsmetrics.DroppedMetricPointsKey,
metric.WithDescription("Number of metric points that were dropped."),
metric.WithUnit("1"),
)
errors = multierr.Append(errors, err)

or.acceptedLogRecordsCounter, err = meter.Int64Counter(
obsmetrics.ProcessorPrefix+obsmetrics.AcceptedLogRecordsKey,
obsmetrics.ProcessorMetricPrefix+obsmetrics.AcceptedLogRecordsKey,
metric.WithDescription("Number of log records successfully pushed into the next component in the pipeline."),
metric.WithUnit("1"),
)
errors = multierr.Append(errors, err)

or.refusedLogRecordsCounter, err = meter.Int64Counter(
obsmetrics.ProcessorPrefix+obsmetrics.RefusedLogRecordsKey,
obsmetrics.ProcessorMetricPrefix+obsmetrics.RefusedLogRecordsKey,
metric.WithDescription("Number of log records that were rejected by the next component in the pipeline."),
metric.WithUnit("1"),
)
errors = multierr.Append(errors, err)

or.droppedLogRecordsCounter, err = meter.Int64Counter(
obsmetrics.ProcessorPrefix+obsmetrics.DroppedLogRecordsKey,
obsmetrics.ProcessorMetricPrefix+obsmetrics.DroppedLogRecordsKey,
metric.WithDescription("Number of log records that were dropped."),
metric.WithUnit("1"),
)
Expand Down
4 changes: 2 additions & 2 deletions processor/processorhelper/obsreport_test.go
Original file line number Diff line number Diff line change
Expand Up @@ -63,11 +63,11 @@ func TestBuildProcessorCustomMetricName(t *testing.T) {
}{
{
name: "firstMeasure",
want: "processor/test_type/firstMeasure",
want: "processor.test_type.firstMeasure",
},
{
name: "secondMeasure",
want: "processor/test_type/secondMeasure",
want: "processor.test_type.secondMeasure",
},
}
for _, tt := range tests {
Expand Down
14 changes: 7 additions & 7 deletions receiver/receiverhelper/obsreport.go
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ import (
)

const (
receiverScope = obsmetrics.Scope + obsmetrics.NameSep + obsmetrics.ReceiverKey
receiverScope = obsmetrics.Scope + obsmetrics.SpanNameSep + obsmetrics.ReceiverKey
)

// ObsReport is a helper to add observability to a receiver.
Expand Down Expand Up @@ -88,42 +88,42 @@ func (rec *ObsReport) createOtelMetrics() error {
var errors, err error

rec.acceptedSpansCounter, err = rec.meter.Int64Counter(
obsmetrics.ReceiverPrefix+obsmetrics.AcceptedSpansKey,
obsmetrics.ReceiverMetricPrefix+obsmetrics.AcceptedSpansKey,
metric.WithDescription("Number of spans successfully pushed into the pipeline."),
metric.WithUnit("1"),
)
errors = multierr.Append(errors, err)

rec.refusedSpansCounter, err = rec.meter.Int64Counter(
obsmetrics.ReceiverPrefix+obsmetrics.RefusedSpansKey,
obsmetrics.ReceiverMetricPrefix+obsmetrics.RefusedSpansKey,
metric.WithDescription("Number of spans that could not be pushed into the pipeline."),
metric.WithUnit("1"),
)
errors = multierr.Append(errors, err)

rec.acceptedMetricPointsCounter, err = rec.meter.Int64Counter(
obsmetrics.ReceiverPrefix+obsmetrics.AcceptedMetricPointsKey,
obsmetrics.ReceiverMetricPrefix+obsmetrics.AcceptedMetricPointsKey,
metric.WithDescription("Number of metric points successfully pushed into the pipeline."),
metric.WithUnit("1"),
)
errors = multierr.Append(errors, err)

rec.refusedMetricPointsCounter, err = rec.meter.Int64Counter(
obsmetrics.ReceiverPrefix+obsmetrics.RefusedMetricPointsKey,
obsmetrics.ReceiverMetricPrefix+obsmetrics.RefusedMetricPointsKey,
metric.WithDescription("Number of metric points that could not be pushed into the pipeline."),
metric.WithUnit("1"),
)
errors = multierr.Append(errors, err)

rec.acceptedLogRecordsCounter, err = rec.meter.Int64Counter(
obsmetrics.ReceiverPrefix+obsmetrics.AcceptedLogRecordsKey,
obsmetrics.ReceiverMetricPrefix+obsmetrics.AcceptedLogRecordsKey,
metric.WithDescription("Number of log records successfully pushed into the pipeline."),
metric.WithUnit("1"),
)
errors = multierr.Append(errors, err)

rec.refusedLogRecordsCounter, err = rec.meter.Int64Counter(
obsmetrics.ReceiverPrefix+obsmetrics.RefusedLogRecordsKey,
obsmetrics.ReceiverMetricPrefix+obsmetrics.RefusedLogRecordsKey,
metric.WithDescription("Number of log records that could not be pushed into the pipeline."),
metric.WithUnit("1"),
)
Expand Down
4 changes: 2 additions & 2 deletions receiver/scraperhelper/obsreport.go
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ import (
)

var (
scraperScope = obsmetrics.Scope + obsmetrics.NameSep + obsmetrics.ScraperKey
scraperScope = obsmetrics.Scope + obsmetrics.SpanNameSep + obsmetrics.ScraperKey
)

// ObsReport is a helper to add observability to a scraper.
Expand Down Expand Up @@ -98,7 +98,7 @@ func (s *ObsReport) createOtelMetrics(cfg ObsReportSettings) error {
// returned context should be used in other calls to the obsreport functions
// dealing with the same scrape operation.
func (s *ObsReport) StartMetricsOp(ctx context.Context) context.Context {
spanName := obsmetrics.ScraperPrefix + s.receiverID.String() + obsmetrics.NameSep + s.scraper.String() + obsmetrics.ScraperMetricsOperationSuffix
spanName := obsmetrics.ScraperPrefix + s.receiverID.String() + obsmetrics.SpanNameSep + s.scraper.String() + obsmetrics.ScraperMetricsOperationSuffix
ctx, _ = s.tracer.Start(ctx, spanName)
return ctx
}
Expand Down