As of now “each host may only have one value per key”, this heavily limits the usefulness of labels.
There are many use-cases where it would be beneficial to have lables like key1:value1; key1:value2 (assigning host to multiple groups, etc.).
I know there are workarounds, like key1:yes; key2:yes, but this makes administration unnecessary complex.
That’s a bad idea as it would break existing usage of host and service labels.
1 Like
In which way would allowing multiple values per key break functionality?
And even if it would break something, there could always be a “use legacy mode” setting.
Best workaround is to use following syntax: KeyCategory/Key:Value, so you have grouping of keys.
Example: user/username1:yes
Hallo,
what is a usecase for your request?
Ralf
I see a lot of potential use-cases…
Creating host, service and contact groups assignment from a label.
Example: contactgroup:group1; contactgroup:group2, assigning a host to both groups.
Compose agent bakery rules by a label.
Example: app:splunk; app:grafana, installing both plugins for one server.
Basically everything where one wants to use a label in a cumulative way.
Ok,
I ve a similar usecase but using two labels app1:yes app2:yes.
Works pefect and simple using the labels in my rules,
Another case where the multiple values are useful are negations in rule conditions:
Example: apply a rule only when the label os:linux is not set, and os:windows is also not set.
@rprengel Sure, one could also create a SQL table with a column for each value, but you will agree that nobody would do it that way.
Same here, why should I have to create dozens of keys, when all I want is to add additional values.
You can achieve exactly the same with contactgroup/group1:yes and contactgroup/group2:yes and app/splunk:yes and app/grafana:yes.
4 Likes
@rprengel I think the most important Usecase is automation.
If you could have one Application Label, you can just extract the app: Key.
If you have another Key for Every Application, as we do have now, the programming part ist more complicated and not as straightforward, as it could be. Also Dashboards and any rule negations are more complicated.
I vote for multiple values!
With multiple values the rulesets “Service Label” and “Host Label” would not work any more.
We are currently assigning labels with these two rulesets in the form “sla:silver”, “sla:gold” and “sla:platinum” to hosts and services.
The rulesets itself have a match type “all”, i.e. all matching rules add to the resulting list. With the exception that labels with the same key will be set on first occurance.
Otherwise we could no assign a label “sla:platinum” to a specific service on a “silver” host where all other services should get “sla:silver” with the host tag as condition.
Example:
rule1: condition: service name = “Interface eth0” value: label = “sla:platinum”
rule2: condition: host tag = “sla:silver” value: label = “sla:silver”
With your idea of multiple values this service would then get “sla:platinum” and “sla:silver” assigned.
How would you solve our use case?
2 Likes
wrt automation: have a look at data2label: check_mk_extensions/data2label at cmk2.0 · HeinleinSupport/check_mk_extensions · GitHub
This automates setting host labels for e.g. applications. There is really no need for multiple values.
1 Like
I feel like stating the obvious when I say: The proposal is just not how labels work.
They are a key:value pair, making several vales per key available breaks a lot of logic as @r.sander already pointed out. If you tell your kid ‘Your name is Gunther’ and one day later you call it by the name ‘Jørgen’, what do you expect? Confusion, correct.
Workarounds (which are not workarounds to me, but proper usage of the features at hand) have also been outlined.
Additionally, for some use cases here you can and should use tags instead of labels. Say you want to label a host regarding its database or web server: Create a host tag ‘webserver’ or ‘database’ and provide all products you are using as choices. That way, you make sure there are no typos and the information is represented consistently across your environment. And if you now want to say, what about two database systems on the same server, tags will not work then, let me tell you: That would be just bad practice. Putting more than one service, especially of the same kind on the same server is just poor IT architecture.
Maybe a friendlier bottom line: The labels feature is very powerful and thought through. Please try to think about different solutions to your ‘problem’, I am sure Checkmk can provide you with a lot of flexibility there. Also, you saw the collective intelligence here at work, so I am positive you will find a way to do what you want to do.
1 Like
Well, I was under the impression that “Feedback/Product Ideas” was about improving the product, not about determining its current status.
Else it could be renamed to “Feedback/Product Praise” 
For me, creating a new key - when I just want to add a value - is a limitation and the ways to migitate this are workarounds.
But one man’s bug my be another man’s feature 
Hey, no hard feelings, I am completely with you, feedback is always appreciated! 
And I think most of the reactions in here were trying so solve your solution with existing methods. Maybe my town was just a little more teacher-like, but I do never mean to be rude. 
After all, there is the Vote button up top and if enough people feel like this is valuable, our product management will take a look.
I actually opened a ticket with support on this because I thought it was a bug.
I’d like to see it accept multiple values per key as well but for now we’re using the “work-a-round” method.