We've been running FortiSASE for about 8 months, covering 50 branch offices. The native FortiManager dashboards are fine for high-level status, but they don't give me the granular, historical view I need for proactive management.
I built a custom Grafana dashboard to monitor the IPSec and ZTNA tunnel health across the entire deployment. It pulls data from the FortiSASE APIs and our own performance monitors. The key panels I've found most useful are:
* **Tunnel Latency & Jitter Trends:** Plotted per location over 30 days. This immediately flags locations with degrading performance before users complain.
* **Tunnel Re-establishment Events:** Logs every time a tunnel drops and reconnects. We correlated a pattern of drops with a specific ISP at three sites.
* **Security Processing Delay:** Tracks the extra latency added by FortiSASE security functions (web filtering, CASB). Crucial for justifying performance overhead to management.
* **Bandwidth Usage vs. Licensed Capacity:** A simple bar chart showing we're consistently hitting 85%+ of licensed bandwidth at five locations, which is now driving a budget conversation for upsizing.
The biggest insight? We found that "healthy" tunnels can still have significant packet loss under 2% that the default portal doesn't highlight. This dashboard surfaces it.
Has anyone else built similar external monitoring? I'm particularly interested in how you're tracking application-specific performance (like Teams or Salesforce) through the SASE tunnels versus direct internet breakouts.
That point about correlating tunnel drops with a specific ISP is golden. It's exactly the kind of proactive insight you can't get from a vendor's green/red status page. Did you find the API logging consistent enough to automate that discovery, or did you have to do some manual digging to spot the pattern?
Great approach, and that last point about bandwidth usage is spot on. Having that visual proof of consistently hitting 85%+ capacity is what finally got finance to listen to our upgrade requests. Numbers from the vendor are one thing, but a simple chart you built yourself seems to carry more weight internally.
One caveat with the security processing delay metric - we've had to be careful about how we present that. Initially, management saw the added latency and questioned the value of the security stack. We had to pair it with a panel showing blocked threat events to frame it as a necessary trade off.
Are you logging the tunnel re-establishment events to a separate data source, or are you parsing that from the standard API event logs? I found the latter needed a fair bit of cleanup to filter out scheduled maintenance events.