Manual OR Automatic tags for service methods and metric events

[Babar_Qayyum]

Dear All,

Could you please let me know if there is a method to tag specific requests/or service methods and metric events?

Regards,

Babar Qayyum

[ChadTurner]

Hey @Babar_Qayyum - I dont think we can target specific traces or requests to have tags. 

We can apply tags to the top-level service either manually or automatically using Monitored Entity Rules or Entity Selectors. However, tagging does not extend beyond that layer.

The closest alternative at lower levels is a Request Attribute. With Request Attributes, you define a key:value pair similar to a tag, but there are more constraints. Specifically, if you want a dynamic value, that value must already exist within the trace data. Unlike tags, you cannot freely assign arbitrary values.

For Metric Events, you can include the associated tags of the alerting entity as Event Properties. For example, if a host triggers a custom Metric Event, all applicable tags on that host can be included in the event payload. This capability also applies to the new Davis Anomaly Detectors, now renamed Anomaly Detection.

In practice, this means you can create dynamic key:value pairs within alerts by leveraging Event Properties. You can also create a manually defined "tag-like" structure within the alert configuration itself. However, manually defined values are static. Unless the value uses a dynamic placeholder (for example, values enclosed in {}), the key:value pair will remain the same for every alert and will not change based on the alerting entity.

[Babar_Qayyum]

Hello @ChadTurner 

I appreciate your feedback. I have implemented a manual tag for custom metrics derived from the metric metadata, allowing for filtering across all metrics based on that tag. However, this same tag is not functioning during the maintenance windows, which is my primary requirement.

Regards,

Babar Qayyum

[ChadTurner]

Hey @Babar_Qayyum I wasn't aware you were looking to leverage it as a maintenance window but I totally understand your goal. To mute a request in a maintenance window fashion you have two options that I am aware of:

1 - Mute the requests individually. You if you navigate to the supporting service in Dynatrace, click into the settings of the service, then select muted requests and click add item. Yes this is very manual and you will need to then circle back around and remove it from the mute manually as well. If you have a ton of requests that need to be muted under the same service, it can take some time doing it manually.  You could also leverage the API as well for bulk adds/removes.

2 - Build out a mute workflow for requests of services. This will do the same exact think but allow you to schedule the reverting action just like when a maintenance window expires. So the first workflow will set the mute at the request level based on a date and time being the trigger, then another workflow that will act as the expiry to then revert the service back to a "No muted requests state" This way you don't have to manually set and revert the mute as expiry times come into play. You could also templatize this for faster posting.