The ability to integrate Dynatrace problem detection with third-party notification services has been available for some time. This provides a lot of flexibility in terms of how and where you receive your problem notifications. The latest Dynatrace release makes this capability even better.
The story up to now
Dynatrace enables you to configure a fully customizable WebHook integration that notifies any third-party system about detected problems, enabling you to:
- Fully customize your outgoing HTTP headers to cope with all available content types and authorization schemes
- Define your own payload structure to fit the receiving system’s demands
Many Dynatrace users are already using these capabilities to push Dynatrace detected problems into their own notification receiver-service implementations. Lightweight notification receivers can be implemented in any number of ways. You can, for example, use a simple AWS Lambda function, or use a customized ServiceNow scripted REST interface.
To make Dynatrace integration with third-party notification services even better, the latest Dynatrace release enables you to:
- Push full problem details from Dynatrace to your notification service in JSON, HTML, text, or Markdown format
- Temporarily disable SSL certificate checks to simplify your pre-production testing
See below for full details.
Push Dynatrace problem details to your notification service
With this Dynatrace release, we introduce several additional payload placeholders that allow third-party problem receivers to get all problem details in JSON, HTML, plain text, or Markdown formats. You choose the format most suitable to the receiver.
With the right formatting, you can push all relevant impact and root-cause information into any third-party destination system or even further process a detected problem within your own alert-receiver service.
The newly introduced problem details placeholders appear as follows in Dynatrace.
In the following example, you’ll see how to send alerts for detected problems to a dedicated Lambda function that further implements some filtering and distribution logic.
Temporarily disable HTTPS certificate checking
Another improvement that comes with the latest Dynatrace release is the ability to temporarily stop checking HTTPS certificates.
Do not use this option within production environments, where it would, of course, present a serious security issue. We offer this option only to make it easier for you to test problem notifications with local data-center systems that don’t provide valid certificates.
For example, Ansible Tower, by default, comes with HTTPS enabled but requires you to provide a valid certificate. If you don’t have a certificate on hand when you set up and test your process, it’s convenient to be able to temporarily disable certificate checking. Once your setup is working as planned and you’ve configured a valid certificate on the third-party system, simply re-enable certificate checking to resume secure production operations.
The actual procedure for enabling or disabling certificate checking is a matter of selecting or clearing a check box to Accept any SSL certificate.
To disable/enable certificate checking, either select or deselect the Accept any certificate (self signed or invalid) option box.
Summary of features
If you’re integrating Dynatrace problem detection with your notification service, we highly recommend that you upgrade to Dynatrace cluster version 143 so you can:
- Push complete problem details to your notification service in JSON, HTML, text, or Markdown format
- Temporarily disable checking of SSL certificates to simplify your tests