监控分布式和微服务部署

本文将介绍在高并发/大用户量下的分布式架构和微服务监控/指标收集如何变化。云计算、大数据集群和服务编排的日益普及迫使Devops人员重新思考如何大规模设计监控并通过更好的工具解决独特的问题。然后，再讨论下新部署模式的不同之处以及可以使用哪些策略来满足这些新需求。

Highly分布式系架构的挑战

工作单元与底层资源分离

容器技术改变了已部署软件与底层操作系统之间的关系。与通过传统方式部署的应用程序相比，部署在容器中的应用程序与外界、其他程序和主机操作系统的关系不同。内核和网络抽象可能会导致对操作环境的不同理解。

这种抽象级别在许多方面都非常有用，它可以创建一致的部署策略，使主机之间的工作迁移变得更容易，并允许开发人员密切控制其应用程序的运行时环境。 然而，这些新功能的代价是增加了复杂性，并且与支持每个流程的资源的关系更加遥远。

网络通信的增加

越来越依赖内部网络通信来协调和完成任务。以前单体应用现在可能分布在需要协调和共享信息的许多微服务中。这对通信基础设施和监控产生了一些影响。

首先，由于这些模型建立在小型离散服务之间的通信之上，因此网络健康变得比以往任何时候都更加重要。高度分布式应用程序使用网络来同步、检查对等系统的运行状况并传递数据。网络健康状况和性能影响更直接，这意味着需要更深入的监控来保证系统的正确。

网络变得比以往任何时候都更加重要，但由于参与者数量和单独的通信线路数量不断增加，有效监控网络的能力也越来越具有挑战性。 为了确保相同的功能，需要在数十个、数百个或数千个不同点之间进行正确的通信，而不是跟踪几个应用程序之间的交互。 除了考虑复杂性之外，流量的增加也给可用的网络资源带来了额外的压力，进一步增加了可靠监控的必要性。

功能和职责划分更细

以微服务为例，一个用户功能由许多微服务联合服务才能能完成。由于完成给定功能的责任是分散的，并且分散在不同的工作人员之间，因此了解性能问题或错误的责任可能很困难。涉及数十个服务的请求和工作单元需要更为直观的展示和告警方式

临时工作单元

当每天可能有数百或数千个节点来来去去时，可能很难知道如何从临时工作单元的碎片数据中最好地构建有关系统整体运行状况的叙述。

需要进行哪些更改来扩展您的监控系统？

Granularity and Sampling

服务数量增加导致的总流量增加是需要考虑的最直接的问题之一。

更改数据采样率可以最大限度地减少系统需要从主机收集的数据量。 采样是指标收集的正常部分，表示请求指标新值的频率。 增加采样间隔将减少必须处理的数据量，但也会降低数据的分辨率（详细程度）

为了减少低分辨率导致的信息丢失，一种选择是继续以相同的频率在主机上收集数据，但将其修改成更容易理解的数字以便通过网络传输。各个Server可以聚合和平均指标值，并将摘要发送到监控系统。这有助于减少网络流量，同时保持准确性。注意，这有助于减少数据收集对网络的影响，但其本身并不能帮助缓解在主机内收集这些数字所涉及的压力。

基于汇总数据做决策

尽管Server健康检查可以发现故障的工作单元，但健康检查池本身更适合发出警报。基于健康成员数量、池聚合延迟或池错误率的警报可以通知操作员更难以自动缓解且更有可能影响用户的问题。

与DevOps 层集成

总体而言，分布式系统中的监控层需要更全面地了解部署环境和配置机制。由于这些架构涉及的工作单位众多，自动生命周期管理变得非常有价值。

监控系统和部署平台集成，自动化分布式系统的目标是自我调节，能够根据预先配置的规则和观察到的状态进行扩展和调整。在这种情况下，监控系统在控制环境和决定何时采取行动方面发挥着核心作用。

Distributed Tracing

由于单个请求可能会涉及数十个微服务来生成响应，因此很难解释瓶颈或性能变化的根源。为了提供有关每个组件如何影响延迟和处理开销的更好信息，出现了一种称为分布式跟踪的技术。例如Pinpoint/Skywalking等

每个请求都会在基础设施的边缘获得一个唯一的ID，该ID会在任务遍历基础设施时传递。 然后，每个服务使用此 ID 来报告错误以及首次看到请求以及将其移交给下一阶段的时间戳。 通过使用请求 ID 聚合来自组件的报告，可以通过您的基础设施跟踪具有准确计时数据的详细路径。

此方法可用于了解流程的每个部分花费了多少时间，并清楚地识别延迟的任何严重增加。 这种额外的检测是一种使指标收集适应大量处理组件的方法。 显示不同服务之间的关系、每个进程运行的时间以及必须并行运行的事件之间的依赖关系。 这对于了解如何改进系统以及时间是如何花费的非常有用。

提高分布式系统的操作响应能力

设置每一层的四个黄金度量指标

• latency
• traffic
• error rate
• saturation

服务全景图

为每一个服务，描绘出上下游依赖的服务地图，直观的展示健康状态，便于排查问题

深入研究具体的问题

按优先级顺序深入了解列表中的服务和系统。有关各个单元的详细指标将帮助您跟踪故障路径到最低责任资源。 简单粗暴的理解，dev了解ops，ops要了解dev

故障的缓解和处理

解决方案将分为三个阶段：

• 采取措施解决问题并立即恢复服务
• 解决根本问题以恢复完整功能和运行状况
• 全面评估失败原因并实施长期修复以防止再次发生

在许多分布式系统中，冗余和高可用组件将确保服务快速恢复，尽管后台可能需要更多工作来恢复冗余或使系统摆脱降级状态。随着监控系统的复杂性不断发展，它还可以通过向部署平台发送命令来启动故障单元的新实例或循环淘汰行为不当的单元，从而使一些更全面的恢复过程自动化。

鉴于前两个阶段可能实现自动化，Ops团队最重要的工作通常是了解事件的根本原因。 从这个过程中收集的知识可用于开发新的报警触发器和策略，以帮助预测未来发生的情况并进一步自动化系统的反应。 监控软件通常会获得新的功能来响应每个事件，以防范新发现的故障场景。 对于分布式系统，分布式跟踪、日志、时序数据可视化和最近部署等事件可以帮助您重建事件序列并确定可以改进软件和人工流程的地方。