关于系统监控的想法和实施（一）：数据监控

  大家好，我是爱吃里脊，下面由我来讨论下监控的想法。提到监控，对于维护系统至关重要，对发现问题，解决问题起着决定性的作用。
  我们来先来进行整体拆解，一个监控系统包含三个主体：数据采集，数据处理，数据展示。这次我们先来了解数据采集。
  首先要做监控系统首先得有一个监控对象，了解监控对象需要什么指标，比如一个业务后台系统，需要知道物理指标有的cup，磁盘，负载，魔法指标有接口调用数，接口的tp99，接口的可用率等等。一个前端应用，可能需要用户点击某个按钮，某个页面的次数，甚至是记录某个用户行为等等。其实这些指标很多，不同系统差别很大，关注点也会随之改变。要做好一个数据监控系统，就得应对这些变化。下边是具体的一些指标用于参考：
  机器维度的监控指标包括CPU、Load、内存、网络、IO、磁盘等相关指标，详细指标可以参考Liux监控命令对应的指标数据：https://linux.cn/article-9373-1.html?pr （主要可以参见top、vmstat 、free、iostat、netstat 、iptraf等命令相关的核心指标）。
  应用维度的监控指标包括JVM使用情况、线程池使用情况：JVM情况主要包括YGC次数、时间，FullGC次数、时间，新生代老年代占比；线程池情况主要包括的线程池大小、最大线程数、活跃线程数、队列大小等。
  服务维度的监控指标包括error日志报错情况、服务接口调用量、耗时、成功率，调用接口调用量、耗时、成功率，dal层操作调用量、耗时、成功率。
  外部依赖维度主要指应用系统常见的外部依赖的监控情况，主要包括数据库、缓存、消息队列等，这些一般情况都会独立进行部署，对应的机器监控同上面列举的机器维度监控；另外数据库还需要关注连接数、内存使用、SQL调用量、耗时、成功率，慢SQL等；缓存需要关注调用量、成功率，命中率、内存使用等；消息队列需要关注调用量、成功率，队列积压情况、死信队列等
  整体上的监控指标包括可用性监控（服务是否可用）、访问量监控（PV/UV）、负载监控（限流、熔断情况）、自定义的业务监控（异常业务场景、服务统计等）

  很显然，如果在应用程序里写这些监控处理，是很笨的，业务代码与功能代码耦合，违反了程序软件开发的开闭原则，单一原则。对之后的维护添堵。

  比较好的方式是机器安装客户端，或者应用集成客户端来进行采集，应用的日志可以通过aop的方式打印上传，为了尽可能的减少对业务代码的影响，可采用独立线程定时同步或者中间件mq，redis等定时同步。这是推日志的方式，对一些实时性较高的监控还可以进行服务端拉取的方式，这种方式较为复杂，需要客户端注册服务到服务中心，服务端获取服务中心服务后，主动请求目标的日志来拉取。这里可以举个例子：
   push方法用于Graphite等系统，而pull方法用于Prometheus等监视系统。但是无论哪种方式，基本思想都是这种组件化，独立处理，异步上传日志。
  下边说说日志结构，监控数据包含在日志中，所以日志的输出不能全部写在一个文件处理，需要对日志归档，日志分类，保持日志大小不能过大，保证日志不混乱分析清晰。而且在输出日志前，需要先定义监控数据结构，结构中包含上述所说的种种指标，为后续数据分析和展示做好铺垫。在elk中，es的数据结构是文档格式，在java应用的系统中可以将对象反序列化成json数组，而且es的性能很好，可以做复杂的索引，全文检索，聚合查询，这点可以解决日志问题，但是不是所有监控系统都是用es的，其他存储这点要注意。
  最后就是配置相关了，好的监控系统需要有运维界面，来实现可配置可插拔，对一些数据指标问题进行报警配置，对于数据收集这块，不可能是所有指标照单全收，而在监控的初期可能不会明确那些不需要，而且监控系统不成熟，那么就需要在开发前期预留配置的扩展点，保证对后续开发的支持。