运维与排障
日常看哪里、积压上涨怎么办、某个组件挂了会怎样、42901 从哪来。
采集状态页
「系统 → 采集状态」只有管理员能看，任意一台进程都能回答。
| 区域 | 内容 |
|---|---|
| 顶部三个数 | 采集队列积压、近 1 分钟入库速率、离线节点数 |
| 节点表 | 节点名（主机名）、版本、最近心跳、待处理条数、最后一次错误。心跳超过 15 秒标黄；心跳消失的节点不再显示 |
| 失败事件 | 被 ClickHouse 拒绝的事件：时间、项目、原因、正文前 200 字。只读 |
每个节点每 5 秒在 Redis 里报一次心跳。滚动升级时，节点表里会短暂同时出现新旧两个版本，这是正常的。
积压持续上涨
积压是已经返回成功、还没写进 ClickHouse 的事件条数，也显示在概览和 /health 的 ingest_lag。短时间的起伏正常，持续上涨时按顺序看：
- 看分片状态：「系统 → 分片」里有没有
down的分片。分片连不上时，发往它的批次写不进去，会一直积压。 - 看失败事件：是不是某类事件一直被拒绝。单条被拒绝的事件会转进失败事件表，不会堵住队列；但整批反复失败时要看原因。
- 看节点：是不是有节点离线，剩下的节点忙不过来。加一台进程是最直接的办法，见 多节点与分片。
- 临时调大攒批：在「系统配置 → 采集调优」里调大
ingest.batch_size（默认 1000）。每次写入更多条，写入次数更少，代价是数据出现在报表上更慢。
积压超过 ingest.stream_max（默认 100 万）时，新的上报会被拒绝，返回 42901，用来保护 Redis。SDK 收到 429 会退避重试。
某个分片挂了
- 只有落在这个分片上的项目查询失败（
50301），别的项目照常。 - 采集照常写进 Redis 队列，这些项目的积压上升；分片恢复后自动写入。
- 积压顶到
ingest.stream_max之后，所有上报都会被拒绝。分片长时间起不来时，先关掉这些项目的采集开关。
Redis 挂了
- 登录会话、采集队列都在 Redis 里，所以登录和采集都会停：后台进不去，
/sa返回错误，SDK 会把事件留在本地队列里重试。 - 已经写进 ClickHouse 的数据不丢。Redis 恢复后一切照常。
- Redis 自己丢了数据时，已经返回成功但还没入库的那一段会丢。所以生产环境要打开 AOF 并备份，见 备份与恢复。
- 统计结果缓存也在 Redis，Redis 不可用时查询直接走 ClickHouse，不影响数字。
ClickHouse（s0）挂了
s0 存着账号、项目和配置。它连不上时进程启动会失败；运行中断开时 /health 返回 503，后台不可用。恢复后照常。
42901：太频繁或超限
42901 对应 HTTP 429，有五个来源：
| 来源 | 触发 | 怎么处理 |
|---|---|---|
| 登录失败过多 | 同一用户名、同一 IP 10 分钟内失败 10 次 | 等 10 分钟再试；登录成功后计数清零。多人共用出口 IP 时各用各的账号 |
| OpenAPI 超频 | 同一把接口密钥全集群每分钟超过 60 次 | 调用方加缓存或降频；多个系统各建一把密钥 |
| 发信过频 | 同一用户 1 小时内申请重置邮件超过 3 封 | 等一小时，或者让管理员直接重置密码 |
| Agent 当日次数用完 | 超过 ai.user_daily_limit（默认 200，演示用户看 demo.agent_daily_limit） | 次日恢复；需要时管理员调大，填 0 不限 |
| 采集队列达到上限 | 积压超过 ingest.stream_max | 按上面「积压持续上涨」排查；SDK 会自己退避重试 |
失败事件
单条事件被 ClickHouse 拒绝、但 JSON 本身合法时，写进失败事件表后确认，不会堵住队列；一整批连续失败 5 次，也整批转进失败事件表。失败事件在采集状态页的下方，默认近 7 天，正文截断到 4KB，不含写入密钥。它们不会自动重放。
指标
GET /metrics 是 Prometheus 文本格式，只放过程指标，只对内网开放。它不是功能依赖，不接 Prometheus 也不影响任何功能。
| 指标 | 类型 | 标签 |
|---|---|---|
evstats_ingest_lag | gauge | |
evstats_ingest_rows_total | counter | shard |
evstats_ingest_errors_total | counter | shard |
evstats_collect_requests_total | counter | code |
evstats_collect_dropped_total | counter | reason |
evstats_query_seconds | histogram | module |
evstats_stat_cache_hits_total | counter | |
evstats_agent_requests_total | counter | code |
标签里没有 IP、项目名和用户名。
日志
进程把日志写到标准输出，由 Docker 或 systemd 收集。级别在「系统配置 → 日志」的 log.level：debug、info、warn，改完所有进程立即生效。debug 的量很大，排障完改回 info。
日志里不会出现密码、ClickHouse 与 Redis 连接里的口令、密钥全文和 Cookie；访问日志只记路径、状态、耗时、字节、request_id 和节点名，不记查询参数。
界面上的每个错误提示都带 request_id，用它在日志里就能找到对应的那一条请求。
停机与重启
对进程发 SIGTERM：停止接收新的上报，把内存里的批次写进 ClickHouse 并确认，最多等 15 秒。Docker 的 docker compose stop 和 systemd 的 systemctl stop 发的都是 SIGTERM。