Customize data with extensions

You can tailor various aspects of Dynatrace to the specifics of data acquired by your extension. You can also use the extension to introduce a new configuration in your environment (for example, organize data in dashboards, create new alerts, or introduce complex metrics).

Custom Dynatrace UI

The Extensions 2.0 framework enables you to tailor the Dynatrace UI for the specific needs of the data ingested by your extension. You can add customized dashboards or specialized unified analysis pages to your extension.

For more information, see Extend Dynatrace with domain-specific web UI.

Custom metric events

You can create custom metric events based on the metrics extracted by your extension and add the exported definitions to your extension archive. This way, you can distribute the custom metric events among Dynatrace environments.

  1. Go to Settings > Anomaly detection > Metric events.
  2. Expand the event of your choice.
  3. Scroll to the bottom of the definition where you'll find the Config id parameter (for example, id=1be8d58d-71a7-4566-9058-754d635363ab) and save the parameter value.
  4. Run the following command to get the definition of the custom metric event. For this example, we use the Dynatrace SaaS URL: 
    curl -X GET "https://{env-id}.live.dynatrace.com/api/config/v1/anomalyDetection/metricEvents/{custom-event-id}" \
    -H "accept: application/json; charset=utf-8" \
    -H "Authorization: Api-Token `{api-token}"
    Replace:
    • {env-id} with your Environment ID.
    • {api-token} with an API token that has the required permissions.
    • {custom-event-id} with the custom metric event identifier you determined in the previous step.
  5. The call returns the JSON payload containing a custom metric event definition. Save it as a JSON file.
  6. Declare the exported JSON files in your extension.yaml file and add them to your extension package.

For more information, see Extensions 2.0 hands-on excercise.

After you upload or update an extension containing custom metric events, make sure you enable the events you'd like to use. The extension-imported events are disabled by default after each upload and activation, inluding an update. To enable metric events, go to Settings > Anomaly detection > Metric events.

Custom topology

After you start to send in your own data via an extension, you might be interested in extending the built-in topology model by adding your own domain-related entity types and relationships.

For more information, see Custom topology model.

Custom metric metadata

To add more context to data points and their dimensions ingested by your extension, your custom metric can carry additional useful information, such as the unit of measurement, display name, and value ranges.

You can provide such information via custom metric metadata. Metadata and data points are stored independently from data points and tied together by the metric key. You can push data points and set metadata in any order.

For more information, see Custom metric metadata.

Data filtering

Extensions also allow you to filter data based on specific criteria. This filtering capability is particularly useful for SNMP extensions, where you might want to limit the data that is ingested by the extension

Filters match entity names to include/exclude certain configurations from monitoring. This makes the data more relevant and saves unnecessary license consumption. Filters work with a specific entity type and support the following syntax:

Expression
Description
$eq(<str>)
Checks if <str> matches what you're filtering
$prefix(...)
Begins with …
$suffix(...)
Ends with …
$contains(...)
Contains …
$and(<expr1>, <expr2>)
Chains two or more of the above expressions with the AND operator
$or(<expr1>, <expr2>)
Chains two or more of the above expressions with the OR operator
$not(<expr>)
Negates an expression. For example, to exclude all Pools from the Common partition, you can add the $not($prefix(/Common/)) filter.

Custom process group detection rules

Dynatrace detects which processes are part of the same process groups by means of a default set of detection rules. However, you can add your own process detection rules suited to the data retrieved by your extension.

For more information, see Process group detection.

Log metrics, events, and processing rules

After you enable log ingestion into Dynatrace you can define the log metrics, events, and add your own log processing rules to be shipped with your extension.

For general information, on your logs configuration, see

The Extensions YAML file supports the same fields as the Settings 2.0 schemas:

You define your custom log configuration in the Extensions YAML file, starting with the following nodes in the root of the file

  • logMetrics
  • logEvents
  • logProcessingRules

To learn the structure of the definition, check the Extensions schemas:

  • log.events.schema.json
  • log.metrics.schema.json
  • log.processing.rule.schema.dql.json
  • log.processing.rule.schema.json
  • log.processing.rule.schema.lql.json

See Extension YAML file to learn how to get the schema JSON files.

Check the examples below on how to define your log metrics, events, and processing rules in the extension YAML file.

name: custom:dynatrace.logmetric.test.extension
version: 1.0.0
minDynatraceVersion: "1.281.0"
author:
  name: "John Doe"


logMetrics:
  - key: log.test.extension.occurrence
    query: content="AllProcessed"
    enabled: true
    measure: OCCURRENCE
  - key: log.test.extension.attribute
    query: content="AllProcessed"
    enabled: true
    measure: ATTRIBUTE
    measureAttribute: dt.os.type
  - key: log.test.extension.dimensions
    query: content="AllProcessed"
    enabled: true
    measure: OCCURRENCE
    dimensions: [
      dimension1,
      dimension2
    ]
ame: custom:dynatrace.logevent.test.extension2
version: 1.0.0
minDynatraceVersion: "1.281.0"
author:
  name: "John Doe"


logEvents:
  - query: content="a"
    enabled: true
    summary: abc
    eventTemplate:
      title: log_event_a
      description: ''
      eventType: CUSTOM_ALERT
      davisMerge: false
  - query: content="a"
    enabled: true
    summary: abd
    eventTemplate:
      title: abd
      description: My custom log event description :)
      eventType: CUSTOM_ALERT
      davisMerge: false

With this definition, you use the RAPLACE_PATTERN to mask sensitive data retrieved using the SQL data source.

logProcessingRules:
  - ruleName: TopN statements masking
    query: event.group="query_performance"
    enabled: true
    ProcessorDefinition:
      rule: |
        USING(INOUT content) | FIELDS_ADD(content: REPLACE_PATTERN(content, "(\"'\"):p1 (LD):p2 (\"'\"):p3", "${p1}${p2|sha1}${p3}"))
    RuleTesting:
      sampleLog: |
        {
          "event.group": "query_performance",
          "content": "/*dt:ownQuery*/SELECT DECODE(name, 'sessions', value) AS sessions_limit, DECODE(name, 'processes', value) AS processes_limit FROM v$parameter WHERE name IN('sessions', 'processes')"
        }