watcher

watcher基于Grafana,InfluxDB以及Kapacitor的监控系统后台

工具介绍

• Grafana 一个专业的图形展示工具
• InfluxDB 一个时间序列的数据库
• Kapacitor 一个设置触发动作的框架应用

监控的目的

当我们谈论监控时，我们在谈论什么？

• 掌握系统健康状况 Elasticsearch中使用三种状态（Green,Yellow,Red）来表示其服务情况，通过监控的指标来表示当前系统的健康状况，比如CPU使用，磁盘，网络IO，内存这些系统指标。
• 查找故障根源 到底是硬件故障还是软件故障，硬件故障的话又是哪个具体的硬件出现了问题
• 系统瓶颈诊断 一个界面查询操作从调用到返回结果，花费了很长时间，而后端调用链又比较长，究竟是哪些服务执行得太慢影响了响应时间，或者是数据库的原因？
• 性能调优 当找到了系统的瓶颈后，使用各种优化方法，如何才能知晓性能得到了优化，以及优化的程度如何。
• 排查安全隐患 一些对外接口，某个时间突然暴增，是不是被爬了，是不是有漏洞，还是只是在做压测。
• 报表生成 运营需要统计一些PV,UV之类的数据做报表，定时任务查询，实时性不高，粒度也比较粗。比如公司的短信报表，虽然有每天的报表，但精细的程度还是不够。 将复杂问题简单化。

watcher的作用

watcehr旨在高性能和高可用的系统提供监控和报警服务,主要功能有:

1. 应用指标的监控,对于一些关键的接口,监控其单位时间内外部调用量,成功失败的次数,以及单位时间内平均调用时间,隐藏Grafana、InfluxDB和Kapacitor配置 细节,你只需要在应用中提供接口或者将数据推送过来,watcher将数据聚合存储以及展示。
2. 报警的设定,接口异常通过合理的报警设置将第一时间通知到应用的负责人,减少不必要的损失。
3. 第三方应用的集中监控

watcher工作流程

目前指标的监控分成两部分:主动拉取或者被动推送。 主动拉取的过程是应用提供一个http接口,该接口返回固定时间的监控指标,应用启动后在watcher上注册,注册完成后会根据配置的信息来进行定时拉取监控的指标数据 被动推送的主要目的是方便管理,因为在应用多了之后,管理起来比较麻烦,所以被动推送的过程只是做了个代理,最后的数据还是会写到InfluxDB中。

monitor目前主要分为三部分:

1. 数据的抓取 monitor
2. 数据的存储 InfluxDB
3. 数据的展示 Grafana

monitor又主要做了三部分的工作:

1. 应用的注册, 为了方便统一管理,需要在应用初始化的时候注册一下,注册的信息主要有一下内容:

• organization 部门的id,这个在页面是一个下拉选项,标识这个应用属于哪个部门
• group 应用的分组,表示这个应用属于那个组,比如瑶光,米奇等,group是唯一的
• name 应用的名称,比如yaoguang_push,yaoguang_postgresql,同一个group下,应用的名称不能重复
• hostname 线上部署时应用的hostname和对应的端口号 当有多台机器时,中间用','号分割开
• save mode 存储数据的方式,针对同一个应用在多台机器部署的情况,是保存每台机器的数据还是在watcher中做聚合保留总的数据信息,会影响到报警的设置,默认是保存多台机器合并的数据
• push or pull 监控的指标数据采用什么样的方式,主动推送到watcher,还是提供接口由watcher拉取,接口在API使用中详细说明
• contact 应用的负责人,多个应用负责人中间用','号隔开
• email 联系人邮箱,过个邮箱使用','号分割开,报警设置时默认的收件箱
• token 是注册成功后后台返回的一个token 当需要推送数据时,需要将token带上,这样采用存储到正确的数据库

使用方法

1. 注册应用