-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
New component: AWS ApplicationSignals Processor #32808
Comments
Added this component to the Collector SIG agenda as a vendor proposed component, the next maintainer on the rotating sponsor list should pick this up. cc @crobert-1 |
Thank you! Missed the collector SIG discussions for this week. Will join the discussions next week and provide more details about the proposal. |
Could we consider achieving this in a non vendor specific way? |
Can we detail this? |
Will keep design updated in https://docs.google.com/document/d/1YybdUN2__QL7mSF86ZBCN7AL4W5eXDgyoVzEGCpwz58/edit?usp=sharing |
Thx @mxiamxia |
@bryan-aguilar We had discussed this in a couple collector sig meetings, are you able to sponsor this? |
Hi @jeromeinsf , sorry for the late response. The MetricLimiter coming with this component primarily having 2 functions - 1) group the metrics on a list of specific metric attributes, then count and sort the occurrences of each grouped metrics using Count-Min Sketch(CMS). 2) take the actions to the metrics having less occurrences found in CMS when the cardinality threshold limit is met. Currently, these 2 piece of functions are implemented in a very specific way based on the customer experience designed for AppSignals. With extra efforts, I think it is possible to abstract some pieces into general purpose. With the current proposal, we probably want to defer this efforts and it requires a follow up with community for the further discussion on the abstractions. |
Thx @mxiamxia
Regarding 4 components listed, AppSignals users can leverage a list of existing processors including |
Hello @jj22ee, I recently sponsored a different vendor-specific component, so I've moved to the back of the rotating sponsors list. I see a few different contributors here proposing to work on this, are any of you OpenTelemetry project members? I ask because if the contributor is a member we'll automatically assign a sponsor. Otherwise, you may need to find a sponsor, or become an OpenTelemetry member. Here are the guidelines for contributing new vendor-specific components. |
@mxiamxia is a member of open-telemetry (checking from - https://github.com/orgs/open-telemetry/people). |
As discussed in a Collector SIG meeting, @djaglowski could be the sponsor for this component. Much appreciated!! |
Why isn't this being added to the ADOT collector? |
This component is not for ADOT only. The reason to add this component into upstream, is so that existing consumers of any OTel collector (non-ADOT) will be able to use ApplicationSignals with their current OTel setup. |
Generally, hosting a component upstream isn't necessary in order to allow others to pull it into any other OTel collector. As long as the component's go module is publicly accessible it should be possible. If this is the only reason then is it worth having the community take this on as an obligation?
I'm not sold on the idea that there's anything vendor-specific here other than configuration settings. Is it fair to say that this proposal could be separated into two parts?
|
Thanks. Another reason is that we want these components to be more discoverable for Otel users. IMHO, I think OTel-contrib repo was designed for this purpose, allowing vendors to contribute their components. AWS has most of its Otel components in the contrib repos, so we would like to include this one there as well. :) |
We can't simply replace this component with the existing opinionated config because it involves very vendor-specific implementations. For example, we mutate telemetry attributes based on the detected AWS platform where the applications are running. We also plan to implement centralized telemetry data filter/replace/drop rules that can be retrieved from AWS, eliminating the need for customers to update their local config. These are part of reasons why we want to introduce this component. Maybe go back your previous comment, for vendors introducing very business specific processors, is it common to contribute their processors to the contrib repo, or should vendors just host them in their own repo with public accessibility?
Yes, we can make the metric limiter part generic for all Otel users. Initially, we were thinking of contributing it as is and then collaborating with the community to optimize it for general use. However, I am fine that we can hold off on MetricLimiter part for now and come up with a more general design later. |
It sounds like there may be a real need for such a component but I'm not going to take it on as an obligation. The concept of automatically accepting vendor-related components was never intended to apply to all vendor-specific use cases. It was intended to ensure no vendor is excluded at a basic level. We recently updated our guidelines to reflect this intention. Generally speaking, components should be accepted based on the capacity and judgement of the maintainers & approvers. |
Hi Daniel, we are committed to maintaining this component and addressing any issues that may come up. We will also follow the guideline and ensure all listed criteria are met. Appreciate it if you could help us on reviewing our ongoing and upcoming PRs. |
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 |
The purpose and use-cases of the new component
Amazon CloudWatch ApplicationSignals utilizes the OTel Auto-instrumentation SDKs to automatically instrument applications running on AWS, and generates the custom application metrics, traces and log to monitor the application health and track long-term application performance. Currently, the generated telemetry data are processed by CloudWatch Agent before being sent to the AWS backend.
This proposal is to contribute ApplicationSignals components in CloudWatch Agent to OpenTelemetry Collector community.
The main functionalities
Example configuration for the component
Telemetry data types supported
Is this a vendor-specific component?
Code Owner(s)
mxiamxia@; bjrara@
Sponsor (optional)
Additional context
The AwsApplicationProcessor provides a data-processing pipeline which has 4 major components:
No response
The text was updated successfully, but these errors were encountered: