SRE:Google运维解密(笔记)2 监控与告警

最新推荐文章于 2025-06-16 00:12:42 发布
最新推荐文章于 2025-06-16 00:12:42 发布
阅读量2.1k 收藏 1
点赞数 1
CC 4.0 BY-SA版权
分类专栏： 读书笔记
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/python_bobo/article/details/88395770
本文深入探讨了监控与告警在运维中的重要性，包括4个黄金指标的概念，如何处理长尾问题以确保指标的准确性，以及监控系统设计的简化原则。告警误报问题被提及，其可能导致的信任危机需要通过精心制定报警规则来缓解。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

SSRE:Google运维解密（笔记）2 监控与告警

1、什么是监控？

在这里插入图片描述

2、为什么要监控？

最初我对监控的目的想的比较简单，以为只是监控有没有问题，有问题就发告警。
在这里插入图片描述 在这里插入图片描述

3、4个黄金指标

后来我了解的稍微多点，就知道，“有没有问题”这个几个字说的太轻飘飘了。
怎么才算有问题，服务挂掉，或者机器挂掉？还是某个cpu，mum满了？
报警的策略下面会说，但是关于指标，本书描述的很清楚。
在这里插入图片描述
在这里插入图片描述

4、长尾问题

关于长尾问题，最近有接触一点点。
有些指标统计出来，一小部分数据的对应值特别高，导致平均数被拉高不能反应真实的情况。
比如http请求延迟，绝大部分数据都在10ms，但小部分请求不到的可能会达到timeout，500ms，那么这部分会使得平均数非常高，如果以

最低0.47元/天 解锁文章

