Dynatrace Service Graph Connector

[Anne Marie Duff]

How do I configure the Dynatrace Service Graph Connector?

Current Version: 1.9

Sample Application Service to Monitor: MediaWiki

URL: http://10.197.203.200:5000/mediawiki

Ingesting Dynatrace Events(Yes\No): Yes

A 2-Tier PHP-based Web Application running on a 5 VM Node configuration in our Crucible Lab Environment will be used to demonstrate the Dynatrace Observability Service Graph Connector.

Environment:

HAProxy Load Balancer (ardeilmwdthap01) routes Web Requests to an Apache Web Server Cluster (ardeilmwdtapp01, ardeilmwdtapp02, ardeilmwdtapp03) that has the MediaWiki Application installed and running. The MediaWiki (PHP) Application in turn routes DB Requests to a MySQL Server DB (ardeilmwdtdb01) as depicted in the top-down discovered Application Service Map below.

This MediaWiki Application is being monitored by the Dynatrace SaaS cloud-based solution, where all application-component data with respect to the application is stored.

The following topics are covered in this How do I configure the Dynatrace Service Graph Connector? Article:

A. Set up Application to be monitored in Dynatrace Cloud

B. Analyze your Application in Dynatrace Cloud

C. Installing & Configuring Dynatrace Service Graph Connector on your ServiceNow Instance

D. Run Dynatrace Service Graph Connector Scheduled Data Import Jobs on your ServiceNow Instance

E. Analyze the Application Service Map created by the Dynatrace Service Graph Connector for your Application in your ServiceNow Instance

F. Analyze the CMDB Records created\updated by the Dynatrace Service Graph Connector for your Application in your ServiceNow Instance

G. Event Management

A. Set up Application to be monitored in Dynatrace Cloud

(i) Log into your company's Dynatrace Cloud Instance

(ii) Install Dynatrace OneAgent on VM's containing Application components to be monitored, e.g. MediaWiki - Install OneAgent on Linux

• • Navigate to Deploy Dynatrace under Manage in the Filter Menu
• Click on Start Installation
• Select the Platform that your Application components run on, e.g. Linux
• Enter a PaaS Token, e.g. 'Crucible Lab' (Under Access Tokens)
• Follow the Steps on the Installer Page (Shown when PaaS Token supplied) to install Dynatrace OneAgent on the VM's containing the Application to be monitored, e.g. MediaWiki
• Restart the Processes to be monitored, e.g. Apache Web Server, HAProxy Load Balancer, MySQL Server

(iii) Create Application Detection Rule for Application in Dynatrace - Define applications for Real User Monitoring 

• Navigate to Application detection under Manage, Settings, Web & mobile monitoring in the Filter Menu
• Click Add Item to add an Application detection Rule for your Application component, e.g. 'URL Contains' 'http://10.197.203.200:5000/mediawiki'
• Click on the Create a New Application button to create an Application Name to associate with your Application in the Dynatrace Cloud environment, e.g. MediaWiki

(iv) Setup RUM Injection method for Application - RUM JavaScript Injection

• Navigate to Front End under Application Observability in the Filter Menu
• Select the Application Name that you created in step (iii) e.g. MediaWiki
• Click on the Context Menu(...) button on the Top Right of the screen and then select Edit from the Menu Pulldown to bring up the Application Settings Filter Menu
• Navigate to Injection under Injection in the Filter Menu
• Select the inline code format under Automatic Injection- Enables Automatic Injection of RUM Javascript Code Snippet into your Application HTML. (Needed for tying your Application URL Entry Point to the next Underlying Process e.g. HAProxy Load Balancer)

B. Analyze your Application in Dynatrace Cloud

(i) Send some Network Traffic through your Application. e.g. For our MediaWiki Application we hit the http://10.197.203.200:5000/mediawiki MediaWiki Web App URL and sent various Web Requests through the Application Home Page (by clicking on different links on the page)

(ii) Navigate to SmartScape topology in the Filter Menu of your Dynatrace Cloud Instance Portal

Application Layer

(i) Navigate to the Applications Layer

(ii) Select your Application from all the Applications displayed in the Right hand Pane by Hoovering over the Globe Icon displaying your Application Name and then clicking on this Globe Icon e.g. MediaWiki

(iii) If your Application has been setup for Monitoring correctly in Dynatrace Cloud and enough Network Traffic has been detected by Dynatrace for your Application you will see the following for your Application;

• Connection Lines between your Application e.g. MediaWiki in the Application Layer and the underlying Services that it calls in the Services Layer.
• Connection Lines between the Services in the Services Layer and the Processes underpinning these Services in the Processes Layer
• Connection Lines between the Processes in the Processes Layer and the Hosts that these Processes run on in the Hosts Layer
• The Data Center that these Hosts reside in in the Data Centers Layer

