New component: AWS CloudWatch metrics receiver

[lewis262626]

The purpose and use-cases of the new component

Collect metrics from AWS Cloudwatch metrics and parse them in to OTel pmetric. Some metrics on AWS, such as Lambda memory usage etc, are only available from CloudWatch — users may want them to be put in one platform for analysis such as Prometheus with Grafana.

Example configuration for the component

receivers:
    awscloudwatchmetrics:
        region: <aws_region>
        profile: <aws_profile> # optional if omitted will use default for current if the AWS credential environment variables are not set
        polling_interval: 60
        metrics:
          named: 
             - namespace: AWS/ALB
                metric_name: RequestCount
             - namespace: AWS/ALB
                metric_name: 500Count

Telemetry data types supported

Metrics

Is this a vendor-specific component?

• [X] This is a vendor-specific component
• [ ] If this is a vendor-specific component, I am proposing to contribute this as a representative of the vendor.

Sponsor (optional)

No response

Additional context

Functionality is similar to AWSContainerMetrics receiver, maybe extend that instead and make it more generic?

[github-actions[bot]]

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.

[jpkrohling]

On behalf of the OpenTelemetry Squad at Grafana Labs, I would like to volunteer as a sponsor for this component. In addition to the component's author, the code owners (as sponsors) will be:

• @jpkrohling
• @kovrus

While we would very much prefer the affected vendor to support this receiver, we understand they might not be interested in translating their proprietary formats into OTLP, only the other way around.

We believe that the community wants this receiver, and if community members are willing to contribute code for this, we are willing to support the community.

[lewis262626]

@jpkrohling That's great, more than happy with that approach. Thanks to Grafana for stepping up :)

[jpkrohling]

@lewis262626, once you submit the PR, let me know. Please, make sure to follow the contributing guidelines for new components.

[lewis262626]

Sorry for the delay -- have made a start on this :)

[lewis262626]

@evan-bradley Please could I be assigned this issue

[matej-g]

Hi @lewis262626, has any work been started on this? We're also interested in having this receiver in the collector, happy to help where needed (contributing PRs, review).

[secustor]

Has it been considered to implement this as part of awscloudwatchreceiver?

awscloudwatchreceiver has all configuration options under a logs attribute, so it make sense to implement it their and add the configuration options for metrics simply under a separate metrics key.

For reference there is also an older issue regarding this component: https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/6226

[lewis262626]

@matej-g H Yes. You can view my progress under my fork https://github.com/lewis262626/opentelemetry-collector-contrib/tree/awscloudwatchmetricsreceiver/receiver/awscloudwatchmetricsreceiver

I only have an hour or so a week to commit to this so been slow progress I'm afraid. I have:

• [X] Implement config for receiver
• [X] Add unit tests to verify config parsing
• [X] Add newFactory method
• [X] Add unit tests for factory code
• [x] Implement AWS API calls (am going to use GetMetricData)
• [x] Parse in to pmetrics
• [x] Add unit tests for pmetrics conversion logic

Any help much appreciated

[lewis262626]

@secustor Potentially, yep. Although other metric receivers are standalone such as the awscontainerinsightreceiver

[matej-g]

@lewis262626 Thanks for sharing that. Let me know what form of help would make it possible to move this forward. Happy to take that code over if you're busy or feel free to open a draft PR if you'd like.

[lewis262626]

@matej-g I'll open a draft PR then

[lewis262626]

I've been pretty much done all the logic. Now onto finishing off the unit tests and integration tests.

Should I also implement this logic or leave for a later version?

The time stamp indicating the earliest data to be returned. The value specified is inclusive; results include data points with the specified time stamp. CloudWatch rounds the specified time stamp as follows: Start time less than 15 days ago - Round down to the nearest whole minute. For example, 12:32:34 is rounded down to 12:32:00. Start time between 15 and 63 days ago - Round down to the nearest 5-minute clock interval. For example, 12:32:34 is rounded down to 12:30:00. Start time greater than 63 days ago - Round down to the nearest 1-hour clock interval. For example, 12:32:34 is rounded down to 12:00:00. If you set Period to 5, 10, or 30, the start time of your request is rounded down to the nearest time that corresponds to even 5-, 10-, or 30-second divisions of a minute. For example, if you make a query at (HH:mm:ss) 01:05:23 for the previous 10-second period, the start time of your request is rounded down and you receive data from 01:05:10 to 01:05:20. If you make a query at 15:07:17 for the previous 5 minutes of data, using a period of 5 seconds, you receive data timestamped between 15:02:15 and 15:07:15. For better performance, specify StartTime and EndTime values that align with the value of the metric's Period and sync up with the beginning and end of an hour. For example, if the Period of a metric is 5 minutes, specifying 12:05 or 12:30 as StartTime can get a faster response from CloudWatch than setting 12:07 or 12:29 as the StartTime .

[matej-g]

Hey @lewis262626, Thanks for opening this up. I took a look at the PR, it looks like a good start. I wonder though do you intend to implement the actual polling?

