prometheus基本使用

参考链接：
https://www.prometheus.wang/
作者总结的很好，大家都可以跟着学习看看

DevOps监控理念
devops基本理念：

if you can’t measure it, you can’t improve it
you build it,you run it, you monitor it. 谁开发，谁运维，谁监控
四种主要的监控方式

Logging
Tracing
Metric
Healthchecks
监控是分层次的，以metric 为例

系统层，比如cpu、内存监控，面向运维人员
应用层，应用出错、请求延迟等，业务开发、框架开发人员
业务层，比如下了多少订单等，业务开发人员
监控的目标
在《SRE: Google运维解密》一书中指出，监控系统需要能够有效的支持白盒监控和黑盒监控。

通过白盒能够了解其内部的实际运行状态，通过对监控指标的观察能够预判可能出现的问题，从而对潜在的不确定因素进行优化。

而黑盒监控，常见的如HTTP探针，TCP探针等，可以在系统或者服务在发生故障时能够快速通知相关的人员进行处理。

通过建立完善的监控体系，从而达到以下目的：

长期趋势分析：通过对监控样本数据的持续收集和统计，对监控指标进行长期趋势分析。例如，通过对磁盘空间增长率的判断，我们可以提前预测在未来什么时间节点上需要对资源进行扩容。
对照分析：两个版本的系统运行资源使用情况的差异如何？在不同容量情况下系统的并发和负载变化如何？通过监控能够方便的对系统进行跟踪和比较。
告警：当系统出现或者即将出现故障时，监控系统需要迅速反应并通知管理员，从而能够对问题进行快速的处理或者提前预防问题的发生，避免出现对业务的影响。
故障分析与定位：当问题发生后，需要对问题进行调查和处理。通过对不同监控监控以及历史数据的分析，能够找到并解决根源问题。
数据可视化：通过可视化仪表盘能够直接获取系统的运行状态、资源使用情况、以及服务运行状态等直观的信息。
可观测性
指标监控

通常使用折线图形态呈现在图表上，比如某个机器的 CPU 利用率、某个数据库实例的流量或者网站的在线人数，都可以体现为随着时间而变化的趋势图。

指标监控只能处理数字，但它的历史数据存储成本较低，实时性好，生态庞大，是可观测性领域里最重要的一根支柱。

日志

从日志中可以得到很多信息，对于了解软件的运行情况、业务的运营情况都很关键。比如操作系统的日志、接入层的日志、服务运行日志，都是重要的数据源。

处理日志这个场景，也有很多专门的系统，比如开源产品 ELK 和 Loki，商业产品 Splunk 和 Datadog

链路追踪

服务之间有错综复杂的调用关系，一个问题具体是哪个模块导致的，排查起来其实非常困难。链路追踪的思路是以请求串联上下游模块，为每个请求生成一个随机字符串作为请求 ID。服务之间互相调用的时候，把这个 ID 逐层往下传递，每层分别耗费了多长时间，是否正常处理，都可以收集起来附到这个请求 ID 上。后面追查问题时，拿着请求 ID 就可以把串联的所有信息提取出来。链路追踪这个领域也有很多产品，比如 Skywalking、Jaeger、Zipkin 等，都是个中翘楚。

监控的几个反模式
事后监控，没有把监控作为系统的核心功能

机械式监控，比如只监控cpu、内存等，程序出事了没报警。只监控http status=200，这样数据出错了也没有报警。

不够准确的监控

静态阈值，静态阈值几乎总是错误的，如果主机的CPU使用率超过80%就发出警报。这种检查通常是不灵活的布尔逻辑或者一段时间内的静态阈值，它们通常会匹配特定的结果或范围.

这种模式没有考虑到大多数复杂系统的动态性。为了更好地监控，我们需要查看数据窗口，而不是静态的时间点。

不频繁的监控

缺少自动化或自服务

一个良好的监控系统应该能提供全局视角，从最高层（业务）依次（到os）展开。同时它应该是：内置于应用程序设计、开发和部署的生命周期中。

很多团队都是按部就班的搭建监控系统：一个常见的例子是监控每台主机上的 CPU、内存和磁盘，但不监控可以指示主机上应用程序是否正常运行的关键服务。

