How to: Inbound Integration from Dynatrace Problems to Zabbix 7.0 (JSON-RPC 2.0)

[Fernando_Moreir]

Hi community,

I'm currently working on a project to push Dynatrace Problems directly into Zabbix 7.0 using a Webhook (Custom Integration).

The Challenge:

The Zabbix API (/zabbix/api_jsonrpc.php) requires a specific JSON-RPC 2.0 structure (methods like history.push). The default Dynatrace Webhook UI sends a flat JSON payload, which causes Zabbix to return an "invalid params" error despite the HTTP 200 connection success.

What I have tried:

1. Zabbix Trapper: Works manually via binary protocol, but Dynatrace speaks HTTP.
2. Custom Webhook: Connects successfully, but fails at the API application layer due to the JSON format.

My Questions:

1. Has anyone successfully "wrapped" the Dynatrace Problem payload into a JSON-RPC compilant structure within the Webhook UI?
2. Would the new Dynatrace Automation Engine (Workflows) be a better fit to construct this specific JSON-RPC call? If so, does anyone have a JS snippet for this?
3. Are there any existing Extensions or templates for Zabbix 7.0 inbound alerts?

I've attached a screenshot showing the API error response for reference. Any insights or examples would be life-saving!

Thanks in advance,

Fernando Moreira

[rgarzon1]

hi Fernando

Dynatrace Workflows is definitely the best approach here—we have implemented this before with great results. You can easily construct the required JSON-RPC 2.0 payload using Jinja templating as shown below

aproach in jinja

Spoiler

{
"jsonrpc": "2.0",
"method": "history.push",
"params": [
{
"itemid": {{ zabbix_item_id | default(10600) }},
"value": {{ {
"problem_id": event["event.id"] | default("N/A"),
"title": event["event.name"] | default("Dynatrace Alert"),
"status": event["event.status"] | default("OPEN"),
"severity": event["event.category"] | default("INFRASTRUCTURE"),
"impact": event["event.impact"] | default("UNKNOWN"),
"url": event["event.details_url"] | default("")
} | to_json | to_json }},
"clock": {{ event["timestamp"] | default(now() | int) }}
}
],
"id": {{ execution.id | default(1) }}
}

y si lo haces para una red interna te conviene hacerlo con el edgeconnect incluido para que puedan llegar las peticiones a tu zabbix 

[Fernando_Moreir]

Hi @rgarzon1 ,

Thank you so much for this detailed response! The Jinja templating approach with Workflows looks incredibly powerful and exactly what Zabbix 7.0 needs for its JSON-RPC structure.

However, I have a specific constraint: I am working on Dynatrace Managed environment that currently does not have the Automation Engine / Workflows enabled.

Because of this, I am restricted to using the classic Custom Integration (Webhook). From your experience:

1. Is it possible to "trick" the classic Webhook's Custom Payload to send a valid JSON-RPC 2.0 structure (including the params array)?
2. Or is a middleware (e.g, a Python/Node script acting as a translator) mandatory when Workflows are not available in a Managed environment?

I've already tested the history.push method via curl and it works perfectly on Zabbix 7.0, so the goal is really down to how to format that call within the limits of a Managed Webhooks.

Thanks again for the "Champion" level support!

Best regards,

Fernando Moreira

[Julius_Loman]

Options on Dynatrace Managed are limited. You need a service in between for the conversion.

[rgarzon1]

Hi Fernando

did you try something like this ? 

Spoiler

{
"jsonrpc": "2.0",
"method": "history.push",
"params": [
{
"itemid": 10600,
"value": "{\"problem_id\":\"{ProblemID}\",\"pid\":\"{PID}\",\"title\":\"{ProblemTitle}\",\"state\":\"{State}\",\"impact\":\"{ProblemImpact}\",\"severity\":\"{ProblemSeverity}\",\"impacted_entities\":\"{NamesOfImpactedEntities}\",\"url\":\"{ProblemURL}\"}"
}
],
"id": 1
}

