Custom Extensions

Instrumenting External Provided Python Extension

  1. Replace/Add Support files to the uniquely named folder
    1. In the support files, make sure the imports have no errors (changing to relative imports)
  2. Replace/Add the main file into the extensions folder
    1. Comment out any calls to class/function
    2. Make sure imports are relative
    3. Add the imports if not already there

From ruxit.api.base_plugin import RemoteBasePlugin

import pytz

from croniter import croniter

from datetime import datetime
  1. Add “(RemoteBasePlugin)” after the class name
  2. Change the “__init__” function name to “initialize”
  3. Add “**kwargs” parameter to the functions (initialize and query functions)
  4. In the initialize function add:

self.cron = self.config[“cron”]

self.tz = pytz.timezone(‘America/New_York’)

  • For Satish’s code

self.theDynatrace_api_token = self.config[“api_token”]

self.theSSPasswordFromExtension = self.config[“secret_server_api_password”]
  • For Satish’s code -> make sure the logger only has the file name (relative)
  • In the query function add:

if croniter.is_valid(self.cron):

cronNow = self.tz.localize(datetime.now()).replace(second=0, microsecond=0)

run = croniter.match(self.cron, cronNow)

if run:

*your code*

else:

raise ValueError(“Cron Input is not valid”)
  1. Add a plugin.json file
    1. “name”: “custom.remote.python.<your python filename>”
    2. “version” : “0.1” for dev and “1.0” for production, each time you deploy you must add .1 manually (1.0 -> 1.1)
    3. “package” : “<your python filename>”
    4. “className” : think just start with capital letter, use camel case, and must be unique
    5. “displayName”: “IAM | <whatever Satish gave you>”
  2. Send build file to Enterprise Monitoring for deployment

Service Offering

If you have a need to monitor a system, service, or technology that is not provided natively through any of our many existing Enterprise Monitoring technologies, you can either submit code (Python, PowerShell, Bash, etc.) or request for the development of a solution capable of obtaining the necessary metrics and having them stored in Dynatrace for custom notifications, alerting, dashboarding, reporting, or even analysis.

This is all provided through the use of Dynatrace Extension 1.0 which is a dedicated host designed to run your scripts every 1 minute or on a schedule support through cron. The resulting metrics are then then stored and retained in Dynatrace for up to 5 years.

Note: When you initially consult us regarding what you are looking to achieve, the Enterprise Monitoring team may be able to redirect you to simpler offerings such as Synthetics in order to reach your objective. Reach out to us and we’re happy to help get you to the simplest solution.

How do I get started?

  • Gather a clear understanding of the metrics you need to monitor.
  • Determine how you would manually obtain these metrics today
    • Including calculations you may need such as delta over time
  • Develop your own scripts in Python, PowerShell, or Bash to obtain the necessary metrics OR let us know that you need help developing a script.
  • Submit a ServiceNow Request to Enterprise Monitoring to initiate the first consultation meeting.

Engagement Process

Welcome Mat

An initial consultation meeting with Enterprise Monitoring to understand your needs and align you with the best service offering for your needs. 

Extension 1.0 - Script development

If the development of a new Extension 1.0 script is the best course, the Enterprise Monitoring team will go over the technical needs in order to reach and extract your metrics. We will then discuss the details of developing a script. And finally discuss thresholds, notifications, and alerting mechanisms.

Extension 1.0 - Pre-made Script adoption

If you already have scripts developed and simply require them to be scheduled and executed using the Dynatrace Extension 1.0 infrastructure, then we do a review of the scripts, instrument it with required Dynatrace components standard for all extensions, plan a deployment, and train your team on managing the scripts configuration.

Script changes will need to follow a migration path involving the Enterprise Monitoring team.

Finally, we discuss thresholds, notifications and alerting mechanisms.