读书笔记(SRE:Google运维解密):第10章 基于时间序列数据进行有效报警

SRE:Google运维解密(笔记)2 监控与告警 SSRE:Google运维解密(笔记)2 监控与告警1、什么是监控?2、为什么要监控?3、4个黄金指标4、长尾问题5、设计监控需要简化6、告警误报 1、什么是监控? 2、为什么要监控? 最初我对监控的目的想的比较简单,以为只是监控有没有问题,有问题就发告警。 3、4个黄金指标 后来我了解的稍微多点,就知道,“有没有问题”这个几个字说的太轻飘飘了。 怎么才算有问题,服务挂掉,或者机器挂掉?还是... 阅读详情
  • 服务可靠度层级模型
    在这里插入图片描述
  • 监控
    (a)埋点
    (b)指标收集:指标合成
    (c)时间序列数据存储
    (d)规则计算
    (e)报警

 

  • 汇总计算(aggregation),是分布式环境中不可缺少的一环。汇总计算过程可以将一个任务的所有实例中的某个time-series相加。通过计算总数,我们就可以计算整体速率(rate)。
    例如:一个任务在整个数据中心中的整体每秒查询率(QPS)需要通过所有实例的查询计数器[14]的变化率的总和[15]来计算。
     
  • 命运共享(share of fate)理念
    建议将所有必要的状态放在通信端点,这些状态用于维护一个互动的通信关联(例如虚拟连接)。由于这个原因,导致通信失效的情况也会导致一个或更多端点失效,这样显然会导致整个通信的失败。命运共享是一种通过虚拟连接(例如,由TCP实现的连接)维持活动的设计理念,即便网络在一段时间内失效。命运共享也支持一种“带智能终端主机的哑网络”模型。
     
