Skip to content
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

Add RDS tags #37

Closed
nhlushak opened this issue Nov 17, 2023 · 5 comments · Fixed by #72
Closed

Add RDS tags #37

nhlushak opened this issue Nov 17, 2023 · 5 comments · Fixed by #72
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@nhlushak
Copy link

Is your feature request related to a problem? Please describe.

Current implementation suggest to fetch data about rds instances across all account/region, which is already great, but lacks additional precision. We have around 50+ databases per region and use tags to be able filter them based on specific tag value.

Describe the solution you'd like

An ability to collect info about instance tags and add them as metric labels would increase possibilities of filtering data we collect.

@nhlushak nhlushak added the enhancement New feature or request label Nov 17, 2023
@vmercierfr
Copy link
Contributor

In our initial use case, we needed to collect metrics from all RDS instances, but it makes sense to support instance filtering. We need to think a bit about the way to implement it.

It could be relevant to be able to filter RDS instances by :

  • RDS engines (e.g PostgreSQL, MySQL..)
  • AWS tags (Environment=production), support of regexp could be interesting

RDS instances can have up to 50 tags, which could be a lot to ingest in Prometheus and probably not be used for alerting or visualization.

  1. Can you provide more details about your ideal instance filters?
  2. Can share your use case to collect AWS RDS tags in Prometheus?

Thanks,

@nhlushak
Copy link
Author

nhlushak commented Dec 1, 2023

Great question.
Indeed, we could use some basic filtering based on resource type, but our infrastructure in used across several teams. Each team is responsible for it's resources, so we consider that in our AWS tags. Usually, all our resources has this number of tags: Name, Env, Team, Component_type, Service, Created_by. These tags are used to filter data in our Grafana.

Speacing about possible cardinality issue, indeed this might be a problem, considering quotas for ResourceTaggingAPI. I might suggest to solve this in similar way as it done in YACE. It also offers exporting AWS tags, but you need to explicitly specify exact tag keys you need to fetch, avoiding unwanted label overflow.

@vmercierfr
Copy link
Contributor

I'm proposing to add rds_instance_tags metric in #72. It's very similar to YACE:

rds_instance_tags{aws_account_id="<account_id>",aws_region="<aws_region>",dbidentifier="<rds_identifier>",tag_Tag1="value1",tag_Tag2="value2"} 0

So you use it to filter metrics based on tags:

rds_instance_info + on (aws_account_id, aws_region, dbidentifier) group_left(tag_Environment) rds_instance_tags{tag_Owner="accountant"}

Does it meet your use case?

@nhlushak
Copy link
Author

nhlushak commented Dec 10, 2023

🤔
It seems like. I was not using joins in promql previously, but according to docs I've read, looks totally legit, so why not 👍

@vmercierfr vmercierfr self-assigned this Dec 11, 2023
@vmercierfr vmercierfr added this to the 0.5 milestone Dec 11, 2023
@vmercierfr vmercierfr reopened this Dec 11, 2023
@vmercierfr
Copy link
Contributor

Hello,

Sorry for the late response. We had to release version 0.5.1 to fix unsupported characters in Prometheus labels, but we introduced the aws_instance_tags metric in version 0.5.0.

Using PromQL joins, you can filter metrics based on AWS RDS instance tags.

Please upgrade your deployment to the latest version (currently 0.5.1), and feel free to reopen this issue if something is missing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants