为什么要有监控系统

在我从业4年多的历程中,大部分时间是没有接触监控系统的或者没有发现监控系统的重要性.这很正常,因为IT界的演化本质上是从简单到复杂从单节点到集群,从裸金属到完全托管云服务的过程.

我工作过程中接触到的技术演变大致也是就如上,也大致经历了这几个阶段.

第一阶段:

• Java SSM单体应用+dubbo rpc
  • 手动在单体应用所在的服务器上逐个手动shell检索数据
  • 没有对单体应用的节点健康,性能,压力监控
  • 没有链路追踪

这是最基础的服务,勉强有了微服务的概念本质上还是单体,没有任何的观察系统概念.但是这个在当年还是够用的,因为单体应用这时数量有限,即使分散到各个服务器但是手动查询还是勉强应付.

第二阶段:

• Java Spring Cloud微服务,部署到裸金属上
  • 手动在单体应用所在的服务器上逐个手动shell检索日志数据
  • 自带简单的单体应用的节点健康检查和容错
  • 自带简单的链路追踪

这时有了基本的服务拆分和微服务的雏形了,但是还没有做到服务节点的动态伸缩. 这时节点的数量比较多了,手动检索日志信息开始有点费力,产生了一些观察系统的需求和必要性.

第三阶段:

• Java Spring Cloud微服务,使用K8S编排
  • 日志数据按照节点的类型做了集中的存储,存储在ES中,在Kibana检索集中起来的数据,不必到每个容器中检索了
  • 自带初级的单体应用的节点健康检查和容错
  • 自带初级的链路追踪
  • 除了日志的检索升级了,其余的功能比如状态自动感知完全没有

这时有了动态伸缩了,手动检索节点的日志数据变得不可能,但是观察系统没有成形.只好通过ELK技术集中存储日志然后搜索,观察系统变成了非常重要的平台需求

第四阶段:

• 完全上云,使用Serverless+K8S容器话.并且语言不再是java一种而是变成了Java/Python/Node/Go
  • 基本没有了节点的概念,无法知道确切的服务节点拓扑和数量,ELK的简单使用只能解决分布式日志源头聚合和检索的问题

在这个时候,观察系统已经变成了刚需,没有好的观察系统团队很难直观的知道当下的服务压力和资源耗费详细情况,这样就会严重现在团队的开发能力和故障反应能力.

总结

在容器化,云原生,serverles等新技术的大量使用现实下,以往的手动/半手动日志检索已经完全不能继续产生任何价值. 它给整个开发团队提出了如下挑战

不单是是日志的检索.新的技术的使用也对现在的后端服务提出了一些新的要求,比如性能监控,故障自动感知,链路追踪,高压力下的自动弹性处理等等. 在这个场景下,一个好的观察系统必须做到这些基本的功能,不单是日志收集和检索

它呈现给我们那些方面的信息

首先是系统多维的状态信息:

1. 各种类型的日志数据.做到分布式收集->集中存储->数据索引->灵活检索
2. 服务的指标数据
   • 服务压力感知和指标数据
   • 服务健康度监控
   • 各服务间相互协作和调用时的性能情况
3. APM数据
   • 随时间线发展而产生的外界压力曲线以及这些时间点上对应的平台的性能表现
   • 用户的使用喜好和周期性规律
4. 服务uptime
   • Serverless服务的消费时长,单个请求的服务耗时
   • 容器的全生命周期中服务时长
   • 裸金属服务器的启停时间

其中ELK技术栈大致能解决大部分的问题

不过链路追踪和更丰富的可视化展现.ELK做的不是100%的完美,它需要在跨语言跨技术体系的日志设计这个顶层的设计上结合最合适的组件完成链路追踪.同时数据的可视化上Kibana有时略显单一. 业界一般使用ELK+Grafana+Prometheus+云服务商的监控(比如AWS CloudWatch)完成更加立体的日志/指标收集->数据存储->数据的分析(解析,提取,索引..)->数据的高级感知(服务链路流程感知,自动告警,自动扩缩容,自动压力分配,自动的资源预先准备)->数据的展现(图形化展示,数据检索,趋势分析)

它怎么展现

在数据可视化上,一般我们喜欢叫它'大屏',关于展示的技术一般这个没有标准,业界比较流行的是Kibana或者Grafana,以Grafana相对更加专业一些.

它需要那些数据

主要是如下的基础数据:

• 日志数据,文本类型或者流式传输都可,不限于日志的传输形式,但是日志是要有格式或者能被预格式化的,这样方便自动化/人工的解读.单条日志是单个事件,代表某个时间点某个服务做了什么,是点信息
• 服务资源指标,这方面的数据有少量是有具体格式并做了记录的的,比如MySQL慢查询日志,但是大部分是实时的非记录的,比如服务器的CPU资源占用默认就没有日志记录,这也是点信息.
• 服务器,服务节点等的心跳信息,用于确定时间点的健康,这也是点信息.
• 服务链路中的traceId,如果没有traceId或者类似的追踪定位点,那么一个网络请求过来经过了那些点是没法做时间前后顺序的链路连接的,也就是点无法连成线.这是针对某个流程,观测其演变过程,前因后果我们成为线信息.

上述的基础信息从产生数据的源进行获取,比如MySQL,Serverless实例,容器化节点,云厂商专有服务(SNS,SQS...)

在某个时间窗口,观测某些指标的规律,以及指标与指标之间的联系我们叫做面信息.基于上述的基础数据,分析服务间的协同状况,将上面的线连成面才有可能才能形成服务间关联关系的感知.

对于整个平台全部服务的点->线->面的全局多维度感知和自动处理是一个好的观察系统的本质诉求,同时记录面随时间线的数据,聚合为更加完善的立体观察平台是这个系统的理想状态.

实现观察系统的技术层次模型

本文原文链接: 观察系统解决了什么它又需要什么