Custom tags to be added to out of box sdk metrics

#1

Most metric which temporal sdk provides are just perfect for me, all i need is 2 or 3 more custom tags which can be added to all metrics / if not available defaulted to null or some value.

is there any way to overide defaultTags in MetricsTag or provide my own MetricsTag , i want both the framework code and my custom workflow/activity code to return the custom tags.

i dont really want to do metricsScope.timer("custometric).start() /stop etc… all i want is framework to capture metric and consistently include my custom tags if available.

#2

| tried something like this :

		Map<String,String>tags =new HashMap<String,String>();
		tags.putAll(MetricsTag.defaultTags("default")); //get the well know tags
		tags.put("customtagname1","defaultValue4tag1");
		tags.put("customtagname2","defaultValue4tag2");
		tags.put("customtagname3","defaultValue4tag3");
		Scope scope = new RootScopeBuilder().reporter(
				reporter).tags(new ImmutableMap<String, String>(tags)))
				.reportEvery(com.uber.m3.util.Duration.ofSeconds(config.getMetricPushIntervalInSeconds()));

-> with this i see that customtagname1, customtagname2, customtagname3 with default value gets appened to all metrics, which is great.

Now i tried doing this in my workflow
-----------Actual workflow Impl code -----------

WorkflowImpl {

workflowMethod () {
Map<String, String> tags =
new ImmutableMap.Builder<String, String>(2).put(“customtagname1”, “a”)
.put(“customtagname2”, “b”)
.build();

        Workflow.getMetricsScope().tagged(new HashMap<String, String>(tags));
  //do rest of workflow stuff..
 }

}

However i donot see my tag values getting reflected when i run this workflow.( this code is very similar to what temporal does inside GRPCMetricInterceptor)

am i missing something?

#3

any idea how i can achieve this? adding custom tags to oob sdk metrics.

#4

Hey @madhu, I don’t think what you are trying out is possible with current metric extensibility. We currently provide a mechanism to provide root scope when you initialize the client. You can set whatever tags on the root scope which will be inherited by all metric emitted by the SDK. But we don’t provide any extensibility to provide custom values for tags when the metric is emitted. So this works for any static tags you want to include with SDK metrics but will not work for dynamic tags. My recommendation would be emit your own metric for such use cases.

Can you also provide more details about the use case? Which metric you want to include more tags? Maybe it is something which makes sense from the SDK perspective in which case we would include the tag in SDK itself.

#5

Thansk samar, I use temporal for user signup , and signups are global in nature.
Through prometus we keep track of all the signup success/failure counts etc.
When a user signsup, the user can choose his home region/ product which the user is sigingup for.
i want to include the region and product in the metric tags , so that i can keep track of failures/sucess count across regions and product lines.

The workflow sucess count metrics is more than enough for me, all i need is additoina info on region,product so that i can tweak the dashboard/graphana alone to reder regional/product specific graphs.

I dont really want to add custom metrics when all i want is really availble oob but for the custom tags i need which are dynamic in nature :slight_smile:

#6

if you think, this will be a common usecase and benefit everybody, i can raise a feature request for the same, let me know your opinion.

#7

This sounds more like a use case for enhanced visibility or SearchableAttributes. If you are running Temporal with ElasticSearch I would highly recommend to use SearchableAttributes which allows you to list, filter, count executions based on your custom search criteria. It is much more powerful than just prometheus metric because it lets you list exact workflow executions based on your custom search criteria. Please see this forum thread for examples.

Regarding metric I’m not sure we want to expose this extensibility for dynamic tags mainly due to restrictions imposed by various metric backends. I would recommend to emit your custom metric using the metricScope on workflow context for this use case.