如果应用程序在你没有注意到的情况下发生故障，那么即使进行了监控，你也需要重新考虑正在监控的内容是否合理。

根据服务价值设计自上而下（业务逻辑 ==> 应用程序 ==> 操作系统）的监控系统是一个很好的方式，这会帮助明确应用程序中更有价值的部分，并优先监控这些内容，再从技术堆栈中依次向下推进。

从业务逻辑和业务输出开始，向下到应用程序逻辑，最后到基础设施。这并不意味着你不需要收集基础设施或操作系统指标——它们在诊断和容量规划中很有帮助——但你不太可能使用这些来报告应用程序的价值。

如果无法从业务指标开始，则可试着从靠近用户侧的地方开始监控。因为他们才是最终的客户，他们的体验是推动业务发展的动力。

PS：只要业务没事，底层os一定没事，底层os没事，业务逻辑不一定没事，监控要尽量能够反应用户的体验。

在应用程序中，通常会记录日志以便事后分析，在很多情况下是产生了问题之后，再去查看日志是一种事后的静态分析。

在很多时候，我们可能需要了解整个系统在当前，或者某一时刻运行的情况。比如：

每秒钟的请求数是多少（TPS）？

请求处理的最长耗时？

请求处理正确响应率？

以及系统运行出错率等等一系列的实时数据。通过 Metrics 监控这些指标的度量，可以来告诉我们应用是否健康。

metric 种类
Metrics，谷歌翻译就是度量的意思。当我们需要为某个系统某个服务做监控、做统计，就需要用到Metrics。

举个栗子，一个图片压缩服务：

每秒钟的请求数是多少（TPS）？
平均每个请求处理的时间？
请求处理的最长耗时？
等待处理的请求队列长度？
又或者一个缓存服务：

缓存的命中率？
平均查询缓存的时间？
Prometheus 中的 metric 种类：

gauge （测量仪/计量器），当期值的一次快照测量，可增可减。比如磁盘使用率、当前同时在线用户数。
它可以表示一个既可以增加, 又可以减少的度量指标值。
它是最简单和最基本的Metrics类型，只有一个简单的返回值，通常用来记录一些对象或者事物的瞬时值。
典型的应用场景：温度，内存使用量
counter（计数器）它是一种累计型的度量指标，数值只能单调递增。
计数器的典型应用场景： http 请求数、下单数，任务完成次数，错误出现次数。
Histogram（直方图），通过分桶方式统计样本分布
Histrogram可以计算最大/小值、平均值，方差，分位数（如中位数，或者95th分位数），如75%,90%,98%,99%的数据在哪个范围内。
直方图的典型使用场景包括：流量最大值，流量最小值，流量平均值等
counter（计数器），始终增加，比如 http 请求数、下单数
gauge（测量仪/计量器），当期值的一次快照测量，可增可减。比如磁盘使用率、当前同时在线用户数
Histogram（直方图），通过分桶方式统计样本分布
Summary（汇总），根据样本统计出百分位，比如客户端计算
4个黄金指标可以在服务级别帮助衡量终端用户体验、服务中断、业务影响等层面的问题。

延迟：服务请求所需时间。
通讯量：监控当前系统的流量，用于衡量服务的容量需求。例如，在HTTP REST API中, 流量通常是每秒HTTP请求数；
错误：监控当前系统所有发生的错误请求，衡量当前系统错误发生的速率。
饱和度：衡量当前服务的饱和度。比如，“磁盘是否可能在4个小时候就满了”。
这四个指标并不是唯一的系统性能或状况的衡量标准，系统可以简单分为两类

资源提供系统 - 对外提供简单的资源，比如CPU（计算资源），存储，网络带宽。针对资源提供型系统，有一个更简单直观的USE标准
Utilization - 往往体现为资源使用的百分比
Saturation - 资源使用的饱和度或过载程度，过载的系统往往意味着系统需要辅助的排队系统完成相关任务。这个和上面的Utilization指标有一定的关系但衡量的是不同的状况，以CPU为例，Utilization往往是CPU的使用百分比而Saturation则是当前等待调度CPU的县城或进程队列长度
Errors - 这个可能是使用资源的出错率或出错数量，比如网络的丢包率或误码率等等
服务提供系统 - 对外提供更高层次与业务相关的任务处理能力，比如订票，购物等等。针对服务型系统，则往往用RED方式进行衡量
Rate - 单位时间内完成服务请求的能力
Errors - 错误率或错误数量：单位时间内服务出错的比列或数量
Duration - 平均单次服务的持续时长（或用户得到服务响应的时延）
Prometheus 提供的许多exporter 或者直接提供上述metric，或者通过计算可以得到上述metric。或者反过来说，这些原则指导了exporter 去暴露哪些metric。

