本文由于工作任务需要，快速入门了一下Prometheus的一些相关理论知识，供开发过程中快速查阅。

一：监控概念&误区

  1. 监控是管理基础设施和业务的核心工具，监控应该和应用程序一起构建和部署，没有监控，将无法了解你的系统运行环境，进行故障诊断，也无法阻止提供系统性的性能、成本和状态等信息
  2. 误区：
      要尽量避免进行机械式的监控、不够准确的监控、静态和监控、不频繁的监控、缺少自动化或自服务

二：黑盒监控&白盒监控

1. 黑盒监控（也叫探针）

  • 应用程序或主机是从外部观察的，因此，这种方法可能相当有限。检查是为了评估被观察的系统是否以已知的方式响应探测。
  • 例子：
    (1) 主机是否相应PING的请求
    (2)特定的TCP端口是否打开
    (3)应用程序在接受到特定的HTTP请求时，是否使用正确的数据和状态代码进行响应
    (4)特定应用程序的进程是否在其主机中运行

2. 白盒监控

系统在被测对象表面显示其内部状态和临界段的性能数据。这种类型的自省可能非常强大，因为它暴露了内部操作，显示不同内部组件的健康状况，否则很难甚至不可能确定。这种数据处理通常以胰腺癌方式进行处理：
（1）通过日志导出：到目前为止。这是也是在广泛引入库之前，应用程序是如何暴露其内部工作的最常见的情况，例如：可以处理HTTP服务器的访问日志来监视请求率、延迟和错误百分比
（2）以结构化的事件输出：这种方法类似于日志记录，但不是将数据写入磁盘，而是直接将数据发送到处理系统进行分析和聚合。
（3）以聚合的方式保存在内存中：这种格式的数据可以驻留在端点中，也可以直接从命令行工具中读取。这种方法的例子有/metrics with Prometheus metrics、HAProxy的stats页面或varnishstats命令行工具

三：度量指标

度量指标有监控系统执行的过程通常可以分为两种方式——push（监控系统去服务进行拉取）、pull（被监控的服务自动往监控系统进行推送）【站在客户的角度】

  • push VSpull
  • 测量什么：
      谷歌提出应该监控的四个指标：
    1、延迟：服务请求所需的时间
    2、流量：正在发出的请求的数量
    3、错误：求失败的比率
    4、饱和：未处理的工作量，通常在队列中
      Brendan的方法更关注于及其，他声明对于每个资源（CPU、磁盘、网络接口等等），应该监视以下指标：
    1、利用率：以资源繁忙的百分比来衡量
    2、饱和：资源无法处理的工作量，通常会排队
    3、错误：发生的错误数量
      汤姆威尔基的红色方法：更侧重于服务级别方法，而不是底层系统本身。显然，这种才领略对于见识服务很有用，对于预测外部客户的体验也很有价值。如果服务的错误率增加，那么就可以合理地假设这些错误将直接或间接地影响客户的体验。
    1、速率：转换成每秒请求数
    2、错误：每秒失败请求的数量
    3、持久性：这些请求所花费的时间

四：Prometheus

1. 介绍&架构

  介绍：Prometheus是一个开源系统监控和警报工具包，将其监控的指标进行收集并存储为时间序列数据，即指标信息与记录时的时间戳以及称为标签的可选键值对一起存储。很多公司用来监控K8s集群。

企业 zabbix监控哪些指标 什么是企业监控_数据


其架构组成：

  • Prometheus server用于抓取和存储时间序列化数据
  • 用于检测应用程序代码的客户端库
  • 支持短期工作的推送网关Pushgateway
  • HAProxy、StatsD、Graphite等服务的专用出口商
  • 处理警报的警报管理器AlertManager
  • 各种支持工具

2. 合适&不合适场景

  合适场景：Prometheus可以很好地记录任何数字时间序列，它既适合以机器为中心的监控，也适合监控高度动态的面向服务的架构。在微服务的世界中，他对多维数据收集的查询的支持是一个特殊的优势。专为可靠性而设计，是在中断期间可以使用的系统，可让你快速诊断问题。每个Prometheus服务器都是独立的，不依赖于网络存储或其他远程服务。当你的基础设施的其他部分损坏时，你可以依赖他，并且你无需设置大量基础设施即可使用
  不合适场景：你需要100%准确性，例如按请求计费。这时候Prometheus就不太适合，你最好使用其他系统来收集和分析数据以进行计费。

3. 数据模型

因为监控数量极大，所以使用了时间序列数据存储（就是带时间戳和值的）

  • Prometheus本地存储：
      Prometheus的本地存储被称为Prometheus TSDB。TSDB的设计核心有两个：block和WAL，而block又包含chunk、index、meta.json、tombstones。
      TSDB将存储的监控数据按照时间分隔成block，block大小并不固定，按照设定的步长倍数递增。随着数据量的不断增长，TSDB会将小的block合并成大的block，这样不仅可以减少数据存储，还可以减少内存中的block个数，便于对数据进行索引。
      每个block都有全局唯一的名称，通过ULID（Universally Unique Lexicograpphically Sortable Indetifier，全局字典可排序ID）原理生成，可以通过block的文件名确定这个block的创建时间，从而很方便的按照时间对block排序。对时序数据库的查询通常会涉及到连续的很多块，这种通过命名便可以排序的设计非常简便。
      WAL（Write-Ahead Logging，预写日志）是关系型数据库中利用日志来实现事务性和持久性的一种技术，即在进行某个操作之前先将这件事情记录下来，以便之后数据进行回滚、重试等操作并保证数据的可靠性。Prometheus为了防止丢失暂存在内存中还未被写入磁盘的监控数据，引入了WAL机制。
      按照每种对象设定的采集周期，Prometheus会将周期性采集的监控数据通过Add接口添加到head block中，但这些数据没有被持久化，TSDB通过WAL将提交的数据先保存到磁盘中，在TSDB宕机重启后，会首先启动多协程读取WAL，从而恢复之前的状态。
  • Prometheus数据模型：
      Prometheus将数据存储为时间序列，其中包括称为标签的键值对、时间戳和最后的值
      表示法：<metric_name>[{<label_1=“value_1”>,<label_N=“value_N”>}]<datapoint_numercial_value>

4. 指标

Counter：Prometheus实例接收的数据包总数**（一直增）**

  • Gauge：测量是一种度量，他在收集时对给定的测量进行快照，可以增加或减少（例如温度、磁盘空间、内存使用量）
  • Histogram：常常用于观察，一个Histogram包含下列值的合并：【某时间段内的百分比或者请求数量有多少】
    （1）Buckets：桶是观察的计数器，他应该有个最大值的边界和最小值的边界。
    （2）观察结果的和，这是所有观察的和
    （3）观察结果统计，这是在本次观察的和
    （4）Summaries：蕾丝Histogram

5. 指标的摘要和聚合

指标摘要：通常来说。单个指标对我们来说价值很小，往往需要联合并可视化多个指标，这其中需要一些数学变换，例如我们可能会统计函数应用于指标或指标组，常见函数有：计数、求和、平均值、中间数、百分位数、标准差、变化率等等

  • 指标聚合：就是能看到来自多个源的指标的聚合视图

6. Prometheus部署【省】

7. Prometheus配置【省】

重新标记：有两个阶段可以重新标记。第一阶段是对来自服务发现的目标进行重新标记，这是对来自服务发现的元数据标签中的信息应用于指标上的标签来说非常有用。第二阶段是抓取指标之后但是在存储系统之前，这样就可以确定哪些指标需要保存，那些需要丢弃以及这些指标的样式

8. NodeExporter部署

Prometheus使用exporter工具来暴露主机和应用程序上的指标。有很多种类型的exporter。

9. cAdvisor监控Docker容器

cAdvisor（Constainer Advisor）是由谷歌开发的一个项目，让从正在运行的容器手机、聚合、分析和导出数据。可用的数据涵盖了几乎所有你可能需要的东西，从内存限制到GPU指标

  • cAdvisor并不绑定到Docker容器，但它通常作为一个容器部署，从容器守护进程和Linux cgroups收集数据，是容器的发现透明且完全自动化。
  • 除了以Prometheus格式公开指标之外，cAdvisor还提供了一个有用的web界面，允许即使可视化主机及其容器的状态

10. 捕获目标生命周期

服务发现——》配置——〉重新标记（relable_configs）——》抓取——〉metrics_relable_configs

11. PromQL查询语言

选择器及标签匹配器：
（1）选择器：Prometheus被设计用来处理成千上万的时间序列、根据标签的组合，咩哥指标名称可以有几个不同的时间序列；当来自不同的工作的类型名称的指标混合在一起时，查询正确的数据可能看起来比较困难。所以在Prometheus中，选择器指的是一组标签匹配器、度量名称也包含在这个定义中，因为从技术上讲，他的内容表示也是一个标签，尽管是一个特殊的标签：name。选择器中的每个标签名称/值对称为标签匹配器，多个匹配器可用于进一步筛选选择器匹配的时间序列。标签匹配器用花括号括起来。如果不需要匹配器，可以省略花括号。选择器可以返回及时或范围向量

//例如：
$ prometheus_build_info{version="2.17.0"}

（2）标签匹配器

  • 标签匹配器用于将查询搜索限制为特定的一组标签值。下面将使用node_cpu_secends_total metric来阐述标签匹配的操作，匹配的操作符有=、!=、=和! 如果没有任何匹配的规范。仅此度量就会返回一个包含度量名称的所有可用时间序列的及时向量。以及所有的CPU核心数（cpu=“0”，cpu=“1”）和CPU的型号（mode=“idle”，mode=“iowait”，mode=“irq”，mode=“nice”，mode=“softirq”，mode=“steal”，mode=“user”，mode=“system”）
    （3）范围、偏移、子查询
  • 范围向量：如果要定义一个范围向量选择查询，你必须设置一个及时向量选择器和使用[]追加一个范围。
  • 偏移量的修饰符：offset的修饰符查询过去的数据，也就是说可双选择相对于当前时间的多长时间以前
  • 子查询【省，道理类似于mysql中】
    （4）PromQL操作符【省】
  • 向量匹配：有one-to-one、many-to-one、one-to-many【其实就类似于mysql的左右外连接】
    （5）PromQL函数
  • lable_join()和label_replace()这些函数用于操作标签——他们允许您将标签连接到其他标签，提取标签值的一部分，甚至删除标签（尽管使用标准的聚合操作更容易、更符合人体工程学）。在这两个函数中，如果定义的目标标签是一个新的，它将被添加到标签集；如果他是一个现有的标签，它将被取代。【也就是说，如果该语句满足什么条件的话，机会产生相对应的结果】
  • predict_linear（）函数可以预测时间序列v在t秒后的值，它基于简单线性回归的方式，对时间窗口内的样本数据进行统计，从而可以对时间序列的变化趋势作出预测。该函数的返回结果不带有度量指标，只有标签列表。
  • rate()和irate()函数：
  • sort()和sort_desc()

12. 计算CPU的使用率

//例子：
avg(irate(node_cpu_seconds_total{job="node"}[5m] by (instance) * 100))

13. 计算CPU负载(饱和度)

在主机上获得CPU饱和的一种方法是跟踪平均负载，实际上它是将主机上的CPU数量考虑在内的一段时间内的平均运行队列长度。平均负载少于CPU的数量通常是正常的，长时间内超过该数字的平均值则表示CPU已经饱和。

  • 要查看主机的平均负载，可以使用node_load*指标，他们显示1分钟、5分钟和15分钟的平均负载。比如使用1分钟的平均负载：node_load1
//计算主机上的CPU数量，可以使用count聚合实现
count by (instance)(node_cpu_seconds_total{mode="idle"})
//接下来将此计算与node_load指标结合起来
node_load1 > on (instance) 2 * count by (instance)(node_cpu_seconds_total{mode="idle"})
//这里我们查询的是1分钟的负载超过主机CPU数量的两倍的结果

