Monitoring an Integration

Why monitor

Logs tell you about one request; monitoring tells you about the system. It aggregates signals across all your traffic so you can see health and trends, and — crucially — be alerted to trouble before customers feel it. The alternative, learning about outages from complaints, is both stressful and slow.

Good monitoring answers continuous questions: is the integration healthy right now, is it getting worse, and where is the problem? It turns the invisible behaviour of an external dependency into something you can watch. For an integration that matters to the business, being able to see and react before users do is the difference between a quiet fix and a public incident.

Signals worth watching

A handful of metrics cover most of an integration's health:

• Error rate — the proportion of calls failing; a sudden rise is your earliest warning.
• Latency — track percentiles such as the 95th, not just the average, which hides slow tails.
• Throughput — request volume, to spot both spikes and unexpected silence.
• Saturation — retry counts, queue depth and breaker state showing stress building.

Together these tell a story. Rising latency often precedes rising errors; climbing retries hint at a struggling dependency before it fully fails. Watching them in combination spots trouble forming rather than only confirming it after the fact. Feed these from your logged calls.

Metrics, logs and alerts

These three play distinct roles and you need all of them. Metrics are aggregate numbers over time — good for trends and dashboards. Logs are detailed per-event records — good for digging into a specific failure. Alerts are automated notifications when a metric crosses a threshold — good for waking someone up.

The pattern in practice: an alert fires on a metric, you glance at the dashboard for the shape of the problem, then drill into the logs for the specific cause. Each layer hands off to the next. Investing in only one — say logs without metrics — leaves you blind to trends, or aware of a problem with no way to investigate it.

Alerting without fatigue

Alerts are only useful if people trust them. The fastest way to ruin monitoring is noisy alerts that cry wolf — once ignored, the one real alert is missed too. Tune for signal.

// alert on a sustained condition, not a blip
if error_rate_5m > 0.05:
    page_on_call()

Alert on conditions that genuinely need a human and are sustained, not on momentary spikes a single retry would have absorbed. Prefer rates over windows to raw counts, set thresholds from real baselines, and route by severity so a minor warning does not page someone at night. Every alert should have a clear meaning and an obvious response; if it does not, refine or remove it. A small set of trustworthy alerts beats a flood of ignored ones.