从零开始prometheus

最新推荐文章于 2024-07-15 13:40:26 发布
最新推荐文章于 2024-07-15 13:40:26 发布
阅读量1.4k 收藏 4
点赞数 1
分类专栏： promethues 文章标签： prometheus
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Anubis000000/article/details/93654253
版权

第一部分：先上一波实战，用prometheus-oprator监控你的k8s集群

一：为什么需要prometheus-operator

在Kubernetes中我们使用Deployment、DamenSet、StatefulSet来管理应用Workload，使用Service、Ingress来管理应用的访问方式，使用ConfigMap和Secret来管理应用配置。我们在集群中对这些资源的创建，更新，删除的动作都会被转换为事件(Event)，Kubernetes的Controller Manager负责监听这些事件并触发相应的任务来满足用户的期望。这种方式我们成为声明式，用户只需要关心应用程序的最终状态，其它的都通过Kubernetes来帮助我们完成，通过这种方式可以大大简化应用的配置管理复杂度。

而除了这些原生的Resource资源以外，Kubernetes还允许用户添加自己的自定义资源(Custom Resource)。并且通过实现自定义Controller来实现对Kubernetes的扩展，不需要用户去二开k8s也能达到给k8s添加功能和对象。

Prometheus-operator的本职就是一组用户自定义的CRD资源以及Controller的实现，Prometheus Operator这个controller有BRAC权限下去负责监听这些自定义资源的变化，并且根据这些资源的定义自动化的完成如Prometheus Server自身以及配置的自动化管理工作。

二：Prometheus-oprator的工作架构：

 

 三：Prometheus Operator引入的自定义资源包括

  1. Prometheus
  2. ServiceMonitor  
  3. Alertmanager

四：部署Prometheus Operator：

git clone https://github.com/coreos/prometheus-operator.git
cd prometheus-operator/contrib/
rm -rf kube-prometheus/
git clone https://github.com/coreos/kube-prometheus.git
cd kube-prometheus/manifests
#####分批处理一下方便管理：
mkdir -p operator node-exporter alertmanager grafana kube-state-metrics prometheus serviceMonitor adapter
mv *-serviceMonitor* serviceMonitor/
mv 0prometheus-operator* operator/
mv grafana-* grafana/
mv kube-state-metrics-* kube-state-metrics/
mv alertmanager-* alertmanager/
mv node-exporter-* node-exporter/
mv prometheus-adapter* adapter/
mv prometheus-* prometheus/
######开始部署：
pro1k8s apply -f bundle.yaml 
######
kubectl apply -f adapter/
kubectl apply -f alertmanager/
kubectl apply -f node-exporter/
kubectl apply -f kube-state-metrics/
kubectl apply -f grafana/
kubectl apply -f prometheus/
kubectl apply -f serviceMonitor/

 五：里面的坑：

打开页面发现：

 

这是因为serviceMonitor是根据label去选取svc的，我们可以看到对应的serviceMonitor是选取的ns范围是kube-system，然而里面没有这两个组件对应的service，不知道k8s搞什么鬼。

创建一个service即可：

 cat 01kube-prom-service.yml 
apiVersion: v1
kind: Service
metadata:
  namespace: kube-system
  name: kube-controller-manager
  labels:
    k8s-app: kube-controller-manager
spec:
  selector:
    component: kube-controller-manager
  type: ClusterIP
  clusterIP: None
  ports:
  - name: http-metrics
    port: 10250
    targetPort: 10250
    protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  namespace: kube-system
  name: kube-scheduler
  labels:
    k8s-app: kube-scheduler
spec:
  selector:
    component: kube-scheduler
  type: ClusterIP
  clusterIP: None
  ports:
  - name: http-metrics
    port: 10250
    targetPort: 10250
    protocol: TCP

然而：

cat /etc/kubernetes/manifests/kube-scheduler.yaml|grep address
    - --address=127.0.0.1
cat /etc/kubernetes/manifests/kube-controller-manager.yaml|grep address
    - --address=127.0.0.1
sed -ri '/--address/s#=.+#=0.0.0.0#' /etc/kubernetes/manifests/kube-controller-manager.yaml
sed -ri '/--address/s#=.+#=0.0.0.0#' /etc/kubernetes/manifests/kube-scheduler.yaml

 