14. 计算内存使用率

Node Exporter的内存指标按内存的类型和使用率进行细分。可以在node_memory为前缀的指标列表找到他们。

//查看主机上的总内存
node_memory_MemTotal_bytes
//主机上的可用内存
node_memory_MemFree_bytes
//缓冲缓存中的内存
node_memory_Buffers_bytes
//页面缓存中的内存
node_memory_Cached_bytes
//通过以上的就可以计算出内存使用率
（总内存-可用内存-缓冲缓存中的内存-页面缓冲中的内存）/总内存 * 100

15. 计算内存饱和度

还可以通过检查内存和磁盘的读写来监控内存饱和度，可以使用从/proc/vmstat收集的两个Node Exporter指标

  • node_vmstat_pswpin：系统每秒从磁盘读到内存的字节数
  • node_vmstat_pswpout：系统每秒从内存写到磁盘的字节数
  • 两者都是自上次启动以来的字节数，以KB为单位
  • 为了获得饱和度指标，对每个指标计算每一分钟的速率，将两个速率相加，然后乘以1024获得字节数
1024 * sum by (instance) ((rate(node_vmstat_pgpgin[1m]) + rate(node_vmstat_pgpgout[1m])))
  • 然后，可以对此设置图形化展示或者警报，以识别行为不当的应用程序主机。

16. 磁盘使用率

对于磁盘，只测量磁盘使用情况而不是使用率、饱和或错误。这是因为在大多数情况下，它是对可视化和警报最有用的数据。

//node_filesystem_size_bytes指标显示了被监控的每个文件系统挂载的大小。
node_filesystem_size_bytes
  • 可以使用与内存指标类似的查询来生成在主机上使用的磁盘空间百分比
(node_filesystem_size_bytes{mountpoint="/"} - node_filesystem_free_bytes{mountpoint="/"}) / node_filesystem_size_bytes{mountpoint="/"} * 100
  • 与内存指标不同，在每个主机上的每个挂载点都有文件系统指标。所以添加了mountpoint标签，特别是跟文件系统"/"挂载。这将在每台主机上返回该文件系统磁盘使用指标
  • 如果想要或需要监控特定挂载点，那么我们可以为其添加查询。比如要监控/data挂载点，可以使用
(node_filesystem_size_bytes{mountpoint="/data"} - node_filesystem_free_bytes{mountpoint="/data"}) / node_filesystem_size_bytes{mountpoint="/data"} * 100
  • 或者可以使用正则表达式匹配多个挂载点
(node_filesystem_size_bytes{mountpoint="/|/run"} - node_filesystem_free_bytes{mountpoint="/|/run"}) / node_filesystem_size_bytes{mountpoint="/|/run"} * 100
  • 可以使用predict_linear函数来构建在未来什么时候会耗尽磁盘空间
//预测四小时之后磁盘空间会不会爆满
predict_linear(node_filesystem_free_bytes{mountpoint="/"}[1h], 4* 3600) < 0
  • 上面是指定跟文件系统，还可以通过制定作业名称或使用正则表达式来选择所有文件系统
predict_linear(node_filesystem_free_bytes{job="node"}[1h], 4* 3600) < 0

17. 服务状态

systemd收集器的数据，它向我们展示了主机上的服务状态和其他各种systemd配置。服务的状态在node_systemd_unit_state指标中暴露出来。对于收集的每个服务和服务状态都有一个指标。

//查询docker的服务
node_systemd_unit_state{name="docker.service"}
//此查询为每个潜在的服务和状态（failed、inactive、active）的组合生成指标，其中表示当前服务状态的指标的值为1，我们可以通过state标签来进一步缩小搜索范围
node_systemd_unit_state{name="docker.service",state="active"}
//或者可以搜索值为1的所有指标，这将返回当前服务的状态
node_systemd_unit_state{name="docker.service"} == 1

18. up指标

用于监控特定节点状态的另一个有用指标，对于每个实例抓取，Prometheus都会在以下时间序列中存储样本

