一、环境准备

k8s集群角色 IP 主机名 配置
控制节点 192.168.199.131 master centos7.9 4核6G
工作节点 192.168.199.128 monitor centos7.9 4核4G
目标:
部署 prometheus、grafana、alertmanager,并且配置 prometheus 的动态、静态服务发现,实现对容器、物理节点、service、pod 等资源指标监控,并在 Grafana 的 web 界面展示prometheus 的监控指标,
然后通过配置自定义告警规则,通过 alertmanager 实现 qq、钉钉、微信报警。Promql 语法、prometheus 数据类型。

github:https://github.com/prometheus/prometheus

官网: https://prometheus.io

二、Prometheus概述

2.1 Prometheus介绍?

Prometheus 是一个开源的系统监控和报警系统,现在已经加入到 CNCF 基金会,成为继 k8s 之后第二 个在 CNCF 托管的项目,在 kubernetes 容器管理系统中,通常会搭配 prometheus 进行监控,同时也支持 多种 exporter 采集数据,还支持 pushgateway 进行数据上报,Prometheus 性能足够支撑上万台规模的集 群。

2.2 Prometheus特点

(1) 多维度数据模型

每一个时间序列数据都由 metric 度量指标名称和它的标签 labels 键值对集合唯一确定:

这个 metric 度量指标名称指定监控目标系统的测量特征(如:http_requests_total- 接收 http 请 求的总计数)。labels 开启了 Prometheus 的多维数据模型:对于相同的度量名称,通过不同标签列表的 结合, 会形成特定的度量维度实例。(例如:所有包含度量名称为/api/tracks 的 http 请求,打上 method=POST 的标签,则形成了具体的 http 请求)。这个查询语言在这些度量和标签列表的基础上进行过 滤和聚合。改变任何度量上的任何标签值,则会形成新的时间序列图。

(2)灵活的查询语言(PromQL)

可以对采集的 metrics 指标进行加法,乘法,连接等操作;

(3)可以直接在本地部署,不依赖其他分布式存储;

(4)通过基于 HTTP 的 pull 方式采集时序数据;

(5)可以通过中间网关 pushgateway 的方式把时间序列数据推送到 prometheus server 端;

(6)可通过服务发现或者静态配置来发现目标服务对象(targets)。

(7)有多种可视化图像界面,如 Grafana 等。

(8)高效的存储,每个采样数据占 3.5 bytes 左右,300 万的时间序列,30s 间隔,保留 60 天,消耗 磁盘大概 200G。

(9)做高可用,可以对数据做异地备份,联邦集群,部署多套 prometheus,pushgateway 上报数据

2.2.1 样本

在时间序列中的每一个点称为一个样本(sample),样本由以下三部分组成:

  1、指标(metric):指标名称和描述当前样本特征的 labelsets;

  2、时间戳(timestamp):一个精确到毫秒的时间戳;

  3、样本值(value): 一个 folat64 的浮点型数据表示当前样本的值。

表示方式:

通过如下表达方式表示指定指标名称和指定标签集合的时间序列:

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

例如,指标名称为 api_http_requests_total,标签为 method="POST" 和 handler="/messages" 的时间序列可以表示为:

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

3.Prometheus组件介绍

(1) Prometheus Server: 用于收集和存储时间序列数据。

(2) Client Library: 客户端库,检测应用程序代码,当 Prometheus 抓取实例的 HTTP 端点时,客户 端库会将所有跟踪的 metrics 指标的当前状态发送到 prometheus server 端。

(3) Exporters: prometheus 支持多种 exporter,通过 exporter 可以采集 metrics 数据,然后发送到 prometheus server 端,所有向 promtheus server 提供监控数据的程序都可以被称为 exporter

(4) Alertmanager: 从 Prometheus server 端接收到 alerts 后,会进行去重,分组,并路由到相应 的接收方,发出报警,常见的接收方式有:电子邮件,微信,钉钉, slack 等。

(5) Grafana:监控仪表盘,可视化监控数据

(6) pushgateway: 各个目标主机可上报数据到 pushgateway,然后 prometheus server 统一从 pushgateway 拉取数据

从上图可发现,Prometheus 整个生态圈组成主要包括 prometheus server,Exporter, pushgateway,alertmanager,grafana,Web ui 界面,Prometheus server 由三个部分组成, Retrieval,Storage,PromQL

  1.Retrieval 负责在活跃的 target 主机上抓取监控指标数据

  2.Storage 存储主要是把采集到的数据存储到磁盘中

  3.PromQL 是 Prometheus 提供的查询语言模块。

4.Prometheus工作流程

(1) Prometheus server 可定期从活跃的(up)目标主机上(target)拉取监控指标数据,目标主机的监控数据可通过配置静态 job 或者服务发现的方式被 prometheus server 采集到,这种方式默认的 pull 方式拉取指标;也可通过 pushgateway 把采集的数据上报到 prometheus server 中;还可通过一些组件 自带的 exporter 采集相应组件的数据;

(2) Prometheus server 把采集到的监控指标数据保存到本地磁盘或者数据库;

(3) Prometheus 采集的监控指标数据按时间序列存储,通过配置报警规则,把触发的报警发送到 alertmanager

(4) Alertmanager 通过配置报警接收方,发送报警到邮件,微信或者钉钉等

(5) Prometheus 自带的 web ui 界面提供 PromQL 查询语言,可查询监控数据

(6) .Grafana 可接入 prometheus 数据源,把监控数据以图形化形式展示出

5.Prometheus 和 zabbix 对比分析

6.Prometheus的集中部署模式

6.1 基本高可用模式

基本的 HA 模式只能确保 Promthues 服务的可用性问题,但是不解决 Prometheus Server 之间的数据 一致性问题以及持久化问题(数据丢失后无法恢复),也无法进行动态的扩展。因此这种部署方式适合监控规模不大,Promthues Server 也不会频繁发生迁移的情况,并且只需要保存短周期监控数据的场景。

6.2 基本高可用+远程存储

在解决了 Promthues 服务可用性的基础上,同时确保了数据的持久化,当 Promthues Server 发生宕机或者数据丢失的情况下,可以快速的恢复。 同时 Promthues Server 可能很好的进行迁移。因此,该方案适用于用户监控规模不大,但是希望能够将监控数据持久化,同时能够确保 Promthues Server 的可迁移性的场景。

6.3 基本HA+远程存储+联邦集群方案

Promthues 的性能瓶颈主要在于大量的采集任务,因此用户需要利用 Prometheus 联邦集群的特性, 将不同类型的采集任务划分到不同的 Promthues 子服务中,从而实现功能分区。

例如一个 Promthues Server 负责采集基础设施相关的监控指标,另外一个 Prometheus Server 负责采集应用监控指标。再有上层 Prometheus Server 实现对数据的汇聚。

7.Prometheus 的四种数据类型

7.1 Counter

Counter 是计数器类型:

  1、Counter 用于累计值,例如记录请求次数、任务完成数、错误发生次数。

  2、一直增加,不会减少。

  3、重启进程后,会被重置。

  例如:

  http_response_total{method="GET",endpoint="/api/tracks"} 100

  http_response_total{method="GET",endpoint="/api/tracks"} 160

Counter 类型数据可以让用户方便的了解事件产生的速率的变化,在 PromQL 内置的相关操作函数可以提供相应的分析,比如以 HTTP 应用请求量来进行说明:

  1、通过 rate()函数获取 HTTP 请求量的增长率:rate(http_requests_total[5m])

  2、查询当前系统中,访问量前 10 的 HTTP 地址:topk(10, http_requests_total)

7.2 Gauge

Gauge 是测量器类型:

  1、Gauge 是常规数值,例如温度变化、内存使用变化。

  2、可变大,可变小。

  3、重启进程后,会被重置

  例如:

  memory_usage_bytes{host="master-01"} 100

  memory_usage_bytes{host="master-01"} 30

  memory_usage_bytes{host="master-01"} 50

  memory_usage_bytes{host="master-01"} 80

对于 Gauge 类型的监控指标,通过 PromQL 内置函数 delta() 可以获取样本在一段时间内的变化情况,例如,计算 CPU 温度在两小时内的差异:

  dalta(cpu_temp_celsius{host="zeus"}[2h])

还可以通过 PromQL 内置函数 predict_linear() 基于简单线性回归的方式,对样本数据的变化趋势做出预测。

例如,基于 2 小时的样本数据,来预测主机可用磁盘空间在 4 个小时之后的剩余情况:

  predict_linear(node_filesystem_free{job="node"}[2h], 4 * 3600) < 0

7.3 histogram

histogram 是柱状图,在 Prometheus 系统的查询语言中,有三种作用:

  1、在一段时间范围内对数据进行采样(通常是请求持续时间或响应大小等),并将其计入可配置的 存储桶(bucket)中. 后续可通过指定区间筛选样本,也可以统计样本总数,最后一般将数据展示为直 方图。

  2、对每个采样点值累计和(sum)

  3、对采样点的次数累计和(count)

度量指标名称: [basename]_上面三类的作用度量指标名称

  1、[basename]_bucket{le="上边界"}, 这个值为小于等于上边界的所有采样点数量

  2、[basename]_sum

  3、[basename]_count

小结:如果定义一个度量类型为 Histogram,则 Prometheus 会自动生成三个对应的指标

7.3.1 为什需要用 histogram 柱状图?

在大多数情况下人们都倾向于使用某些量化指标的平均值,例如 CPU 的平均使用率、页面的平均响 应时间。这种方式的问题很明显,以系统 API 调用的平均响应时间为例:如果大多数 API 请求都维持 在 100ms 的响应时间范围内,而个别请求的响应时间需要 5s,那么就会导致某些 WEB 页面的响应时间 落到中位数的情况,而这种现象被称为长尾问题。

为了区分是平均的慢还是长尾的慢,最简单的方式就是按照请求延迟的范围进行分组。例如,统计 延迟在 0~10ms 之间的请求数有多少,而 10~20ms 之间的请求数又有多少。通过这种方式可以快速分析系统慢的原因。Histogram 和 Summary 都是为了能够解决这样问题的存在,通过 Histogram 和 Summary 类型的监控指标,我们可以快速了解监控样本的分布情况。

Histogram 类型的样本会提供三种指标(假设指标名称为 ):

  样本的值分布在 bucket 中的数量,命名为 _bucket{le="<上边界>"}。解释的更通俗易 懂一点,这个值表示指标值小于等于上边界的所有样本数量。

(1)、在总共 2 次请求当中。http 请求响应时间 <=0.005 秒 的请求次数为 0

  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code= "200",le="0.005",} 0.0

(2)、在总共 2 次请求当中。http 请求响应时间 <=0.01 秒 的请求次数为 0

  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200 ",le="0.01",} 0.0

(3)、在总共 2 次请求当中。http 请求响应时间 <=0.025 秒 的请求次数为 0

  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200 ",le="0.025",} 0.0

  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code= "200",le="0.05",} 0.0

  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code= "200",le="0.075",} 0.0

  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code= "200",le="0.1",} 0.0

  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code= "200",le="0.25",} 0.0

  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code= "200",le="0.5",} 0.0

  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code= "200",le="0.75",} 0.0

  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code= "200",le="1.0",} 0.0

  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code= "200",le="2.5",} 0.0

  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code= "200",le="5.0",} 0.0

  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code= "200",le="7.5",} 2.0

(4)、在总共 2 次请求当中。http 请求响应时间 <=10 秒 的请求次数为 2

  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code= "200",le="10.0",} 2.0

  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code= "200",le="+Inf",} 2.0

  所有样本值的大小总和,命名为 _sum。

(5)、实际含义: 发生的 2 次 http 请求总的响应时间为 13.107670803000001 秒

  io_namespace_http_requests_latency_seconds_histogram_sum{path="/",method="GET",code="20 0",} 13.107670803000001

  样本总数,命名为 _count。值和 _bucket{le="+Inf"} 相同。

(6)、实际含义: 当前一共发生了 2 次 http 请求

  io_namespace_http_requests_latency_seconds_histogram_count{path="/",method="GET",code=" 200",} 2.0

注意:

bucket 可以理解为是对数据指标值域的一个划分,划分的依据应该基于数据值的分布。注意后面的 采样点是包含前面的采样点的,假设 xxx_bucket{...,le="0.01"} 的值为 10,而xxx_bucket{...,le="0.05"} 的值为 30,那么意味着这 30 个采样点中,有 10 个是小于 0.01s 的,其 余 20 个采样点的响应时间是介于 0.01s 和 0.05s 之间的。

可以通过 histogram_quantile() 函数来计算 Histogram 类型样本的分位数。分位数可能不太好理 解,你可以理解为分割数据的点。我举个例子,假设样本的 9 分位数(quantile=0.9)的值为 x,即表 示小于 x 的采样值的数量占总体采样值的 90%。Histogram 还可以用来计算应用性能指标值(Apdex score)。

7.4 summary

与 Histogram 类型类似,用于表示一段时间内的数据采样结果(通常是请求持续时间或响应大小 等),但它直接存储了分位数(通过客户端计算,然后展示出来),而不是通过区间来计算。它也有三种 作用:

  1、对于每个采样点进行统计,并形成分位图。(如:正态分布一样,统计低于 60 分不及格的同 学比例,统计低于 80 分的同学比例,统计低于 95 分的同学比例)

  2、统计班上所有同学的总成绩(sum)

  3、统计班上同学的考试总人数(count)

带有度量指标的[basename]的 summary 在抓取时间序列数据有如命名。

  1、观察时间的φ-quantiles (0 ≤ φ ≤ 1), 显示为[basename]{分位数="[φ]"}

  2、[basename]_sum, 是指所有观察值的总和

  3、[basename]_count, 是指已观察到的事件计数值

样本值的分位数分布情况,命名为 {quantile="<φ>"}。

  1、含义:这 12 次 http 请求中有 50% 的请求响应时间是 3.052404983s

    io_namespace_http_requests_latency_seconds_summary{path="/",method="GET",code="200",quantil e="0.5",} 3.052404983

  2、含义:这 12 次 http 请求中有 90% 的请求响应时间是 8.003261666s

    io_namespace_http_requests_latency_seconds_summary{path="/",method="GET",code="200",quantil e="0.9",} 8.003261666

所有样本值的大小总和,命名为 _sum。

  1、含义:这 12 次 http 请求的总响应时间为 51.029495508s

    io_namespace_http_requests_latency_seconds_summary_sum{path="/",method="GET",code="200",} 51.029495508

样本总数,命名为 _count。

  1、含义:当前一共发生了 12 次 http 请求

    io_namespace_http_requests_latency_seconds_summary_count{path="/",method="GET",code="200",} 12.0

现在可以总结一下 Histogram 与 Summary 的异同:
  1.它们都包含了 <basename>_sum 和 <basename>_count 指标
  2.Histogram 需要通过 <basename>_bucket 来计算分位数,而 Summary 则直接存储了分位数的值。
    prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.5"} 0.012352463
    prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.9"} 0.014458005
    prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.99"} 0.017316173
    prometheus_tsdb_wal_fsync_duration_seconds_sum 2.888716127000002
    prometheus_tsdb_wal_fsync_duration_seconds_count 216
从上面的样本中可以得知当前 Promtheus Server 进行 wal_fsync 操作的总次数为 216 次,耗时2.888716127000002s。其中中位数(quantile=0.5)的耗时为 0.012352463,9 分位数(quantile=0.9)
的耗时为 0.014458005s。

 8.Prometheus能监控什么?

• Databases
• Hardware related
• Messaging systems
• Storage
• HTTP
• APIs
• Logging
• Other monitoring systems
• Miscellaneous
• Software exposing Prometheus metrics
# 1.databases数据库
• Aerospike exporter
• ClickHouse exporter
• Consul exporter (official)
• Couchbase exporter
• CouchDB exporter
• ElasticSearch exporter
• EventStore exporter
• Memcached exporter (official)
• MongoDB exporter
• MSSQL server exporter
• MySQL server exporter (official)
• OpenTSDB Exporter
• Oracle DB Exporter
• PgBouncer exporter
• PostgreSQL exporter
• ProxySQL exporter
• RavenDB exporter
• Redis exporter
• RethinkDB exporter
• SQL exporter
• Tarantool metric library
• Twemproxy # 2.Hardware Related 硬件设备相关
• apcupsd exporter
• Collins exporter
• IBM Z HMC exporter
• IoT Edison exporter
• IPMI exporter
• knxd exporter
• Netgear Cable Modem Exporter
• Node/system metrics exporter (official)
• NVIDIA GPU exporter
• ProSAFE exporter
• Ubiquiti UniFi exporter # 3.Messaging systems-消息服务
• Beanstalkd exporter
• Gearman exporter
• Kafka exporter
• NATS exporter
• NSQ exporter
• Mirth Connect exporter
• MQTT blackbox exporter
• RabbitMQ exporter
• RabbitMQ Management Plugin exporter # 4.Storage-存储
• Ceph exporter
• Ceph RADOSGW exporter
• Gluster exporter
• Hadoop HDFS FSImage exporter
• Lustre exporter
• ScaleIO exporter # 5.http-网站服务
• Apache exporter
• HAProxy exporter (official)
• Nginx metric library
• Nginx VTS exporter
• Passenger exporter
• Squid exporter
• Tinyproxy exporter
• Varnish exporter
• WebDriver exporter # 6.API
• AWS ECS exporter
• AWS Health exporter
• AWS SQS exporter
• Cloudflare exporter
• DigitalOcean exporter
• Docker Cloud exporter
• Docker Hub exporter
• GitHub exporter
• InstaClustr exporter
• Mozilla Observatory exporter
• OpenWeatherMap exporter
• Pagespeed exporter
• Rancher exporter
• Speedtest exporter # 7.Logging 日志
• Fluentd exporter
• Google's mtail log data extractor
• Grok exporter # 8.Other monitoring systems
• Akamai Cloudmonitor exporter
• Alibaba Cloudmonitor exporter
• AWS CloudWatch exporter (official)
• Cloud Foundry Firehose exporter
• Collectd exporter (official)
• Google Stackdriver exporter
• Graphite exporter (official)
• Heka dashboard exporter
• Heka exporter
• InfluxDB exporter (official)
• JavaMelody exporter
• JMX exporter (official)
• Munin exporter
• Nagios / Naemon exporter
• New Relic exporter
• NRPE exporter
• Osquery exporter
• OTC CloudEye exporter
• Pingdom exporter
• scollector exporter
• Sensu exporter
• SNMP exporter (official)
• StatsD exporter (official) # 9.Miscellaneous-其他
• ACT Fibernet Exporter
• Bamboo exporter
• BIG-IP exporter
• BIND exporter
• Bitbucket exporter
• Blackbox exporter (official)
• BOSH exporter
• cAdvisor 收集容器日志
• Cachet exporter
• ccache exporter
• Confluence exporter
• Dovecot exporter
• eBPF exporter
• Ethereum Client exporter
• Jenkins exporter
• JIRA exporter
• Kannel exporter
• Kemp LoadBalancer exporter
• Kibana Exporter
• Meteor JS web framework exporter
• Minecraft exporter module
• PHP-FPM exporter
• PowerDNS exporter
• Presto exporter
• Process exporter
• rTorrent exporter
• SABnzbd exporter
• Script exporter
• Shield exporter
• SMTP/Maildir MDA blackbox prober
• SoftEther exporter
• Transmission exporter
• Unbound exporter
• Xen exporter # 10.Software exposing Prometheus metrics-Prometheus 软件/度量指标
• App Connect Enterprise
• Ballerina
• Ceph
• Collectd
• Concourse
• CRG Roller Derby Scoreboard (direct)
• Docker Daemon
• Doorman (direct)
• Etcd (direct)
• Flink
• FreeBSD Kernel
• Grafana
• JavaMelody
• Kubernetes (direct)
• Linkerd

 9.Prometheus对kubernetes的监控

对于 Kubernetes 而言,我们可以把当中所有的资源分为几类:

  • 基础设施层(Node):集群节点,为整个集群和应用提供运行时资源(物理机、云主机、虚拟机等)

  • 容器基础设施(Container):为应用提供运行时环境

  • 用户应用(Pod):Pod 中会包含一组容器,它们一起工作,并且对外提供一个(或者一 组)功能

  • 内部服务负载均衡(Service):在集群内,通过 Service 在集群暴露应用功能,集群内 应用和应用之间访问时提供内部的负载均衡

  • 外部访问入口(Ingress):通过 Ingress 提供集群外的访问入口,从而可以使外部客户 端能够访问到部署在 Kubernetes 集群内的服务

因此,如果要构建一个完整的监控体系,我们应该考虑,以下 5 个方面:

  • 集群节点状态监控:从集群中各节点的 kubelet 服务获取节点的基本运行状态;

  • 集群节点资源用量监控:通过 Daemonset 的形式在集群中各个节点部署 Node Exporter 采集节点的资源使用情况;

  • 节点中运行的容器监控:通过各个节点中 kubelet 内置的 cAdvisor 中获取个节点中所有 容器的运行状态和资源使用情况;

  • 如果在集群中部署的应用程序本身内置了对 Prometheus 的监控支持,那么我们还应该找 到相应的 Pod 实例,并从该 Pod 实例中获取其内部运行状态的监控指标。

  • 对 k8s 本身的组件做监控:apiserver、scheduler、controller-manager、kubelet、 kube-proxy

10.node-exporter 组件安装和配置(收集物理节点信息)

规划:k8s集群:一个master和一个node节点

master IP:192.168.199.131      主机名:master

node节点IP:192.168.199.128  主机名:monitor

# node-exporter介绍
node-exporter 可以采集机器(物理机、虚拟机、云主机等)的监控指标数据,能够采集到的指标包 括 CPU, 内存,磁盘,网络,文件数等信息。

10.1 安装node-exporter

# 1.创建名称空间
[root@master ~]# kubectl create ns monitor-sa
namespace/monitor-sa created # 2.下载node-exporter镜像压缩包到k8s各个节点并解压
docker load -i node-exporter.tar.gz
Loaded image: prom/node-exporter:v0.16.0 github:https://github.com/prometheus/node_exporter/releases
dockerhub:https://hub.docker.com/r/quboleinc/node_exporter/tags [root@master prometheus]# kubectl apply -f node-export.yaml
daemonset.apps/node-exporter created
[root@master prometheus]# kubectl get pods -n monitor-sa -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
node-exporter-bg78z 1/1 Running 0 101s 192.168.199.131 master <none> <none>
node-exporter-c6hlb 1/1 Running 0 101s 192.168.199.128 monitor <none> <none>

apiVersion: apps/v1
kind: DaemonSet #可以保证k8s集群每隔节点都运行一样的pod
metadata:
name: node-exporter
namespace: monitor-sa
labels:
name: node-exporter
spec:
selector:
matchLabels:
name: node-exporter
template:
metadata:
labels:
name: node-exporter
spec:
hostPID: true
hostIPC: true
hostNetwork: true
# hostNetwork、hostIPC、hostPID 都为 True 时,表示这个 Pod 里的所有容器,会直接使用宿主机的网络,直接与宿主机进行 IPC(进程间通信)通信,可以看到宿主机里正在运行的所有进程。
加入了 hostNetwork:true 会直接将我们的宿主机的 9100 端口映射出来,从而不需要创建 service 在我们的宿主机上就会有一个 9100 的端口
containers:
- name: node-exporter
image: prom/node-exporter:v0.16.0
imagePullPolicy: IfNotPresent
ports:
- containerPort: 9100
resources:
requests:
cpu: 0.15 #这个容器运行至少需要 0.15 核 cpu
securityContext:
privileged: true #开启特权模式
args:
- --path.procfs #配置挂载宿主机(node 节点)的路径
- /host/proc
- --path.sysfs
- /host/sys
- --collector.filesystem.ignored-mount-points
- '"^/(sys|proc|dev|host|etc)($|/)"' #通过正则表达式忽略某些文件系统挂载点的信息收集
volumeMounts:
- name: dev
mountPath: /host/dev
- name: proc
mountPath: /host/proc
- name: sys
mountPath: /host/sys
- name: rootfs
mountPath: /rootfs
#将主机/dev、/proc、/sys 这些目录挂在到容器中,这是因为我们采集的很多节点数据都是通过这些文件来获取系统信息的。
tolerations:
- key: "node-role.kubernetes.io/master"
operator: "Exists"
effect: "NoSchedule"
volumes:
- name: proc
hostPath:
path: /proc
- name: dev
hostPath:
path: /dev
- name: sys
hostPath:
path: /sys
- name: rootfs
hostPath:
path: /

node-export.yaml

通过node-exporter采集数据

curl http://主机:9100/metrics

#node-export 默认的监听端口是 9100,可以看到当前主机获取到的所有监控数据