As I mentioned previously, I'd be happy to take it from there if you're busy.

[lewis262626]

Hey @lewis262626,

Thanks for opening this up. I took a look at the PR, it looks like a good start. I wonder though do you intend to implement the actual polling?

As I mentioned previously, I'd be happy to take it from there if you're busy.

Hey, I'll reply to your PR comments in a bit. To answer your question, the receiver is done and I've been using to pull metrics from CloudWatch.

I was asked to split my PR, but if you want to use my code feel free to check out my branch as referenced in #19218.

[matej-g]

Got it, thanks @lewis262626, in that case I'll wait on that second PR.

[github-actions[bot]]

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.

[welljonathan]

Hi, I'm wondering how close this is to being completed? I see that @lewis262626 got it working and is using it, but then communication pretty much stopped. This looks like a very useful receiver so I'm trying to decide whether I can wait for it or whether I need to figure out a different way to accomplish the same thing. Thanks!

[matej-g]

Hey @welljonathan, the component skeleton was just merged yesterday (https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/19429), @lewis262626 should follow up soon with the PR for initial implementation. So hopefully this will be usable soon 🙂.

[lewis262626]

Hi, I'm wondering how close this is to being completed? I see that @lewis262626 got it working and is using it, but then communication pretty much stopped. This looks like a very useful receiver so I'm trying to decide whether I can wait for it or whether I need to figure out a different way to accomplish the same thing. Thanks!

The stub of the receiver was merged in 9a9ffcd. I'm working on the 2nd PR now, but feel free to look at the earlier PR and use that code. I've tested it locally but not production ready or anything like that.

[lewis262626]

I've done 90% of the receiver here.I still have to do some more tests but feel free to try it out. I'll be updating so rebase it every few days

https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/23562

[vainiusd]

Hi @lewis262626,

Really appreciate You taking up development of this feature!

I'm reviewing multiple available options for Cloudwatch metric collection and have stumbled upon an issue that none of the tools support: cross account metrics. It introduces some additional metric request logic but I would definitely vote for it's support 👍

I see that this introduces additional settings in SDKs usage: IncludeLinkedAccounts in listing metrics and AccountId in getting metric data.

Just putting it here to start a conversation and looking forward to the release of this receiver :)

[lewis262626]

Hi @lewis262626,

Really appreciate You taking up development of this feature!

I'm reviewing multiple available options for Cloudwatch metric collection and have stumbled upon an issue that none of the tools support: cross account metrics. It introduces some additional metric request logic but I would definitely vote for it's support 👍

I see that this introduces additional settings in SDKs usage: IncludeLinkedAccounts in listing metrics and AccountId in getting metric data.

Just putting it here to start a conversation and looking forward to the release of this receiver :)

I assume it's more than a one-line change, so it might be worth raising it as an issue once my PR has been merged

[github-actions[bot]]

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.

[ceevaaa]

Hey guys, is this completed ? It would be really helpful in my case.

[ashoktelukuntla]

Team - is the PR completed ? This will be a great value add.

[ceevaaa]

@ashoktelukuntla @lewis262626 is still working on the final changes and testing. See link.

[github-actions[bot]]

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.

[matej-g]

Still needed cc @lewis262626

[lewis262626]

@matej-g For sure, want to get this out for review soon

[ceevaaa]

@lewis262626 any updates here ?

[jaslkaur29]

Hi Team, is this available for use?

[mrphiljayfry]

Hey guys, are there any updates on this? :)

[imanAzi]

Hi all, is there any news when this would be available?

[jpkrohling]

There hasn't been progress for more than a year, and I'm not open anymore to being a sponsor for this component.

[wesleyreis1808]

Hi, I am interested in continuing the implementation of this receiver.

[wesleyreis1808]

Hi Team, I have finished the implementation. I used as a basis the work that @lewis262626 had started. I separated the implementation into two parts, the first containing a redefinition of the proposed structure and the second, the remainder of the receiver implementation. Can I open a PR?

[jpkrohling]

@wesleyreis1808, I'd recommend doing the following, in order:

1. asking on #otel-collector (CNCF Slack) whether any approvers would be willing to be sponsors
2. join the Collector SIG call on Wednesday asking the same

Without a sponsor, we cannot accept this. Unfortunately, I'm trying to offload commitments as I have too many things on me already, so I can't be a sponsor for this.

[dthauvin]

Hi @wesleyreis1808 , does this receiver can handle EKS IRSA ( IAM ROLE for Service Account) and find credential with this Env variable :

AWS_DEFAULT_REGION : eu-west-1 AWS_REGION : eu-west-1 AWS_ROLE_ARN : arn:aws:iam::xxxxxxxxxxxxx:role/myrole AWS_STS_REGIONAL_ENDPOINTS : regional AWS_WEB_IDENTITY_TOKEN_FILE : /var/run/secrets/eks.amazonaws.com/serviceaccount/token

I do not find any trace of usage GetMetricData api in AWS cloudtrail , and i do not find any debug usefull information.