第二部分：prometheus详解：

一:什么是TSDB？

时间序列数据库的特点

  • 大部分时间都是写入操作。
  • 写入操作几乎是顺序添加，大多数时候数据到达后都以时间排序。
  • 写操作很少写入很久之前的数据，也很少更新数据。大多数情况在数据被采集到数秒或者数分钟后就会被写入数据库。
  • 删除操作一般为区块删除，选定开始的历史时间并指定后续的区块。很少单独删除某个时间或者分开的随机时间的数据。
  • 基本数据大，一般超过内存大小。一般选取的只是其一小部分且没有规律，缓存几乎不起任何作用。
  • 读操作是十分典型的升序或者降序的顺序读。
  • 高并发的读操作十分常见。

二：什么是Prometheus?

  • 多维度数据模型。
  • 灵活的查询语言。
  • 不依赖分布式存储，单个服务器节点是自主的。
  • 通过基于HTTP的pull方式采集时序数据。
  • 可以通过中间网关进行时序列数据推送。
  • 通过服务发现或者静态配置来发现目标服务对象。
  • 支持多种多样的图表和界面展示，比如Grafana等。

三：Prometheus都有哪些组件？

  • Prometheus Server：主要负责数据采集和存储，提供PromQL查询语言的支持。
  • 客户端SDK：官方提供的客户端类库有go、java、scala、python、ruby，其他还有很多第三方开发的类库，支持nodejs、php、erlang等。
  • Push Gateway：支持临时性Job主动推送指标的中间网关。
  • PromDash：使用Rails开发可视化的Dashboard，用于可视化指标数据。
  • Exporter：Exporter是Prometheus的一类数据采集组件的总称。它负责从目标处搜集数据，并将其转化为Prometheus支持的格式。与传统的数据采集组件不同的是，它并不向中央服务器发送数据，而是等待中央服务器主动前来抓取。

Prometheus提供多种类型的Exporter用于采集各种不同服务的运行状态。目前支持的有数据库、硬件、消息中间件、存储系统、HTTP服务器、JMX等。

  • alertmanager：警告管理器，用来进行报警。
  • 其他辅助性工具： promtool

四：prometheus的架构：

五：prometheus的基本原理：

Prometheus的基本原理是通过HTTP协议周期性抓取被监控组件的状态，任意组件只要提供对应的HTTP接口就可以接入监控。不需要任何SDK或者其他的集成过程。这样做非常适合做虚拟化环境监控系统，比如VM、Docker、Kubernetes等。输出被监控组件信息的HTTP接口被叫做exporter 。mysql、kafka、redis、等许多组件都有exporter

六：Prometheus工作过程：

  • Prometheus Daemon负责定时去目标上抓取metrics(指标)数据，每个抓取目标需要暴露一个http服务的接口给它定时抓取。Prometheus支持通过配置文件、文本文件、Zookeeper、Consul、DNS SRV Lookup等方式指定抓取目标。Prometheus采用PULL的方式进行监控，即服务器可以直接通过目标PULL数据或者间接地通过中间网关来Push数据。
  • Prometheus在本地存储抓取的所有数据，并通过一定规则进行清理和整理数据，并把得到的结果存储到新的时间序列中。
  • Prometheus通过PromQL和其他API可视化地展示收集的数据。Prometheus支持很多方式的图表可视化，例如Grafana、自带的Promdash以及自身提供的模版引擎等等。Prometheus还提供HTTP API的查询方式，自定义所需要的输出。
  • PushGateway支持Client主动推送metrics到PushGateway，而Prometheus只是定时去Gateway上抓取数据。
  • Alertmanager是独立于Prometheus的一个组件，可以支持Prometheus的查询语句，提供十分灵活的报警方式。

 

第三部分：prometheus的分布式思路详解：

一：prometheus-server的分布式思路：

  • 只需要部署多套Prometheus，采集相同的Targets即可实现基本的HA：下面的prometheus写相同的targets

./remote_storage_adapter -influxdb-url=http://localhost:8086/ -influxdb.database=prometheus -influxdb.retention-policy=autoge

 prometheus的配置文件：

remote_write:
 - url: "http://localhost:9201/write"
