美文网首页云原生
Prometheus架构从入门到实践(1) --监控的基础知识

Prometheus架构从入门到实践(1) --监控的基础知识

作者: 負笈在线 | 来源:发表于2021-12-04 21:30 被阅读0次


    1・什么是监控

          从技术角度来看,监控是衡量和管理技术系统的工具和流程。同时,监控将系统和应用程序生成的指标转换成对应的业务价值。监控系统会

    将这些指标转换成衡量用户体验的依据,该依据为业务提供反馈,以确保为客户提供了所需的产品。同时这个依据还提供了对技术的反馈,

    指出哪些组件不起作用或者导致服务质量下降。

    ・技术作为客户

        监控系统的第一个客户是技术,这是你、你的团队以及其他管理和维护技术环境的同事(可能被称为运维工程师、DevOps或是SRE)需要

    面对的。你可以通过监控来了解技术环境状况,还可以帮助检测、诊断和解决技术环境中的故障和问题(尤其是在影响用户之前)。监控

    提供了大量的数据,帮助洞察关键的产品和技术决策,并衡量这些项目是否成功。监控也是产品管理生命周期以及与内部客户关系的基础,

    有助于验证项目资金是否得到充分利用。

    ・业务作为客户

            业务是监控系统的第二个客户。监控系统是为了支持业务,并确保业务持续开展。监控可以提供报告,使企业能够进行良好的产品和技术投

    资,还有助于企业衡量技术带来的价值。

    2・监控的误区

    ・事后监控

            即将监控和其他运维工作(比如安全性)视为应用程序的增值组件而非核心功能。与安全性一样,监控也应该是应用程序的核心功能。

    ・机械式监控

            为所有应用程序建立货物崇拜式的监控系统。比如,监控每台主机上的CPU、内存和磁盘,但不监控可以指示主机上应用程序是否正常运行

    的关键服务。从业务逻辑和业务输出开始,向下到应用程序逻辑,最后到基础设施。这并不意味着你不需要收集基础设施或操作系统指标——它们在诊断和容量规划中很有帮助——但你不太可能使用这些来报告应用程序的价值。

    ・不够准确的监控

            这个反模式的一个常见形式是虽然监控了主机上的服务状态,但不够准确。例如,通过检查HTTP 200状态码可以监控Web应用程序是否

    正常运行,它会告诉你应用程序正在响应请求,但并不会反映出是否返回了正确的数据。

    ・静态监控

            使用静态阈值。

    ・不频繁的监控

            设定监控周期都是一项挑战。

    ・缺少自动化或自服务

            如果应用程序开发人员觉得监测应用程序、收集数据或可视化很难完成,那么他们可能就不会去做这些事。

    3・良好的监控系统

    ・全局视角:从最高层(业务)依次展开

    ・协助故障诊断

    ・作为基础设施、应用程序开发和业务人员的信息源

    ・内置于应用程序设计、开发和部署的生命周期中

    ・尽可能自动化,并提供自服务

    4・通用的监控方法(监控机制)

    ・探针(黑盒)・内省(白盒)

            探针监控是在应用程序的外部,它查询应用程序的外部特征:监听端口是否有响应并返回正确的数据或状态码。比如ping进行ICMP检查。

    内省监控主要查看应用程序内部的内容。。应用程序经过检测,并返回其状态、内部组件,或者事务和事件性能的度量。这些数据可准确

    显示应用程序的运行方式,而不仅是其可用性或其表面行为。内省监控可以直接将事件、日志和指标发送到监控工具,也可以将信息发送给

    状态或健康检查接口,然后由监控工具收集。

    ・拉取・推送

            基于拉取的监控方式会提取或检查远程应用程序——例如包含指标的端点,或是探针监控中使用ICMP进行的检查。

            基于推送的监控方式中,应用程序发送事件给监控系统接收。

    ・指标・日志

            指标用于记录应用程序度量的状态

            日志是从应用程序发出的(通常是文本的)事件

    5.监控方法论

    USE方法

            Brendan Gregg的USE(Utilization、Saturation和Error)方法,针对每个资源,检查使用率、饱和度和错误,侧重于主机级监控。监控那些受高使用率或饱和度的性能问题影响的资源来说是最有效的。

            ·资源:系统的一个组件。在Gregg对模型的定义中,它是一个传统意义上的物理服务器组件,如CPU、磁盘等,但许多人也将软件资源包含在定义中。

            ·使用率:资源忙于工作的平均时间。它通常用随时间变化的百分比表示。

            ·饱和度:资源排队工作的指标,无法再处理额外的工作。通常用队列长度表示。

            ·错误:资源错误事件的计数。

    Google的四个黄金指标

            四个指标延迟、流量、错误、饱和度来自Google SRE手册,专注于应用程序级监控。

            ·延迟:服务请求所花费的时间,需要区分成功请求和失败请求。例如,失败请求可能会以非常低的延迟返回错误结果。

            ·流量:针对系统,例如,每秒HTTP请求数,或者数据库系统的事务。

            ·错误:请求失败的速率,要么是HTTP 500错误等显式失败,要么是返回错误内容或无效内容等隐式失败,或者基于策略原因导致的失败

            ·饱和度:应用程序有多“满”,或者受限的资源,如内存或IO。这还包括即将饱和的部分,例如正在快速填充的磁盘。

    6.告警和通知

            警报和通知是监控工具的主要输出。

    出色的通知系统,需要考虑以下基础信息:

            ·哪些问题需要通知

            ·谁需要被告知

            ·如何告知他们

            ·多久告知他们一次

            ·何时停止告知以及何时升级到其他人

    通知框架的重点

            ·使通知清晰、准确、可操作。

            ·使用由人而不是计算机编写的通知在清晰度和实用性方面有显著差异。

            ·为通知添加上下文。通知应包含组件的其他相关信息。

            ·仅发送有意义的通知。

    相关文章

      网友评论

        本文标题:Prometheus架构从入门到实践(1) --监控的基础知识

        本文链接:https://www.haomeiwen.com/subject/zmhwtrtx.html