听说你的监控不理想?这5个特征具备了么

听说你的监控不理想?这5个特征具备了么


在当今以用户为中心的IT环境中,越来越多的组织正在实施站点可靠性工程师 (SRE) 功能,以此来定义衡量系统的可用性和正常运行时间、提高发布效率和降低故障成本。用户需求也在不断推动系统频繁的变更。基于此,传统的监控方法根本无法满足SRE的监控期望和要求。

从本质上讲,监控是观察系统的行为。它的目的是:我的系统是否在做他们应该做的事情?

现在,越来越多的组织开始采用微服务系统架构模式,微服务中的各个服务具有很高的*度,弹性和安全性要求,因此我们需要一种新的方法来进行监控。

成功监控策略的5个特征

要使SRE取得成功,组织需要一种全新的现代方式,来管理和监控快速扩展和快速变化的IT基础设施,其中监控是保障服务稳定的关键组成部分。

那么SRE世界中的监控应该是什么样的呢?成功的监控策略具有什么特征?

1. 衡量性能以满足服务质量要求

现在,仅仅一个Ping命令,来查看系统它是正常运行还是停机了,已经是不够了。Ping 命令很有用,但它不能了解服务运行情况。知道一台机器正在运行并提供给客户的服务,才是真正的商业价值。

那么,我们如何才能最有效地衡量这些服务的性能。答案是测量系统中每个组件之间每次交互的延迟。在这个以客户为中心的世界中,高延迟就是新的“故障”

Web用户体验的质量受到众多微服务性能的影响。如果要完全了解性能,就需要检查该系统中每个组件和微服务的延迟。所有这些延迟加起来决定了客户体验的成败,从而决定了你的服务质量。

如果每100次数据库查询中就有1次运行缓慢,你的服务质量会受到影响吗?如果每100个客户中就有5个客户对你的服务感到不愉快,你的业务会受到影响吗?

但是,传统的监视方法使SRE对这些情况并不知情。每个用户都很重要,每个用户的交互也很重要。而,他们的体验直接受到每一次组件交互、每一次磁盘交互、每一次云服务交互、每一次微服务交互和每一次API 查询的直接影响,所以它们都应该被衡量。

想象一下,如果不衡量用户请求的总延迟,并在子组件和微服务中出现不可接受的延迟时提醒SRE,那么SRE就无法了解导致Web 应用程序失败的原因。

因此,SRE需要能够可靠且经济高效地测量所有数据,需要全面了解所有基础设施和所有服务指标。这不仅有助于问题的快速解决,而且一旦你收集了这些指标,你的团队就有可能在这海量数据中发掘出额外的商业价值(如:用户偏好)。

2. 集中式监控平台

传统监控,往往拥有不同的监控工具,每个工具都有特定的目的并创建数据孤岛。这是一个缺乏一致标准和流程的环境。因此,常常无法在组织内的不同团队之间以清晰且标准的方式共享信息。

拥有不同的监控工具通常需要更多额外的成本和资源,而且通常只有少数人知道如何使用它们。在战略层面,无法全面、统一地了解支撑业务的系统的运行状况和性能。

通过将你的所有指标(应用程序、基础设施、云平台、网络、容器)集中到一个可观察性平台中,你的组织将拥有一个跨团队和服务的一致的标准性的监控指标。

一个统一实时呈现和关联所有数据的集中式监控平台,整合了组织内所有团队的监控工作,并使企业能够从其监控工作中获取最大价值。

3.Metrics 2.0的监控解决方案

如果使用传统的监控流程,今天的SRE如果要从数百万个数据流中确定性能问题的根源,可能需要数小时的工程时间。为了快速解决性能问题,SRE需要系统更多的上下文内容。

带有上下文的指标,可以帮助SRE关联事件,减少识别服务故障的根本原因所需的时间。

这就是为什么SRE需要拥有符合Metrics 2.0的监控解决方案的原因。Metrics 2.0 是一组围绕时间序列指标元数据的约定、标准和概念,其目标是以自我描述和标准化的格式生成指标。

Metrics 2.0 的基本前提是没有上下文的指标,没有多大价值。Metrics 2.0 要求使用有关正在收集的指标的关联元数据或上下文标记指标。例如,在没有上下文的情况下从一百台服务器收集CPU利用率并不是特别有用。但是使用Metrics 2.0标签,你会知道这个特定的CPU指标来自这个特定的服务器。

当所有指标都以这种方式标记时,查询和分析变得非常强大。你可以根据这些标签进行搜索,并且能够以多种方式对数据进行切片和切块,以收集有关你的运营的分析见解和情报。

4.SLO要具有灵活性

服务级别目标 (SLO) ,最近已经成为描述应用程序可靠性的流行工具。正如谷歌SRE书中所描述的,SLO是应用程序开发人员和SRE团队明确捕获应用程序风险容忍度的一种方法,通过定义可接受的失败级别,然后根据该决策做出风险vs回报的决策。

用于创建 SLO 的基本步骤包括以下部分:

    • 要测量的内容 - 请求数、存储检查、操作,就是要测量什么。
    • 所需比率 - 例如“50% 的成功时间”、“99.9% 的时间可以读取”、“90% 的时间在 10ms 内返回”。
    • 时间范围 - 要为目标使用的时间段:最后 10 分钟、上个季度期间、30 天的滚动时间内。 SLO 多半使用滚动时间段或者日历单位(如“一个月”)来指定,使我们可以比较不同时间段的数据。

    将这些部分组合在一起,并在其中包含重要的“位置”信息,示例 SLO 如下所示:

    “据负载均衡器报告,最近 30 天内,90% 的 HTTP 请求成功。”

    同样,衡量延迟的基本 SLO 可能如下所示:

    据客户端报告,最近 30 天内,90% 的 HTTP 请求在 20 毫秒内返回。

    将这种做法引入组织时,从这种简单的基本 SLO 开始。 之后可以根据需要创建更复杂的 SLO。

    因为SLO是一种可用性和性能保证,所以它不应该围绕识别何时出现问题而设置。相反,SLO 应该围绕客户感知价值设置,因为这会直接影响你取得成功的能力。

    许多组织花费大量精力尝试正确设置他们的SLO。不幸的是,这是白费力气。因为,很难第一次就让你的SLO完美,这是不可能的。相反,SLO应该是一个迭代过程。你应该有一个反馈循环,根据你每天得到的信息,及时更新。因此,你的SLO要具有灵活性,需要定期重新评估它们,以确保它们不会太松也不会太紧。

    5. 保留你的监测数据以降低未来风险

    以前,监测数据通常被认为价值低且成本高。时代变了,与所有计算资源一样,数据存储的成本已经大幅下降。

    更重要的是,SRE提高了长期保留这些数据的价值。当系统出错时,SRE需要能回到过去并了解过去有关问题的原因,了解失败是如何发生的。

    数据保留,通常可以带来有价值的学习,从而降低未来的风险。

    总结

    与过去相比,在当今以客户为中心的IT环境中,SRE越来越需要更高级的监控。

    当组织接受这些监控特性时,将获得许多好处,例如更快地识别和解决问题、全面了解所有指标、更好的性能、降低成本以及对决策的准确性更有信心。

    译文链接:https://thenewstack.io/5-monitoring-characteristics-sres-must-embrace/

    上一篇:Thymeleaf模板常用知识点


    下一篇:Weblogic加Apache的群集配置