remote_read:
 - url: "http://localhost:9201/read"
  • prometheus本身的联邦机制：不同的prometheus可以通过联邦机制实现数据聚合：

 

scrape_configs:
  - job_name: 'federate'
    scrape_interval: 15s
    honor_labels: true ##(to not overwrite any labels exposed by the source server）
    metrics_path: '/federate'
    params:
      'match[]':
        - '{job=~"kubernetes.*"}'
        - '{__name__=~"job:.*"}'
        #- '{job="mysql"}'
        #- '{job="pgsql"}'
    static_configs:
      - targets:
        - '10.111.178.30:30373'

 

可以解决什么问题呢？

  • 单数据中心 + 大量的采集任务，将不同类型的采集任务划分到不同的Promthues子服务中，从而实现功能分区。例如一个Promthues Server负责采集基础设施相关的监控指标，另外一个Prometheus Server负责采集应用监控指标。再有上层Prometheus Server实现对数据的汇聚。
  • 多数据中心，当Promthues Server无法直接与数据中心中的Exporter进行通讯时，在每一个数据中部署一个单独的Promthues Server负责当前数据中心的采集任务是一个不错的方式。这样可以避免用户进行大量的网络配置，只需要确保主Promthues Server实例能够与当前数据中心的Prometheus Server通讯即可。 中心Promthues Server负责实现对多数据中心数据的聚合。

二：alertmanager的分布式思路：

  • 因为是分开的，多个server可以公用一个alertmanager

  • 虽然Alertmanager能够同时处理多个相同的Prometheus Server所产生的告警。但是由于单个Alertmanager的存在，当前的部署结构存在明显的单点故障风险，当Alertmanager单点失效后，告警的后续所有业务全部失效。

 

 but，但是由于Alertmanager之间不存在并不了解彼此的存在，因此则会出现告警通知被不同的Alertmanager重复发送多次的问题。

  • 为了解决这一问题，如下所示。Alertmanager引入了Gossip机制。Gossip机制为多个Alertmanager之间提供了信息传递的机制。确保及时在多个Alertmanager分别接收到相同告警信息的情况下，也只有一个告警通知被发送给Receiver。

 

  • Gossip 协议：

Alertmanager基于Gossip实现的集群机制虽然不能保证所有实例上的数据时刻保持一致，但是实现了CAP理论中的AP系统，即可用性和分区容错性。同时对于Prometheus Server而言保持了配置了简单性，Promthues Server之间不需要任何的状态同步。

nohup ./alertmanager  --web.listen-address=":9093" --cluster.listen-address="127.0.0.1:8001" --config.file="alertmanager.yml" 2>&1 > alert1.log &
nohup ./alertmanager  --web.listen-address=":9094" --cluster.listen-address="127.0.0.1:8002" --cluster.peer=127.0.0.1:8001 --config.file="alertmanager.yml" 2>&1 > alert2.log &
nohup ./alertmanager  --web.listen-address=":9095" --cluster.listen-address="127.0.0.1:8003" --cluster.peer=127.0.0.1:8001 --config.file="alertmanager.yml" 2>&1 > alert3.log &

模拟代码测试：

alerts1='[
  {
    "labels": {
       "alertname": "DiskRunningFull",
       "dev": "sda1",
       "instance": "example1"
     },
     "annotations": {
        "info": "The disk sda1 is running full",
        "summary": "please check the instance example1"
      }
  }
]'
curl -XPOST -d"$alerts1" http://localhost:9093/api/v1/alerts
curl -XPOST -d"$alerts1" http://localhost:9094/api/v1/alerts
curl -XPOST -d"$alerts1" http://localhost:9095/api/v1/alerts

所以这套可以作为prometheus-server的通用报警集群，每套server里面添加配置保证像每个alertmanager都发送报警消息即可：

alerting:
  alertmanagers:
  - static_configs:
      - targets: ["localhost:9093"]
      - targets: ["localhost:9094"]
      - targets: ["localhost:9095"]

执行脚本sh sent_alert.sh 

{"status":"success"}{"status":"success"}{"status":"success"}

查看钉钉消息只收到一条：

 

第四部分：promsql详解：

一：数据库格式：

