Watching the Fabric: FortiAnalyzer and FortiMonitor for SD-WAN SLA Observability

Every design document contains a promise

Go back through the hub placement series or the resilience series and you’ll find the same shape of sentence again and again: “the performance SLA will detect degradation and steer traffic away from it,” “BFD convergence will keep the failover under N milliseconds,” “this link is sized to absorb failover load from its pair.” Every one of those is a design-time promise about run-time behaviour. None of them are self-verifying.

This post is about the tooling that turns “the design assumes X” into “here’s six months of data showing X is actually true” — or, just as usefully, into an early warning that it’s quietly stopped being true. FortiAnalyzer and FortiMonitor are the operational bookend to the FortiManager lab series: FortiManager is how you push and template configuration at scale; FortiAnalyzer/FortiMonitor is how you find out, after the fact and in aggregate, whether what you pushed is actually working.

Two tools, two different jobs

It’s worth being precise about the division of labour, because reaching for the wrong one wastes time:

FortiAnalyzer is the log aggregation and historical analysis layer. It ingests logs from your FortiGates — including SD-WAN performance-SLA results, session logs, and event logs — and gives you long-horizon reporting and forensic drill-down. Its natural question is “what happened, when, and how often” — the tool you reach for when you need to show a trend over weeks or months, or reconstruct exactly what the fabric was doing during an incident that happened three days ago.

FortiMonitor is the real-time monitoring and alerting layer — synthetic checks, uptime monitoring, performance dashboards, and the alerting pipeline that taps someone on the shoulder while something is happening rather than after. Its natural question is “is something wrong right now, and who needs to know.”

The shorthand that holds up in practice: FortiAnalyzer answers “what happened” with depth and history; FortiMonitor answers “is it happening now” with speed. A mature operational setup uses both, deliberately, for the questions each is actually good at — not one tool stretched to cover the other’s job.

Turning SLA design assumptions into alerting thresholds

This is where the resilience series’ performance-SLA configuration stops being a steering mechanism and becomes an observability data source as well — the same measurements that drive path selection in real time are exactly what you’d want trended and alerted on after the fact.

The translation work is straightforward in concept and easy to get subtly wrong in practice: every threshold your SD-WAN rules use to make a steering decision is a candidate alerting threshold for FortiMonitor, and every one of those measurements is a candidate trend line in FortiAnalyzer. If your performance SLA steers voice traffic away from a path once latency crosses a defined threshold, that’s not just a steering rule — it’s a statement that “latency above this number is a problem for this traffic class,” which is precisely the kind of statement an alert should be built around.

The trap to avoid: setting alert thresholds more strictly than the steering thresholds “to be safe.” That produces a flood of alerts every time the SD-WAN fabric does exactly what it was designed to do — quietly steer around a brief degradation — and the inevitable result is that people start ignoring the alert channel. Set the alerting threshold to catch the situations the steering can’t fully absorb: sustained degradation across multiple paths, a pattern that recurs at the same time daily, anything that looks like a trend rather than the noise the SLA steering already handles gracefully. The goal is an alert that means “this needs a human,” not an alert that means “the system is working as designed, again.”

Historical link-quality reporting: making the case with data, not memory

Six months after a migration or a hub redesign, someone will ask whether it actually delivered what the project promised. “It feels faster” is not an answer that survives a budget review. A FortiAnalyzer report showing latency, jitter, and packet-loss trends across the relevant period — ideally spanning the before-and-after of a change — is.

This works in both directions, which is exactly what makes it valuable rather than just reassuring: the same historical reporting that validates a successful migration is what surfaces a slow-burning problem before it becomes an incident — a link that’s been quietly trending toward its SLA threshold over three months looks unremarkable on any single day’s dashboard and unmistakable on a quarter’s trend line. That’s the entire argument for keeping this data and looking at it on a cadence, rather than only when something’s already on fire.

Feeding observations back into design — closing the loop

The quiet payoff of this whole exercise is that it’s not a one-way reporting function — it’s a feedback loop back into the design work the rest of this series has covered:

• Consistently high utilisation on a “backup” path in the resilience series’ full-DCI design is a signal that the failover-sizing assumption needs revisiting — not a problem with the monitoring, a finding from it.
• A pattern of SLA breaches concentrated at specific times of day is exactly the kind of evidence that should shape traffic shaping and QoS policy refinement — not a guess about when contention happens, a measurement of it.
• A circuit that has trended cleanly for months is the evidence base for expanding its role in the design, with actual data behind the decision rather than an assumption that it’ll keep performing the way it always has.

None of this is exotic tooling — it’s the same SLA measurements and session logs the fabric is already generating, aggregated somewhere you can actually see the shape of them over time. The discipline is in deciding, deliberately, which numbers matter enough to alert on, which matter enough to trend, and which can be left as raw logs until the day you need to go looking for them.

Where this leaves the SD-WAN series

This closes the loop the series opened with hub placement: design, build, secure it with ZTNA, police it with shaping and QoS, migrate to it deliberately with the cutover playbook, and now — watch it, measure it, and let what you see reshape what you build next. That last step is the one that turns a project into an operating discipline.