文章目录
- @[toc]
- 什么是 Prometheus
- Prometheus 架构及其一些生态系统组件
- Prometheus 的工作模式
- Prometheus 的适用场景
- Prometheus 的不适用场景
- Prometheus 词汇表
- Prometheus 启动参数
- Prometheus 配置文件
- 通用占位符定义
- 配置文件示例解释
- 服务发现
- Prometheus 部署
- 创建 namespace
- 创建 rbac 相关的
- 创建 svc
- 固定节点创建 label 和持久化目录
- 创建 deployment
文章目录
- @[toc]
- 什么是 Prometheus
- Prometheus 架构及其一些生态系统组件
- Prometheus 的工作模式
- Prometheus 的适用场景
- Prometheus 的不适用场景
- Prometheus 词汇表
- Prometheus 启动参数
- Prometheus 配置文件
- 通用占位符定义
- 配置文件示例解释
- 服务发现
- Prometheus 部署
- 创建 namespace
- 创建 rbac 相关的
- 创建 svc
- 固定节点创建 label 和持久化目录
- 创建 deployment
Prometheus 官网
什么是 Prometheus
- Prometheus is an open-source systems monitoring and alerting toolkit originally built at SoundCloud. Since its inception in 2012, many companies and organizations have adopted Prometheus, and the project has a very active developer and user community. It is now a standalone open source project and maintained independently of any company. To emphasize this, and to clarify the project’s governance structure, Prometheus joined the Cloud Native Computing Foundation in 2016 as the second hosted project, after Kubernetes.
Prometheus 是一个开源系统监控和警报工具包,最初由 SoundCloud 构建。自 2012 年成立以来,许多公司和组织都采用了 Prometheus,该项目拥有非常活跃的开发者和用户社区。它现在是一个独立的开源项目,独立于任何公司进行维护。为了强调这一点,并明确项目的治理结构,Prometheus 于 2016 年加入云原生计算基金会,成为继 Kubernetes 之后的第二个托管项目。
- Prometheus collects and stores its metrics as time series data, i.e. metrics information is stored with the timestamp at which it was recorded, alongside optional key-value pairs called labels.
Prometheus 将其指标收集并存储为时间序列数据,即指标信息与记录它的时间戳一起存储,以及称为标签的可选键值对。
Prometheus 架构及其一些生态系统组件
Prometheus server
Retrieval
:获取监控数据
TSDB
:时间序列数据库 (Time Series Database)
HTTP Server
:为告警和出图提供查询接口
Pushgateway
:针对一些 Prometheus 无法获取监控数据的服务,可以通过推送监控数据给 Pushgateway 后,由 Prometheus 去 Pushgateway 获取
Alertmanager
:在触发了预先设置在 Prometheus 中的告警规则后, Prometheus 便会推送告警消息到 AlertManager。
AlertManager 提供了十分灵活的告警方式,可以通过邮件、slack 或者钉钉等途径推送。
并且 AlertManager 支持高可用部署,为了解决多个 AlertManager 重复告警的问题,引入了 Gossip,在多个 AlertManager 之间通过 Gossip 同步告警信息
PromQL
:Prometheus 提供了一种称为 PromQL(Prometheus Query Language)的功能查询语言,允许用户实时选择和聚合时间序列数据。表达式的结果可以显示为图形,在 Prometheus 的表达式浏览器中查看为表格数据,也可以通过 HTTP API 由外部系统使用。
Prometheus web UI
:通过 PromQL 语句查询指标信息,并在页面展示。虽然 Prometheus 自带 UI 界面,但是大部分都是使用 Grafana 出图。另外第三方也可以通过 API 接口来获取监控指标。
Exporters
:指标暴露器,负责从目标应用程序上采集和聚合原始格式的数据,并转换或聚合为 Prometheus 格式的指标向外暴露。
Node-Exporter
:用于收集服务器节点(例如 k8s)的物理指标状态数据,如平均负载、CPU、内存、磁盘、网络等资源信息的指标数据,需要部署到所有运算节点
Kube-state-Metrics
:为 Prometheus 采集 k8s 资源数据的 exporter,通过监听 APIServer 收集 kubernetes 集群内资源对象的状态指标数据,例如 pod、deployment、service 等等。同时它也提供自己的数据,主要是资源采集个数和采集发生的异常次数统计。
cAdvisor
:用来监控容器内部使用资源的信息,比如 CPU、内存、网络 I/0、磁盘 I/0。
blackbox-exporter:监控业务容器存活性。
Prometheus 的工作模式
- 通过上面的图可以看出,Prometheus 有两种模式
- 服务发现(Service Discovery)机制
- 静态配置获取要监视的目标(Prometheus Targets)
- 通过每个目标上的指标 exporter 来采集(Scrape)指标数据
Prometheus 的适用场景
- Prometheus works well for recording any purely numeric time series. It fits both machine-centric monitoring as well as monitoring of highly dynamic service-oriented architectures. In a world of microservices, its support for multi-dimensional data collection and querying is a particular strength.
Prometheus 非常适合记录任何纯数字时间序列。它既适合以机器为中心的监控,也适合监控高度动态的面向服务的架构。在微服务的世界中,它对多维数据收集和查询的支持是一个特别的优势。
- Prometheus is designed for reliability, to be the system you go to during an outage to allow you to quickly diagnose problems. Each Prometheus server is standalone, not depending on network storage or other remote services. You can rely on it when other parts of your infrastructure are broken, and you do not need to setup extensive infrastructure to use it.
Prometheus 专为可靠性而设计,是您在中断期间访问的系统,可让您快速诊断问题。每个 Prometheus 服务器都是独立的,不依赖于网络存储或其他远程服务。当基础架构的其他部分损坏时,您可以依赖它,并且无需设置广泛的基础架构即可使用它。
Prometheus 的不适用场景
- Prometheus values reliability. You can always view what statistics are available about your system, even under failure conditions. If you need 100% accuracy, such as for per-request billing, Prometheus is not a good choice as the collected data will likely not be detailed and complete enough. In such a case you would be best off using some other system to collect and analyze the data for billing, and Prometheus for the rest of your monitoring.
Prometheus 重视可靠性。您始终可以查看有关系统的可用统计信息,即使在故障条件下也是如此。如果您需要 100% 的准确性,例如按请求计费,Prometheus 不是一个好的选择,因为收集的数据可能不够详细和完整。在这种情况下,您最好使用其他系统来收集和分析计费数据,并使用 Prometheus 进行其余的监控。
Prometheus 词汇表
Prometheus 词汇表
Alert
:Prometheus 中主动触发的警报规则的结果。Alert 从 Prometheus 发送到 Alertmanager。Alertmanager
:接收警报,将它们聚合到组中,删除重复数据,应用静音、限制,然后向电子邮件、Pagerduty、Slack 等发送通知。Bridge
:从客户端库中获取样本并将其公开给非 Prometheus 监控系统的组件。例如,Python、Go 和 Java 客户端可以将指标导出到 Graphite。Client library
:某种语言(例如 Go、Java、Python、Ruby)的库,可以轻松地直接检测代码、编写自定义收集器以从其他系统提取指标并将指标公开给 Prometheus。Collector
:exporter 的一部分,表示一组指标。如果它是直接检测的一部分,它可能是单个指标,如果它从另一个系统提取指标,则可能是多个指标。Direct instrumentation
:使用客户端库作为程序源代码的一部分以内联方式添加的检测。Endpoint
:可以抓取的指标源,通常对应于单个进程。Exporter
:与要从中获取指标的应用程序一起运行的二进制文件。exporter 公开 Prometheus 指标,通常是将以非 Prometheus 格式公开的指标转换为 Prometheus 支持的格式。Instance
:用于唯一标识作业中目标的标签。Job
:具有相同目的的目标集合(例如,监视为可伸缩性或可靠性而复制的一组类似进程)称为 job。Notification
:表示一组或多个警报,并由 Alertmanager 发送到电子邮件、Pagerduty、Slack 等。Promdash
:Prometheus 的原生仪表板构建器。它已被弃用,取而代之的是 Grafana。Prometheus
:通常是指 Prometheus 系统的核心二进制文件。它也可以指整个普罗米修斯监控系统。PromQL
:Prometheus 查询语言。它允许广泛的操作,包括聚合、切片和切割、预测和连接。Pushgateway
:保留来自批处理作业的最新指标推送。这允许 Prometheus 在终止后抓取其指标。Recording Rules
:预先计算经常需要或计算成本高昂的表达式,并将其结果保存为一组新的时间序列。Remote Read
:Prometheus 的一项功能,它允许在查询过程中透明地读取来自其他系统(例如长期存储)的时间序列。Remote Read Adapter
:位于 Prometheus 和另一个系统之间,在它们之间转换时间序列请求和响应。Remote Read Endpoint
:Prometheus 在执行远程读取时与之通信的内容。Remote Write
:Prometheus 的一项功能,允许将摄取的样本动态发送到其他系统,例如长期存储。Remote Write Adapter
:Prometheus 和另一个系统之间,将远程写入中的样本转换为其他系统可以理解的格式。Remote Write Endpoint
:Prometheus 在执行远程写入时与之通信的内容。Sample
:样本是时间序列中某个时间点的单个值。在 Prometheus 中,每个样本都由一个 float64 值和一个毫秒精度的时间戳组成。Silence
:Alertmanager 中的静默可防止警报(与静默匹配的标签)包含在通知中。Target
:要抓取的对象的定义。例如,要应用哪些标签、连接所需的任何身份验证或定义抓取方式的其他信息。Time Series
:Prometheus 时间序列(Time Series)是属于同一指标和同一组标记维度的时间戳值流。Prometheus 将所有数据存储为时间序列。
Prometheus 启动参数
可以通过
prometheus -h
命令来查看拥有哪些参数
参数 | 参数解释 |
---|---|
-h, --help | 显示参数的帮助文档 |
--version | 显示版本信息 |
--config.file"prometheus.yml" | 指定配置文件 |
--web.listen-address="0.0.0.0:9090" | ui、api、telemetry监听地址信息 |
--web.config.file | TLS或身份验证配置文件 |
--web.read-timeout=5m | 页面读取请求最大超时时间 |
--web.max-connections=512 | 同时访问Prometheus页面的最大连接数,默认为512 |
--web.external-url | Prometheus对外提供的url(eg: Prometheus通过反向代理提供服务)。用于生成一个相对和绝对的链接返回给Prometheus本身。如果这个url有路径部分,它将用于Prometheus所有HTTP端点的前缀。如果省略了,则相关的url组件将自动派生 |
--web.route-prefix | Web端点内部路由的前缀。默认路径:web.external-url |
--web.user-assets | 静态资源路径,可以在/user下找到 |
--web.enable-lifecycle | 通过HTTP请求启用关闭和重新加载 |
--web.enable-admin-api | 启用管理控制操作的api端点 |
--web.enable-remote-write-receiver | 启用接受远程写入请求的 API 端点 |
--web.console.templates="consoles" | 到控制台模板目录的路径,可以在consoles/目录下找到。 |
--web.console.libraries="console_libraries" | 控制台库目录的路径 |
--web.page-title="Prometheus Time Series Collection and Processing Server" | Prometheus实例的文件标题 |
--web.cors.origin=".*" | 正则表达式为CORS原点 |
--storage.tsdb.path="data/" | 数据存储的路径 |
--storage.tsdb.retention | 此标志已被弃用,请使用 --storage.tsdb.retention.time |
--storage.tsdb.retention.time | TSDB 数据保留时长,默认是 15天,可以配置的单位:y(年),w(周),d(天),m(分钟),s(秒),ms(毫秒) |
--storage.tsdb.retention.size | TSDB 数据最大保存大小,可以配置的单位:B, KB, MB, GB, TB, PB, EB;1KB=1024B |
--storage.tsdb.no-lockfile | 不在数据目录中创建lockfile |
--storage.tsdb.head-chunks-write-queue-size=0 | 通过其将头块写入要进行 m-mapped 的磁盘的队列的大小,0 将完全禁用队列。实验的仅与服务器模式一起使用。 |
--storage.agent.path="data-agent/" | 数据存储的路径。仅与代理模式一起使用。 |
--storage.agent.wal-compression | 压缩代理 wal。仅与代理模式一起使用。 |
--storage.agent.retention.min-time | 最小时间当 WAL 被截断时,TSDB 数据保留时长。仅与代理模式一起使用 |
--storage.agent.retention.max-time | 最长时间当 WAL 被截断时,TSDB 数据保留时长。仅与代理模式一起使用 |
--storage.agent.no-lockfile | 不要在数据目录中创建lockfile。仅与代理模式一起使用。 |
--storage.remote.flush-deadline | 关闭或重新加载配置时需要等待多长时间刷新样例。 |
--storage.remote.read-sample-limit=5e7 | 在单个查询中通过远程读接口返回的最大样本总数。0意味着没有限制。对于流响应类型,此限制将被忽略。 |
--storage.remote.read-concurrent-limit=10 | 并发远程读调用的最大数量。0意味着没有限制。 |
--storage.remote.read-max-bytes-in-frame=1048576 | 在编组前流化远程读取响应类型的单个帧中的最大字节数。请注意,客户端可能也有帧大小的限制。默认情况下为1MB。 |
--rules.alert.for-outage-tolerance=1h | 忍受Prometheus故障恢复"for"警报状态的最大时间。 |
--rules.alert.for-grace-period=10m | 警报和恢复"for"状态之间的最小持续时间。仅对配置的"for"时间大于宽限期的警报进行维护。 |
--rules.alert.resend-delay=1m | 在向Alertmanager重新发送警报之前等待的最短时间。 |
--alertmanager.notification-queue-capacity=10000 | 等待报警通知队列的大小。 |
--query.lookback-delta=5m | 允许在表达式求值期间检索度量值的delta差值。 |
--query.timeout=2m | 一个查询在终止之前可以执行的最长时间(如果超过2min,就会自动kill掉)。 |
--query.max-concurrency=20 | 并发执行的最大查询数,默认为20。 |
--query.max-samples=50000000 | 单个查询可以加载到内存中的最大样本数。注意,如果查询尝试将比这个更多的样本加载到内存中,那么查询将会失败,因此这也限制了查询可以返回的样本数量。 |
--enable-feature | 逗号分隔要启用的功能名称,有效选项:agent, exemplar-storage, expand-external-labels, memory-snapshot-on-shutdown, promql-at-modifier, promql-negative-offset, promql-per-step-stats, remote-write-receiver (DEPRECATED), extra-scrape-metrics, new-service-discovery-manager, auto-gomaxprocs, no-default-scrape-port, native-histograms。详情请查看https://prometheus.io/docs/prometheus/latest/feature_flags/。 |
--log.level=info | 开启打印日志级别(debug,info,warn,error,fatal)。默认为info |
--log.format=logfmt | 日志消息的输出格式。[logfmt, json] |
Prometheus 配置文件
Prometheus 配置文件
通用占位符定义
占位符 | 占位符解释 |
---|---|
<boolean> | 可以取值 true 或 false 的布尔值 |
<duration> | `与正则表达式((([0-9]+)y)?(([0-9]+)w)?(([0-9]+)d)?(([0-9]+)h)?(([0-9]+)m)?(([0-9]+)s)?(([0-9]+)ms)? |
<filename> | 当前工作目录中的有效路径 |
<float> | 浮点数 |
<host> | 由主机名或 IP 后跟可选端口号组成的有效字符串 |
<int> | 整数值 |
<labelname> | 与正则表达式 [a-zA-Z_][a-zA-Z0-9_]* 匹配的字符串。源标签中任何其他不受支持的字符都应转换为下划线。例如,标签 app.kubernetes.io/name 应写为 app_kubernetes_io_name。 |
<labelvalue> | 一串 Unicode 字符 |
<path> | 有效的 URL 路径 |
<scheme> | 可以采用值 http 或 https 的字符串 |
<secret> | 作为机密的常规字符串,例如密码 |
<string> | 常规字符串 |
<size> | 以字节为单位的大小,例如 512MB。需要一个单位。支持单位:B、KB、MB、GB、TB、PB、EB。 |
<tmpl_string> | 使用前经过模板扩展的字符串 |
其他占位符是单独指定的。
配置文件示例解释
github 上的配置文件模板
#配置文件中的全局配置
global:
scrape_interval: 15s # 多久收集一次数据,默认1分钟
evaluation_interval: 30s # 多久评估一次规则,默认1分钟
scrape_timeout: 10s # 每次收集数据的超时时间,默认10秒
# 当 Prometheus 和外部系统(联邦, 远程存储, Alertmanager)通信的时候,添加标签到任意的时间序列或者报警
external_labels:
monitor: codelab
foo: bar
# 加载规则文件, 可以使用通配符
# 规则文件指定全局变量列表。从所有匹配的文件中读取规则和警报。
rule_files:
- "first.rules"
- "my/*.rules"
# 远程写入功能相关的设置
remote_write:
- url: http://remote1/push
write_relabel_configs:
- source_labels: [__name__]
regex: expensive.*
action: drop
- url: http://remote2/push
# 远程读取相关功能的设置
remote_read:
- url: http://remote1/read
read_recent: true
- url: http://remote3/read
read_recent: false
required_matchers:
job: special
# 收集数据-配置列表
# scrape_config 部分指定了一组目标和参数,描述了如何抓取它们。
# 在一般情况下,一个抓取资源配置指定一个作业。在高级配置中,这可能会改变。
# 可以通过 static_configs 参数静态配置目标,也可以使用支持的服务发现机制之一动态发现目标。
# 此外,relabel_configs 允许在抓取之前对任何目标及其标签进行高级修改。
scrape_configs:
# 必须配置, 自动附加的 job labels, 必须唯一
- job_name: prometheus
# 标签冲突, true 为以抓取的数据为准并忽略服务器中的,false 为通过重命名来解决冲突。
honor_labels: true
# 从目标获取指标的 HTTP 资源路径
metrics_path: '/metrics'
# 文件服务发现配置列表
# 基于文件的服务发现提供了一种更通用的方法来配置静态目标,并用作插入自定义服务发现机制的接口。
# 它读取一组包含零个或多个 <static_config> 列表的文件。
# 对所有定义文件的更改都会通过磁盘监视检测到并立即应用。
# 文件可以 yaml 或 json 格式提供。仅应用形成良好目标组的更改。
file_sd_configs:
# 从这些文件中提取目标
- files:
- foo/*.slow.json
- single/file.yml
# 刷新文件的时间间隔
refresh_interval: 10m
# 使用 job 名作为 label 的静态配置目录的列表
static_configs:
- targets: ['localhost:9090', 'localhost:9191']
labels:
my: label
your: label
# 目标节点重新打标签的配置列表。
# 重新标记是一个功能强大的工具,可以在抓取目标之前动态重写目标的标签集。
# 可以配置多个,按照先后顺序应用
relabel_configs:
- source_labels: [job, __meta_dns_name]
# 从现有的标签中选择源标签, 最后会被替换,保持,丢弃
regex: (.*)some-[regex]
# 正则表达式, 将会提取 source_labels 中匹配的值
# 在替换动作中将结果值写入的标签
target_label: job
replacement: foo-${1}
# 如果正则表达匹配, 那么替换值. 可以使用正则表达中的捕获组
# 将 abc 标签的内容复制到 cde 标签中
- source_labels: [abc]
target_label: cde
- replacement: static
target_label: abc
- regex:
replacement: static
target_label: abc
# 可选的, bearer token 文件的信息
bearer_token_file: valid_token_file
# Alertmanager相关的配置
alerting:
alertmanagers:
# 配置如何访问 Alertmanager,可使用 http 或 https
- scheme: https
static_configs:
- targets:
- "1.2.3.4:9093"
- "1.2.3.5:9093"
- Prometheus 的配置文件是 prometheus.yml,在启动时指定相关的文件,可对配置内容进行加载,配置文件分为四个模块
global
:全局配置
alerting
:告警配置
rule_files
:规则配置
scrape_configs
:目标拉取配置
服务发现
在 Prometheus 的配置中,一个最重要的概念就是数据源 target,而数据源的配置主要分为静态配置和动态发现,以下简单列举几个国内用的上的,其他详细的,可以看 Prometheus 的官方文档
服务发现名称 | 服务发现类型 |
---|---|
static_configs | 静态服务发现 |
azure_sd_configs | 亚马逊云主机服务发现 |
consul_sd_configs | consul 服务发现 |
docker_sd_configs | docker 服务发现 |
dockerswarm_sd_configs | dockerswarm 服务发现 |
dns_sd_configs | DNS 服务发现 |
ec2_sd_configs | AWS EC2 服务发现 |
eureka_sd_configs | eureka 服务发现 |
file_sd_configs | 文件服务发现 |
http_sd_configs | HTTP 服务发现 |
kubernetes_sd_configs | Kubernetes 服务发现 |
Prometheus 部署
- 以下采用 k8s 的方式部署,所以,需要现有一套 k8s 集群,以下的 k 命令是 kubectl 命令的简化版,需要自己对 kubectl 命令做一个软连接,如果没有,需要自己替换成 kubectl 命令
- 我的 k8s 版本是 v1.26.3 的,有可能会出现 kind 版本不对,需要自己对应的去修改 yaml 文件
- 部署的 prometheus 是 v2.45.5 版本,是当前 2024年5月 的 LTS 版本
创建 namespace
k create ns monitor
创建 rbac 相关的
---
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
name: prometheus
namespace: monitor
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: prometheus
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: prometheus
namespace: monitor
创建 svc
创建一个 nodeport 类型的,这样可以直接使用 ip+端口的方式访问 Prometheus 的 web UI
---
apiVersion: v1
kind: Service
metadata:
annotations:
labels:
app: prometheus
name: prometheus-svc
namespace: monitor
spec:
type: NodePort
ports:
- name: http
port: 9090
targetPort: 9090
nodePort: 31090
selector:
app: prometheus
固定节点创建 label 和持久化目录
- 当前没有做 ha 模式,也没做远程共享存储,这里直接使用 localpath 的方式来持久化 Prometheus 的 TSDB 数据,因此也需要固定 Prometheus 到某个固定节点
- 关于目录的创建和配置文件的准备,也需要去指定的节点操作,下面的节点信息,需要自己替换
- config 目录放 Prometheus 的配置文件
- data 目录放 Prometheus 的 TSDB 数据
- rules 目录放 Prometheus 的告警规则文件
k label node 192.168.11.185 prometheus=
mkdir -p /data/k8s-data/prometheus/{config,data,rules}
chmod -R 777 /data/k8s-data/prometheus
Prometheus 配置文件,对应的路径
/data/k8s-data/prometheus/config/prometheus.yml
global:
scrape_interval: 30s
evaluation_interval: 30s
scrape_timeout: 10s
external_labels:
prometheus: monitor/k8s
rule_files:
- /etc/prometheus/rules/*.yml
scrape_configs:
- job_name: prometheus
metrics_path: '/metrics'
static_configs:
- targets: ['prometheus-svc.monitor.svc.cluster.local:9090']
创建 deployment
---
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
labels:
app: prometheus
name: prometheus
namespace: monitor
spec:
replicas: 1
selector:
matchLabels:
app: prometheus
template:
metadata:
labels:
app: prometheus
spec:
serviceAccount: prometheus
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: prometheus
operator: Exists
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- prometheus
topologyKey: kubernetes.io/hostname
terminationGracePeriodSeconds: 0
containers:
- name: prometheus
command:
- "/bin/prometheus"
args:
- "--config.file=/etc/prometheus/config/prometheus.yml"
- "--storage.tsdb.path=/etc/prometheus/data"
- "--storage.tsdb.retention.time=30d"
- "--web.enable-lifecycle"
image: prom/prometheus:v2.45.5
env:
- name: TZ
value: Asia/Shanghai
imagePullPolicy: IfNotPresent
ports:
- containerPort: 9090
name: http
livenessProbe:
failureThreshold: 60
initialDelaySeconds: 5
periodSeconds: 10
successThreshold: 1
tcpSocket:
port: http
timeoutSeconds: 1
readinessProbe:
failureThreshold: 60
initialDelaySeconds: 5
periodSeconds: 10
successThreshold: 1
tcpSocket:
port: http
timeoutSeconds: 1
volumeMounts:
- name: prometheus-home
mountPath: /etc/prometheus
resources:
requests:
memory: 256Mi
cpu: 100m
limits:
memory: 2048Mi
cpu: 1000m
volumes:
- hostPath:
path: /data/k8s-data/prometheus
type: DirectoryOrCreate
name: prometheus-home
启动成功后,使用 ip:31090 的方式来访问 Prometheus,访问 status 下面的 targets 可以看到,我们配置文件配置的 Prometheus 已经有了,并且状态是 up