忘记最新的科技产品和最新产品。bob手机app官网谈论最多的可观测性的趋势吗?
“SLOs真的成为一种时尚,每个人都想要他们,“说Grafana实验室主要软件工程师Bjorn“Beorn”Rabenstein最近播出bob电竞频道的一集里“Grafana的大帐篷,”我们新的播客关于人、社会、科技和工具在可观测性。“我明白了会议的名称和所有的东西,所以很受欢迎。”
以至于我们专用的一整集“Grafana大帐篷”到“在可观测性为什么SLOs mvp吗”。对于这个做事投入讨论,Parca软件工程师马提亚Loibl,谁共创开源SLO软件PyrraNadine Vehling, Grafana实验bob电竞频道室的Rabenstein加入我们的东道主垫黑麦和汤姆•威尔基学分SLOs改变Grafana实验室的业bob电竞频道务。
“我承认我比较天真的对整个误差预算SLO几年前。然后Bjorn加入给我引路,”威尔基说。“这只是如此的文化转型Grafana实验室如何测量性能。bob电竞频道,我只是很兴奋地看到项目,比如Pyrra把这个提供给更多的人。”
只要新用户也同样渴望但合理的预期。“你不会是百分之一百完美。应用在这里,”Loibl说。
“这是相当容易说服组织采用[SLOs],但是他们认为这是一个魔术棒,将解决所有问题,”Rabenstein补充道。“警报突然两个数量级少吵了。你可以谈论很多事情更有意义。你的资源计划可能是更明智的。我真的认为这是一个工具,之前会给你很多的回报,但你必须重复。”
注意:这个成绩单已经编辑了长度和清晰。
服务水平目标(SLOs):基础知识
汤姆·威尔基:SLOs是什么?它代表什么?为什么这些东西重要吗?
比约恩·“Beorn Rabenstein”:SLO代表服务水平的目标,这可以声明解释了一切。但是非常一般,这就是你的想法,你将提供的服务质量。这是经常与正常运行时间,但我们会看到,在现代系统正常运行时间不是那么容易定义;它进入错误率,误差预算。
所以你不只是尝试你最好的服务,让它运行总是可用。这实际上是不可能的。你开始谈论你的服务级别是什么?有多少你能提供你的服务,平均而言,在一定时间内?
马提亚Loibl:“某些时间段”方面对我是非常重要的,因为每一个其他的报警方式看,“嘿,出错率在过去5到10分钟吗?“如果超过一定的阈值,将警报。但服务水平目标你看看整体方案”我的服务将会是什么样子的?”或“它应该是什么样子的在四个星期吗?”然后你开始朝着这一目标。
汤姆:不是的一个例子是什么?你会如何表达不是?
马提亚:我总是喜欢用的例子是一个简单的一个:你有一个网站,有一个着陆页,和你想要的着陆页可用。这是目标。这不是一个现实的目标,所以你需要定义有多少错误你可以当服务的着陆页。也许1%的用户去你的着陆页,它很好显示500错误,它仍然是足够好了99%的其他人。
垫黑麦:如果非技术CEO进来,说:“不,我不希望有任何错误,“有人在那个位置你会说什么?
马提亚:是的,祝你好运…我认为有很多变量。显然,技术人员了解DNS问题总是,但是有很多其他东西。然后有方面的请求-响应类型的系统,你甚至不控制。我们甚至可能不能够控制它。也许有一个错误在客户端,你必须考虑这个。所以会有错误,只是多少是可以接受的。
汤姆:我注意到的一件事在这个行业有很大的推动相关话题,如持续交付。“我们应该每天部署新版本的软件。每小时。“我发现SLOs是一个伟大的交易方式的能力迅速行动,行动迅速,打破东西,著名的Facebook说,和提供一个可靠的服务的能力。
所以一旦你承认,“好吧,0.1%的请求被允许失败在一个月内,“突然的另一侧,“我今天发布这个功能的风险,它可能打破的东西?“你可以测量这两种;你可以测量你的释放哲学,你可以衡量你的SLO性能。SLO如果你做更糟糕的是,可能减缓释放。
Beorn:SLOs是汤姆说:他们一个很好的方式,客观地发现,“我们移动太快,打破太多?实际上还是我们走得太慢了,什么都不会发生,但我们也创新不够快吗?“现在你有办法说所有这些不同的利益相关者之间找到一个中间立场和移动的速度有多快。
请求和正常运行时间服务水平目标
汤姆:当我在采购、销售软件的人,他们会说,“我想要这99.9%的时间,”我说“我会让你99.9%的请求成功,“这就像我们说的两种不同的语言。你怎么让他们相信,你要给他们的东西更友好?
Beorn:这实际上取决于类型的服务。有被机器的服务;有人类所食用的服务;还有服务有合同义务履行一定的服务水平目标,然后叫SLA(服务水平协议)。还有服务,你没有,喜欢它的免费邮件服务,和你做所有你的钱从服务广告然后你没有用户的合同义务,但你仍然希望用户能快乐,而不是逃跑。
这是如何设计的关键不是:你必须看看服务消费,以及用户如何感知;直观地说,或真的有时是合法的。现实情况是,有时你在你的合同比用户所想的更重要。但是,同样,取决于上下文。
有情况uptime-based SLO就是正确的事,有时一个request-based SLO是正确的事情。有时你有一个混合的东西或者你必须想出一些全新的。
“(SLOs)是一个很好的方式客观地发现,“我们移动太快,打破太多?实际上还是我们走得太慢了,什么都不会发生,但我们也创新不够快吗?’”
- - - - - -Bjorn Rabenstein“Beorn”
设置“正确的”SLOs
汤姆:我真的想深入更多细节关于你如何构建这些SLOs。技术和技术可以使整个过程更容易。但在我们做之前,我怎么知道什么是正确的号码吗?它是80%吗?它是90%吗?它是99.999%吗?我怎么知道当我得到了正确的SLO吗?
这张:,当人们第一次开始。我一直推荐的是如果你有可用的数据你当前的系统,使用数据,测量当前的正常运行时间是在最后一个月左右,然后用这个作为基础为未来几个月基于你的目标。他们从来都不是一成不变的,所以你可以随时调整和完善。应该继续给你一个很好的基础。
Beorn:在理想的世界里,我认为这是完全有效的,马蒂亚斯说。但我想设置一个对比,在理想的世界里你永远不会只看你上个月的性能和调整你的SLOs。是有道理的在实践中,进行产品研究和了解你的产品应该被交付,服务水平你希望交付你的产品为你的客户有最好的结果。你有一个想法是多么昂贵,使其更可靠,多少快乐是你的客户。
汤姆:我们提出了我们的查询延迟SLO Grafana云度量服务是我们有效地按你说的做了,马蒂亚斯:我们看历史性能。我们就像“是的,这是它是什么。我们会坚持。”,但实际上,当我们试图卖给书第一个大型六位数Grafana云标准服务协议,客户不会接受SLO。这是真正改善查询性能的过程直到它们就像,“是的,这是不够好。现在我们将签合同。“这是我们当前的SLO锁在了,有一成不变的。它是第一个六位数的交易。
垫:这让我想起了建筑产品。bob手机app官网理想的情况下,有一些你做自己和一些猜测和假设。但最好的信息来自真实用户,从人会最终购买或使用它。
错误预算:它们是什么,为什么他们很重要
垫:我们可以深入一下,一个错误的预算是多少?
Beorn:一个错误是如果你想要一个倒置的SLO预算。或者假设你有一种特殊的SLO,基于成功率。你承诺客户服务请求正确和及时的99.9%。然后的倒数,你剩下的0.1%是你的错误的预算。现在你需要一个计费周期,如果你有一个SLA,很好地制定合同。如果你只是用户,来来去去,因为你提供一个免费产品和广告赚钱,并不是正式的。但你可能仍然想要一个计费周期,这通常是一个月。
然后你进入这个想法你燃烧误差预算。如果你有一个中断一个星期到月,和一定数量的请求失败了,那么你知道你烧你的错误预算的20%,但你也已经25%到月,这样很好。你烧误差预算在正确的水平。如果你烧得太快,你可以开始说“好的,让我们更加谨慎的行动。我们不要这样做风险本月新功能推出。”
汤姆:所以让这一点更真实,我承认没有完全理解背后的数学表达式和误差预算提醒Bjorn已经实施或马提亚工具实现,但是当我们开始提供这个SLA Grafana云服务Grafana实验室指标,我们同意99.5%的请求在几秒钟内完成。bob电竞频道所以我们建立了一个警告说,“在一个5分钟移动窗口中,如果超过0.5%的请求比几秒钟,慢页面。“这似乎是显而易见的事,对吧?
我们建造的警报,它发射,并不是所有的时间,但一周多次,有时一天多次。我们会争相扩大服务规模,诊断任何问题,通常把很多精力优化。然而,每个月月底,当我们去跑了一份报告,说什么是我们的第99.5个百分位延迟在上个月,它总是回来200毫秒。我说,“这两个东西怎么能是真的吗?“就像,我们是远低于SLO我们同意客户,我们在我们的SLA,然而我们要分页的一天多次。
“采用SLOs和与他们的高质量警报一直更为深刻的事情之一的工作。”
——汤姆·威尔基
Beorn:是的,这是问题的核心。如果你的计费周期是五分钟,那么你的5分钟滑动窗口恰恰是正确的。这是当你承诺客户”,每隔五分钟,我们永远知道我们永远不会有超过0.5%的错误。”,但如果你有一个计费周期一个月,这对我们的系统,通常要求更有道理,你可以说平均超过一个月,这样让我有一个5分钟或10分钟或者如果它是一个完整的故障,这与我们的系统可能是罕见的,这仍然是好的,如果剩下的月是完全好的。但是,同样,取决于你的产品,你的用户,你的合同。
但这是最重要的:有一个不吵SLO。每5分钟窗口小于0.5%的错误通常是非常昂贵的,而且它也不是在大多数情况下用户需要什么。这就是你进入平均,这就是报警也越来越复杂,为了不让它吵了。
汤姆:日夜,Bjorn把我们的标准服务。我们从分页每隔几天,有时一天多次,只有分页每隔几周这个特殊的警报。当它做的页面,有一个实际的问题,我们可以解决。
其他团队Grafana实验室很快就像,“哦bob电竞频道,我们想要的,”,他们充满警戒规则Bjorn构建和实现他们的服务。我们看到一个巨大的减少随叫随到负载。
垫:我想问,如何团队这样做如果你没有Bjorn进来,只是为你这么做吗?
汤姆:每一个人都没有Bjorn吗?
垫:我不认为每个人都有一个比约恩。在推出的扩展问题。我们没能推出足够bjorn。不幸的是没有,不是每个人都有一个。所以他们如何发现?
汤姆:如果每个人都没有比约恩,我们还没有完善人类克隆,我认为这是一个很好的segue马蒂亚斯的项目,Pyrra。马提亚,我能用Pyrra为我这样做吗?
这张:这正是我们构建Pyrra。我们开始看谁是使用SLOs的角色,我们发现,通常它'sSREs,没有大的惊喜。然后我们开始采访几个人,与他们交谈了很久,想弄清楚,“你用SLOs吗?如果不是,你为什么不使用呢?”等等。所以我们真的试图找出使用SLOs的进入壁垒。Pyrra项目了,现在可以给你一个高级配置文件,你可以把你的目标和你的时间窗口。然后一个指标,或服务水平指标(SLI)使用一个普罗米修斯度量和所有PromQL查询,创建多个燃烧速率警报。所有的照顾,你真的没有去想别的,但我们谈论的是高层的事情,像“我的目标是什么?我们谈论的时间窗口是什么?”
这是一个自定义资源定义或CRD-based配置,但也Kubernetes以外的工作。每一个SLO,是一个配置文件;一旦你写这一个,它被加载到Kubernetes控制器或只是一个文件系统运行时读取这个配置和生成的输出普罗米修斯然后阅读和做所有报警和消化的重任…你可以用你正常的工作流程,和它关系到现有的普罗米修斯实例。
汤姆:我注意到,一旦你开始给人们一个接口,在那里他们可以看到SLOs性能,然后在组织内,团队要在这个接口。他们希望看到自己。
使用Bjorn的规则,他,我们开始产生仪表板和上传,然后我们开始发邮件一个PDF的仪表板云团队中的每个人都每个周一早上。随着时间的推移,我发现团队PRs提交给我们配置回购将自身添加到仪表板。现在大概有30 - 40 SLOs找到,它成为一个服务目录内的所有服务Grafana云及其性能。周一,每当这封邮件出去,SLO性能不是绿色,我得到一个电子邮件从团队问为什么。这是伟大的;我从来没有要求,但是他们觉得责任。和文化,SLOs内部的司机”哦,我们都应该报告SLO性能以同样的方式。我们都应该以同样的方式让它可见。”
我认为这些文化变化,采用SLOs和高质量的警报,它实际上可能是一个更为深刻的东西出来的这一块的工作。我认为像Pyrra可以驱动,在其他组织。这不是一个问题;这只是一个声明。这只是一些我真的很兴奋。