200万优质内容无限畅学
【读书笔记】SRE：Google运维解密 第Ⅰ部分 概览
睡觉的咖啡
08-19 493
研发团队和系统运维团队分属两个部门所带来的间接成本就没那么容易度量了，但是这些间接成本往往大得多。
《SRE：Google运维解密》读后有感
学无止境
07-22 944
当我们进行体系化的思考的后，我们就会有新的收获，并且在解决方案上更加的完善。框架和SRE平台这种模式，提供了很多的益处，比如说显著的降低运维开销，因为它支持代码结构、依赖关系、测试、编码样式指南等的强合规性测试，内置服务部署、监控和自动化，设计中自带的通用性支持，这种在框架中把基于生产最佳实践的代码模式进行标准化封装，让SRE在管理时降低了认知的负担，同时仍然可以保持服务的质量，每一个标准框架都为问题所在的领域或者问题相关的基础设市以来提供了一个完整的解决方案。，其次SRE的关注焦点在于。...
《SRE：Google运维解密》
weixin_33727510的博客
01-19 653
2019独角兽企业重金招聘Python工程师标准>>> ...
微服务架构监控：四大黄金指标解析
最新发布
AI云原生与云计算技术学院
06-16 727
随着微服务架构的普及，分布式系统的复杂度呈指数级增长。服务间依赖关系的碎片化、流量模式的动态变化、故障传播的不可预测性，对传统监控体系提出严峻挑战。本文聚焦Google SRE提出的四大黄金指标（Four Golden Signals），系统讲解其在微服务监控中的应用框架，涵盖指标定义、数据采集、阈值设定、异常响应全流程，帮助技术团队建立标准化的监控度量体系。核心概念：解析四大黄金指标的定义与相互关系，构建监控指标矩阵技术实现：基于Prometheus/Grafana生态，演示指标采集与可视化落地。
googleSRE运维解密
weixin_44246168的博客
03-20 1318
SRE读书沉淀
《SRE:Google运维解密》读书笔记（一）
weixin_33699914的博客
02-07 499
1.SRE是目前最火的devops模型在google具体实践；2.Google SRE都有的共同特点是对重复性工作有排斥感以及喜欢用技术来代替手工操作；3.SRE核心的工作职责是变更管理、监控、故障处理、可用性改进以及优化；4.SRE将运维工作限制在50%，剩余时间花在研发上。5.SRE最终工作是在系统的稳定性和灵活性保持平衡；6.一个需要人工阅读邮件和分析警报来决定目前是否需要采取某种行动的系统...
SRE-Google运维解密随记-1
砚墨
12-31 536
增加现有容量经常需要启动新的实例甚至是整个集群，这通常需要大幅度修改现有的集群配置(配置文件、负载均衡、网络等),同时还要执行一系列测试，确保新上线的容量可以正确地服务用户。虽然不论多么完备的“运维手册”也无法替代人的创新思维，但 是在巨大的时间压力和产品压力下，运维手册中记录的清晰调试步骤和分析方法对处理 问题的人是不可或缺的。、一个业务的容量规划，不仅仅要包括自然增长(随着用户 使用量上升，资源用量也上升),也需要包括一些非自然增长的因素(新功能的发布、商业推广，以及其他商业因素在内)。
读书笔记（SRE：Google运维解密）：第22章 处理连锁故障
lo_ong的博客
11-09 490
连锁故障是由于正反馈循环（positivefeedback）导致的不断扩大规模的故障。 连锁故障可能由于整个系统的一小部分出现故障而引发，进而导致系统其他部分也出现故障。例如，某个服务的一个实例由于过载出现故障，导致其他实例负载升高，从而导致这些实例像多米诺骨牌一样一个一个全部出现故障。   连锁故障产生的原因 （a）服务器过载：直接由于服务器过载导致，或间接由于服务器过载引发的其他问题导致 例如，某个集群内部的过载可能会导致该服务实例崩溃；这时负载均衡器会将请求发送给其他集群，使那.
读书笔记（SRE：Google运维解密）：第6章 分布式系统的监控
lo_ong的博客
10-04 423
绝大部分通用的术语： （a）监控（monitoring）：收集、处理、汇总，并且显示关于某个系统的实时量化数据，例如请求的数量和类型，错误的数量和类型，以及处理用时，应用服务器的存活时间等 （b）白盒监控（white-box monitoring）：依靠系统内部暴露的一些性能指标进行监控。包括日志分析、Java虚拟机提供的监控接口，或者一个列出内部统计数据的HTTP接口进行监控。 （c）黑盒监控（black-box monitoring）：通过测试某种外部用户可见的系统行为进行监控。 （d）监控台页面（d.
SRE Google运维解密_读书笔记1
snlying的专栏
07-15 872
监控的4个黄金指标：错误、延迟、流量、饱和度（容量）。 SLO服务水平目标，健康度检测使用 运维平台： 关于应急管理时，有没有考虑过通过一键触发的方式，将当前紧急情况通过内部通讯工具、邮件、短信等渠道触达到系统相关人。这样可以实时看到当前系统处理情况，调配各种资源协助，根据故障情况决定是否升级保障，记录整个应急处理各时间点的过程，也便于编写事后总结报告。当前应急处理时大家忙于处理问题，内部通讯...
SRE:Google运维解密(心得)
python_bobo的博客
03-06 2885
SRE:Google运维解密（心得）风险与可用性错误预算总结： 风险与可用性 在一个运行的系统中，出现风险是不可能避免的，而运维工程师的存着便是控制并解决风险。 书中提到构建百分百可靠的服务是不可取的，因为一个服务面向用户的不止是可靠，还有创新。当可靠性达到一定的数量级后，再花费大量的成本在可靠性上而忽略服务的创新，这种方式得不偿失。 书中还提到可用性为多少个‘9’这个概念 上面提到额外一个‘9...
SRE Google运维解密-第二章
intheafk的博客
03-09 294
google使用 Borg（伯格）分布式集群管理系统进行资源分配，负责集群层面管理任务的编排工作； google使用 BNS 在Borg启动某一个任务时，会给每个具体的任务实例分配一个名字和编号，作为名称解析、地址转换； google数据中心构建拓扑结构： Rack Row Cluster Datacenter Campus 数台物理服务器组成机柜 数台机柜组成机柜排 数排机柜组成一个集群 多个集群组成数据中心 多个相邻的数据中心组成园区 google使用..
SRE - 监控建设
qq_34068440的博客
12-24 1154
本文旨在深入介绍监控文档中的各要素，探讨监控工具的应用，以及阐述监控建设的方法和最佳实践，以实现高效的服务运维和故障应急。服务指标阈值和使用规则定义了错误预算，即允许一定量的服务不可用，如99.9%的SLO可能意味着每月最多43分钟的完全服务中断。- 故障自愈：设计和实施自动化的故障恢复和自愈策略，如自动重启服务、调整资源分配、切换流量等，减少人工干预的需求和故障恢复的时间。- 提高故障发现率：通过实时监控系统各项指标和日志，及时发现潜在的故障和异常情况，减少因未被察觉的问题导致的服务中断或性能下降。
SRE Google运维解密——第10章 基于时间序列数据进行有效报警
Hcode4的博客
09-14 766
第10章 基于时间序列数据进行有效报警 一个大型的系统不应该要求运维人员持续关注其中使用的无数个小组件，而是应该汇总所有的信息，自动抛弃其中的异常情况。 监控系统应该从高级服务质量目标层次进行报警，但是也应该保持足够的力度，可以追踪到某个具体组件 Borgmon 的起源 依靠一种标准数据分析模型进行报警。使得批量，大规模，低成本的数据收集变得可能 ，成为白盒监控 报警规则使用简单的数学表...
保持警惕 - SRE 的监控与告警基础
weixin_42587823的博客
05-20 1050
监控为我们提供了观察系统内部运作的“眼睛”，让我们能量化可靠性、诊断问题、做出数据驱动的决策。而有效的告警机制则是将这些观察转化为及时、可操作响应的关键，帮助我们在问题失控前介入处理。理解监控什么、如何监控以及如何设置有意义的告警，是每一位 SRE 的基本功。那么，当告警真的响起，系统确实发生故障时，SRE 该如何有效地进行响应和处理呢？没有监控，我们就如同在黑暗中驾驶，对系统的真实状况一无所知，更谈不上保障其可靠性了。通常，我们会结合使用这些方法，确保从服务到基础设施都有全面的监控覆盖。
如何做监控？Google SRE 解密
一猿小讲
02-13 1703
监控值班室：@隔壁老王头 SQL执行耗时时间过长，达到了报警阈值【5000ms】隔壁老王头：@监控值班室 少量报警请忽略，批量关注即可。监控值班室：@隔壁老王头 ...
SRE认知之监控概述
fsx2550553488的博客
07-05 767
监控 监控理念 当为监控系统和警报系统增加新的规则时，我们应该关注一下问题： 该规则是否能够检测到一个目前检测不到的、紧急的、有操作性的，并且即将发生或者已经发生的用户可见故障？ 是否可以忽略该警报？什么情况可能会导致用户忽略该警报，如何避免？ 这条警报是否确实显示了用户正在收到影响？是否存在用户没有收到影响也会触发这条规则？例如测试环境和系统维护状态下的警报是否应该被过滤掉？ 收到警报后，是否要进行某个操作？是否需要立即执行该操作，还是可以等到第二天早上再进行？该操
SRE学堂：OSS监控告警案例分析
阿里云开发者
01-15 3379
简介：【SRE学堂】OSS从入门到精通第四章：OSS监控告警案例分析处理阿里云阿里云智能GTS-平台技术部-SRE混合云技术服务赋能团队通过OSS第一章的学习，大家知道了OSS是什么、OSS的各项优势、OSS的架构组成以及OSS相关的一些基本概念；通过OSS的第二章的学习，大家知道了如何创建、查看、删除、修改OSS的存储空间，如何实现object上传、下载、删除的操作；通过OSS第三章的学习，大家知道了OSS如何执行天基的终态检查、赤骥白屏巡检以及黑屏巡检；第四章将为大家介绍OSS监控TAC以及OSS集群出
SRE Google 运维解密--管理
watermelonbig的专栏
06-15 7074
一、迅速培养SRE加入on-call 在SRE团队的职责中，主动性任务和被动性任务兼有，每个SRE团队都坚守的一个重要目标是：利用积极主动的办法，去减少和限制被动性工作的产生。 SRE培训课程 推荐的培训方式 错误的培训方式 设计一个具体的、有延续性的学习体验，以便学员跟进 通过给学员安排一些烦琐的工作（处理警报/工单）来培训
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值