云原生全栈监控解决方案(全面详解)

这篇具有很好参考价值的文章主要介绍了云原生全栈监控解决方案(全面详解)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

【作者】JasonXu

前言

当前全球企业云化、数字化进程持续加速,容器、微服务等云原生技术在软件架构中快速渗透,IT 架构云化、复杂化持续驱动性能监控市场。企业云化、数字化持续转型,以及为了考虑系统的弹性、效率,企业软件开发中大量云原生技术的应用推动全球 IT 监控市场快速变化,如何全面、有效的对容器、K8s、微服务进行监控是当下云原生技术面临的重要课题。

背景和挑战

云化产品通常采用服务化框架,由一系列微服务组成,且微服务是可以独立运行的进程,不同服务可使用不同开发语言,可能分布部署在几千台服务器上,甚至可能横跨多个不同的数据中心,服务间使用轻量的通信机制;服务之间存在复杂的调用关系,对运维人员理解系统的行为或分析系统性能带来巨大挑战 如:

(1)容器是否正常运行

(2)K8S是否正常运行。

(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-cAdvisor,cAdvisor是谷歌专为监控容器性能状态设计的一个开源工具,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-3)prometheus-deploy.yml定义Prometheus的部署    

3-4)prometheus-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-driver=fluentd)将获得实时性很好的汇聚端日志展示,但由于日志直接发送到了远端的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 调用的 Span,D 和 E 两个后端服务调用的 Span 则都是 C 的子 Span。跟踪系统根据用户请求每次生成的全局唯一的ID(TraceId),TraceId 在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、NoSQL:Memcached/Redis/MogooDB的操作总耗时、平均响应时间、吞吐率

5、外部应用:HTTP/Thrif/Dubbo/Web Service的响应时间占比、平均响应时间、响应总时间、吞吐率、错误率

6、MQ:RabbitMQ/JMS/ActiveMQ生产者、消费者的消息总数、每分钟消息数、平均消息发送时间、总流量

7、JVM:内存使用量、线程、HTTP会话文章来源地址https://www.toymoban.com/news/detail-818289.html

到了这里,关于云原生全栈监控解决方案(全面详解)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • ‍Java OCR技术全面解析:六大解决方案比较

    博主猫头虎的技术世界 🌟 欢迎来到猫头虎的博客 — 探索技术的无限可能! 专栏链接 : 🔗 精选专栏 : 《面试题大全》 — 面试准备的宝典! 《IDEA开发秘籍》 — 提升你的IDEA技能! 《100天精通鸿蒙》 — 从Web/安卓到鸿蒙大师! 《100天精通Golang(基础入门篇)》 — 踏入

    2024年04月15日
    浏览(12)
  • 光学设备监控解决方案

    MES是美国管理界上世纪九十年代提出的新概念,MESA(MES国际联合会)对MES的定义是:MES能通过信息传递对从订单下达到产品完成的整个生产过程进行优化管理。当工厂发生实时事件时,MES能对此及时作出反应、报告,并用当前的准确数据对它们进行指导和处理。这种对状态变

    2024年04月10日
    浏览(25)
  • 【监控】Zabbix:企业级开源监控解决方案

    zabbix是一个监控软件,其可以监控各种网络参数,保证企业服务架构安全运营,同时支持灵活的告警机制,可以使得运维人员快速定位故障、解决问题。zabbix支持分布式功能,支持复杂架构下的监控解决方案,也支持web页面,为主机监控提供了良好直观的展现。 官网 zabbix主

    2024年02月12日
    浏览(17)
  • 修复“找不到unityplayer.dll”故障:全面解析与实用解决方案大全

    在运行基于Unity引擎开发的游戏或应用时,遭遇“找不到unityplayer.dll,无法继续执行代码”的错误提示,意味着系统未能找到该核心动态链接库(DLL)文件,从而导致程序无法启动或正常运行。本文将深入解析该问题的原因,提供一系列详细的排查步骤与有效的修复策略,帮

    2024年04月12日
    浏览(19)
  • 天然气井远程监控解决方案

    一、项目背景 随着天然气开发规模日益增长,天然气井的数量也在不断增加。且位置分散环境恶劣。传统的人工巡检方式越来越不能满足天然气井的生产需求和安全保障。天然气井井由储罐和集气站组成。 集气站通过计量站将天然气输入储罐或由集气站的储气装置输出, 再

    2024年02月09日
    浏览(15)
  • SAP性能监控分析解决方案

            SAP应用的重要性不言而喻,历经30余年的国内发展,已经拥有成百上千的中国用户。         SAP应用对业务至关重要,一旦该应用出现缓慢或性能不佳的情况,将会对企业收入造成重大损失。因此,SAP性能监控和用户体验监测变得尤为重要。         网深科

    2024年02月01日
    浏览(24)
  • 项目解决方案:商务大楼(大厦)网络高清视频监控建设方案

    目           录 第1章、前言 第2章、高清监控系统概述 第3章、设计原则 第4章、设计规范和依据 第5章、 系统总体设计 5.1 系统逻辑图 5.2 系统技术架构图 5.3 系统网络拓扑图 5.4 系统工作原理 5.4.1 前端监控资源采集 5.4.2前端监控资源采集 5.4.3 终端平台系统  5.5 系统组成

    2024年01月25日
    浏览(19)
  • 居民配电所远程监控解决方案

    一、项目背景 随着城市建设 提速 发展、能源利用日益提高、环保节能成为了城市发展的新趋势,配电站逐渐成为企业和居民生活中不可或缺的组成部分。居民的生活用电需求也日益增大。如果没有及时处理好用电安全很容易出现电力中断等情况发生。因此及时高效地为用电

    2023年04月25日
    浏览(15)
  • 电梯安全远程监控系统解决方案

    一、方案背景 随着万丈高楼的平地起,电梯也成为了我们出入高层建筑最常用的工具之一。面对电梯数量的不断增加,电梯安全事故也是相继频发,因此关于电梯的安全运行就越来越受到社会各界的关注。电梯的使用在给人们出入高层建筑带来便利的同时,由于电梯故障所造

    2024年02月03日
    浏览(15)
  • 远程监控及数据采集解决方案

    越来越多的企业集团呈跨地域的发展趋势。随着网络技术的不断发展,很多跨地域企业把远程监控应用在生产过程的管理中。通过远程监控,专业技术人员可以管理和维护生产过程,通过远程监控现场运行数据的实时采集和快速集中,专业技术人员可以获得监控现场数据,以

    2024年02月13日
    浏览(211)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包