Skip to content
xtan edited this page Jun 13, 2022 · 12 revisions

写在前面

夜莺遇到问题,有如下途径获取答案:

  • 查看模块报错日志,这是最重要的手段;搜索github issue、baidu、google,这是技术人员必须要会的工具
  • 校准机器时间,监控系统对时间一致性要求高,否则容易出现各种古怪问题,浏览器所在的机器、n9e-server所在的机器、tsdb所在的机器,时间要校准一致
  • 通读官方文档:n9e.github.io,通读文档,大部分问题都可以解决掉
  • 夜莺视频教程:B站和公众号都放了入门级的视频教程,2个小时即可看完,链接
  • 上面的途径还是解决不了,可能是因为你的Linux进阶知识掌握的不好,作者录制了一套课程,可以学习一下Linux进阶知识
  • 终极杀器,与我司开展商务合作(我们做了一家公司:快猫星云),采购技术支持服务,作者7*24在线支持,传授业界最佳实践,花半个人力的钱,让大厂高P为你手把手讲解,提升自己和团队的能力,节省时间,贵司就可以有更多时间做更高级的事情,合作双赢感谢支持

001. 多集群部署的时候MySQL、Redis分别部署几个?

公众号有个视频讲解了 如何接入多个时序存储, 请先查看。MySQL是只需要一个,不管部署多少个n9e-webapi多少个n9e-server。redis也可以只用一个,所有的n9e-webapi和n9e-server共享,但是,如果部署多套n9e-server(一套n9e-server可能是多个n9e-server实例组成一个集群)分布在不同的地域,网络链路可能不太好,此时是建议一套n9e-server对应一个redis,n9e-webapi自己用一个redis

002. 架构中可以完全不用Prometheus吗?

原理上是可以的,Prometheus在夜莺的架构中,是作为时序库使用,除了Prometheus,也可以使用VictoriaMetrics、M3DB等,因为这些时序库都实现了Prometheus的Querier接口,而夜莺依赖这些接口拉取监控数据和做告警判断。

003. 机器只能归属一个业务组吗?

是的。

用户可能会继续追问:一台机器可能有混部的情况,同时部署多个服务,那如何来描述这种现实(毕竟,软件就是对现实的建模)呢?其实,这种关联信息在监控中是使用标签来反映的。比如某个监控数据带有这几个标签: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相同的情况会产生覆盖,故而页面上监控对象打标签的时候压根就不允许这种标签。

004. 为何我的target_up指标一会是0一会是1,导致一会有告警一会又恢复了

这个很可能是因为调整了客户端采集上报频率导致的,默认Telegraf上报频率是10s,不会有这个问题,n9e-server每15s生成一次target_up的值,标识机器是否在正常上报数据,如果发现机器有指标在上报,target_up就置为1,否则就是0,如果把客户端采集上报频率调大,比如改成60s,那n9e-server在某些周期检查的时候,确实就发现客户端没有上报数据,毕竟上报频率太大了。此时可以调整server.conf的配置,把检测客户端是否存活的周期也放大一些,比如调整为60秒:

[NoData]
Metric = "target_up"
# unit: second 如果看图时不希望折线图一会是0一会是1,可以把这个值调大,比如130
Interval = 60

告警规则也可以针对这种情况做一些调整,比如改成:

# 告警规则的持续时长设置为0,该PromQL表示130s内一直都没有监控数据上报,故而要报警。
max_over_time(target_up[130s]) == 0

target_up指标是0,还有可能的原因是客户端夯住了,可以重启一下客户端试试,或者是客户端所在机器当前压力过大,影响了客户端到服务端的网络通信。

005. 夜莺用的redis支持cluster版本或者sentinel版本吗?

不支持,就是用的单机版,改造成cluster版本或者sentinel应该也没啥太大问题,一般公有云会提供高可用的redis,一主一从那种,足够用了,自己搭建也可以,机器挂掉的概率其实很小,满足sla问题不大的

更新:5.9.0版本开始,支持了cluster和sentinel版本

006. Telegraf上报的主机标识默认用的机器名,可以让它自动上报IP作为本机标识吗?

可以让它上报IP作为唯一标识,但是要想自动获取IP,做不到。个人建议是使用一些批量执行工具,比如ansible之类的,批量部署Telegraf,部署脚本里自动获取目标机器的IP,然后填充到telegraf.conf中。

007. 触发告警和触发恢复的逻辑是什么?

告警规则里有3个配置非常关键,promql、执行频率、持续时长,意思就是按照执行频率,每隔一段时间执行promql查询(即时查询,即调用Prometheus协议的/api/v1/query接口),如果查到数据就认为触发了阈值,触发了阈值是否会产生告警事件,不一定,还要看持续时长,如果持续时长为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非常复杂,没法这么轻易的拿掉操作符和阈值。

