I've been working on a proof-of-concept integration with the Radware Cloud WAF API, specifically around the `application` and `health` endpoints. While the API provides robust health status data, I found myself needing a more granular, external monitoring tool that could log trends and trigger alerts based on specific backend server response patterns—something that operates outside the WAF's own alerting for my internal dashboards. So, I built a simple, containerized health-check monitor in Go.
The core idea is to periodically poll the Radware API for a specific application's health status, parse the JSON response to isolate the backend server metrics, and apply custom threshold logic. For instance, the WAF might report an overall "Healthy" status, but I want to be alerted if the `avg_response_time` for a particular server pool exceeds a certain value over three consecutive checks, indicating potential latency creep. The service logs all data to a local time-series database (I used QuestDB) for historical analysis.
Here's a simplified snippet of the configuration and the main polling logic. The configuration is YAML-based for easy deployment:
```yaml
monitor:
interval_seconds: 60
radware_api_base: "https://api.radwarecloud.com"
application_guids:
- "app-guid-1"
- "app-guid-2"
thresholds:
max_avg_response_time_ms: 500
max_server_errors_per_minute: 5
alerting:
webhook_url: "https://hooks.slack.com/services/..."
```
```go
func pollApplicationHealth(appGUID string) error {
url := fmt.Sprintf("%s/application/v4/applications/%s/health", config.RadwareAPIBase, appGUID)
// ... API request with auth header ...
var healthResponse HealthResponse
json.Unmarshal(body, &healthResponse)
for _, backend := range healthResponse.BackendServers {
if backend.AvgResponseTime > config.Thresholds.MaxAvgResponseTime {
log.Warnf("Threshold exceeded for server %s: %dms", backend.Name, backend.AvgResponseTime)
if checkConsecutiveFailures(backend) >= 3 {
triggerAlert(backend)
}
}
}
return nil
}
```
The architecture is straightforward: it runs as a single container, with secrets injected via environment variables. The main challenges I encountered were around the pagination of health data for applications with a large number of backend servers and ensuring the API client handled rate limiting gracefully (the 429 responses are well-formed). I also added a simple circuit breaker pattern to prevent cascading failures if the Radware API becomes temporarily unavailable.
This tool is quite niche, but it demonstrates how you can extend the visibility provided by Radware's own API into custom operational dashboards. I'm considering expanding it to correlate health events with log entries from the `security-events` endpoint, which could help in distinguishing between performance degradation caused by attack traffic versus genuine backend issues. Has anyone else built similar external monitoring or data aggregation layers on top of the Radware APIs? I'm particularly interested in patterns for handling the real-time streaming of security events without overwhelming the downstream consumers.
API whisperer