Nezha (哪吒)
Internal data-center/rack asset-management and infrastructure monitoring platform -- physical topology (机房/data center, 机柜/rack, U-slot) inventory, node/node-group management, business- system and user-group permissions, and monitoring/alert configuration (nz-agent, nz-confagent report to a central nezha-fronted/nz-web service). Distinct from the unrelated open-source "nezha" server-monitoring project of the same name -- this is Geedge/MESA's own internal ops tooling, not a traffic-inspection or censorship-detection capability itself, but its rack/site inventory and per-deployment monitoring dashboards (e.g. "nezha_monitor_K18") are useful corroborating evidence of physical deployment footprint and scale.
Nezha's nz-confagent implements a two-tier, per-data-center Prometheus monitoring federation: each "prom_server" row is typed either center (type=1) or sub (type=2) and scoped to an idc_id (data center). A central node's job auto-generates a federate scrape_configs block that pulls from every sub server's :9090/federate endpoint plus alerting/Alertmanager config assembled from DB tables, while each sub-node's job queries all exporter endpoints registered for its own idc_id and self-assigns roughly 1/N of them via a modulo split across the sibling sub-Prometheus instances in that data center, then rewrites the local prometheus.yml on disk. This confirms Nezha (and by extension the TSG deployments it monitors) operates across multiple physical data centers with enough per-site monitored endpoints to require horizontal splitting of scrape load within a single site, not just a single flat Prometheus instance.
Nezha's internal DB schema doc (neza数据库定义.md) shows the platform tracks physical infrastructure down to individual rack-unit placement: NODE_ROOM (机房/data center) has a row/column grid; NODE_CABINET (机柜/rack) is placed at a specific room_row/room_col within a room and records total U-slot capacity (ubit); NODE_INFO (each monitored server or network device) records its exact cabinet_id, u_size, and cabinet_start position within that rack, plus per-device SNMPv3 polling credentials (user_name, password, snmp_port, snmp_community) stored directly in the table. This is a full physical asset-inventory model, not just a logical/IP-based node list, corroborating that Geedge/MESA maintains precise rack-level hardware inventories for its (and its customers') data-center footprint.