Monitor Sangfor HCI, SCP, every VM and every node with Zabbix - templates

Most people who try to monitor Sangfor HCI with Zabbix stop at the same place: a couple of SNMP items on the physical node, and nothing about the virtual machines running on it.

This post closes that gap. Attached are four ready-to-import Zabbix templates that monitor a Sangfor HCI cluster, the SCP management platform, EVERY VIRTUAL MACHINE as its own Zabbix host, and EVERY PHYSICAL NODE as its own Zabbix host. Tested in production against Sangfor HCI 6.11.3 / SCP 6.11 with Zabbix 7.2.7.

Free to use and adapt. No warranty; not an official Sangfor or Zabbix product.


=== WHAT THE TEMPLATES MONITOR ===

[1] Sangfor HCI by SNMP - one Zabbix host per physical node
CPU, memory, disk usage, filesystems, physical NICs and negotiated speed, fans, power supplies, temperature sensors, optical module Rx/Tx power, SSD life, datastores and chassis inventory (model, serial, BIOS, BMC).

[2] Sangfor SCP by API - one Zabbix host for the management platform
Cluster CPU/memory/storage capacity and overcommit, node status and health, license status and expiry, storage pools, and the SCP's own alarms as Zabbix problems.

[3] Sangfor VM by SCP - one Zabbix host per virtual machine
Power state, uptime, CPU %, memory used/total, read/write IOPS, network throughput, provisioned and used storage, IP and MAC, whether Sangfor Tools is installed, one entry per virtual NIC and per virtual disk, and which physical node runs it.

[4] Sangfor Node by SCP - one Zabbix host per physical node, as the SCP sees it
Node status, CPU %, memory used/total, storage capacity, disk subsystem state (normal / alert), SSD remaining life, node alarm count, IP, serial number and cluster. No SNMP and no agent: it appears on its own.

How they fit together:

   Sangfor HCI by SNMP  -->  host per physical node  (SNMPv3, port 161, created by hand)

   Sangfor SCP by API   -->  host for the platform   (REST API, port 4430)
                                   |
                                   |-- discovers the VMs    -->  Sangfor VM by SCP
                                   |                             one host per VM
                                   +-- discovers the nodes  -->  Sangfor Node by SCP
                                                                 one host per node

You never assign the VM or Node template by hand: the SCP template's two HOST PROTOTYPES do it through low-level discovery. Anything created in the SCP shows up on its own, and anything that disappears from inventory raises an alarm instead of quietly going dark.

[1] and [4] are not redundant: two views of the same machine. The SNMP one sees the HARDWARE and you create it by hand; the SCP one sees what the platform knows and appears on its own.


=== THE ONE THING THAT COSTS EVERYONE AN AFTERNOON: THE HCI SNMP AGENT IS v3-ONLY ===

Search this community for "Zabbix" and you land on the same advice we did: "HCI supports SNMP" and "make sure port 161 is enabled." Both true. Neither is why your polling fails.

Point SNMPv2c at a Sangfor HCI node with any community string and you get a SILENT TIMEOUT. No refusal, no error: exactly what a closed firewall port looks like, so you check the firewall, then the ACL, then the community, then you open a ticket. The port was never the problem. The agent does not answer v2c at all. Switch to SNMPv3 and it answers on the first try.

Confirm it in ten seconds:

  # v2c: no response at all (the misleading part)
  snmpget -v2c -c public <hci-ip> .1.3.6.1.4.1.35047.3.2.1.1.0

  # v3: completes the engineID handshake, returns the HCI version
  snmpget -v3 -l authPriv -u admin -a SHA -A '<auth>' -x AES -X '<priv>' <hci-ip> .1.3.6.1.4.1.35047.3.2.1.1.0

Two more details that cost us time: enable it under System > Advanced > SNMP Settings > SNMP Transmission > Configure, where the user is admin and NOT editable; and choose SHA + AES, because the MD5/DES defaults did not work for us. The dialog never re-displays saved passphrases, so write them down before closing it.

The enterprise MIB tree is .1.3.6.1.4.1.35047.3.2.1 (sangfor.cloud.cProduct.aCloud).


=== NO EXTERNAL SCRIPT REQUIRED ===

Data collection is a native Zabbix SCRIPT item with the AWS4-HMAC-SHA256 signature written in plain JavaScript inside the item. Nothing to install on the proxy, no cron, no external check, no file on disk.

Why the signature is hand-rolled instead of Zabbix's hmac() and sha256(): those encode their arguments as UTF-8, and the AWS4 key derivation produces raw bytes, about half of them >= 0x80, which get mangled. The SCP then answers "401 Authorization for EC2 is invalid". Worth knowing before anyone "simplifies" it back to the built-ins.

Because that signing code is hand-written, the package ships a self-test: item sangfor.crypto.selftest runs the official FIPS 180-4, RFC 4231 and AWS SigV4 vectors inside the same JS engine that signs the requests, hourly, and alarms if any stops matching. No network and no credentials, so it can only fail for one reason.


=== IP ADDRESSES WHERE YOU CAN ACTUALLY USE THEM ===

Every discovered host carries its IP in the Zabbix inventory (Host networks) and as an "ip" tag, so you can search and filter by address straight from the host list. Nodes also publish their serial number to the inventory - what you need to open a warranty case without walking over to read the label - and the cluster they belong to. VMs publish MAC and OS.

One measured warning: the IP the SCP reports for a NODE is not necessarily the management IP you poll it on over SNMP. On our reference cluster, the node managed over SNMP on one address shows up in the SCP with a different one, its second NIC. Use it to identify the machine, not to build the SNMP interface. Nodes that are not HCI return it empty.


=== ALERTING DESIGN: ONE INCIDENT, ONE NOTIFICATION ===

With one Zabbix host per VM and one per node, an SCP outage could easily mean N identical alarms at 3am.

The templates ship a dependency cascade with staggered windows - root 15m < inventory 20m (VMs) / 30m (nodes) < per-object 45m - hanging off two ROOT triggers: "API/probe unreachable", and an INTERNAL item watching the proxy itself, which the server evaluates even when the proxy is dead. Inside each node host there is a second, local cascade rooted at "node is NOT running", so a downed node is one problem and not five.

One manual step the YAML cannot carry: a template cannot depend on a trigger of another host, so the per-object dependencies get wired by API after importing and after each batch of new VMs or nodes. The README explains how. Skipping it turns one outage into N pages.


=== INSTALL, SHORT VERSION ===

1. Create the host groups "Sangfor/Discovered VMs" and "Sangfor/Discovered nodes" BEFORE importing: the host prototypes reference them and the import does not create them.
2. Import in this order: VM by SCP, Node by SCP, SCP by API, HCI by SNMP. The two per-object templates go FIRST, because the SCP one links them by name; the other way round Zabbix drops the link in silence and every discovered host is born with no template.
3. HCI host: SNMPv3 interface (authPriv, SHA, AES) plus the three {$SNMPV3_*} macros as Secret text. SCP host: NO interface, plus the {$SCP.API.*} macros (both keys as Secret text).
4. Wait. The VMs and the nodes show up as hosts on their own, with the parent's macros propagated automatically, secrets included.

Full instructions, macro reference and tuning table are in the README inside the attachment.


=== WHAT WE FIXED, AND WHERE IT CAME FROM ===

Earlier revisions shipped with real defects. Several were found because people in this community pushed on details instead of nodding along; the rest turned up when we stopped trusting our own checks and started installing the package from scratch on an empty Zabbix. In short:

- The packaging produced YAML with folded long strings. Zabbix's importer resolves those differently and injects a space at every fold point, corrupting string literals - including the one that gets signed. The import reports success and then nothing collects. The build now emits literal blocks and compares every Script item's code byte for byte against the file after importing it for real.
- Object uuids were not v4, so the whole file was rejected. And trigger expressions referenced a template name that did not exist, which Zabbix imports "successfully" while dropping those triggers silently.
- Alarm triggers whose name went past 255 characters were never created. The discovery rule stayed green and only some triggers were missing - the disk ones, of course. Names are bounded now and the full text lives in the trigger description.
- The per-VM master item identified its VM by the technical host name, so renaming a host left it green, with all its items, and no data. It uses a macro now.
- Node alarms used to fire on the SCP host with the node name buried in the trigger text. Nodes have their own host now.

If an OID behaves differently on your firmware, if a threshold is wrong for your workload, or if you extend the templates, post it here. That is exactly how the list above got shorter.


---
(c) 2026 Yerko Umana Parra - T-Line. Free to use, adapt and redistribute, with attribution.
Provided as-is, without warranty of any kind. Not an official Sangfor or Zabbix product;
Sangfor and Zabbix are trademarks of their respective owners.