//如果是健康的，则指标设置为1，即数据抓取成功返回，如果抓取失败，则设置为0，指标使用作业名称job和时间序列的实例instance来进行标记
up{job="<job-name>",instance="<instance-id>"}

19. metadata指标

使用Node Exporter的textfile收集器来查看我们创建的metadata指标

metadata{role="docker_server",datacenter="SH"} 1

20. 向量匹配

可以使用metadata指标来进行向量匹配，向量匹配可以使用任何的PromQL二次运算符。向量匹配尝试针对左侧向量中的每个元素在右侧向量中查找对应的匹配元素。

  • 一对一、多对一、一对多

21. 查询持久化

可以通过以下三种方式使查询持久化
（1）记录规则：根据查询创建新指标
（2）警报规则：从查询生成警报
（3）可视化规则：使用Grafana等仪表板可视化查询
之前的查询都可以交替应用这三种机制，因此所有这些机制都能理解和执行PromQL查询

  • 记录规则：一种根据已有时间序列计算新时间序列（特别是聚合时间序列）的方法
    （1）跨多个时间序列生成聚合
    （2）预先计算消耗大的查询
    （3）产生可用于生成警报的时间序列
  • 配置记录规则：记录规则存储在Prometheus服务器上，位于Prometheus服务器加载的文件中，规则是自动计算的，频率则由prometheus.yml配置文件中的evaluation_interval参数控制

22. 服务发现

对于指定的每个目标，在抓取配置中手动列出了他们的IP地址和端口。这种方法在主机较少时还行，但不适用于规模较大的集群，尤其不适用于使用容器和给予云的实例的动态集群，这些实例经常会出现变化、创建或销毁的情况。

  • Prometheus通过使用服务发现解决了这个问题：通过自动化的机制来检测、分类和识别新的变更的目标。服务发现可以通过以下几种机制实现：
    （1）从配置管理工具生成的文件中接收目标列表
    （2）查询API以获取目标列表
    （3）使用DNS记录以返回目标列表
  • 基于文件的服务发现：这些文件可以是YAML或JSON格式，包含定义的目标列表，就像我们在静态配置中定义的一样。让我们将现有作业迁移到基于文件的服务发现开始。refresh_interval
  • 基于API的服务发现：原生的服务发现集成在某些工具和平台上提供，他们内置支持Prometheus，这些服务发现插件使用工具和现有的数据存储或API来返回目标列表。当前可用的本机服务发现插件包括的平台有（Amazon、Azure、Consul、Googe Compute Cloud、kubernetes）。监控K8s上运行的应用程序会用到K8s服务发现
  • 基于DNS的服务发现：DNS服务发现允许你制定DNS条目列表，然后查询这些条目中的记录以发现目标列表。它依赖于A、AAAA或SRV DNS记录查询。dns_sd_configs

23. 警报的管理

Prometheus是一个按功能划分的平台，指标的收集和存储与警报是分开的。警报管理功能由名为Alertmanager的工具提供，该工具是监控体系中的独立组件。我们需要用Prometheus定义警报规则——触发事件——传播到Alertmanager——处理相应的警报——发送给对应的负责人员进行处理（钉钉、微信、邮件）

24 alertmanager集群部署【省】

25 alertmanager基本配置【省】

26 Prometheus与Alertmanager的集成

  1. 静态配置：
  • 需要告诉prometheus关于Alertmanager的信息，如果使用的默认prometheus.yml的配置【具体的配置项省】
  1. 服务发现：
  • 由于我们可以使用服务发现机制，因此也可以使用这些机制来识别一个或多个AlertManager。我们可以添加一条DNS SRV记录，让Prometheus发现Alertmanager

