《分布式应用的 4 个核心可观测性指标.docx》由会员分享，可在线阅读，更多相关《分布式应用的 4 个核心可观测性指标.docx（5页珍藏版）》请在课桌文档上搜索。
1、基于关键的可观测性指标，我们更能了解我们的应用服务运行状态，以便提升服务运行效能。如今，种最为流行的架构设计模式便是将应用程序总体分解为更小的微服务，然后.旬个微服务负责应用程序的特定方面或功能。例如,一个微服务可能负比提供外部APl请求，而另一个可能处理前端的数据获取.以这种方式设计一个强大且故障安全的基此设施可能具有挑战性：一起监控所有这些微服务的操作可能更加困难。取好不要简单地依免应用程序日志来了解系统的成功和错误，设置适当的监控将为我们提供更完整的观测图，但可能很难知道从哪里开始。在这篇文章中，我们将介绍可观测性指标应该关注的那些服务领域，以确保大家不会错过关键信息。在开始木文内容之前
2、，我们将对所运行的应用程序设置做一些假设.我们不需要使用任何特定框架来开始跟踪指标，但是，它确实有助于对所涉及的组件有个大致的/解，换句话说，你如何设司你的可观察性工具比你跟踪什么更理要。由于足够大的微服务集需要某种程欧的协调,我们将假设使用Kubemetes进行编排.我们还假设有一个时间序列数据底，如Prometheus或InfluxDB,用于存储我们的指标数据。同时，我们可能还需要一个入口控制器（例如Kong提供的用于控制流量的控制器）和服务网格（例如Ku三）以更好地促进服务之间的连接,在实施任何监控之前，必须了解我们的应用服务实际上如何进行相互交互.编写一份文档，确定哪些服务和功能相互依
3、赖,以及可用性问地将如何影响它们，可以帮助我们制定战略,围绕为构成适当阈值的内容设冒基线数字.指标类型我们应该能纷从两个角度杳看数据点：影响数据和因果数据。影响数据表示识别谁受到影响的信息,例如，如果服芬中断并且响应变慢，ImpactData可以帮助确定受影响的活跃用户的百分比。ImpactData确定谁受到影响，CausalDala确定受影响的对象及其原因.KongIngress可以监控网络活动，可以让我们深入了解影响数据。同时，Kuma可以收集和报告因果数据.让我们看一下几个数据源，并探索可以收集到的账第数据和因果数据之间的差异。1、延迟延迟是用户执行操作与其最终结果之间所花费的时间.例如
4、，如果用户将一件商品添加到他们的阙物车中，则延迟将衡量从添加商品到用户看到表明添加成功的响应之间的时间.如果负击执行此操作的服务降级，则延迟会增加,并且如果没有立即峋应,用户可能会怀疑该站点是否正在运行为了在影响数据上下文中正确短踪延迟，有必要在整个生命周期中民踪单个事件.维续我们的果购示例，我们可能论望事件的完整流程如下所示：客户点击“加入购物车按钮浏览器发起服务器端请求，发起事件服务器接受请求数据库套询确保产品仍有廓存解析数据库响应，向用户发送响应，事件完成要成功地遵循此啦i序，我们应该标准化个命名模式，以标识正在发生的事情和发生的时间，例如CUSIOmeJPUrChaSe.initiat
5、e、CUSlOmeJPUrChaSe.queried、customerpurchase,finalized等.基于所采用的煽程语言,我们可能能峥为指标服务提供功能块或Iambda：statsd.timing(custoner-purchase.initiate)do.end通过提供特定的关键字，我们应该确定在出现延迟问即时事件的哪个部分变假。跟踪因果数据上卜.文中的范迅需要我们跟踪服务之间事件的速改，而不仅仅是执行的操作。实际上，这意味着定时服务到服务请求：statsd.histogram(,custoner-urchase.initiate,)dostatsd.histogram(custo
6、merpurchase.externaldatabasequery,)doendend这不应仅限于捕获整个端点请求/响应周期，这种延迟跟踪太广泛了，应该更细化.假设我们有一个带有发出内部数据库请求的端点的微服务。在这种情况下，我们可能希里计停收到请求的时间、查询花费的时间、服务响应请求的时间以及原始客户端收到该请求的时间。通过这种方式，我们可以精确地确定服务如何相互通信。2,流量如果有望我们的应用程序有用且受欢迎一一但此时,我们还没有做好准备，大量用户涌入可能是一件好事！网站流量的变化很爆预测.我们可能能够每天为用户负我提供服务,但事件(预期的和意外的)可能会产生意想不到的后果。我们的电子商务
7、网站是否在进行周末促梢？我们的网站是否因为一些意外的赞美而走红？流fit差异也会受到地理位巴的影.也许日本用户正在以一种法国用户没有的方式体验流靖负载.我们可能认为我们的系统正在按预期工作，倒所需要的只是大量用户涌入来测试这种信念，如果一个M件带要200是杪才能完成，但我们的系统一次只能处理一个事件，那么看起来似乎没有问HS宜到密件队列突然被工作堵塞为止,与延迟类似，跟踪整个密件生命冏期中正在处理的事件数量以了解任何腿颈很有用。例如，跟踪队列中的作业数、每秒完成的I11p请求数和活动用户数是监控流量的良好起点.对于因果数据，监控流量涉及捕获服务如何相互传输信息，类似于我们如何处理延迟，我们的监
8、控设置应该跟踪对特定服务的请求数量、它们的响应代码、它们的有效负载大小等一一尽可能多地了解请求和响应周期.当我们需要调查恶化的性能时，了解哪个服务遇到问题将有助于我们更快地跟踪可施的来源,3、错界率出踪错误率相当简单。我们的服务器作为HTTP响应发出的任何5xx（甚至Ixx）都应该被标记和计数。即使我们已经考虑到的情况,例如捕获的异常,也应该受到监视，因为它们仍然代表非理想状态。这些问四可以作为防御性编码产生的更深层次问题的警告，这些问剧没有解决实际问即,Kuma可以捕获我们的服务抛出的错误代码和消息，但这仅代表可操作数据的一部分.例如，我们还可以捕获导致错误的参数（万一杳询格式错误）、发出的
9、数据库杳诲（万一超时）、执行用户的权限（万一他们进行了未经授权的尝试）、等等，简而言之捕获产生错误时的服务状态可以帮助我们在开发和测试环境中豆制问题.4、惚和度除此之外,我们还应该跟踪每个微服务的内存使用情况、（TU使用情况、程盘读/用和可用存储。如I果我们服务的资源使用在某些时间或操作期间经常激增或以税定的速度熠加,则表明应用服务过度使用了服务器资源.虽然服务器可能按预期运行，但再次涌入的流砧或其他不可预见的事件可能会迅速推翻它。KongIngress只监控网络活动，因此不太适合跟踪饱和度。但是，有许多工具可用于使用KUbeEeteS进行跟踪.实施监控和可观察性到目前为止，我们已经讨论了在云
10、应用程序中跟踪很巾要的指标类型，接卜.来,让我们深入了斛我们可以采取的一些具体步骤来实现这种监控和可观察性，1、安装PrOeetheU8Toaetheus是监控的首选标准，是个易于安装并与Kubcrnetes设置集成的开源系统。如果班于HeIm部署，则安装会特别简生。首先，我们创建一个监控命名空间：admii%kubectlcreatenamespacemonitoring接卜来.我们使用Helm安装Prometheus0我们确保也将Promelheus图表添加到Helm：%helmrepoaddprometheus-communityhttps:(.j1,.i.；.(：I11-1nc.j*4
11、、启用口转发现在Prometheus和Grafana在我们的Kubernetes集群中启动并运行，我们需要访问他们的仪表板。在本文中，我们将设过电木端口转发以公开这些服务.这是一种荷华但不是很安全的访问方式，但不建议用于生产部署.(administrator1%POD_NAME=$(kubectlgetpods-naresacemonitoring-1-app=prometheus,Component=Server0-ojsonpath=,.items0.metadata.name)kubectl-namespacemonitoringport-forward$POO_NAME9090&(ad
12、ministrator-%PODNAME=$(kubec11getpods-namespacemonitoring1app.kuberetes.ioinstance三grafanaM-ojsopath-,.items.metadatanameM)kubectl-rmespacemonitoringport-forward$P00_NME3O0&以上两个命令在端口9090上公开Prometheus服务器,在端口3000上公开Grafana仪衣板，这些简单的步骤应该足以让其开始运行.使用KongIngressControIIer及其集成的Prometheus插件,使用Prometheus捕获指标并
13、使用Grafana将它们可视化设笆起来既快速又简单。结论当我们需要调查恶化的性能时，我们的影响数据指标都可以帮助我们确定问题的严城程度：它应该告诉我们有多少人受到影响,同样，我们的因果数据确定什么不起作用以及为什么。前者将我们指向一缕烟,后者将我们指向火，除了上述所有因索外,我们还应该考虑指标变化的速度.例如，假设我们的流玻数字正在增加.观察这些数字的变化速度可以帮助我们确定何时(或是否)它会成为问超。这时于通过定期海罟和服务更改来管理即将进行的工作至关重要.它还确定了理想的性能指标应该是什么。Google写了案本关于站点可靠性的书，这是任何开发人员的必读之书.如果我们已经在集群旁边运行Kong,那么像这样的插件直接与Prometheus集成，这意味着我们可以减少用J-监控和存储服务指标的配置.