# 主机 cpu 的使用情况
[root@master prometheus]# curl http://192.168.199.131:9100/metrics | grep node_cpu_seconds
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 67877 100 67877 0 0 9522k 0 --:--:-- --:--:-- --:--:-- 10.7M
# HELP node_cpu_seconds_total Seconds the cpus spent in each mode.
# TYPE node_cpu_seconds_total counter
node_cpu_seconds_total{cpu="0",mode="idle"} 17998.73
node_cpu_seconds_total{cpu="0",mode="iowait"} 5.74
node_cpu_seconds_total{cpu="0",mode="irq"} 0
node_cpu_seconds_total{cpu="0",mode="nice"} 0.01
node_cpu_seconds_total{cpu="0",mode="softirq"} 31.18
node_cpu_seconds_total{cpu="0",mode="steal"} 0
node_cpu_seconds_total{cpu="0",mode="system"} 312.73
node_cpu_seconds_total{cpu="0",mode="user"} 138.94
node_cpu_seconds_total{cpu="1",mode="idle"} 18039.41
node_cpu_seconds_total{cpu="1",mode="iowait"} 4.58
node_cpu_seconds_total{cpu="1",mode="irq"} 0
node_cpu_seconds_total{cpu="1",mode="nice"} 0.01
node_cpu_seconds_total{cpu="1",mode="softirq"} 25.46
node_cpu_seconds_total{cpu="1",mode="steal"} 0
node_cpu_seconds_total{cpu="1",mode="system"} 311.16
node_cpu_seconds_total{cpu="1",mode="user"} 130.6
node_cpu_seconds_total{cpu="2",mode="idle"} 18032.72
node_cpu_seconds_total{cpu="2",mode="iowait"} 5.99
node_cpu_seconds_total{cpu="2",mode="irq"} 0
node_cpu_seconds_total{cpu="2",mode="nice"} 0
node_cpu_seconds_total{cpu="2",mode="softirq"} 27.06
node_cpu_seconds_total{cpu="2",mode="steal"} 0
node_cpu_seconds_total{cpu="2",mode="system"} 309
node_cpu_seconds_total{cpu="2",mode="user"} 133.23
node_cpu_seconds_total{cpu="3",mode="idle"} 18030.87
node_cpu_seconds_total{cpu="3",mode="iowait"} 6.66
node_cpu_seconds_total{cpu="3",mode="irq"} 0
node_cpu_seconds_total{cpu="3",mode="nice"} 0
node_cpu_seconds_total{cpu="3",mode="softirq"} 24.58
node_cpu_seconds_total{cpu="3",mode="steal"} 0
node_cpu_seconds_total{cpu="3",mode="system"} 307.78
node_cpu_seconds_total{cpu="3",mode="user"} 140.79

cpu使用情况

#HELP:解释当前指标的含义,上面表示在每种模式下 node 节点的 cpu 花费的时间,以 s 为单位

#TYPE:说明当前指标的数据类型,上面是 counter 类型

  node_cpu_seconds_total{cpu="0",mode="idle"}  # cpu0 上 idle 进程占用 CPU 的总时间,CPU 占用时间是一个只增不减的度量指标,从类型中也可以看 出 node_cpu 的数据类型是 counter(计数器)

counter 计数器:只是采集递增的指标

平均负载:

# 如果要看节点的信息,IP替换为节点就行

[root@master prometheus]# curl http://192.168.199.131:9100/metrics | grep node_load
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 67833 100 67833 0 0 8453k 0 --:--:-- --:--:-- --:--:-- 9463k
# HELP node_load1 1m load average.
# TYPE node_load1 gauge
node_load1 0.07
# HELP node_load15 15m load average.
# TYPE node_load15 gauge
node_load15 0.25
# HELP node_load5 5m load average.
# TYPE node_load5 gauge
node_load5 0.22

node_load1 该指标反映了当前主机在最近一分钟以内的负载情况,系统的负载情况会随系统资源的 使用而变化,因此 node_load1 反映的是当前状态,数据可能增加也可能减少,从注释中可以看出当前指 标类型为 gauge(标准尺寸)

gauge 标准尺寸:统计的指标可增加可减少

11. Prometheus server 安装和配置

11.1 创建sa账号,对sa做rbac授权

# 创建一个sa账号monitor
[root@master prometheus]# kubectl create serviceaccount monitor -n monitor-sa
serviceaccount/monitor created
[root@master prometheus]# kubectl get sa -n monitor-sa
NAME SECRETS AGE
default 1 76m
monitor 1 49s # 把 sa 账号 monitor 通过 clusterrolebing 绑定到 clusterrole 上
[root@master prometheus]# kubectl create clusterrolebinding monitor-clusterrolebinding -n monitor-sa --clusterrole=cluster-admin --serviceaccount=monitor-sa:monitor
clusterrolebinding.rbac.authorization.k8s.io/monitor-clusterrolebinding created

11.2 创建prometheus数据存储目录

# 在monitor节点创建数据目录
[root@monitor ~]# mkdir /data
[root@monitor ~]# chmod 777 /data

11.3 安装Prometheus server 服务

11.3.1 创建configmap存储卷,用来存放prometheus配置信息

# 服务发现基于node或者endpoint
[root@master prometheus]# cat prometheus-cfg.yaml
---
kind: ConfigMap
apiVersion: v1
metadata:
labels:
app: prometheus
name: prometheus-config
namespace: monitor-sa
data:
prometheus.yml: |
global:
scrape_interval: 15s # 采集目标主机监控据的时间间隔
scrape_timeout: 10s # 数据采集超时时间,默认 10s
evaluation_interval: 1m # 触发告警检测的时间,默认是 1m
scrape_configs: # 配置数据源,称为 target,每个 target 用 job_name 命名。又分为静态配置和服务发现
- job_name: 'kubernetes-node'
kubernetes_sd_configs: #使用的是 k8s 的服务发现
- role: node # 使用 node 角色,它使用默认的 kubelet 提供的 http 端口来发现集群中每个 node 节点。
relabel_configs: #重新标记
- source_labels: [__address__] #配置的原始标签,匹配地址
regex: '(.*):10250' #匹配带有 10250 端口的 url
replacement: '${1}:9100' #把匹配到的 ip:10250 的 ip 保留
target_label: __address__ #新生成的 url 是${1}获取到的 ip:9100
action: replace
- action: labelmap
#匹配到下面正则表达式的标签会被保留,如果不做 regex 正则的话,默认只是会显示 instance 标签
regex: __meta_kubernetes_node_label_(.+)
- job_name: 'kubernetes-node-cadvisor' # 抓取 cAdvisor 数据,是获取 kubelet 上/metrics/cadvisor 接口数据来获取容器的资源使用情况
kubernetes_sd_configs:
- role: node
scheme: https
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
relabel_configs:
- action: labelmap # 把匹配到的标签保留
regex: __meta_kubernetes_node_label_(.+) #保留匹配到的具有__meta_kubernetes_node_label 的标签
- target_label: __address__ #获取到的地址:__adress__=192.168.199.131:10250
replacement: kubernetes.default.svc:443 #把获取到的地址替换成新的地址 kubernetes.default.svc:443
- source_labels: [__meta_kubernetes_node_name] #把原始标签中__meta_kubernetes_node_name 值匹配到target_label
regex: (.+)
target_label: __metrics_path__ #获取__metrics_path__对应的值
replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor
     # #把 metrics 替换成新的值 api/v1/nodes/master/proxy/metrics/cadvisor
     # ${1}是__meta_kubernetes_node_name 获取到的值
     # 新的 url 就是 https://kubernetes.default.svc:443/api/v1/nodes/master/proxy/metrics/cadvisor