27 添加警报规则

  • 警报规则在Prometheus服务器配置中加载的规则文件，也是使用yaml语句定义
  • 警报触发：Prometheus以一个固定时间间隔来评估所有规则，这个时间由evaluate_interval定义，我们将其设置为5秒，在每个评估周期，Prometheus运行每个警报规则中定义的表达式并更新报警状态。
  • 警报可能有以下三种状态：
  1. Inactive：警报未激活
  2. Pending：警报已满足测试表达式条件，但仍在等待for字句中指定的持续时间
  3. Firing：警报已满足测试表达式条件，并且Pending的时间已超过for子句的持续时间
  • Pending到Firing的转换可以确保警报更有效，且不会来回浮动，没有for子句的警报会自动从Inactive转换为Firing，只需要一个评估周期即可触发，带有for子句的警报将首先转换为Pending，然后转换为Firing，因此至少需要两个评估周期才能触发。
  • 警报的生命周期如下：
  1. 节点的CPU不断变化，每隔一段时间由scrape_interval定义的时间被Prometheus抓取一次
  2. 根据每个evaluation_interval的指标来评估警报规则
  3. 当警报表达式为true时（比如CPU超过80%），会创建一个警报并转换为Pending状态，执行for子句
  4. 在下一个评估周期中，如果警报测试表达式仍然为true，则检查for的持续时间，如果超过持续的时间，则警报将转换为Firing，生成通知并将其推送到Alertmanager
  5. 如果警报测试表达式不再为true，则Prometheus会将警报规则的状态从Pending更改为Inactive

28 alertmanager的路由定义

  • 我们选择了一些具有不同属性的警报，需要将他们路由到不同的目的地。

29 接收器（发送方式）和通知模版【省】

30 警报的静音

  • 通常我们需要让警报系统知道我们已经停止服务以进行维护，并且不希望触发警报。或者，当上游出现问题时，我们需要将下游服务器和应用程序“静音”。Prometheus称这种警报静音为silence。silence可以设定为特定时期
  • 可以使用以下两种方式来设置silence：
  1. 通过Alertmanager Web控制台
  2. 通过amtool命令行工具

31 Prometheus的可靠性、容错性和可扩展性

  • Prometheus解决容错问题的方法考虑到了操作和技术的复杂性。在多数情况下，监控服务的容错性可以通过使监控服务高可用来解决。通常的实现方式是构建集群。但是，集群解决方案需要相对复杂的网络，并且需要解决集群中节点之间的状态管理问题。
  • Prometheus专注于实时监控，通常会保留一段时间内的数据，并且我们假设配置是由配置管理工具管理的。从可用性的角度来看，单个Prometheus服务器通常被认为是不可靠的。Prometheus架构认为，实现集群所需的投入以及维护集群节点之间数据一致性的成本要高于数据本身的价值。
  • 但是Prometheus并没有忽视解决容错问题的必要性，实际上，Prometheus推荐的容错解决方案是并行运行两个配置相同的Prometheus服务器，并且这两个服务器同时处于活动状态，该配置生成的重复警报交由上游Alertmanager使用其分组（及抑制）功能进行处理。一个推荐的方法是尽可能使上有Alertmanager高度容错，而不是关注Prometheus服务的容错能力
  • Prometheus环境扩展通常有两种方式：水平扩展或功能扩展
  1. 功能扩展
  • 功能扩展使用分片奖监控内容分布到不同的Prometheus服务器上（例如通过地理位置或者逻辑域来进行拆分服务），或者可以通过特定功能，将所有基础设施加浓发送到一台服务器，而将所有应用程序监控发送到另一台服务器
  • 如果需要对某些区域或功能进行整体视图查看，你可以使用联合功能，将时间序列提取到集中的Prometheus服务器。Grafana支持从多个Prometheus服务器提取数据构建图形，这可能对你没有帮助，他允许在可视化级别联合来自多个服务器的数据，前提是收集的时间序列具有一定的一致性
  1. 水平扩展
  • 通常在大规模部署中，垂直分片的容器和复杂性将会出现问题，当单个作业包含数千个实例时尤其如此。这种情况下，你可以考虑另外一种方案：水平分片。水平分片使用一系列工作节点（worker），每个节点都抓取一部分目标，然后，我们在工作节点上汇总感兴趣的特定时间序列。
  • 我们的主节点不仅可以提取聚合指标，还可以为Grafana等工具暴露指标或者作为可视化的默认数据源。如果需要更深入或者进一步扩展，则可以添加分层的主节点或工作节点。一个很好的例子是基于区域的主节点和工作节点，可能是故障域或者像AWS可用区这样的逻辑区域，将给予区域的主节点视为全局的工作节点，然后想全局的主节点进行报告。
  • 需要注意的是，这种扩展方式存在风险和限制，最显而易见的是，你需要从工作节点中抓取一部分指标。而不是大量货正在收集的所有指标，这是一个类似金字塔的层级结构，而不是分布式的层级结构。此外，你还需要考虑主节点对工作阶段的抓取请求负载。
  • 接下来，你会在你的环境中创建复杂的Prometheus服务器层级结构，还需要担心主节点与工作节点之间的连接，而不仅仅是工作节点与目标之间的连接，这可能会降低解决方案的可靠性。
  • 最后，数据的一致性和正确性也可能会降低，工作节点正在根据设定的间隔抓取目标，而你的主节点也要抓取工作节点。这会导致到达主节点的结果出现延迟，并可能导致数据倾斜或警报延迟
  • 这两个问题的后果是，在主节点上集中警报可能不是一个好主意，相反，应该将警报推送到工作节点上，在哪里更有可能识别出问题，或减少识别鸡公煲条件和处罚静吧之间的滞后。
  • 配置【省略】