<--------------- metric ---------------------><-timestamp -><-value->
http_request_total{status="200", method="GET"}@1434417560938 => 94355
http_request_total{status="200", method="GET"}@1434417561287 => 94334
http_request_total{status="404", method="GET"}@1434417560938 => 38473
http_request_total{status="404", method="GET"}@1434417561287 => 38544
http_request_total{status="200", method="POST"}@1434417560938 => 4748
http_request_total{status="200", method="POST"}@1434417561287 => 4785

二：什么是metrics：

grpc_cache_total{app="smpre-svc-ads-go",enable="true",instance="172.24.4.172:2112",job="kubernetes-pods",kubernetes_namespace="staging",kubernetes_pod_name="smpro-svc-ads-go-58d6d44cb5-xthqz",pod_template_hash="1482800761",rpc="Execute",service="svc-rule",status="hit",version="pre"}327
  1. 为了能够帮助用户理解和区分这些不同监控指标之间的差异，Prometheus定义了4中不同的指标类型(metric type)：Counter（计数器）、Gauge（仪表盘）、Histogram（直方图）、Summary（摘要）。直接curl能看到每个metrics的type，如下所示
# HELP mysql_up Whether the MySQL server is up.
# TYPE mysql_up gauge
mysql_up 1
# HELP mysql_version_info MySQL version and distribution.
# TYPE mysql_version_info gauge
mysql_version_info{innodb_version="5.7.25",version="5.7.25-log",version_comment="Source distribution"} 1
# HELP mysqld_exporter_build_info A metric with a constant '1' value labeled by version, revision, branch, and goversion from which mysqld_exporter was built.
# TYPE mysqld_exporter_build_info gauge
mysqld_exporter_build_info{branch="HEAD",goversion="go1.10.3",revision="5d7179615695a61ecc3b5bf90a2a7c76a9592cdd",version="0.11.0"} 1
# HELP process_cpu_seconds_total Total user and system CPU time spent in seconds.
# TYPE process_cpu_seconds_total counter
process_cpu_seconds_total 2871.09
  •  Counter：只增不减的计数器：

五分钟的增长率：rate(http_requests_total[5m])

前五的请求：topk(5, http_requests_total)

  • Gauge：可增可减的仪表盘

mysql_global_status_memory_used

对于Gauge类型的监控指标，通过PromQL内置函数delta()可以获取样本在一段时间返回内的变化情况:

delta(mysql_global_status_memory_used{instance="pro-ab-test"}[1h])

还可以使用deriv()计算样本的线性回归模型，甚至是直接使用predict_linear()对数据的变化趋势进行预测:

predict_linear(mysql_global_status_memory_used{instance="pro-ab-test"}[1h], 4 * 3600)

  • Histogram &Summary

例如nginx_ingress_controller_ingress_upstream_latency_seconds这个metric为Summary：

其中0.5比例、0.9比例和0.99比例的延时秒分别为0.001 、0.001和 0.002

grpc_server_handling_seconds_bucket这个参数是咱们线上的一个histogram类型数据

histogram_quantile(0.90, sum(rate(grpc_server_handling_seconds_bucket{grpc_service="shimo.svc.comment.CommentService"}[1m])) by (grpc_method,le))

线上某时段的90请求的平均延时

与Summary类型的指标相似之处在于Histogram类型的样本同样会反应当前指标的记录的总数(以_count作为后缀)以及其值的总量（以_sum作为后缀）。不同在于Histogram指标直接反应了在不同区间内样本的个数，区间通过标签len进行定义。

同时对于Histogram的指标，我们还可以通过histogram_quantile()函数计算出其值的分位数。不同在于Histogram通过histogram_quantile函数是在服务器端计算的分位数。 而Sumamry的分位数则是直接在客户端计算完成。因此对于分位数的计算而言，Summary在通过PromQL进行查询时有更好的性能表现，而Histogram则会消耗更多的资源。反之对于客户端而言Histogram消耗的资源更少。在选择这两种方式时用户应该按照自己的实际场景进行选择。

三：promsql：

  • 直接输入metric的值：

promhttp_metric_handler_requests_total

{}里面的参数都可以用来过滤查询支持=、!=、正则

promhttp_metric_handler_requests_total{app="ingress-nginx",code!="400",instance=~"10.111.178.109:10254|10.111.178.110:10254"}

加入一个5m就能查到最近五分钟内的所有数值：

加offset 5m 可以查五分钟前的瞬时样本：

那么我想求上一个五分的所有数值怎么办：

总结：offset函数是一个相对的时间函数，可以用来时间位移

  • 使用聚合操作：

sum:

avg:

increase：函数获取区间向量中的第一个后最后一个样本并返回其增长量

rate:rate函数可以直接计算区间向量v在时间窗口内平均增长速率。因此，通过以下表达式可以得到与increase函数相同的结果：

需要注意的是使用rate或者increase函数去计算样本的平均增长速率，容易陷入“长尾问题”当中，其无法反应在时间窗口内样本数据的突发变化。 例如，对于主机而言在2分钟的时间窗口内，可能在某一个由于访问量或者其它问题导致CPU占用100%的情况，但是通过计算在时间窗口内的平均增长率却无法反应出该问题。

为了解决该问题，PromQL提供了另外一个灵敏度更高的函数irate(v range-vector)。irate同样用于计算区间向量的计算率，但是其反应出的是瞬时增长率。irate函数是通过区间向量中最后两个两本数据来计算区间向量的增长速率。这种方式可以避免在时间窗口范围内的“长尾问题”，并且体现出更好的灵敏度，通过irate函数绘制的图标能够更好的反应样本数据的瞬时变化状态。

举个例子：我们查最近十分钟的cpu利用率sum(irate(process_cpu_seconds_total[10m])) * 100 这个是最好的因为能够比较清晰的反映出十分钟内cpu利用率的变化

但是我们要查大约一个月的cpu利用率，用这个比较好

sum(rate(process_cpu_seconds_total[10m])) * 100

类似的可以直接使用sum，min，max，avg，stddev，stdvar，count，count_values，bottomk，topk，quantile  

 

第五部分：alertmanager详解：

一：alertmanager特点：

  • 分组，太多的报警信息来到时，可以分组发送
  • 抑制，如果一个报警规则触发以后，后面相同的触发就会被抑制
  • 静音，直接将个别报警进行屏蔽
  • 高可用，可以组成Alertmanager集群

二：Prometheus对接

Prometheus需要加入两个配置项

  • 配置文件引入Alertmanager实例
  • 定义出报警规则alerting rules
alerting:
  alertmanagers:
    #一组配置项目就是一个列表
    - scheme: https
      static_configs:
        - targets:
            - "1.2.3.4:9093"
            - "1.2.3.5:9093"
            - "1.2.3.6:9093"
    - scheme: http
      static_configs:
        - targets:
            - "1.2.3.7:9093"
            - "1.2.3.8:9093"
            - "1.2.3.9:9093"

或者k8s自动发现：

alerting:
  alertmanagers:
  - kubernetes_sd_configs:
      - role: pod
    tls_config:
      ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
    relabel_configs:
    - source_labels: [__meta_kubernetes_namespace]
      regex: default
      action: keep
    - source_labels: [__meta_kubernetes_pod_label_app]
      regex: prometheus
      action: keep
    - source_labels: [__meta_kubernetes_pod_label_component]
      regex: alertmanager
      action: keep
    - source_labels: [__meta_kubernetes_pod_container_port_number]
      regex:
      action: drop

三：引入报警规则

rule_files:
- "/etc/prometheus_rule/rule_*.yml"

具体规则如下：

# 定义alert类型并加上名称
alert: <string>
# PromQL 表达式
#expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5
expr: <string>
# 报警间隔，含义就是 当一个报警信息触发以后延迟多少时间再去fire
[ for: <duration> | default = 0s ]
# 报警标签
labels:
  [ <labelname>: <tmpl_string> ]
# 报警中的注释
annotations:
  [ <labelname>: <tmpl_string> ]
  #建议写上summary describipton
  #summary: "High request latency on {{ $labels.instance }}"
  #description: "{{ $labels.instance }} has a median request latency above 1s (current value: {{ $value }}s)"
#####label和annotations的值是以模板console templates来渲染的，用到go模板语言，报警注释和标签中常用的是变量$labels和$value，分别表示一个监控实例和expr字段上表达式所拉取的值

项目地址：https://git.shimo.im/shimo/prometheus_rule/tree/master

四：route

