学习夜莺的前置知识
先掌握日志、进程、时序数据、PromQL 与采集链路，再按现象定位采集、存储、告警和通知问题。
最后校对于
读完这页，你会知道使用夜莺前需要掌握什么，并能把“没数据”“没告警”“没通知”拆成具体环节排查。
Linux 与部署基础
二进制部署需要知道进程工作目录、配置文件位置、stdout / stderr 和 systemd 服务。
容器部署需要知道端口映射、挂载目录、容器日志，以及容器内的 127.0.0.1 指向哪里。
sudo journalctl -u n9e.service -n 100 --no-pager
sudo journalctl -u categraf.service -n 100 --no-pager
服务名按实际安装修改。预期结果：能看到所排查进程的近期日志；如果没有该服务单元，换成实际运行方式的日志入口。
时序数据模型
- 指标名描述测量对象，比如 CPU 使用率。
- 标签区分主机、服务和实例；指标名与标签组合标识一条时序。
- 时间戳与数值是一条样本。主机时钟错误会让数据落到错误时间范围。
- Gauge 表示当前值；Counter 表示累计值，计算速率时要考虑重启归零。
- Histogram / Summary 不是一个普通数值，查询时需要理解桶、计数和求和。
避免把每次请求的唯一 ID 当作标签。更多概念见 Prometheus 数据模型。
PromQL
先能做三件事：按标签选择时序、对 Counter 计算 rate()、按需要聚合多个实例。
指标阈值应建立在数据语义上，不能把累计计数直接当每秒请求量。
Instant query 返回某个时刻的结果，Range query 返回一段时间内的序列；查询时间范围和步长影响展示。 在即时查询验证表达式，再放到指标告警规则里。 表达式说明见 Prometheus 查询文档。
Pull 与 Push
Prometheus / vmagent 的抓取是 Pull：采集端知道一次抓取是否成功，可以产生 up。
Categraf Remote Write 是 Push：采集器主动发送指标，不能把它的链路直接套成抓取 up 的判断。
夜莺 v9 可以使用内置时序库，也可以查询外置存储。已有 Prometheus 数据时，接数据源即可，不必迁移数据。 心跳元信息与时序写入也是两条不同链路，见 Linux 机器监控。
排查与提问
先确定哪条链路出了问题：
- 采集器本地有没有样本？
- 样本有没有送到正确存储？
- 夜莺查询的是不是该数据源？
- 规则判定有没有产生事件？
- 事件有没有被屏蔽、过滤或处理？
- 通知发送是否成功？
提问时附组件版本、部署方式、预期与实际现象、问题时间段、最小配置和相关日志。 配置与日志中的密码、Token、真实用户信息先做脱敏。保留错误上下文，比只贴一行“报错了”更容易定位。