- job_name: 'kubernetes-apiserver'
kubernetes_sd_configs:
- role: endpoints #使用 k8s 中的 endpoint 服务发现,采集 apiserver 6443 端口获取到的数据
scheme: https
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
relabel_configs:
    #endpoint 这个对象的名称空间kubectl get ep,endpoint对象服务名,endpoint的端口名称
- source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
action: keep #采集满足条件的实例,其他实例不采集
regex: default;kubernetes;https #正则匹配到的默认空间下的 service 名字是 kubernetes,协议是 https 的 endpoint 类型保留下来
- job_name: 'kubernetes-service-endpoints'
kubernetes_sd_configs:
- role: endpoints
relabel_configs:
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
action: keep
regex: true
# 重新打标仅抓取到的具有 "prometheus.io/scrape: true" 的 annotation 的端点,意思是说如果某个 service 具有 prometheus.io/scrape = true annotation 声明则抓取,annotation本身也是键值结构,
所以这里的源标签设置为键,而 regex 设置值 true,当值匹配到 regex 设定的内容时则执行 keep 动作也就是保留,其余则丢弃。

- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
action: replace
target_label: __scheme__
regex: (https?)
#重新设置 scheme,匹配源标签__meta_kubernetes_service_annotation_prometheus_io_scheme 也就是 prometheus.io/scheme annotation,如果源标签的值匹配到 regex,则把值替换为__scheme__对应的值。

- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
action: replace
target_label: __metrics_path__
regex: (.+)
# 应用中自定义暴露的指标,也许你暴露的 API 接口不是/metrics 这个路径,那么你可以在这个 POD 对应的 service 中做一个"prometheus.io/path = /mymetrics" 声明,上面的意思就是把你声明的这 个路径赋值
给__metrics_path__,其实就是让 prometheus 来获取自定义应用暴露的 metrices 的具体路 径,不过这里写的要和 service 中做好约定,如果 service 中这样写 prometheus.io/app-metricspath: '/metrics'
那么你这里就要 __meta_kubernetes_service_annotation_prometheus_io_app_metrics_path 这样写。

- source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]
action: replace
target_label: __address__
regex: ([^:]+)(?::\d+)?;(\d+)
replacement: $1:$2
# 暴露自定义的应用的端口,就是把地址和你在 service 中定义的 "prometheus.io/port = " 声明做一个拼接,然后赋值给__address__,这样 prometheus 就能获取自定义应用的端口,然后通过这个端口再结合
__metrics_path__来获取指标,如果__metrics_path__值不是默认的/metrics 那 么就要使用上面的标签替换来获取真正暴露的具体路径。

- action: labelmap #保留下面匹配到的标签
regex: __meta_kubernetes_service_label_(.+)
- source_labels: [__meta_kubernetes_namespace]
action: replace #替换__meta_kubernetes_namespace 变成 kubernetes_namespace
target_label: kubernetes_namespace
- source_labels: [__meta_kubernetes_service_name]
action: replace
target_label: kubernetes_name

[root@master prometheus]# kubectl apply -f prometheus-cfg.yaml
configmap/prometheus-config created

[root@master prometheus]# kubectl get configmap -n monitor-sa
NAME DATA AGE
kube-root-ca.crt 1 154m
prometheus-config 1 4m14s [root@master prometheus]# kubectl describe configmap prometheus-config -n monitor-sa
Name: prometheus-config
Namespace: monitor-sa
Labels: app=prometheus
Annotations: <none> Data
====
prometheus.yml:定义了全局配置、scrape_configs
----
....
...

---
kind: ConfigMap
apiVersion: v1
metadata:
labels:
app: prometheus
name: prometheus-config
namespace: monitor-sa
data:
prometheus.yml: |
global:
scrape_interval: 15s
scrape_timeout: 10s
evaluation_interval: 1m
scrape_configs:
- job_name: 'kubernetes-node'
kubernetes_sd_configs:
- role: node
relabel_configs:
- source_labels: [__address__]
regex: '(.*):10250'
replacement: '${1}:9100'
target_label: __address__
action: replace
- action: labelmap
regex: __meta_kubernetes_node_label_(.+)
- job_name: 'kubernetes-node-cadvisor'
kubernetes_sd_configs:
- role: node
scheme: https
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
relabel_configs:
- action: labelmap
regex: __meta_kubernetes_node_label_(.+)
- target_label: __address__
replacement: kubernetes.default.svc:443
- source_labels: [__meta_kubernetes_node_name]
regex: (.+)
target_label: __metrics_path__
replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor
- job_name: 'kubernetes-apiserver'
kubernetes_sd_configs:
- role: endpoints
scheme: https
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, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
action: keep
regex: default;kubernetes;https
- job_name: 'kubernetes-service-endpoints'
kubernetes_sd_configs:
- role: endpoints
relabel_configs:
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
action: keep
regex: true
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
action: replace
target_label: __scheme__
regex: (https?)
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
action: replace
target_label: __metrics_path__
regex: (.+)
- source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]
action: replace
target_label: __address__
regex: ([^:]+)(?::\d+)?;(\d+)
replacement: $1:$2
- action: labelmap
regex: __meta_kubernetes_service_label_(.+)
- source_labels: [__meta_kubernetes_namespace]
action: replace
target_label: kubernetes_namespace
- source_labels: [__meta_kubernetes_service_name]
action: replace
target_label: kubernetes_name