route定义了报警信息的分发策略，receivers定义了发送媒介，两者合在一起就是什么样的报警信息以什么样的形式发送。主要流程

  • 报警信息从Prometheus过来后就依据label(在Prometheus中alerting rules来定义)来分配属于哪一个route中的哪一个group中的哪一个alert
  • 新的Group等待group_wait指定的时间（等待时可能收到同一Group的Alert），根据resolve_timeout判断Alert是否解决，然后发送通知
  • 已有的Group等待group_interval指定的时间，判断Alert是否解决，当上次发送通知到现在的间隔大于repeat_interval或者Group有更新时会发送通知

 总路由：

#总路由，下面的配置都是各个子路由所继承的配置，如果子路由中没有配置就是使用总路由的配置，子路由中可以覆盖总路由的配置
route:
  #定义全路由默认的接受者
  receiver: 'default-receiver'
  #报警是否需要继续向兄弟(同级)节点匹配
  [ continue: <boolean> | default = false ]
  #等待还有可能到达的同组报警信息，初次发送一条警报包含多个信息
  [ group_wait: <duration> | default = 30s ]
  #已经存在的group等待group_interval这个时间段看报警问题是否解决
  [ group_interval: <duration> | default = 5m ]
  #当上次发送完报警信息之后再次发送的间隔，用来重复发送报警信息
  [ repeat_interval: <duration> | default = 4h ]
  #根据不同的标签来分组，这个主要用来筛选报警信息
  group_by: [cluster, alertname]
  #使用标签值精确匹配
  match:
    [ <labelname>: <labelvalue>, ... ]
  #使用正则表达进行范围匹配
  match_re:
    [ <labelname>: <regex>, ... ]

子路由构成的路由树：

route:
  receiver: default
  routes:
  - match:
      service: database
    receiver: a
    routes:
    - match:
        owner: team-X
      receiver: a1
    - match:
        owner: team-Y
      receiver: a2
      routes:
      - match:
          owner: ll
        receiver: a2.1
      - match:
          owner: rr
        receiver: a2.2
  - match:
    receiver: b
  - match:
    receiver: c
    routes:
    - match:
      receiver: c1
    - match:
      receiver: c2

五：报警抑制：

拿线上举个例子：

groups:
- name: dingtalk
  rules:
  - alert: dingtalk api 调用过多
    expr: sum(irate(dingtalk_api_call{}[1m])) > 60
    for: 1m
    labels:
      severity: warning
    annotations:
      summary: "钉钉 API 调用过多, 当前 {{ $value }} qps"

如果定义超过100 级别为critical 也发出告警：

groups:
- name: dingtalk
  rules:
  - alert: dingtalk api 调用过多
    expr: sum(irate(dingtalk_api_call{}[1m])) > 60
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "钉钉 API 调用过多, 当前 {{ $value }} qps"

可以设定抑制规则：

inhibit_rules:
  - source_match:
    altername: 'dingtalk api 调用过多'
    severity: 'critical'
  target_match:
    severity: 'warning'
  # Apply inhibition if the alertname is the same.
  equal: ['alertname', 'instance']

六：支持的发送方式：

这个不展开说了，咱们内部用钉钉，可以直接发到群里 prometheus机器里面：

./prometheus-webhook-dingtalk --web.listen-address=:8060 --ding.profile=ops_dingding=https://oapi.dingtalk.com/robot/send?access_token=xxxxxxx

 

第六部分：pushgateway

 一：安装：

docker pull prom/pushgateway
docker run ‐d ‐p 9091:9091 prom/pushgateway

二：简单使用：

echo "some_metric 3.14" | curl ‐‐data‐binary @‐ http://127.0.0.1:9091/metrics/job/some_job

 

因为 Prometheus 配置 pushgateway 的时候，也会指定 job 和 instance, 但是它只表示 pushgateway 实例，不能真正表达收集数据的含义。所以在prometheus 中配置 pushgateway 的时候，需要添加  honor_labels: true 参数，从而避免收集数据本身的  job  和  instance  被覆盖。

三：持久化

注意，为了防止 pushgateway 重启或意外挂掉，导致数据丢失，我们可以通过  -persistence.file  和  -persistence.interval  参数将数据持久化下来。

四：注意事项：

