夜莺监控，是一款云原生融合监控解决方案，可以看做是Prometheus的Plus版本，如果你用了Prometheus，一定要尝试一下搭配夜莺使用，定会给你的工作带来帮助。近期发布v5.0版本，收到客户各类问题，现总结常见问题，回答如下，从中也可以看到一些设计理念。夜莺新版本的文档主站在 n9e.gitee.io 欢迎品鉴。
001. 为什么活跃告警页面，业务组右侧的红色数字（表示该业务组活跃告警的数量）和右侧表格的内容数量不匹配？
因为表格默认选择的是查看最近6小时，而红色数字是计算的该业务组的所有的活跃告警数量，没有考虑时间范围的问题，此时需要，把表格上面的时间范围调大，就能看到更多活跃告警了
002. 夜莺前后端都是开源的吗？代码在哪里？
都是开源的，前端代码地址在 github.com/n9e/fe-v5 v5版本相关的代码在v5.1分支；后端代码在 github.com/didi/nightingale 在main分支，在gitee.io/n9e/nightingale上做了镜像，也在main分支
003. 多集群部署的时候MySQL、Redis分别部署几个？
B站有个视频讲解了如何接入多个时序存储：https://www.bilibili.com/video/BV1vb4y1i7a9/ 请先查看。MySQL是只需要一个，不管部署多少个n9e-webapi多少个n9e-server。redis也可以只用一个，所有的n9e-webapi和n9e-server共享，但是，如果部署多套n9e-server（一套n9e-server可能是多个n9e-server实例组成一个集群）分布在不同的地域，网络链路可能不太好，此时是建议一套n9e-server对应一个redis，n9e-webapi自己用一个redis
004. 架构中可以完全不用Prometheus吗？
原理上是可以的，Prometheus在夜莺的架构中，是作为时序库使用，除了Prometheus，也可以使用VictoriaMetrics、M3DB等，因为这些时序库都实现了Prometheus的Querier接口，而夜莺依赖这些接口拉取监控数据和做告警判断。
005. 机器只能归属一个业务组吗？
是的。
用户可能会继续追问：一台机器可能有混部的情况，同时部署多个服务，那如何来描述这种现实（毕竟，软件就是对现实的建模）呢？其实，这种关联信息在监控中是使用标签来反映的。比如某个监控数据带有这几个标签：host=cs-node001.hna service=n9e-server method=get api=/ping statuscode=200 表示：这个监控数据是n9e-server这个服务的，来自cs-node001.hna这个机器，这条监控数据描述的是/ping接口，/ping接口是个get接口，statuscode是200，这个信息非常丰富，里边既有服务名称，又有机器信息，通过这种方式我们就知道服务和机器的关联关系。
大家不要把CMDB中的机器分组需求放到夜莺中来维护，这是职责上的错配。
那为何还要提供业务组这个概念？岂不是多余了？业务组更多的是想处理权限的问题，比如我们的告警规则、屏蔽规则、订阅规则、监控大盘、自愈脚本等，只能由我们自己管理，不能被无关人员修改了或删除了。把这些规则类信息放到某个业务组中，只有这个业务组的管理员有权限管理，其他人就没有权限乱搞了。
那机器为何要归属业务组？其实也是从权限上考虑的，自愈脚本是归属业务组的，脚本的执行需要有权限控制，不能随便去机器上运行，现在的控制逻辑是脚本只能在自己的业务组下辖的机器上运行。
综上，坦白讲，我没有想到什么场景是必须让机器（即系统中的监控对象）归属到多个业务组的。关键原因是监控数据上报的时候就是自描述的，已经包含了各类信息了，不需要通过外挂的方式重新归类监控数据，而机器的分组，虽然有需求，但那是CMDB的需求，也不是监控要处理的。
更新：另外，机器（即系统中的监控对象）可以打标签，可以通过标签体现一定的分类信息，比如region=bj env=prod表示bj区的生产环境的机器。标签是K=V的格式，K可以体现维度信息，大部分归类需求都可以通过标签来解决，唯独比较麻烦的是，在同一个维度有多个值的情况，比如K=V1 K=V2这种情况，这种情况目前不支持，因为标签信息会被附到监控对象的时序数据上，时序数据的标签是map结构，所以K=V1 K=V2这种K相同的情况会产生覆盖，故而页面上监控对象打标签的时候压根就不允许这种标签。
006. 为何我的target_up指标一会是0一会是1，导致一会有告警一会又恢复了
这个很可能是因为调整了客户端采集上报频率导致的，默认Telegraf上报频率是10s，不会有这个问题，n9e-server每15s生成一次target_up的值，标识机器是否在正常上报数据，如果发现机器有指标在上报，target_up就置为1，否则就是0，如果把客户端采集上报频率调大，比如改成60s，那n9e-server在某些周期检查的时候，确实就发现客户端没有上报数据，毕竟上报频率太大了。此时的告警规则应该配置为：
max_over_time(target_up[130s]) == 0
告警规则的持续时长设置为0，上面的PromQL表示130s内一直都没有监控数据上报，故而要报警。
007. 夜莺用的redis支持cluster版本或者sentinel版本吗？
不支持，就是用的单机版，改造成cluster版本或者sentinel应该也没啥太大问题，一般公有云会提供高可用的redis，一主一从那种，足够用了，自己搭建也可以，机器挂掉的概率其实很小，满足sla问题不大的
008. Telegraf上报的主机标识默认用的机器名，可以让它自动上报IP作为本机标识吗？
可以让它上报IP作为唯一标识，但是要想自动获取IP，做不到。个人建议是使用一些批量执行工具，比如ansible之类的，批量部署Telegraf，部署脚本里自动获取目标机器的IP，然后填充到telegraf.conf中。
009. 触发告警和触发恢复的逻辑是什么？
告警规则里有3个配置非常关键，promql、执行频率、持续时长，意思就是按照执行频率，每隔一段时间执行promql查询，如果查到数据就认为触发了阈值，触发了阈值是否会产生告警事件，不一定，还要看持续时长，如果持续时长为0，就相当于不用等待，触发了阈值就立马生成事件，如果持续时长大于0，那就要等待，要保证持续时长这段时间内，每次执行promql的查询都触发阈值，才认为应该生成事件。持续时长就相当于prometheus.yml中的alert rule中的for。
比如promql为cpu_usage_idle{cpu="cpu-total"} < 20 ，执行频率是10s，持续时长是60s，就表示在60s内每10s执行一次promql查询，看promql查询是否返回内容，如果6次都返回了，说明应该生成告警事件。
恢复的逻辑：比如已经产生了告警事件，然后再次拿着promql去查询，发现没有返回内容，那就说明当前的监控数据已经不符合promql中指定的阈值条件了，就表示恢复了。当然， 如果数据丢点了，promql自然也查不到，这种情况也是会报恢复，因为夜莺确实无法区分到底是因为丢点了，还是因为没有满足阈值而导致没有返回内容。那你可能会问，把promql解析一下，去掉promql中的操作符和阈值，只拿着前面部分去查询，不就能区分到底是没数据还是因为没有满足阈值了吗？其实很难，上面举例的promql是一种简单情况，复杂的promql非常复杂，没法这么轻易的拿掉操作符和阈值。
010. 如何监控机器的CPU、内存、磁盘、IO、网络、进程？
这个问题，文档里有答案，Telegraf章节，有个调研笔记的链接，调研笔记中描述的很清楚了，除了机器层面的这些监控项，还有讲如何做PING监控，TCP探测等
011. 夜莺可以接入到Grafana来展示吗？
可以。但不是把夜莺作为DataSource，因为实在是没必要。夜莺后端可以接入多个时序库：Prometheus、M3DB、VictoriaMetrics、OpenTSDB、InfluxDB等，这些时序库都可以直接作为Grafana的DataSource，所以，只要监控数据进了这些时序库了，Grafana就可以直接展示了
012. 夜莺可以配置InfluxDB的QL做告警规则吗？
不支持，当前只支持配置promql，夜莺接入时序库，有两个层面的接入，一是通过remote write，把夜莺收到的数据转发给时序库，所有支持remote write 接口的存储都可以通过这种方式接入夜莺，接收夜莺转发过来的数据；二是时序库如果开放兼容Prometheus的Querier接口，那夜莺还可以读取时序库的数据做告警判断，即Prometheus、M3DB、VictoriaMetrics、Thanos等这些存储，都完全兼容Prometheus的Querier接口，则夜莺可以配置告警规则，从这些存储中读取监控数据做告警判断。而OpenTSDB、InfluxDB等，因为不支持Prometheus的Querier接口，所以夜莺的告警规则，没法读取这些存储的数据做判断，这些存储只能作为remote write的写入端。