Below is an example of this for the MediaWiki Application in our Crucible Lab Environment.

Services Layer

(iv) Navigate to the Services Layer and select 1 of the Services shown for your Application e.g. ardeilmwdtapp02.ares.local Web Request Service. A Service Flow Topology for your Application will be shown in the Right Hand Pane with the Service that you selected highlighted in the Pane, e.g. ardeilmwdtapp02.ares.local Web Request Service as shown below. The full Service Topology is shown depicting how there are 3 Apache Web Servers, each providing an Apache Web Request Service that in turn gets routed to the PHP Application Web Request Service running on the Apache Web Server. All 3 PHP Application Web Request Services are shown calling on the same underlying MySQL Database Service.

Processes Layer

(v) Navigate to the Process Layer and select 1 of the Processes shown for your Application e.g. Apache Web Server httpd. A Process Flow Topology underpinning your Application Services will be displayed in the right hand pane with the Process that you selected highlighted as shown below. The full Process Topology supporting the application is shown depicting how there is a HAProxy process running that routes all Web Requests to an Apache Web Server httpd process which in turn calls on a MySQL Database Server Process when needed.

Note: The Apache Web Request Service and the PHP Application Web Request Service that the Apache Web Server httpd process supports are shown connecting to the Apache Web Server httpd process in the above Services Layer

(vi) Dynatrace groups related Processes into Process Groups. (Refer to the Dynatrace Process Group Process groups  documentation page for more information). To see the Process Group that each Process associated with your application belongs to do the following:

• Select 1 of the Processes shown for your Application e.g. Apache Web Server httpd and click on the Expand icon to the right of the Process Name, e.g. Apache Web Server httpd. You are brought to a Process Overview Screen showing your Process Details. The screen below shows the Process Overview screen for the Apache Web Server httpd on ardeilmwdtapp02.ares.local process associated with our MediaWiki Application:

• Select View Process Group from the Context Menu shown in the above screen shot. You are brought to a Process Group Overview screen showing Process Group details associated with the Process Group that your Process is associated with. The screen shot below shows the Process Group details associated with the Apache Web Server httpd Process Group that Dynatrace created for our MediaWiki Application. 

All 3 Apache Web Server httpd processes that run in our MediaWiki Apache Web Server Cluster (ardeilmwdtapp01, ardeilmwdtapp02, ardeilmwdtapp03 Linux Servers) are shown in the Process List on this screen, for example the Apache Web Server httpd on ardeilmwdtapp02.ares.local process whose Process Overview was shown in the above screen.

Note: To see all the Process Groups that Dynatrace creates for your environment navigate to Technology & Processes from the Filter Menu. You will be brought to screen showing all the Process Groups in your environment represented as Tiles. The screenshot below shows the Process Groups for our environment represented as Tiles. You will notice the Apache HTTP Server Process Group Tile.

In Dynatrace, it is possible to Tag all Dynatrace Entities. The screen shot below shows all Process Groups associated with our MediaWiki Application that have been Tagged with an 'Application' Tag Key and associated 'MediaWiki' Tag Key Value. (The relevance of Tagging in Dynatrace will be explained in more detail in the Filtering what gets ingested from Dynatrace into the ServiceNow CMDB Subsection of the C. Installing & Configuring Dynatrace Service Graph Connector on your ServiceNow Instance Section below).

Hosts Layer

(vii) Navigate to the Hosts Layer to see what host machine the processes run on as per the screen shot below. Each Apache Web Server http process running on its own host machine, e.g. Apache Web Server httpd process running on the ardeilmwdtapp02 Linux Server.

Data Center Layer

(viii) Navigate to the Data Center Layer to see what Data Center the Hosts are housed in as per the screen shot below.

C. Installing & Configuring Dynatrace Service Graph Connector on your ServiceNow Instance

(i) Login to your ServiceNow Instance

(ii) Install the following Applications & Plugins in the order shown:

Applications

1. *Observability Commons for CMDB: sn_observability
2. Integrations Commons for CMDB: sn_cmdb_int_util
3. CMDB CI Class Model: sn_cmdb_ci_class
4. ITOM Discovery License: com.snc.itom.discovery.license (Included with full Discovery Product)
5. Event Management: sn_em_ai (for enabling the capturing of events from Dynatrace)  
6. Service Graph Connector for Observability - Dynatrace: sn_dynatrace_integ

*Observability Commons for CMDB is required for ingesting Events from Dynatrace. It's important that it's installed before Service Graph Connector for Observability - Dynatrace. This is required in order for you to see the Create Default Notification Payload Template step in the Basic and Add Multiple Instances sections of Guided Setup. This step is explained in greater detail in the Event Management Section at the end of this Whitepaper.

