You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's not possible to configure the receiver with PT10S with a mix of both projects, as MongoDB Atlas API returns an error, made worse by the nature of the error which contains no details.
HTTP 500 Internal Server Error (Error code: "UNEXPECTED_ERROR") Detail: Unexpected error. Reason: Internal Server Error. Params: []
The feature would be to allow different granularity for projects. It would probably be too opinionated to default to the lowest granularity depending on instance type, configuration at the project level would be ideal for flexibility.
Describe the solution you'd like
A global granularity as is, and also a project granularity (ie. override the default), for projects that have premium monitoring these can then be specified to be PT10S.
Describe alternatives you've considered
Running two exporters, one for standard and one for premium, or running multiple exporters, one per project.
Additional context
No response
The text was updated successfully, but these errors were encountered:
Component(s)
receiver/mongodbatlas
Is your feature request related to a problem? Please describe.
Currently granularity is configured globally https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/mongodbatlasreceiver/config.go#L29
Supported granularity is different depending on instance type. The standard granularity is PT1M, but if any cluster within a project is M40 or greater, premium monitoring for the entire project is enabled, which allows PT10S.
https://www.mongodb.com/docs/atlas/monitor-cluster-metrics/#premium-monitoring-granularity
It's not possible to configure the receiver with PT10S with a mix of both projects, as MongoDB Atlas API returns an error, made worse by the nature of the error which contains no details.
The feature would be to allow different granularity for projects. It would probably be too opinionated to default to the lowest granularity depending on instance type, configuration at the project level would be ideal for flexibility.
Describe the solution you'd like
A global granularity as is, and also a project granularity (ie. override the default), for projects that have premium monitoring these can then be specified to be PT10S.
Describe alternatives you've considered
Running two exporters, one for standard and one for premium, or running multiple exporters, one per project.
Additional context
No response
The text was updated successfully, but these errors were encountered: