首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >Prometheus的配置文件prometheus.yml详细说明

Prometheus的配置文件prometheus.yml详细说明

原创
作者头像
Bob hadoop
修改于 2021-07-08 10:23:49
修改于 2021-07-08 10:23:49
13.2K0
举报
文章被收录于专栏:日常杂记日常杂记

翻看官网一边学习,一边记录告警部分没有写,后面继续学习后再完善

总体

############################################################################

global:

# How frequently to scrape targets by default. 默认情况下抓取目标的频率。

[ scrape_interval: <duration> | default = 1m ]

# How long until a scrape request times out.抓取请求超时的时间。

[ scrape_timeout: <duration> | default = 10s ]

# How frequently to evaluate rules.评估规则的频率。

[ evaluation_interval: <duration> | default = 1m ]

# The labels to add to any time series or alerts when communicating with external systems (federation, remote storage, Alertmanager).

#与外部系统(联合、远程存储、警报管理器)通信时添加到任何时间序列或警报的标签。

external_labels:

[ <labelname>: <labelvalue> ... ]

# File to which PromQL queries are logged. PromQL 查询记录到的文件。

# Reloading the configuration will reopen the file.重新加载配置将重新打开文件。

[ query_log_file: <string> ]

# Rule files specifies a list of globs. Rules and alerts are read from all matching files.存放告警规则的地方,

rule_files:

[ - <filepath_glob> ... ]

# A list of scrape configurations. 抓取的作业以及目标,job1 、 job2、job3等。

scrape_configs:

[ - <scrape_config> ... ]

# Alerting specifies settings related to the Alertmanager.警报指定与警报管理器相关的设置。

alerting:

alert_relabel_configs:

[ - <relabel_config> ... ]

alertmanagers:

[ - <alertmanager_config> ... ]

# Settings related to the remote write feature.与远程写入相关配置。

remote_write:

[ - <remote_write> ... ]

# Settings related to the remote read feature.与远程读取相关配置。

remote_read:

[ - <remote_read> ... ]

总结:基本配置就如上面介绍那样,日常使用,如新增刮擦任务,scrape_configs下需要配置各类机器的相关yml文件,不同的报警规则就是看rule_files,存放不同告警规则的地方,比如后端要接入click house需要调用remote_write与remote_read。

下面详细说一些技巧参数

############################################################################

<scrape_config>

scrape_config部分指定一组目标和参数,描述如何刮除它们。在一般情况下,一个刮擦配置指定一个作业。在高级配置中,这种情况可能会改变。目标可以通过static_configs参数静态配置,也可以使用支持的服务发现机制之一动态发现。此外,relabel_configs允许在刮取之前对任何目标及其标签进行高级修改。

举例:

静态配置

- job_name: 'prometheus' static_configs: - targets: ['xxx.xxx.x.xx:9090']

配置文件发现

第一段代码是放在prometheus.yml的scrape_config内,第二段代码是保存在/opt/prometheus/monitor_config/目录下,名称可以写被监控的机器ip文件为yml文件,如10.172.12.12.yml

- job_name: 'zx_host' file_sd_configs: - files: ['/opt/prometheus/monitor_config/*.yml'] refresh_interval: 5s

- targets: [ "xx.xx.xx.xx:9100" ] labels: group: "host" kind: "jkj"

# 默认分配给抓取指标的作业名称。

job_name: <job_name>

# 从这项工作中抓取目标的频率。

[ scrape_interval: <duration> | default = <global_config.scrape_interval> ]

# 抓取此作业时的每次抓取超时。

[ scrape_timeout: <duration> | default = <global_config.scrape_timeout> ]

# 从目标获取指标的 HTTP 资源路径。

[ metrics_path: <path> | default = /metrics ]

# Honor_labels 控制 Prometheus 如何处理已存在于抓取数据中的标签与 Prometheus 将在服务器端附加的标签(“作业”和“实例”标签、手动配置的目标标签以及由服务发现实现生成的标签)之间的冲突。

# 如果honor_labels 设置为“true”,标签冲突通过从抓取的数据中保留标签值并忽略冲突的服务器端标签来解决。

# 如果 Honor_labels 设置为“false”,则通过将抓取数据中的冲突标签重命名为“exported_<original-label>”来解决标签冲突(对于

