Skip to content

feat: Infer ARN from dimensions during discovery. - #1926

Open
jeschkies wants to merge 7 commits into
prometheus-community:masterfrom
jeschkies:karsten/arn-from-dimensions
Open

feat: Infer ARN from dimensions during discovery.#1926
jeschkies wants to merge 7 commits into
prometheus-community:masterfrom
jeschkies:karsten/arn-from-dimensions

Conversation

@jeschkies

Copy link
Copy Markdown
Contributor

This changes adds a few missing dimensions regexp to match more namespace to tagged resources. It also offers an optional fallback that infers the ARN and thus resource name from the metric dimensions in case a resources isn't tagged and couldn't be found using GetTaggedResources.

Adds a per-service ArnFromDimensionsFunc field that builds a resource ARN
directly from a metric's dimensions, without requiring the resource to be
discovered via the Tagging API first. Left nil wherever the canonical ARN
can't be trivially derived from dimensions alone -- e.g. it embeds an
internal ID CloudWatch doesn't expose (AutoScaling, Kafka), the format has
undocumented edge cases (DMS, WAFV2, EventBridge default bus, StorageGateway,
API Gateway), or the namespace has no fixed resource type at all.

Best-effort, derived from documented AWS ARN formats; not yet validated
against live AWS API responses.

Signed-off-by: Karsten Jeschkies <karsten.jeschkies@grafana.com>
…nd ArnFromDimensions

Verified against live resources in a sandbox account:
- AWS/Prometheus (amp): "Workspace" dimension is the workspace ID, maps
  directly onto the ARN (service segment is "aps", not "prometheus").
- AWS/Scheduler: metrics are only dimensioned by "ScheduleGroup", not
  per-schedule -- the ARN this reconstructs is the schedule group's.
- AWS/ECR: "RepositoryName" dimension is the repository name.

Also confirmed AWS/Redshift-Serverless can't be covered by either
DimensionRegexps or ArnFromDimensions: its "Namespace"/"Workgroup"
dimensions carry the resource name, but the canonical ARN embeds an
internal UUID that isn't derivable from the name.

Signed-off-by: Karsten Jeschkies <karsten.jeschkies@grafana.com>
Signed-off-by: Karsten Jeschkies <karsten.jeschkies@grafana.com>
Verified against live resources in a sandbox account:
- AWS/Timestream: "DatabaseName"/"TableName" dimensions map directly onto
  the ARN structure.
- AWS/RUM: "application_name" dimension is the app monitor name (only
  appears once a CloudWatch metrics destination is explicitly configured
  via PutRumMetricsDestination -- it's not on by default).
- AWS/AppRunner: uniquely among the UUID-suffixed ARN services checked so
  far, CloudWatch publishes both "ServiceName" and "ServiceID" as separate
  dimensions, so the full ARN (which needs both) is reconstructable.

AWS/Transfer, and the three SageMaker job-type namespaces, remain
unresolved: Transfer needs real SFTP transfer activity to emit any
metrics at all, and two separate SageMaker training jobs run to
completion produced zero metrics under any SageMaker namespace with a
bare (non-framework) container.

Signed-off-by: Karsten Jeschkies <karsten.jeschkies@grafana.com>
…rnFromDimensions

Signed-off-by: Karsten Jeschkies <karsten.jeschkies@grafana.com>
Signed-off-by: Karsten Jeschkies <karsten.jeschkies@grafana.com>
Signed-off-by: Karsten Jeschkies <karsten.jeschkies@grafana.com>
@jeschkies
jeschkies force-pushed the karsten/arn-from-dimensions branch from d7606c3 to cd7a08e Compare August 28, 2026 09:30
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

Successfully merging this pull request may close these issues.

1 participant