详解云原生全栈监控.docx

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

1、响应码和响应时间判断。Springboot的endport/health可以检查应用的健原状态，举例说，当我们访问http:/localhost:8088/health时,可以看到HeaIthEndPoint给我们提供默认的监控结果，包含跟盘检测和数据库检测。(status:,Pdiskspace:bstatus:Prtotal:398458875904,free:315106918400,threshold:10485760,db:status:,P-database*:,MySQ1.,hello:1)容器监控容器监控使用Prometheus-CAdvisor,CAdvisor是谷歌专为监控

2、容器性能状态设计的一个开源工具,CAdvisor提供有Push和Pull两种获取性能数据的接口.Push接口指的是由CAdvisor主动将数据周期性的推送到远端的存储服务中，Influxdb与CAdvisor的对接就是通过这个接口完成的.而Pull接口则允许外部访问服务随时主动从CAdvisor获取到当时时刻的性能数据，然后自行处理,PrOrnetheUS与CAdViSor的对接用的是这种方法.基于容器的微服务监控和原始的监控是有很大区别的，因为服务的实例生存周期很短分分钟可能就会有容器的生灭。微服务的容器与宿主机的监控离不开CPU、内存、磁盘、网卡这些基础的性能指标，对于宿主机的监控来说，我

3、们可以依然使用原始的监控方式，每个宿主机安装一个代理来采集服务器的性能指标，代理在采集性能指标的时候可以打上时间做和相应的标签来区分不同性能指标的数据维度（metric）,然后将监控数据汇总到时间序列数据库，里面的数据可以对接目前一些开源的组件来进行可视化的展示，也可以对接报警服务（结合报警服务的报警策略）进行报警。容器的监控自然就和宿主机不太一样了,我们不能说给每个容器镜像内部都集成一个监控代理（agent）,这样的话侵入性太强，不易于维护.Prometheus有很多的EXPorter可以用来采集监控数据，例如我们想采集KUberneteS上所有容器（pod）的性能指标的话，Promethu

4、s可以通过直接配置多个KubernetesApiServer的Endpoints来监控整个Kubernetes集群.K8S监控K8S集群层面选择使用Prometheus.集群层面的监控又分为Node、K8S基础组件、K8S资源对蕊三大类.1 .对于Node的监控,Prometheus提供了node-exporter,可采集到CPU、内存、磁盘10、磁盘使用率、网络包量、带宽等数据；2、K8S基拙组件类的kubelet、kube-apiserver、kube-ContrOHer-manager和kube-scheduler等，都提供了metrics接口品露自身的运行时的监控数据，这些数据都可被部

5、署在K8S集群中的Prometheus亘接拉取到；3、结合Cadvisor和kube-state-metrics,可直接采集到K8S中Pod的CPU、内存、磁盘】0、网络10等数据.由CoreOS开源的KUbe-Prometheus项目，极大简化了Prometheus的安装部署运维工作。基于KUbemeteS实现的微服务应用级的监控插件，如下图：http在Kubernetes的master节点，也就是安装apiserver的那台服务器上运行一个监控插件,该插件可以通过一个kubernetes提供的官方客户端来访问apiserver,首先我们要告知插件要监控哪个namespace下的哪个serv

6、ice,然后，插件通过和apiserver进行交互获取某个service下所有Pods的实例，插件会并发访问所有pod提供的/metrics接口（Path可配），并给每个pod的返回数据（json格式，遵守一定的数据格式契约）打上pod_name的标签来标识每个pod返回的metrics,打上pod_name标签的同时也会打上SerViCe_name的标签用来区分具体是哪个service的监控数据.KUberneteS主要提供了如下5种服务发现模式和PrometheUS进行集成:Node、PodxEndpointsxService.Ingress.监控K8S将使用Prometheusfeder

7、ation的形式，k8s集群外部的PrometheUS从k8s集群中PrometheUS拉取监控数据，外部的Prometheus才是监控数据的存储.k8s集群中部署Prometheus的数据存储层可以简单的使用emptyDir,数据只保留24小时（或更短时间）即可，部署在k8s集群上的这个Prometheus实例即使发生故障也可以放心的让它在集群节点中濠移.1）创建namespace取名ns-monitor2 ）在k8s中部署node-exporterNode-exporter用于采集kubernetes集群中各个节点的物理指标，比如：Memory.CPU等.可以直接在每个物理节点直接安装，这

8、里我们使用DaemonSet部署到每个节点上，使用hostNetwork:true和hostPID:true使其获得Node的物理指标信息，配普t。IeratiOnS使其在master节点也启动一个pod.#创建node-eXPorter.yml文件3-1）创建编辑rabc.ymlrbac.yml定义了Prometheus容器访问k8sapiserver所需的ServiceAccount和CIusterRoIe及CIusterRoIeBinding3-2）创建编辑configmap.ym进行Configm叩中的prometheus的配置文件3-3）PrometheUS-deploy.yml定义

