直接用topk(5, rate(node_network_receive_bytes_total[1m]))可快速识别接收流量最高的5个节点，但需结合阈值判断、白名单过滤、突增检测、错误率关联及标签筛选才能准确定义并响应高危节点，PromQL仅负责数据发现，阻断需联动告警与自动化执行。
直接用 topk(5, rate(node_network_receive_bytes_total[1m])) 就能快速识别过去1分钟内接收流量最高的5个节点，但“盘点+阻断高危节点”不能只靠这一个查询——它只是起点。真正实现秒级响应，需结合指标含义、阈值判断、上下文过滤和联动动作，否则容易误杀或漏判。
明确“高危”的定义，避免把正常大流量当威胁
单纯按流量排序会把CDN边缘节点、大数据传输服务器、备份网关等误标为“高危”。必须叠加业务语义：
- 排除已知白名单：如
node_network_receive_bytes_total{job="node-exporter", instance=~"cdn-.*|etl-.*"} - 关注异常突增：用
rate(...[1m]) / avg_over_time(rate(...[1h])[1h:]) > 3找出同比突增3倍以上的节点 - 结合错误率：高流量 + 高丢包（
rate(node_network_receive_drop_total[1m]) > 100）或高重传（TCP层指标），才更可能是扫描、DDoS或配置错误
用 topk/bottomk 快速聚焦，但必须带标签筛选
topk 和 bottomk 本身不做过滤，输出的是原始时间序列。要准确定位到“节点”，必须保留关键标签：
- ✅ 推荐写法：
topk(5, rate(node_network_receive_bytes_total{job="node-exporter"}[1m]))—— 明确 job，避免混入其他 exporter 数据 - ✅ 加上实例维度：
topk(5, rate(node_network_receive_bytes_total{job="node-exporter"}[1m]) * on(instance) group_left(node_name) node_uname_info)，可同时查出主机名 - ❌ 避免裸用：
topk(5, rate(node_network_receive_bytes_total[1m]))—— 若有多个 job 或无 instance 标签，结果无法对应到具体机器
从“看到”到“阻断”，PromQL 只负责前半程
PromQL 本身不执行阻断操作，但它可作为告警触发器或自动化脚本的数据源：
- 在 Alertmanager 中配置规则，例如：
expr: topk(5, rate(node_network_receive_bytes_total{job="node-exporter"}[1m])) > 100 * 1024 * 1024 # >100MB/s
触发后调用 webhook，由运维平台自动执行iptables -A INPUT -s ${instance} -j DROP或下发SDN流表 - 用 curl + jq 快速手动干预（应急时）：
curl -s 'http://prom:9090/api/v1/query?query=topk(5%2C+rate(node_network_receive_bytes_total[1m])[1m%3A10s])' | jq -r '.data.result[].metric.instance'
输出 IP 列表，再批量封禁
补充 bottomk：用于发现“该传却没传”的静默故障节点
高危不止是“流量过大”，也可能是“该通信却不通信”，比如心跳中断、服务僵死：
- 查最近1分钟零接收的节点：
bottomk(5, rate(node_network_receive_bytes_total[1m])) == 0 - 结合 uptime 判断是否真宕机：
rate(node_network_receive_bytes_total[1m]) == 0 and node_time_seconds - node_boot_time_seconds （刚启动但无网络收包，大概率网卡/配置异常） - 这类节点虽不耗流量，但属于业务断连风险点，需同步纳入处置流程