prometheus-cfg.yaml

 11.3.2 安装Prometheus

# 下载promethus镜像并上传到工作节点monitor进行加载
[root@monitor ~]# docker load -i prometheus-2-2-1.tar.gz
Loaded image: prom/prometheus:v2.2.1 [root@master prometheus]# kubectl apply -f prometheus-deploy.yaml
deployment.apps/prometheus-server created
[root@master prometheus]# kubectl get pods -n monitor-sa -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
node-exporter-bg78z 1/1 Running 0 123m 192.168.199.131 master <none> <none>
node-exporter-c6hlb 1/1 Running 0 123m 192.168.199.128 monitor <none> <none>
prometheus-server-64f6fd555f-sgw67 1/1 Running 0 29s 10.244.75.193 monitor <none> <none>
# prometheus-server的IP是不能访问的,需要创建服务
[root@master prometheus]# kubectl apply -f prometheus-svc.yaml
service/prometheus created
[root@master prometheus]# kubectl get svc -n monitor-sa
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
prometheus NodePort 10.106.76.183 <none> 9090:30051/TCP 55s

访问:service在宿主机上映射的端口是30051,访问k8s集群master节点:192.168.199.131:30051就可以访问到prometheus的web ui界面了

注意:在下面的 prometheus-deploy.yaml 文件有个 nodeName 字段,这个就是用来指定创建的这个 prometheus 的 pod 调度到哪个节点上,我们这里让 nodeName=monitor也即是让 pod 调度到monitor节点上,因为在monitor
节点创建了数据目录/data,所以:你在 k8s 集群的哪个节点创建/data,就让 pod 调度到哪个节点,nodeName 根据你们自己环境主机去修改即可。

[root@master prometheus]# cat prometheus-deploy.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: prometheus-server
namespace: monitor-sa
labels:
app: prometheus
spec:
replicas: 1
selector:
matchLabels:
app: prometheus
component: server
#matchExpressions:
#- {key: app, operator: In, values: [prometheus]}
#- {key: component, operator: In, values: [server]}
template:
metadata:
labels:
app: prometheus
component: server
annotations:
prometheus.io/scrape: 'false'
spec:
nodeName: monitor
serviceAccountName: monitor
containers:
- name: prometheus
image: prom/prometheus:v2.2.1
imagePullPolicy: IfNotPresent
command:
- prometheus
- --config.file=/etc/prometheus/prometheus.yml
- --storage.tsdb.path=/prometheus # 旧数据存储目录
- --storage.tsdb.retention=720h # 默认保留15天后删除
- --web.enable-lifecycle # 开机热加载
ports:
- containerPort: 9090
protocol: TCP
volumeMounts:
- mountPath: /etc/prometheus/prometheus.yml
name: prometheus-config
subPath: prometheus.yml
- mountPath: /prometheus/
name: prometheus-storage-volume
volumes:
- name: prometheus-config
configMap:
name: prometheus-config
items:
- key: prometheus.yml
path: prometheus.yml
mode: 0644
- name: prometheus-storage-volume
hostPath:
path: /data
type: Directory

prometheus-deploy.yaml

[root@master prometheus]# cat prometheus-svc.yaml
apiVersion: v1
kind: Service
metadata:
name: prometheus
namespace: monitor-sa
labels:
app: prometheus
spec:
type: NodePort
ports:
- port: 9090
targetPort: 9090
protocol: TCP
selector:
app: prometheus
component: server

prometheus-svc.yaml

浏览器访问http://192.168.199.131:30051

可以对照prometheus-cfg.yaml来看以下图片解释

 10.3.3 Prometheus热加载

#为了每次修改配置文件可以热加载 prometheus,也就是不停止 prometheus,就可以使配置生效, 想要使配置生效可用如下热加载命令:

[root@master prometheus]# kubectl get pods -n monitor-sa -o wide -l app=prometheus
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
prometheus-server-64f6fd555f-sgw67 1/1 Running 0 26m 10.244.75.193 monitor <none> <none>
# 修改prometheus-cfg.yaml进行测试
global:
scrape_interval: 20s
scrape_timeout: 15s [root@master prometheus]# kubectl apply -f prometheus-cfg.yaml
configmap/prometheus-config configured
[root@master prometheus]# kubectl get configmap -n monitor-sa
NAME DATA AGE
kube-root-ca.crt 1 3h17m
prometheus-config 1 47m
[root@master prometheus]# kubectl describe configmap prometheus-config -n monitor-sa
Name: prometheus-config
Namespace: monitor-sa
Labels: app=prometheus
Annotations: <none> Data
====
prometheus.yml:
----
global:
scrape_interval: 20s
scrape_timeout: 15s

目前修改的配置还没有生效,想要使配置生效需用如下命令热加载

[root@master prometheus]# curl -X POST http://10.244.75.193:9090/-/reload

[root@master /]# kubectl logs -f prometheus-server-64f6fd555f-sgw67 -n monitor-sa

level=info ts=2022-08-08T09:36:28.004988349Z caller=main.go:588 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml
level=info ts=2022-08-08T09:36:28.006529001Z caller=kubernetes.go:191 component="discovery manager scrape" discovery=k8s msg="Using pod service account via in-cluster config"
level=info ts=2022-08-08T09:36:28.007115043Z caller=kubernetes.go:191 component="discovery manager scrape" discovery=k8s msg="Using pod service account via in-cluster config"
level=info ts=2022-08-08T09:36:28.007544007Z caller=kubernetes.go:191 component="discovery manager scrape" discovery=k8s msg="Using pod service account via in-cluster config"
level=info ts=2022-08-08T09:36:28.008121103Z caller=kubernetes.go:191 component="discovery manager scrape" discovery=k8s msg="Using pod service account via in-cluster config"

# 热加载后可以进入到prometheus-server-64f6fd555f-sgw67中查看 /etc/prometheus/prometheus-cfg.yaml中修改的地方发现还没有变化
#热加载速度比较慢,可以暴力重启 prometheus,如修改上面的 prometheus-cfg.yaml 文件之后,可执行如下强制删除:
kubectl delete -f prometheus-cfg.yaml
kubectl delete -f prometheus-deploy.yaml
然后再通过 apply 更新:
kubectl apply -f prometheus-cfg.yaml
kubectl apply -f prometheus-deploy.yaml
注意:
线上最好热加载,暴力删除可能造成执行时间内监控数据的丢失,等待半小时或1小时,或者replicas有2个,删除一个加载一个