32 mtail的部署与使用

  • 是一个非常轻的日志处理器，它能够运行具有模式匹配逻辑的程序，允许从所述提取指标。他支持多种导出格式，如Prometheus、StatsD、Graphites等

33 blackbox的部署和使用

  • 内省对于收集关于系统的数据是非常宝贵的，但是有时我们需要从系统用户的角度进行度量。在这种情况下，探测是模拟用户交互的一个很好的选择。由于探测是在外部进行的，并且不了解系统内部的工作情况，因此将其归类为黑盒监视
  • blackbox_exporters是普逻辑休斯生态系统中所有现有出口最奇特的一家。他的使用模式是巧妙的
  • blackbox_exporter服务暴露两个主要的端点
  1. /metrics：暴露自己的度量
  2. /probe：正是查询断电启用了blockbox探测，以Prometheus呈示格式返回他们的结果
  • 除了前面的两个端点之外，服务还提供了有价值的信息，包括执行探测的日志。
  • blackbox导出器支持通过各种各样的本地协议探测端点，比如TCP、ICMP、DNS、HTTP，以及大多数探测上的TLS。此外，他还支持脚本的机遇文本的协议，如IRC、IMAP或AMTP，通过TCP连接并配置应该发送哪些消息和需要哪些响应；即使是普通的HTTP也可以编写脚本，但是由于HTTP探测是如此常见的用例，他已经内置了。
  • 尽管如此，这个出口商并不能满足所有blackbox类型的监视需求，对于这些情况，可能需要编写自己的出口商。例如你不能使用blackbox_exportes来从头到尾测试一个Kafka主题，所以你可能需要寻找一个能够生成一条消息给Kafka并将其消费掉的出口商

34 Pushgateway部署和使用

  • 尽管普罗米修斯服务器的设计中存在关于推和拉的激烈争论，以及使用拉的慎重决定，但是在一些合法的情况下，推更合适
  • pushgateway：这个导出程序应该只在非常特定的用例中使用。例如，我们应该注意一些常见的陷阱，一个可能的问题是缺乏高可用性，使其成为单点故障。这也会影响可伸缩性，因此容纳更多度量/客户端的唯一方法是垂直伸缩实例（添加更多资源）或分片（为不同的逻辑组拥有不同的Pushgateway实例）。通过使用pushgateway，Prometheus不会直接获取应用程序实例，这就防止了up指标成为健康状况的代理。
  • 要推送一个度量，您需要使用以下URL路径定义向Pushgateway端点发送一个HTTP POST请求。
