Fortinet

FortiOS SNMP configuration follows the standard FortiOS CLI pattern - config/edit/set/next/end - under system snmp.

General settings

config system snmp sysinfo
    set status enable
    set description "Edge firewall"
    set contact-info "[email protected]"
    set location "Rack 4, DC1"
end

SNMPv1/v2c (communities)

config system snmp community
    edit 1
        set name "public"
        set query-v2c-status enable
        set trap-v2c-status enable
        config hosts
            edit 1
                set ip 192.168.1.100 255.255.255.255
            next
        end
    next
end

Each community is its own numbered entry, with query and trap enabled/disabled independently per SNMP version - and a nested hosts table naming exactly which managers this community is valid for, rather than a single global allow-list.

SNMPv3

config system snmp user
    edit "MYUSER"
        set security-level auth-priv
        set auth-proto sha
        set auth-pwd MYAUTHPASS
        set priv-proto aes
        set priv-pwd MYPRIVPASS
        set notify-hosts 192.168.1.100
        set queries enable
        set trap-status enable
    next
end

Choosing which events send traps

Rather than a blanket "enable all traps" switch, FortiOS lets you pick specific event categories per community or per v3 user:

config system snmp community
    edit 1
        set events cpu-high mem-low ha-switch fan-failure power-supply-failure
    next
end

The full event list is extensive - CPU/memory thresholds, HA state changes, IPS/AV signature updates, hardware sensor failures, and many more - set events ? at the CLI on the actual device shows the complete, version-specific list.

Model/platform differences

The CLI syntax above is consistent across FortiGate hardware models and VM instances - FortiOS's configuration model doesn't fork by platform the way some vendors' does. What varies by model is which hardware-sensor events are actually meaningful: a VM instance obviously has no fan or power-supply sensors to report on, so those event options exist in the config but have nothing to trigger them. FortiGate's own hardware sensor table (fgHwSensorTable) is likewise sparse or empty on virtual appliances.

Common OIDs and MIBs

Everything Fortinet-specific lives under enterprises.12356 (1.3.6.1.4.1.12356) - but see the gotcha below before picking a CPU/memory OID, since there are genuinely two, incompatible generations of those specifically.

• CPU and memory (current) - FORTINET-FORTIGATE-MIB. fgSysCpuUsage (1.3.6.1.4.1.12356.101.4.1.3.0) and fgSysMemUsage (1.3.6.1.4.1.12356.101.4.1.4.0) are the current, recommended objects, matching what get system performance status shows at the CLI.
• High availability - fgHaStatsTable (under 1.3.6.1.4.1.12356.101.13). Reports per-cluster-member statistics including fgHaStatsMemUsage - a distinct value from the single unit's own fgSysMemUsage, and worth polling separately if the full cluster's health matters, not just whichever member happens to answer a given SNMP request.
• Per-VDOM resource usage - fgVdTable (under 1.3.6.1.4.1.12356.101.3). On a device with virtual domains enabled, fgVdEntCpuUsage and fgVdEntMemUsage break resource usage down per VDOM - see the gotcha below, since the device-wide fgSysCpuUsage/fgSysMemUsage objects don't reflect this breakdown at all.
• Hardware sensors - fgHwSensorTable, already mentioned above for the VM/hardware platform difference - fan speed, temperature, and power supply status on models that expose it.

Gotchas and platform-specific nuances

There are two, entirely separate generations of CPU/memory OIDs, and mixing them up is a genuinely common mistake. An older, legacy MIB (unofficially referred to as FORTINET-MIB-280 in some tooling) defines fnSysCpuUsage and fnSysMemUsage directly under 1.3.6.1.4.1.12356.1 - OIDs .8 and .9 respectively. The current FORTINET-FORTIGATE-MIB defines a completely different pair, fgSysCpuUsage and fgSysMemUsage, several branches deeper at 1.3.6.1.4.1.12356.101.4.1.3.0 and .4.0. Real support threads show people trying the older, shorter OIDs against current-generation hardware and getting "unsupported OID" back, or trying pre-built MIB templates from an old monitoring integration that were never updated for the newer namespace. If a CPU or memory OID that "used to work" suddenly returns nothing after a hardware refresh, checking which of these two generations a given monitoring template or integration was actually built against is the first thing worth checking - both still coexist on current firmware, but only one of them is the one Fortinet's own documentation and CLI commands actually track today.

VDOM-enabled devices need the per-VDOM table, not the device-wide OIDs, for meaningful resource data. fgSysCpuUsage and fgSysMemUsage report the whole physical device's usage - on a FortiGate carved into several virtual domains, that single device-wide number doesn't tell you which VDOM is actually driving load. fgVdEntCpuUsage/fgVdEntMemUsage in the per-VDOM table give that breakdown, indexed by VDOM rather than by the device as a whole - worth switching to explicitly on any multi-VDOM deployment, rather than assuming the device-wide figures are granular enough.

A cluster member's own OIDs don't necessarily represent the whole HA cluster. Polling fgSysMemUsage against a cluster's shared/virtual IP gets you whichever unit currently answers that address - not necessarily a meaningful "cluster" figure, and not guaranteed to be the same unit from one poll to the next if a failover happens between them. fgHaStatsMemUsage in the dedicated HA stats table reports figures per named cluster member instead, which is the more reliable way to monitor an HA pair's health as two distinct units rather than one ambiguous, address-based target.