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.

relationship-gtpc-user derives a single per-subscriber correlation key as Hashkey = md5(IMEI + IMSI + phone_number + vsys_id) from mobile-core GTP-C signaling, and a separate per-tunnel key gtp_uuid = md5(uplink_teid + "|" + downlink_teid). On every update it writes not just the primary user<->TEID row (tsg_galaxy:relation_user_teid) but up to four additional secondary-index rows into tsg_galaxy:gtpc_knowledge_base, one per identifier (IMEI, IMSI, phone number, APN) with a type-digit prefix ("0"/"1"/"2"/"3") and — for phone number and APN — the value's characters reversed before use as the row key, a range-scan-friendly key design that lets any of the four identifiers be used to look up the associated tunnel/session independently.

log-subscriber-hbase-datacenter is a Storm topology that, on a 300-second tick, scans a "national center" HBase cluster (national.hbase.zookeeper.servers) for subscriber_id/account rows changed in that window and replicates them into a separate "branch/regional datacenter" HBase cluster (center.hbase.zookeeper.servers, table sub:subscriber_info) — confirming a two-tier, hub-and-spoke data-federation architecture where subscriber-account correlation data is centrally maintained at a national level and periodically pushed down to per-datacenter local copies for regional/site-level querying.

radius-relationship-hbase and relationship-gtpc-user both ship byte-identical plaintext, hardcoded Kafka SASL credentials (a fixed admin username, product-branded password) in their default_config.properties — the same static credential shared verbatim across at least two independent TSG-OLAP pipeline components rather than injected per-deployment.

radius-account-knowledge decrypts its Kafka SASL credentials at runtime using a jasypt StandardPBEStringEncryptor whose password is the hardcoded literal string "galaxy", compiled directly into RadiusKnowledgeConfig.java — the same string used as the internal product/platform name throughout this corpus (Galaxy / tsg_galaxy HBase namespace), reused here as a shared symmetric secret rather than a deployment-specific one.

radius-relationship-hbase (galaxy/tsg_olap) builds a bidirectional, MD5-keyed RADIUS accounting index in HBase — a framed-IP-to-account table and its account-to-IP mirror — so any subscriber account or assigned IP can be looked up in O(1) from either direction, per multi-tenant vsys_id. Each direction is fronted by a Guava write-through cache (10M-entry cap, 24h TTL) so lookups do not hit HBase on the hot path.