theroricaly works. but idk, i dont have a zabbix in this moment. 

[Fernando_Moreir]

Hi @rgarzon1 ,

That is a brilliant "trick"! Escaping the quotes inside the value string is exactly the workaround I was looking for to bypass the flat JSON limitation of the classic Webhook UI in Managed.

Quick update on my progress:

I've successfully tested the history.push method via curl and it worked perfectly on Zabbix 7.0 after correcting the itemid and changing the item type from integer to Text (extremely important step!).

I have already configured the Webhook in Dynatrace using the structure you shared (JSON-RPC 2.0 compilant). Currently, Dynatrace returns a "Successful" notification, but the data is not yet appearing in Zabbix's "Latest Data".

It seems to be a security/networking detail now: Zabbix Trapper items require the source IP to be in the "Allowed hosts" list. I am working with the Zabbix admins to "allowlist" the IPs of our ActiveGates (or the NAT/VIP they are using).

Once the "Allowed hosts" are set, this native Push approach should be the definitive solution for Dynatrace Managed users without Workflows.

I will post the final confirmation once the data reflects in the Zabbix UI!

Best regards,

Fernando Moreira

[AntonPineiro]

Hi Fernando,

Maybe another solution would be create a custom extension in some Activegate since you are in Managed. It will take more time but you will have full control.

Python script will get problems via Dynatrace API and send them to Zabbix API. I think Python library is rich enough to format a compliant JSON-RPC structure.

Another option would be Dynatrace is not pushing, Zabbix is pulling problems via Dynatrace API. But you need to use LLD in Zabbix and another Zabbix features to create problems dynamically.

Best regards

[Fernando_Moreir · Accepted solution]

Hi everyone,

I am pleased to confirm that we have achieved 100% SUCCESS with this native integration on Dynatrace Managed!

Here is the summary of the solution and the critical findings for anyone looking to push Dynatrace Problems into Zabbix 7.0 via Classic Webhooks (without Workflows or middleware):

1. The "Allowed Hosts" Gotcha in Zabbix 7.0:
The initial roadblock where Dynatrace reported "test successful" but Zabbix discarded the data was caused by the Trapper Item's "Allowed hosts" setting. When using the JSON-RPC history.push method, Zabbix evaluates the internal source address executing the API call (local server / localhost).

Solution: Clear the "Allowed hosts" field completely on the Zabbix Trapper item so authentication is handled strictly by the API Bearer/Auth Token.

2. Item Configuration in Zabbix:

• Item Type: Zabbix trapper
• Type of Information: Text
• Key: dynatrace.problem.state (or any custom key)

3. Final Working Custom Payload in Dynatrace Managed:
To prevent JSON parsing errors (such as unquoted control characters or line breaks from complex objects), we structured the payload into a clean, flat string:

{
"jsonrpc": "2.0",
"method": "history.push",
"params": [
{
"itemid": "YOUR_ZABBIX_ITEM_ID",
"value": "Problem: {ProblemTitle} | ID: {ProblemID} | Status: {State} | Severity: {ProblemSeverity} | Impact: {ProblemImpact} | Entities: {ImpactedEntityNames} | Tags: {Tags} | URL: {ProblemURL}"
}
],
"auth": "YOUR_ZABBIX_API_TOKEN",
"id": 1
}

Note: Make sure to use {ImpactedEntityNames} instead of {ImpactedEntities} (which outputs a JSON array), and avoid {ProblemDetailsHTML} / {ProblemDetailsText} inside single-line strings to prevent unescaped newline breaks.

Results:

• Ingestion is immediate in Zabbix Monitoring > Latest Data.
• Trigger rules in Zabbix fire instantly with the enriched Davis AI context (Root cause URL, impact, severity, affected entities).

Special thanks to @rgarzon1 for pointing in the right direction with the JSON-RPC wrapping! This proves that Dynatrace Managed can seamlessly integrate with Zabbix 7.0 natively.

Best regards,
Fernando Moreira