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

Ability to use lowercaseOutputName in particular rules #945

Open
Nirzak opened this issue Apr 22, 2024 · 4 comments
Open

Ability to use lowercaseOutputName in particular rules #945

Nirzak opened this issue Apr 22, 2024 · 4 comments

Comments

@Nirzak
Copy link
Contributor

Nirzak commented Apr 22, 2024

Hi, we know that we can define lowercaseOutputName globally which reflects all the rules. but If we want to define lowercaseOutputName only for particular rules except others then it doesn't work. Currently, we can define attrNameSnakeCase on the rules section but not lowercaseOutputName. The ability to use this option in the rule section will help us a lot. Thanks

@dhoard
Copy link
Collaborator

dhoard commented Apr 30, 2024

The current code either..

  1. uses the attribute name as defined by an MBean
  2. converts the attribute name to snake case

I looked at the code...

if (rule.attrNameSnakeCase) {
attributeName = toSnakeAndLowerCase(attrName);
} else {
attributeName = attrName;
}

... and adding a rule configuration value of attrNameLowercase would result in confusing configuration.

Example:

rules:
  - pattern: 'org.apache.cassandra.metrics<type=(\w+), name=(\w+)><>Value: (\d+)'
    name: cassandra_$1_$2
    value: $3
    valueFactor: 0.001
    labels: {}
    help: "Cassandra metric $1 $2"
    cache: false
    type: GAUGE
    attrNameSnakeCase: true
    attrNameLowercase: true

Is the attribute name snake case? lower case?
Is the user expecting a specific order of operations? (snake case then lowercase?

This feels like a workaround for inconsistent configuration of exporter rules and dashboards.

@Nirzak
Copy link
Contributor Author

Nirzak commented Apr 30, 2024

The current code either..

  1. uses the attribute name as defined by an MBean
  2. converts the attribute name to snake case

I looked at the code...

if (rule.attrNameSnakeCase) {
attributeName = toSnakeAndLowerCase(attrName);
} else {
attributeName = attrName;
}

... and adding a rule configuration value of attrNameLowercase would result in confusing configuration.

Example:

rules:
  - pattern: 'org.apache.cassandra.metrics<type=(\w+), name=(\w+)><>Value: (\d+)'
    name: cassandra_$1_$2
    value: $3
    valueFactor: 0.001
    labels: {}
    help: "Cassandra metric $1 $2"
    cache: false
    type: GAUGE
    attrNameSnakeCase: true
    attrNameLowercase: true

Is the attribute name snake case? lower case? Is the user expecting a specific order of operations? (snake case then lowercase?

This feels like a workaround for inconsistent configuration of exporter rules and dashboards.

Yeah the attrNameSnakeCase already makes an attribute name in lower case order. but my request was for lowercaseOutputName configuration per rule not the attribute name lower case. Currently metrics name can only be lowercase or uppercase globally. it reflects on all the rules which sometimes breaks some dashboards where one dashboard is using uppercase form of metrics where other is using the lower case form.

@dhoard
Copy link
Collaborator

dhoard commented Apr 30, 2024

where one dashboard is using uppercase form of metrics where other is using the lower case form.

At this time, I feel the best approach is to make your dashboards consistent. It will resolve operational issues in the future and prevent a mismatch of inconsistent usage.

@Nirzak
Copy link
Contributor Author

Nirzak commented Apr 30, 2024

where one dashboard is using uppercase form of metrics where other is using the lower case form.

At this time, I feel the best approach is to make your dashboards consistent. It will resolve operational issues in the future and prevent a mismatch of inconsistent usage.

Oh ok got it. Yeah are currently doing this as this is the only way..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants