做网站一单能挣多少,深圳网站搜索优化,昆明旅游网站建设,淮南政务网作者|无敌码农来源|无敌码农监控系统是运维体系乃至整个软件产品生命周期中最重要的一环#xff0c;完善的监控可以帮助我们事前及时发现故障#xff0c;事后快速追查定位问题。而在以微服务为代表的云原生架构体系中#xff0c;系统分为多个层次#xff0c;服务之间调用链… 作者|无敌码农来源|无敌码农监控系统是运维体系乃至整个软件产品生命周期中最重要的一环完善的监控可以帮助我们事前及时发现故障事后快速追查定位问题。而在以微服务为代表的云原生架构体系中系统分为多个层次服务之间调用链路复杂系统中需要监控的目标非常多如果没有一个完善的监控系统就难以保证整体服务的持续稳定。监控对象及分层在实际场景中监控系统按照监控的对象及系统层次结构从底向上可以依次划分为基础层、中间层、应用层、业务层等多个层面的监控。具体可如图所示基础层监控就是对主机服务器(包括宿主机、容器)及其底层资源进行监控以保证应用程序运行所依赖的基础环境的稳定运行。基础层监控主要有两个方向资源利用是对像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. 测量仪Gauge表示某个时间点对某个数值的测量。测量仪和计数器都可以用来查询某个时间点的固定内容的数值但和计数器不同测量仪的值可以随意变化可以增加也可以减少。比如获取Java线程池中活跃的线程数使用的是ThreadPoolExecutor中的getActiveCount方法;此外还有比较常见的CPU使用率、内存占用量等具体指标都是通过测量仪获取的。3. 直方图Histogram直方图是一种将多个数值聚合在一起的数据结构可以表示数据的分布情况。比如以常见的响应耗时举例可以把响应耗时数据分为多个桶Bucket,每个桶代表一个耗时区间例如0100毫秒、100500毫秒以此类推。通过这样的形式可以直观地看到一个时间段内的请求耗时分布这将有助于我们理解耗时情况分布。4. 摘要Summary摘要与直方图类似表示的也是一段时间内的数据结果但是摘要反应的数据内容不太一样。摘要一般用于标识分位值分位值其实就是我们常说的TP90、TP99等。例如有100个耗时数值将所有的数值从低到高排列取第90%的位置这个位置的值就是TP90的值如果这个桶对应的值假设是80ms那么就代表小于等于90%位置的请求都≤80ms。Kubernetes微服务监控体系前面我们从整体上描述了监控系统分层以及理解指标类监控系统所需要掌握的几类常见的指标类型。接下来我们重点探讨基于Kubernetes的微服务监控体系。从监控对象及系统分层的角度看监控系统需要监控的范围是非常广泛的但从微服务监控的角度来说如果你的微服务部署完全是基于Kubernetes云原生环境的那么我们需要关注的监控对象主要就是Kubernetes集群本身以及运行其中的微服务应用容器。例如对容器资源使用情况如CPU使用率、内存使用率、网络、I/O等指标的监控。当然这并不是说像基础层的物理机、虚拟机设备或者中间层软件的监控我们不需要关注只是这部分工作一般会有专门的人员去维护。而如果使用的是云服务那么云服务厂商大都已经为我们提供了监控支持。此外对于基础物理层及大部分中间软件的监控并不是本文所要表达的重点所以也就不再做过多的实践大家对此有个全局的认识即可。而回到以Kubernetes为载体的微服务监控体系虽然曾经Kubernetes项目的监控体系非常复杂社区中也有很多方案。但是这套体系发展到今天已经完全演变成了以Prometheus项目为核心的一套统一方案。在本节的内容中我们就将演示如何围绕Prometheus来构建针对Kubernetes的微服务监控系统。1. Prometheus简介经过行业多年的实践和沉淀目前监控系统按实现方式主要可以分为四类1)、基于时间序列的Metrics度量指标监控2、基于调用链的Tracing链路监控3、基于Logging日志的监控4、健康性检查(Healthcheck)。而在上述几种监控方式中Metrics监控是其中最主要的一种监控方式。简单理解Metrics的表现形式就是在离散的时间点上产生的数值点[Time,Value],由某个指标组成的一组[Time,Value]数值点序列也被称为时间序列所以Metrics监控也常常被称为时间序列监控。如上所述我们简单阐述了指标系统的基本特点而接下来要介绍的Prometheus就是一款基于时间序列的开源Metrics类型的监控系统它可以很方便地进行统计指标的存储、查询和告警。从整体上看Prometheus的系统结构如下图所示从上图中可以看出Prometheus工作的核心主要是使用Pull(拉取)的模式去收集被监控对象的Metrics数据监控指标数据然后由Prometheus服务器将收到的指标数据进行聚合后存储到TSDB时间序列数据库例如OpenTSDB、InfluxDB中以便后续根据时间自由检索。有了这套核心机制Prometheus剩下的组件就主要是用来配合这套机制运行的了。比如PushGateway它可以允许被监控对象以Push的方式向Prometheus推送Metrics数据。而Alertmanager则可以根据Metrics信息灵活地设置报警。此外Prometheus还提供了一套完整的PromQL查询语言通过其提供的HTTP查询接口使用者可以很方便地将指标数据与Grafana可视化监控指标展示工具结合起来从而灵活地定制属于系统自身的关键指标监控Dashboard看板。2. Prometheus Operator安装部署前面我们简单介绍了Prometheus监控系统的基本原理接下来的内容将以实操的方式演示如何使用Prometheus构建一套针对Kubernetes集群的微服务监控体系。在实际的应用场景中针对不同的监控对象Prometheus的部署方式也会有所不同。例如要监控的对象是底层的物理机或者以物理机方式部署的数据库等中间件系统那么这种情况下一般也会将Prometheus监控系统的部署环境放置在物理机下。而如果针对的是Kubernetes集群的监控那么现在主流的方式是采用Promethues-Operator将Promethues部署到Kubernetes集群之中这样能以更原生的方式实施对Kubernetes集群及容器的监控。这里所说的Promethues-Operator 是指专门针对Kubernetes的Promethues封装包它可以简化Promethues的部署和配置。接下来我们具体演示如何通过Promethues-Operator在Kubernetes中快速安装部署PromethuesKubernetes实验环境可参考本专栏相关内容具体步骤如下1安装Helm在本次安装过程中将使用到Kubernetes的包管理工具Helm。Helm是Kubernetes的一种包管理工具与Java中的Maven、NodeJs中的Npm以及Ubuntu的apt和CentOS的yum类似。主要用来简化Kubernetes对应用的部署和管理。首先从Github下载相应的Helm安装包具体命令参考如下#找到Github中Helm相关的发布包参考链接如下
https://github.com/helm/helm/releases#确定好相关版本后将具体安装版本下载至某个安装了kubectl的节点
wget https://get.helm.sh/helm-v3.4.0-rc.1-linux-amd64.tar.gz解压并将下载的可执行Helm文件拷贝到文件夹/usr/local/bin下命令如下tar -zxvf helm-v3.4.0-rc.1-linux-amd64.tar.gz
#将下载的可执行helm文件拷贝到文件夹/usr/local/bin下
mv linux-amd64/helm /usr/local/bin/之后执行helm version如果能看到Helm版本信息就说明Helm客户端安装成功了具体如下:$helm version
version.BuildInfo{Version:v3.4.0-rc.1,
GitCommit:7090a89efc8a18f3d8178bf47d2462450349a004,
GitTreeState:clean, GoVersion:go1.14.10}安装完Helm客户端后由于一些公共Kubernetes包是在远程仓库中管理的所以还需要添加helm chartsHelm中的Kubernetes安装包又叫charts官方仓库命令如下$helm repo add stable https://charts.helm.sh/stable查看本地helm仓库是否添加成功命令如下$helm repo list
NAME URL
stable https://charts.helm.sh/stable此时查看Helm仓库就能看到各种组件的charts列表了命令效果如下$helm search repo stableNAME CHART VERSION APP VERSION DESCRIPTION
stable/acs-engine-autoscaler 2.1.3 2.1.1 Scales worker nodes within agent pools
stable/aerospike
...如上所示此时通过“helm search”命令就可以查看到各种stable版本的Kubernetes安装包了!2Helm搜索Prometheus-Operator安装包在具体安装Prometheus-Operator之前我们先用“helm”命令搜索Prometheus相关的charts包命令如下$ helm search repo prometheus具体搜索结果如下图所示如上图所示我们可以看到Helm仓库中可以搜索到版本为0.38.1的“stable/prometheus-operator”的安装包。接下来就可以通过helm具体安装了3Helm安装Prometheus-Operator监控系统接下来啊通过Helm具体安装prometheus-operator监控系统命令如下#创建k8s名称空间
kubectl create ns monitoring#通过helm安装promethues-operator监控系统
helm install promethues-operator stable/prometheus-operator -n monitoring执行安装命令后输出结果如下WARNING: This chart is deprecated
manifest_sorter.go:192: info: skipping unknown hook: crd-install
manifest_sorter.go:192: info: skipping unknown hook: crd-install
manifest_sorter.go:192: info: skipping unknown hook: crd-install
manifest_sorter.go:192: info: skipping unknown hook: crd-install
manifest_sorter.go:192: info: skipping unknown hook: crd-install
manifest_sorter.go:192: info: skipping unknown hook: crd-install
NAME: promethues-operator
LAST DEPLOYED: Mon Oct 26 10:15:45 2020
NAMESPACE: monitoring
STATUS: deployed
REVISION: 1
NOTES:
*******************
*** DEPRECATED ****
*******************
* stable/prometheus-operator chart is deprecated.
* Further development has moved to https://github.com/prometheus-community/helm-charts
* The chart has been renamed kube-prometheus-stack to more clearly reflect
* that it installs the kube-prometheus project stack, within which Prometheus
* Operator is only one component.The Prometheus Operator has been installed. Check its status by running:kubectl --namespace monitoring get pods -l releasepromethues-operatorVisit https://github.com/coreos/prometheus-operator for instructions on how
to create configure Alertmanager and Prometheus instances using the Operator.执行完安装命令后查看具体的Kubernetes Pods信息命令如下$ kubectl get po -n monitoringNAME READY STATUS RESTARTS AGE
alertmanager-promethues-operator-promet-alertmanager-0 2/2 Running 0 5m42s
prometheus-promethues-operator-promet-prometheus-0 3/3 Running 1 5m31s
promethues-operator-grafana-5df74d9cb4-5d475 2/2 Running 0 6m53s
promethues-operator-kube-state-metrics-89d8c459f-449k4 1/1 Running 0 6m53s
promethues-operator-promet-operator-79f8b5f7ff-pfpbl 2/2 Running 0 6m53s
promethues-operator-prometheus-node-exporter-6ll4z 1/1 Running 0 6m53s
promethues-operator-prometheus-node-exporter-bvdb4 1/1 Running 0 6m53s如上所示可以看到Prometheus监控系统相关的组件都以Pod的方式运行在了Kubernetes集群中。Prometheus监控效果演示通过前面的实际操作我们通过Helm的方式已经将Prometheus Operator安装包部署在了Kubernetes集群之中。而此时的Prometheus实际上就已经开始发挥作用并采集了各类Kubernetes的运行指标信息。可以通过Promethues内置的监控界面对此进行查看具体步骤如下查看Kubernetes中查看内置监控界面所在的Pod节点命令如下kubectl -n monitoring get svc使用nodeport方式将promethues-operator内置界面服务暴露在集群外并指定使用30444端口命令如下kubectl patch svc promethues-operator-promet-prometheus -n monitoring -p {spec:{type:NodePort,ports:[{port:9090,targetPort:9090,nodePort:30444}]}}
service/promethues-operator-promet-prometheus patched此时在浏览器中输入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 -n monitoring get svc#使用nodeport方式将promethues-operator-grafana暴露在集群外指定使用30441端口
kubectl patch svc promethues-operator-grafana -n monitoring -p {spec:{type:NodePort,ports:[{port:80,targetPort:3000,nodePort:30441}]}}需要注意由于Grafana的应用运行的默认端口为80为避免实验环境冲突这里映射时将目标容器端口指定为3000并最终将节点端口映射为30441。完成后浏览器输入URL#IP地址为映射命令执行时所在的节点
http://10.211.55.11:30441如果映射正常此时会返回Grafana可视化图形界面的登录界面如图所示这里缺省登录账号密码为admin/prom-operator。输入后可进入Grafana主界面如下图所示可以看到部署完成的Grafana已经默认内置了许多针对Kubernetes平台的企业级监控Dashboard例如针对Kubernetes集群组件的“Kubernetes/API server”、“Kubernetes/Kubelet”以及针对Kubernetees计算资源的“Kubernetes/Compute Resources/Pod”、“Kubernetes/Compute Resources/Workload”等等。这里我们找一个针对Kubernetes物理节点的“Nodes”监控Dashboard点击打开后看到的监控效果如下图所示上图所示的Dashboard中展示了Kubernetes集群所在的各物理节点CPU、负载、内存、磁盘I/O、磁盘空间、网络传输等硬件资源的使用情况。从这些丰富的视图可以看出Grafana强大的监控指标可视化能力后记本文给大家从理论到实践简单介绍了Kubernetes微服务监控体系的构建步骤希望能够对大家学习Kubernetes有所帮助。目前以Kubernetes为代表的容器化技术已经成为现代软件应用发布的标准方式作为一名普通研发人员对Kubernetes的学习将有助于我们更深入的理解整体软件系统的构建原理也是我们进阶提升必不可少的知识储备往期推荐做安全操作系统这位技术老兵很认真云原生时代底层性能如何调优到底什么是“无源物联网”张一鸣购得元宇宙入场券谁将是头号玩家点分享点收藏点点赞点在看
