LLD 自动发现场景 → 对应使用哪种探测方式（SNMP/HTTP/Agent）最优
7 大 LLD 核心场景 → 最优探测方式（最常用、最稳定）
下面按“你实际工作中最常见的 LLD 场景”来分。
1. 网络接口（交换机、路由器、防火墙、AP）
推荐最优：SNMP agent（IF-MIB / ETHERLIKE-MIB）
原因
- 接口数量多（24/48 口），LLD 批量发现天生适配
- SNMP 是网络设备最原生、最稳定的发现方式
- 设备端性能消耗低（不会因为遍历接口就宕机）
- 新增/删除端口 → 自动增减监控项
不推荐
- HTTP：太重，且大部分网络设备不提供开放接口
- Agent：不存在（网络设备没有 Zabbix Agent）
2. 文件系统/磁盘（Linux、Windows、服务器）
推荐最优：Zabbix Agent / Agent2
原因
- 本地采集速度快、耗资源少
- 磁盘、分区、挂载点变化频繁（LLD 最适合这种动态）
- 本地脚本返回结构化数据最稳定
其他方式
- SNMP：可以，但不推荐，因为不同系统 SNMP 枚举磁盘不稳定
- HTTP：没必要，几乎没有服务器开放磁盘枚举接口
3. 服务器硬件传感器（温度、风扇、电源、RAID、硬盘）
推荐最优：SNMP（iDRAC/ILO/IPMI 或服务器厂商 MIB）
原因
- 服务器硬件状态天然适合 SNMP 枚举
- 不同型号硬件列表变化大 → LLD 自动发现是刚需
- 厂商 MIB 都自带“硬件状态表”
不推荐
- Agent：数据来源有限，不如 SNMP 全面
- HTTP：太多厂商没有开放 API
4. 光模块/SFP/板卡/存储设备
推荐最优：SNMP（SFP-MIB、厂商私有 MIB）
原因
- 几乎所有交换机/存储都支持 SNMP 枚举光模块
- LLD 自动发现 SFP/QSFP 状态非常稳
- 光模块数量不固定 → LLD 自动新增/删除监控项
不推荐
- HTTP/API：很多老旧设备不提供
- Agent：不适用
5. Docker、Kubernetes、容器环境
推荐最优：Zabbix Agent2（或 Kubernetes API 依赖监控）
原因
- 容器数量动态变化 → 必须 LLD
- Agent2 能本地发现容器、Pod、镜像
- K8s 用 API 发现更稳（但 SNMP 不适用）
其他方式
- SNMP：不适用，容器不暴露 SNMP 硬件表
- HTTP：需额外暴露指标接口（如 cadvisor）
6. 数据库多实例/进程/端口
推荐最优：Agent + 脚本（Shell/Python）或 HTTP 接口
原因
- 实例数量可能动态变化（MySQL、Redis、Tomcat）
- Agent 本地获取进程数量更稳
- 数据库一般有专用 API（如 MySQL:
show databases）
不推荐
- SNMP：数据库基本不支持 SNMP 发现实例
7. 云平台/API 资源（阿里云、腾讯云、AWS、内部平台）
推荐最优：HTTP（调用 REST API）
原因
- 云资源本身就是 API 驱动
- 云主机、负载均衡、数据库实例变化频繁 → LLD 最佳匹配
- JSON 预处理非常适合解析 API 返回
不推荐
- SNMP：云产品不暴露
- Agent：无法运行在云资源抽象层
二、最终速查表（最有用）
我把它做成直接可落地的选型表，你一看就会用。
| 监控对象 | 最优探测方式 | 原因 |
|---|---|---|
| 网络接口（交换机/路由器） | SNMP | 稳定、批量、设备原生支持 |
| 磁盘/文件系统 | Agent/Agent2 | 本地采集最快最稳 |
| 服务器硬件（温度/风扇/RAID） | SNMP | 厂商 MIB 提供硬件枚举 |
| 光模块/SFP/存储柜 | SNMP | 设备原生支持 SFP-MIB |
| Docker/K8s 容器 | Agent2 / Kubernetes API | 动态环境必备 |
| 数据库实例/进程 | Agent（脚本）或 HTTP | 实例动态变化 |
| 云平台资源 | HTTP/API | 完全由 API 驱动发现 |
| 固定指标（无需 LLD） | 直接监控项 | 性能更好更稳 |
三、最关键的总结（3 句话）
- 网络设备 → 一律 SNMP（最稳定、最轻量）
- 服务器本地资源 → 一律 Agent（速度快、兼容性好）
- 动态变化的对象（接口、磁盘、容器、云资源）→ 必须 LLD