Skip navigation

Enhancements to TSCO tags - Visibility rules and dedicated dataset

score 65
You have not voted. Product Team Review

In our projects, TSCO tags are more and more used to provide added value to the customer.

Most of our custom report templates and custom dashboards use tag information (as a metadata to be shown or as a filter dimension).


For example, we have been using tags:

  • to group servers of a specific business service basing on their role/functionality. CMDB does not provide the needed granularity, most of the times. When dealing with huge services, tags avoid you to run reports upon hundreds items. Instead, reports by layer can be instantiated.
  • to identify & group servers even if distributed within many different services
  • to mark servers which were involved in a specific activity (e.g. rightsizing, decommissioning or other) to easily filter them
  • to define aggregate server KPIs basing on tag value
  • ...


Given this, while we found a lot of benefits in using tags inside TSCO, we also had some design challenges in working with them efficiently.


1) The first point is related to tag proliferation & visibility:

  • tags are visible to everybody. When a TSCO environment is shared by many tenants and/or many internal customers, there is no way to make a tag type visible only to a subset of the stakeholders
  • as a side effect, tags assigned by different users might create confusions (for example: tags with similar names created for different purposes)
  • a wrong tag assignment, for the reasons above, might lead to have a server included by mistake into a report or dashboard


--> As a mitigation of this, we think it could make sense to have tag type visibility defined inside ACL groups.

We might decide to keep some tag types as "public" (as the OOTB ones based on OS platform or hw technology) and to restrict the access to other tag types.


2) A second point is related to the way tags are loaded and kept up-to-date.

Keeping tags aligned manually is a waste of time, especially when dealing with many internal customers/services/servers, and it's prone to errors.

This is why, whenever we need tags to be used for relevant projects, we decide to have automatic flows in place.

This is normally managed by filling configuration metrics, created only for this purpose.


Since tags are used often, this introduces some complexity in the management. For eac tagging as we need to:

  • configure a new ETL to read from tagging datastource(CSV, db table, ...) and to fill a new configuration metric
  • configure a new tagging rule to assign a tag value basing on the configuration metrics



--> Our suggestion would be to provide a specific "tagging" dataset (same way as we have a specific dataset to load objects relationships), which can be filled directly by ETL modules.

It would be then very easy to create two generic ETL modules (one to read from CSV, one to read from tables) to manage 90% of tagging needs.



What's your feedback on this?




Vote history