Plugins

7. com.glide.hub.action_type.datastream Plugin (ServiceNow IntegrationHub Action Template - Data Stream) -  click on the  Request Plugin Button from the System Applications Screen

(iii) Navigate to Setup under Dynatrace Observability in the Filter Menu

(iv) Go through all Setup Steps as per the ServiceNow Documentation: Configure Service Graph Connector for Observability - Dynatrace

Specifying what Service Types to Ingest from Dynatrace

In Advanced Settings, Configure Instance Settings ensure to specify All Service Types that need to be ingested in the serviceTypes property listed in the Service Graph Connection Properties Tab of the Configure Instance Settings Screen. This Configure Instance Settings Screen is displayed when you click on the Configure Pushbutton to the right of the Configure Instance Settings subsection of the Advanced Section of Guided Setup. The below screenshot shows the Configure Instance Settings Screen with this serviceTypes Property:

In this serviceTypes Property field you need to specify all the Service Types that your Application relies on. i.e. The Service Types depicted for your Applications in the Services Layer of the Dynatrace Smart Scape Topology for your Application (Described in the 'Services'  Step (iv) in the 'Analyse your Application in Dynatrace Cloud' Section above). Out of the Box this serviceTypes property is populated with the WEB_SERVICE, CUSTOM_SERVICE and DATABASE_SERVICE Service Types.

For our sample MediaWiki Application we needed to add the WEB_REQUEST_SERVICE Service Type to this serviceTypes property because, as you can see in the screen shot in the Services Step (iv) in the 'Analyse your Application in Dynatrace Cloud' Section above, the MediaWiki Application has Web Request Services connecting to the underlying Apache Web Server Process. e.g. ardeilmwdtapp02.ares.local Web Request Service connecting to the Apache Web Server httpd process. The below screen shot shows the WEB_REQUEST_SERVICE Service Type (highlighted in yellow) being added to the Out of the Box WEB_SERVICE, CUSTOM_SERVICE and DATABASE_SERVICE Service Types already specified in the serviceTypes property.

Filtering what gets ingested from Dynatrace into the ServiceNow CMDB

You can use the tags property listed as one of the property fields in the Service Graph Connection Properties Tab of the Configure Instance Settings Screen to filter what Applications and associated Services, Processes and Hosts you want to ingest from Dynatrace into the ServiceNow CMDB. Only the Entities in Dynatrace containing the Tags that you specify in this field will be ingested with a cmdb_key_value record being created for each Entity in the Key Value [cmdb_key_value] table 