# 示例 "exported_instance", "exported_job") 然后附加服务器端标签。

# 将 Honor_labels 设置为“true”对于联邦和抓取 Pushgateway 等用例很有用,其中应保留目标中指定的所有标签。

# 请注意,任何全局配置的“external_labels”都不受此设置的影响。在与外部系统通信时,它们总是仅在时间序列还没有给定标签时才应用,否则会被忽略。

[ honor_labels: <boolean> | default = false ]

# Honor_timestamps 控制 Prometheus 是否尊重抓取数据中存在的时间戳。

# 如果 Honor_timestamps 设置为“true”,则将使用目标公开的指标的时间戳。

# 如果honour_timestamps 设置为“false”,则目标公开的指标的时间戳将被忽略。

[ honor_timestamps: <boolean> | default = true ]

# 配置请求使用的协议方案。

[ scheme: <scheme> | default = http ]

# Optional HTTP URL parameters.

params:

[ <string>: [<string>, ...] ]

# 使用配置的用户名和密码在每个抓取请求上设置 `Authorization` 标头。

# password 和 password_file 是互斥的。

basic_auth:

[ username: <string> ]

[ password: <secret> ]

[ password_file: <string> ]

# 配置抓取请求是否遵循 HTTP 3xx 重定向。

[ follow_redirects: <bool> |默认=真]

# 配置抓取请求的 TLS 设置。

tls_config:

[ <tls_config> ]

# 可选的代理 URL。

[ proxy_url: <字符串> ]

# Azure 服务发现配置列表。

azure_sd_configs:

[ - <azure_sd_config> ... ]

# Consul 服务发现配置列表。

consul_sd_configs:

[ - <consul_sd_config> ... ]

# DigitalOcean 服务发现配置列表。

digitalocean_sd_configs:

[ - <digitalocean_sd_config> ... ]

# Docker 服务发现配置列表。

docker_sd_configs:

[ - <docker_sd_config> ... ]

# Docker Swarm 服务发现配置列表。

dockerswarm_sd_configs:

[ - <dockerswarm_sd_config> ... ]

# DNS 服务发现配置列表。

dns_sd_configs:

[ - <dns_sd_config> ... ]

# EC2 服务发现配置列表。

ec2_sd_configs:

[ - <ec2_sd_config> ... ]

# Eureka 服务发现配置列表。

eureka_sd_configs:

[ - <eureka_sd_config> ... ]

# 文件服务发现配置列表。

file_sd_configs:

[ - <file_sd_config> ... ]

这里着重记录下因为用的较多比较熟悉

基于文件的服务发现提供了一种更通用的静态目标配置方式,并作为插入自定义服务发现机制的接口。

它读取一组包含零个或多个<static_config>列表的文件。所有定义文件的更改都通过磁盘监视来检测,并立即应用。文件可以以YAML或JSON格式提供。只应用导致目标群体形成良好的变化。

文件必须包含静态配置列表,使用以下格式:

JSON json

[ { "targets": [ "<host>", ... ], "labels": { "<labelname>": "<labelvalue>", ... } }, ... ]

YAML yaml

- targets: [ - '<host>' ] labels: [ <labelname>: <labelvalue> ... ]

作为回退,文件内容也在指定的刷新间隔内定期重读。

在重新标记阶段,每个目标都有一个元标签__meta_filepath。其值设置为从中提取目标的文件路径。

有一份与此发现机制集成的列表。

# Patterns for files from which target groups are extracted.

files:

[ - <filename_pattern> ... ]

# Refresh interval to re-read the files.

[ refresh_interval: <duration> | default = 5m ]

其中<filename_pattern>可能是以.json、.yml或.yaml结尾的文件路径。最后一个路径段可能包含一个与任何字符序列匹配的单个*,例如my/path/tg_*.json。

# GCE 服务发现配置列表。

gce_sd_configs:

[ - <gce_sd_config> ... ]

# Hetzner 服务发现配置列表。

hetzner_sd_configs:

[ - <hetzner_sd_config> ... ]

# HTTP 服务发现配置列表。

http_sd_configs:

[ - <http_sd_config> ... ]

# Kubernetes 服务发现配置列表。

kubernetes_sd_configs:

[ - <kubernetes_sd_config> ... ]

# Lightsail 服务发现配置列表。

lightsail_sd_configs:

[ - <lightsail_sd_config> ... ]

# Linode 服务发现配置列表。

linode_sd_configs:

[ - <linode_sd_config> ... ]

# Marathon 服务发现配置列表。

marathon_sd_configs:

[ - <marathon_sd_config> ... ]

# AirBnB 的 Nerve 服务发现配置列表。

Neuro_sd_configs:

[ - <nerve_sd_config>

# OpenStack 服务发现配置列表。

openstack_sd_configs:

[ - <openstack_sd_config> ... ]

# Scaleway 服务发现配置列表。

scaleway_sd_configs:

[ - <scaleway_sd_config> ... ]

# Zookeeper Serverset 服务发现配置列表。

serverset_sd_configs:

[ - <serverset_sd_config> ... ]

# Triton 服务发现配置列表。

triton_sd_configs:

[ - <triton_sd_config> ... ]

# 此作业的标记静态配置目标列表。

静态配置:

[ - <static_config> ... ]

# 目标重新标记配置列表。

relabel_configs:

[ - <relabel_config> ... ]

# metric relabel 配置列表。

metric_relabel_configs:

[ - <relabel_config> ... ]

# 大于这么多字节的未压缩响应体将导致抓取失败。 0 表示没有限制。示例:100MB。这是一项实验性功能,此行为将来可能会更改或删除。

[ body_size_limit: <size> | default = 0 ]

# 每次抓取对将被接受的抓取样本数量的限制。如果在度量重新标记后存在超过此数量的样本,则整个刮擦将被视为失败。 0 表示没有限制。

[ sample_limit: <int> | default = 0 ]

# 每次抓取对样本可接受的标签数量的限制。如果超过这个数量的标签存在后度量重新标记,整个抓取将被视为失败。 0 表示没有限制。

[ label_limit: <int> |默认值 = 0]

# 每次抓取对样本可接受的标签名称长度的限制。如果标签名称长于此数字,则在度量重新标记后,整个刮将被视为失败。 0 表示没有限制。

[ label_name_length_limit: <int> |默认值 = 0]

# 每次抓取对样本可接受的标签值长度的限制。如果一个标签值长于这个数字后度量重新标记,整个抓取将被视为失败。 0 表示没有限制。

[ label_value_length_limit: <int> |默认值 = 0]

# Per-scrape 配置限制唯一目标的数量接受。如果在目标之后存在超过此数量的目标重新标记,Prometheus 会将目标标记为失败而不抓取它们。 0 表示没有限制。这是一个实验性功能,这种行为可能未来改变。

[ target_limit: <int> | default = 0 ]

总结在刮擦作业这里由于生产环境的需求功能不同,日常我使用的比较多的还是静态与文件,就如上面举例那样,直接通过更改/opt/prometheus/monitor_config/内的文件来改变刮擦job。其他详细的使用方法可参考官网。https://prometheus.io/docs/

############################################################################

<alert_relabel_configs>

############################################################################

<alertmanager_config>

############################################################################

<remote_write>

write_relabel_configs在将样本发送到远程端点之前,正在重新标记应用于它们。写重标签应用于外部标签之后。这可以用来限制发送哪些样品。

# 将样本发送到的端点的 URL。

url: <string>

# 对远程写入端点的请求超时。

[ remote_timeout: <duration> | default = 30s ]

# 要与每个远程写入请求一起发送的自定义 HTTP 标头。

# 请注意,无法覆盖 Prometheus 本身设置的标头。

headers:

[ <string>: <string> ... ]

# 远程写relabel配置列表。

write_relabel_configs:

[ - <relabel_config> ... ]

# 远程写入配置的名称,如果指定,则在远程写入配置中必须是唯一的。

# 该名称将用于指标和日志记录中代替生成的值,以帮助用户区分

# 远程写入配置。

[ name: <string> ]

# 启用通过远程写入发送示例。请注意,必须首先启用示例存储本身才能抓取示例。

[ send_exemplars: <boolean> | default = false ]

# 在每个远程写入请求上设置 `Authorization` 标头

# 配置的用户名和密码。

# password 和 password_file 是互斥的。

basic_auth:

[ username: <string> ]

[ password: <secret> ]

[ password_file: <string> ]

# 可选的 `Authorization` 头配置。

authorization:

# 设置认证类型。

[ type: <string> | default: Bearer ]

# 设置凭据。它与互斥

# `credentials_file`。

[ credentials: <secret> ]

# 将凭据设置为从配置文件读取的凭据。

# 它与 `credentials` 互斥。

[ credentials_file: <filename> ]

# 可选地将 AWS 的签名验证 4 签名过程配置为

# 签署请求。不能与 basic_auth、authorization 或 oauth2 同时设置。

# 要使用 AWS 开发工具包中的默认凭证,请使用 `sigv4: {}`。

SIGV4:

# AWS 区域。如果为空,则来自默认凭据链的区域

# 用来。

[ region: <string> ]

# AWS API 密钥。如果为空,环境变量`AWS_ACCESS_KEY_ID`

# 和 `AWS_SECRET_ACCESS_KEY` 被使用。

[ access_key: <string> ]

[ secret_key: <secret> ]

# 用于身份验证的命名 AWS 配置文件。

[ profile: <string> ]

# AWS 角色 ARN,替代使用 AWS API 密钥。

[ role_arn: <string> ]

# 可选的 OAuth 2.0 配置。

# 不能与basic_auth、authorization、sigv4同时使用。

oauth2:

[ <oauth2> ]

# 配置远程写入请求的 TLS 设置。

tls_config:

[ <tls_config> ]

# 可选的代理 URL。

[ proxy_url: <string> ]

# 配置HTTP请求是否遵循HTTP 3xx重定向。

[ follow_redirects: <bool> |default = true]

# 配置用于写入远程存储的队列。

队列配置:

# 在我们阻止读取更多之前每个分片缓冲的样本数

# 来自 WAL 的样本。建议每个容量都足够

# 分片缓冲多个请求以在处理时保持吞吐量

# 偶尔缓慢的远程请求。

[ capacity: <int> | default = 2500 ]

# 最大分片数,即并发量。

[ max_shards: <int> |default = 200]

# 最小分片数,即并发量。

[ min_shards: <int> |default = 1]

# 每次发送的最大样本数。

[ max_samples_per_send: <int> |default = 500]

# 样本在缓冲区中等待的最长时间。

[batch_send_deadline: <duration>|default = 5s ]

# 初始重试延迟。每次重试都会加倍。

[ min_backoff: <duration> | default = 30ms ]

# 最大重试延迟。

[ max_backoff: <duration> | default = 100ms ]

# 从远程写入存储接收到 429 状态代码后重试。

# 这是实验性的,将来可能会改变。

[ retry_on_http_429: <boolean> | default = false ]

# 配置将系列元数据发送到远程存储。

# 元数据配置随时可能更改

# 或在以后的版本中删除。

元数据配置:

# 是否将度量元数据发送到远程存储。

[ send: <boolean> | default = true ]

# 度量元数据发送到远程存储的频率。

[ send_interval: <duration> | default = 1m ]

<remote_read>

# 要查询的端点的 URL。

url: <string>

# 远程读取配置的名称,如果指定,则在远程读取配置中必须是唯一的。

# 该名称将用于指标和日志记录以代替生成的值,以帮助用户区分远程读取配置。

[ name: <string> ]

# 一个可选的相等匹配器列表,必须是

# 存在于选择器中以查询远程读取端点。

required_matchers:

[ <labelname>: <labelvalue> ... ]

# 对远程读取端点的请求超时。

[ remote_timeout: <duration> | default = 1m ]

# 要与每个远程读取请求一起发送的自定义 HTTP 标头。

# 请注意,无法覆盖 Prometheus 本身设置的标头。

headers:

[ <string>: <string> ... ]

# 是否应该为查询的时间范围进行读取

# 本地存储应该有完整的数据。

[ read_recent: <boolean> | default = false ]

# 在每个远程读取请求上设置 `Authorization` 标头

# 配置的用户名和密码。

# password 和 password_file 是互斥的。

basic_auth:

[ username: <string> ]

[ password: <secret> ]

[ password_file: <string> ]

# 可选的 `Authorization` 头配置。

授权:

# 设置认证类型。

[ type: <string> | default: Bearer ]

# 设置凭据。它与互斥

# `credentials_file`。

[ credentials: <secret> ]

# 将凭据设置为从配置文件读取的凭据。

# 它与 `credentials` 互斥。

[ credentials_file: <filename> ]

# 可选的 OAuth 2.0 配置。

# 不能与basic_auth或authorization同时使用。

oauth2:

[ <oauth2> ]

# 配置远程读取请求的 TLS 设置。

tls_config:

[ <tls_config> ]

# 可选的代理 URL。

[ proxy_url: <string> ]

# 配置HTTP请求是否遵循HTTP 3xx重定向。

[ follow_redirects: <bool> | default = false]

总结:Prometheus 的远程写入和远程读取功能允许透明地发送和接收样本。 这主要用于长期存储。 在官网有一个详细的解释说明,如果后端接存储可以看下官网,https://prometheus.io/docs/operating/integrations/#remote-endpoints-and-storage

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
构建企业级监控平台系列(十三):Prometheus Server 配置详解
更多关于企业级监控平台系列的学习文章,请参阅:构建企业级监控平台,本系列持续更新中。
民工哥
2023/10/23
1.8K0
构建企业级监控平台系列(十三):Prometheus Server 配置详解
自建 Prometheus 采集腾讯云容器服务监控数据最佳实践
用 Prometheus 采集腾讯云容器服务的监控数据时如何配置采集规则?主要需要注意的是 kubelet 与 cadvisor 的监控指标采集,本文分享为 Prometheus 配置 scrape_config 来采集腾讯云容器服务集群的监控数据的方法。
imroc
2022/08/01
3.2K3
自建 Prometheus 采集腾讯云容器服务监控数据最佳实践
Promtail 配置文件说明
Promtail 是负责收集日志发送给 loki 的代理程序,Promtail 默认通过一个 config.yaml 文件进行配置,其中包含 Promtail 服务端信息、存储位置以及如何从文件中抓取日志等配置。
我是阳明
2021/05/17
22K3
Promtail 配置文件说明
【云原生 • Prometheus】Prometheus 注册中心Eureka服务发现原理
Eureka服务发现协议允许使用Eureka Rest API检索出Prometheus需要监控的targets,Prometheus会定时周期性的从Eureka调用Eureka Rest API,并将每个应用实例创建出一个target。
Reactor2020
2023/04/20
4830
【云原生 • Prometheus】Prometheus 注册中心Eureka服务发现原理
Grafana Promtail 配置解析
-print-config-stderr 通过 ./promtail 直接运行Promtail时能够快速输出配置 -log-config-reverse-order 配置通过反向输出,这样再Grafana中就能从上到下正确读取
阿提说说
2024/01/11
1.4K0
使用 vmagent 代替 Prometheus 采集监控指标
vmagent 可以帮助我们从各种来源收集指标并将它们存储在 VM 或者任何其他支持 remote write 协议的 Prometheus 兼容的存储系统中。
我是阳明
2022/05/22
3.8K0
使用 vmagent 代替 Prometheus 采集监控指标
Prometheus2.8简介 原
Prometheus(普罗米修斯)是一套最初在SoundCloud上构建的开源监视和告警系统 。
阿dai学长
2019/04/03
8550
【实践】2.Prometheus命令和配置详解
Prometheus配置方式有两种: (1)命令行,用来配置不可变命令参数,主要是Prometheus运行参数,比如数据存储位置 (2)配置文件,用来配置Prometheus应用参数,比如数据采集,报警对接
辉哥
2021/04/01
4.7K0
第03期:Prometheus 数据采集(二)
爱可生上海研发中心成员,研发工程师,主要负责 DMP 平台监控告警功能的相关工作。
爱可生开源社区
2020/06/28
2.1K0
构建企业级监控平台系列(十二):Prometheus 入门与安装
Prometheus 是一个开源的服务监控系统和时序数据库,最初由SoundCloud开发的开源的系统监控和报警工具包。自2012年诞生以来,被许多公司和组织采用,该项目拥有非常活跃的社区和开发者。Prometheus 现在是一个独立的开源项目,独立于任何公司进行维护。为了证明这一点,Prometheus 于2016年加入了云原生计算基金会CNCF,成为了继Kubernetes之后的第二个CNCF托管项目。
民工哥
2023/10/23
1.2K0
构建企业级监控平台系列(十二):Prometheus 入门与安装
构建企业级监控平台系列(二十二):Prometheus 基于 K8S 服务发现详解
Prometheus Server 的数据抓取工作基于 Pull 模型,因而,它必须要事先知道各 target 的位置,然后才能从相应的 Exporter 或 Instrumentation 中抓取数据。
民工哥
2023/10/31
2.2K0
构建企业级监控平台系列(二十二):Prometheus 基于 K8S 服务发现详解
Prometheus监控k8s集群组件
cAdvisor已经内置在了 kubelet 组件之中,所以不需要单独去安装,cAdvisor的数据路径为/api/v1/nodes//proxy/metrics,同样这里使用 node 的服务发现模式,因为每一个节点下面都有 kubelet,自然都有cAdvisor采集到的数据指标,配置如下:
mikelLam
2022/10/31
1.4K0
Prometheus监控k8s集群组件
prometheus内核
这篇文章会着重分析 其中的 discovery => scrap => storage 的流程
王磊-字节跳动
2019/12/29
2.5K0
prometheus (三) 服务发现
基于 centos7.9 docker-ce-20.10.18 kubelet-1.22.3-0 kube-prometheus-0.10 prometheus-v2.32.1
Amadeus
2023/05/02
1.2K0
prometheus (三) 服务发现
what is vmagent
在之前的文章中,讲解了如何在k8s上安装vm;但采集指标的组件使用的是opentelemetry,那么vm是否有自己的组件去采集指标呢?实际上,vm是拥有自己的组件可以去替代opentelemetry,它就是vmagent。使用它也可以进行指标的收集,再存储到vmstorage。
没有故事的陈师傅
2022/02/09
1.2K0
what is vmagent
使用prometheus监控多k8s集群
调研发现prometheus配合node_exporter、kube-state-metrics可以很方便地采集单个集群的监控指标。因此最初的构想是在每套k8s集群里部署prometheus,由它采集该集群的监控指标,再运用prometheus的联邦模式将多个prometheus中的监控数据聚合采集到一个中心prometheus里来,参考模型为Hierarchical federation。
jeremyxu
2019/03/13
10.1K8
使用prometheus监控多k8s集群
prometheus k8s服务发现
被监控的目标(target)是整个监控体系中重要组成部分,传统监控系统zabbix通过 网络发现的机制自动创建主机到zabbix-server,进而快速地对目标进行监控。同样在Prometheus监控中存在一个叫 服务发现的机制,在k8s容器环境中由于集群内实例网络地址是动态的,我们不可能每次创建或修改实例都将实例IP写入Prometheus的target中,借助 服务发现我们可以快速的将集群内的资源注册到Prometheus-server中。
你大哥
2022/03/14
2K0
prometheus k8s服务发现
Prometheus 标签全揭秘:从数据源到仪表盘
前言:本文通俗易懂地介绍了 Prometheus 标签,并且直击用户痛点,提供避坑指南。以下内容由腾讯云 Prometheus 团队雷畅、徐帅、赵志勇共同创作。
腾讯云可观测平台
2025/02/11
3530
Prometheus 标签全揭秘:从数据源到仪表盘
Prometheus监控学习笔记之prometheus的远端存储
prometheus在容器云的领域实力毋庸置疑,越来越多的云原生组件直接提供prometheus的metrics接口,无需额外的exporter。所以采用prometheus作为整个集群的监控方案是合适的。但是metrics的存储这块,prometheus提供了本地存储,即tsdb时序数据库。本地存储的优势就是运维简单,启动prometheus只需一个命令,下面两个启动参数指定了数据路径和保存时间。
Jetpropelledsnake21
2019/03/08
5.2K0
Prometheus监控学习笔记之prometheus的远端存储
【prometheus】-04 轻松搞定Prometheus Eureka服务发现
Eureka服务发现协议允许使用Eureka Rest API检索出Prometheus需要监控的targets,Prometheus会定时周期性的从Eureka调用Eureka Rest API,并将每个应用实例创建出一个target。
Reactor2020
2023/03/22
7350
【prometheus】-04 轻松搞定Prometheus Eureka服务发现
推荐阅读
相关推荐
构建企业级监控平台系列(十三):Prometheus Server 配置详解
更多 >
交个朋友
加入HAI高性能应用服务器交流群
探索HAI应用新境界 共享实践心得
加入架构与运维学习入门群
系统架构设计入门 运维体系构建指南
加入架构与运维工作实战群
高并发系统设计 运维自动化实践
换一批
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档