Problem notification: is there a way to reference sub-elements of the {ProblemDetailsJSON} Placeholder?

Platform Open Q&A
,
1

I’ve tried to set-up an custom problem notification that contains a small json body. 
here, i want to reference some sub-elements of the {ProblemDetailsJSON} Placeholder.
For {Tags} this can be done with {Tags[value]}. Is there a way to extract sub-elements from the {ProblemDetailsJSON} as well? I only want to include the relevant values for the custom notification. 
E.g:

{
  "id": "6029162950440568052_1751963460000V2",
  "startTime": 1751963520000,
  "endTime": 1751963888036,
  "displayName": "P-2507568",
  "impactLevel": "INFRASTRUCTURE",
  "status": "CLOSED",
  "severityLevel": "CUSTOM_ALERT",
  ...
  "rankedImpacts": [
    {
      "entityId": "CLOUD_APPLICATION_NAMESPACE-F3D62A923B6A6730",
      "entityName": "dynatrace-system",
      "severityLevel": "CUSTOM_ALERT",
      "impactLevel": "INFRASTRUCTURE",
      "eventType": "CUSTOM_ALERT"
    }
  ],

would like to extract and display specific fields from the rankedImpacts array (e.g., entityName, severityLevel, etc.) directly via the {ProblemDetailsJSON} placeholder in the notification payload.

Regards,
Simon

2

Hi @Simon_

At the moment, Dynatrace does not support extracting specific fields from {ProblemDetailsJSON} directly in the notification configuration.  This needs to be handled on the receiver side.

Radek

3

Hi @radek_jasinski,

It’s unfortunate that Slack webhooks currently don’t support nested JSON payloads.

Is there a way to request support for this feature, or are there any updates planned in this area? Right now, extracting a simple value—like a Kubernetes cluster or namespace—from incoming data is more difficult than it should be.

Regards,
Simon

4

Hi,

For example you can based on:

  • {ImpactedEntities} or {Tags}

Full payload from documentation:

{ImpactedEntities}: Details about the entities impacted by the problem in form of a json array.

{ImpactedEntity}: A short description of the problem and impacted entity (or multiple impacted entities).

{ImpactedEntityNames}: The entity impacted by the problem.

{NamesOfImpactedEntities}: The names of all entities that are impacted by the problem.

{PID}: Unique system identifier of the reported problem.

{ProblemDetailsHTML}: All problem event details including root cause as an HTML-formatted string.

{ProblemDetailsJSONv2}: Problem as json object following the structure from the Dynatrace Problems V2 API. The optional fields evidenceDetails and impactAnalysis are included, but recentComments is not.

{ProblemDetailsJSON}: Problem as json object following the structure from the Dynatrace Problems V1 API.

{ProblemDetailsMarkdown}: All problem event details including root cause as a Markdown-formatted string.

{ProblemDetailsText}: All problem event details including root cause as a text-formatted string.

{ProblemID}: Display number of the reported problem.

{ProblemImpact}: Impact level of the problem. Possible values are APPLICATION, SERVICE, or INFRASTRUCTURE.

{ProblemSeverity}: Severity level of the problem. Possible values are AVAILABILITY, ERROR, PERFORMANCE, RESOURCE_CONTENTION, or CUSTOM_ALERT.

{ProblemTitle}: Short description of the problem.

{ProblemURL}: URL of the problem within Dynatrace.

{State}: Problem state. Possible values are OPEN or RESOLVED.

{Tags}: Comma separated list of tags that are defined for all impacted entities. To refer to the value of a specific tag, specify the tag’s key in square brackets: {Tags[key]}. If the tag does not have any assigned value, the placeholder will be replaced by an empty string. The placeholder will not be replaced if the tag key does not exist.

5

And that is exactly the issue here. The Kubernetes information is nested inside the ProblemDetailsJSONv2, which is not accepted by Slack (since it cannot handle nested data). The only way to have this information in Slack is by leveraging ProblemDetailsText, But this comes with a major trade-off, since this includes loads of irrelevant text as well.