Page tree
Skip to end of metadata
Go to start of metadata

 

Overview

Dynatrace AppMon provides deep application monitoring and performance lifecycle management. The Dynatrace APM LAM connects with Dynatrace AppMon and fetches incidents from it, the fetched incidents are then forwarded to Moogsoft AIOps.

Process Overview

 

  1. LAM reads the configuration from the dynatrace_apm_lam.conf file.
  2. LAM will connect with Dynatrace APM REST API with given host name.
  3. The response is received with event data in json format.
  4. Dynatrace_APM_ LAM has an option to filter event data based on the set filters, if filters are set, then the events are fetched based on the defined filters in the config file.
  5. The events are parsed and converted into normalized Moogsoft AIOps events.
  6. The normalized events are then published to MooMS bus.

Dynatrace APM LAM Configuration

The alarms received from Dynatrace AppMon are processed according to the configurations in the dynatrace_apm_lam.conf file. The processed alarms are published to Moogsoft AIOps.

The configuration file contains a JSON object. At the first layer of the object, the LAM has a parameter called config, and the object that follows config has all the necessary information to control the LAM.

The following sections are available for configuration in the Dynatrace APM LAM configuration file.

Monitor

The Dynatrace APM LAM takes the incidents from Dynatrace AppMon. The user can configure the parameters here to establish a connection with Dynatrace AppMon.

    config :
    {

        monitor:
        {
            name                    		  : "DynatraceApm Lam Monitor",

            class               		      : "CDynatraceApmMonitor",

			host_url                		  : "localhost:8021"",

            user_name                		  : "username",

            password                		  : "password",

            # encrypted_password     		  : "ieytOFRUdLpZx53nijEw0rOh07VEr8w9lBxdCc7229o=",

            ssl                      		  : false,

            ssl_keystore_file_path   		  : "",

            ssl_keystore_password    		  : "password",

	      	polling_interval         		  : 10,

	      	max_retries              		  : 10, 
 
			retry_interval           		  : 60,

			timeout							  : 120,

	        filter                            : {	     
	        										profileName  : "",
 
													incidentRule : "",
 
	        										state        : "",

													# time_from  : "",

	        										# time_till  : ""
	       										 }
              
	  },
  • name and class: These fields are reserved and should not be changed. The default values are DynatraceApm Lam Monitor and CDynatraceApmMonitor respectively
  • host_url: Enter the hostname or the IP address of the Dynatrace AppMon server along with its port e.g. "localhost:8021". Do not add http or https in front of the url.
  • user_name and Password: Enter the username and password for accessing Dynatrace AppMon server
  • encrypted_password: If the password is encrypted then enter the encrypted password in this field and comment the password field. At a time either password or the encrypted_password field is used. If both the fields are not commented then the field encrypted_password will be used by the Dynatrace APM LAM
  • ssl: Enter true here, to enable SSL Communication
    • ssl_keystore_file_path: Enter the path of the keystore file. This is the path where the generated keystore file is copied e.g. "/usr/local/dynatrace_appmon_ssl/keystore.jks"

    • ssl_keystore_password: Enter the password of keystore. It is the same password that was entered when the keystore was generated

  • polling_interval: The polling time interval between the requests after which the event data is fetched from Dynatrace. The polling interval is entered in seconds

    The default value is set to 10 seconds, if 0 is entered in this field then the time interval is by default set to 10 seconds

  • max_retries: The maximum number of retry attempts to reconnect with Dynatrace AppMon in case of a connection failure

    The default value is set to 10, if 0 is entered in this field then the LAM by default takes the value 10 and will try at least 10 times to reconnects

    If all the number of retries are exhausted, then an alarm is sent to Moogsoft AIOps about the connection failure. For re-establishing the connection, the LAM has to be restarted

  • retry_interval: The time interval between two successive retry attempts

    The default value is set to 60 seconds, if 0 is entered in this field then the time interval is by default set to 60 second

  • timeout: If for any reason the response is not received from the Server against a request, then the LAM discards the request after waiting for some time. The time that the LAM waits before discarding is given here in the timeout field. For example, If the timeout field has 120 entered in it, then the LAM will wait for 120 seconds for a response from the server, against a request. If no response is received for 120 seconds, then the LAM discards the request and sends a new request
  • filter: The incidents can be filtered on basis of following parameters:
    • profileName: Enter the Dynatrace profile name here
    • incidentRule: Enter the incident rule here

      If the profileName and the incidentRule filter are set, then the incidents are fetched from the single incident rule of the profile. At a time only one profile name and an incident rule of the given profile can be entered

      If only the profileName filter is set, then the incidents are fetched from all the incident rules of the profile

    • state: The incidents with the state mentioned here will be fetched from the Dynatrace AppMon server. At a time only one state can be given here. The states that can be given here are CreatedInProgress and Confirmed
    • time_from: The incidents will be fetched from the time given here. The time should be given in the yyyy-MM-dd'T'HH:mm:ss.SSSZ format
    • time_till: The incidents will be fetched till the time given here. The time should be given in the yyyy-MM-dd'T'HH:mm:ss.SSSZformat

      time_from and time_till can be collectively used to fetch incidents in a given time range

      The filter settings must be checked every time the LAM is restarted, as the unwanted filter settings may lead to undesired results. It is advisable to go through the config file before starting the LAM and check if any of the set filters is required or not

The entry in the fields port_number, polling_interval, max_retries, thread_pool_size, retry_interval and timeout should be an integer, therefore enter the values in these fields without quotation mark 

When connecting the first time, the LAM fetches any incidents that are generated from the current time. If the previous incidents are to be fetched, then use the time_from filter. Using the time_from field fetches all the incidents that have been generated from the time entered in the field and all the open incidents.

While using the time_from filter the LAM may take some time in fetching the incidents, the time taken may vary upon the number of incidents the LAM would be fetching

Only the incidents that are older than 3 days can be fetched by the LAM, as the Dynatrace API does not provide any incidents older than 3 days.

The Dynatrace API by default sends any open incidents it has (i.e. incidents without any end time). The 3 days limit is not valid for open incidents. If there are any open incidents, then the API will send all the open incidents to the LAM

Agent

Agent allows the user to define two parameters:

agent:
        {
                name    : "Dynatrace APM"
                #log    : "/var/log/moogsoft/dynatrace_apm_lam.log"
        },


The above example specifies:  

name: This is the agent name, the events sent to MooMs by the Dynatrace APM LAM are identified by the agent name in the log. In this example the agent name is Dynatrace APM

log: In this instance, the Dynatrace APM LAM will write its ingress contents in the file dynatrace_apm_lam.log located at /var/log/moogsoft/

HA Configuration

Refer the document HA Configuration of LAM

Mapping 

For events received in JSON format, a user can directly map the alarm/event fields of Dynatrace AppMon with moogsoft fields. In the case of an event received in text format, the event is first tokenised in the Variable section, and the tokenised event is then mapped here in the mapping section. The parameters of the received alarm/event are displayed in Moogsoft AIOps according to the mapping done here.

 mapping :
        {
            catchAll: "overflow",
			rules:
            [
                { name: "signature", rule:      "$systemprofile :: $rule" },
                { name: "source_id", rule:      "Dynatrace APM" },
                { name: "external_id", rule:    "$id" },
                { name: "manager", rule:        "Dynatrace Apm" },
                { name: "source", rule:         "$source" },
                { name: "class", rule:          "$rule" },
                { name: "agent", rule:          "$LamInstanceName" },
                { name: "agent_location", rule: "$LamInstanceName" },
                { name: "type", rule:           "$state" },
                { name: "severity", rule:       "$severity", conversion:"sevConverter" },
                { name: "description", rule:    "$description" },
                { name: "agent_time", rule:     "$start", conversion:"timeConverter"}
            ]
        },
        filter:
        {
            presend:"DynatraceApmLam.js"
        }


The above example specifies the mapping of the Dynatrace AppMon alarm fields with the Moogsoft AIOps fields. The stringToInt is used to convert the time received in the string format into an integer format.

The signature field is used by the LAM to identify correlated alarms

An example of Dynatrace events:

Constants and Conversions

Constants and Conversions allow the user to convert formats of the received data defined users.

        constants:
        {
            severity:
            {
            	"informational" : 1,
            	"warning" 		: 2,
            	"severe"		: 5
            },           
        },
 
        conversions:
        {
            sevConverter:
            {
                lookup: "severity",
                input:  "STRING",
                output: "INTEGER"
            },
	    	            
            stringToInt:
            {
                input:      "STRING",
                output:     "INTEGER"
            },
         
            timeConverter:
            {
                timeFormat: "yyyy-MM-dd'T'HH:mm:ss.SSS",
                input:      "STRING",
                output:     "INTEGER"
            }
        },


The above example specifies:

  • Severity and sevConverter: The severity field has a conversion defined as sevConverter in the Conversions section, this looks up the value of severity defined in the severity section of constants and returns back the mapped integer corresponding to the severity

  • stringToInt: It is used in a conversion, which forces the system to turn a string token into an integer value
  • timeConverter: It is used in conversion which forces the system to convert time. If epoc time is to be used, then timeFormat mentioned in timeConverter should be commented. Otherwise, the user should provide the timeFormat

catchALL 

The attribute that is never referenced in a rule is collected and placed as a JSON object in a variable called overflow defined here and passed as part of the event.

mapping :
        {
            catchAll: "overflow",
			rules:
            [
                { name: "signature", rule:      "$systemprofile :: $rule" },
                { name: "source_id", rule:      "Dynatrace APM" },
                { name: "external_id", rule:    "$id" },
                { name: "manager", rule:        "Dynatrace Apm" },
                { name: "source", rule:         "$source" },
                { name: "class", rule:          "$rule" },
                { name: "agent", rule:          "$LamInstanceName" },
                { name: "agent_location", rule: "$LamInstanceName" },
                { name: "type", rule:           "$state" },
                { name: "severity", rule:       "$severity", conversion:"sevConverter" },
                { name: "description", rule:    "$description" },
                { name: "agent_time", rule:     "$start", conversion:"timeConverter"}
            ]
        },

The Dynatrace APM field time is sent to Dynatrace APM LAM. Since it is not mapped to a field in the dynatrace_apm_lam.conf file, it is placed in the overflow JSON object. The fields that are placed in the overflow variable can be viewed in the Dynatrace APM LAM log file.

An example of an overflow JSON object created in the Dynatrace APM LAM log file:

 "overflow":"{\"time\":\"2017-02-23T10:44:45.099+05:30\"}"

Quotes

In some instances, the attribute strings are quoted. Our JSON parser ignores it, but the standard requires quoting for all strings, so Moogsoft recommends that user quote all strings. 

Comments

A user can comment out lines by appending them with a hash. 

Starting the Dynatrace APM LAM

To start the Dynatrace APM LAM enter the following command:

service dynatraceapmlamd start

To stop the Dynatrace APM LAM enter the following command:

service dynatraceapmlamd stop


To view the status of Dynatrace APM LAM, enter the following command:

service dynatraceapmlamd status


Command line attributes

The dynatrace_apm_lam is a command line executable that can be run as a service daemon, and takes four attributes, which can be viewed by typing:

 dynatrace_apm_lam --help

Option

Description

--config

Points to a pathname to find the configuration file for the LAM. This is where the entire configuration for the LAM is specified

--help

Displays all the command line options

--version

Displays the component’s version number

--log level

Specifies the level of debugging. By default, User gets everything. In common with all executables in MOOG, having it set at that level can result in a lot of output (many messages per event message processed).

In all production implementations, it is recommended that log level is set to WARN, which only informs user of matters of importance


Version Information

LAM Version

Tool Version

Tested?

Expected to Work

1.0

Dynatrace Server 6.5 & Dynatrace Server 7.0

Yes

Yes

1.1

Dynatrace Server 6.5 & Dynatrace Server 7.0

Yes

Yes

1.2Dynatrace Server 6.5 & Dynatrace Server 7.0
YesYes
1.3Dynatrace Server 6.5 & Dynatrace Server 7.0
YesYes
1.4 Dynatrace Server 6.5 & Dynatrace Server 7.0 YesYes

System Information

This LAM was tested on a system with the following configurations:

CPU2 core
RAM4 GB
Operating SystemCentOS Linux release 6.7

The system must at least have the above mentioned system requirements to run the LAM.



  • No labels