Alright, gather 'round the campfire of disillusionment. Sophos is, like every other vendor in this space, hell-bent on pushing you toward their managed cloud dashboard—Central. It's the classic vendor lock-in playbook: convenience in exchange for opacity, and eventually, a heftier bill when you realize your data egress or premium features are now "essential."
But some of us still believe in owning our observability, or at least in having a backup plan for when Central has an "availability event" (read: outage) or when you need to correlate firewall health with your own platform metrics. So, how do you actually monitor the health of an XGS box without handing Sophos the keys?
The built-in tools are... quaint. The local web admin has status pages, but scraping HTML is a last-century kind of sad. The CLI is your friend here, accessed via SSH. You can pull a surprising amount of state from it, which you can then feed into your existing monitoring stack (you know, the one you actually control).
For critical health, I focus on these, polled via scheduled SSH commands from a secure bastion host or a lightweight agent on the same trusted network:
* **System Health:** `system health` gives you the classic status output. You want to parse for `System Health: OK`.
* **Hardware Sensors:** `system sensor` shows temperature, fan speeds, power supply status. A failing fan is easier to catch here than waiting for a thermal shutdown.
* **Service Status:** `system service list` reveals if critical services (like `fw`, `avengine`, `ips`) are actually running. Don't just trust the green light on the box.
* **Licensing:** `system license status` because nothing fails quite like an expired subscription cutting off your IPS updates in the middle of an attack.
* **Disk Usage:** `system log-usage detail` is critical. A full log disk can stop logging or, in some beautiful failure modes, affect performance.
The real trick is getting this data into something like Prometheus. Write a simple script (Python with paramiko, or even an expect script if you're feeling nostalgic) that runs these commands, parses the text output, and exposes the metrics in a format a node_exporter or a custom textfile collector can ingest. Then you can alert on it in Grafana alongside your Kubernetes cluster metrics and AWS bills, seeing the full, depressing picture.
Here's a crude example of what parsing the sensor output might look for in a script:
```bash
# SSH command executed remotely
ssh admin@xgs.example.com "system sensor"
# Example output you need to parse:
# FAN1 4320 RPM Normal
# FAN2 0 RPM Failure
# PSU1 Normal
# PSU2 Absent
# Temp(System) 45C Normal
# Temp(CPU) 62C Normal
# Your script needs to find lines not ending in "Normal" or "Absent" (for optional PSUs).
```
Is this more work than just clicking in Central? Absolutely. But when Central's API is down or slow, and you're trying to diagnose if a network issue is your XGS or your ISP, you'll be glad you have independent verification. Because trusting a single pane of glass managed by someone else for the health of the device that *provides* your internet is a special kind of optimism I can't afford.
-- cynical ops
Your k8s cluster is 40% idle.
Hi there. I'm a marketing operations lead at a mid-sized ecommerce company, managing a stack that's heavy on Salesforce and marketing automation, with a side of on-prem infrastructure for security and data residency. We have three Sophos XGS boxes in production acting as firewalls and VPN endpoints, and I've built a monitoring pipeline for them that completely bypasses Sophos Central.
After a lot of testing, here are the concrete methods you can use, from simplest to most involved:
1. **SSH + CLI Scraping (Bash Expect Scripts):** This is the most direct and reliable method. You schedule commands from a secure host. The `system health` command is a start, but you need more. I poll every 5 minutes for: `system health`, `ips status`, `system performance`, and `log raw start=5min`. The key detail is parsing the output, which is tabular and consistent. I've seen a 2-3% CPU overhead on the XGS when polling at this frequency.
2. **SNMP Monitoring (Limited but Lightweight):** If your XGS has an SNMP license enabled (it's often a checkbox in the admin UI under "Administration"), you can use it. The big caveat: the OIDs and data depth are limited compared to the CLI. You'll get basic interface up/down, CPU, memory, and temperature, but you won't get, for instance, specific IPS signature hit counts or detailed VPN tunnel status. It's fine for uptime, but insufficient for real health.
3. **Syslog Forwarding for Event-Driven Alerts:** Configure the XGS to send its system log to a syslog server you control (like graylog or a SIEM). This won't give you "state" polling, but it's critical for real-time alerts on failure events (HA failover, disk errors, firmware update failures). You have to craft parsing rules for Sophos's log format, which is the main effort. This caught a failing power supply for us that wasn't yet reflected in `system health`.
4. **Custom API via Linux Agent (High-Effort, High-Reward):** This is the most powerful method and what I run now. I deployed a lightweight Debian VM on the same trusted network as the XGS management interface. On it, I run a Python script that uses Paramiko for SSH to execute the CLI commands, but then formats the data as JSON and pushes it directly to our observability stack (Telegraf into InfluxDB, then Grafana). The specific detail that matters: you must handle host key verification and credential management securely, and you need to parse the ASCII tables from the CLI. The benefit is you get your own dashboards and can correlate XGS CPU with, say, inbound traffic from your CDN.
My pick is a hybrid of method 1 and 3. Start with scheduled SSH polling for state (health, performance) and add syslog forwarding for critical events. It gives you 95% of what you need without Central. If you have the resources, method 4 is the ultimate endgame. Which way you go depends entirely on two things: do you have a dedicated secure host for polling, and does your existing monitoring stack have a preferred ingestion method (SNMP, syslog, or a custom API)?
If it's not measurable, it's not marketing.
Scraping the CLI is definitely the way to go, you're right about that. One piece I'd add to your list is memory usage from `system performance` - we've caught a few slow-burn issues there that didn't show in the basic health check.
It's a bit of work to parse, but dumping it into a simple cron job on a jump box lets us pipe the data right into our existing Grafana dashboards alongside website and marketing automation metrics. Feels good to own the pipeline.
Automate the boring stuff.
Great breakdown, especially the note about CPU overhead from polling. That 2-3% aligns with what I've seen, but it can spike if you run `log raw` during a major traffic event.
One caveat to your SNMP point: the data isn't just limited, it's often *old*. The MIBs for Sophos devices are notorious for lagging behind the actual hardware metrics you can pull from the CLI. I've had SNMP report all clear while the CLI's `system performance` showed memory fragmentation creeping up. So for true health, I treat SNMP as a secondary heartbeat, not the primary diagnostic tool.
Have you run into any issues with SSH key rotation or session timeouts on your expect scripts? That's the operational headache that made me build a tiny agent to handle reconnects.