作者介绍
肖双，2018年加入去哪儿网，现在担任去哪儿网 CI/CD、监控渠道和云原生相关渠道建造。期间担任落地了去哪儿网容器化渠道建造，帮忙事务线大规模运用迁移至容器渠道，完结监控体系 Watcher 2.0 的改造晋级和根因剖析体系落地。对监控告警、CI/CD、DevOps 有深化的理解和实践经验。
一、布景
现在开源的监控体系越来越多，不同的体系针对的侧要点和特性也不同，像 Zabbix/Nagios 这种老牌的监控体系侧重于主机体系层监控和告警，比方 Zabbix 和 Nagios 都自带有一套完善的体系层面监控插件，并且还答应运维很便当的运用 Shell 脚本或任何其他脚本语言来扩展自己想要的插件，一起 Zabbix 还供给了比较便当的 Discovery 功用，创立一套模板后，便能主动发现和检测相应主机状况，省掉了繁琐的装备过程。而 Graphite/Prometheus 这样的则更统筹事务运用层监控，它们供给了一套机制，运用能够在代码里记载自己在运行时的状况数据，然后经过 Exporter 或许 Push 的办法将状况数据暴露或推送到 Server 端，Server 存储在时序 DB 中用于之后的剖析、检查和告警等。
许多企业在用开源软件的一个途径大概都是这样的，纯开源运用 → 少量的定制化开发或外层封装 → 深度的二次开发 → 自研。
去哪儿网的监控渠道前期的时分用的也是用的纯原生办法，但随着之后的开展这种办法现已不能满意咱们的需求，因而咱们开端规划自己的监控体系，从用户视点看咱们要供给一致入口的一站式的监控渠道，防止开发在各个体系间跳来跳去，要更友爱的支撑运用监控，要有更快捷的目标检查和快速定位，要更便当的让用户自己装备告警以及告警晋级之类的告警操作等。依据此咱们开发了 Watcher 监控体系。
Watcher 是去哪儿网内部的一站式监控渠道，它的开发办法是大部分自研组件加上小部分二开组件的办法完结的。现在每分钟搜集存储的目标总量在亿级，检测和处理的报警量是百万级的。因为考虑到数据量比较大，所以咱们要求监控体系中任何组件都能够很好的水平扩展。
二、打造契合需求的企业级监控渠道
因为前期运用的开源监控现已不能满意咱们的需求了，因而咱们需求考虑建造自己的监控渠道。这个渠道要能处理几个问题：
- 供给一站式监控告警的才干
- 供给更友爱的运用层面或运用维度的监控才干
- 一致监控资源，让用户自己办理，一起供给足够便当的快速排障才干。
- 运用简略，因为用户是面对全公司的，其间有技术同学和非技术同学，所以要防止过高的学习和运用本钱。
1. 渠道中心功用规划
Grafana 本身就供给了很优秀的监控绘图才干和多数据源的支撑，并且是十分的灵活，答运用户从各种数据源选择目标数据绘制各种类型的图表并保存下来。但 Grafana 在企业的运用中也是会有一些不便利的，比方：
- 检查目标不行快捷，前期的 Grafana 是没有 Explore 功用的，用户在 Grafana 中检查目标必需求先新建一个 Panel，然后在 Panel 中输入对应的查询表达式才干看到自己的目标，这关于有许多目标，并且仅仅临时性的检查一次的这种场景来说就极为不便利了。
- 面板办理不便利当，新版的 Grafana 给面板增加了目录和标签功用，可是关于面板比较多安排架构比较深的时分办理仍然不行快捷。
- 没有模板功用，比方在一些主机监控的场景中，咱们要检查主机的监控内容基本是相同的，比方主机的 CPU、内存、Load、网络、磁盘等等，在这种场景假如每台机器都要手工的装备出来一个面板，那工作量仍是很大的，即就是运用 Variables 才干(前期叫 Templating)，在主机量许多时，在下拉框里去查找运用也很困难。
- 报警功用无法满意企业需求
依据这些原因咱们的操控面选择对 Grafana 进行二次开发。
Watcher 整体上分为运用空间、公共空间、用户空间、报警空间、大局装备、体系装备等6个功用模块，其间
- 运用空间：以运用为维度办理一切的监控资源，包含用户自己上报的目标数据和其时运用下的主机、Pod、DB、redis、负载均衡等监控信息。
- 公共空间：公共空间供给了用户自定义面板的才干，以及多元的函数剖析才干，用户能够在公共空间创立自己的面板进行多目标联合分。
- 用户空间：类似公共空间，只不过属私家空间，其他人无权检查。
- 报警空间：办理一切的报警，能够快速依据 appCode、目标、联系人等检索报警，以及修正和装备报警。
- 大局装备：望文生义供给了一些个人大局特点上的装备修正，如 主题、图上是否相关故障事情、用户组办理以及其他快捷的东西。
- 体系装备：这部分操控监控渠道的一些展现行为和大局的插件装备，只需办理员有权限。
下面介绍下咱们渠道的部分中心功用规划：
1.1. 运用维度的监控办理
去哪儿网是以运用维度来办理各种资源的包含监控资源，咱们给每一个运用会起一个仅有标识叫做 AppCode，抽象出 AppCode 后，咱们能够对这个 AppCode 能够在多个体系进行连通，多体系能够数据共享，并且在各体系规划时一致依据 AppCode 的概念来规划，这样关于一切人在运用这个体系时分也能下降许多理解本钱。
因而咱们在 Watcher 上创立了运用空间，运用空间办理了一个运用一切的监控资源，并且与服务树打通，能够快速检索或阅读自己的 appCode 。
多环境目标检查
Watcher 打通了环境办理，能够收集不同环境的目标如 prod、beta，并且能够主动列出其时运用的一切环境，用户能够快捷的找到自己对应环境目标。
目标检索和目标阅读
默许情况下，用户能够输入关键字或许正则来快速检索自己的目标，如上图，但假如实在忘记了自己的目标名，也是点击查找框后面的目标树来阅读自己其时运用其时环境下的一切目标的。如下图：
没错，目标也会被组装成一棵树形，不同于现在的 Prometheus 的 Tag 目标的扁平化办法，在 Qunar 目标命名也是层级化的，是以 “metic.name.xxx” 这种办法组合成一个 Metric，每一个点就是 Tree 的一级，树形结构天然带有目录作用，因而以树形结构安排一组目标可读性比较好。
单机维度目标
Watcher 在收集目标的时分除了记载每台主机上报的目标数据之外，还会主动聚合运用维度的目标，比方运用有3台主机上报了”myapi.qps”目标，那么每台主机都有自己的 myapi.qps 目标，一起集聚合出一个总的 myapi.qps 目标，而一般咱们增加监控也是监控运用维度的 myapi.qps 目标，假如目标有动摇想要继续排查问题，就需求看每台主机的 qps 是否有动摇，这个时分就能够如下图点击目标上的 “单机数” 就会列出每台主机的 qps 趋势，便运用户定位根因。
运用主机资源监控
Watcher 打通了 CMDB，能够即时动态的的在运用空间中快速列出自己运用的主机/Pod 资源，以及这些资源的监控趋势，如 CPU、Load、内存、网络等等，无须任何手动的装备操作。
DB监控
同样的在运用空间，用户能够选择自己的 DB，这样就能主动列出其时 DB 的一切状况目标监控，便运用户快速定位 DB 问题。
域名监控
假如你的运用以域名的办法对外供给服务，那你只需输入自己的域名就能看到自己域名其时的一些 QPS 和网络流量等监控趋势。
1.2. 公共空间自定义面板办理
树形结构办理面板
咱们将 Grafana 扁平化的面板办理改形成了目录树结构的面板办理，这在面板比较多的时分十分有用，并且层级清楚关于人回忆和查找都比较友爱，一起也供给了查找功用，能够针对关键字快速查找自己的面板。一起能够给目录树做更详尽的权限办理，比方是否仅检查，检查和编辑，仍是无权限拜访等，这些权限也能够从父节点承继到子节点。
权限办理
树形结构上的权限很办理，因为完结了承继特性，用户想要在一定范围内增加或删除权限时不必一个一个节点去操作，只需求在父节点上设置对应的权限即可，比方在父节点设置了Owner权限那么也能够检查子节点的面板。
报警联动
在公共空间的面板上装备的报警，能够与面板状况联动，当报警产生反常时，面板上能立即感知到。
1.3. 报警办理
报警办理模块，处理了两个问题：
- 一致了告警装备和告警检查，用户不在需求到多个体系检查自己告警，告警仍然支撑依据 AppCode 来查找自己装备过的告警
- 丰厚告警周边组件，便运用户在产生告警时快速定位问题。比方 ①告警与 Trace 进行相关，当告警时能够检索到与其时反常目标有关的 trace id ；②与根因剖析体系相关，当产生反常告警时，运用根因剖析体系辅佐定位。
告警办理分为事务告警和主机告警：
- 事务告警是指用户运用埋点监控的Metrics增加的告警，用户能够恣意增加、删除、修正、设置告诉联系人等。
- 主机告警这块咱们完结了类似Zabbix的主机模板和Discovery功用，用户能够装备一类主机监控模板，一起设置Discovery规矩，一旦当有匹配类别的主机上线，则主动运用这些监控和告警。
2. 告警办理
2.1. 报警晋级
报警晋级分为提示晋级和联系人晋级，咱们的报警晋级没有强制联系人向上晋级，但用户能够便当的在树节点上设置联系人（一般在树节点上设置相关担任人），树节点上设置的联系人，其子节点上的告警都会接收到，并且是前面的联系人都没人处理告警的时分（比方没有接听告警电话），才会告诉树节点联系人， 因而运用这种办法做联系人晋级。
提示晋级是当一个报警开端发送告警告诉时，一开端咱们只会发送 Qtalk 提示，Qtalk 属于弱提示，但假如过了一段时间这个报警仍然没有人处理，就会晋级成电话提示，电话提示则是属于强提示。
晋级模板装备
2.2. 报警降噪
当装备的告警越来越多，许多告警都不是重要的告警，经过几轮人员替换后，这些告警都会成为极大的噪音，当它报警后，新来的同学不清楚这个告警是监控的什么东西，也不敢随便处理比方封闭告警，所以放任不管，那这些报警就会一直报着，长期的没有人来出来。时间长了很简单引起相关人麻痹，导致错失重要告警的处理。针对这种情况，咱们开发了降噪算法，算法只依据报警开端时间和设置的报警距离，来核算出其时是否处于发送窗口，只需在发送窗口期，告警告诉才干真的发送出去，否则不发送告诉。以此到达的作用是 比方：当一个告警设置告诉距离是5分钟，可是继续了30分钟还没有人处理，那么咱们会动态拉伸他的告诉距离，逻辑大将告诉距离变成了10分钟，1个小时没人处理则变成20分钟等等依次类推，这个告警继续时间越长，那么告诉窗口也会被拉的越来越长，告诉的频率就会越来越低，即就是他处在告警中。
2.3. 闪报按捺
在 Qunar，一个报警继续时间小于5分钟的报警咱们称为闪报。许多时分咱们刚开端装备报警时，尤其是一个新的报警，大家或许对阈值估算不准，或许因为很早之前装备的报警，之前设置的阈值现已跟现在的事务动摇不太匹配了，就会导致报警动摇、闪报。这种闪报一般来说不影响事务，可是频频打扰会导致报警接收人麻痹。因而按捺的意图就是减少无意义的打扰，尽或许提升报警的精准性。
其时报警按捺的完结办法是调查一个报警一段时间内报警状况改动的频率，假如频率高于某一个点（这个阈值点是体系依据算法算出并默许供给的，用户能够自己修正）则会进入按捺状况，频率低于某一个点则会退出按捺状况。其间半个小时内的状况多次改动则状况权重递增。
闪报按捺装备：
2.4. 报警收敛
当某一个时间突然呈现了很多告警，这会导致告警刷屏，在去看 Qtalk 告警消息时，底子就看不过来，一些要点的告警会被淹没掉，或许底子无法确定哪个告警最有或许是需求要点重视的。在这些告警里一定会有一些告警是因为其他告警形成的，比方一台宿主宕机，主机上的 load、disk 等告警都会报出来，甚至或许影响到事务目标，导致某个事务目标告警。所以报警之间会有一个隐形的依靠，一般主机或机房层面的告警依靠十分明晰，属于物理依靠，而运用之间也有依靠，运用之间的告警就是逻辑依靠。
所以在做告警收敛时，依靠拓扑是很重要的，物理依靠能够很简略的核算或许定义出来，而多运用间依靠在 Qunar 能够经过 Qtrace 来拿到依靠拓扑，因而现在在 Qunar 当某一时间呈现很多告警时，会触发告警收敛，告警收敛会先在 Appcode 内收敛，依据依靠拓扑一层层收敛，AppCode 内收敛完结之后会进行 AppCode 间收敛，最终只会将叶子告警发送告诉，其他的只在详情页展现，并不实在发送告诉。
这里边有一个难点，就是 AppCode 内装备的多个事务告警怎么拿到依靠联系（依靠树），现在 Qunar 将 Metrics 和 Qtrace 进行了结合，Qtrace 在记载办法间调用时假如经过的办法内有记载 Metric，那么会将这个 Metric 信息带入到 Trace 信息里，最终经过洗数剖析就能拿到目标间的依靠联系，依据目标间的依靠联系就能拿到告警的依靠联系。比方 一个 http 的入口办法 foo，此办法里记载了一个目标就是 foo.access.time，foo 调用了 bar 事务层办法，bar 事务层办法内记载了一个目标 bar.exec.time，那么目标 foo.access.time 就能够认为依靠 bar.exec.time，假如foo.access.time 和 bar.exec.time 一起告警，那么只需bar.exec.time 的告警会告诉出去。
3. Trace结合
Qtracer 是 Qunar 自研的 Trace 体系， Qtracer 首要是一个全链路追寻体系，能够用来定位跨体系的各种问题；别的，经过搜集链路中的各种数据到达运用性能办理(APM)的意图。而监控就是经过 Qtracer 搜集链路数据的特性来做到跟 Qtracer 结合的。
首要 Qtracer 供给了 QTracer.mark() 办法，此办法能够将自己想要的信息相关进其时 trace 的 context 中， 然后在咱们自研的 Qmonitor agent 中，在记载目标数据时调用 mark 办法，将其时目标标记进其时的 Trace 信息里边（假如其时有 Trace 信息的话），以此能到达的作用就是一个带着 Trace 信息的恳求从入口进来（假如没有携带 Trace 信息，能够生成 Trace），经过了 foo() 办法，而 foo 办法中记载了目标 foo.access.time，那么 foo.access.time 目标会被 mark 到其时 Trace 信息中。
数据被 mark 进来后，其时会以日志的办法落盘，然后经过洗数，最终会将 Trace 的 Trace Id 和其时经过的 Metric Name 的相关信息存入到 ElasticSearch 中便于后期检索运用。
当这些数据信息都没有问题的时分，此时比方咱们在 foo.access.time 目标上加了一个告警，一旦目标告警，咱们就能够检索出告警的这一段时间内一切的 Trace 信息，经过 Trace 信息能够快速的反应出其时恳求的状况，以此来帮忙开发或运用 Owner 快速定位问题。
下图是在 Watcher 上拉取其时告警时间段的 Trace Id 信息:
点击 Trace Id 能够检查具体的 Trace 信息，以及调用拓扑等。
三、云原生年代监控渠道的演进
2021年时，去哪儿网在公司内部进行了大规模容器化布置，到现在为止去哪儿网大部分的运用都现已运行在内部的多个 Kubernetes 集群上。在这样一个布景下前期咱们许多依据 kvm 特性的相关规划也要跟着变化，比方容器跟 kvm 最大的一个变化就是动态 IP 问题，kvm 的主机一旦申请后IP 是固定的，且 kvm 主机的生命周期远远长于容器，一般是跟 AppCode 同生命周期，而容器生命周期则十分短，每一次改变发布都会导致容器 IP 变化，这种频频变化给周边体系带来了许多问题，因而周边体系也需求进行改造以应对这种变化。
1.事务目标数据收集
Qmonitor 是 Watcher 的数据收集模块，虽然 Prometheus 有自己的 Client，可是想要让全公司的运用从Qmonitor 改成 Prometheus Client 显然不现实。而Qmonitor 前期规划是针对 kvm 的流程规划的，比方用户在经过 Qmonitor 监控时咱们主动拿到对应的需求监控的主机名或 IP，然后经过 Pull 其时主机对应的 url 才干拿到监控数据。而容器的 IP 是常常变化的，因而咱们修正流程，增加了 Discovery 的功用。
首要咱们增加了事情监听器，用来监听和搜集一切 k8s 集群的事情，然后将这些事情存储到 DB 的一起发送到 mq中，其他运用能够监听 mq 来拿到自己想要的事情。然后在 qmonitor 增加 client-discovery 模块，此模块能够监听对应的消息事情，然后动态的替换对应的 ip 和 meta 信息，更新的数据供给给 qmonitor server来运用。这样便能动态的发现和改变对应的 client 地址，并且对事务无感知。
2. 基础设施层监控
云原生年代，咱们的基础设施层由 kvm 云变成了容器云， kvm 时咱们运用的 collectd 来搜集基础设施相关的监控目标，比方 cpu、磁盘数据。collectd 是一个 agent 需求安装在 kvm server 上，可是容器内一般只需一个进程，agent 的办法是不友爱的。而 k8s 层的相关监控咱们运用 prometheus+cAdvisor，k8s 本身就是运用 prometheus client 来 export 内部的状况数据再合作运用 cAdvisor 监控容器运行时的状况数据比方 cpu、内存。
2.1 交融Prometheus
咱们的 Dashboard 是依据 Grafana 做的二次开发，而 Grafana 本身就支撑许多的数据源插件，其间便包含 Prometheus，因而能够很便当的将 Prometheus 跟 Watcher 进行交融，集成后仍然供给对用的 Pod 模板检查，答运用户直接经过自己的 AppCode 就能检查到本身运用下其时的 pod 状况，以及运用级的 pod 状况。
2.2 容器告警
容器的告警像 kvm 相同，也支撑模板化，容器经过监听事情来将模板运用到对应 AppCode 上完结动态增加告警，模板包含了检测目标、检测规矩、告警阈值等信息。因为 Prometheus 本身支撑反常检测，因而可直接将告警规矩经过 prometheus crd 同步到 prometheus，经过装备， Prometheus 检测到反常后，会将反常信息 Push 到 咱们自研的 Alert-API 模块，Alert-API 能够说是 prometheus 到 icinga 的一个转换器，Icinga 是咱们真实的告警办理模块，支撑开关报警、告警晋级等战略，Icinga 类似 Nagios，可是 icinga 供给了更友爱的 API 操作入口。
四、未来规划
Metrics 的数据是比较简练和标准的，所以咱们很简单从微观层面上观测剖析和判别它正常与否，断语 Metrics 的本钱也相对较低，可是想要定位真实的根因，还要凭借 Trace、Log 的数据，比方经过 metrics 你只能发现现在体系处于一种反常状况，但到底是代码 Bug 仍是什么原因形成的，就需求更详细的信息输入，而这些信息是 Trarce 和 Log 或许其他维度的数据供给的。因而接下来 Watcher 体系也会测验交融 Trace、Log 以及更多维度的数据比方事情，其实从上面能够看到，Watcher 现已开端与 Trace 进行了交融，咱们现在的办法是经过报警的 metrics 相关到 trace，假如目标产生反常了就能准确的检索出跟这个反常目标相关的 trace 信息，就能准确定位到哪些 trace 或许是有问题的，而更多的场景还需求咱们去发掘，现在业界也都在向这个方向演进。
关于智能监控部分，2022年末 Qunar 内部落地了根因剖析体系，现在与 Watcher 的报警体系进行了联动，当呈现告警时根因剖析主动监听到告警事情，测验从链路 Trace、日志、事情、中间件、运行时、物理拓扑探索等维度进行相关剖析最终将陈述推送给用户，以此辅佐用户快速定位问题。而动态反常检测雷达也还在落地中，用于补偿部分不易运用静态阈值断语的目标的反常检测。
