Issue

Use this article to troubleshoot HTTP notification endpoint and third-party application integration issues.

Environment

• Product: ZCF
• Versions: 4.x, 5.x
• Component: Cloud
• Affected objects: Alarm Center, alarms, HTTP application notification endpoints, and customer HTTP receiver programs
• Scenario: The customer receives ZStack Cloud alarms through an HTTP URL and integrates them with a third-party platform.

Symptoms

• After an alarm is triggered on the platform, the HTTP application notification endpoint is invoked.
• The customer application detects the alarm trigger or arrival of the HTTP request.
• The customer application reads empty alarm content and cannot parse the alarm details.

Possible causes

• The customer HTTP application or gateway filters the request body.
• The customer program reads only the URL, header, or status code and does not correctly read the body.
• The customer application framework restricts the content type, request method, or body parsing method.
• The platform notification failed to send, but the customer treats another probe request as an alarm request.

Resolution

1. Confirm that the alarm has been triggered, and record the alarm UUID, notification endpoint UUID, trigger time, and alarm content.
2. Check management-node logs to confirm whether the platform sent an HTTP request and whether an exception occurred during sending.
3. On the customer HTTP receiver, log the complete request, including Method, Path, Header, Body, and response code.
4. If management-node logs contain no sending failure and the customer can see a request with an empty Body, focus on whether the customer program filters or does not read the request body.
5. Reproduce the issue with a temporary test receiver, such as an HTTP service that logs only the raw request, to isolate the customer application logic.

Key command

grep -a -nE "Alarm|alarm|notification|notify|webhook|HTTP" /usr/local/zstack/apache-tomcat/logs/management-server.log*

Remediation

• Modify the customer HTTP application to retain and parse the request body sent by ZStack Cloud.
• If necessary, adjust body passthrough or parsing rules in the customer gateway, reverse proxy, or application framework.
• Trigger a test alarm again and confirm that the customer side records the complete body.

Verification

• Platform logs contain no notification-sending failure.
• Customer HTTP logs show the complete request body.
• The third-party platform can parse the alarm title, object, severity, and trigger time from the request body.

Risks and rollback

• Do not determine that ZStack Cloud has sent complete content only because the customer side received a request.
• Customer program changes can affect existing alarm-receiving workflows. It is recommended to validate them first with a test URL.

Notes

• Before adjusting management services, databases, certificates, permissions, auditing, or security settings, confirm the HA state, service window, rollback plan, and compliance-retention requirements.
• If database modifications, underlying file operations, lock release, service restarts, driver or firmware upgrades, or bulk resource changes are required, contact ZStack technical support before proceeding.