云原生全栈监控解决方案（全面详解）.docx

前言当前全球企业云化、数字化进程持续加速，容、徵服务等云原生技术在软件架构中快速渗透，IT架构云化、匆朵化持续骤动性能监控市场，企业云化、数字化持续转型，以及为了考虑系统的邦性、效率，企业软件开发中大量云底生技术的应用推动全球IT监控市场快速变化，如何全面、有效的对容器、K8s、微服务进行监控是当N云原生技术面临的Ift要课次.背景和挑战云化产品通常采用服务化框架，由一系列微服务组成，目微服务是可以独立运行的进程，不同服务可使用不同开发语言，可能分布部署在几千台服务器上，甚至可能横跨多个不同的数据中心，服务间使用轻量的通信机制；服务之间存在复杂的调用关系，对运维人员理解系统的行为或分析系统性能带来巨大挑战如：(1)容器是否正常运行(2)K8S是否正常运行.(3)微服务是正常(5)业务调用出现问题，如何快速找出哪个服务发生失败？(6)某个业务调用耗时较长，如何快速找到性能瓶颈点？<7)如何快速获取某次调用的业务H志进行分析定位？解决方案概述云原生监控体系包括:Healthchecks.Metrics.1.oggingTracing.Healthchecks:健康检宣可以定期检直某个应用的存活状态；Metrics:度量指标监控，在离散的时间点上产生数值点；1.ogging:日志监控；Tracing:调用链监控。各种监控工具适用场景如下图所示：适用场合健康检笠微服务架构，为了保证所有服务可用，当服务发生问题时能及时摘除有问题的服务需要定期检测服务可用性，即健康检直.通常健臣健康检直包括TCP与HTTP两种.即定时发送TCP或HTTP请求，根据响应来确定服务是否可用.一般通过TCP定期请求来判定网络层是否正常,而通过Http请求判断应用层是否正常.服务要配置好请求接口，检测服务定期向指定的接口发送http请求,并根据接口响应码和响应时间判断.Springboot的endport/health可以检直应用的健康状态，举例说，当我们访问http:/localhost:8088/health时，可以看到HeaIthEndPoint给我们提供默认的监控结果，包含磁盘检测和数据库检测。Pstatus":UP'f"diskspace":'status':'UP，'total':398458875904,"free":315106918400,'threshold":10485760，,db,:Pstatus':'UP',-database":,MySQ1.",hello':1)容器监控容器监控使用Prometheus-CAdvisor,CAdvisor是谷歌专为监控容器性能状态设计的一个开源工具,CAdvisor提供有Push和Pull两种获取性能数据的接口.Push接口指的是由CAdvisor主动将数据周期性的推送到远端的存储服务中，Influxdb与CAdvisor的对接就是通过这个接口完成的.而PUIl接口则允许外部访问服务随时主动从CAdvisor获取到当时时刻的性能数据，然后自行处理，Prometheus与CAdvisor的对接用的是这种方法.基于容器的微服务监控和原始的监控是有很大区别的，因为服务的实例生存周期很短分分钟可能就会有容器的生灭.微服务的容器与宿主机的监控商不开CPU、内存、磁盘、网卡这些基础的性能指标，对于宿主机的监控来说，我们可以依然使用原始的监控方式，每个宿主机安装一个代理来采集服务器的性能指标，代理在采集性能指标的时候可以打上时间觑和相应的标签来区分不同性能指标的数据维度（metric）,然后将监控数据汇总到时间序列数据库，里面的数据可以对接目前一些开源的组件来进行可视化的展示，也可以对接报警服务（结合报警服务的报警策略）进行报警.容器的监控自然就和宿主机不太一样了，我们不能说给每个容器镜像内部都集成一个监控代理（agent）,这样的话侵入性太强，不易于维护.Prometheus有很多的Exporter可以用来采集监控数据，例如我们想采集KUberneteS上所有容器（pod）的性能指标的话，Promethus可以通过直接配百多个KubernetesApiServer的Endpoints来监控整个Kubernetes集群.K8S监控K8S集群层面选择使用Prometheus.集群层面的监控又分为Node,K8S基础组件、K8S资源对象三大类。I、对于Node的监控，Prometheus提供了node-exporter,可采集到CPU、内存、磁盘10、磁盘使用率、网络包量、带宽等数据；2、K8S基础组件类的kubelet,kube-apiserver,kube-controller-manager和kube-scheduler等,都提供了metrics接口基露自身的运行时的监控数据，这些数据都可被部署在K8S奥群中的Prometheus直接拉取到；3、结合CadViSOr和kube-state-metrics,可直接采集至JK8S中Pod的CPU.内存、段盘10、网络IO等数据。由COreoS开源的KUbe-PrOmetheUS项目，极大简化了Prometheus的安装部署运维工作.基于KUberneteS实现的微服务应用级的监控插件，如下图：fSw<B:http/metrics在Kubernetes的master节点，也就是安装aiserver的那台服务器上运行一个监控插件,该插件可以通过一个kubernetes提供的官方客户端来访问apiserver,苜先我们要告知插件要监控哪个namespace下的哪个service,然后，插件通过3-1）创建编辑rabc.ymlrbac.yml定义了Prometheus容器访问k8sapiserver所需的ServiceAccount和CIusterRoIe及CIusterRoIeBinding3-2）创建编辑configmap.ym进行configmap中的prometheus的配署文件3-3）prometheus-deploy.ym定义Prometheus的部署3-4）PrOmetheUS-SVC.yml定义Prometheus的Service需要将Prometheus以NodePort,1.oadBaIancer或使用Ingress易露到集群外部,这样外部的Prometheus才能访问它.3-5）使用yml文件创建对象kubectlcreate-frbac.ymlkubectlcreate-fconfigmap.ymlkubectlcreate-fprometheus-deploy.ymlkubectlcreate-fprometheus-svc.yml4 ）百己2S配JSPrometheusFederation完成Kubernetes集群上的Prometheus的部署之后，下面将配置集群外部的PrOmetheUS使其从集群内部的PrometheUS拉取数据.实际上只需以静态配置的形式添加一个job就可以.5 ）£Spushgateway日志监控Fluentd是一个通用的信息收集、整理、转发的流式数据处理工具。默认情况下Docker会将所有容器输出到系统控制台的内容函定向到以容器ID命名的一个本地目录中，只需要定期采集所有这些目录的内容就能一字不混的将容器的输出捕获出来，这种方式的侵入性很小，但由于是周期性的收集，日志在汇聚端（例如Kibana）的展示会有一定的延时，延时长度与日志收集的周期相关。相反的，如果使用Docker的日志驱动（启动docker后台服务时指定参数-log-driver=fluentd）将获得实时性很好的汇聚端日志展示，但由于日志直接发送到了远端的Fluentd服务，会使得在本地主机上的dockerlogs命令失效.两种方式的共性在于：不论通过哪一种方式，收集到的日志都能修以容器名称、镜像、标签等对容器使用十分友好的维度进行检索。Kubernetes集群本身不提供日志收集的解决方案，我们采用fluentd>kafka->Iogstash->elasticsearch>kibana的方式,亘接在应用程序中将日志信息推送到采集后端.调用链监控调用缝定义：在系统完成一次业务调用的过程中，把服务之间的调用信息（时间、接口、层次、结果）打点到日志中，然后将所有的打点数据连接为一个树状链条就产生了一个调用链.跟踪系统把过程中产生的日志信息进行分析处理，将业务端到端的执行完整的调用过程进行还原，根据不同维度进行统计分析；从而标识出有异常的服务调用，能够快速分析定界到出异常的服务；同时可根据数据统计分析系统性能瓶颈.Dapper,a1.arge-ScaleDistributedSystemsTracingInfrastructure描述了其中的原理和一般性的机制.模型中包含的术语也很多，理解最主要的两个即可：Trace:一次完整的分布式调用跟踪链路.Span:跨服务的一次调用；多个Span组合成一次Trace追踪记录.下面通过一次用户服务请求来完成调用链过程模拟：左图为一个和5台服务器相关的一个服务，包括：前端（八）,两个中间层（B和C）,以及两个后端（D和E）。当一个用户（这个用例的发起人）发起一个请求时，首先到达前端，然后发送两个RPC到服务器B和C.B会马上做出反应,但是C需要和后锥的D和E交互之后再返还给A,由A来响应最初的请求.右表示对应Span的管理关系.每个节点是一个Span,表示一个调用.至少包含Span的名、父SpanId和SPanId.节点间的连线下表示Span和父Span的关系.所有的Span属于一个跟踪，共用一个TraceId.从图上可以看到对前端A的调用Span的两个子Span分别是对B和C调用的Span,D和E两个后端服务调用的Span则都是C的子Span.跟踪系统根据用户请求每次生成的全局唯一的ID(TraceId),TraceId在SPan间传递,将不同服务的“孤立的“日志串在一起，束组还原出更多有价值的信息.如今调用链系统有很多实现，用的比较多的如Zipkin,还有已经加入CNCF基金会并且用的越来越多的Jaeger.调用链模型格式为了能将一系列埋点率接成一个完整的调用缝，并区分不同请求的调用使日志信息，同时信息中标要包含请求状态与时长，对于不同业务应用可能需要有特殊的信息记录到日志中；所以调用腌日志信息(SPan)应包含如下内容：名B含义longNu明的ID.。如一e«.-个k>1198个long的16遇Im；M2bMX¼d99f179cnm*Stnng三HJWOS9三Mtt(AS0«.iaWWJ*»()R«UR1.息域Ol明lA的名aDnfi90ea.缸as的sc9nnout*l0c9，阳的父2e«.«.<?.SpinttOCXiMTMOmtwntum>l0n9¥归发集的才他当祭如筋州（位叫.0«.用HgIa时间的OU1.TtpnftH>*kn11ot>ocMi1.tdocfVACSa.s>vcNe-StrSgM目区一努名rlpont交SF映目标的IPP(XtStnn9WmIMWn。v>uSgg方兀HIUICS.SR.$.CRbtnrAnnot9Stnn9Mngc*y可IRma熊.施议“搐口筑行失W0Tff(RruHCodrwtcvk>Stnn9用M优的”8rvdpot»«rv»c«N*mStrFM口Ke狗名on-信息以便方便的这0向B1.ndpc«M，问防!BStnn9auu11M9pp<XtSK神目MWn一次业务请求调用链模型：对于Trace而言,最基础的能力是能够记录请求在多个服务之间调用的传播、依赖关系并进行可视化.而从Trace本身的数据特点而言,它是规则化、标准化且带有依赖关系的访问日志，因此可以基于Trace去计第并挖掘更多的价值。下面是S1.SOpenTeIemetryTrace的实现架构，核心是通过数据编排计算TraCe原始数据并得到聚合数据,并基于S1.S提供的接口实现各类Trace的附加功能.例如：1 .依赖关系：这是绝大部分的Trace系统都会附带的功能，基于Trace中的父子关系进行聚合计凭,得到TraceDependency2 .服务/接口黄金指标：Trace中记录了服务/接口的调用延迟、状态码等信息,基于这些数据可以计算出QPS、延迟、错误率等黄金指标.3 .上下游分析：基于计算的DePendenCy信息，按照某个SerViCe进行聚合，统-Service依赖的上下游的指标4.中间件分析：TraCe中对于中间件（数据库/MQ等）的调用一般都会记录成一个个Span,基于这些SPan的统计可以得到中间件的QPS、延迟、错i吴率.告警相关：通常基于服务/接口的黄金指标设置监控和告警，也可以只关心整体服务入口的告警（一般对父Span为空的Span认为是服务人口调用）Metrics:通常都是range查询，每次叠询某一个单一的指标/时间线，或者一组时间线进行聚合，例如统一某个应用所有机器的平均CPU时序类的查询一段QPS都较高（主要有很多告警规则），为了适应高QPS直询，需要把数据的聚合性做好对于这类数据都会有专门的时序引擎来支控，目前主流的时序引擎基本上都是用类似于1.SMTree的思想来实现，以适应高吞吐的写入和直询（Update.Delete操作很少）同时可观测性数据还有一些共性的特点，例如高吞吐写入（高流量、QPS,而且会有Burst）、超大规模查询特点、时间访问特性（冷热特性、访问局部性等）.业务调用琏路监控Skywalking是一款比蛟优秀的开源的应用性能监控工具，支持对分布式系统的监控、跟踪和诊断.它提供了如下的主要功能特性：ServiceTopology监控调用腌路监控可以从两个角度去看待.通过给服务添加探针并产生实际的调用之后，我们可以通过Skywalking的前端UI有看服务之间的调用关系。我们简单模拟一次服务之间的调用.新建两个服务，service-provider以及service-consumer,服务之间简单的通过FeignClient来模拟远程调用。I92.IM1612$1761从图中可以看到:有两个服务节点：provider&consumer有一个数据库节点:localhostmysql一个注册中心节点consumer消费了PrOVider提供出来的接口.一个系统的拓扑图让我们清晰的认识到系统之间的应用的依赖关系以及当前状态下的业务流转流程.细心的可能发现图示节点consumer上有一部分是红色的，红色是什么意思呢？红色代表当前流经consumer节点的请求有一段时间内是响应异常的.当节点全部变红的时候证明服务现阶段内就彻底不可用了。运维人员可以通过Topology迅速发现某一个服务潜在的问题，并进行下一步的排面并做到预防.SkywalkingTrace监控Skywalking通过业务调用监控进行依赖分析，提供给我们服务之间的服务调用拓扑关系、以及针对每个endpoint的trace记录，我们在之前看到consumer节点服务中发生了错误，让我们一起来定位下错误是发生在了什么地方又是什么原因呢？我OMt入海的ServiceSIQkonsumeriSRttAII（我们看下所口求的状35）WAEndpointhUmF:gHSl<x（这IkomUmerM外集的徭口身）KttCiE*在每一条trace的信息中都可以看到当前请求的时间、GIoabIeId,以及请求被调用的时间.我们分别看一着正确的调用和异常的调用.TraCe调用犍路监控SUrtTimeHHHEHK1ToutDUrM8OBSpan*O图示展示的是一次正常的响应，这条响应总耗时19ms,它有4个span:spanl/getStore=19ms响应的总流转时间span2demo2stores=14msfeignclient开始调用远程服务后的响应的总时间span3/stores=14ms接口服务响应总时间span4Mysql=Ims服务提供端查询数据库的时间这里spa2和span3的时间表现相同，其实是不同的，因为这里时间取了整。在每个Span中可以查看当前Span的相关属性。组件类型：SpringMVC.FeignSpan状态：falseHttpMethod:GETUrl:http:/192.168.16.125:10002/demo2/storesTags1.09sWrtp.VlW1612SIa)OIAJem01/9HSWreGeTTagslogsC11M×<lfF«>QAMtpmctfvdie2.l8l6.US10002urt:27/192.181ITS10002jX¼oo2otm这是一次正常的请求调用Trace日志，可能我们并不关心正常的时候，毕竟一切正常不就是我们期待的么！我们再来看下，异常状态下我们的Trace以及Span又是什么样的呢.发生错误的调用雄中Span中的iserror标识变为true并且在名为1.ogs的TAB中可以看到错误发生的具体原因,根据异常情况我们就可以轻松定位到影响业务的具体原因，从而快速定位问题，解决问题.通过1.og我们看到连接被拒，那么可能是我们的网络出现了问题（可能性小，因为实际情况如果网络出现问题我们连这个trace都看不到了）,也有可能是服务端配戳问题无法正确建立连接.通过异常日志，我们迅速就找到了问SS的关键.服务性能监控服务性能可以实现以下关键指标：1、关键业务指标：响应时间、Apex、吞吐率、错误率2、事务：耗时百分比、响应时间、吞吐量、APdeX、错误率、调用次数3、数据库：SQ1.耗时、平均响应时间、吞吐率、SQ1.语句执行计划、代码堆栈4、NoSQ1.:MemCaChed/Redi$/MOgOODB的操作总耗时、平均响应时间、吞吐率5、外部应用：HTTP/Thrif/Dubbo/WebService的响应时间占比、平均响应时间、响应总时间、吞吐率、错误率6.MQ:RabbitMQ/JMS/ActiveMQ生产者、消费者的消息总数、每分钟消息数、平均消息发送时间、总流量7、JVM:内存使用量、线程、HTTP会话