直接删除

[root@master prometheus]# kubectl delete pods prometheus-server-64f6fd555f-sgw67 -n monitor-sa
pod "prometheus-server-64f6fd555f-sgw67" deleted

[root@master prometheus]# kubectl get pods -n monitor-sa
NAME                    READY STATUS RESTARTS AGE
prometheus-server-64f6fd555f-t7bv7 1/1 Running 0 19s

Prometheus+Grafana+alertmanager构建企业级监控系统(一)的更多相关文章

  1. Prometheus+Grafana+Alertmanager实现告警推送教程 ----- 图文详解

    前言 本文主要介绍的是Prometheus采集数据,通过Grafana加上PromQL语句实现数据可视化以及通过Alertmanage实现告警推送功能.温馨提示,本篇文章特长,2w多的文字加上几十张图 ...

  2. Telegraf+InfluxDB+Grafana快速搭建实时监控系统 监控postgresql

    Telegraf+InfluxDB+Grafana快速搭建实时监控系统  监控postgresql

  3. 互联网企业级监控系统 OpenFalcon

    Open-Falcon 人性化的互联网企业级监控系统,Open-Falcon 整体可以分为两部分,即绘图组件.告警组件.其中: 安装绘图组件 负责数据的采集.收集.存储.归档.采样.查询.展示(Das ...

  4. 使用Ubuntu系统编译安装Zabbix企业级监控系统

    使用Ubuntu系统编译安装Zabbix企业级监控系统   作者:尹正杰 版权声明:原创作品,谢绝转载!否则将追究法律责任. Ubuntu系统部署笔记:https://www.cnblogs.com/ ...

  5. 使用Ubuntu系统管理包工具(apt)部署Zabbix企业级监控系统

    使用Ubuntu系统管理包工具(apt)部署Zabbix企业级监控系统  作者:尹正杰 版权声明:原创作品,谢绝转载!否则将追究法律责任. Ubuntu系统部署笔记:https://www.cnblo ...

  6. 基于Prometheus+Grafana+AlertManager的监控系统

    一.Prometheus 1.1 简介 Prometheus是一套开源的监控&报警&时间序列数据库的组合,基于应用的metrics来进行监控的开源工具 . 1.2 下载&安装 ...

  7. Prometheus+Grafana+Alertmanager搭建全方位的监控告警系统

    prometheus安装和配置 prometheus组件介绍 1.Prometheus Server: 用于收集和存储时间序列数据. 2.Client Library: 客户端库,检测应用程序代码,当 ...

  8. Grafana & Graphite & Collectd:监控系统

    简介 监控是运维工作中的一个重要组成部分,今天介绍一套新的监控工具,方便好用,扩展性强,这套工具有三个组件,Grafana & Graphite & Collectd: Grafana ...

  9. Grafana + Zabbix --- 部署分布式监控系统

    阅读目录: 1. 关闭防火墙 2. 安装Zabbix下载源 3. ZabbixClient  --- 安装zabbix-agent代理 4. ZabbixServer --- 安装zabbix-ser ...

  10. Zabbix+Grafana打造高逼格监控系统

    第一章 zabbix监控的意义 1.1 为什么要监控 业务安全性的保障 系统的保障 产品持续性的运行 1.2 监控的内容 1.3 zabbix的选择性 [x] 纯命令监控太局限性 [x] 监控三剑客( ...

随机推荐

  1. 工作记录:TypeScript从入门到项目实战(基础篇)

    前言 TypeScript是什么? 引用官方原话 TypeScript是JavaScript类型的超集,它可以编译成纯JavaScript.TypeScript可以在任何浏览器.任何计算机和任何操作系 ...

  2. WPF 组件间通信 MVVM 进行解耦

    假设有这样一个需求,有这样一个聊天界面,主界面是选项卡,其一选项卡内部是真正的聊天列表和聊天界面,我们需要实时的在主界面显示未读消息的数量 假设我们已经有方法可以拿到未读消息的数量,那么如何在主界面的 ...

  3. drools中no-loop和lock-on-active的区别

    一.背景 在我们编写drools规则的过程中,可能会发生死循环,那么该怎么解决呢?如果想某一个规则只执行一次,即别的规则导致该规则重新执行,也不需要执行,那么该怎么解决呢? 二.解决方案 针对以上问题 ...

  4. IDEA 突然无法打开 解决办法

    如果实在没有方法了可以试一试 删除所有的配置文件,默认位置C:\Users\${你的用户名}\${.IntelliJIdea+版本} 注意:删除配置后之前所有的设置都会失效,谨慎操作.

  5. ZYNQ7000系列学习

    ZYNQ7000-系列知识学习 一.ZYNQ7000简介 ZYNQ7000是xilinx推出的具有ARM内核的FPGA芯片,可用于常见SOC开发.基于此,通过学习ZYNQ7000的各种设置和开发,可以 ...

  6. 【已解决】Hadoop_02 bash: start-all.sh: 未找到命令...Linux

    在配置hadoop时需要进到/etc/profile中修改hadoop路径 #配置Hadoop和Java环境 export JAVA_HOME=/JDK-1.8 #你自己Java的安装路径 expor ...

  7. WPF中封装一个自己的MessageBox

    前言 在WPF应用程序开发中,我们可以借助其强大灵活的设计能力打造出绚丽而富有创意的用户界面.然而,与这种高度定制化的界面相比,标准MessageBox却显得有些原始和古老.它的外观与现代.绚丽的应用 ...

  8. #结论#洛谷 3199 [HNOI2009]最小圈

    题目 求有向图最小平均权值回路. \(n\leq 3*10^3,m\leq 10^4\) 分析 设 \(f_k(x)\) 表示从点 \(x\) 出发恰好走 \(k\) 条边的最短路, 那么答案就是 \ ...

  9. #线段树#LOJ 6029「雅礼集训 2017 Day1」市场

    题目 在长度为\(n(n\leq 10^5)\)的数列中, 需要满足区间加,区间下取整的操作 以及能够查询区间和以及区间最小值 除数\(d\)满足\(2\leq d\leq 10^9\) 加数\(c\ ...

  10. XML 简介及用法详解

    XML 是一种用于存储和传输数据的与软件和硬件无关的工具. 什么是XML? XML代表eXtensible Markup Language(可扩展标记语言).XML是一种与HTML非常相似的标记语言. ...