Output of “cmk --debug -vvn hostname”: (If it is a problem with checks or plugins)
If I understand it correctly then the if a tag group got a non-empty value then the first value is set as “Default Value” and that I can also see in the host.
But for services this tag is not set as default!
Furthermore the “service tags” rules got this matching rule - which means that there is no possibility to set a default tag for all services: Matching: All matching rules will add to the resulting list.
I could maybe go via labels but I don’t wanna do again a workaround. Do I miss something?!
How do you set service tags? You normally have to set that specific to a service? Host tags are set on ALL hosts by default, so the first value will ALWAYS be set, independent on if you want it or not
I set service tags via service tags rules like I mentioned. Is there another way?!
Yes I know that hosts got a default value but services don’t and exactly this is the problem! If I want to set a default tag on service then I need to set it for all services - which is no solution.
Ok now I understand,
I don’t think that will work, as you can only use one tag key at once (there are no multi-select)
I think the rule talks about that of course if you assign multiple TAGS they will all add up…
Host tags are easier as you can set the tag on the WATO folder, you don’t need a rule for that. But services don’t have a folder…
I assume you have tested the above? Just curios what happened?
We use service labels to tag services that are under SLA, the others we don’t care about tagging at all.
Yes I have tested that already But thanks for the help!
We also use service labels for SLA calculating. But we also got a “severity” which we use in a different way.
So maybe I have to open a bug (but probably it won’t be seen as a bug) or I have workaround with labels or I have a look at “service level for services”. At the beginning I thought this can be used for SLA too but there is no option to set it to a service with a certain “service level”. The good thing about “service level” would be that it is better shown in views. Because I also reported that for hosts you can explicitly say which tag you want to see in a view but for services you can just show all tags in views.
We have added service labels to all service views (and made them public, so they replace the internal ones) - This is quite useful as you can click on them and quickly filter services != OK
That way we can combine host labels (there is where we set “severity” based on data from our CMDB that is automatically imported)
So we can have rules saying “if host X severity=critical AND service = Gold SLA” > then push notifications (or whatever we want to do)
Yes, I agree SLA should be more than a “tag”, you have to use Business Intelligence for that (I think)
Can anyone from “tribe29” explain why the default tag is not applied to services as default?
Also why there all tags are added to a service in service tag rules? Is there a use-case why I want a tag of same “key” but different values? @lars.getwan maybe?
Just want to understand because we need to find a workaround then. Maybe we could use “service level” for that but also because of bad documentation the use-case is also not 100% clear in my opinion.
Hi @matze218,
Services do not have tags by default at all, that’s why they do not have a default.
Question: why do you use service tags at all? What’s the benefit? Where do you use them after having applied any?
@MarsellusWallace let me ask the other way round: What exactly is the purpose of service tags? Maybe we didn’t get it properly. I would not ask that if there would be a proper documentation. But I couldn’t find anything about service tags in the checkmk documentation.
service tags were once meant to be used like host tags, too. But till now nobody was able to define a use-case with current implementation. It’s really totally unclear what they currently are used for by our customers:
not usable in rule conditions
not usable in notification rules
only view filters available
Since we have service labels, who still needs service tags?
Checkmk rigidly defines which tags and tag groups are present. Everything is well-defined. Every host has exactly one tag from every group. Everyone can rely on it. Typing errors in the spelling of tags cannot occur — not even with hosts which do not stick to the scheme — because its compliance is strictly controlled by Checkmk.
This is why we wanted to use tags ^.
Our use-case is that we got a severity which we show at our Service Desk Dashboard that the service desk know how “important” that service is and when it shall be looked after. But there also could be any other use-case because tags are free to define and used.
Probably many don’t use it or workaround it because there are not condition and it seems like that it is not implemented in a final version. We thought that this is probably just the “state of implementation”.
Furthermore if service tags would be implemented like host tags then it would be possible to show a certain tag in views and not just all tags. If we would now use labels then all labels would be shown in the view - which can be very very much.
as said service do not have any tags by default. this is also the reason why they do not use the tag-defaults like the hosts.
Why not using the existing “service level” rules for hosts and services? With these you can set service levels (defined in global settings) just like you currently do for service tags.
Benefits:
service levels available in view and dashboard filters
service levels available in event console (if the EC is used)
service levels available in notification conditions
view columns showing the service level available for hosts and services
I asked internally about the current and future state of “service tags” though and will get back with any information I get…
@MarsellusWallace yes in this one special use-case I could maybe use service level as I also mentioned before. But in general it should work like host tags imho.
But according to service level I also expected that this can be used for SLA but it seems like it got nothing to do with SLA. There isn’t an option to put a “service level condition” to SLA.
One important question: Where can I find “service level” in the API? Was not able to find in the service status table.
The service levels get set in livestatus columns custom_variable/custom_variable_names/custom_variable_values for hsts/services, where the custom variable is called “EC_SL”. These columns can be fetched by RestAPI host/service status endpoints.
@MarsellusWallace we got another use-case where we wanted to use tags. “Escalation” shows our service desk who has to be called: “so which team or which customer has to be informed”.
But thanks for the help!