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

最新推荐文章于 2024-03-17 20:01:44 发布
最新推荐文章于 2024-03-17 20:01:44 发布
阅读量2.1k 收藏 1
点赞数 1
分类专栏： 读书笔记
版权声明：本文为博主原创文章，遵循 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、长尾问题

关于长尾问题，最近有接触一点点。

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

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值