Prometheus入门

最新推荐文章于 2024-03-07 18:54:20 发布
最新推荐文章于 2024-03-07 18:54:20 发布
阅读量559 收藏 4
点赞数
文章标签： ldap 操作系统 数据库
原文链接：https://my.oschina.net/plutonji/blog/2873389
版权

2019独角兽企业重金招聘Python工程师标准>>> hot3.png

Prometheus入门

本文介绍新一代的监控系统 Prometheus，并指导用户如何一步一步搭建一个 Prometheus 系统。

什么是 Prometheus ？

Prometheus是一套开源的监控与告警框架，由工作在 SoundCloud 的 google 前员工在 2012 年创建，作为社区开源项目进行开发，并于 2015 年正式发布。2016 年， 继 Kubernetes 之后，Prometheus 成为 Cloud Native Computing Foundation 的第二个项目。

Prometheus 的特点

  1. 多维度的时间序列数据模型，以 metric 和键值对加以区分；
  2. 灵活的查询语言；
  3. 部署方便：不依赖分布式存储；可自治的单服务器节点；
  4. 时间序列数据通过HTTP协议以拉取（pull）的方式收集；
  5. 通过中间的网关可以实现时间序列的推送；
  6. 监控目标可以通过服务发现或静态配置；
  7. 支持多种绘图和仪表盘模式

Prometheus 的组件

Prometheus 的生态系统包括多个组件，其中大部分都是可选的：

  1. Prometheus Server，负责抓取、存储时间序列数据；
  2. 客户端库（client library），组合进应用代码；
  3. 推送网关（push gateway），支持“短暂”的任务；
  4. 特殊用途的exporter，支持如 HAProxy，StatsD，Graphite，Redis 一类的服务；
  5. 一个 告警管理器（Alertmanager）来管理告警；
  6. 各种支持工具

大部分 Prometheus 的组件都是用 Go 写的，部署很方便。

Prometheus 的架构

Architecture

从架构图中可以看出其大概的工作流程：

  1. Prometheus Server 以服务发现（如 Kubernetes 等）的方式自动发现或者静态配置添加监控目标；
  2. Prometheus Server 定期从监控目标（Jobs/exporters）或 Pushgateway 中拉取数据（metrics），将时间序列数据保存到其自身的时间序列数据库（TSDB）中；
  3. Prometheus Server 通过 HTTP Server 对外开放接口，可以给可视化工具（如 Prometheus web UI、Grafana 或 你自己开发的工具）用 PromQL 查询/导出数据；
  4. 当有告警产生时，Prometheus Server 将告警信息推送到 Alertmanager ，由 Alertmanager 根据配置的策略发送告警信息到对应的接收方；
  5. Pushgateway 接收 “Short-lived” 类型的 Jobs 推送过来的 metrics 并缓存，等待 Prometheus Server 抓取。

Prometheus 适合做什么？

Prometheus 非常适合记录纯数字的时间序列，既可以是以主机为中心的监控，也可以是以服务为导向的动态架构。在微服务的世界，它支持多维度的数据集合，查询功能非常强大。

Prometheus 是为可用性而设计，利用它你可以快速定位问题。每一个 Prometheus Server 都是独立的，不依赖于网络存储或其他的第三方服务。你可以在部分基础设施出现问题时仍然使用它。

Prometheus 不适合做什么？

Prometheus 用于评估可用性。如果你想要100%的精准度，比如每个请求的账单，Prometheus就不是一个好的选择，因为收集上来的数据可能没这么细致、完整。对于这样的需求，你最好用其他的大数据系统对数据做分析。

Prometheus 相关概念

为了在后面的安装和配置步骤中更好地理解，我们首先需要学习一下 Prometheus 的一些相关概念。

数据模型

Prometheus 以时间序列存储所有的数据：属于相同 metric 名称和相同标签组（键值对）的值以时间顺序形成数据流。

Metric 名称和标签

每一个时间序列都是由其 metric名称和一组标签（键值对）唯一标识。

metric名称 代表了被监控系统的一般特征（比如 http_requests_total，代表接收到的 HTTP 请求总数）。其语法要求符合正则表达式 [a-zA-Z_:][a-zA-Z0-9_:]*。

需要注意的是，冒号 : 一般保留用于用户自定义的记录规则，不应该给 exporter 使用。

标签 给 Prometheus 带来了多维度数据模型：对于相同metric名称，任意的标签组合标识出该 metric 在某特定维度上的实例（比如：所有使用POST方法到/api/tracks接口的HTTP请求）。查询语言可以基于这些维度过滤和聚合数据。变更任何标签值，包括增加和删除标签，都会创造新的时间序列。

标签名称可以包含 ASCII 字符、数字和下划线，其必须符合正则表达式 [a-zA-Z0-9_]*，以双下划线__开头的标签名用于内部使用。

标签的值可以包含 Unicode 字符。

表示法

给定 metric名称和一组标签，我们一般用以下的表示法来表示时间序列：

<metric name>{<label name>=<label value>, ...}

举个例子：一个时间序列的 metric名称是api_http_requests_total，标签是method="POST"和handler="/messages"，那么我们可以这样写：

api_http_requests_total{method="POST", handler="/messages"}

这和 OpenTSDB 的表示法是一样的。

Metric 的类型

Prometheus 的客户端库提供四种 Metric 的类型，这些类型目前只在客户端库和传输协议上做区分。Prometheus server 暂时没有使用这些类型信息，会将数据变成无类型的时间序列。这种情况在未来可能会有所变化。

Counter

Counter 是一种累加的 metric ，代表一个单调函数，其值只能上升或在重启时重置为0。可以用 counter 代表处理的请求数、完成的任务数、出现的错误数量等。

不可以用 counter 代表一个可能会下降的值。比如，不能用 counter 表示正在运行的进程数，而应该用下面我们将提到的 gauge。

Gauge

Gauge 代表一个可以任意增加或减少的 metric 值。

Gauge 一般用来测量如温度、当前的内存使用量这样的值，也用来检测会上升或下降的值，比如 Go 的并发 goroutine 的数量。

Histogram

Histogram 取样观测的结果（一般是请求持续时间或响应大小）并在一个可配置的分布区间（bucket）内计算这些结果。其也提供所有观测结果的总和。

Histogram 有一个基本 metric名称 <basename>，在一次抓取中展现多个时间序列：

  • 累加的 counter，代表观测区间：<basename>_bucket{le="<upper inclusive bound>"}
  • 所有观测值的总数：<basename>_sum
  • 观测到的事件数量：<basenmae>_count

使用 histogram_quantile() 函数计算 histogram 的分位数或者聚合 histogram。Histogram 也适用于计算 Apdex指数。当配置分布区间（bucket）的时候请牢记 histogram 是累加的。

Summary

和 histogram 相似，summary 取样观测的结果（一般是请求持续时间或响应大小）。但是它还提供观测的次数和所有值的总和，它通过一个滑动的时间窗口计算可配置的分位数。

Summary 有一个基本的 metric名称 <basename>，在一次抓取中展现多个时间序列：

  • 观测事件的流式φ-分位数（0 ≤ φ ≤ 1）：<basename>{quantile="φ"}
  • 所有观测值的总和：<basename>_sum
  • 观测的事件数量：<basename>_count

任务（Job）与实例（Instance）

在 Prometheus 中，一个你可以抓取数据的端点叫做实例（instance），一般等价于一个进程。一组有着同样目标的实例（例如为弹性或可用性而复制的进程副本）叫做任务（job）。

自动生成的标签和时间序列

当 Prometheus 抓取目标时，它会自动添加一些标签到时间序列中，用于标识被抓取的目标：

  • job：目标所属的任务名称；
  • instance：目标URL中的<host>:<port>部分；

如果两个标签在被抓取的数据中已经存在，那么就要看配置选项 honor_labels 的值来决定行为了。

每次对实例的抓取， Prometheus 会在以下的时间序列中保存一个样本（样本指的是在一个时间序列中特定时间点的一个值）：

  • up{job="<job-name>", instance="<instance-id>"}：如果实例健康（可达），则为 1 ，否则为 0
  • scrape_duration_seconds{job="<job-name>", instance="<instance-id>"}：抓取的时长
  • scrape_samples_post_metric_relabeling{job="<job-name>", instance="<instance-id>"}：在 metric relabeling 之后，留存的样本数量
  • scrape_samples_scraped{job="<job-name>", instance="<instance-id>"}：目标暴露出的样本数量

up 这个时间序列对于实例的可用性监控来说非常有用。

安装与配置 Prometheus

Prometheus 大部分组件都是用 Go 编写，因此安装非常方便。

在组件的选择上，一般包括必选的 Prometheus server 和各种可选组件如：Alertmanager、各种 exporter、Grafana 等。

安装方式可以是二进制安装或通过 Docker 安装。

下面我们将通过二进制的方式安装 Prometheus server + Alertmanager + Grafana + node_exporter，另外我们还需要安装一个钉钉告警组件 prometheus-webhook-dingtalk，用于将告警发送到钉钉群组。

其他的组件读者可以参考官网/Github 等站点自行安装。

主机资源准备

| 编号 | 系统 | IP地址 | 安装的组件 | | -- | -- | -- | -- | | 1 | CentOS 7 | 192.168.2.10 | Prometheus server & node_exporter | | 2 | CentOS 7 | 192.168.2.11 | Grafana | | 3 | CentOS 7 | 192.168.2.12 | Alertmanager & prometheus-webhook-dingtalk |

安装 Prometheus Server

熟悉 Ansible 的同学可以从 Github 上下载 Playbook 进行 Prometheus server 的安装，下面介绍手动安装的步骤：

  1. 在 192.168.2.10 上创建系统用户 prometheus 和组 prometheus：

    $ groupadd -r prometheus
$ useradd -r -M -s /sbin/nologin -d /tmp prometheus

  2. 到官网下载已编译的二进制源码包，解压缩。

    $ curl https://github.com/prometheus/prometheus/releases/download/v2.5.0/prometheus-2.5.0.linux-amd64.tar.gz | tar -zx

  3. 规定配置文件的目录为 /etc/prometheus，数据库目录为 /data/prometheus。复制配置文件 prometheus.yml 、目录 conf.d、rules、file_sd、console_libraries、consoles 到配置文件目录 /etc/prometheus，创建数据库目录。

    $ mkdir -p /etc/prometheus /data/prometheus
$ chown root:prometheus /etc/prometheus /data/prometheus
$ cp -rf prometheus.yml conf.d rules file_sd console_libraries consoles /etc/prometheus

  4. 复制二进制文件 prometheus 和 promtool 到 /usr/local/bin。

  5. 创建 systemd service unit 文件 /etc/systemd/system/prometheus.service：

    [Unit]
Description=Prometheus
After=network.target

[Service]
Type=simple
Environment="GOMAXPROCS=4"
User=prometheus
Group=prometheus
ExecReload=/bin/kill -HUP $MAINPID
ExecStart=/usr/local/bin/prometheus \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.path=/data/prometheus \
  --storage.tsdb.retention=30d \
  --web.console.    libraries=/etc/prometheus/console_libraries \
  --web.console.templates=/etc/prometheus/consoles \
  --web.listen-address=0.0.0.0:9090 \
  --web.external-url=/prometheus
PrivateTmp=true
PrivateDevices=true
ProtectHome=true
NoNewPrivileges=true
LimitNOFILE=infinity
ReadWriteDirectories=/data/prometheus
ProtectSystem=full


SyslogIdentifier=prometheus
Restart=always

[Install]
WantedBy=multi-user.target

通过以上几步我们就完成了 Prometheus server 的安装。

配置 Prometheus Server

Prometheus server 的配置分两部分，一部分属于固定配置，需要通过命令行参数传递，在上面安装的时候我们已经写在 unit 文件中。另一部分就需要配置文件了。配置文件 prometheus.yml 的格式是 yaml ，主要分以下几个配置块：

  • 全局配置 global
  • 规则文件配置 rule_files
  • 抓取配置 scrape_configs
  • 告警配置 alerting
  • 远程读/写功能 remote_read 和 remote_write

我们来逐个进行配置。

全局配置 global

全局配置中的参数在其他的所有配置块中都可以使用，将作为其他配置块的默认值。 以下是一个例子：

global:
  evaluation_interval: 5s
  scrape_interval: 5s
  scrape_timeout: 3s #需注意该值应小于 scrape_internal
  external_labels:
    environment: vm-tel-xyz-prometheus.xyz.cn
