小楼一夜听春雨，深巷明朝卖杏花

您可以使用导出导入Grafana仪表盘功能对Grafana仪表盘进行备份，或将仪表盘从一个Grafana实例迁移到另一个实例中。本文介绍如何导出和导入Grafana仪表盘。

2、第二种方式则基于正则表达式，通过设置match_re验证当前告警标签的值是否满足正则表达式的内容。当前告警中是否存在标签labelname并且其值等于labelvalue。1、一种方式基于字符串验证，通过设置。告警的匹配有两种方式可以选择。

3、 container_cpu_user_seconds_total与container_cpu_system_seconds_total的总和，代表容器占用CPU的总和。6、 查询容器相关的 数据：查询所有POD的1min内CPU使用情况，用到的数据指标是k8s通过request（下限）和limit（上限）限制容器的CPU和内存的使用范围，在容器运行的过程中需要实时监控容器对cpu的使用情况。1、 容器用户态占用CPU的时间总和。

中添加标签可以采用Relabel Config的方式，通过在配置文件中编写relabel_config模块来定义要给哪些目标添加标签，该模块可以实现筛选、替换、修剪、添加等不同的转换操作。已经加载了新的配置文件。

指标是用来衡量性能、消耗、效率和许多其他软件属性随时间的变化趋势。它们允许工程师通过警报和仪表盘来监控一系列测量值的演变（如CPU或内存或磁盘使用量请求持续时间、延迟等指标在IT监控领域有着悠久的历史，并被工程师广泛使用，与日志和链路追踪一起被用来检测系统是否有不符合预期的表现。Prometheus收集的指标有四种，作为其暴露格式的一部分CountersGaugesHistogramsSummaries。

etcd 监控可以帮助您更好地利用 etcd，特别用于是定位性能问题。KubeSphere 监控系统提供了高度图形化和响应性强的仪表板，用于显示原生数据。频繁变更 Leader 将显著影响 etcd 性能，同时这还表明 Leader 可能由于网络连接问题或 etcd 集群负载过高而不稳定。如果成员没有 Leader，则成员完全不可用。如果集群中的所有成员都没有任何 Leader，则整个集群完全不可用。etcd 的底层数据库大小，单位为 MiB。图表中显示的是 etcd 的每个成员数据库的平均大小。.....

是一个Counter类型的指标，也就是会一直增长，这个数值其实是CPU时间片的一个累积值，意思就是从操作系统启动起来CPU开始工作，就开始记录自己总共使用的时间，然后保存下来。接下来我们来对节点的CPU进行监控，我们也知道一个一直增长的CPU时间对我们意义不大，一般我们更希望监控的是节点的CPU使用率，也就是我们使用top命令看到的百分比。对于节点我们首先能想到的就是要先对CPU进行监控，因为CPU是处理任务的核心，根据CPU的状态可以分析出当前系统的健康状态。......

前面的课程中我们知道我们可以通过AlertManager的配置文件去配置各种报警接收器，现在我们是通过Operator提供的alertmanager资源对象创建的组件，应该怎样去修改配置呢？我们可以看到内容和上面查看的配置信息是一致的，所以如果我们想要添加自己的接收器，我们就可以直接更改这个文件，但是这里的内容是base64编码过后的，如果手动添加内容就非常不方便，为此Prometheus-Operator新增了一个。的Receiver，在最终生成的配置中名称了。...

他们应该用怎样的方式通知我们呢？我们知道之前我们使用自定义的方式可以在Prometheus的配置文件之中指定AlertManager实例和报警的rules文件，现在我们通过Operator部署的呢？对象即可，比如现在我们添加一个etcd是否可用的报警，我们知道etcd整个集群有一半以上的节点可用的话集群就是可用的，所以我们判断如果不可用的etcd数量超过了一半那么就触发报警，创建文件。，用来匹配rule规则的过滤器，我们这里没有过滤，所以可以匹配所有的，假设要求匹配具有。...

为了使用 Prometheus-Operator，这里我们直接使用 kube-prometheus 这个项目来进行安装（提供了很多的内置规则，可以直接拿来使用），该项目和 Prometheus-Operator 的区别就类似于 Linux 内核和 CentOS/Ubuntu 这些发行版的关系，真正起作用的是 Operator 去实现的，而 kube-prometheus 只是利用 Operator 编写了一系列常用的监控资源清单。不过需要注意 Kubernetes 版本和 的兼容：我们可以直接使用 的

Prometheus 与 K8s 作为云原生时代的一对黄金搭档，是目前许多企业运行环境的标准配置。然而，为了适应业务规模和微服务的发展演进，被监控对象的数量会一路增长；为了更完整的体现系统或应用的状态细节，指标粒度划分越来越细致，指标数量越来越多；为了发现更长周期的趋势变化，指标数据的保留周期势必也要更长。所有这些变化最终都会导致监控数据量的爆炸性增长，给观测产品的存储、查询、计算带来非常大的压力。我们可以通过一个简单的场景，来更直观的感受下这种数据爆炸的后果。假如我们需要查询近一个月中我的集群各个节点上

在前面，我们单纯手工管理Prometheus还是复杂一些，因为它有很多东西需要我们去维护，特别是当有很多指标的时候需要我们去手工抓取和配置。前面我们用自定义的方式来对 Kubernetes 集群进行监控，基本上也能够完成监控报警的需求了。但实际上对上 Kubernetes 来说，还有更简单方式来监控报警，那就是 Prometheus Operator。Prometheus Operator 为监控 Kubernetes 资源和 Prometheus 实例的管理提供了简单的定义，简化在 Kubernetes

在了解了 VM 集群的一些配置细节后，接下来我们就来开始部署 VM 集群。Helm如果你已经对 VM 组件非常了解了，那么推荐使用 Helm Chart 的方式进行一键安装。我们这里选择手动方式进行部署，之所以选择手动部署的方式是为了能够了解各个组件的更多细节。手动安装由于 vmstorage 组件是有状态的，这里我们先使用 StatefulSet 进行部署，由于该组件也是可以进行扩展的，这里我们首先部署两个副本，对应的资源清单如下所示：由于是有状态的，这里创建的为headless servic

对于低于每秒一百万个数据点的摄取率，建议使用单节点版本而不是集群版本。单节点版本可根据 CPU 内核、RAM 和可用存储空间的数量进行扩展。单节点版本比集群版本更容易配置和操作，所以在使用集群版本之前要三思而后行。上面我们介绍了 VM 的单节点版本的基本使用，接下来我们来介绍下如何使用集群版。（集群对于维护工作增加了，而且数据量不大的话没必要使用集群版本）集群版主要特点：前面我们了解了 VM 的基本架构，对于集群模式下主要包含以下几个服务：每个服务都可以进行独立扩展， 节点之间互不了解、互不通信，并且不共享

这里我们采集 node-exporter 为例进行说明，首先使用 Prometheus 采集数据，然后将 Prometheus 数据远程写入 VM 远程存储，由于 VM 提供了 组件，最后我们使用 VM 来完全替换 Prometheus，可以使架构更简单、更低的资源占用。这里我们将所有资源运行在 命名空间之下：首先我们这 命名空间下面使用 DaemonSet 控制器运行 node-exporter，对应的资源清单文件如下所示：由于前面章节中我们也创建了 node-exporter，为了防止

