《Prometheus监控实战》读书笔记

最新推荐文章于 2024-08-13 16:44:01 发布

johnny233

最新推荐文章于 2024-08-13 16:44:01 发布

阅读量106

点赞数

分类专栏：监控文章标签： prometheus

本文链接：https://blog.csdn.net/lonelymanontheway/article/details/126662503

版权

监控专栏收录该内容

4 篇文章 0 订阅

订阅专栏

监控简介

Google服务层次结构图，监控是底座
在这里插入图片描述
一些监控反模式：

事后监控
机械式监控
不（够）准确的监控
静态监控：不是说超过某个绝对阈值系统就一定出现问题，更有意义的监控是对比（环比）动态监控。数据库性能分析供应商VividCortex的首席执行官Baron Schwartz对此评论道[插图]：它们比一个停摆的时钟更糟糕，至少时钟每天还会有两次准的时候
不频繁的监控
不能自动化或自服务的监控

应尽可能使监控系统的实施和部署自动化：

应该由配置管理进行部署
主机和服务的配置应该通过自动发现或自助提交来进行，这样可以自动监控新的应用程序，而不需要人为添加
添加检测应该很简单，并且是基于插件模式，开发人员应该能够把它放置到库中，而不必自己配置它
数据和可视化应该是自服务的。每个需要查看监控输出的人都应该能够查询和可视化这些内容

一个良好的监控系统应该能提供以下内容：

全局视角，从最高层（业务）依次展开
协助故障诊断
作为基础设施、应用程序开发和业务人员的信息源
内置于应用程序设计、开发和部署的生命周期中
尽可能自动化，并提供自服务

有两类方法：探针（probing）和内省（introspection）
有两种方式：拉取（pull）和推送（push）
监控数据有两种形式：指标和日志

指标类型：

测量型Gauge
计数型Counter
直方图Histogram

监控方法论

Prometheus简介

大多数监控查询和警报都是从最近的（通常是一天内的）数据中生成的。

可以通过多种方式来处理要监控的资源的发现：

用户提供的静态资源列表
基于文件的发现
自动发现，查询Consul等服务注册中心进而知道需要监控哪些服务

安装和启动Prometheus

官方提供的校验工具promtool，用于。

Windows平台安装Prometheus，双击prometheus.exe即可，如果要作为服务运行，可通过NSSM（Non-Sucking Service Manager）工具来实现。还可以Chocolatey包管理器，类似于Yum，APT。

除了各大操作平台安装方式外，也可用配置管理工具来安装：Puppet、Chef、Ansible、SaltStack

监控主机和容器

服务发现

警报管理

可靠性和可扩展性

搭建Prometheus监控平台是为了监控业务系统，保证业务系统高可用和稳定性。那Prometheus自身的可靠性如何保证呢？

官方推荐的容错解决方案是并行运行两个配置相同且同时处于活动（standby）状态的Prometheus服务器，两个服务器生成的重复警报可以交由上游Alertmanager使用其分组（及抑制）功能进行处理。

监控应用程序

实用程序模式：一个metrics-utility类，它不需要实例化，只包含静态方法。

监控日志

使用Process exporter查看/proc子系统的内容。

日志处理工具有很多，如Grok Exporter和mtail。

mtail

Google开源的基于Go语言的日志处理器，使用RE2正则表达式，

运行：
sudo mtail --progs /etc/mtail --logs '/var/log/*.log'
--progs告诉mtail在哪里找到程序，--logs告诉mtail在哪里找到要解析的日志文件。

使用glob模式来匹配/var/log目录中的所有日志文件。你可以指定以逗号分隔的文件列表，也可以多次指定--logs参数。mtail会识别到日志文件被截断，因此它可以处理停止、重新启动和日志轮换等操作。

在端口3903上启动Web服务器（可以使用--address和--port参数来设置IP地址和端口）。

mtail输出指标的不同形式：JSON、varz（Google内部用于指标收集的格式）以及我们想要的格式Prometheus。

运行mtail的用户需要针对正在解析的日志文件的权限，否则mtail将无法读取文件。当无法读取文件时，你将在使用--logtostderr参数获得的mtail日志输出中看到读取错误。

探针监控

监控探针有三个约束：

它们需要能够访问到被探测的资源。
探针需要放置在可以测试资源的正确位置上。
探针exporter的位置能够被Prometheus服务器抓取。

Blackbox exporter是Prometheus官方提供的Go语言组件，可通过HTTP、HTTPS、DNS、TCP和ICMP来探测端点，执行检查并将生成的指标返回给Prometheus。

因为基于Go语法开发，安装很简单，也支持各大系统平台，也能使用配置管理工具安装。默认端口是9115，启动成功后，可浏览器打开

配置文件prober.yml，使用模块来定义各种检查，每个模块都有一个名称和一个特定的探针。示例：

modules:
  http_2xx_check:
  	prober: http
  	timeout: 5s
  	http:
  	  valid_status_codes: ['200', '204']
  	  method: GET
  icmp_check:
    prober: icmp
    timeout: 5s
    icmp:
      preferred_ip_protocol: "ip4"
  dns_my_domain_check:
    prober: nds
    dns:
      preferred_ip_protocol: "ip4"
      query_name: "www.my.domain.com"

ICMP需要一些额外的权限。Windows上，需要管理员权限，Linux上需要root或CAP_NET_RAW权限，BSD或OS X上则需要root用户。

DNS检查会向目标发送一个ANY查询类型的请求。

推送指标和Pushgateway

在某些情况下，抓取指标无法实现：

安全性或连接性问题，使你无法访问目标资源。这是一种非常常见的情况，比如服务或应用程序仅允许特定端口或路径访问。
目标资源的生命周期太短，例如容器的启动、执行和停止。在这种情况下，Prometheus作业将会发现目标已完成执行并且不再可以被抓取。
目标资源没有可以抓取的端点，例如批处理作业。批处理作业不太可能具有可被抓取的HTTP服务，即使假设作业运行的时间足够长。

因此需要推送指标，即需要Push。

Pushgateway，简写PG，基于Go语言。默认端口9091，使用--web.listen-address参数来覆盖地址和端口，可浏览器打开http://localhost:9091。默认将所有指标存储在内存中，如果PG停止或重新启动，则将丢失内存中的所有指标，指定--persistence.file参数将指标持久存储于磁盘路径。默认每五分钟持久化写入文件一次，使用--persistence.interval参数指定想要的频率。

PushProx是监控这些不可访问资源的一个工具，旨在抓取通过NAT连接的指标。

监控Kubernetes

kops。

kops创建集群命令：

kops create cluster --node-count 6 --zones zone1,zone2,zone3 --master-zones zone1,zone2,zone3 \
--node-size t2.micro --master-size t2.micro --topology private --networking kopeio-vxlan \
--api-loadbalancer-type=public --bastion www.aaa.com