How  do I configure the Dynatrace Service Graph Connector using SGC Central with a Focus on Service Maps

 

Version : 1.16

Sample Application Service to Monitor:  MediaWiki

URL:  http://10.197.203.200:5000/mediawiki

Dynatrace Back End Environment:  Dynatrace Classic - Dynatrace Managed (self‑hosted) or legacy Dynatrace SaaS environments which support (v1/v2 APIs) 

Ingesting Dynatrace Events(Yes\No): Yes

Filtering Applied(Yes\No): Yes

 

The focus of this Article is on analyzing the data brought in by the Dynatrace Service Graph Connector for a particular Sample Application , in our case the MediaWiki Application, where only Dynatrace Entities associated with this Sample Application in Dynatrace will have corresponding Target CI's created for them in the CMDB. Ingesting only this subset of Sample Application specific data from Dynatrace will be achieved by means of Filtering via the use of the Tags Connection Property.

 

Time will be spent analyzing the Service Maps that are created for this Sample MediaWiki Application which is a 2-Tier PHP-based Web Application running on a 5 VM Node configuration in our Crucible Lab Environment.

 

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 using SGC Central with a Focus on Service Maps?  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 the SGC Central Tab in the CMDB Workspace

(iv) Go through all  SGC Central  Steps for creating a New Dynatrace Classic Connection  and associated Scheduled Imports as outlined in the ServiceNow Documentation: Configure Service Graph Connector for Observability - Dynatrace using SGC Central 

 

Create and Test Connection step

 

(i) Navigate to the Create and Test Connection step listed in the Left Hand Navigator of Setup to bring up the below screen:

 

 

Connection name: Provide a  Name  that will allow you to easily identity the  Dynatrace Tenant  that you are connecting to, e.g. USA. 

 

Hostname: This Name will be used as part of the naming convention for the newly created  Customer Specific Data Sources & Import Sets  as per below.

 

| Customer Specific Data Sources | Data Source Name - Connection Name |
| Customer Specific Scheduled Import Jobs | Import Job Name - Connection Name |

 

API Key: Enter " api-token API Key" where _ API Key _ is replaced with the  API Key associated with the  Customer specific Dynatrace Tenant that you are connecting to.

 

(ii) Click on the  Continue Pushbutton

 

• A new  Child   Connection & Credential Alias Record is created with the Credential Details  specified. This  Child   Connection & Credential Alias  Record is associated with the OOTB Parent Dynatrace Connection Connection & Credential Alias  Record as shown in the below screen shot. We specified  USA  for our example so  USA  is shown as the  Child Connection & Credential Alias  below.

 

 

• A new set of  Customer specific Data Sources and Scheduled Imports  are created that contain the  Connection Name  specified in the  Create and test Connection Screen. An example of the  Customer specific Data Sources and Scheduled Imports  that get created is shown below, where  USA  was used to identify our Customer specific Schedule Imports and Data Sources:

 

 

• A Service Graph Connection[sn_cmdb_int_util_service_graph_connection] Record is created that encapsulates the  Properties ,  Data Sources  and  Scheduled Data Import  Jobs associated with the newly created Child Alias Connection & Credential Record. The screenshot below shows the Service Graph Connection[sn_cmdb_int_util_service_graph_connection] Record that was created for our  USA   Child Alias Connection & Credential Record:

 

 

Note: We will be updating the serviceTypes and tags Properties in the next step.

 

Set Connection Properties  step

 

In this step you will be setting the Properties associated with the Service Graph Connection[sn_cmdb_int_util_service_graph_connection] Record that was created in the previous step. In particular, you will be setting the below properties:

 

• serviceTypes

Specifies what Service Types to Ingest from Dynatrace

 

• tags

Specifies what Dynatrace Tags to use for filtering what Applications and associated Services, Processes and Hosts you want to ingest from Dynatrace into the ServiceNow CMDB.

 

(i) Navigate to the Set connection properties Step (Y_ou are automatically brought to this step when you click Continue in the previous  Create and Test Connection step_) to bring up the below screen:

 

 