prometheus的由来

受启发与google的brogmon监控系统，从2012年开始由前Google工程师在Soundcloud以开源软件的形式进行研发，并且于2015年早期对外发布早期版本。2016年5月继Kubernetes之后成为第二个正式加入CNCF基金会的项目，同年6月正式发布1.0版本。2017年底发布了基于全新存储层的2.0版本，能更好地与容器平台、云平台配合。

监控的目标

监控系统需要能够有效的支持白盒监控和黑盒监控。

白盒监控

通过白盒能够了解其内部的实际运行状态，通过对监控指标的观察能够预判可能出现的问题，

黑盒监控

创建的如HTTP探针，TCP探针等，可以在系统或者服务在发生故障时能够快速通过相关的人员进行处理。通过建立完善的监控体系，从而达到以下目的

长期趋势分析
对照分析
告警
故障分析与定位
数据可视化

与常见监控系统比较

优势：易于管理，监控服务的内部运行状态，强大的数据模型，强大的查询语言 PromQL，高效，可扩展，易于集成，可视化，开放性

安装Prometheus Server

软件下载地址

https://prometheus.io/download/

docker安装

docker run -p 9090:9090 -v /etc/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus

默认的配置文件

promethes.yml:

# my global config 全局配置
global:
  # 拉取时间间隔 设置为每15秒一次。默认是每1分钟一次。
  scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  # 每15秒评估一次规则。默认为每1分钟一次
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
  # 拉取超时时间 设置为全局默认值(10秒)。
  # scrape_timeout is set to the global default (10s).

# 告警管理组件配置
# Alertmanager configuration
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      # - alertmanager:9093

# 加载一次规则，并根据全局'evaluation_interval'定期对它们进行评估
# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  # - "first_rules.yml"
  # - "second_rules.yml"

# 一个只包含一个端点的拉取配置:
# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
# 拉取配置
scrape_configs:
  # 作业名称作为标签' job=<job_name> '添加到从该配置中抓取的任何时间序列中。
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
  - job_name: 'prometheus'

    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.

    static_configs:
    - targets: ['localhost:9090']

安装Node Exporter

node exporter简介

在Prometheus的架构设计中，Prometheus Server并不直接服务监控特定的目标，其主要任务负责数据的收集，存储并且对外提供数据查询支持。因此为了能够能够监控到某些东西，如主机的CPU使用率，我们需要使用到Exporter。Prometheus周期性的从Exporter暴露的HTTP服务地址（通常是/metrics）拉取监控样本数据。

从上面的描述中可以看出Exporter可以是一个相对开放的概念，其可以是一个独立运行的程序独立于监控目标以外，也可以是直接内置在监控目标中。只要能够向Prometheus提供标准格式的监控样本数据即可。

这里为了能够采集到主机的运行指标如CPU, 内存，磁盘等信息。我们可以使用Node Exporter。

下载参考上面的prometheus二进制下载链接

解压完成后，直接启动即可
./node_exporter

配置prometheus从node exporter拉取监控数据

编辑prometheus.yml并在scrape_configs节点下添加以下内容:

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']
  # 采集node exporter监控数据
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']

重新启动Prometheus Server

访问http://localhost:9090，进入到Prometheus Server。如果输入“up”并且点击执行按钮以后，可以看到如下结果：

up{instance="localhost:9090",job="prometheus"}    1
up{instance="localhost:9100",job="node"}    1

其中“1”表示正常，反之“0”则为异常。

监控数据可视化

使用grafana创建可视化Dashboard

docker run -d -p 3000:3000 grafana/grafana

选择数据源可就可以看到prometheus的数据了。

posted @ 2024-01-25 10:53 jasmine456 阅读(46) 评论(0) 编辑收藏举报

刷新页面返回顶部