Support for AWS Firehose Receiver in ADOT Collector

[jakeskyaws]

Description:

We would like to request the addition of the awsfirehosereceiver receiver in the ADOT Collector. This feature would enable direct ingestion of metrics from Amazon Kinesis Firehose streams, bypassing the need for sidecars or the ECS metrics receiver.

Use Case:

Our application is deployed at scale and does not utilize sidecars, making the ECS metrics receiver unsuitable for our needs. Deploying the ADOT collector as a service also does not currently support receiving ContainerInsights/Metrics for monitoring in AMP or Prometheus. We do not wish to view Continer Insights in CW but rather AMP to use along side other metrics currently in AMP.

Currently, we rely on alternatives like Yet Another CloudWatch Exporter (YACE) to scrape metrics, but this approach has notable drawbacks:

Significant Load: YACE introduces considerable load on the CloudWatch metrics API, which can be expensive.
Cost Implications: The high API usage can lead to increased costs.

We have previously implemented a solution involving a Kinesis Firehose stream to ingest selected metrics, such as Container Insights, and process them with a Lambda function. However, this solution is not sustainable long-term due to the lack of active maintenance for the Lambda function.

https://aws-observability.github.io/observability-best-practices/recipes/recipes/lambda-cw-metrics-go-amp/#create-an-amp-workspace

Proposed Solution:

Introducing an awsfirehosereceiver in the ADOT Collector would allow us to route metric data directly from Kinesis Firehose streams into the collector. This would streamline the ingestion process and enable us to view these metrics in AMP or Prometheus, adhering to our observability best practices.

Alternative Solutions:

While YACE is a possible solution, it has the aforementioned drawbacks. Additionally, our current setup using a Lambda function for processing Firehose data is not ideal due to maintenance challenges.

Additional Context:

A blog post on observability best practices that we follow highlights the benefits of using Kinesis Firehose for selected metrics. However, our current implementation is limited by the maintenance requirements of the Lambda function used for processing.
Implementing direct Firehose support in the ADOT Collector would provide a more reliable and scalable solution for ingesting and visualizing metrics from our distributed applications.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.