日常维护 FortiGate 时，我做得最多的其实不是修改配置，而是先确认设备状态。比如远程站点有人说网络变慢了，或者某条 WAN 链路刚刚出现过波动，我通常不会马上去改配置，而是先看一眼设备现在的情况。
设备是否在线、WAN 链路是否正常、上下行流量有没有异常、接口有没有掉线、CPU 和内存使用率怎么样，以及 Session 数量有没有明显变化。多数情况下，看完这些基础状态，我大概就知道下一步应该往哪里查了。
FortiGate 设备的控制台可以提供这些信息。但是呢，有时候我不是要去更改配置参数，也不需要立即进入完整的管理流程，只是希望先快速了解设备当前的运行状态。
NOC for FGT 最初就是从这个很具体的需求开始的。
能登录设备，不等于已经了解设备状态
FortiGate 的 Web GUI 功能非常完整。系统状态、接口、路由、VPN、防火墙策略、日志以及各种安全功能，几乎所有管理操作都可以在其中完成。
如果准备修改策略、检查路由或者调整配置，打开完整的管理界面当然很合理。但如果有人只是告诉我“这个站点网络好像有点问题”，第一时间通常并不需要修改任何东西，而是先确认 CPU、Memory、WAN、Interface 和 Session 等几个基础状态。
这些信息虽然基础，却往往决定了接下来的排障方向。如果 WAN 已经掉线，那么问题可能并不在防火墙策略；如果接口状态正常，但 CPU 使用率或 Session 数量突然发生明显变化，就需要进一步检查设备负载和当前流量情况；如果这些指标都没有明显异常，再把排查范围逐步扩大到 DNS、上游网络、客户端或者应用本身。
因此，很多网络故障排查的第一步并不是修改配置，而是先观察设备当前的运行状态。先了解设备现在发生了什么，再决定是否需要进入 CLI、查看日志或者检查具体配置。
NOC for FGT 的信息展示密度，就从这边开始考量。
已经有 FortiManager、FortiAnalyzer 和 NMS，为什么还需要另一个工具？
FortiManager、FortiAnalyzer，以及 Zabbix、PRTG、Prometheus、Grafana 等系统，都有非常明确的用途，也各自解决了不同规模和层次的网络管理问题。
如果需要管理大量 FortiGate、集中配置策略、长期保存日志、分析历史趋势，或者为整个基础设施建立完整的监控体系，这些平台显然更加合适。我并不打算重新做一个 NMS，也没有把 NOC for FGT 设计成缩小版的 FortiManager。
因为我真正想解决的问题，比这些平台面对的问题小得多：我只是希望快速看一下某一台 FortiGate 当前怎么样。
完整的管理平台关注的是“整个网络应该如何管理”，而在日常运维中，有时候我只需要回答一个更具体的问题：眼前这台设备现在有没有什么值得注意的地方？
这两个需求虽然都属于网络管理，但使用场景并不相同。
对于大型企业环境，集中管理和监控平台依然非常重要；但对于只有一两台 FortiGate 的小型环境、实验室、Homelab，或者临时排障场景，如果只是为了快速查看设备状态，再额外部署和维护一套完整的管理或监控基础设施，复杂度有时反而会超过需求本身。原稿本身也把 NOC for FGT 定位为“轻量级 FortiGate 监控助手”，并明确说明它并不是 FortiManager 或企业级 NMS 的替代品。
因此，NOC for FGT 从一开始就没有按照“大平台”的思路设计。
为什么坚持只读
在设计 NOC for FGT 时，我一直希望它保持一个非常明确的定位：它首先是一个监控工具，而不是一个配置工具。
网络设备的配置往往直接关系到真实业务。无论是防火墙策略、路由还是接口调整，一旦操作不当，都可能影响网络的正常运行。对于一个主要用于快速查看设备状态的工具来说，如果同时加入大量配置能力，不仅会增加使用复杂度，也会带来额外的操作风险。
因此，NOC for FGT 选择把重点放在状态查看和辅助判断上。它希望帮助用户更快了解设备当前的运行情况，而不是承担完整的网络配置和管理工作。
这并不是功能上的取舍，而是一个明确的产品边界。如果一个工具的目标只是帮助管理员快速确认设备是否正常，那么首先应该把“看清当前状态”这件事做好，而不是不断增加并不属于核心场景的管理功能。
保持只读，也让 NOC for FGT 能够始终围绕最初的问题展开：
更简单、更直接地了解一台 FortiGate 当前的运行状态。
为什么选择直接连接 FortiGate
另一个较早确定下来的设计，是尽量不增加中间基础设施。
NOC for FGT 的拓扑示意：
应用直接与用户自己的 FortiGate 通信，不要求另外部署云端服务器、数据库、Agent 或中间监控节点，设备连接信息保存在本地安全存储中，这也是我选择这种架构时考虑的一个重要因素。这就是我更倾向于这种 Local-First 的方式的落地形式。
如果用户只是希望查看自己设备的当前状态，就没有必要为了完成这件事，再增加一套额外的后端系统。组件越少，部署和维护成本也越低，整个使用流程也会更加直接。
当然，这种设计本身也意味着取舍。NOC for FGT 不会像完整的监控平台一样承担集中数据存储、长期日志分析或者大规模跨组织设备管理。
但这正是它希望保持的状态：打开工具，然后直接查看自己的设备。
凭据如何保存
既然 NOC for FGT 直接连接 FortiGate，设备凭据怎么保存也是我比较在意的一件事。
目前设备数据只保存在本机，不接入云同步，也不会上传到第三方服务；其中用于登录 FortiGate 的密码会存储在 iOS 系统的 Keychain 中(加密存储)，而不是直接保存在应用自己的普通数据里。
在需要访问相关凭据时，NOC for FGT 也支持使用 Face ID 进行身份验证。这样既保留了移动端快速查看设备状态的便利，也避免为了方便使用而降低本地凭据的保护。
对我来说，Local-First 不只是“没有云服务器”，还包括一个更基本的原则：设备信息和登录凭据尽可能留在用户自己的设备里，并交给系统提供的安全机制保护。
看到 CPU 70%，然后呢？
做监控工具时还有一个很容易忽略的问题：把数据展示出来，并不等于已经帮助用户理解设备状态。
例如 CPU 使用率是 70%。单独看到这个数字，很难直接判断一台 FortiGate 是否存在异常。如果设备长期都在这一负载范围内运行，那么 70% 可能完全正常；但如果 CPU 原本一直维持在 20% 左右，最近一小时却持续上升到 70%，那么这种变化就值得进一步关注。
Session 数量也是一样。10000 个 Session 对某些设备来说可能已经非常高，对另外一些型号和业务环境而言却可能只是正常负载。
因此，我逐渐发现，比“能够显示多少数据”更重要的问题是：这些数据能不能帮助管理员理解当前状态。
目前 NOC for FGT 主要关注 CPU、Memory、Session、WAN、Interface 以及一些系统运行信息。未来如果继续增加能力，我更希望重点放在趋势和诊断上，而不是单纯在界面中加入越来越多的数字。
一个真正有价值的监控工具，不应该只告诉用户“CPU 现在是 70%”，而应该逐渐帮助用户判断“这个 70% 在当前环境下是否值得关注”。
从“查看状态”到“辅助判断”
现在回头看，我创建 NOC for FGT 并不是因为 FortiGate 缺少管理能力。恰恰相反，FortiGate 已经拥有非常完整的管理界面和成熟的企业级生态。
真正促使我开始做这个工具的，是日常运维中的另一个需求：并不是每一次打开设备，都是为了修改配置。
很多时候，我们只是收到一句“网络好像有点不对”，然后需要快速判断设备是否正常、WAN 是否在线、接口有没有异常、系统资源有没有突然变化。这些信息本身不会直接解决故障，却可以帮助我们迅速决定接下来应该检查什么。
如果需要深入排查，我仍然会继续使用 FortiGate Web 管理界面、CLI、日志或者其他专业平台。NOC for FGT 并不打算替代它们。
我更希望它成为排障过程前面的一个观察入口。
当我只是想知道：
“这台 FortiGate 现在到底怎么样？”
不必先进入一整套复杂的管理流程，就能够快速得到一个基本判断。
对我来说，这就是 NOC for FGT 最初想解决的问题，也是它需要继续保持简单的原因。
试用 NOC for FGT
如果你也希望用更简单、更直接的方式查看 FortiGate 当前的运行状态，可以访问 NOC for FGT 官方网站：
