本文转载自微信公众号《无敌码农》，作者无敌码农。转载请联系无敌码农公众号。监控系统是运维系统乃至整个软件产品生命周期中最重要的一环。完善的监控可以帮助我们事前及时发现问题，事后快速跟踪定位问题。然而，在以微服务为代表的云原生架构体系中，系统分为多层，服务之间的调用链路复杂，系统中需要监控的目标较多。没有完整的监控系统，就很难保证整体服务的持续稳定。监控对象及层次在实际场景中，监控系统可以根据监控对象和系统层次从下到上分为基础层、中间层、应用层、业务层等多个层次的监控。具体如图所示：基础层监控是对宿主服务器（包括宿主机和容器）及其底层资源进行监控，保证应用程序运行的基础环境稳定运行。基础层监控主要有两个方向：资源利用率：监控I/O利用率、CPU利用率、内存利用率、磁盘利用率、网络负载等硬件资源。避免因应用本身或其他特殊情况导致硬件资源耗尽而导致服务失败。网络通讯：就是监控服务器之间的网络状态。网络通信是互联网的重要基石。如果主机间网络出现延时过大、丢包率高等网络问题，将严重影响业务。需要注意的是，在基于Kubernetes容器化技术的全新云原生基础设施中，基础层的监控不仅是监控主机本身，还监控Kubernetes集群的状态及其容器资源使用情况。这个我们在后面搭建基于Kubernetes的基础层监控系统的时候会详细介绍。中层监控主要是指对Nginx、Redis、MySQL、RocketMQ、Kafka等应用服务所依赖的中间件软件的监控。它们的稳定性也是确保应用程序持续可用的关键。一般来说，具体的中间件软件会根据自身的特点构建有针对性的监控系统。这里的应用层监控指的是对业务服务程序的监控。一般来说，我们对应用监控的关注主要体现在以下几个方面：HTTP接口请求接入。包括接口响应时间、吞吐量等；JVM监控指标。对于Java服务，我们也会重点关注GC时间、线程数、FGC/YGC耗时等JVM性能相关指标；资源消耗。应用部署后，会消耗一定的资源，比如应用对内存、CPU的消耗；服务的健康状态。比如当前服务是否存活，运行是否稳定等；调用链接。在微服务架构中，由于调用链路变长，还需要重点监控服务间的调用关系和调用情况，避免本地上下游服务之间的链路故障导致系统全局雪崩；业务层监控也是监控系统需要重点关注的一件事情。在实际场景中，仅仅让应用稳定运行是肯定不够的。因此，我们经常监控特定业务产生的数据，如网站系统关注的PV、UV等参数；在交易等后台系统中，我们会关注订单量、成功率等，业务指标也是体现系统稳定性的核心要素。任何一个系统，一旦出现问题，首先受到影响的一定是业务指标。核心业务指标的设置因具体业务和场景而异，因此对于业务层的监控，需要构建具有业务特点的业务监控体系。常见的几种监控指标在指标监控系统中，可以通过统计指标来感性地感知整个系统的运行情况。出现问题后，各个指标首先会出现波动，这些波动会反映出系统是哪些方面出现了问题，从而可以据此排查问题的原因。下面我们来看一下统计指标的种类和常见的统计指标。是我们进一步了解指标监控系统的基础。综合来看，常见的Metrics指标类型主要有：Counter、Gauge、Histogram、Summary。它们的特点如下：1.计数器（Counter）计数器是一种具有累积特性的指标类型。一般这个值是Double或者Long类型。比如QPS、TPS等常见的统计指标的值都是以计数器的形式计算出来的，然后结合一些统计函数。2、量具是指在某一时间点对某一数值的测量。计量器具和计数器都可以用来查询某个时间点固定内容的数值，但与计数器不同的是，计量器具的数值是可以随意改变的，可以增减。例如获取Java线程池的活跃线程数，使用ThreadPoolExecutor中的getActiveCount方法；除此之外，还有一些比较常见的具体指标，比如CPU占用率、内存占用率，都是通过meter来获取的。3、直方图（Histogram）直方图是一种将多个值聚合在一起的数据结构，可以表示数据的分布情况。例如，以常见的响应耗时为例，响应耗时数据可以分为多个桶（Bucket），每个桶代表一个耗时区间，比如0-100毫秒，100-500毫秒，等等。通过这个表格，我们可以直观的看到一段时间内请求的耗时分布情况，有助于我们了解耗时情况的分布情况。4.汇总（Summary）汇总类似于直方图，也是展示一段时间内的数据结果，只是汇总反映的数据内容不同。摘要一般用来标识分位数值，其实也就是我们常说的TP90、TP99等，比如有100个耗时值，把所有的值从低到高排列，取90%的位置。这个位置的值就是TP90的值。如果假设这个bucket对应的值为80ms，那么意味着小于等于90%的定位请求都是≤80ms。Kubernetes微服务监控系统在上一节中，我们介绍了监控系统整体的分层以及需要掌握的常见指标类型，以了解指标监控系统。接下来重点介绍基于Kubernetes的微服务监控系统。从监控对象和系统层来看，监控系统需要监控的范围很广，但是从微服务监控的角度来说，如果你的微服务部署完全基于Kubernetes云原生环境，那么我们需要的监控对象主要关注的是Kubernetes集群本身以及运行在其中的微服务应用容器。比如容器资源使用情况的监控，比如CPU使用率、内存使用率、网络、I/O等指标。当然，这并不是说我们在基础层不需要关注物理机、虚拟机设备或者中间层软件的监控，只是这部分工作一般都是由专人维护的.而如果你使用的是云服务，大部分云服务厂商都为我们提供了监控支持。另外，基础物理层和大部分中间软件的监控不是本文的重点，所以不做过多的练习，大家需要对此有一个整体的了解。回到基于Kubernetes的微服务监控系统，虽然Kubernetes项目的监控系统非常复杂，但是社区中有很多解决方案。但是这套系统发展到今天，已经完全演变成一套以Prometheus项目为核心的统一解决方案。在本节中，我们将演示如何围绕Prometheus构建Kubernetes的微服务监控系统。一、Prometheus简介经过多年的行业实践和沉淀，目前的监控系统按照实现方式主要可以分为四类：1）、基于时间序列的Metrics（指标）监控；2)、基于调用链的Tracing(link))监控；3）、基于Logging（日志）的监控；4）、健康检查（Healthcheck）。在以上监控方式中，Metrics监控是最主要的监控方式。Metrics的形式简单理解就是离散时间点产生的数值点[Time,Value]，由某个指标组成的一组[Time,Value]数值点序列也称为时间序列，所以Metrics监控通常也称为时间序列监控。上文简单介绍了指标体系的基本特性，接下来要介绍的Prometheus是一个开源的基于时间序列的Metrics类监控系统，可以方便的对统计指标进行存储、查询和告警。整体来看Prometheus的系统结构，如下图所示：从上图可以看出，Prometheus的工作核心主要是使用Pull（拉取）方式收集Metrics数据（监控对象的监控指标数据），然后Prometheus服务器将接收到的指标数据进行聚合存储到TSDB（时间序列数据库，如OpenTSDB、InfluxDB）中，供后续根据时间自由检索。有了这个核心机制，Prometheus剩下的组件主要就是用来配合这个机制的。比如PushGateway，它允许被监控对象以Push的形式将Metrics数据推送给Prometheus。Alertmanager可以根据Metrics信息灵活设置告警。此外，Prometheus还提供了一套完整的PromQL查询语言。通过其提供的HTTP查询接口，用户可以方便地将指标数据与Grafana（可视化监控指标展示工具）相结合，灵活定制系统本身。关键指标监控仪表板（Kanban）。2.PrometheusOperator安装部署我们简单介绍了Prometheus监控系统的基本原理。下面的内容将实战演示如何使用Prometheus搭建Kubernetes集群的微服务监控系统。在实际应用场景中，Prometheus针对不同监控对象的部署方式也会有所不同。比如监控的对象是底层的物理机，或者部署在物理机上的数据库等中间件系统。在这种情况下，Prometheus监控系统的部署环境一般放在物理机下。而如果是针对Kubernetes集群的监控，目前主流的方式是使用Promethues-Operator将Promethues部署到Kubernetes集群中，这样可以更原生的实现对Kubernetes集群和容器的监控。这里所说的Promethues-Operator是指专门针对Kubernetes的Promethues包，可以简化Promethues的部署和配置。接下来我们将演示如何通过Promethues-Operator在Kubernetes中快速安装部署Promethues（Kubernetes实验环境可参考本专栏相关内容）。具体步骤如下：1）安装Helm。在这个安装过程中，Kubernetes会用到包管理工具Helm。Helm是Kubernetes的包管理工具，类似于Java中的Maven、NodeJs中的Npm、Ubuntu中的apt和CentOS中的yum。主要用于简化Kubernetes对应用的部署和管理。首先从Github下载对应的Helm安装包。具体命令如下：#在Github中找到Helm相关的release包，参考链接如下https://github.com/helm/helm/releases#确定相关版本后，具体下载安装版本到安装了kubectl的节点wgethttps://get.helm.sh/helm-v3.4.0-rc.1-linux-amd64.tar.gz，解压，将下载的可执行Helm文件复制到文件夹/下usr/local/bin，命令如下：tar-zxvfhelm-v3.4.0-rc.1-linux-amd64.tar.gz#将下载的可执行helm文件复制到文件夹/usr/local/bin下载mvlinux后-amd64/helm/usr/local/bin/，执行helm版本。如果可以看到Helm版本信息，说明Helm客户端已经安装成功。具体如下：$helmversionversion.BuildInfo{Version:"v3.4.0-rc.1",GitCommit:"7090a89efc8a18f3d8178bf47d2462450349a004",GitTreeState:"clean",GoVersion:"go1.14.10"}安装Helm客户端后，由于一些公共的Kubernetes包在远程仓库管理，需要添加helmCharts（Helm中的Kubernetes安装包也叫charts）官方仓库，命令如下：$helmrepoaddstablehttps://charts.helm.sh/stable查看本地helm仓库是否添加成功，命令如下：$helmrepolistNAMEURLstablehttps://charts.helm。sh/stable此时通过查看Helm仓库可以看到各个组件的charts列表。命令效果如下：$helmsearchrepostableNAMECHARTVERSIONAPPVERSIONDESCRIPTIONstable/acs-engine-autoscaler2.1.32.1.1Scalesworkernodeswithinagentpoolsstable/aerospike...如上图，此时可以通过“helmsearch”命令查看各种稳定版本的Kubernetes安装包！2）、Helm在具体安装Prometheus-Operator之前先搜索Prometheus-Operator安装包，我们先使用“helm”命令搜索Prometheus相关的charts包。命令如下：$helmsearchrepoprometheus具体搜索结果如下图所示：如上图所示，我们可以看到在Helm仓库中可以找到0.38.1版本的“stable/prometheus”-operator”安装包接下来就可以通过helm安装了！3）Helm安装Prometheus-Operator监控系统接下来通过Helm安装prometheus-operator监控系统。命令如下：#createk8snamespacekubectlcreatensmonitoring#installpromethues-operatormonitoringthroughhelm系统helminstallpromethues-operatorstable/prometheus-operator-nmonitoring执行安装命令后，输出如下：WARNING:Thischartisdeprecatedmanifest_sorter.go:192:信息：skippingunknownhook：“crd-install”manifest_sorter.go:192：信息：skippingunknownhook：“crd-install”manifest_sorter.go:192：信息：skippingunknownhook：“crd-install”manifest_sorter.go:192：信息：skippingunknownhook：“crd-install"manifest_sorter.go:192:info:skippingunknownhook:"crd-install"manifest_sorter.go:192:info:skippingunknownhook:"crd-install"NAME:promethues-operatorLASTDEPLOYED:MonOct2610:15:452020NAMESPACE:monitoringSTATUS:deployedREVISION:1注：**********************已弃用************************稳定/prometheus-operatorchartis已弃用。*进一步开发已移至https://github.com/prometheus-community/helm-charts*Thecharthasbeenrenamedkube-prometheus-stacktomoreclearlyreflect*thatitinstallsthe`kube-prometheus`projectstack,withinwhichPrometheus*Operatorisonlyonecomponent.ThePrometheusOperatorhasbeeninstalled.Checkitsstatusbyrunning:kubectl--namespacemonitoringgetpods-l"release=promethues-operator"Visithttps://github.com/coreos/prometheus-operatorforinstructionsonhowtocreate&configureAlertmanagerandPrometheusinstancesusingtheOperator.执行完安装命令后，查看具体的KubernetesPods信息，命令如下：$kubectlgetpo-nmonitoringNAMEREADYSTATUSRESTARTSAGEalertmanager-promethues-operator-promet-alertmanager-02/2Running05m42sprometheus-promethues-operator-promet-prometheus-03/3Running15m31spromethues-operator-grafana-5df74d9cb4-5d4752/2Running06m53spromethues-operator-kube-state-metrics-89d8c459f-449k41/1Running06m53spromethues-operator-promet-operator-79f8b5f7ff-pfpbl2/2Running06m53spromethues-operator-prometheus-node-exporter-6ll4z1/1Running06m53spromethues-operator-prometheus-node-exporter-bvdb41/1Running06m53s如上图，可以看到与Prometheus监控系统相关的组件以pod的形式运行在Kubernetes集群中。顺便在Kubernetes集群中部署了PrometheusOperator安装包。这时候Prometheus其实已经开始发挥作用了，收集了各种Kubernetes运行指标信息。您可以通过Promethues内置的监控界面查看。具体步骤如下：在Kubernetes中查看内置监控接口所在的Pod节点。命令如下：指定端口30444，命令如下：kubectlpatchsvcpromethues-operator-promet-prometheus-nmonitoring-p'{"spec":{"type":"NodePort","ports":[{"port":9090,"targetPort":9090,"nodePort":30444}]}}'service/promethues-operator-promet-prometheuspatched此时输入Pod节点所在主机的IP+端口地址浏览器。URL示例如下：http://10.211.55.11:30444/graph此时可以看到Promethues内置的监控可视化界面，效果如下图：如果查看具体的此时PromeQL模式的指标，以“http_requests_total”为例，显示效果如图：这说明此时Promethues监控系统已经开始运行，相关的Metrics指标数据已经采集完成！Grafana可视化监控系统Grafana是一个强大的跨平台开源度量分析和可视化工具，可以将采集到的指标数据以自定义的图形化界面展示，常被用作时间序列数据的可视化和应用分析。Grafana支持多种数据源，例如InfluxDB、OpenTSDB、ElasticSearch和Prometheus。当我们在Kubernetes中安装部署Prometheus-Operator时，Grafana其实已经集成并运行起来了。可以通过Kubernetes相关命令查询Grafana实际运行的Pod，并将其web端口对外暴露，如下：#查看服务节点信息kubectl-nmonitoringgetsvc#使用nodeport将promethues-operator-grafana暴露在集群外，并指定端口30441kubectlpatchsvcpromethues-operator-grafana-nmonitoring-p'{"spec":{"type":"NodePort","ports":[{"port":80,"targetPort":3000,"nodePort":30441}]}}'需要注意的是，由于Grafana的应用默认端口是80，为了避免实验环境冲突。这里映射的时候指定目标容器端口为3000，最后映射节点端口为30441，完成后在浏览器中输入网址：#IP地址为执行映射命令的节点http://10.211.55.11:30441如果映射正常，此时会返回Grafana可视化图形界面的登录界面，如图：这里默认登录账号密码为：admin/prom-operator。进入后可以进入Grafana的主界面如下图所示：可以看到部署好的Grafana默认为Kubernetes平台搭建了很多企业级的监控Dashboard，比如“Kubernetes/APIserver”和“Kubernetes集群组件的Kubernetes/Kubelet”。”，以及Kubernetes计算资源的“Kubernetes/ComputeResources/Pod”、“Kubernetes/ComputeResources/Workload”等。在这里，我们找到了Kubernetes物理节点的“节点”监控仪表板。点击打开可以看到如下图的监控效果：上图的Dashboard显示了CPU、负载、内存、磁盘I/O、磁盘空间、网络传输等硬件资源的使用情况。从这些丰富的视图中，我们可以看出Grafana强大的监控指标可视化能力！后记本文从理论到实践简要介绍了Kubernetes微服务监控系统的构建步骤，希望对大家学习Kubernetes有所帮助。目前，以Kubernetes为代表的容器化技术已经成为现代软件应用发布的标准方式。作为一名普通的研发人员，学习Kubernetes将帮助我们更深刻地理解整个软件系统的构建原理，也是我们前进的途径，提高必备的知识储备！原文链接：https://mp.weixin.qq.com/s/WbkoqOnCQv0cywPysfKzng