http://<pushgateway_address>:
<push_port>/metrics/job/<job_name>/[<label_name1>/<label_value1>]
上述,<job_name>将成为被推送的指标的标签作业的值，而<label_name>/<label_value>对将成为额外的标签/值对，请记住，在手动删除之前，或者在没有配置持久性的情况下重启之前，指标都是可用的
  • pushgateway使用详情【省】

35 promtool工具的使用【省】

36 logs和endpoint的校验

  • endpoints：检查prometheus是否启动并运行通常非常简单，因为它遵循了大多数云本地应用程序用于服务健康状况的惯例：一个端点检查服务是否健康，另一个端点检查服务是否准备好开始处理传入的请求。实际上，Kubernetes还使用了这些约定来评估是否需要重新启动容器（例如，如果应用程序死锁并停止响应健康状况探测），以及是否可以开始向容器发送流量
  • logs：通过 --log.level选项来设置日志级别

37 k8s部署prometheus和alertmanager【省】

38 k8s部署nodeExporter【省】

39 监控k8s本身

  • 有很多种方法可以监控kubernetes本身，其中包括凯源kubernetes生态系统中的工具，如Heapster和Kube-state-metrics，以及其他商业化和给予SaaS的工具。因为Heapster已经过时了，所以可以采用Kube-state-metrics来进行监控

40 kube-prometheus部署

  • prometheus operator：他抽取了kubernetes应用的打包、部署和管理复杂性。操作员综合应用程序的操作所需的知识（如配置和部署逻辑）Kubernetes定义资源和自定义控制器。除了管理部署（包括Prometheus服务器的pod数量和持久卷）之外，普罗米修斯操作员还将使用ServiceMonitor的概念动态更新配置，该概念针对服务使用与运行容器的标签相匹配的规则

41 k8s中服务的监控

告警通知（邮件、微信、钉钉）

  • 非kube-prometheus中的配置

42 matelLB部署

  • Layer 2 mode（ARP/NDP）
  1. 在这种模式下，服务由集群中的一个节点拥有，他是通过两层地址实现的，与外部IP匹配的是节点的mac地址，对于外部设备，节点有多个IP地址
  • 架构
  1. 在两层的MetalLB运行两个组件及账户：
  • 集群级的控制器：这是在集群范围内处理IP地址分配的控制器
  • Speaker daemonset：Speaker必须安装在集群中的每个节点上，是服务可访问的协议的组件。他通告两层地址。
  • 针对controller和speaker运行的服务账户，还有组件运行所需的权限

43 ingress-controller(nginx)部署【省】

44 kube-controlelr监控控制器

45 kube-scheduler（k8s调度器）监控

46 kube-proxy监控【省】

47 Grafana

  1. Prometheus有一个内置的仪表板和图形界面。通常适合查看指标和呈现单个图表。为了给prometheus添加一个功能更全面的可视化界面，可以选择与开源的grafana进行集成。Grafana接受来自不同数据源的数据，然后提供可视化仪表板。它支持多种数据源，例如Grapgite、ElasticSearch和Prometheus。值得注意的是，Prometheus通常不同于长期数据保留，默认保存15天的时间序列化数据。这意味着Prometheus更专注于监控问题。而不是其他可视化和仪表板系统。针对Prometheus时间序列数据的处理，更加实用的方式是使用表达式浏览器、绘制Prometheus UI内置图形以及构建适当的警报，而不是构建大量仪表板。
  2. 可视化操作

五：服务端开发过程中常用到的Linux命令

  • top: 查看整个系统资源使用情况
  • free -m 查看内存使用情况
  • iostat 查看磁盘读写活动情况
  • netstat 查看网络连接情况
  • df -h 查看磁盘空间使用情况
  • du -sh 查看文件大小情况（也可以用ll命令）
  • pwd：查看自己所在路径
  • cat：查看文件内容
  • more：分段查看文件内容
  • tail：从尾部查看文件内容
  • head：从头开始查看文件内容
  • ps：查看进程快照信息
  • grep：对内容进行过滤筛选
  • touch/vi/vim：创建文件
  • locate、find：查找文件所在目录