由于以上原因，不得不使用 pushgateway，但在使用之前，有必要了解一下它的一些弊端：

  • 将多个节点数据汇总到 pushgateway, 如果 pushgateway 挂了，受影响比多个 target 大。
  • Prometheus 拉取状态 up 只针对 pushgateway, 无法做到对每个节点有效。
  • Pushgateway 可以持久化推送给它的所有监控数据。

因此，即使你的监控已经下线，prometheus 还会拉取到旧的监控数据，需要手动清理 pushgateway 不要的数据。

伯纳乌的王子
关注
  • 1
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
GRPC: 如何在 gRPC 服务中加入 Prometheus 监控？
pointgoal_io的博客
10-10 1297
本文将介绍如何在 gRPC 微服务中，加入 Prometheus 监控。 gRPC 函数的自动监控，将会在后续的文章中介绍，这里我们只介绍如何在 gRPC 代码中，实现 prometheus 监控。
从零开始搭建prometheus+grafana
qq_30966497的博客
01-17 367
从零开始搭建prometheus+grafana 一、grafana安装 1、官网下载rpm安装包 https://grafana.com/get 我下载的是 grafana-6.4.4-1.x86_64.rpm 2、切换到root，安装启动 yum localinstall grafana-6.4.4-1.x86_64.rpm service grafana-server start...
Prometheus完整搭建及实战各种监控
热门推荐
Derek彬的博客
04-30 1万+
一.Prometheus介绍 Prometheus（普罗米修斯）是一个最初在SoundCloud上构建的监控系统。自2012年成为社区开源项目，拥有非常活跃的开发人员和用户社区。为强调开源及独立维护，Prometheus于2016年加入云原生云计算基金会（CNCF），成为继Kubernetes之后的第二个托管项目。https://prometheus.iohttps://github.com/prometheus 作为新一代的监控框架，Prometheus 具有以下特点： • 多维数据模型：由度量名称和键
prometheus PromSQL使用小技巧
u012803274的博客
02-27 3353
前言 这个礼拜一面在找那个CrashLoopBackoff的原因，另一个是在尝试修复es报错Data too large的问题，还有一个任务就是解析告警规则了，因为新需求加了很多类型的告警，支持的维度也更多了，我们的告警使用的Prometheus + Alertmanager，之前的几篇博客也提到过，这里主要想记录一下我在解析规则这里，遇到的一些问题以及解法。 抛出问题 Counter类型计算过去一个时间段内的增量 举例问题：计算revision_request_count过去五分钟的请求次数？ 问题分析：
prometheus operator
最新发布
qq_31055683的博客
07-15 1132
Prometheus 开源的系统监控和报警框架，本身也是一个时序数据库（TSDB）
Prometheus入门
JesJiang的博客
06-07 243
下载地址https://prometheus.io/download/ tar xvfz prometheus.tar.gz cd prometheus 启动 ./prometheus –config.file=prometheus.yml 默认访问地址 http://localhost:9090/ 部分prometheus.yml配置 global: scrape_interv...
etcd监控-prometheus+grafana
qq522044637的博客
07-23 2646
etcd metrics etcd通过2379端口，metrics。可以访问http://etcd-ip:2379/metrics prometheus-etcd metric采集 配置文件内如如下 promethrus通过etcd的2379端口，采集metric cat > promethrus-etcd.yaml <<EOF global: scrape_interval: 10s scrape_configs: - job_name: etcd .
架构探险：从零开始写分布式服务架构
01-29
本篇将深入探讨如何从零开始构建一个分布式服务架构，涵盖一系列关键知识点。 1. **微服务概念**：分布式服务架构的核心思想是微服务架构，即构建应用程序为一组小型、可独立部署的服务，每个服务都有明确的业务...
从零开始写分布式服务架构pdf和源码
12-06
"从零开始写分布式服务架构"这本书籍结合源码，提供了一条深入理解并实践分布式架构的道路。 首先，我们要明白分布式服务架构的核心理念。分布式架构的目标是通过解耦各个组件，提高系统的可伸缩性、容错性和灵活性...
从零开始在linux中搭建Prometheus环境并启动
Freedomlalala的博客
10-11 501
1 下载 prometheus 压缩包 进入Prometheus官网https://prometheus.io/download ，下载里面的压缩包 prometheus-2.20.0.linux-amd64.tar.gz ，可以直接用命令下载此安装包。 wget https://github.com/prometheus/prometheus/releases/download/v2.20.0/prometheus-2.20.0.linux-amd64.tar.gz 如果因为网速不行，也可以下载到本地，
network_exporter：ICMP和MTR＆TCP端口和HTTP Get-网络Prometheus导出器
02-04
network_exporter ICMP＆MTR＆TCP端口和HTTP Get Prometheus导出器 该导出器收集ICMP，MTR，TCP端口或HTTP Get统计信息，并通过HTTP导出它们以供Prometheus使用。 产品特点 IPv4和IPv6支持 重新加载配置（按间隔或操作系统信号） 动态添加或删除目标，而不会影响当前正在运行的测试 目标可以在所有的主机或指定的人的名单中执行probe 可配置的日志记录级别和格式（文本或json） 可配置的DNS服务器 导出的指标 ping_up出口商状态 ping_targets活动目标数 ping_status ：Ping状态 p
promsql:软件包promsql导出* sql.DB统计信息作为Prometheus指标收集器
04-01
Promsql的 软件包promsql导出* sql.DB统计信息作为Prometheus指标收集器。 例子 package promsql_test import ( "bufio" "database/sql" "fmt" "net/http" "strings" "time" "github.com/johejo/promsql" _ "github.com/go-sql-driver/mysql" "github.com/prometheus/client_golang/prometheus" "github.com/prometheus/client_golang/prometheus/promhttp" ) func Example () { db , err := sql . Open ( "mysql" , "CONNECTION_STRING" )
Kubernetes监控体系(15)-peomethuse联邦集群
会哭的雨@的博客
07-13 348
联邦集群： 假设有三组项目，A组项目是web，B组项目是数据库，C组项目是业务，可以在每一组项目下部署一个prometheus server实例，然后由一个中心prometheus server负责收集各个组下的监控数据，具有这种特性的称为prometheus联邦集群 联邦集群配置： master1的prometheus server当成是中心节点： master2和node1当成是各项目组下收集数据的prometheus server 修改master1上的prometheus serv
Prometheus监控实战系列二十三：高可用与扩展性
青梅煮酒
03-27 1126
目前Prometheus在集群与扩展性方面的功能并不算强大，通过分级联邦的方式虽然可以解决扩展性的问题，但依然存着的一些不足之处。例如：多层结构使得Prometheus之间的网络变得复杂，我们不止要关注工作节点和目标之间的连接，也要关注主节点与工作节点的连接；工作节点根据设定的间隔获取目标指标，而主节点对于工作节点数据的抓取也存在着时间间隔，这可能导致主节点出现数据延迟的情况；最后，当所有的指标汇总到主节点时，可能会对其造成较大的压力，在资源的调配上需做好分配，以免引起主节点的崩溃。
prometheus连续查询_7.prometheus之查询API
weixin_32066337的博客
01-28 2143
一、格式概述二、表达式查询2.1 Instant queries(即时查询)2.2 范围查询三、查询元数据3.1 通过标签匹配器找到度量指标列表3.2 获取标签名3.3 查询标签值四、表达式查询结果格式4.1 范围向量4.2 瞬时向量4.3 标量4.4 字符串五、Targets目标六、Rules规则七、Alerts报警八、查询目标元数据九、Altermanagers警报管理器十、Status状态1...
【Sanic】Prometheus监控接入（QPS、P99等）
u011590738的博客
07-05 3917
【Prometheus】常见监控指标代码
【GO】26. golang iris prometheus grafana 监控
chen_peng7的博客
09-23 701
1.引入包 go get github.com/prometheus/client_golang 2.添加metrics路径 app.Get("/metrics", http.UnGzip, iris.FromStd(promhttp.Handler())) func UnGzip(ctx context.Context) { ctx.Gzip(false) ctx.Next() } 3.启动项目查看默认数据 4.Grafana添加模版 ...
prometheus高可用配置
null
08-16 6589
方案一 Thanos https://github.com/improbable-eng/thanos 部署要求： prometheus v2.2.1版本以上 go 1.10 以上版本 用户对象存储的数据库 安装thanos: go get -v -d github.com/improbable-eng/thanos/.. cd ${GOPATH}/src/github....
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值