上海建设工程 U盘登录哪个网站,抚州网络推广,中企动力企业邮箱手机登录,可视化编辑 wordpress【作者】JasonXu 前言
当前全球企业云化、数字化进程持续加速#xff0c;容器、微服务等云原生技术在软件架构中快速渗透#xff0c;IT 架构云化、复杂化持续驱动性能监控市场。企业云化、数字化持续转型#xff0c;以及为了考虑系统的弹性、效率#xff0c;企业软件开发中…【作者】JasonXu 前言
当前全球企业云化、数字化进程持续加速容器、微服务等云原生技术在软件架构中快速渗透IT 架构云化、复杂化持续驱动性能监控市场。企业云化、数字化持续转型以及为了考虑系统的弹性、效率企业软件开发中大量云原生技术的应用推动全球 IT 监控市场快速变化如何全面、有效的对容器、K8s、微服务进行监控是当下云原生技术面临的重要课题。 背景和挑战
云化产品通常采用服务化框架由一系列微服务组成且微服务是可以独立运行的进程不同服务可使用不同开发语言可能分布部署在几千台服务器上甚至可能横跨多个不同的数据中心服务间使用轻量的通信机制服务之间存在复杂的调用关系对运维人员理解系统的行为或分析系统性能带来巨大挑战 如
1容器是否正常运行
2K8S是否正常运行。
3微服务是正常
5业务调用出现问题如何快速找出哪个服务发生失败
6某个业务调用耗时较长如何快速找到性能瓶颈点
7如何快速获取某次调用的业务日志进行分析定位 解决方案
概述
云原生监控体系包括Healthchecks、Metrics、Logging、Tracing。Healthchecks健康检查可以定期检查某个应用的存活状态Metrics度量指标监控在离散的时间点上产生数值点Logging日志监控Tracing调用链监控。
各种监控工具适用场景如下图所示 健康检查
微服务架构为了保证所有服务可用当服务发生问题时能及时摘除有问题的服务需要定期检测服务可用性即健康检查。通常健康健康检查包括TCP与HTTP两种。即定时发送TCP或HTTP请求根据响应来确定服务是否可用。一般通过TCP定期请求来判定网络层是否正常而通过Http请求判断应用层是否正常。服务要配置好请求接口检测服务定期向指定的接口发送http请求并根据接口响应码和响应时间判断。Spring boot的end port /health可以检查应用的健康状态举例说当我们访问 http://localhost:8088/health 时可以看到 HealthEndPoint 给我们提供默认的监控结果包含磁盘检测和数据库检测。
{
status: UP,
diskSpace: {
status: UP,
total: 398458875904,
free: 315106918400,
threshold: 10485760
},
db: {
status: UP,
database: MySQL,
hello: 1
}
}
容器监控
容器监控使用Prometheus-cAdvisorcAdvisor是谷歌专为监控容器性能状态设计的一个开源工具cAdvisor提供有Push和Pull两种获取性能数据的接口。Push接口指的是由cAdvisor主动将数据周期性的推送到远端的存储服务中Influxdb与cAdvisor的对接就是通过这个接口完成的。而Pull接口则允许外部访问服务随时主动从cAdvisor获取到当时时刻的性能数据然后自行处理Prometheus与cAdvisor的对接用的是这种方法。
基于容器的微服务监控和原始的监控是有很大区别的因为服务的实例生存周期很短分分钟可能就会有容器的生灭。微服务的容器与宿主机的监控离不开CPU、内存、磁盘、网卡这些基础的性能指标对于宿主机的监控来说我们可以依然使用原始的监控方式每个宿主机安装一个代理来采集服务器的性能指标代理在采集性能指标的时候可以打上时间戳和相应的标签来区分不同性能指标的数据维度metric然后将监控数据汇总到时间序列数据库里面的数据可以对接目前一些开源的组件来进行可视化的展示也可以对接报警服务结合报警服务的报警策略进行报警。
容器的监控自然就和宿主机不太一样了我们不能说给每个容器镜像内部都集成一个监控代理agent,这样的话侵入性太强不易于维护。Prometheus有很多的Exporter可以用来采集监控数据例如我们想采集Kubernetes上所有容器pod的性能指标的话Promethus可以通过直接配置多个Kubernetes ApiServer的Endpoints来监控整个Kubernetes集群。
K8S监控
K8S集群层面选择使用Prometheus。集群层面的监控又分为Node、K8S基础组件、K8S资源对象三大类。
1、对于Node的监控Prometheus提供了node-exporter可采集到CPU、内存、磁盘IO、磁盘使用率、网络包量、带宽等数据
2、K8S基础组件类的kubelet、kube-apiserver、kube-controller-manager 和 kube-scheduler等都提供了 metrics接口暴露自身的运行时的监控数据这些数据都可被部署在K8S集群中的Prometheus 直接拉取到
3、结合cadvisor 和kube-state-metrics 可直接采集到K8S中Pod的 CPU、内存、磁盘 IO、网络 IO 等数据。由CoreOS开源的Kube-Prometheus项目极大简化了Prometheus的安装部署运维工作。
基于Kubernetes实现的微服务应用级的监控插件如下图 在Kubernetes的master节点也就是安装apiserver的那台服务器上运行一个监控插件该插件可以通过一个kubernetes提供的官方客户端来访问apiserver,首先我们要告知插件要监控哪个namespace下的哪个service然后插件通过和apiserver进行交互获取某个service下所有Pods的实例插件会并发访问所有pod提供的/metrics接口Path可配,并给每个pod的返回数据json格式遵守一定的数据格式契约打上pod_name的标签来标识每个pod返回的metrics打上pod_name标签的同时也会打上service_name的标签用来区分具体是哪个service的监控数据。
Kubernetes主要提供了如下5种服务发现模式和Prometheus进行集成Node、Pod、Endpoints、Service、Ingress。监控K8S将使用Prometheus federation的形式k8s集群外部的Prometheus从k8s集群中Prometheus拉取监控数据外部的Prometheus才是监控数据的存储。k8s集群中部署Prometheus的数据存储层可以简单的使用emptyDir数据只保留24小时(或更短时间)即可部署在k8s集群上的这个Prometheus实例即使发生故障也可以放心的让它在集群节点中漂移。
1创建namespace取名ns-monitor
2在k8s中部署node-exporter
Node-exporter用于采集kubernetes集群中各个节点的物理指标比如Memory、CPU等。可以直接在每个物理节点直接安装这里我们使用DaemonSet部署到每个节点上使用 hostNetwork: true 和 hostPID: true 使其获得Node的物理指标信息配置tolerations使其在master节点也启动一个pod。
#创建node-exporter.yml文件
3-1创建编辑rabc.yml
rbac.yml定义了Prometheus容器访问k8s apiserver所需的ServiceAccount和ClusterRole及ClusterRoleBinding
3-2创建编辑configmap.yml 进行configmap中的prometheus的配置文件
3-3prometheus-deploy.yml定义Prometheus的部署
3-4prometheus-svc.yml定义Prometheus的Service
需要将Prometheus以NodePort, LoadBalancer或使用Ingress暴露到集群外部这样外部的Prometheus才能访问它 。
3-5使用yml文件创建对象 kubectl create -f rbac.yml kubectl create -f configmap.yml kubectl create -f prometheus-deploy.yml kubectl create -f prometheus-svc.yml
4配置配置Prometheus Federation
完成Kubernetes集群上的Prometheus的部署之后下面将配置集群外部的Prometheus使其从集群内部的Prometheus拉取数据。实际上只需以静态配置的形式添加一个job就可以。
5配置pushgateway
日志监控
Fluentd是一个通用的信息收集、整理、转发的流式数据处理工具。默认情况下Docker会将所有容器输出到系统控制台的内容重定向到以容器ID命名的一个本地目录中只需要定期采集所有这些目录的内容就能一字不漏的将容器的输出捕获出来这种方式的侵入性很小但由于是周期性的收集日志在汇聚端例如Kibana的展示会有一定的延时延时长度与日志收集的周期相关。相反的如果使用Docker的日志驱动启动docker后台服务时指定参数–log-driverfluentd将获得实时性很好的汇聚端日志展示但由于日志直接发送到了远端的Fluentd服务会使得在本地主机上的docker logs命令失效。
两种方式的共性在于不论通过哪一种方式收集到的日志都能够以容器名称、镜像、标签等对容器使用十分友好的维度进行检索。Kubernetes 集群本身不提供日志收集的解决方案我们采用fluentd--kafka--logstash--elasticsearch--kibana的方式直接在应用程序中将日志信息推送到采集后端。
调用链监控
调用链定义在系统完成一次业务调用的过程中把服务之间的调用信息(时间、接口、层次、结果)打点到日志中然后将所有的打点数据连接为一个树状链条就产生了一个调用链。跟踪系统把过程中产生的日志信息进行分析处理将业务端到端的执行完整的调用过程进行还原根据不同维度进行统计分析从而标识出有异常的服务调用能够快速分析定界到出异常的服务同时可根据数据统计分析系统性能瓶颈。
Dapper, a Large-Scale Distributed Systems Tracing Infrastructure 描述了其中的原理和一般性的机制。模型中包含的术语也很多理解最主要的两个即可 Trace一次完整的分布式调用跟踪链路。 Span跨服务的一次调用多个 Span 组合成一次 Trace 追踪记录。
下面通过一次用户服务请求来完成调用链过程模拟 左图为一个和5台服务器相关的一个服务包括前端A两个中间层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 调用的 SpanD 和 E 两个后端服务调用的 Span 则都是 C 的子 Span。跟踪系统根据用户请求每次生成的全局唯一的IDTraceIdTraceId 在span间传递将不同服务的“孤立的”日志串在一起重组还原出更多有价值的信息。如今调用链系统有很多实现用的比较多的如 zipkin 还有已经加入 CNCF 基金会并且用的越来越多的 Jaeger。
调用链模型格式
为了能将一系列埋点串接成一个完整的调用链并区分不同请求的调用链日志信息同时信息中需要包含请求状态与时长对于不同业务应用可能需要有特殊的信息记录到日志中所以调用链日志信息(Span)应包含如下内容 一次业务请求调用链模型 对于Trace而言最基础的能力是能够记录请求在多个服务之间调用的传播、依赖关系并进行可视化。而从Trace本身的数据特点而言它是规则化、标准化且带有依赖关系的访问日志因此可以基于Trace去计算并挖掘更多的价值。下面是SLS OpenTelemetry Trace的实现架构核心是通过数据编排计算Trace原始数据并得到聚合数据并基于SLS提供的接口实现各类Trace的附加功能。例如
1.依赖关系这是绝大部分的Trace系统都会附带的功能基于Trace中的父子关系进行聚合计算得到Trace Dependency
2.服务/接口黄金指标Trace中记录了服务/接口的调用延迟、状态码等信息基于这些数据可以计算出QPS、延迟、错误率等黄金指标。
3.上下游分析基于计算的Dependency信息按照某个Service进行聚合统一Service依赖的上下游的指标
4.中间件分析Trace中对于中间件数据库/MQ等的调用一般都会记录成一个个Span基于这些Span的统计可以得到中间件的QPS、延迟、错误率。
告警相关通常基于服务/接口的黄金指标设置监控和告警也可以只关心整体服务入口的告警一般对父Span为空的Span认为是服务入口调用。
Metrics 通常都是range查询每次查询某一个单一的指标/时间线或者一组时间线进行聚合例如统一某个应用所有机器的平均CPU 时序类的查询一般QPS都较高主要有很多告警规则为了适应高QPS查询需要把数据的聚合性做好 对于这类数据都会有专门的时序引擎来支撑目前主流的时序引擎基本上都是用类似于LSM Tree的思想来实现以适应高吞吐的写入和查询Update、Delete操作很少 同时可观测性数据还有一些共性的特点例如高吞吐写入高流量、QPS而且会有Burst、超大规模查询特点、时间访问特性冷热特性、访问局部性等。
业务调用链路监控
Skywalking是一款比较优秀的开源的应用性能监控工具支持对分布式系统的监控、跟踪和诊断。它提供了如下的主要功能特性 Service Topology监控
调用链路监控可以从两个角度去看待。通过给服务添加探针并产生实际的调用之后我们可以通过Skywalking的前端UI查看服务之间的调用关系。我们简单模拟一次服务之间的调用。新建两个服务service-provider以及service-consumer服务之间简单的通过Feign Client 来模拟远程调用。 从图中可以看到: 有两个服务节点provider consumer 有一个数据库节点localhost【mysql】 一个注册中心节点
consumer消费了provider提供出来的接口。
一个系统的拓扑图让我们清晰的认识到系统之间的应用的依赖关系以及当前状态下的业务流转流程。细心的可能发现图示节点consumer上有一部分是红色的红色是什么意思呢
红色代表当前流经consumer节点的请求有一段时间内是响应异常的。当节点全部变红的时候证明服务现阶段内就彻底不可用了。运维人员可以通过Topology迅速发现某一个服务潜在的问题并进行下一步的排查并做到预防。
Skywalking Trace监控
Skywalking通过业务调用监控进行依赖分析提供给我们服务之间的服务调用拓扑关系、以及针对每个endpoint的trace记录。
我们在之前看到consumer节点服务中发生了错误让我们一起来定位下错误是发生在了什么地方又是什么原因呢 在每一条trace的信息中都可以看到当前请求的时间、GloableId、以及请求被调用的时间。我们分别看一看正确的调用和异常的调用。
Trace调用链路监控 图示展示的是一次正常的响应这条响应总耗时19ms它有4个span span1 /getStore 19ms 响应的总流转时间 span2 /demo2/stores 14ms feign client 开始调用远程服务后的响应的总时间 span3 /stores 14ms 接口服务响应总时间 span4 Mysql 1ms 服务提供端查询数据库的时间
这里span2和span3的时间表现相同其实是不同的因为这里时间取了整。
在每个Span中可以查看当前Span的相关属性。 组件类型: SpringMVC、Feign Span状态: false HttpMethod: GET Url:
http://192.168.16.125:10002/demo2/stores 这是一次正常的请求调用Trace日志可能我们并不关心正常的时候毕竟一切正常不就是我们期待的么我们再来看下异常状态下我们的Trace以及Span又是什么样的呢。 发生错误的调用链中Span中的is error标识变为true并且在名为Logs的TAB中可以看到错误发生的具体原因。根据异常情况我们就可以轻松定位到影响业务的具体原因从而快速定位问题解决问题。通过Log我们看到连接被拒那么可能是我们的网络出现了问题可能性小因为实际情况如果网络出现问题我们连这个trace都看不到了也有可能是服务端配置问题无法正确建立连接。通过异常日志我们迅速就找到了问题的关键。
服务性能监控
服务性能可以实现以下关键指标
1、关键业务指标响应时间、Apex、吞吐率、错误率
2、事务耗时百分比、响应时间、吞吐量、Apdex、错误率、调用次数
3、数据库SQL耗时、平均响应时间、吞吐率、SQL语句执行计划、代码堆栈
4、NoSQLMemcached/Redis/MogooDB的操作总耗时、平均响应时间、吞吐率
5、外部应用HTTP/Thrif/Dubbo/Web Service的响应时间占比、平均响应时间、响应总时间、吞吐率、错误率
6、MQRabbitMQ/JMS/ActiveMQ生产者、消费者的消息总数、每分钟消息数、平均消息发送时间、总流量
7、JVM内存使用量、线程、HTTP会话
