Skip to content
Fixter Docs
↑↓ Select⏎ OpenEsc Close

AWS Firehose

Some of your telemetry never passes through code you control. RDS, load balancers, Lambda and the rest of AWS write to CloudWatch, where no OpenTelemetry SDK can reach them. Fixter accepts an Amazon Data Firehose HTTP delivery stream, so that data can land in the same place as everything else.

This is for AWS-managed sources only. Your own services should send OpenTelemetry directly, which gives you traces as well as logs and metrics.

What you can send

Section titled “What you can send”
SourceFixter endpointArrives as
CloudWatch metric streamshttps://ingest.fixter.dev/aws/firehose/metricsmetrics
CloudWatch Logs, via a subscription filterhttps://ingest.fixter.dev/aws/firehose/logslogs

Both are Firehose HTTP endpoint destinations. Point a delivery stream at the URL and set its access key to your Fixter API key.

Before you start

Section titled “Before you start”

You need a Fixter API key, from Settings > API keys. Firehose sends it as the access key on every request, so it is the whole authentication story: no IAM role on the Fixter side and no other header.

Send CloudWatch metrics

Section titled “Send CloudWatch metrics”

  1. Create a Firehose delivery stream in the AWS console, source Direct PUT, destination HTTP Endpoint.

  2. Configure the endpoint. Set the URL to https://ingest.fixter.dev/aws/firehose/metrics and paste your Fixter API key into the access key field. Leave content encoding on GZIP; Fixter decompresses either way.

  3. Create a CloudWatch metric stream (CloudWatch > Metrics > Streams), choose the delivery stream from step 1, select OpenTelemetry 1.0 as the output format, and pick the namespaces you want. Start narrow, for example AWS/RDS and AWS/ApplicationELB; every namespace you add is billable volume on both sides.

  4. Confirm. Within a few minutes the metrics appear on the Metrics page, and list_metrics over MCP returns them.

Send CloudWatch Logs

Section titled “Send CloudWatch Logs”

  1. Create a second delivery stream, same as above, but with the URL https://ingest.fixter.dev/aws/firehose/logs.

  2. Subscribe a log group to it. In CloudWatch Logs, open the log group, then Subscription filters > Create Amazon Data Firehose subscription filter, and select that delivery stream. Repeat per log group you want in Fixter.

  3. Confirm. The lines appear on the Logs page.

The service name comes from the log group. Fixter takes the last path segment, so /aws/lambda/checkout-worker becomes service checkout-worker. RDS is special-cased to use the instance name, so /aws/rds/instance/orders-prod/postgresql becomes orders-prod rather than postgresql, which keeps one database’s logs together instead of splitting them by log type. Each record also carries the AWS account and log stream, so you can filter by them in QuerySQL.

If nothing shows up

Section titled “If nothing shows up”
  • Firehose reports delivery failures. The access key is wrong. It is your Fixter API key, pasted whole, with no Bearer prefix. Firehose retries into its S3 backup bucket, so check there for what it could not deliver.
  • The stream succeeds but nothing is queryable. Fixter skips records it cannot decode rather than rejecting the whole batch, which keeps one bad record from stalling a stream. The usual cause on metrics is the wrong output format: a metric stream must be OpenTelemetry 1.0, not JSON.
  • Logs arrive under a service name you did not expect. That is the log group’s last path segment, as above.
  • You are looking for control plane or kubelet logs from EKS. Those live in CloudWatch and journald respectively, so a log group subscription is exactly how you reach the CloudWatch half. See Kubernetes for what the collector covers instead.

Still stuck? Email info@fixter.dev and one of our founders will help you fix your problem asap.

Section titled “Related”