008. 如何监控机器的CPU、内存、磁盘、IO、网络、进程?

这个问题,文档里有答案,Telegraf章节,有个调研笔记的链接,调研笔记中描述的很清楚了,除了机器层面的这些监控项,还有讲如何做PING监控,TCP探测等

009. 夜莺可以接入到Grafana来展示吗?

可以。但不是把夜莺作为DataSource,因为实在是没必要。夜莺后端可以接入多个时序库:Prometheus、M3DB、VictoriaMetrics等,这些时序库都可以直接作为Grafana的DataSource,所以,只要监控数据进了这些时序库了,Grafana就可以直接展示了

010. 夜莺可以配置InfluxDB的QL做告警规则吗?

不支持,当前只支持配置promql,夜莺接入时序库,有两个层面的接入,一是通过remote write,把夜莺收到的数据转发给时序库,所有支持remote write 接口的存储都可以通过这种方式接入夜莺,接收夜莺转发过来的数据;二是时序库如果开放兼容Prometheus的Querier接口,那夜莺还可以读取时序库的数据做告警判断,即Prometheus、M3DB、VictoriaMetrics、Thanos等这些存储,都完全兼容Prometheus的Querier接口,则夜莺可以配置告警规则,从这些存储中读取监控数据做告警判断。而OpenTSDB、InfluxDB等,因为不支持Prometheus的Querier接口,所以夜莺的告警规则,没法读取这些存储的数据做判断,这些存储只能作为remote write的写入端。

011. 从哪里获取微信机器人token?

首先,是企业微信,不是微信,在企业微信里建个群,点开群管理,添加机器人,完事查看这个机器人的信息,即可看到webhook地址,webhook地址中包含一个key的参数,key=后面就是token。拿着这个token,去夜莺里创建一个用户,比如就叫xx企微机器人,给这个用户设置一下Wecom Robot Token,配置为刚才从webhook中获取的token,后面把这个人加入告警接收组,相关的告警就会发给企业微信的这个群组。

012. 监控对象列表中如何添加监控对象?看到监控对象列表和对象视角都是空的

公众号的视频教程要整体看一遍,就理解整个设计了。简而言之,监控数据需要上报给n9e-server,然后由n9e-server转发给时序库,即监控数据要流经n9e-server,n9e-server才有可能从监控数据中提取ident标签的值,n9e-server会把ident标签的值作为监控对象注册到数据库中,才能在列表中看到。如果监控数据的整个传输过程没有流经n9e-server,或监控数据中没有ident标签,也就没法提取到了。

夜莺可以支持Telegraf作为客户端采集器,也可以支持grafana-agent作为采集器,这俩采集器实际都没法上报ident标签,但是Telegraf会上报host标签,grafana-agent会上报agent_hostname标签,这俩标签会被自动转换为ident字段。

当然,即使没有注册到对象视角中,其实也不耽误,没啥大不了的,只是未来看监控图表的时候,没法使用对象视角看图罢了。后面夜莺也会持续优化,增加自定义视图,到时候对象视角的看图可能就可有可无了。

013. v5版本如何通过api接口上报数据的时候顺便带上alias字段?

v5目前支持的上报接口是opentsdb的协议、remote write协议、datadog的协议,都不支持alias字段,而数据库中也干掉了这个字段,所以,v5没法通过api上报这个字段了,不过v5有备注字段,和自定义标签字段,可以考虑用这俩字段放置别名,这需要直接操作DB,或者通过API修改监控对象,总之,无法通过上报数据的接口来搞定

014. v5邮件告警的服务器配置(smtp)在哪里?

v5.4(含)之后的版本,在server.conf中,v5.4之前的版本,在etc/script/notify.py中,脚本的前面几行,很容易找到

015. 我在A业务组配置的告警规则,为何收到了B业务组的机器的告警?

告警规则的逻辑可以查看009号问题,每次就是用promql查询时序库,而时序库里是没有业务组的信息的,所以promql就生效到了全量的监控对象上了。推荐做法:a业务组的机器,统一打上bg=a的标签,b业务组的机器统一打上bg=b的标签,配置告警规则的时候,要带上这个标签做筛选,比如 cpu_usage_idle{bg="a"}<15 就表示只有bg=a这个标签的机器生效,即只有a业务组的机器生效。

近期夜莺新版本支持在告警规则配置的时候指定只在本业务组生效,一定程度上解决了这个问题,后续也会支持把业务组直接作为标签附到时序数据上,到时候就更方便了