VictoriaMetrics(VM) 是一个支持高可用、经济高效且可扩展的监控解决方案和时间序列数据库，可用于 Prometheus 监控数据做长期远程存储。前面章节我们介绍了 Thanos 方案也可以用来解决 Prometheus 的高可用和远程存储的问题，那么为什么我们还要使用 VictoriaMetrics 呢？相对于 Thanos，VictoriaMetrics 主要是一个可水平扩容的本地全量持久化存储方案(性能比thanos性能要好，thanos不是本地全量的，它很多历史数据是存放在对象存储当中

前面我们提到 Thanos 有 和 两种不同的架构模式，前面已经学习了 Sidecar 模式，接下来我们再来了解下 Receiver 模式是如何工作的。我们知道 Sidecar 是在每一个 Prometheus 的实例旁边添加一个 sidecar 组件来上传数据，但是数据上传并不是实时的，而是每 2h 上传一个数据块，所以远程存储的数据并不是实时的，Prometheus 需要各自持久化部分数据，这也是现在使用的 Sidecar 模式的弊端，但这并非是 Thanos 团队引入 Receiver 的决定性因

Store 组件上面我们安装了 Thanos 的 Sidecar 和 Querier 组件，已经可以做到 Prometheus 的高可用，通过 Querier 提供一个统一的入口来查询监控数据，而且还可以对监控数据自动去重，但是还有一个非常重要的地方是还没有配置对象存储，如果想要查看历史监控数据就不行了，这个时候我们就需要去配置 Thanos Store 组件，将历史监控指标存储在对象存储中去。目前 Thanos 支持的对象存储有：要在生产环境使用最好使用 Stable 状态的，比如 S3

前面我们了解到 querier 这个组件可以提供一个统一的查询入口，所以当查询的数据规模较大的时候，对 querier 组件也会有很大的压力，为此 Thanos 也提供了一个 Query Frontend 的组件来提升性能，当然该组件是可选的。Thanos Query Frontend 是 Thanos Query 的前端，它的目标是将大型查询拆分为多个较小的查询，并缓存查询结果来提升性能。类似于前面是nginx代理，把后面query组件的数据代理过来。然后做些缓存。概述Th

统计面板统计面板可以用于显示一个大的统计值和一个可选的背景颜色，我们可以使用阈值来控制背景或颜色值，效果如下所示：注意：该面板取代了在 Grafana 7.0 中已弃用的Singlestat面板。文本模式首先创建一个空的面板，选择使用Stat面板：首先添加一个用于查询节点运行时间的统计数据：同样我们可以在面板编辑器右侧对该面板的属性进行编辑，可以选择展示的方向是水平还是垂直，文本展示模式选择只展示 Value 值或者只展示 Name，也可以都显示...

现在历史监控数据已经上传到对象存储中去了，但是由于监控数据量非常庞大，所以一般情况下我们会去安装一个 Thanos 的 Compactor 组件，用来将对象存储中的数据进行压缩。Compactor 组件只与对象存储交互，是唯一拥有删除对象存储数据权限的组件，主要有两个作用：压缩 block（将多个 block 合并成一个）、降采样（可禁用，5m/1h 采样数据）。可设置数据保留时长，原始数据、5m/1h 降采样数据可分别设置保留时长。下采样Compactor 用于定时对远端对象...

Querier 组件现在我们就创建成功了两个 Prometheus 实例，但是我们真正去使用的时候并不是像上面提到的在前面加一个负载均衡器去查询监控数据，而是使用 Thanos 的Querier组件来提供一个全局的统一查询入口。对于Quierier最重要的就是要配置上 Thanos 的 Sidecar 地址，我们这里完全可以直接使用 Headless Service 去自动发现：# thanos-querier.yamlapiVersion: apps/v1kind: Deployme....

Sidecar 组件首先将前面章节中的 Prometheus 相关的资源对象全部删除，然后我们需要在 Prometheus 中去自动发现集群的一些资源对象，所以依然需要对应的 RBAC 权限声明：(rbac.yaml)Prometheus需要去做自动发现，所以RBAC还是不可少的。apiVersion: v1kind: ServiceAccountmetadata: name: prometheus namespace: kube-mon---apiVersion: rbac.

ThanosThanos是一个基于 Prometheus 实现的监控方案，其主要设计目的是解决原生 Prometheus 上的痛点，并且做进一步的提升，主要的特性有：全局查询，高可用，动态拓展，长期存储。下图是 Thanos 官方的架构图：Thanos 主要由如下几个特定功能的组件组成：(相当于微服务的模式，里面有比较多的组件)边车组件（Sidecar）：连接 Prometheus，并把 Prometheus 暴露给查询网关（Querier/Query），以供实时查询，并且可以上传 Pro.

前面我们已经学习了 Prometheus 的使用，了解了基本的 PromQL 语句以及结合 Grafana 来进行监控图表展示，通过 Alertmanager 来进行报警，这些工具结合起来已经可以帮助我们搭建一套比较完整的监控报警系统了，但是也仅仅局限于测试环境，对于生产环境来说则还有许多需要改进的地方，其中一个非常重要的就是 Prometheus 的高可用。单台的 Prometheus 存在单点故障的风险，随着监控规模的扩大，Prometheus 产生的数据量也会非常大，性能和存储都会面临问题。毋庸

通知模板告警通知使用的是默认模版，因为它已经编译到二进制包了，所以我们不需要额外配置。如果我们想自定义模版，这又该如何配置呢？Alertmanager 默认使用的通知模板可以从alertmanager/default.tmpl at main · prometheus/alertmanager · GitHub获取，Alertmanager 的通知模板是基于Golang 的模板系统，当然也支持用户自定义和使用自己的模板。第一种方式是基于模板字符串，直接在 Alertmanager 的配...

何时报警在 Prometheus 与 Alertmanager 中有很多地方都涉及到报警时机的配置，那么我的报警规则具体会在什么时候报警呢？首先在 Prometheus 的全局配置中有一个evaluation_interval属性，该属性表示的是间隔多长时间对报警规则进行评估，比如我们这里配置的 30s，那么每 30s 会去验证下我们的报警规则是否达到了阈值。 global: scrape_interval: 15s scrape_timeout: 10s ..

现在我们只是把 AlertManager 容器运行起来了，也和 Prometheus 进行了关联，但是现在我们并不知道要做什么报警，因为没有任何地方告诉我们要报警，所以我们还需要配置一些报警规则来告诉我们对哪些数据进行报警。属性，该属性表示的是间隔多长时间对报警规则进行评估，比如我们这里配置的 30s，那么每 30s 会去验证下我们的报警规则是否达到了阈值。这么长的时间才会发送，这里不会马上发送就是需要积攒一定数量的报警，防止报警数量过多，形成报警风暴。

监控 Pod之前的apiserver 实际上就是一种特殊的 Endpoints，现在我们同样来配置一个任务用来专门发现普通类型的 Endpoint，其实就是 Service 关联的 Pod 列表，由于并不是所有的 Endpoints 都会提供 metrics 接口，所以需要我们主动告诉 Prometheus 去发现哪些 Endpoints，当然告诉的方式有很多，不过约定俗成的一种方式是通过 annotations 注解进行通知，如下所示：- job_name: "endpoints" kube

前面我们和大家介绍了 Prometheus 的数据指标是通过一个公开的 HTTP(S) 数据接口获取到的，我们不需要单独安装监控的 agent，只需要暴露一个metrics接口，Prometheus 就会定期去拉取数据；对于一些普通的 HTTP 服务，我们完全可以直接重用这个服务，添加一个/metrics接口暴露给 Prometheus；而且获取到的指标数据格式是非常易懂的，不需要太高的学习成本。现在很多服务从一开始就内置了一个/metrics接口，比如 Kubernetes 的各个组件都直...

在图形上面某些点，比如波峰，这就可以为其添加注释，在图形看到的时候，就可以了解到当时的现场。AnnotationsGrafana 中提供了一个 Annotations 注释的方法，通过该方式可以在图形上标记一个点，当将鼠标悬停在上面的时候，可以获得该注释的具体信息，我们可以在 Panel 面板中某一个点添加注释，也可以在某一个区域内添加注释。Grafana 带有本地注释存储，并且能够直接从图形面板或通过 HTTP API 添加注释事件。在某一个点添加注释，我们只需要按住C...

文本面板¶前面我们介绍的一些面板基本上都是通过查询来获取数据进行展示的，这里给大家另外一个面板：文本面板，该面板不需要查询语句，直接用来展示文本信息，而且是支持Markdown和HTML两种格式，这就为我们提供了很大的定制灵活性。文本面板的使用非常简单，直接选择使用 Markdown 还是 HTML 来设置文本样式即可，然后在面板编辑器的文本框中输入内容即可。比如很多公司业务太大太多，需要监控的 Dashboard 非常多，操作管理起来非常麻烦，这个时候我们就可以使用文本面板来做一个导航页面...

之前介绍了基于时序数据来可视化我们的面板，今天要介绍表格面板。

仪表盘如果想展示与最大值和最小值相关的数据，我们可以选择使用仪表盘面板，比如我们用一个仪表盘面板来展示内存使用率。标准仪表盘可视化在 Dashboard 页面上点击创建一个新的空面板，在面边编辑器右上方选择Gauge类型的面板：然后添加如下所示的查询语句，获取内存使用率：接下来在右侧属性区域设置单位、最小值为 0、最大值为 100：同样的，如果选择多个节点的时候显示不够友好:需要在 Legend 地方配置显示的标签{{instance}}，...

但是这里有一个明显的问题是内存使用率的结果是一个百分比，而其他内存使用情况的结果是具体的内存大小，那么将他们绘制在同一个图形中必然会有单位不一致的问题。如果有多个转换，Grafana 会按照它们列出的顺序来应用它们，每个转换都会创建一个新的结果集，该结果集会传递到管道中的下一个转换进行处理。根据上面的方式方法基本上可以把我们的监控图表绘制出来，但是有的场景下面可能需要更多的定制功能。按钮可以对属性进行覆盖操作，可选的方式有很多，比如可以设置指定具体属性的值，也可以根据正则表达式来匹配属性的名进行配置，

现在我们在一个 Dashboard 中添加了两个 Panel，我们可以很明显看到会直接将所有的节点信息展示在同一个面板中，但是如果有非常多的节点的话数据量就非常大了，这种情况下我们最好的方式是将节点当成参数(通过这个参数添加到Promql里面去，实现对时间序列的过滤，比如只过滤出某些节点)，可以让用户自己去选择要查看哪一个节点的监控信息，要实现这个功能，我们就需要去添加一个以节点为参数的变量来去查询监控数据。点击 Dashboard 页面右上方的Dashboard settings按钮，进入配置页面..

面板介绍面板（Panel）是 Grafana 中基本可视化构建块，每个面板都有一个特定于面板中选择数据源的查询编辑器，每个面板都有各种各样的样式和格式选项，面板可以在仪表板上拖放和重新排列，它们也可以调整大小，所以要在 Grafana 上创建可视化的图表，面板是我们必须要掌握的知识点。Panel 是 Grafana 中最基本的可视化单元，每一种类型的面板都提供了相应的查询编辑器(Query Editor)，让用户可以从不同的数据源（如 Prometheus）中查询出相应的监控数据，并且以可视化的方式

Grafana 介绍Grafana是一个监控仪表系统，它是由 Grafana Labs 公司开源的的一个系统监测工具，它可以大大帮助我们简化监控的复杂度，我们只需要提供需要监控的数据，它就可以帮助生成各种可视化仪表，同时它还有报警功能，可以在系统出现问题时发出通知。Grafana 支持许多不同的数据源，每个数据源都有一个特定的查询编辑器，每个数据源的查询语言和能力都是不同的，我们可以把来自多个数据源的数据组合到一个仪表板，但每一个面板被绑定到一个特定的数据源。目前官方支持以下数据源：Alert.

predict_linear()预测Gauge指标变化趋势predict_linear(v range-vector, t scalar)函数可以预测时间序列 v 在 t 秒后的值。它基于简单线性回归的方式，对时间窗口内的样本数据进行统计，从而可以对时间序列的变化趋势做出预测。该函数的返回结果不带有度量指标，只有标签列表。例如，基于 2 小时的样本数据，来预测主机可用磁盘空间的是否在 4 个小时候被占满，可以使用如下表达式：predict_linear(node_filesystem_f...

Exporter 介绍前面我们介绍了我们可以通过一个 metrics 接口为 Prometheus 提供监控指标，最好的方式就是直接在目标应用中集成该接口（有些应用集成了metrics 接口），但是有的应用并没有内置支持 metrics 接口，比如 linux 系统、mysql、redis、kafka 等应用，这种情况下我们就可以单独开发一个应用来专门提供 metrics 服务，这就是我们这里说的Exporter，广义上讲所有可以向 Prometheus 提供监控样本数据的程序都可以被称为一个 Exp.