监控、日志、APM整个监控体系思考

序言

监控

在做监控之初，我的出发点很简单，就是为性能测试做基础设施的准备，因为采用Jmeter这样的工具来做，它的报表功能实在有限，很难说准确定位到性能瓶颈。进而从这个出发点来开始思考，首先考虑了Jmeter+InfluxDB+Grafana这样的组合，让性能测试有足够的数据来进行支撑，因为采用Jmeter做持续压测的话，产生报告是一个问题。由此再进行深入，我已经能够拿到压测的数据了，我是不是可以拿相应的服务器中的物理数据和相对应的软件数据来进行具体状态分析呢？再次引入Prometheus这样的监控工具来做，配合不同的exporter可以收集到大部分需要的数据，同时通过Grafana进行集中展示。这样一个相对而言整体的大盘监控，我个人认为是比较满意的了。

日志

但是这样也只能发现到大方向的问题，例如知道什么服务比较慢，有性能瓶颈，至于为什么会慢，可能需要通过查询相应时间点的日志来具体分析才能够知道，但是平时我们也有查看日志的需求，之前的做法是自己上服务器拿去对应的日志数据，再进行检索。这样的流程实在太繁琐了，所以打算部署ELK这样的日志统一调度平台，来进行统一管理，采用Elasticsearch这样的关键字分布式搜索，能够快速定位到我们想要的日志，并且搭配Kibana这样的可视化平台，能够从多个维度来对日志进行细化跟踪。对于相关问题的解决有着事半功倍的作用。

APM

监控有了，日志也有了，但是这些都是单个层面进行监控部署的，随着分布式和微服务的开展，这样的监控层面往往会显得不足，这个时候需要考虑引入APM这样的链路监控系统来进行服务跟踪，和传统的监控不一样，APM这样的监控主要是来解决分布式链路追踪，对每个服务进行跟踪，并且持续观测整个系统链路的情况，可以更具调用链，主动暴露问题。经过选型，最后决定采用Skywalking这样国人开发的APM工具。

监控

监控的本质是来对服务的稳定性做预防，例如传统的监控Zabbix工具已经可以做到很全面了，都是随着云时代的到来和分布式的大行其道，和Docker容器的快速发展，传统的监控可能面对力度不足的层面，

针对容器的监控，一般采用Prometheus并且配合着cAdvisor来对容器进行监控，当然也可以结合K8s来做容器的集群管理。同时可以利用不同的Prometheus的Exporter来监控到相关服务的数据，最后集中展示在Grafana平台。

image.png

除此之外，还可以配合不同的采集器来完成同时指标的采集，选取存储在不同类型的数据库中，在Grafana里面进行集中展示和报警监控。

image.png

image.png

当然想完成这样一个相当全面监控大盘，并非一日之功，需要不断的量化和优化相关指标，选取关键的点来进行监控，合理整合为一个监控质量面板。里面包含服务器中运行的物理指标和软件运行的性能指标。有着合理的布局配置。需要多方配合才能够得以完成。

日志

现在广泛采纳并且投入使用的就是Elastic Stack(ELK)日志分析，得益于开源社区的奉献，网上有非常多的文档来介绍怎么样进行部署，这里不讲基础层面的，更多的是关心怎么样才能够用好这样的日志分析，部署日志分析这样一套系统，其实占用的成本是挺大的，所以更多的是让日志分析能够最大利用，减少不必要的浪费。做日志统一调度的最大目的就是，方便快速的查询日志定位问题，并且根据日志来监控多个维度的问题，存在的问题也很明显，这样的日志分析需要占用服务器资源，业务日志是时时打印的。量大的话，一天可能就是几十G，所以要进行合理的收集和过滤，关键日志一定要搜集到。

image.png

APM

APM应用性能管理（Application Performance Management）主要指对企业的关键业务应用进行监测、优化，提高企业应用的可靠性和质量，保证用户得到良好的服务，降低IT总成本。

从实际的应用场景上，APM可以在以下方面为我们提供帮助：

• 最终用户体验评估和优化，提升用户体验，提高应用DAU和留存

• 链路监控，线路优化

• 机房选型，第三方服务（CDN、云服务、推送等）选型

• 竞品性能对标

• 劫持分析和优化

• 实时告警和通知

• 业务流程代码级的监控和优化

• 业务压测和性能剖析

• 快速发现和定位性能问题，减少业务故障恢复时间

image.png

• 数字化体验监控（DEM）

数字化体验监控是一种可用性和性能监控体系，支持与企业应用软件或服务进行交互时，对数字化代理、人员或机器与的运维体验和行为进行优化。为了进行这次评估，它包括实际用户监控（RUM）和合成交易监控（STM），面向基于Web的最终用户和基于移动的最终用户（EUEM）。

最终用户体验监测始终是APM最重要的维度没有之一，这也是APM与传统运维监控的最主要差别。

传统运维监控一般都是自下而上的监控，关注点在系统和服务层面，通过对基础架构、系统、服务、应用的监控来保证服务的高可用和应用的体验效果。而APM是自上而下的监控，关注点在最终用户的体验层面，通过对用户体验、网络、应用以及服务的监控来保证应用的高可用和体验效果。

• 应用程序发现、跟踪和诊断（ADTD）

应用程序发现、跟踪和诊断是一套流程，旨在了解应用服务器之间的关系，跨这些节点描述事务，并且能够深入检查方法及其他主机资源。它把三个之前不同的方面（应用程序拓扑结构的发现及可视化、用户定义的事务剖析和应用程序组件的深入探究）统一起来。所有三个方面主要专注于解决问题，相互关联。

应用拓扑逻辑发现和可视化

能自动识别应用在执行的过程中涉及的软硬件架构和组件，并且可以描绘出应用交付链中相互通讯的各种组件的访问路径，通过调用链的实现，形成拓扑图并进行可视化，直观地展示应用的拓扑逻辑。

用户定义的事务剖析

从用户请求的角度来对事务中的用户定义的事件进行追踪。可以根据要求对特定的用户访问特定的事务请求进行完整的追踪，包括在整个请求过程中涉及到的所以服务和组件。

应用组件深度钻取

对发现的服务和组件的资源消耗和事件提供足够细粒度的监控。例如对应用访问的数据库服务，MQ服务等提供深度的监控，当发现有数据库服务查询性能问题的时候，可以提供包括完整的SQL语句，执行计划，数据库状态等在内的详细监控数据。

• 面向应用程序的IT运维AI（AIOps）

面向应用程序的AIOps能够自动发现性能和事件模式，支持发现Java和.NET应用服务器支持的HTTP/S事务出现的性能异常的根本原因。这是通过机器学习、统计推理及/或其他方法来实现的。 2016 年，面向应用程序的AIOps被称为“应用分析”，后来被称为“算法IT运维”，最后在2017年年中改为“AIOps”。

其实就是运维数据分析，要求使用以下技术的组合来进行运维数据分析：复杂事件处理，统计模式发现与识别，非结构化数据索引、查询和推断，拓扑逻辑分析，多维数据库检索和分析。这里的数据分析技术都是为了对APM采集到的大量的各维度性能数据进行实时的运算和处理，从而对应用的运维和优化起到辅助决策和驱动。例如通过实时的智能基线和异常监测来驱动警报系统。

作者：我为峰2014
链接：https://www.jianshu.com/p/ec9ca8087e89