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

《云原生全栈监控解决方案（全面详解）.docx》由会员分享，可在线阅读，更多相关《云原生全栈监控解决方案（全面详解）.docx（19页珍藏版）》请在优知文库上搜索。

1、前言当前全球企业云化、数字化进程持续加速，容、徵服务等云原生技术在软件架构中快速渗透，IT架构云化、匆朵化持续骤动性能监控市场，企业云化、数字化持续转型，以及为了考虑系统的邦性、效率，企业软件开发中大量云底生技术的应用推动全球IT监控市场快速变化，如何全面、有效的对容器、K8s、微服务进行监控是当N云原生技术面临的Ift要课次.背景和挑战云化产品通常采用服务化框架，由一系列微服务组成，目微服务是可以独立运行的进程，不同服务可使用不同开发语言，可能分布部署在几千台服务器上，甚至可能横跨多个不同的数据中心，服务间使用轻量的通信机制；服务之间存在复杂的调用关系，对运维人员理解系统的行为或分析系统性能

2、带来巨大挑战如：(1)容器是否正常运行(2)K8S是否正常运行.(3)微服务是正常(5)业务调用出现问题，如何快速找出哪个服务发生失败？(6)某个业务调用耗时较长，如何快速找到性能瓶颈点？7)如何快速获取某次调用的业务H志进行分析定位？解决方案概述云原生监控体系包括:Healthchecks.Metrics.1.oggingTracing.Healthchecks:健康检宣可以定期检直某个应用的存活状态；Metrics:度量指标监控，在离散的时间点上产生数值点；1.ogging:日志监控；Tracing:调用链监控。各种监控工具适用场景如下图所示：适用场合健康检笠微服务架构，为了保证所有服务可

3、用，当服务发生问题时能及时摘除有问题的服务需要定期检测服务可用性，即健康检直.通常健臣健康检直包括TCP与HTTP两种.即定时发送TCP或HTTP请求，根据响应来确定服务是否可用.一般通过TCP定期请求来判定网络层是否正常,而通过Http请求判断应用层是否正常.服务要配置好请求接口，检测服务定期向指定的接口发送http请求,并根据接口响应码和响应时间判断.Springboot的endport/health可以检直应用的健康状态，举例说，当我们访问http:/localhost:8088/health时，可以看到HeaIthEndPoint给我们提供默认的监控结果，包含磁盘检测和数据库检测。Ps

4、tatus:UPfdiskspace: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接口则允

5、许外部访问服务随时主动从CAdvisor获取到当时时刻的性能数据，然后自行处理，Prometheus与CAdvisor的对接用的是这种方法.基于容器的微服务监控和原始的监控是有很大区别的，因为服务的实例生存周期很短分分钟可能就会有容器的生灭.微服务的容器与宿主机的监控商不开CPU、内存、磁盘、网卡这些基础的性能指标，对于宿主机的监控来说，我们可以依然使用原始的监控方式，每个宿主机安装一个代理来采集服务器的性能指标，代理在采集性能指标的时候可以打上时间觑和相应的标签来区分不同性能指标的数据维度（metric）,然后将监控数据汇总到时间序列数据库，里面的数据可以对接目前一些开源的组件来进行可视化的

6、展示，也可以对接报警服务（结合报警服务的报警策略）进行报警.容器的监控自然就和宿主机不太一样了，我们不能说给每个容器镜像内部都集成一个监控代理（agent）,这样的话侵入性太强，不易于维护.Prometheus有很多的Exporter可以用来采集监控数据，例如我们想采集KUberneteS上所有容器（pod）的性能指标的话，Promethus可以通过直接配百多个KubernetesApiServer的Endpoints来监控整个Kubernetes集群.K8S监控K8S集群层面选择使用Prometheus.集群层面的监控又分为Node,K8S基础组件、K8S资源对象三大类。I、对于Node的监

7、控，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项目，极大简化了Prom

8、etheus的安装部署运维工作.基于KUberneteS实现的微服务应用级的监控插件，如下图：fSwkafka-Iogstash-elasticsearchkibana的方式,亘接在应用程序中将日志信息推送到采集后端.调用链监控调用缝定义：在系统完成一次业务调用的过程中，把服务之间的调用信息（时间、接口、层次、结果）打点到日志中，然后将所有的打点数据连接为一个树状链条就产生了一个调用链.跟踪系统把过程中产生的日志信息进行分析处理，将业务端到端的执行完整的调用过程进行还原，根据不同维度进行统计分析；从而标识出有异常的服务调用，能够快速分析定界到出异常的服务；同时可根据数据统计分析系统性能瓶颈.D

9、apper,a1.arge-ScaleDistributedSystemsTracingInfrastructure描述了其中的原理和一般性的机制.模型中包含的术语也很多，理解最主要的两个即可：Trace:一次完整的分布式调用跟踪链路.Span:跨服务的一次调用；多个Span组合成一次Trace追踪记录.下面通过一次用户服务请求来完成调用链过程模拟：左图为一个和5台服务器相关的一个服务，包括：前端（八）,两个中间层（B和C）,以及两个后端（D和E）。当一个用户（这个用例的发起人）发起一个请求时，首先到达前端，然后发送两个RPC到服务器B和C.B会马上做出反应,但是C需要和后锥的D和E交互之后再

10、返还给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,

11、还有已经加入CNCF基金会并且用的越来越多的Jaeger.调用链模型格式为了能将一系列埋点率接成一个完整的调用缝，并区分不同请求的调用使日志信息，同时信息中标要包含请求状态与时长，对于不同业务应用可能需要有特殊的信息记录到日志中；所以调用腌日志信息(SPan)应包含如下内容：名B含义longNu明的ID.。如一e.-个k1198个long的16遇Im；M2bMXd99f179cnm*Stnng三HJWOS9三Mtt(AS0.iaWWJ*()RUR1.息域Ol明lA的名aDnfi90ea.缸as的sc9nnout*l0c9，阳的父2e.l0n9归发集的才他当祭如筋州（位叫.0.用HgIa时间的OU1.TtpnftH*kn11otocMi1.tdocfVACSa.svcNe-StrSgM目区一努名rlpont交SF映目标的IPP(XtStnn9WmIMWn。vuSgg方兀HIUICS.SR.$.CRbtnrAnnot9Stnn9Mngc*y可IRma熊.施议“搐口筑行失W0Tff(RruHCodrwtcvkSt