9、Prometheus的部署3-4）PrOmetheUS-SVC.yml定义Prometheus的Service需要将Prometheus以NodePort,1.oadBaIancer或使用Ingress爆露到集群外部，这样外部的Prometheus才能访问它.3-5）使用yml文件创建对象kubectlcreate-frbac.ymkubectlcreate-fcofigmap.ymkubectlcreate-fprometheus-deploy.ymlkubectlcreate-fprometheus-svc.yml4）配者配置PrometheusFederation完成Kubernetes

10、集群上的Prometheus的部署之后，下面将配替集群外部的PrOmetheUS使其从集群内部的PrometheUS拉取数据。实际上只需以静态配SS的形式添加一个job就可以.5）配置pushgateway日志监控Fluentd是一个通用的信息收集、整理、祷发的流式数据处理工具.默认情况下Docker会将所有容器输出到系统控制台的内容圭定向到以容器ID命名的一个本地目录中，只需要定期采集所有这些目录的内容就能一字不混的将容器的输出捕获出来，这种方式的侵入性很小，但由于是周期性的收集，日志在汇聚端（例如Kibana）的展示会有一定的延时，延时长度与日志收集的周期相关。相反的，如果使用Docker

11、的日志驱动（启动docker后台服务时指定参数-log-driver=fluentd）将获得实时性很好的汇聚端日志展示，但由于日志直接发送到了远端的Fluentd服务，会使得在本地主机上的dockerlogs命令失效.两种方式的共性在于：不论通过哪一种方式,收集到的日志都能终以容器名称、镜像、标签等对容器使用十分友好的维度进行检索。Kubernetes集群本身不提供日志收集的解决方案，我们采用fluentd-kafka-Iogstash-elasticsearch-kibana的方式,亘接在应用程序中将日志信息推送到采集后端.调用链监控调用睫定义：在系统完成一次业务调用的过程中，把服务之间的调

12、用信息（时间、接口、层次、结果）打点到日志中，然后将所有的打点数据连接为一个树状链条就产生了一个调用链.跟踪系统把过程中产生的日志信息进行分析处理，将业务端到端的执行完整的调用过程进行还原，根据不同维度进行统计分析；从而标识出有异常的服务调用，能够快速分析定界到出异常的服务；同时可根据数据统计分析系统性能瓶颈.Dapper,a1.arge-ScaleDistributedSystemsTracingInfrastructure描述了其中的原理和一般性的机制.模型中包含的术语也很多，理解最主要的两个即可：Trace:一次完整的分布式调用跟踪链路.Span:跨服务的一次调用；多个Span组合成一次

13、Trace追踪记录.下面通过一次用户服务请求来完成调用链过程模拟：左图为一个和5台服务器相关的一个服务，包括：前端（八）,两个中间层（B和C）,以及两个后端（D和E）.当一个用户（这个用例的发起人）发起一个请求时，苜先到达前端，然后发送两个RPC到服务器B和C,B会马上做出反应，但是C需要和后端的D和E交互之后再返还给A,由A来响应最初的请求.右表示对应Span的管理关系.每个节点是一个Span,表示一个调用。至少包含Span的名、父SpanId和SPanld.节点间的连线下表示Span和父Span的关系。所有的Span属于一个跟踪，共用一个TraCekt从图上可以看到对前端A的调用Span的

14、两个子Span分别是对B和C调用的Span,D和E两个后端服务调用的Span则都是C的子Span.跟踪系统根据用户谙求每次生成的全局唯一的ID(TraceId),TraceId在SPan间传递，将不同服务的“孤立的“日志串在一起，函组还原出更多有价值的信息.如今调用链系统有很多实现，用的比较多的如zipkin,还有已经加入CNCF基金会并且用的越来越多的Jaeger.蠲用链模型格式为了能将一系列埋点串接成一个完整的调用他，并区分不同请求的调用他日志信息，同时信息中需要包含请求状态与时长，对于不同业务应用可能需要有特殊的信息记录到日志中；所以调用道日志信息(SPan)应包含如下内容：含义.trx

15、dlong，用事由ID.必发全J29个k53个k119的16调折冲；M2bMX99p*nD1.ongspan的ID-0.Fl钻的FIOr9pc的父2ea.纪点SXCtAo或无造字I。annoution4tmUmplf9单件及生的本地当*0.atmtM0Hf)me1.Wn支持多个nnoUtonfvcNmString滨州IJXe务名Stnn9用H标明IP3flCntWtMCS.CR,SrvPoftSInng网。网94口vuSVaW5(HIUC$.SR.SS.CRbryAnrotFStnng用MU晒Sy三ja.mmae.R议&幡口执行实或时JS依rwKCodr*sultD*cvuString用鹤息的3M吟CqsfvcNmSVmgJUHHe好名ton信也以便方便的定2阿B1.ndpont为可4an”映目网9POrtStnn9WiQM911