Query request count ( time series data ) using HTTP headers / attributes in Dynatrace DQL

[Butchi]

I have a java application with bunch of API end points and each end point has a unique identifier in the HTTP header header ( for example : sourceID as one identifier in the request header).  Whats the best way to get the  request count ( as time series data ) for each endpoint using service name and HTTP header attributes ?

In this case :

my service name = XYX_Service

Endpoint  = processRequest

URL path  = /api/my_request

HTTP request header attribute sourceID =abc

[dannemca]

You could enable the business events capture for these requests, and extract the HTTP header as attribute, then you can easily summarize it.

https://docs.dynatrace.com/docs/observe/business-observability/bo-events-capturing#examples-of-data-... 

Or, you could create a request attribute from classic settings, and create a calculated service metric from MDA app, using the created request attribute as dimension.

https://docs.dynatrace.com/docs/observe/applications-and-microservices/services/request-attributes/c... 

https://docs.dynatrace.com/docs/observe/applications-and-microservices/multidimensional-analysis#cal... 

[Butchi]

Hi @dannemca Yes we enabled those business events to capture business level metrics but we're not able to capture response times, failures and request counts via business events unless we're missing some additional steps in business events config.

From classic setting page, we have a request attribute rule to capture those headers ( using HTTP Request header as attribute source ) but those request attribute are not showing up as dimension although we have some traffic. Not sure what the issue was and whats causing it not to show up. 

[Julius_Loman]

@Butchi  can you share a screenshot? If can see request attributes on the service, you can define it in the calculated service metric:

You can also try to "reload" the Dynatrace UI (refresh the page), if the request attribute is newly defined, it might not be yet visible.

The most straightforward path is using the multidimensional analysis for the service, use the request attribute for splitting and then if the values are as expected, create a metric:

[Butchi]

Just to add , From classic setting page, with request attribute rule, Dynatrace shows ( Under Explore view ) those attributes under HTTP Headers as opposed to showing it under Request attributes. This is preventing us to create a calculated service metric using those dimensions.

[t_pawlak]

Hi,
if you can see the header under HTTP Headers in Explore, it means the OneAgent is capturing it.
However, for it to be available as a dimension (for Calculated Service Metrics or DQL), it must first be converted into a Request Attribute.

Here’s what you should check:

1. Verify the Request Attribute configuration

   • Go to Settings → Server-side service monitoring → Request attributes

   • Ensure the rule applies to the correct service (XYX_Service) or process group.

   • Make sure the data source is set to HTTP request header and the header name matches exactly (sourceID).

   • Choose a proper extraction type (usually First value).

2. Wait for propagation
   Request Attributes are calculated by the OneAgent. After saving the rule, allow a few minutes for the config to propagate and generate new traffic – attributes are not calculated retroactively.

3. Validate in MDA
   Open Multidimensional analysis for the service, try “Split by → Request attribute → sourceID”.

   • If you see values, the RA works and you can now create a Calculated Service Metric from it.

   • If not, enable Request Attribute debug logs in OneAgent to verify extraction.

4. Then create the Calculated Service Metric
   In MDA, click “Create metric” with the Request Attribute as dimension.
   
   Could you share a screenshot of your Request Attribute configuration?
   That will help confirm whether the setup matches the service and header correctly.

[Butchi]

Hi  @t_pawlak  & @Julius_Loman Thank you. Yes those settings are defined as mentioned in your steps. I think I found the issue. 

This is how my header looks like

accept: */*

source-id:QTR

content-length:2415

content-type: application/json

in my RA rule , I have "HTTP Request header" as my request attribute source and then parameter name defined as "source-id:" ( with column at the end ) and for some reason Dynatrace didn't like ":" so I went a head and removed it and request attributed are picking up and showing in MDA.

one final question - is there way to query time series data using those request attributes as filters ? I do not want to use fetch spans in this case.

Thank you.

[Julius_Loman]

Sure, when you create your calculated service metric, it will have the dimension (just a single one) you specified. So you can query it in both Dashboards and Dashboards classic.

[t_pawlak]

Calculated Service Metric (CSM) from MDA 

In Multidimension Anlaysys for your service, split by your Request Attribute source-id and pick the measure you want (e.g., request count, response time).

Click Create metric, and include the Request Attribute as a dimension in the metric definition

[Butchi]

Hi @t_pawlak , @Julius_Loman Yes I agree and  we can query Calculated Service Metrics (CSM) generated from MDA . However I'm thing about using requestAttribute as a filter in my DQL instead of going with Calculated Service Metric route. is that possible ? something like give me all request count where dt.serviceName=myService and source-id=XYZ

[Julius_Loman]

When you don't want a calculated service metric, you need query spans in DQL. (or bizevent - if you defined capturing). All has pros and cons. See table below

	Pros	Cons
Calculated service metric	No additional cost for queries	Works on captured traces (might not be 100% accurate)
Fetch spans	More flexibility in queries	Additional cost with queries. Works on captured traces (might not be 100% accurate)
Bizevents	Accurate - works with 100% of requests, regardless of sampling (yes some limits for very high volume services apply)	Technology must be supported for OneAgent bizevent capture. Additional cost with queries on raw bizevents using DQL - but can be eliminated by metrics from bizevents. Can't capture response time of the request - product idea.

[Butchi]

Got it thanks for the info. Unfortunately we don't DT have license for spans and have a need to capture response time for all service metrics. so it sounds like CSM is the only option. thank you all for your inputs.

[Julius_Loman · Accepted solution]

Yes, then you are most likely left with calculated service metric. 
Bizevents might be interesting approach too in your case - but it depends on the technologies used. 

[t_pawlak · Accepted solution]

You can’t directly use a Request Attribute as a filter in a metric query unless you’ve turned it into a dimension of a metric first.
Request Attributes are available as fields in trace/span data, so you can use them with fetch spans like this:

fetch spans
| filter service.name == "myService"
  and requestAttribute."source-id" == "XYZ"
| summarize count()

But i not recommended this option

In metric queries (timeseries), request attributes aren’t exposed by default as dimensions.
To filter by them in a metric query, you need to create a Calculated Service Metric (CSM) with the request attribute included as a dimension.
Then you can query time series data like this:

timeseries req = sum(m:calc:service.requests.by_source_id), by: {dt.entity.service, source_id}
| filter dt.entity.service == "SERVICE-XXXXXXXXXXXXXXX" and source_id == "XYZ"

[Butchi]

Thank you @Julius_Loman & @t_pawlak . We don't have a license for spans so CSM is the only option. will try your time series query using CSM, thanks for your help and really appreciated.