IRIS的/api/monitor/alerts接口需增量拉取且配合本地记录点，避免漏告警；必须用since参数（2023.1+支持）或客户端去重，响应为含id/timestamp/severity/message的JSON数组，空响应不表示无告警。
IRIS 的 /api/monitor/alerts 接口怎么用才不会漏告警
直接轮询 /api/monitor/alerts 是常见做法，但容易因“无新增就返回空”而误判为“无告警”。这个接口本质是**增量拉取**：只返回自上次调用以来新产生的系统告警，且不带时间戳、不保留历史。如果两次请求间隔过长，中间的告警可能被后续请求覆盖或丢失（尤其在高频率告警场景）。
实操建议：
- 必须维护一个本地记录点（例如 Redis 中的
last_alert_fetch_time），每次请求后更新为当前时间，下一次带上?since=xxx参数（注意：IRIS 2023.1+ 版本才支持该参数；旧版本只能靠轮询 + 客户端去重） - 不要依赖 HTTP 状态码判断是否有告警——它永远返回 200，空响应体不等于“一切正常”
- 响应体是 JSON 数组，每个元素含
id、severity、message、timestamp字段，timestamp是 IRIS 服务端生成时间（ISO8601 格式），不是客户端请求时间 - 若发现重复
id，说明服务端未做幂等，需在客户端做基于id的去重缓存（例如用 LRUMap 缓存最近 1000 条）
如何把 IRIS 告警接入 Prometheus + Alertmanager
IRIS 原生支持 Prometheus 格式的 /api/monitor/metrics，但 /alerts 不是指标流，不能直接被 scrape。强行把告警转成指标（如 iris_alert_count{severity="error"}）会丢失上下文，也不符合告警生命周期管理逻辑。
正确路径是走「双通道」：
- 用 Prometheus 定期抓取
/api/monitor/metrics（推荐间隔 15s），监控iris_system_alerts_total这类内置计数器，但它只反映累计量，无法触发精准告警 - 单独起一个轻量采集器（例如用 Python 写个
iris-alert-poller），定时调用/api/monitor/alerts，解析后通过 Alertmanager 的/api/v1/alertsREST 接口主动推送告警事件（注意：必须带startsAt和endsAt，否则 Alertmanager 会拒绝） - 避免在采集器里做复杂聚合或抑制逻辑——交给 Alertmanager 的
inhibit_rules和route配置更可靠 - 采集器自身要可监控：暴露
/healthz和/metrics，记录 last_fetch_status、fetch_latency_ms、alert_push_success_total 等指标
IRIS 告警内容里哪些字段真正可用于自动化处理
IRIS 返回的告警 JSON 看似结构化，但部分字段在不同版本中含义不稳定。实测（基于 2025.2 LTS 版本）以下字段最可靠：
-
id：全局唯一字符串，格式类似"ALERT-20260911-142305-789"，可用于去重和关联日志 -
severity：固定为"info"、"warning"、"error"或"critical"，是路由和通知级别的唯一依据 -
source：通常是模块名，如"%SYS.Monitor"或"User.MyApp"，可用于按业务域过滤 -
message：人类可读描述，但含变量占位符（如"Connection to %1 failed after %2 retries"），不适合正则提取结构化数据 - 慎用
category和code：前者值不规范（有时为空，有时为"System"），后者是内部错误码（如5002），文档未公开映射表，不宜作为决策依据
为什么用 SNMP 监控 IRIS 告警反而更稳定
当你的运维栈已重度依赖 SNMP（比如 Zabbix、SolarWinds 或传统网管平台），直接对接 IRIS 的 SNMP 子代理（iscsnmp.dll on Windows / AgentX on Linux）比 HTTP API 更可靠——它不经过 Web 服务器层，绕开了 Apache/Nginx/Tomcat 的配置、TLS 终止、连接池耗尽等问题。
关键细节：
- IRIS 的 SNMP MIB（
ISC-IRIS.mib）中，告警对应 OID1.3.6.1.4.1.1658.2.2.1.1.10（irisAlarmTable），每条 trap 包含irisAlarmSeverity、irisAlarmMessage、irisAlarmTimestamp - SNMP TRAP 是推模式，无需轮询，天然解决“拉取间隔导致的告警丢失”问题
- 但 Windows 下必须使用
iscsnmp.dll，不能直接跑 Net-SNMP agent；Linux 下需确认主代理启用 AgentX 支持（agentxSocket /var/agentx/master） - TRAP 本身无重传机制，网络丢包会导致告警丢失——必须在接收端（如 Zabbix）开启 trap 日志并配置重试队列
HTTP API 灵活但脆弱，SNMP 滞重但稳。选哪个，取决于你是否愿意为告警的“最终可达性”多扛一层基础设施复杂度。