Service types: 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  field 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  Field 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.

 

tags: Specify what Dynatrace Tag to use for filtering what Applications and associated Services, Processes and Hosts you want to ingest from Dynatrace into the ServiceNow CMDB.

 

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).

 

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 Calculated Service Type and Host Type Entity in the Key Value [cmdb_key_value] table 

 

The below screen shot shows the  cmdb_key_value  records that were created in the Key Value [cmdb_key_value] table for the  Linux Server & Calculated Application Service entities associated with our  MediaWiki Application

 

 

(ii) Click on the Save Pushbutton to save the updated Service Types and Tags Properties in the Service Graph Connection[sn_cmdb_int_util_service_graph_connection] Record. The below screenshot shows our USA Service Graph Connection Record with the serviceTypes and tags Properties after they were updated with the values specified for these fields in the Set Connection Properties Screen

 

 

The below screenshot shows the serviceTypes Property with the WEB_REQUEST_SERVICE Service Type(highlighted in yellow) being added.

 

 

The below screen shot shows the  Application:MediaWiki  Tag Key Value Pair (highlighted in yellow) being added to the  tags  Property.

 

 

Configure Import Schedule  step

 

Dynatrace Service Graph Connector  Scheduled Import Jobs will be run at the interval you specify to ingest data from the  Dynatrace Tenant  that the  Dynatrace**  Service Graph Connector** connects to. The CMDB database on your ServiceNow Instance will be populated with this ingested data.

 

The  Dynatrace**  Service Graph Connector  comes with  37  Out of the Box  Data Source  and  Scheduled Data Import Templates. These Templates were used for creating your own  Customer Specific Data Sources and Scheduled Data Imports  in the previous  Create and Test Connection** step. Please refer to this ServiceNow

Data mapping for Service Graph Connector for Observability - Dynatrace Documentation page for more details on these Schedule Import Jobs.

 

(i) Navigate to the Configure import Schedule  step listed in the Left Hand Navigator of Setup to bring up the below screen:

 

 

(ii) Turn on the Parent  SGO-Dynatrace Hosts - Connection Name  Scheduled Import job by changing it's Active Field from false to true, in our case the  SGO-Dynatrace Hosts - USA Scheduled Import job.

(iii) The  SGO-Dynatrace Hosts  job is set to run Daily  by default. Specify at what  Repeat Intervals  that you want this Job to run. 

 

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. 37 Scheduled Import Jobs should be listed containing the Connection Name that you specified in the  Create and Test Connection step in the previous  C. Installing & Configuring Dynatrace Service Graph Connector on your ServiceNow Instance Section. The below screenshot shows our 37 USA Scheduled Import Jobs:

 

(ii) Open the  SGO-Dynatrace Hosts - Connection Name  Parent Scheduled job record, in our case the  SGO-Dynatrace Hosts - USA  Parent Scheduled job record, and click on the  Execute  button

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

• Wait for all 37 Scheduled Data Import jobs to finish

 

For each  Scheduled Data Import  Job, the following happens:

 

1. Payload Records  are created in the appropriate  Scheduled Import Staging Table  with data that is loaded from the  Scheduled Import Data Source.
2. These  Payload Records  are then passed to the  Robust Import Set Transformer  associated with the  Scheduled 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* :

5. It  Creates\Updates  the appropriate CI Record in the CMDB 

6. 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 Event Management  in the Filter Menu.

 

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 jobs run.

 

(ii) Open your Application Calculated Application Service Record e.g.  MediaWiki - APPLICATION-A33AB241EDACC4B2 Record and click on the Open in Workspace Pushbutton on the Record to open the Record in the SGC Central Tab in CMDB Workspace.

(iii) Click on the Open Map Pushbutton on the SGC Central Record Form that is displayed to bring up the Unified Service Map for your Application Calculated Application Service Record

 

Top Level Application Unified Service Map

 

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 (s_hown in the screen shot in ' Processes' Step (v) in the 'Analyze your Application in Dynatrace Cloud' Section above_)

 

2nd Level Service Unified Service Map

 