规则文件配置 rule_files

规则文件配置指定规则和告警的配置文件的路径，可以是 glob 模式：

rule_files:
  - /etc/prometheus/rules/*.rules

Prometheus 中的规则文件分两种类型：记录规则和告警规则。

记录规则可以让你提前计算高频需求或对计算性能要求很高的表达式，将结果保存为一组新的时间序列。查询这些提前计算好的结果一般都会比每次到用时才计算要快得多。对于 Dashboard 来说这很重要，因为 Dashboard 每次刷新的时候都会重复查询同样的表达式。

告警规则可以让你基于 PromQL 表达式定义告警条件，并将触发的告警提醒发送给外部的服务。每当告警表达式在一个时间点产生一个或多个矢量元素时，告警会将这些元素的标签设为激活状态。

记录和告警规则放在一个规则组（group）中。同一个组中的规则会以一个特定的频率不断地执行。

规则文件的语法
groups:
  [ - <rule_group> ]

举个例子：

groups:
  - name: example
    rules:
    - record: job:http_inprogress_requests:sum
      expr: sum(http_inprogress_requests) by (job)

<rule_group>

# 组的名称，在一个文件中需唯一
name: <string>

# 组中规则执行的频率
[ interval: <duration> | default = global.evaluation_interval ]

rules:
  [ - <rule> ... ]

<rule>

记录规则的语法：

# 时间序列的名称，必须是一个合法的 metric 名称
record: <string>

# PromQL 表达式。每一个计算周期内都会计算一次，结果记录为一组以上面 'record' 给定的名称命名的时间序列
expr: <string>

# 保存结果前需要添加或覆盖的标签
labels:
  [ <labelname>: <labelvalue> ]

告警规则的语法：

# 告警的名称，必须是一个合法的 metric 名称。
alert: <string>

# PromQL 表达式。每一个计算周期内都会计算一次，所有的结果组成时间序列，会成为待定/触发的告警。
expr: <string>

# 告警如果持续了这么长时间，就会触发一次；如果还没持续这么长时间，就认为是待定的告警
[ for: <duration> | default = 0s ]

# 对于每一个告警需要添加/覆盖的标签
labels:
  [ <labelname>: <tmpl_string> ]

# 对于每一个告警需要添加的注释
annotations:
  [ <labelname>: <tmpl_string> ]

一个告警规则的例子如下：

groups:
- name: example
  rules:
  - alert: HighErrorRate
    expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5
    for: 10m
    labels:
      severity: page
    annotations:
      summary: High request latency

for 子句使 Prometheus 在第一次发现一个表达式输出的矢量元素后、到触发该元素对应的告警之前需要等待特定的时长。在这种情况下， Prometheus 会检查告警是否在10分钟的等待期内持续被激活，当等待期满了以后就会触发告警。被激活而未触发的告警，就处于等待状态（Pending）。

label 子句用于给告警提供一组额外的标签。已经存在的标签会被覆盖。标签的值可以用模板做替换。

annotations 子句用于给告警提供一组信息标签，这组标签可以保存更长的信息，比如告警描述、运行记录链接等。注释的值也可以用模板做替换。

模板

标签和注释的值都可以用 console templating 格式做模板转换。$labels 变量代表一个告警实例的所有标签键/值对，$value 变量代表告警实例计算的值。

# 插入一个触发元素的标签值：
{{ $labels.<labelname> }}
# 插入触发元素的数字表达式值：
{{ $value }}

例：

groups:
- name: example
  rules:

  # 对于任何超过5分钟还不可达的实例进行告警：
  - alert: InstanceDown
    expr: up == 0
    for: 5m
    labels:
      severity: page
    annotations:
      summary: "Instance {{ $labels.instance }} down"
      description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes."

  # 对于平均请求延迟超过1秒的实例进行告警：
  - alert: APIHighRequestLatency
    expr: api_http_request_latencies_second{quantile="0.5"} > 1
    for: 10m
    annotations:
      summary: "High request latency on {{ $labels.instance }}"
      description: "{{ $labels.instance }} has a median request latency above 1s (current value: {{ $value }}s)"

更多模板的例子可以访问官方文档查看。

抓取配置 scrape_configs

抓取配置设置抓取配置的列表。

每一个抓取配置指定了一组抓取的目标和描述抓取方式的一些参数。一般来说，一个抓取配置对应一个任务（job）。

目标可以用 static_configs 静态配置，也可以用支持的某种服务发现机制动态发现。

另外 relabel_configs 允许在抓取前对目标及其标签进行修改。

下面展示了四个抓取配置，其中 prometheus 和 redis 通过 static_configs 静态配置，node 和 dms 则通过 file_sd 的方式自动发现目标。如果你是在 Kubernetes 中运行，或环境中有 Consul 一类服务发现工具，你也可以配置 kubernetes_sd_configs 或 consul_sd_configs 等实现动态发现。

scrape_configs:
  - job_name: prometheus
    metrics_path: /prometheus/metrics
    static_configs:
    - targets:
      - vm-tel-xyz-prometheus.xyz.cn:9090
  - job_name: node
    file_sd_configs:
    - files:
      - /etc/prometheus/file_sd/node.yml
  - job_name: redis
    static_configs:
    - targets:
      - localhost:9121
  - job_name: dms
    metrics_path: /actuator/prometheus
    file_sd_configs:
    - files:
      - /etc/prometheus/file_sd/dms.yml
告警配置 alerting

alerting 的配置与 Alertmanager 有关，目前我们还没安装 Alertmanager，但可以先把配置配上，这里我们用静态配置指定 Alertmanager 的 HTTP 接口：

alerting:
  alertmanagers:
  - path_prefix: /alertmanager
    scheme: http
    static_configs:
    - targets:
      - 192.168.2.12:9093
远程读/写功能 remote_read 和 remote_write

这部分配置将数据源与 Prometheus 分离时使用，在我们当前的安装架构中不需要做额外配置。

下面是完整的配置文件：

global:
  evaluation_interval: 5s
  scrape_interval: 5s
  scrape_timeout: 3s
  external_labels:
    environment: vm-tel-xyz-prometheus.xyz.cn

rule_files:
  - /etc/prometheus/rules/*.rules

alerting:
  alertmanagers:
  - path_prefix: /alertmanager
    scheme: http
    static_configs:
    - targets:
      - 192.168.2.12:9093

scrape_configs:
  - job_name: prometheus
    metrics_path: /prometheus/metrics
    static_configs:
    - targets:
      - vm-tel-xyz-prometheus.xyz.cn:9090
  - job_name: node
    file_sd_configs:
    - files:
      - /etc/prometheus/file_sd/node.yml
  - job_name: redis
    static_configs:
    - targets:
      - localhost:9121
  - job_name: dms
    metrics_path: /actuator/prometheus
    file_sd_configs:
    - files:
      - /etc/prometheus/file_sd/dms.yml

关于配置中更多的配置项和用法，请参阅官方文档。

exporter 简介

对于自己研发的应用，我们可以在应用内加入客户端库，各种语言的库使用方式请参考：https://prometheus.io/docs/instrumenting/clientlibs/

但是对于某些监控对象，比如：操作系统、Nginx、Redis、MySQL，我们不能插入库文件，怎么办呢？ Prometheus 的解决方案是引入 exporter 。通过各种 exporter 你可以方便地采集各类目标运行数据。

这里我们只介绍 node_exporter。该 exporter 适用于 *nix 操作系统，可以采集各种基础资源使用信息如 CPU、内存、磁盘、网络等。

其他的 exporeter 你可以在 https://prometheus.io/docs/instrumenting/exporters/ 查找并使用。

安装 node_exporter

同样在官方下载页面我们可以找到 node_exporter 的二进制安装包，只需下载并放到后台运行即可。

细心的同学已经发现了，我们在 Prometheus 配置 scrape_configs 时已经加入了 node_exporter 的部分配置：

scrape_configs:
...
  - job_name: node
    file_sd_configs:
    - files:
      - /etc/prometheus/file_sd/node.yml

file_sd_configs中的配置文件可以用 yaml 或 JSON 格式编写，这里还是用我们熟悉的 yaml ：

- targets:
  - 192.168.2.10:9100
  labels:
  - server_name: prometheus_server

安装 Alertmanager 和 prometheus-webhook-dingtalk

让我们来到告警服务器（192.168.2.12），下载两个软件的二进制包：

$ curl https://github.com/prometheus/alertmanager/releases/download/v0.15.2/alertmanager-0.15.2.linux-amd64.tar.gz | tar zx

$ git clone https://github.com/timonwong/prometheus-webhook-dingtalk.git

只需要将两个二进制包 alertmanager 和 prometheus-webhook-dingding 放进 /usr/local/bin 就能运行了。

配置 Alertmanager 和 prometheus-webhook-dingtalk

  1. 创建配置文件目录 /etc/alertmanager 并复制配置文件 alertmanager.yml 到这里；创建存储目录：

    $ mkdir -p /etc/alertmanager
$ cp alertmanager.yml /etc/alertmanager.yml
$ mkdir -p /data/alertmanager

  2. 修改配置文件，使其在告警时发送给钉钉的 webhook：

    global:
  resolve_timeout: 5m

route:
  receiver: 'focusops'
  group_wait: 10s
  group_interval: 1m
  repeat_interval: 1h
  group_by: ['alertname']
  routes:
    - receiver: 'focusops'
      continue: true
    - receiver: 'xyz'

receivers:
# 我们指定了两个receiver，分别到 dingtalk 的 webhook1 和 webhook2 ，这和我们后面启动 prometheus-webhook-dingtalk 时的参数保持一致，    需要注意。
- name: 'focusops'
  webhook_configs:
  - send_resolved: true
    url: 'http://localhost:8060/dingtalk/webhook1/send'
- name: 'xyz'
  webhook_configs:
  - send_resolved: true
    url: 'http://localhost:8060/dingtalk/webhook2/send'

inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']

  3. 编写 Alertmanager 和 prometheus-webhook-dingtalk 的启动脚本，并启动：

    alertmanager.sh：

    alertmanager \ --config.file=/etc/alertmanager/alertmanager.yml \
--web.external-url=/alertmanager \
--storage.path=/data/alertmanager/ \
&> alertmanager.log &

    dingtalk.sh（注意替换token1和token2）：

    prometheus-webhook-dingtalk \
--ding.profile=webhook1=https://oapi.dingtalk.com/robot/send?access_token=<token1> \
--ding.profile=webhook2=https://oapi.dingtalk.com/robot/send?access_token=<token2> \
&>dingtalk.log &

安装与配置 Grafana

尽管 Prometheus 自身提供一个 web UI，但是这个 UI 还是太简陋了， Grafana 几乎是标配的展示工具。

对于我们的 CentOS 7 系统，我们可以通过 YUM 快速安装：

  1. 添加 yum 源文件 /etc/yum.repos.d/grafana.repo：

    [grafana]
name=grafana
baseurl=https://packagecloud.    io/grafana/stable/el/7/$basearch
#repo_gpgcheck=1
enabled=1
gpgcheck=0
#gpgkey=https://packagecloud.io/gpg.key     https://grafanarel.s3.amazonaws.    com/RPM-GPG-KEY-grafana
#sslverify=1
#sslcacert=/etc/pki/tls/certs/ca-bundle.crt

    因为国内网络的关系我把 gpgcheck 相关的验证都去掉了，不放心的可以把删除注释，但是需要保证可以网络连通哦！

  2. YUM 安装：

    $ yum install grafana

  3. 配置 Grafana

    配置文件 /etc/grafana/grafana.ini 只需要注意登录方面的配置，如 admin_user 和 admin_password，你还可以启用 LDAP 验证模块：

    [auth.ldap]
enabled = true
config_file = /etc/grafana/ldap.toml

    然后配置 /etc/grafana/ldap.toml ，这里不再赘述。

  4. 启动 Grafana

    $ systemctl start grafana-server

  5. 关联 Grafana 与 Prometheus 数据源

    访问 http://192.168.2.11:3000 打开 Grafana，登录后选择添加数据源，在 Settings 中选择 Type 为 Prometheus ，在 HTTP 的 URL 中填入 Prometheus server 的 HTTP 接口地址，点击 Save & Test，看到绿色的 Data source is working 就说明已经关联成功了。

  6. 添加 Dashboard

    虽然你可以自定义 Dashboard，但是如果我告诉你已经有很多人做好了现成的 Dashboard 并且你可以直接拿来用呢？

    是的，除非我们有特定要求，不然我们何必自己造轮子。

    打开 http://192.168.2.11:3000/dashboard/import ，填入 grafana 官网的 Dashboard ID，即可以导入其他人做好的 Dashboard 作品。

    各种 Dashboard 我们可以在 https://grafana.com/dashboards 查看、检索。

在 Grafana 中查看数据和图表

对于不同的时间序列我们可以使用不同的 Dashboard 进行查看。比如对于 node_exporter 采集到的时间序列，我们只需导入 node_exporter 适配的 Dashboard （ID：1860），就可以看到图表了：

node_dashboard

最后

上面介绍了这么多，但是如何自定义图表和告警规则？在下一篇文章中我将给大家介绍 Prometheus 的查询语言 PromQL。

转载于:https://my.oschina.net/plutonji/blog/2873389

weixin_34212189
关注
prometheus存储
孔小发
05-21 7806
本地存储 '''核心概念''' 采用TSDB本地存储，核心为block和wal. 最新版本每秒可以接收1000w样本更新. '''block''' *目录结构* [root@shzj-o-docker-12-2 data]# tree 01DB5QAD1P5WBBRPEJAABZERFX 01DB5QAD1P5WBBRPEJAABZERFX ├── chunks # 保存压缩...
一文读懂如何在 Kubernetes 上轻松实现自动化部署 Prometheus
easylife206的专栏
08-27 852
简介Prometheus 是当下火热的监控解决方案，尤其是容器微服务架构，Kubernetes 的首选监控方案。关于为什么要用 Prometheus，我这里就不多讲，相关...
prometheus 修改存储目录
mixboot
07-08 7947
--storage.tsdb.path="/storage/prometheusData" [Unit] Description=prometheus service [Service] User=root ExecStart=/root/prometheus-2.19.2.linux-amd64/prometheus --config.file=/root/prometheus-2.19.2.linux-amd64/prometheus.yml --storage.tsdb.path="/stora.
prometheus 修改 tsdb 数据存储时长
最新发布
以梦为马|越骑越傻
03-07 664
【代码】prometheus 修改 tsdb 数据存储时长。
总结：Prometheus长期存储方案
w2009211777的专栏
07-27 1万+
prometheus存储梳理
Prometheus入门终极指南.doc
05-09
Prometheus 入门终极指南 Prometheus 是一个开源监控系统，前身是 SoundCloud 的告警插件。从 2012 年开始，Prometheus 逐渐被大量公司使用。该项目的社区也便跃起来，收到越来越多的贡献。在 2016 年继 Kurberntes...
Prometheus入门与进阶实践教程2024
02-22
一、Prometheus的概念和发展史 Prometheus是一个开源的完整监控解决方案，本文将从指标抓取到查询及可视化展示，以及最后的监控告警，对Prometheus做一个基本的认识。 Prometheus发展速度很快，12年开发完成，16年...
Prometheus入门与进阶实践（2024最新）
02-26
### Prometheus入门与进阶实践（2024最新） #### 一、Prometheus概述 **Prometheus** 是一款开源的服务监控系统与时间序列数据库。它最初由SoundCloud开发，后来得到了广泛的应用和支持，并最终成为云原生计算基金...
prometheus入门讲解.pptx
03-20
Prometheus 入门讲解 Prometheus 是一个开源的监控系统，主要用于收集和存储时间序列数据。下面是对 Prometheus 的基本原理、组件介绍、工作过程、数据类型等方面的详细讲解。 基本原理 Prometheus 的核心是时序...
g2ww-serverless:代理Grafana Webhook对微信工作发出警报。（现在在Cloudflare Workers“ Staff Picks”中）
05-12
G2WW（Grafana 2微信工作）无服务器版 代理Grafana Webhook提醒微信工作。 Grafana不支持设计为对微信Work（企业微信）的推送警报（他们甚至关闭了我的PR： ），这是支持此功能的小型适配器。 这是的无服务器版本，现在在“ ”的“ Staff Picks”中。 安装 只需将index.js的内容复制到Cloudflare Workers。 用法 创建一个微信工作机器人 创建一个微信工作机器人并获取webhook地址。 例如，Webhook地址为https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=e28dde4c-1998-0002-0018-114514114514 。 配置Grafana 在上面的配置中，我们需要这样指定地址： https://g2ww.knat.network/e28dde
【prometheus】- 01 云原生时代的监控系统入门
god_86的专栏
08-16 879
【定时调度】- 01 quartz的基础你真的了解吗03 xxl-job任务执行流程【RabbitMQ分析】01 SimpleMessageListenerContainer原理分析【sh...
普罗米修斯清除历史数据
热门推荐
w345731923的专栏
02-04 1万+
数据存储 Prometheus具有配置本地存储的多个标志。最重要的是： --storage.tsdb.path：Prometheus写入数据库的位置。默认为data/。 --storage.tsdb.retention.time：何时删除旧数据。默认为15d。storage.tsdb.retention如果此标志设置为默认值以外的任何值，则覆盖。 --storage.tsdb.retention.size：[EXPERIMENTAL]要保留的最大存储块字节数。最旧的数据将首先被删除。默认为0或禁用。
Prometheus Operator 配置PrometheusRule告警规则
小楼一夜听春雨，深巷明朝卖杏花
07-19 2597
他们应该用怎样的方式通知我们呢？我们知道之前我们使用自定义的方式可以在Prometheus的配置文件之中指定AlertManager实例和报警的rules文件，现在我们通过Operator部署的呢？对象即可，比如现在我们添加一个etcd是否可用的报警，我们知道etcd整个集群有一半以上的节点可用的话集群就是可用的，所以我们判断如果不可用的etcd数量超过了一半那么就触发报警，创建文件。，用来匹配rule规则的过滤器，我们这里没有过滤，所以可以匹配所有的，假设要求匹配具有。...
prometheus02-prometheus完整配置文件详细介绍
weixin_44242433的博客
03-15 714
以上是一个简单的Prometheus配置文件的介绍，根据实际需求可以进行更多的配置。
【Java】企业微信机器人自动发送群消息
分数没二舅血压高
05-19 4232
1.先在群里添加机器人，然后获取机器人的webhook地址： 假设webhook是：https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=693a91f6-7xxx-4bc4-97a0-0ec2sifa5aaa 2.有多种方式发送群消息，可以采用curl，也可以采用发送https请求的方式，我这里采用okhttp发送http请求，pom如下： <!-- https://mvnrepository.com/artifact/com.squareup
prometheus.service配置文件说明
wsyzxss的博客
07-22 2139
[root@HRBB03-PUB-UNDEFINED-26-ITC51 system]# cat prometheus.service [unit] Description=Prometheus Server Documentation=https://prometheus.io/docs/introduction/overview/ After=network.target [Service] User=root Group=root Type=simple Restart=on-fai.
Python书签 # 实现用企业微信机器人发送消息（文本消息、图文消息、Markdown消息）
有时有味的博客
03-04 1万+
在终端某个群组添加机器人之后，可以获取到 webhook 地址，然后我们按以下说明构造 post data，向这个地址发起 HTTP POST 请求，就可以实现给该群组发送消息。 假设我们在群组里添加机器人后获取的webhook 是：https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=69e3bed5-a20e-45be-9999-e30...
Prometheus数据存储、集群和高可用
hanjinjuan的博客
11-17 5659
文章目录1. Prometheus 储存瓶颈2. 本地存储2.1 本地存储配置2.2 从失败中恢复3. 远程存储3.1 Remote Write3.2 Remote Read3.3 配置文件3.4 使用Influxdb作为远程存储3.4.1 Influxdb部署3.4.2 创建数据库3.4.3 Prometheus指定存储路径3.4.4 添加远程读写3.4.5 验证influxdb数据4. 联邦集群4.1 使用联邦集群4.2 功能分区5. Prometheus高可用部署5.1 基本HA：服务可用性5.2 基
企业运维监控深度解析：Prometheus入门与实战指南
讲座内容涵盖了多个核心环节，包括企业级运维监控的基础理论、通用技术，如Prometheus的入门介绍，其运行框架、数据格式以及安装和配置。深入讲解了Prometheus命令行使用技巧和数学理论基础，涉及Exporter和...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值