016. Telegraf推送数据给n9e-server,如何加上认证机制保证安全?

Telegraf使用datadog的output吐数据给n9e-server(版本要在5.2.1以上)

[[outputs.datadog]]
timeout = "5s"
url = "http://localhost:19000/datadog/api/v1/series"
apikey = "datadog-api-key"

n9e-server中加上这个配置:

[BasicAuth]
apiKey = "datadog-api-key"

注意:这样配置之后,表示n9e-server的所有请求都走basic auth认证,原来Telegraf通过openTSDB的接口吐数据的链路就走不通了

另外,BasicAuth这个配置段可以加多个,每个一行,比如通过prometheus推数据给n9e-server想加个认证,username设置为admin,password设置为1234,则可以在BasicAuth中加一行:

[BasicAuth]
apiKey = "datadog-api-key"
admin = "1234"

017. 从低版本怎么向高版本升级?

首先去github的 releases 页面 找到自己的版本,然后挨个查看每个比你高的版本,看看各个版本的release log中写了要更新哪些内容,重点关注sql相关的,比如你的版本是5.1.0,当前版本是5.3.0,那你要看 ( 5.1.0, 5.3.0 ]之间的所有版本,从低到高挨个查看,把每个版本的release log中的sql都执行一遍(如果release log中没有提sql语句,说明这几个版本没有DB表结构变更,那更简单了),最后替换n9e二进制和etc下的内容到最新版本,如果你之前etc下有些特殊配置,记得要基于最新的配置文件再修改下

018. telegraf的基本配置和中间件采集的配置都放到一个telegraf.conf中不好管理怎么办?

telegraf启动的时候支持两个参数--config--config-directory,这俩参数可以一并使用,通过--config指定主配置文件,通过--config-directory指定配置目录,各种非通用的配置,都可以放到配置目录里,每个配置文件以.conf结尾,这样telegraf就可以都识别到了,比如:

./usr/bin/telegraf --config etc/telegraf/telegraf.conf --config-directory etc/telegraf.d

然后我做了一个mysql.conf放到telegraf.d目录下,专门用于监控mysql,内容如下,供大家参考:

[[inputs.mysql]]
servers = ["root:1234@tcp(localhost:3306)/?tls=false"]
metric_version = 2
gather_global_variables = true
interval_slow = "1m"
tagexclude = ["innodb_version"]

019. 附加标签是干啥的?怎么用比较好?

附加标签和promql中的标签不是一码事,promql中的标签是用于筛选时序数据的,而附加标签,是在告警事件产生之后,附加到告警事件上的,作为告警事件的一个元信息,便于后面的告警屏蔽、订阅、分类等。

比如 cpu_usage_idle{cpu="cpu-total"} < 15 这个告警规则,产生的告警事件是会自动带有3个标签,name、cpu、ident,其中__name__表示指标名称、cpu表示是第几个CPU核心、ident表示机器,看起来信息比较丰富,无需附加额外的标签。

但是另一个promql:system_load1 / system_n_cpus > 2 这个是平均每个CPU核心的负载,这个值是靠除法算出来的,这个promql生成的告警事件中就没有__name__这个标签,此时,我们可以手工加一个附加标签来定义其指标名:name=system_load1_per_cpu 这样生成的告警事件信息就更丰富了。

另外,我们也可以在附加标签中附上一些所属服务、团队、地域类的信息,后面就可以基于这些信息做事件聚合、屏蔽、订阅等

020. 夜莺可否对接Grafana?

夜莺无需对接 Grafana,夜莺会把监控数据转存到后端时序库,比如 Prometheus、VictoriaMetrics、M3DB 等,把这些时序库配置为 Grafana 的数据源即可。

021. 告警事件标签有点多,可否自定义展示?

告警事件的格式,由 etc/template 下面的模板来定义,这些模板遵从 Go 的 template 语法,如果想更改事件内容,就修改这些模板即可。

模板中可以引用哪些变量?可以从这个 struct 中找到答案。

  • 方法1:标签不展示整个 TagsJSON,而是从 TagsMap 中拿具体的个别标签
  • 方法2:告警规则的规则备注可以自定义(v5.8.0+),类似 prometheus 那样写,比如:监控指标:{{$labels.__name__}} 所属业务组:{{$labels.busigroup}} 然后修改告警模板,告警模板支持go template语法,可以在tpl中做个判断,如果规则备注不为空,就展示规则备注,不展示标签了,如果规则备注为空,就展示 TagsJSON

加交流群,请先加微信:borgmon 备注:夜莺加群

Clone this wiki locally