监控系统怎样做？

监控类型自底向上分为资源监控、服务监控和业务监控。希望打造公司级的监控系统最好的时机是系统规划时，如果把监控设计往后放，将会面临一个巨大的难题：推行和现有不兼容的规范。

三种监控类型

资源监控

这个相对简单，随着k8s的兴起，目前比较流行的是Prometheus。zabbix和falcon也比较普遍。因为对业务侵入性较小，属于比较容易实现和维护的部分。

服务监控

中间件、数据库和安全漏洞扫描，这些软件依赖于软件本身自带的配套监控，因为是量身定做，监控效果取决于技术选型等因素，可以各个击破，不需要特殊的进行统筹考虑。

应用接口监控的健康检查是需要统一标准的。一般的做法是就算服务本身是基于websocket协议、dubbo协议等进行通信，但还是会暴露一个http接口用于统一进行健康检查的监控。这个接口对每个应用来说，请求路径、请求方式(一般是get请求)，返回结构都相同。如果响应返回码属于200~399范围，‌则证明服务探活成功，‌否则探活失败。响应内容里通常还包含信息标识应用组件是否准备好开始处理用户请求。这对于启动时间较长的程序特别有用，‌如需要加载磁盘数据或依赖外部模块启动完成才能提供服务的情况。‌如果应用组件的就绪检查失败，‌集群会屏蔽请求访问该组件；‌若检查成功，‌则会开放对该应用组件的访问。‌‌

应用接口监控的耗时、QPS和成功率因为一旦协议确定，标准也确定。协议实现端通过切面等方式可以进行统一处理，只要引入相应的处理组件即可。

业务监控

业务监控不管是日志监控还是调用链监控，本质上都是基于日志埋点。

调用链监控需要在基于协议（比如http协议的请求头）和线程内部处理时（比如使用threadlocal）来传递和保持traceID，以便于在日志中将请求链路进行串联。

日志埋点总体来说分为两类：结构化日志和非结构化日志。

结构化日志里有一类重要日志是访问日志。这就要涉及开头说的巨大难题：推行和现有不兼容的规范。因为访问日志的最大作用是统计。统计系统状态、业务状态。我建议的规范是两码一态返回值结构。

{"sysCd":"00000000","sysMsg":"OK""biz":{"bizCd":"00000000", "bizMsg":"OK","data":{"serverTime": 1499827319559}}
}

明确标识出系统码和业务码。如果系统码显示有系统错误，业务码就不需要关注。系统码显示有问题，一定是需要系统维护人员处理的。系统码正常，业务码显示有问题，那理论上来说更可能是用户自身的问题，比如付款时余额不足等。系统码和业务码共同决定了请求的最终状态。这种设计在运维上提供了极大的方便：系统码显示的问题需要系统维护人员来处理，业务码显示有问题可以大胆的让用户自己检查，不用半夜将开发小哥哥叫起来。

结构化日志里还可以用来记录与第三方交互的结果。非结构化日志一般会打印两种：一种是控制台日志，一种是错误日志。大多数业务放在云上，看到的POD日志是控制台日志。特别是在程序发布时，如果日志滚动太快，有可能忽略重要信息。这时候怎样处理呢？建议把结构化日志内容单独文件打印，不输出到控制台。因为结构化日志查起来比较方便，控制台尽量只打印非结构化日志。

数据可视化

Grafana和Kibana都是开源的数据可视化和监控工具，但它们在设计目标、数据源和特性上有所不同。

Grafana

设计目标：Grafana是一个通用的开源数据可视化工具，主要用于监控和展示各种数据源的时间序列数据。它可以帮助用户快速创建、编辑和共享数据仪表板。

数据源：Grafana支持多种数据源，包括但不限于Graphite、InfluxDB、OpenTSDB、Elasticsearch、Prometheus、MySQL和PostgreSQL等。这使得Grafana可以灵活地集成到各种环境中。

特性：

灵活的查询和聚合：Grafana提供了一个强大的查询编辑器，允许用户根据需求定制查询，以及使用不同的聚合函数来处理数据。

丰富的图表类型：Grafana支持多种图表类型，如折线图、柱状图、饼图、散点图等，用户可以根据需要选择合适的图表来展示数据。

警报和通知：Grafana内置了警报功能，允许用户设置阈值，当数据达到或超过这些阈值时，Grafana会发送通知给相关人员。

强大的插件系统：Grafana有一个活跃的插件社区，用户可以通过安装插件来扩展其功能，比如添加新的数据源支持、图表类型等。

Kibana

设计目标：Kibana是一个为Elasticsearch设计的开源数据可视化和探索工具。它是ELK中的K，主要用于分析存储在Elasticsearch中的数据，特别是日志和时序数据。