NFS服务器配置与autofs自动挂载 NFS服务器配置autofs自动挂载 环境: hostname ip OS server 192.168.220.138 centos7 client 192.168.220.139 centos7 一、NFS概述 NFS(Network File System)网络文件系统。最大功能就是通过网络,让不同的机器、不同的操作系统可以共享彼此的文件。 二、端口 [root@se... 阅读详情

相关推荐

启动盘安装Win10完整指南:U盘制作、BIOS设置与分区排错

系统重装是解决电脑卡顿、系统崩溃、病毒残留等问题的基础操作,而U盘启动盘则是目前最主流的安装介质。其核心原理在于通过Rufus等工具,将原版ISO镜像写入U盘,并依据主板固件类型(UEFI或Legacy)选择对应的GPT或MBR分区表,确保引导程序能正确加载。掌握这些底层概念,不仅能提升安装成功率,还能避免因引导模式不匹配导致的黑屏、无法启动等问题。在实际应用中,无论是老旧电脑升级、硬盘更换,还是需要纯净的系统环境,制作一个可靠的启动盘都是必备技能。本文从备份数据、下载官方镜像讲起,逐步演示U盘制作、启动快

weixin_32667955的博客 343

C. Google SRE 实践

C. Google SRE 实践 概述 服务可靠度层级模型 产品设计 软件开发 容量规划 测试 + 发布 事后总结和问题根源分析 应急事件处理 监控 监控(10) 组件 ...

micklongen的专栏 1102

手把手教你打造CTF动态靶场

公司想搞一个CTF比赛,需要一个竞赛靶场,于是这个任务就落在了我的身上,平台是利用CTFd框架,基于docker搭建的动态靶场,搭建过程中遇到的坑比较多,这里我会把每一个遇到的坑都指出来。我搭建的是CTFd的3.X的版本。第一次搭建的话,搭建的过程会有些痛苦,但是搭建完成后会越来越熟练,这个平台的可用性还是很高的。由于搭建的过程中遇到的坑太多了,各种各样的问题,所以决定写下这篇文章,把所有的坑都指出来,也算为后边想搭这个平台的小伙伴指一条路。Taps:资源来源:星海安全实验室如果你也对网络安全&黑客。

Python栈 4935

SRE Google运维解密——第10章 基于时间序列数据进行有效报警

第10章 基于时间序列数据进行有效报警 一个大型的系统不应该要求运维人员持续关注其中使用的无数个小组件,而是应该汇总所有的信息,自动抛弃其中的异常情况。 监控系统应该从高级服务质量目标层次进行报警,但是也应该保持足够的力度,可以追踪到某个具体组件 Borgmon 的起源 依靠一种标准数据分析模型进行报警。使得批量,大规模,低成本的数据收集变得可能 ,成为白盒监控 报警规则使用简单的数学表...

Hcode4的博客 848

手把手教你用FPGA+AD9822搭建300DPI的CIS高速图像采集系统(附时序调试心得)

本文详细介绍了如何利用FPGA作为核心控制器,结合AD9822三通道采样保持放大器/ADC,构建一套完整的300DPI CIS高速图像采集系统。内容涵盖从CIS传感器驱动时序、AD9822寄存器配置与协同调试,到采用千兆以太网替代USB实现稳定高速数据传输的完整实战指南,并分享了关键的时序调试心得与系统集成经验。

weixin_29306261的博客 135

openbmc 支持mctp over pcie(二)

本文介绍了在OpenBMC系统中实现MCTP over PCIe的社区方案,主要针对AMD CPU和Intel CPU平台。方案基于社区开发的mctpd应用层和内核驱动,通过修改设备树(dts)配置内存区域,并编译Linux内核模块。验证时可通过查看/proc/net/protocols确认MCTP协议支持,使用ip addr命令检查mctppci0网络接口状态。相关代码和文档参考了AspeedTech和CodeConstruct的GitHub仓库。该方案为BMC作为MCTP端点提供了标准化实现方法。

wit_yuan的专栏 379

《SRE Google运维解密》读书笔记

SRE团队职责:确保服务可以正常运转 可用性改进 延迟优化 性能优化 效率优化 变更管理 (渐进式发布) 监控 紧急事务处理 容量规则与管理 (N+2 模式,google--> 15倍) SRE核心处理思想: 灾难预演与演习 确保系统按照预想方式应对故障 寻找系统中未预料的弱点 寻找其他提高鲁棒性的方式避免事故发生 从组织架构层面关注 关注...

victorzzzz的专栏 1266

C#利用最小二乘法拟合任意次函数曲线

给出一组离散点,确定一个函数逼近原函数,插值是这样的一种手段。在实际中,数据不可避免的会有误差,插值函数会将这些误差也包括在内。因此,我们需要一种新的逼近原函数的手段: ①不要求过所有的点(可以消除误差影响);②尽可能表现数据的趋势,靠近这些点。利用最小二乘法可以简便地求得未知的数据,并使得这些求得的数据与实际数据之间误差的平方和为最小 [1],其他一些优化问题也可通过最小化能量或最大化熵用最小二乘法来表达,具体可以查阅相关资料。最小二乘法(又称最小平方法)是一种数学技术。

qq_30725967的博客 3756

《SRE:Google运维解密》读后有感

当我们进行体系化的思考的后,我们就会有新的收获,并且在解决方案上更加的完善。框架和SRE平台这种模式,提供了很多的益处,比如说显著的降低运维开销,因为它支持代码结构、依赖关系、测试、编码样式指南等的强合规性测试,内置服务部署、监控和自动化,设计中自带的通用性支持,这种在框架中把基于生产最佳实践的代码模式进行标准化封装,让SRE在管理时降低了认知的负担,同时仍然可以保持服务的质量,每一个标准框架都为问题所在的领域或者问题相关的基础设市以来提供了一个完整的解决方案。,其次SRE的关注焦点在于。...

学无止境 1073

SIWAVE+ADS提取PCB走线寄生参数

本文将介绍一种很适合PCB走线提取寄生电感等参数的方法,即是通过SIWAVE将PCB走线的S参数提取出来,再通过ADS将S参数转换成电感、电容值。

sinat_15150363的博客 1766

超声波法检测局部放电的原理与实现

摘要:超声波法通过捕捉局部放电产生的声波信号进行检测,系统由超声波传感器、信号调理单元和数据采集系统组成。其核心应用是局放源定位,主要采用时差定位法和声-电联合定位法。该方法具有抗电磁干扰强、定位精确等优点,但也存在信号衰减大、传播路径复杂等缺点,典型应用于变压器、GIS等设备的在线监测与故障诊断。

start_up_go的博客 376

SRE 工程实践——基于时间序列存储数据的报警

构建智能运维平台,运行监控和故障报警是两个绕不过去的重要部分。本次分享主要是数人云工程师介绍引入 SRE 理念后的基于时间序列数据存储的报警工程实践。 SRE 报警介绍 今天我分享的主题是 SRE 基于时间序列数据的报警实践,既然是基于时间序列。 首先,我先简单介绍一下什么是时间序列数据。 时间序列( time series )数据是一系...

weixin_34356310的博客 459

51智能小车(双轮)

前几天接了个小单子,是一个基于51单品机的作品,发现自己对小车的认识还是不太🆗。也算是完成了任了的;欢迎各位小伙伴来多多交流,大家一起进步。最后有需要单片机课程设计的小伙伴滴滴我哦(有偿)。企鹅:2397746994。

qq_56992543的博客 2348

《SRE:Google 运维解密》读书笔记11: 基于时间序列数据进行有效报警 - 新型的监控

在正式进入第10章之前,有必要对“具体实践”这一部分的整体结构有所了解。章节主题核心内容第10章基于时间序列数据进行有效报警Borgmon、时间序列数据库、报警规则设计第11章on-call 轮值多地团队、轮值频率与生产环境熟悉度第12章有效的故障排查手段假设-排除法、常见陷阱第13-14章应急事件管理降低影响范围、管理事故响应第15-16章事后总结与根源分析无指责文化、事故跟踪系统第17章测试避免已知类型问题重复发生第18-22章容量规划与负载均衡Auxon、GSLB、BwE、连锁故障。

1933

Data-Structures-and-Algorithm-Analysis-in-Java.pdf

作者: Weiss, Mark A. 出版社: Addison Wesley Data Structures and Algorithm Analysis in Java is an “advanced algorithms” book that fits between traditional CS2 and Algorithms Analysis courses. In the old ACM Curriculum Guidelines, this course was known as CS7. This text is for readers who want to learn good programming and algorithm analysis skills simultaneously so that they can develop such programs with the maximum amo...

霍尼韦尔SoftMaster使用说明

霍尼韦尔SoftMaster使用说明

《SRE:Google 运维解密》读书笔记12: on-call轮值 - SRE的“生命线”

on-call 轮值是 SRE 保障服务可靠性的核心机制,通过主副值班制、多地团队、25%运维时间红线和12小时≤2事件的质量标准,让应急响应可持续。关键点一句话概括on-call 的核心目标服务可靠性(分钟级响应)+ 团队可持续性(避免疲劳战)主副值班制主 on-call 负责主要响应,副 on-call 作为备份和协助多地团队优势避免夜间值班损害健康 + 控制团队规模保障熟悉度数量平衡纯运维时间 ≤ 25%,至少 50% 投入研发质量平衡。

1742

锂电池充电器电路设计 里面有电路

锂电池充电器电路设计 里面有电路 3.7V升压到5V电路设计。

《SRE Google运维解密》散文

文章目录SRE认识运维认识SRE避免琐事工程化自动化监控发布工程oncall团队管理K8S其它章节当前问题 SRE 《SRE Google运维解密》 读书笔记 引言:曾经,觉得写接口改Bug不好玩了,就此带着热情走进了运维世界,探索这奇妙的监控、容器、自动化…。幸得茅哥的引路,让自己在运维的世界越走越远。近些天,我确定了新的方向,再次燃起我眼睛里无限探索的渴望;今天结束或许就是自己人生中最后一个运维相关岗位的工作日。假使将来有时间,我将把这些年的运维笔记整理升华发布于此。 认识运维 软件的生命周期

IMPlove的博客 669

Google SRE 读书笔记 扒一扒SRE用的那些工具

写在前面 最近花了一点时间阅读了《SRE Goolge运维解密》这本书,对于书的内容大家可以看看豆瓣上的介绍。总体而言,这本书是首次比较系统的披露Google内部SRE运作的一些指导思想、实践以及相关的问题,对于我们运维乃至开发人员都有一定的借鉴意义。 书中的一些思想也令我印象深刻,例如SRE工程师要保证投入50%的时间在项目上、错误预算、命运之轮、事故总结等等,对于从业者有很大的启发。...

aifeier1982的博客 1267

《SRE:Google 运维解密》读书笔记07: 监控分布式系统 - SRE的“眼睛“

监控 = 用四个黄金指标(延迟/流量/错误/饱和度)度量服务健康,用白盒定位原因、用黑盒发现现象,只告警真正需要人介入的问题,其余交给自动化。关键点一句话概括监控的五大目的趋势分析、实验对比、告警、仪表板、事后调试四个黄金指标延迟、流量、错误、饱和度——从用户视角抽象服务健康度白盒 vs 黑盒白盒关注"原因",黑盒关注"现象";两者结合才是完整监控分布 > 平均值P99 延迟反映长尾问题,平均值会掩盖糟糕的用户体验现象 vs 原因紧急告警应关注用户可见的现象,而非系统内部的原因。

1631

《SRE:Google 运维解密》读书笔记39: 完结篇补充2 - SRE进阶学习路线图

第一阶段(巩固基础):阅读《SRE Workbook》,动手定义你当前负责系统的 SLI/SLO,并尝试进行一次完整的事后复盘(Post-mortem)。第二阶段(深化技术):阅读 DDIA 理解分布式原理;搭建 Prometheus+Grafana 监控体系;学习 Terraform 管理基础设施。第三阶段(拓展视野):阅读《Observability Engineering》;引入混沌工程实验;关注 SRECon 最新议题。第四阶段(架构与组织):阅读《Team Topologies》;

2480

读书笔记(SRE:Google运维解密):第11章 on-call轮值

作为生产系统的监管者,on-call工程师负责处理生产环境中即将或者正在发生的业务事故,以及评审对生产系统的变更请求。   紧急事件(incident)的定义是:一系列根本原因一致或者相关的事件和报警信息,这些事件应该在同一个事后报告中讨论   现代理论研究指出,在面临挑战时,一个人会主动或非主动(潜意识)地选择下列两种处理方法之一: (a)依赖直觉,自动化、快速行动。 (b)理性、专注、有意识地进行认知类活动。   在应急事件处理过程中,最理想的方法论是这样的:在有足够数据.

lo_ong的博客 700

读书笔记(SRE:Google运维解密):第16章 跟踪故障

提高可靠性的唯一可靠的方法论是建立一个基线(baseline),同时不断跟踪改变。   消息系统 (a)消息聚合:能更好地消除重复报警,避免重复性工作。 (b)加标签: (c)分析:包括计数和基本的汇总统计报告;环比。找到影响更广泛的问题。 ...

lo_ong的博客 336

读书笔记(SRE:Google运维解密):第15章 事后总结:从失败中学习

基本的事后总结条件为: (a)用户可见的宕机时间或者服务质量降级程度达到一定标准。 (b)任何类型的数据丢失。 (c)on-call 工程师需要人工介入的事故(包括回滚、切换用户流量等)。 (d)问题解决耗时超过一定限制。 (e)监控问题(预示着问题是由人工发现的,而非报警系统)。   协作和知识共享 (a)实时协作:可以很快地收集数据和想法 (b)开放的评论系统:使大家都可以参与进来提供解决方案 (c)邮件通知: ...

lo_ong的博客 396

SRE神作之精华

读《SRE Google运维解密》是我首次比较系统地了解和学习Google内部SRE运作的指导思想、实践以及相关问题,最近又花了一些时间,仔细阅读了关于SRE的第二本书籍《SRE生存指南》。 《SREGoogle运维解密》与《SRE生存指南》 SRE首先是一套方法论,它从传统运维中与稳定性相关的工作内容提炼出来进行升华,构建了SRE的方法论体系。冗余和容灾、容量规划、系统自动保护、失败预案、监控能力、发布与变更管理、故障应急处理等构成了SRE领域的蓝图,并不断地快速迭代着。 方...

一个天秤座的架构师 2万+

Google SRE 指导思想

第二部分:指导思想 一、拥抱风险 Marc Alvidrez 1、管理风险 不可靠的系统会很快侵蚀用户的信心,所以我们想要减少系统故障的几率。 然而,经验表明,在构建系统的过程中,可靠性进一步提升的成本并不是线性增加的——可靠性的下一个改进可能比之前的改进成本增加 100 倍。 高昂的成本主要存在于以下两个维度。 冗余物理服务器 / 计算资源的成本机会成本,这类成

watermelonbig的专栏 3852

vsphere ha 虚拟机监控错误_【第7期】云计算监控——Prometheus监控系统

本文摘自于《Prometheus监控技术与实战》一书,从云计算时代的业务特点出发,探讨了云计算监控的目标和挑战,梳理了云资源监控的范围及监控系统实现的一般方式。接着从开源监控软件的演进出发,简单介绍了Zabbix、OpenTSDB等常用监控系统。最后详细介绍Prometheus云原生监控系统的产生、发展、特点,以及成功部署可获得的运营优势。1 云计算监控的目标和挑战1. 1 云计算监控目...

weixin_39952074的博客 1191

SRE Google 运维解密 具体实践一

一、基于时间序列数据进行有效报警 Borgmon是google使用的时间序列监控系统,在开源软件中Prometheus是非常类似的一款工具。这个软件将收集时间序列信息作为监控系统的首要任务,同时发展了一种丰富的时间序列信息操作语言,通过使用该语言将数据转化为图表和报警。 因为总是会有大批量的服务器在上线、下线,建立和维护一个有效的服务注册、发现系统是很有必要的。上线的主机需要能主动让B

watermelonbig的专栏 7363
上一篇: 读书笔记(SRE:Google运维解密):第9章 简单化
下一篇: 读书笔记(SRE:Google运维解密):第11章 on-call轮值
github_37320188
博客等级 码龄10年 24粉丝 86原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值