(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  Application Services  in your Application's Service Map. e.g.  MediaWiki - APPLICATION-A33AB241EDACC4B2. The Root Application Service Map shows the Outermost Application Service(s), with the Service Map for the Services that it is dependent on being shown in a new Window when you select Set as Home Node  in its Pull Down Menu of a particular Service Node on the Root Application Service Map.

 

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 FPM pool www - SERVICE-BB21D8E43D3422E6

- PHP on FPM Web Request Service  running on the  ardeilmwdtapp02 ** Apache Web Server** (i.e. Apache Server @ardeilmdtapp02 )

 

 

3rd Level Service Unified Service Map

 

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  Service shown in the above Service Map.

 

It shows the below 2 Entry Points:

 

•   PHP-FPM - PROCESS_GROUP-59872C7073844C3E - SERVICE-BB21D8E43D3422E6

- PHP-FPM on ardeilmwdtapp02  process in the  PHP-FPM - PROCESS_GROUP-59872C7073844C3E  Process Group which in turn runs on the  ardeilmwdtapp02 Linux Server.

 

• wikidatabase - SERVICE-5D36DF985035B592

• The  Wikidatabase'  Database  Service that the  PHP on ardeilmwdtapp02.ares.local - SERVICE-BEC89F4DA1D1D748  Service connects to which in turn runs on the  ardeilmwdtdb01 Linux Server.

 

 

 

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.

 

--> All CMDB CI Records that were created\updated by the  Dynatrace Service Graph Connector  are listed. If you used Filtering (by updating the tags Property as described in the  _Set Connection Properties  step in the previous __ C. Installing & Configuring Dynatrace Service Graph Connector on your ServiceNow Instance Section_) for just your Application 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  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 a HAProxy Load Balancer**  Class (_Child Class ofApplication*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  Configure Observability  step in  Dynatrace SGC Central Setup that you need to follow to enable Dynatrace to push Dynatrace Events to your ServiceNow Instance. This step is shown in the below screenshot:

 

 

Clicking on the Create problem notification Pushbutton on this screen 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.  A** lerting 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

 

- _ W __ ebhook 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 on the Service Map. To see if your Application Service Map has any associated Alerts to the following:

 

(i)    Navigate to the Services Operations Workspace

(ii)   Navigate to the Services Dashboard Tab in this Workspace 

• All your Services will be displayed on the Screen as Tiles with associated Green, Yellow, Red Colors to indicate the severity of associated Alerts if any. The below screenshot shows the 8 Services associated with our MediaWiki Application with the below 3 Services being displayed in Red to indicate that Critical Alerts are associated with them:

• MediaWiki - APPLICATION-A33AB241EDACC4B2

• ardeilmwdtapp02.ares.local - SERVICE-3083A71F82164258

• PHP on FPM pool www - SERVICE-BB21D8E43D3422E6

 

 

(iii) If you see any Service Tiles being displayed in Red, Click on it to bring up the associated Service Overview Screen. The below screenshot shows the Service Overview Screen for our  MediaWiki - APPLICATION-A33AB241EDACC4B2 Service

 

(iv) Click on the Service Map Pushbutton on the Service Overview Screen to bring up the Unified Service Map associated with the Service that is being displayed in Red.

The screen shot below shows our  MediaWiki - APPLICATION-A33AB241EDACC4B2  Root Unified Service Map with the Root  MediaWiki - APPLICATION-A33AB241EDACC4B2 Node being displayed in Red along with the Nodes that it depend on i.e. the  ardeilmwdtapp02.ares.local - SERVICE-3083A71F82164258 Service Node ,  Apache Server @@ardeilmdtapp02  Web Server Node and the  ardeilmdtapp02 Linux Server Node.

 

 

(v) Click on the   icon displayed at the top of the Screen to display the Alert associated with Service being displayed in Red. The below screenshot shows the Critical Alert being displayed for the  ardeilmwdtapp02**  Linux Server (1 of the Linux Server nodes) on the MediaWiki - APPLICATION-A33AB241EDACC4B2 **Root Service Map.