The suggested example configuration contradicts the opentelemetry-collector docs (batch, memory_limiter)

[x-yuri]

Component(s)

exporter/googlemanagedprometheus

Describe the issue you're reporting

I'm talking about the following example.

The order in each section below is the best practice. Refer to the individual processor documentation for more information.

1. memory_limiter
2. Any sampling or initial filtering processors
3. Any processor relying on sending source from Context (e.g. k8sattributes)
4. batch
5. Any other processors

https://github.com/open-telemetry/opentelemetry-collector/tree/v0.111.0/processor#recommended-processors

For the memory_limiter processor, the best practice is to add it as the first processor in a pipeline. This is to ensure that backpressure can be sent to applicable receivers and minimize the likelihood of dropped data when the memory_limiter gets triggered.

https://github.com/open-telemetry/opentelemetry-collector/blob/v0.111.0/processor/memorylimiterprocessor#best-practices

The batch processor should be defined in the pipeline after the memory_limiter as well as any sampling processors. This is because batching should happen after any data drops such as sampling.

https://github.com/open-telemetry/opentelemetry-collector/blob/v0.111.0/processor/batchprocessor#batch-processor

Also I believe it should be documented why you're renaming the location, cluster, namespace, job, instance, and project_id attributes. Are they produced by k8s? Resource Detection Processor? Or is it just in case something produces them?

[github-actions]

Pinging code owners:

• exporter/googlemanagedprometheus: @aabmass @dashpole @jsuereth @punya @damemi @psx95

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[dashpole]

Also I believe it should be documented why you're renaming the location, cluster, namespace, job, instance, and project_id attributes.

They can often be produced by things like kube-state-metrics. Even if they aren't, it is a precaution to prevent ingestion errors.

[damemi]

Also I believe it should be documented why you're renaming the location, cluster, namespace, job, instance, and project_id attributes.

They can often be produced by things like kube-state-metrics. Even if they aren't, it is a precaution to prevent ingestion errors.

This is documented in the Resource Attribute Handling section and the official GCP docs