本司监控报警现状

监控报警现状
本司是基于open falcon进行监控报警

1. 系统资源监控：cpu、mem、io等，都有这些监控和报警数据 — 100%
2. 业务系统可用性监控(连接层面，进程存活)：health接口(有部分服务没有，正在催促加上)、grpc可用性(开发了一个版本，正在部分使用阶段) — 70%
3. 业务系统业务可用性和监控：服务可用性、耗时等监控的很少 — 20%

急需解决的问题
1.业务可用性的完善：health接口都加上、grpc的探活加上。此处后续需要业务系统也加上容错能力。
2.业务系统的业务可用性和监控，主要是通过日志采集分析来进行监控报警。nginx的接入log和业务log
nginx日志监控：非200的监控报警、不同url的response耗时输出，加了十几个域名，比较重要的域名的耗时统计
业务日志监控：业务日志不规范，输出的日志可读性差，需要研发配合进行日志的梳理，整理日志的输出，给出监控点，抓取对应的日志然后进行统计和报警。
业务异步推送统计打点：集成falcon的包，可以实时的将接口的调用次数和耗时都push到falcon中，从而可以进行耗时统计以及添加报警策略。

监控根据不同的需求分为两种，一种是整体系统的健康程度的监测，一种是trace系统来精准跟踪问题。

• 整体健康程度的监测，通过整体服务的资源使用情况，接口的响应耗时来给出
• trace系统通过linker可以做到服务间的耗时统计，同时也可以做到trace的串联，但是针对于周边的耗时，比如redis、mysql的或者调用第三方接口的trace根据无法串联起来。考虑通过日志采集的方式来进行trace的组件，或者业务系统集成brave的方式(之前有系统集成过，需要持续的加进去)。
  总结
• 业务监控缺失严重，需要逐渐补充上
• k8s的统一调度导致服务本身资源服务查看不是很方便，需要重新规划(k8s升级到1.6，做定向调度)
  规划
  falcon目标用户更多是运维同时，所以对于研发来说使用可读性稍差，所以后续会有服务树给出，通过服务树关联服务的相关的监控信息。同时会基于服务树提供给研发自己添加监控的能力，一般就是日志监控，给出对应的log正则规则，然后抓取日志，给出报警策略。