使用Elastic Stack做应用的360度全观察性监控

Elastic坚信，如果我们要监控企业的IT基础设施或者说完成整个软件的端到端的全链路监控，那么就不应该漏过任何一个侧面的数据。这需要通过360度的全观察性来完成。Elastic Stack，作为一个大数据平台的技术栈，在运维监控这个垂直领域，已经提供了一套完整的技术解决方案，从日志分析，到指标监控，再到软件性能监控和可用性监控，都有产品级的开箱即用的方案。

在这篇文章里面，我们通过一个例子，展示如何通过使用Elastic的全观察性解决方案去快速定位应用运行过程中的问题。

示例架构

我们假设有一个宠物医院的应用，其架构如下：

从上图可以看到，这是一个常见的前后端分离的微服务架构：

• 用户流量通过K8S的负载均衡进行导入
• 前端部署多个基于REACT的Nodejs服务器 + NGINX反向代理
• 前端通过K8S的负载均衡对后端服务器进行访问
• 后端服务包含两组服务的多个服务器，分别是：
  • 基于java spring的 web service + NGINX反向代理，用于事务型操作
  • 基于python flask的 web service + NGINX反向代理，用于检索型操作
• 数据层有两组服务器，分别是MySQL和Elasticsearch，用于提供事务数据和可检索数据

在这个架构中的每一次，我们都使用：

• filebeat，用于日志的采集
• packetbeat，用于网络数据的采集
• Metricbeat，用于系统、中间件指标的采集
• Auditbeat，用于安全、审计事件的采集

事件分析和探索

我们可以通过构建机器学习的任务，持续的对系统里面的各种指标进行监控，并且配合Alert功能，实时的对异常事件进行上报。配置了邮件告警之后，当监测到异常，我们会收到如下告警：

可以将调查链接附在邮件里面。通过链接，我们可以访问Kibana的机器学习异常监测界面。

因为是实时告警，我们可以直接观测8:00 PM的异常

机器学习任务包含了多种信息，包括：

• 服务的总体异常情况（Overall）
• 各子服务层的异常情况（spring后端和node前端）
• 异常的严重程度（Severity）
• 探测器监控的指标类型（这里是服务的时延方差指标）
• 影响因子（/api/owner）
• 指标的实际值、标准值和偏差描述

从这里，我们可以基本分析到，整体响应从前端到后端的监控都有异常，即问题定位应该是在spring的后端服务上。

通过点击右边的Action窗口，我们可以从其他方面探索整个App在这个时间段内的实际运行情况：

可探索的数据包括：

• APM运行时数据 （APM Analysis）
• APM的统计数据仪表板 (Service Analysis)
• 基础设施监控数据 （Infra Analysis)
• 服务可用性数据 （Uptime Analysis）

注意，在探索的过程中，被探索的其他数据，仍然是铆定在出现问题的时间窗口的。这个功能很利于我们做数据的切片观察

APM 探索

通过APM Analysis，进入APM的探索页面，我们可以看到，在7:58 pm 开始，接口调用的响应时间出现了一个明显的毛刺。我们可以直接在界面上下钻该毛刺。

可以看到，在这个毛刺产生阶段，不只是/api/owner这个API有问题，而且其他的api比如，api/visits同样出现了问题。
可以继续对API接口进行探索：

通过APM的数据，我们可以看到api/visits在7:58 pm ~ 8:01 pm这个时间段内的调用时间情况。在毛刺之前，api/visits的响应时间在100ms左右，在毛刺阶段，响应时间变为1000ms。

基本上，所有的的时间都是花在sping对后端数据库的访问上。在异常之前，DB的访问延时在xxx微秒（百级）左右，在毛刺阶段，变为xxxx微秒（千级）

这时，我们基本可以判断，问题可能出在数据库上！

Infra探索

要判断数据库上的问题，就全方位的IT基础设施的监控，从主机到数据库，中间件。
通过Infra Analysis对IT基础设施进行探索：

可以看到，我们对整个IT基础设施有一个全景图。颜色越深的节点，代表该资源在特定时间段内资源使用率越高。我们可以看到，这个时间点内，我们的MySQL服务器的使用情况明显比其他服务偏高。
可以通过点击右键，进入对应节点的日志。很容易，我们可以发现MySQL服务在这个时间点做了一次多表的联合扫描。耗时120s

Discovery探索

我们可以在Discovery页面再做深度的探索，可以看到，这个多表联合扫描和服务的异常是重叠的。

由此，我们找到根本原因

Service探索

我们也可以在Service Analysis页面分析服务层面的影响。比如，查看该事件段有多少用户登录了系统，系统响应时延的百分位等指标，因为所有的数据是关联分析的，我们可以在可视化图标上集成所有的信息，下图中，System performance子图，就使用machine learning的数据，在对应时间点打上了alert flag

总结

大多数时候，我们的可观察性是被撕裂的，任何从单一维度，比如日志，指标，APM方面独立去看，可以看到异常，但是却无法找到根本原因。数据需要被放在一起，提供360度的全观察性进行，才能最大化的对数据进行探索。不光是运维问题，商业洞察，安全分析同样如此，希望这篇文章对你有所启发，能够构建一个真正的大数据平台对数据进行探索，因为大数据不仅是数据量大，数据类型多，更重要的是数据并非孤立，需要放在一起才能产生价值。