For example, we added an Application tag to the MediaWiki Application and its associated Services, Processes and Hosts in Dynatrace to ensure that only the MediaWiki Application and its associated Services, Processes and Hosts got ingested into the CMDB(The Dynatrace Cloud environment contains other Applications that we didn't want to ingest). The below screen shot shows the Application:MediaWiki Tag Key Value Pair (highlighted in yellow) being added to the tags Property.

A cmdb_key_value record was created in the Key Value [cmdb_key_value] table for the MediaWiki Application and all its associated entities as shown in the screen shot below.

D. Run Dynatrace Service Graph Connector Scheduled Data Import Jobs on your ServiceNow Instance

(i) Navigate to Scheduled Data Imports under Dynatrace Observability in the Filter Menu. 6 Scheduled Import Jobs should be listed as shown below

(ii) Open the SGO-Dynatrace Hosts Parent Scheduled job record and click on the Execute button

(iii) Navigate to Concurrent Import Sets in the Filter Menu.

- Wait for all 6 Scheduled Data Import jobs to finish

For each Scheduled Data Import Job, the following happens:

1. Payload Records are created in the appropriate Scheduled Data Import Staging Table with data that is loaded from the Scheduled Data Import Data Source.
2. These Payload Records are then passed to the Robust Import Set Transformer associated with the Scheduled Data Import Data Source which in turn Transforms their data as defined by the Robust Import Set Transformer Transform Definition (using the Robust Transform Engine(RTE) ).
3. Output Records from the Robust Import Set Transformer are then sent to the Identification & Reconciliation(IRE) Engine for processing.
4. The Identification & Reconcilation(IRE) Engine does the following with each Output Record:

1. It Creates\Updates the appropriate CI Record in the CMDB 
2. It Creates a Source Record with Key CI Record data like Source Native Key, Configuration Item and Target Table (CI Type) in the Sources[sys_object_source] Table so that these CI's can be quickly located at a later point when needed, like e.g. during Dynatrace Event Processing (described further down in the G. Event Management Section below).

E. Analyze the Application Service Map created by the Dynatrace Service Graph Connector for your Application in your ServiceNow Instance

(i) Navigate to Application Services under Service Mapping in the Filter Menu.

(ii) Click All to show All Application Service Types

You should see a Calculated Application Service for your Application with the following format: Application Name - APPLICATION-XXXXXXXXXX, e.g. MediaWiki - APPLICATION-A33AB241EDACC4B2 for the MediaWiki Calculated Application Service that was automatically generated at the end of the Scheduled Data Import.

(iii) Click on the View Map button to the right of your Calculated Application Service, e.g. MediaWiki - APPLICATION-A33AB241EDACC4B2 in the case of our MediaWiki Application

An Application Service Map Page should be displayed showing the Service Map for your Application. In the case of our MediaWiki Application the MediaWiki Application Service Map depicts 4 separate Entry Points (shown in the screen shot below), 1 for the Apache Web Server httpd Process Group representing all the Apache Web Server httpd processes that run in our Apache Web Server Cluster (described in the (vi) Process Groups step of the above Processes Layer Subsection) and 1 for each Apache Web Request Service that processes incoming Web Requests from the http://10.197.203.200:5000/mediawiki URL (hosted on the HAProxy Load Balancer).  

• Apache Web Server httpd - PROCESS_GROUP-9AA8EFDE2B906FE8 - APPLICATION-A33AB241EDACC4B2
• ardeilmwdtapp01.ares.local - SERVICE-F1F61414FBA29432
• ardeilmwdtapp02.ares.local - SERVICE-3083A71F82164258
• ardeilmwdtapp03.ares.local - SERVICE-979DF09F1DCECB2A

Note: A HAProxy Load Balancer Entry Point is not shown in this Service Map because Dynatrace does not Classify HAProxy Load Balancer as a Service but rather as a Process. i.e. The HAProxy process underpinning the Apache Web Request Service that it supports (shown in the screen shot in 'Processes' Step (v) in the 'Analyze your Application in Dynatrace Cloud' Section above)

(iv) For every Service associated with your Application in Dynatrace, a Calculated Application Service record  is created in the ServiceNow CMDB to represent that Service and uses the Service Name - SERVICE-XXXXXXXXXX naming convention for the Service Name. The screenshot below shows all the Service CI records that were created in the Calculated Application Service[cmdb_ci_service_calculated] table to represent the Services associated with the MediaWiki Application. These records were created at the end of the Dynatrace Service Graph Connection Scheduled Job Imports.

All the SERVICE type Calculated Application Services are represented as nested Contained Application Services in your Application's Service Map. e.g. MediaWiki - APPLICATION-A33AB241EDACC4B2.   The Root Application Service Map shows the Outermost Contained Application Service(s) with the Service Map for the  Services that it is dependent on being shown in a new Window when you select Show Contained Service in its Pull Down Menu.

For example, for the MediaWiki Application, below is a screen shot showing the Service Map for  the ardeilmwdtapp02.ares.local - SERVICE-3083A71F82164258 Service contained in the Outermost MediaWiki - APPLICATION-A33AB241EDACC4B2 Root Service Map (shown in the screen shot in step (iii) above) .

It shows the below 2 Entry Points:

• Apache Web Server httpd - PROCESS_GROUP-9AA8EFDE2B906FE8 - SERVICE-3083A71F82164258 

Apache Web Server httpd on ardeilmwdtapp02 process in the Apache Web Server httpd - PROCESS_GROUP-9AA8EFDE2B906FE8 Process Group

• PHP on ardeilmwdtapp02.ares.local - SERVICE-BEC89F4DA1D1D748

The screen shot below shows the Service Map for the PHP on ardeilmwdtapp02.ares.local - SERVICE-BEC89F4DA1D1D748 Service Contained within the Outermost ardeilmwdtapp02.ares.local - SERVICE-3083A71F82164258 Contained Service shown in the above Service Map.

It shows the below 2 Entry Points:

• Apache Web Server httpd - PROCESS_GROUP-9AA8EFDE2B906FE8 - SERVICE-BEC89F4DA1D1D748

Apache Web Server httpd running PHP on ardeilmwdtapp02 process in the Apache Web Server httpd - PROCESS_GROUP-9AA8EFDE2B906FE8 Process Group.

• wikidatabase

The Wikidatabase' Database that the PHP on ardeilmwdtapp02.ares.local - SERVICE-BEC89F4DA1D1D748 Service connects to. It is shown as running on the ardeilmwdtdb01 Linux Server.

The MySQL process that is associated with the MySQL - PROCESS_GROUP-36BAFEFE448A1CAD Process Group is also shown in the Service Map

F. Analyze the CMDB Records created\updated by the Dynatrace Service Graph Connector for your Application in your ServiceNow Instance

(i)    Navigate to cmdb_ci.list in the Filter Menu

(ii)   Group by Discovery Source

(iii)  Navigate to the SGO-Dynatrace Discovery Source and double click on its Discovery source:SGO-Dynatrace(n) link where n represents the Number of CMDB records(entities) Created\Updated by the Dynatrace Service Graph Connector.

Note: If you used the Tags field in the earlier Setup Step to limit what gets ingested to just entities associated with your Application then this number will represent what gets Created\Updated for your Application only.

--> All CMDB CI Records that were created\updated by the Dynatrace Service Graph Connector are listed. If you used Filtering for just your Application as described above, this will be the CMDB CI records for your Application only. 

(iv) Group By Class

A List of CMDB CI Records Created\Updated by the Dynatrace Service Graph Connector will be displayed grouped by Class. 

• All the Service entities associated with your Application in Dynatrace will be represented as Calculated Application Service Class Records
• All the Process entities associated with your Application in Dynatrace will be represented as Application Class Records in the Class List that is displayed

For Process entities that the Dynatrace Service Graph Connector found a Class Match for lower down the Application Class Hierarchy, these Process entities will be listed under that Class instead of the Application Class e.g. Apache Web Server

• All the Process Group entities associated with your Application in Dynatrace will be represented as Group Class Records in the Class List that is displayed

• All Host entities associated with your Application in Dynatrace will be represented as Computer Class Records in the Class List that is displayed.

1. For Host entities that the Dynatrace Service Graph Connector found a Class Match for lower down the Computer Class Hierarchy, these Host entities will be listed under that Class instead of the Computer Class e.g. Linux Server

2. All Entities that are in turn associated with these Computer Class records will shown in the Class List displayed, e.g. IP Address, Software

The screen shot below shows all of the Class Records displayed in this Class List for our MediaWiki Application.

Note: HAProxy Load Balancer is listed as an Application Class as oppose to a Calculated Application Service Class which is the reason why HAProxy Load Balancer is not shown in the MediaWiki Application Service Map described in the E. Analyze Service Map Section above.

G. Event Management

A Dynatrace Observability Push Connector is installed as part of the Service Graph Connector for Observability - Dynatrace installation in the Push Connectors[sn_em_connector_listener] Table on your Instance. This Listener connector listens for Event Messages from your Dynatrace Source. These Events are sent from Dynatrace to your ServiceNow Instance via the EM-Connector Inbound Event REST API using the format 

https://{Instance-name}.service-now.com/api/sn_em_connector/em/inbound_event?source=SGO-Dynatrace. The Listener connector parses the data from the Event Messages it receives and does the following:

1. Constructs a Source Native Key (SourceNativeKey) from the entityId value that it receives in the Event Message Payload.
2. Locates the CI associated with the Event by querying the Sources[sys_object_source] Table using this Source Native Key (Primary Key in the Sources[sys_object_source] Table).
3. Creates an Event Record and populates the Configuration Item(sys Id) and Configuration Item Type fields in the Event Record with the output from this query (Binds the CI to the Event).

These Events are then processed by the Event Management Module on your ServiceNow Instance with Alerts being generated for these Events.

Event Management Configuration

There is a Create Default Notification Payload Template step in Dynatrace Guided Setup that you need to follow to enable Dynatrace to push Dynatrace Events to your ServiceNow Instance. Clicking on the Problem Notification Setup pushbutton on this Configuration Page calls a Dynatrace API that in turn creates the following in your Dynatrace Cloud Instance;

• Alerting Profile for your ServiceNow Instance that can be used for setting up fine grained Alert Filtering Rules. Alerting Profile is created with the following format: ServiceNow Default Problem Notification - SN Instance Profile

• Problem Notification for your ServiceNow Instance that will be used by Dynatrace for pushing Events to your ServiceNow Instance by calling the ServiceNow Event Management API.

Problem Notification is created with the following format: ServiceNow Default Problem Notification - SN Instance Name (Custom Integration - Webhook URL, Alerting Profile: ServiceNow Default Problem Notification -SN Instance Name Profile). 

- SN Instance Name is the name of your ServiceNow Instance

- Webhook URL is the URL for the Dynatrace Observability Push Connector (referred to above) that Dynatrace will send your Application Events to i.e. https://{Instance-name}.service-now.com/api/sn_em_connector/em/inbound_event?source=SGO-Dynatrace

-  Alerting Profile is the Alerting Profile that was created for your ServiceNow Instance in the above bullet that is now being associated with the Problem Notification being created for your ServiceNow Instance.

Dynatrace is now enabled to push Events to your ServiceNow Instance. These Events then get processed by the Event Management Module in your ServiceNow Instance with Alerts being created as appropriate etc. These Alerts then get shown in the Dynatrace Calculated Service Map similarly to how Alerts from other Monitoring Tools(e.g. Agent Client Collector) get shown when you click on Monitor Service on the Service Map. The screen shot below shows a Critical Alert being displayed for the ardeilmwdtapp02 Linux Server(1 of the Apache Web Server nodes) on the  MediaWiki - APPLICATION-A33AB241EDACC4B2 Root Service Map.

[Community Alums]

Hi @Anne Marie Duff ,

Thankyou for this fantastically useful run-through, it is very much appreciated. The last time I used the Dynatrace connector was before it became an SG Connector, back in 2019 😀.

I have a question, though: Dynatrace counts the HAProxy as an application, but it isn't part of the MediaWiki Application Service. If the HAProxy were to fail and generate an Incident (via the Dynatrace Incident plugin for example), the Impacted Services/CIs related list would not show MediaWiki - is that correct?

Thanks,

Jason

[vaibhavbhatnaga]

Very helpful article

[Anne Marie Duff]

Hi Jason,

      Thank you for your positive feedback on this Whitepaper. Appreciated. Answer to your "Dynatrace counts the HAProxy as an application, but it isn't part of the MediaWiki Application Service. If the HAProxy were to fail and generate an Incident (via the Dynatrace Incident plugin for example), the Impacted Services/CIs related list would not show MediaWiki - is that correct?" question below:

1. The HAProxy Load Balancer Application is classified as a Process in the Process Layer in Dynatrace as shown in the Processes Layer subsection of the B. Analyze your Application in Dynatrace Cloud section of this Whitepaper. When it is ingested from Dynatrace into your ServiceNow CMDB, it is created as a CMDB Application Record, explained in section F. Analyze the CMDB Records created\updated by the Dynatrace Service Graph Connector for your Application in your ServiceNow Instance section of this Whitepaper.

In Dynatrace, it is not associated with a Top Level Dynatrace Service the same way as the other Processes are in this MediaWiki Application, e.g. the Apache Web Server httpd process as shown in the same Processes Layer Subsection. So to answer your question, if it were to fail, I believe that there would be no Services shown in the Impacted Services/CIs related list associated with the Alert that is generated due to it's failure. A workaround for this to ensure that failures associated with it get shown in the  impacted Services/CIs related list associated with it's Alerts is to do the following:

(i) Tag it in Dynatrace with your Application Name, probably best to Tag all associated Application Services, Processes with the same Tag etc.

(ii) Manually create a Tag Based Application Service with the same Name in your ServiceNow Instance

--> Doing this means that an entry for the HAProxy Configuration Item that get's populated in your CMDB will have a Service associated with it in your Service Configuration Item Associations[svc_ci_assoc_list] Table. The Impacted Services/CIs related list Tab pulls it's records from this Table.

Note: There is a known issue with some Dynatrace Services being missing from the Impacted Services/CIs related list associated with Alerts coming from Dynatrace. This will be fixed in a future family release. It is related to a missing Group Rule and it's associated Identifier Entry from the CMDB CI Class Models  application that is shipped with the Family Release. In the meantime you can follow the steps below to implement the Fix in your own instance:

1. Create an Independent Group Rule in the CI Class Manager

2. Create a Name Identifier Entry for this new Group Rule giving it a Priority of 100.

Hoping this helps,

Thanks,

Anne-Marie

[Community Alums]

Hi @Anne Marie Duff ,

Thanks for this solution, and thanks for also telling me about a problem I didn't know that I had yet :-).

Your suggestion has led me to another question, though:

If I were to create a Tag Based Application Service, this sounds like I'd end up with duplicate Application Services - or rather, one Calculated Application Service created by the Dynatrace connector and containing CIs except processes / applications, and one Tag-Based Application Service containing everything I'd tagged with the same Application (Service) name. I think that this could get confusing and a bit messy to manage.

I'm wondering if it would be easier to add the HAProxy application to the existing Dynatrace-created Calculated Application Service. The correct relationships could be added. I thinking that the Dynatrace connector could wipe out any changes to the App Service, as it refreshes the 'map' though.

What are your thoughts? Is there a simple/clean solution? Maybe just use tag-based maps (if dependency isn't a requirement), and abandon the Dynatrace maps (set them to non-operational).

Thanks,

Jason

[Anne Marie Duff]

Hi Jason,

I take your point about there being 2 separate Calculated Application Service and a Tag-based Application Services to manage. There is a way to Merge the Tag-based Application Service with the Calculated Application Service by using an Asynch Business Rule on the Key Value Table that would add the Tag-based Application Service to the Parent Calculated Application Service but this could be confusing and difficult to manage.

I think your suggestion to manually add the HAProxy application to the already existing Calculated Application service is an easier and cleaner approach. The Dynatrace Service Graph Connector should not wipe out the change you make to the Application Service. I just tested adding the HAProxy Application to the Calculated Application Service on my instance and then running the Dynatrace Service Graph Connector Import Job immediately after. The Service Map with the newly added HAProxy Application was left intact.

Just to note, in order to add an Entry Point to a Calculated Application Service, you need to do the following:

1. Elevate your role to security_admin

2. Open the Calculated Application Service and click on the Convert to Manual Service Related Link (only available from the security_admin role) to convert it to a Manual Service (can only add Entry Points to Manual Services)

3. Add the HAProxy Application Entry Point

4. Click on the Convert to Dynamic Service Related Link (only available from the security_admin role) to convert it back to being a Dynamic Service 

5. Click on the View Map button to confirm that the new HAProxy Application Entry point is shown in the Service Map

Any Alerts associated with the HAProxy Application should now be shown in the updated Calculated Application Service Map. I tested this in my own instance where I manually created an Event for the HAProxy node. The HAProxy Icon in the Service Map was shown as Red with the associated Alert (generated from the Event) being shown in the Alerts Tab.

Hoping this helps,

Thanks,

Anne-Marie

[Anne Marie Duff]

Hi Jason,

I want to correct the method I outlined in my previous comment for adding an Entry Point to a Calculated Application Service. I have since learnt that the Convert to Manual Service Related Link is not available to the security_admin Role. With that in mind I am recommending the method described below for adding an Entry Point to a Calculated Application Service.

1. Navigate to the Calculated Application Services[cmdb_ci_service_calculated] Table

2. Open your Calculated Application Service and navigate down to the Related Items section of the form

3. Click on the Gear icon to bring up the Settings Dialog Box.

4. Change the Filter Relations by Max Level to 1 (Entry points are at Level 1)

5. Click on the Add CI Relationships + Icon to bring up the Relationship Editor for your Calculated Application Service

6. Select the Depends on (Parent) Relationship Type from the Suggested relationship types List

7. Set the Filter to Class is a HAProxy Load Balancer and click on Run Filter

8. Select the HAProxy Load Balancer CI that you want to add from the HAProxy Load Balancer CI List that is displayed

9. Navigate down to the Relationships section of the Relationships Editor

10. Click on the + Icon to add the new Depends on (Parent) Relationship with the Calculated Application Service being the Parent and the HAProxy Load Balancer CI you selected in Step 8. being the Child. 

- You should see the new Depends on (Parent) Relationship Record added to the Relationships list highlighted in Green

11. Click on the Save and Exit button to go back to the Calculated Application Service Form

12. Click on the View Map button to confirm that the new HAProxy Application Entry point is shown in the Service Map

[PierreG28451806]

The step by step configuration with Dynatrace is spectacular.
I am trying to carry out some very similar tests, for these tests I have created an account as Developer and I already have an Instance.

But I don't see the Plugins to install or activate them, does anyone know if it is possible to do it with a Developer account, or is there any other way to test this connection with Dynatrace?

[Community Alums]

@PierreG28451806 the plugin is called sn_dynatrace_integ (or just search for Dynatrace).

There is no reason that you shouldn't be able to do this. I have installed it on my PDI, just now.

Please mark as helpful, if this helped - thanks.

[Andrew G1]

Excellent white paper !

Just curious why both Applications and Services in Dynatrace are mapped to the SAME Ci Class in Servicenow (ie Calculated Services table cmdb_ci_service_calculated). Is it possible (without breaking the SG logic) to use a different CI Class extended from Calculated Services (eg Dynatrace Services cmdb_ci_service_dynatrace) so we can easily separate the top level applications from the sub-services that make up components of the service? 

[Anne Marie Duff]

Hi Jason,

    Thank you for your positive feedback. Unfortunately this is not possible with the OOTB Dynatrace Service Graph Connector. But what I recommend that you do is submit your above ask as an Enhancement Request in the ServiceNow Idea Portal: Idea Portal on Now Support . The ideas in this Portal are reviewed regularly by the Development Team. It will also allow other customers with a similar ask to Vote on your Enhancement Request.

Hoping this helps,

Thanks,

Anne-Marie

[Craig_Sellin]

Excellent article well done.

Just asking why the MAC Address and Serial Number attributes are not imported? I have confirmed that MAC Address exists within the payload from Dynatrace and is somewhat enriched with other data, but I am not seeing this in ETL transform maps.

Considering both MAC Address and Serial Number are valuable attributes for IRE lookups, this would assist with a more robust CI identification rather than relying just on Name attribute (Hardware rule).

[Manmohan Verma]

Is there a way that we can still use the V1 instead of V2. I tried finding "Service Graph Connector for Dynatrace". I am unable to find the plugin on the store or plugin list. I only get "Service Graph Connector for Observability - Dynatrace". Has the v1 already been deprecated?

[Community Alums]

@Manmohan Verma V1 isn't available any longer, only the SG Connector for Observability - Dynatrace is available.

Please mark as helpful, if this helped.

Thanks,

Jason

[marcguegueniat]

Hello,

Thanks for the article, I have a question regarding the Event Management part.

I installed SGO dynatrace on a PDI and:

- there was no new push connector (sn_em_connector_listener_list.do).

- I wasn't able to do a unit test using REST API Explorer on the /api/sn_em_connector/em/inbound_event. It says the source SGO-Dynatrace does not exist.

Am I missing something ?

I also noted that there already a Dynatrace Push connector that is installed with plugin "Event Management Connectors" (but it has a different source: "dynatrace").

Are they related?

Reagrds,

[Chris354]

Idea posted to use more Identifier rules for the Dynatrace Service Graph Connector than just the host name.

https://support.servicenow.com/now?id=view_idea&sysparm_idea_id=256ce26747da3190b7832920326d4350&sys...

[Anne Marie Duff]

Hi Marc,

The screenshot below shows the full name of the Dynatrace Observability Push Connector that you should expect to see in the Push Connectors[sn_em_connector_listener] Table table:

Note: It show's SGO-Dynatrace as Source as oppose to Dynatrace for the Dynatrace Monitor Push Connector that was installed as part of the Event Management Application (as you point out).

Regarding you not being able to see this SGO-Dynatrace Push Connector in the Push Connectors[sn_em_connector_listener] Table, a common reason for this happening is that the *Observability Commons for CMDB: sn_observability Framework called out in Step 1 of the C. Installing & Configuring Dynatrace Service Graph Connector on your ServiceNow Instance section above was not installed before the Dynatrace Service Graph Connector.

If this Observability Commons for CMDB: sn_observability Framework has not been installed, you can still install it after the Dynatrace Service Graph Connector installation where you run Repair on the Dynatrace Service Graph Connector install to resolve any missing ServiceNow Table entries

Hoping this helps,

Thanks,

Anne-Marie

[marcguegueniat]

Hi Anne-Marie,

Thanks for the previous answer, I've been able to repair.

I have digged into the behavior of Dynatrace Observability Push Connector.

I was wondering why you had to rebuild one and why it differs from Dynatrace Monitor Push Connector.

Your connector seems better because it extracts events from the Dynatrace Problem and uses the ProblemId to correlate events in the same ServiceNow Alert.

Did you consider reusing the existing Dynatrace Monitor Push Connector when building this ? why not reuse it?

Regards,

[Ganeshm1]

Hi @Anne Marie Duff 

Thank you for this great article. 

Currently we are planning to use SGO-Dynatrace for only event management. Is there any way we can connect two different Dynatrace application to one ServiceNow instance?
Could you please help me by providing some suggestion on this? Thank You!

Best Regards,
Ganesh

[Anne Marie Duff]

Hi Ganesh,

Yes, you can use the Multi Instance Feature available in the Service Graph Connector for Observability - Dynatrace Guided Setup to create a new Connection to your 2nd Dynatrace Instance. Please refer to this Configure Service Graph Connector for Observability - Dynatrace ServiceNow Documentation Page for more details on this Multi Instance Feature.

Basically you will be creating a new Connection to your 2nd Dynatrace Instance with an accompanying set of Scheduled Imports + Data Sources   

Hoping this helps,

Thanks,

Anne-Marie

[Ganeshm1]

@Anne Marie Duff : We were able to establish the connection from two different dynatrace instances. 
Source is showing as SGO-Dynatrace for both. Is this expected? is there any way we can change it or how we can identify which event is from which dynatrace instance. 

Your input will help me a lot here. Please let me know your thoughts on this. 

Best Regards,
Ganesh

[Anne Marie Duff]

Hi Ganesh,

It is not possible to change the value for Source from 'SGO-Dynatrace' to show the Dynatrace Instance a Dynatrace Event is coming from but you can identify what Dynatrace Instance a Dynatrace Event is coming from by examining the 'ConnectionId' parameter in the 'Additional Information' section of the Event Payload.

The 'ConnectionId' Parameter indicates which Dynatrace Instance the Event came from. There is a unique 'ConnectionId' associated with each different Dynatrace Instance the Dynatrace Service Graph Connector is connecting to.

[B Wetzstein]

@Anne Marie Duff is it possible to load a visual representation of the schema map between SNOW CMDB and Dynatrace? This will help with stakeholder alignment in pre-implementation phase of SG-Dyna to CMDB. These two tools see and represent the data center environment in very different ways and its easier to show how we can talk in the same language.

[Dan Aragon]

Totally agree with the comment above.