question

Josep C. avatar image
Josep C. asked ·

Merge services via API

Hi all,

we want to merge several atomatic detected services via the new Dynatrace API - Service detection rules API into one single service.

We've several Tomcat services with the same context-path and the same Web application ID but with different Web Server Name.

With this scenario Dynatrace detects one service for each web server name:

How can I, via API, tell Dynatrace to not use the Web Server Name in the service detection (only use the context-path and the Web application ID) to merge all the default detected services in one service?

Was this possible? How can we do that?

Regards, Josep Maria

configurationjavaapplication monitoring
1.jpg (58.5 KiB)
2.jpg (81.2 KiB)
10 |2000000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 50.0 MiB each and 250.0 MiB total.

1 Answer

Julius L. avatar image
Julius L. answered ·

This is a perfect use case for the service detection API.

With the API you can create a rule that will modify the detected service properties (Web Application ID / Context Root or Web Server Name) and you can specify the scope of the rule.
The modifications are either an override with a static value or some sort of extraction / modification of the detected value. You cannot push an extracted value from one property to another - for example use part of application id for context root.

First I recommend to read two blog posts regarding this feature by @Michael K.:
https://www.dynatrace.com/news/blog/new-dynatrace-api-enhances-automatic-service-detection/
https://www.dynatrace.com/news/blog/new-dynatrace-api-enhances-automatic-service-detection-part-2/

See the following simple example in one of our customer's cases - this example sets the server name to the values up to first character "m" for each web request service where the server name starts with xxx01. Other service properties - Context Root and Application ID are left untouched in this example. I believe this is almost exactly your case.

{
  "type": "FULL_WEB_REQUEST",
  "metadata": {
    "configurationVersions": [
      0
    ],
    "clusterVersion": "1.188.88.20200313-114149"
  },
  "managementZones": [],
  "name": "XXX Merge",
  "description": "XXX Merge Rule\n",
  "enabled": true,
  "conditions": [
    {
      "attributeType": "SERVER_NAME",
      "compareOperations": [
        {
          "type": "STARTS_WITH",
          "negate": false,
          "ignoreCase": true,
          "values": [
            "xxx01"
          ]
        }
      ]
    }
  ],
  "applicationId": null,
  "contextRoot": null,
  "serverName": {
    "transformations": [
      {
        "type": "BEFORE",
        "delimiter": "m"
      }
    ],
    "valueOverride": null
  }
}


There are several properties you can use. Without exactly knowing your environment and how your services have been automatically detected, it is difficult to suggest a rule.

Please see the docs for all options:
https://www.dynatrace.com/support/help/dynatrace-api/configuration-api/service-api/detection-rules/

I agree this is complex, the docs are lacking some details such as all possible attributes for operations. And more examples will be definitely appreciated by the community :-).

Cheers
Julius

4 comments Share
10 |2000000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 50.0 MiB each and 250.0 MiB total.

I believe in your case you will probably want to just override the server name value. So it will likely look like this. You may want to add some additional conditions for the scope of this rule :

{
  "type": "FULL_WEB_REQUEST",
  "metadata": {
    "configurationVersions": [
      0
    ],
    "clusterVersion": "1.188.88.20200313-114149"
  },
  "managementZones": [],
  "name": "ZUUL Merge",
  "description": "ZUUL Merge Rule\n",
  "enabled": true,
  "conditions": [
    {
      "attributeType": "APPLICATION_ID",
      "compareOperations": [
        {
          "type": "EQUALS",
          "negate": false,
          "ignoreCase": true,
          "values": [
            "ZUUL"
          ]
        }
      ]
    }
  ],
  "applicationId": null,
  "contextRoot": null,
  "serverName": {
    "valueOverride": "ZUUL server"
  }
}
2 Likes 2 · ·

Hi @Julius L.,

thanks for your response!!! one more question, If we've one rule like this and we monitor other zuul processes, the serverName for these new monitored processes will be ZUUL server and these newservices will be merged with the existing ones, rigth?

So, with this approach the maintenance will be lower.

Regards! Josep Maria

1 Like 1 · ·

Hi @Josep Maria C.,

for the full web request, the services will be merged only within a process group. So if you have your process groups correctly, the rule will apply automatically. So if the processes have different process groups, the services will not merge. If the newly added server falls into the same process group, the service will be automatically merged.

This is exactly why I prefer these rules over existing merge service functionality which is static. Typically you don't have to worry about any maintenance when scaling your applications.

Cheers
Julius

0 Likes 0 · ·

Hi @Julius L.,

thanks for your quick and accurate responses! All clear and all applied :-)

Regards, Josep Maria

1 Like 1 · ·

Space Topics

mobile monitoring dotnet synthetic monitoring reports iis chat kubernetes servicenow amazon web services mysql mainframe rest api errors cassandra dashboard oneagent sdk cmc application monitoring openkit smartscape request attributes monitoring developer community user tagging log monitoring services ufo syntheticadvisory activegate ip addresses auto-detection high five award oracle hyperion webserver uem usql iib test automation license web performance monitoring ios news migration management zones index ibm mq web services custom event alerts notifications sso host monitoring knowledge sharing reports browser monitors java hybris sap vmware maintenance window user action naming javascript appmon ai synthetic classic availability tipstricks automation extensions session replay diagnostic tools permissions davis assistant faq documentation problem detection http monitors server easytravel apdex aws-quickstart network docker tags and metadata cloud foundry google cloud platform synthetic monitoring process groups account usability dynatrace saas gui paas openshift key user actions administration user actions postgresql synthetic locations oneagent security Dynatrace Managed user management custom python technologies mongodb openstack user session monitoring continuous delivery citrix configuration alerting NGINX action naming linux nam installation masking error reporting database mission control jmeter recorder apache mobileapp RUM php threshold azure purepath davis scripting agent aix nodejs android