Well you said “no relevant adoption”. What is relevant? 40%? 60%? Of course you can not talk to every single customer. But I doubt that you talked to a “relevant” number of customers about that.
And there is no official mailing to customers about the deprecation, just an announcement here in the forum. How many customers do visit the forum regulary?
And to be honest: When looking at the thread I mentioned before, this descition sounds pretty lighthearted to me.
And please answer this question: Why do you deprecate service tags but not host tags? And that doesn’t mean, that I want you to deprectate host tags!
Another very good point! @martin.hirschvogel and @Sara
I agree, this should be an E-Mail announcement to all your paying customers. Like this, many will just notice by coinsidence or even confronted when upgrading and hopefully testing before. Imagine you created a lot with the service tags (can be any feature) and even your billing relys on it - boom!
Would also match and should be attached to this topic too
Thank you all for your feedback. Let me clarify some details discussed in the replies above in more details:
We do not take any decision to deprecate a feature lightly. Before making this announcement, we checked with our Checkmk consultants and our top partners, if they are aware of any usage of this feature. The feedback was a clear no.
As the next step in the process of deprecating a feature, we placed this announcement, which will be referenced in the next Checkmk newsletter. This should help to reach more customers. I asked for a direct message if this is an issue for any of our customers. While I haven’t got any direct message, I notice 3 customers having issues with the deprecation as they left comments under the announcement.
Since the newsletter is not yet sent, I monitor the forum for more comments.
As Martin mentioned, Checkmk currently does not have any feature to collect product telemetry. Therefore, forum posts and newsletters are the only way to get feedback. But this is something we should consider for the future.
Ok, so if a customer neither has a contract with a “top partner” nor uses consulting, he has no voice. No matter if he licensed a 6 digit number of checks in the highest edition (cme). Wow, interesting to read.
I guess most tribe29 customers are german companies. So IMHO collecting telemetry is not a very good idea. Instead of this, you should make surveys and give every (paying) customer a voice.
Apart from this: Have you asked your proxied customers why they don’t use the feature? The chance is high that they don’t use this because the implementation is pretty incomplete.
+1
There should be a dedicated way (i.e. special EMail address) for important notifications. I do not read every newsletter. There are too many and I can easily oversee the one from Tribe.
Rephrasing what Thomas said: The post here is your chance to make your voice heard, if you are using this feature. It’s a way for us to test the waters as well. F.e. in the Deprecation of the Favorites feature thread, we see that no one actually seems to care about the feature.
And, we use our top partners and our consultants as a proxy as it is not viable for us to reach out manually to 3000+ customers. To facilitate open exchange and discuss topics like this, we build this forum (instead of the old mailing list, which some might remember) as well.
If you use the feature heavily or have dedicated workflows depending on this feature, please send me a direct message here in the forum and I will reach out to you.
Thus, please use the chance and send Thomas a message. It gives us then the chance to go into a 1-on-1 discussion with you to better understand why and how you use the feature, and helps us to decide how to move forward with this.
To shine some history on the feature: When we added cloud monitoring in Checkmk 1.6, we wondered how to best integrate “labels”, which are a key element to cloud services. As we already had host tags, we thought why not reuse this concept and introduce service tags. Quickly we realized, this is not the right path due to the required flexibility, thus we introduced host and service labels. What we should have done back then was to immediately remove the commit with the service tags. That’s why you also don’t see a big werk announcing the service tags and any comment on service tags in the documentation. (@LaMi please correct me if I am wrong as I just joined the company back then)
The crucial part about tags vs labels is: Tags are predefined. Labels are freeform.
This makes a huge difference when many people from different teams are working with a system.
Also in views, if service tags would be implemented the same way as host tags, the view would only show the selected tags. When using labels, every label is displayed, which is unusable when a service has many labels
Also searching labels sometimes takes very long. But this could also be specific to our setup.
Wow!
But this actually matches with the QA Problem (@Sara for the dev thread)
“Yes we testet it, of course, we also run this version in a hand full of Production Environments we have access too”
Good that we have this amazing, and obviously hetorogen production environments for testing, cant imagine how much higher the number of bugs would be without them (right now around 550!
bug/sec fixes with p19)
Does it also imply that you dont check your tickets and feedback emails regarding desicions this?
As I’m 100% sure you will find some mentioning about it and not only from one customer
Not a partner, but with more then a couple of dozens of customers and some of the biggest companys in our country, nobody asked us as well
But this is really alarming if its the same case like QA. Ask a couple of Partners and Customers and if they dont have a case, thats it, especially if you know the number of usecases are limited due to incomplete implementation, as @gk998 mentioned as well
First of all, I would like to thank Tribe29 for the open discussion here. It takes some backbone to expose yourself to public criticism and deserves our thanks and respect.
The feedback here and the 20+ votes clearly show that your (paying) customers prefer to keep this Feature. The service tag feature request has already received more votes than the many of the cloud related feature requests.
I hope you can embrace the feedback from your customers and improve this great feature by adding the so long missed functions instead of removing the service tags. So that Checkmk continues to be this great tool that we all love so much.
On my distributed monitoring set up I am using Host Tags extensively.
I have around 2000 Tags that are controlling many rules and views. And having them predefined helps putting asset numbers and serial numbers on hosts. Tags can also be used to define locations, customers, rooms, contacts, warranties, system functions etc…
We even wrote software that synchronizes the host tags using the REST API of Checkmk with our ticketing system. Additionally, we use the tags together with dynamic host information from agents and snmp to automatically create offline documentations of hosts with a template.
Having the Tags stripped away would leave my setup totally unusuable. If the Tags are removed in future versions, I won’t update.
Don’t worry. This is about the service tags, not host tags.
Thanks for clearing this up, I misunderstood the feature that was being deprecated.
We want to thank you for your feedback. We have decided to NOT deprecate Service Tags in Checkmk 2.2.
What does this mean going forward?
While we recognize the use cases for Service Tags in their current state, our focus will remain on expanding the functionality of host- and service labels. This is where we see more demand from a broader customer base. For example, we are currently working on supporting using AND / OR / NOT operations on labels in filters and are evaluating if it is feasible to extend this to rules as well.
In the spirit of transparency and managing expectations: this means that in the near future we do not plan to dedicate development resources towards expanding the functionality of service tags. If you feel different about the priority of service tags, please feel free to vote on the feature request by LaSoe.
As long service tags are not same implemented like host tags we at least cannot use it like we want to.
In Detail:
-
Matching: All matching rules will add to the resulting list.
… and having not default tag like for host tags means that multiple tags of same “key” will be added - A column in a view cannot be set to show only a certain tag - it will always show all tags
Is there a quick way to search for service tags? Looking to see if anyone in my org deployed them. I have a feeling the answer is yes.
Since the service tags were never properly implemented, it is probably not so easy to answer this question. Maybe the “Tag usage” view can help you.
…/wato.py?folder=&mode=tag_usage
But this view only shows if and where which tags are used. It does not distinguish between host and service tags.
Update: I have just noticed that the view also lists the service tags but apparently does not evaluate where these are used
I am happy to hear that Tribe29 have decided to keep the status quo of service tags for now.
The Service Tag Feature Request is listed among the top 25 of 570 Feature Requests and has received already more votes than half of all the Feature Requests marked as “planned” and “implemented” – in just one month
Where does this leave the “we understand what our customers need, and we’re working on the features that matter most to them”?
We will evaluate it, when we do the detailed planning for Checkmk 2.3. So, we will consider it as we will consider all other highly voted features in the roadmapping process.