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 new option '--instance_id' to have the wrapper look up instance-i… #2

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

thors
Copy link

@thors thors commented Sep 12, 2017

…d and push as additional dimension

Hi,
We intend to use the script in our AMIs for an environment with plenty of nodes and use crond to push data to cloudwatch. We could put another wrapper and use the 'dimension' option to add the instance-id, but imo

  • that would become messy
  • the requirement is generic enough to support it directly from your script

@slank
Copy link
Owner

slank commented Sep 12, 2017

Hi, @thors. Thanks for your pull request. I appreciate your help.

I can see how adding the instance ID to your metrics' dimensions would be useful. My gut says that this is outside the scope of what the tool should do.

The way I see it, there are a number of common dimensions one might use on metrics - Autoscaling group, availability zone, VPC or subnet ID, tag values - and that instance ID is not special in this regard. There are even many use cases where the check will not be run against the local host and the flag would do the wrong thing.

Even if we do support this type of special case, what naming convention would we use for the dimension? I notice that EC2 itself uses InstanceId for its own metrics (rather than instance-id in your PR).

I'm inclined to have users rely on "messy" wrappers, but perhaps this could be approached in a more generic way? Perhaps --metadata-dimension Key=/path/to/value that would allow the user to set dimensions based on a path in the EC2 metadata service? A good compliment would be --tag-dimension Key=<TagName>.

@thors
Copy link
Author

thors commented Sep 13, 2017

I see your point, looked again into the idea of writing a wrapper. It would be helpful if in cli::cli() you could call ap.arg_parse(args) instead of ap.arg_parse(), that way anyone using the wrapper-approach could use "ArgumentParser.parse_known_args()" in their wrapper and pass through a modified argument list. I provided a separate pull request #3, which should be risk-free (default-behaviour of your module shouldn't change).

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.

3 participants