Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[metrics builder] Ability to re-aggregate metric by attributes #10726

Open
1 of 3 tasks
Tracked by #10904
dmitryax opened this issue Nov 19, 2022 · 10 comments
Open
1 of 3 tasks
Tracked by #10904

[metrics builder] Ability to re-aggregate metric by attributes #10726

dmitryax opened this issue Nov 19, 2022 · 10 comments
Assignees

Comments

@dmitryax
Copy link
Member

dmitryax commented Nov 19, 2022

We need to provide users with the ability to change a set of attributes emitted by a metrics receiver by applying an automatic re-aggregation of the data points. For example, system.cpu.time is emitted by default with state and cpu attributes. Many users don't need metrics per CPU core, so they would like to get metrics per host and state instead. Currently, they would need to set up an additional metricstransform processor to achieve that. But this can happen inside the metrics builder instead.

Changes to metadata.yaml interface for receiver builders

metrics:
  system.cpu.time:
    enabled: true
    description: Total CPU seconds broken down by different states.
    unit: s
    sum:
      value_type: double
      aggregation: cumulative. # Probably to be renamed to not confuse with attributes_aggregation
      monotonic: true
    attributes_aggregation: sum  # NEW FIELD, name of the field is TBD
    attributes:
      cpu:
        enabled: true  # NEW FIELD
        description: CPU number starting at 0.

      state:
        enabled: true  # NEW FIELD
        description: Breakdown of CPU usage by type.
        enum: [idle, interrupt, nice, softirq, steal, system, user, wait]

This will also allow us to introduce the notion of Optional attributes that are disabled by default. E.g. cpu core is a good candidate for that.

This also requires moving the attributes section from the top level under each metric removing the naming confusion between the name of an attribute key and value field that not be needed anymore. Receiver authors that don't like the additional repetition can use YAML anchors instead.

Additional interface to user configuration

The metrics interface will get additional fields to disable/enable metrics and change the aggregation type. For example:

metrics:
  system.cpu.time:
    attributes_aggregation: [sum|avg|min|max]
    attributes:
      cpu:
        enabled: [true|false]
      state:
        enabled: [true|false]

Action items

  • Move the attributes section under each metric
  • Rename sum.aggregation field to not confuse it with attributes_aggregation
  • Introduce the re-aggregation functionality in the metrics builder
@dmitryax dmitryax changed the title Ability to re-aggregate metric by a smaller set of attributes. [metrics bbuilder] Ability to re-aggregate metric by attributes Nov 19, 2022
@dmitryax dmitryax changed the title [metrics bbuilder] Ability to re-aggregate metric by attributes [metrics builder] Ability to re-aggregate metric by attributes Nov 22, 2022
@dmitryax
Copy link
Member Author

dmitryax commented Dec 1, 2022

As discussed in open-telemetry/opentelemetry-collector-contrib#16533, we will not be moving the attributes to the metrics section in metadata.yaml. So I'm closing the corresponding action item as "Won't do"

@github-actions
Copy link
Contributor

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

@github-actions
Copy link
Contributor

Pinging code owners for cmd/telemetrygen: @mx-psi @amenasria @codeboten. See Adding Labels via Comments if you do not have permissions to add labels yourself.

@dmitryax
Copy link
Member Author

It's cmd/mdatagen not telemetrygen :)

@github-actions
Copy link
Contributor

github-actions bot commented Apr 3, 2023

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

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

@github-actions github-actions bot added the Stale label Apr 3, 2023
@github-actions
Copy link
Contributor

github-actions bot commented Jun 2, 2023

This issue has been closed as inactive because it has been stale for 120 days with no activity.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 2, 2023
@dmitryax dmitryax reopened this Jun 2, 2023
@dmitryax dmitryax removed the Stale label Jun 2, 2023
@dmitryax dmitryax self-assigned this Jun 2, 2023
@atoulme
Copy link
Contributor

atoulme commented Aug 1, 2023

Rename sum.aggregation field to not confuse it with attributes_aggregation
Rename sum.aggregation to sum.aggregation_temporality ? Following https://github.com/open-telemetry/opentelemetry-collector/blob/main/pdata/pmetric/generated_sum.go#L49

@github-actions
Copy link
Contributor

github-actions bot commented Oct 2, 2023

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

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

@github-actions github-actions bot added the Stale label Oct 2, 2023
@dmitryax dmitryax removed the Stale label Oct 2, 2023
Copy link
Contributor

github-actions bot commented Dec 4, 2023

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

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

@github-actions github-actions bot added the Stale label Dec 4, 2023
Copy link
Contributor

github-actions bot commented Feb 2, 2024

This issue has been closed as inactive because it has been stale for 120 days with no activity.

@dmitryax dmitryax removed the Stale label Feb 15, 2024
@dmitryax dmitryax reopened this Feb 15, 2024
@atoulme atoulme transferred this issue from open-telemetry/opentelemetry-collector-contrib Jul 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants