什么是PrometheusPrometheus是由SoundCloud开源、前Google工程师借鉴Google Borg监控体系理念打造的云原生时序数据库兼监控告警系统2016年加入CNCF云原生基金会并顺利毕业采用Pull拉取模式采集服务器、容器、数据库、中间件与业务程序的各项指标依托多维度标签Label存储时序数据内置PromQL查询语言、时序数据库、告警及可视化模块是K8s容器生态主流标配监控基础设施核心作用就是监测系统各类运行指标并在异常时自动告警。核心架构组件1.Prometheus Server主服务定时拉取监控指标、本地时序存储、执行 PromQL、规则预计算Prometheus Server核心组件负责 Service Discovery服务发现、Scrape指标采集、TSDB本地时序数据库、PromQL 查询、Recording Rules预计算规则、Alert Rules告警规则计算。因为 Prometheus Server 内部其实包含几个子模块Prometheus Server ┌──────────────────┐ │Service Discovery │ ├──────────────────┤ │Scrape Manager │ ├──────────────────┤ │TSDB │ ├──────────────────┤ │PromQL Engine │ ├──────────────────┤ │Rule Engine │ └──────────────────┘所以它不仅仅是拉数据而是自动发现目标、抓取、规则计算、查询执行、本地存储2.Exporter各类组件指标采集端Node Exporter 服务器硬件、MySQL Exporter 数据库、Kube-State-Metrics K8s 资源Exporter 本质就是把各种系统转换成 Prometheus 能理解的 /metrics 格式。例如Linux ↓ Node Exporter ↓ /metrics ↓ PrometheusMySQL ↓ MySQL Exporter ↓ /metrics很多新人误以为Exporter 是采集器。更准确的说法是Exporter 是一个翻译器Adapter。3.Pushgateway适配短生命周期任务脚本、CI 任务主动推送指标再由 Prometheus 拉取这里需要明确一点普罗米修斯的这个核心组件并不是指由服务向普罗米修斯推送它的一个服务状态而是由Prometheus自己主动去拉取询问服务的一个状态信息。4.Alertmanager独立告警管理组件负责告警去重、分组、静默、路由分发钉钉 / 邮件 / 企业微信Prometheus ↓ Alertmanager ↓ Deduplicate去重 ↓ Group聚合 ↓ Silence静默 ↓ Route路由 ↓ Receiver ↓ 邮件 企业微信 Slack 钉钉5.Grafana常用配套可视化面板Prometheus 仅自带简易 UI生产环境基本搭配 Grafana 做大盘。核心数据模型以指标名 多维度标签唯一标识一条时序线例如node_cpu_seconds_total{cpu“0”,mode“idle”,instance“192.168.1.10”}支持灵活聚合、过滤、分组统计。四种基础指标类型1.Counter计数器只增不减用于请求总量、错误数、总流量2.Gauge仪表盘可增可减CPU 使用率、内存占用、在线人数3.Histogram直方图统计数据分布接口响应耗时分位数4.Summary摘要直接计算分位数适合客户端侧预聚合。Prometheus的优点架构简单易部署无强依赖单二进制文件即可启动开箱即用无需额外数据库集群单机部署成本极低小团队几分钟搭建监控体系。原生适配云原生 KubernetesK8s 官方主推监控方案支持服务发现SDKubernetes SD、Consul SD、DNS SD、文件 SD容器 Pod 扩缩容自动发现目标不用手动改配置。Pull 拉取架构更适合分布式集群服务端主动定时抓取目标指标被监控端无感知相比传统 Zabbix Agent 主动上报集群节点多、动态扩缩容时不会出现大量客户端往服务端疯狂推送造成流量风暴服务端统一管控采集频率方便权限与采集策略收敛。强大灵活的 PromQL 查询语言支持聚合、过滤、四则运算、速率计算、区间查询、多指标关联、多维度分组可实现复杂业务监控PV、UV、错误率、饱和度计算。自带告警能力生态极其丰富Alertmanager 支持告警抑制、分组、静默、分级路由社区海量 Exporter 覆盖几乎所有中间件、数据库、硬件、中间件Redis、Nginx、ES、RabbitMQ、JVM、Windows、交换机等。自带本地时序存储轻量化持久化默认本地磁盘存储时序数据短期监控无需对接外部存储支持远程读写Remote Read/Remote Write对接 Thanos、VictoriaMetrics 实现集群与长期存储。完全开源免费社区活跃CNCF 顶级项目文档完善大厂大规模落地资料、模板、问题方案极多。支持多语言 SDK 埋点Java/Python/Go/PHP/.NET 都有官方客户端业务代码可自定义埋点上报业务指标订单量、支付数。Prometheus 缺点单机存储有瓶颈不适合超大规模长期存储默认本地存储单节点有磁盘、IO、查询性能上限原生不支持集群分片、高可用、数据持久化多副本单实例挂掉会丢数据需额外部署 Thanos / VictoriaMetrics / Cortex 做集群化、对象存储长期归档架构复杂度上升。Pull 模式对不可寻址场景不友好被监控机器在内网 NAT、防火墙后Prometheus 无法主动拉取短生命周期一次性任务Shell 脚本、Job 任务无法暴露 HTTP 接口被拉取必须依赖 Pushgateway 中转额外增加组件。不适合日志监控与链路追踪只擅长指标Metric监控不能直接采集日志、堆栈、调用链日志需要搭配 Loki / ELK链路追踪搭配 Jaeger / SkyWalking属于互补组件而非替代。PromQL 学习成本较高语法逻辑和传统 SQL 差异大分位数、瞬时向量 / 区间向量、rate/increase 函数容易误用新手容易写出错误监控语句。原生无精细化权限与多租户单 Prometheus 实例默认无账号权限隔离多业务线共用需要二次开发或依托上层中间件做权限管控。告警能力基础无内置工单闭环Alertmanager 只负责转发告警没有告警认领、处理记录、工单流转需要对接运维平台二次开发。数据精度固定不适合高频超高密采集默认按秒级抓取若毫秒级高频采集会产生海量时序数据磁盘压力巨大。Prometheus 适用场景Kubernetes / 容器化集群环境监控Pod、Deployment、Service、Node、Ingress 资源监控集群资源使用率、容器 CPU / 内存 / 磁盘网络监控云原生首选。服务器基础设施监控Linux/Windows 主机 CPU、内存、磁盘 IO、网卡、系统负载、磁盘使用率替代传统 Zabbix 做主机监控。中间件与数据库运维监控MySQL、PostgreSQL、Redis、Nginx、Elasticsearch、MQ、Tomcat、JVM 进程运行指标监控。微服务业务指标埋点监控业务代码埋点接口 QPS、响应耗时、异常错误率、订单数量、用户注册量、缓存命中率等核心业务度量指标。中小型运维监控平台中小企业、初创团队轻量化运维监控快速搭建告警 大盘部署维护成本低。DevOps 流水线 定时任务监控配合 Pushgateway 监控 CI/CD 构建任务、定时脚本执行状态、定时任务成功率。物联网、边缘节点集群监控边缘设备数量多、动态上线下线依靠服务发现自动管理监控目标。Prometheus不适用的场景纯日志收集与检索不要用来替代 ELK/Loki 做日志全文检索海量数据长期归档存储PB 级单节点 Prometheus 无力承载必须搭配远端存储组件强审计、多租户严格权限隔离的大型集团多租户监控原生能力不足调用链全链路追踪无法替代 SkyWalking、Pinpoint设备完全离线、完全无法网络互通Pull 模式完全无法使用。这边我用docker进行实战这个Prometheus并在 Java 项目中使用这个Prometheus。首先在 Java 项目中你需要先在POM文件中引入对应的一个依赖。!--监控--dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-actuator/artifactId /dependency dependency groupIdio.micrometer/groupId artifactIdmicrometer-registry-prometheus/artifactId /dependencyspring-boot-starter-actuator 端点提供者Spring Boot Starter Actuator 它是让 Prometheus 能够接入 Java 项目的一个起步的依赖。除了提供端点它还提供了健康检查、信息展示等内置端点自动集成 Micrometer提供了统一的监控端点入口micrometer-registry-prometheus 格式转换器它的具体作用是实现 MeterRegistry 接口将 Micrometer 的指标模型转换为 Prometheus 的文本格式自动注册 /actuator/prometheus 端点处理 Prometheus 特有的标签labels格式帮你引入上面的这个 Actuator 和 Micrometer Registry Prometheus 的依赖时候会有依赖传递机制自动包含micrometer-core。micrometer-core数据收集者它是一个 指标门面 类似 SLF4J作用是提供统一的 API 来记录指标支持多种指标类型Counter计数器、Gauge仪表盘、Timer计时器、DistributionSummary分布统计内置了 JVM、HTTP、数据库等指标的自动收集不绑定具体的监控系统 可以对接 Prometheus、Graphite、Datadog 等其次你需要编写 prometheus.yml文件# Prometheus 配置文件global:scrape_interval:15s# 全局抓取间隔evaluation_interval:15s# 规则评估间隔# 告警管理器配置 (可选)alerting:alertmanagers:-static_configs:-targets:# - alertmanager:9093# 规则文件配置rule_files:# - alert_rules.yml # 可以添加告警规则# 抓取配置scrape_configs:# Prometheus 自身监控-job_name:prometheusstatic_configs:-targets:[localhost:9090]# Spring Boot 应用监控-job_name:metrics_path:/api/actuator/prometheus# Spring Boot Actuator 端点static_configs:-targets:[host.docker.internal:8123]# 宿主机上的 Spring Boot通过 host.docker.internal 访问scrape_interval:10s# 每 10 秒抓取一次scrape_timeout:10s# 抓取超时时间这里我们一行一行的来看首先是 global 那个顶格的一个关键词。作用 定义全局配置块这些配置对所有抓取任务生效注意事项 缩进必须是 2 个空格YAML 语法要求配置要求 必须在文件顶部适用场景 任何场景global配置的两行大概意思如下Prometheus 每隔 15 秒从目标拉取一次指标数据如果某个 job 没有单独设置就用这个值Prometheus 每隔 15 秒评估一次告警规则和记录规则之后是告警管理器配置alerting配置 Alertmanager 的连接信息。alertmanagers:是Alertmanager列表指定一个或多个 Alertmanager 实例static_configs:静态配置直接指定 Alertmanager 的地址而不是通过服务发现targets:目标地址列表Alertmanager 的访问地址alertmanager:9093Alertmanager 默认端口 9093这里被注释了说明当前没启用告警还有规则文件配置rule_files指定包含告警规则和记录规则的文件使用alert_rules.yml文件进行记录接下来是抓取配置scrape_configs。定义所有抓取任务jobsjob_name: prometheus’任务名称给这个抓取任务起个名字叫 “prometheus”用于标识static_configs:静态配置直接指定目标地址。targets: [‘localhost:9090’]目标地址Prometheus 监控自己地址是 localhost:9090抓取配置 - Spring Boot 应用监控metrics_path: /api/actuator/prometheus’指标路径。从哪个 URL 路径获取指标数据覆盖默认的 /metrics targets: [‘host.docker.internal:8123’]。目标地址。Spring Boot 应用的地址 host.docker.internal 是 Docker 宿主机的特殊域名scrape_interval: 10s。抓取间隔。这个 job 单独设置每 10 秒抓取一次覆盖全局的 15 秒。scrape_timeout: 10s。抓取超时。单次抓取请求的超时时间是 10 秒。最后你需要在docker-compose.yml文件中将Prometheus的容器配置好services:# Prometheus 监控服务 - 教学示例prometheus:image:prom/prometheus:latestcontainer_name:prometheus-teachingports:-9090:9090# Prometheus Web UI 端口volumes:# 挂载 Prometheus 配置文件-./prometheus.yml:/etc/prometheus/prometheus.yml# 挂载数据卷实现数据持久化防止容器重启后数据丢失-prometheus-data:/prometheuscommand:# 指定配置文件路径---config.file/etc/prometheus/prometheus.yml# 指定数据存储路径---storage.tsdb.path/prometheus# 设置数据保留时间为 15 天生产环境建议设置---storage.tsdb.retention.time15d# 启用控制台库用于 Web UI---web.console.libraries/usr/share/prometheus/console_libraries---web.console.templates/usr/share/prometheus/consolesnetworks:-prometheus-network# 健康检查确保 Prometheus 正常运行healthcheck:test:[CMD,wget,--quiet,--tries1,--spider,http://localhost:9090/-/healthy]interval:30stimeout:10sretries:3start_period:40srestart:unless-stopped# 自动重启策略除非手动停止# 数据卷定义volumes:prometheus-data:name:prometheus-teaching-data# 给数据卷起个明确的名字# 网络定义networks:prometheus-network:name:prometheus-teaching-networkdriver:bridge首先在docker-compose.yml文件中写好Prometheus的服务配置信息services:# Prometheus 监控服务 - 教学示例prometheus:image:prom/prometheus:latestcontainer_name:prometheus-teachingports:-9090:9090# Prometheus Web UI 端口volumes:# 挂载 Prometheus 配置文件-./prometheus.yml:/etc/prometheus/prometheus.yml# 挂载数据卷实现数据持久化防止容器重启后数据丢失-prometheus-data:/prometheuscommand:# 指定配置文件路径---config.file/etc/prometheus/prometheus.yml# 指定数据存储路径---storage.tsdb.path/prometheus# 设置数据保留时间为 15 天生产环境建议设置---storage.tsdb.retention.time15d# 启用控制台库用于 Web UI---web.console.libraries/usr/share/prometheus/console_libraries---web.console.templates/usr/share/prometheus/consolesnetworks:-prometheus-network# 健康检查确保 Prometheus 正常运行healthcheck:test:[CMD,wget,--quiet,--tries1,--spider,http://localhost:9090/-/healthy]interval:30stimeout:10sretries:3start_period:40srestart:unless-stopped# 自动重启策略除非手动停止# 数据卷定义volumes:prometheus-data:name:prometheus-teaching-data# 给数据卷起个明确的名字# 网络定义networks:prometheus-network:name:prometheus-teaching-networkdriver:bridge开头service服务定义块定义所有要运行的 Docker 服务容器的开始下面缩进的内容都是服务配置。prometheus:服务名称。给这个服务起个名字叫 “prometheus”在 Docker Compose 内部可以通过这个名字访问服务。image: prom/prometheus:latest。指定使用的镜像告诉 Docker 从 Docker Hub 的 prom 仓库拉取 prometheus 镜像版本是 latest 最新版。container_name: prometheus-teaching。自定义容器名称给容器起个明确的名字方便管理和识别。如果不设置Docker 会自动生成一个随机名字。ports: - “9090:9090”ports:端口映射配置块。定义宿主机和容器之间的端口映射关系。“9090:9090”。端口映射规则。格式 宿主机端口:容器端口将宿主机的 9090 端口映射到容器的 9090 端口这样访问 http://localhost:9090 就能访问到容器内的 Prometheus Web UI。volumes:数据卷配置块。定义宿主机和容器之间的文件/目录挂载关系。./prometheus.yml:/etc/prometheus/prometheus.yml。bind mount绑定挂载格式 宿主机路径:容器路径将宿主机当前目录下的 prometheus.yml 文件挂载到容器内的 /etc/prometheus/prometheus.yml 这样修改宿主机的文件就能直接影响容器不需要重新构建镜像。prometheus-data:/prometheus。named volume命名卷挂载一个命名数据卷到容器的 /prometheus 目录用于持久化 Prometheus 的数据防止容器删除后数据丢失。command:启动命令配置块覆盖镜像默认的启动命令传递自定义参数给 Prometheus。–config.file/etc/prometheus/prometheus.yml。指定配置文件。告诉 Prometheus 从哪里读取配置文件。–storage.tsdb.path/prometheus。指定数据存储路径告诉 Prometheus 把时序数据存储在容器的 /prometheus 目录。–storage.tsdb.retention.time15d数据保留时间设置 Prometheus 数据保留 15 天超过 15 天的数据会自动清理防止磁盘空间耗尽。–web.console.libraries 和 --web.console.templates。控制台库路径。指定 Web UI 的控制台库和模板路径启用一些内置的控制台功能。networks:网络配置块定义这个服务要连接的 Docker 网络。prometheus-network网络名称。将这个服务连接到名为 prometheus-network 的网络同一个网络中的服务可以通过服务名互相访问。healthcheck:健康检查配置块。定义如何检查容器是否健康运行。test: [“CMD”, “wget”, …]健康检查命令。使用 wget 访问 Prometheus 的健康检查端点 /-/healthy 如果能正常访问说明服务健康。interval: 30s 检查间隔 每 30 秒检查一次健康状态。timeout: 10s 超时时间 单次检查如果超过 10 秒没响应就认为检查失败。retries: 3 重试次数 连续失败 3 次才认为容器不健康。start_period: 40s 启动宽限期 容器启动后的前 40 秒内即使健康检查失败也不计入重试次数给应用足够的启动时间。restart: unless-stopped # 自动重启策略除非手动停止volumes: 数据卷定义块 定义这个 Compose 文件中用到的命名数据卷。prometheus-data: 数据卷引用名 在服务配置中通过这个名字引用数据卷。name: prometheus-teaching-data 数据卷名称 给数据卷起个明确的名字方便在 Docker 中管理。networks: 网络定义块 定义这个 Compose 文件中用到的 Docker 网络。prometheus-network: 网络引用名 在服务配置中通过这个名字引用网络。name: prometheus-teaching-network 网络名称 给网络起个明确的名字方便管理。driver: bridge 网络驱动 使用 bridge 驱动Docker 默认的网络驱动适合单机多容器通信。Prometheus看板监控使用学习首先呢前面的环境起好之后的话你在浏览器的一个地址栏上输入 localhost:9090就可以来到 Prometheus 的一个首页了。如下图所示首先的话我先给大家介绍一个比较重要的一个路径就是这个9090后面再加一个/metrics。你就能看到下面这个页面内容。使用 Prometheus UI访问http://localhost:9090在 Expression Browser 中输入 PromQL 查询语句例如up- 查看监控目标是否在线rate(http_requests_total[5m])- 查看请求速率使用命令行工具curlhttp://localhost:9090/metrics1. 指标类型解析Prometheus 有四种核心指标类型类型说明示例Counter只增不减的计数器请求总数、错误总数Gauge可增可减的瞬时值内存使用量、CPU 使用率、连接数Histogram分桶统计的直方图请求延迟分布Summary分位数统计请求延迟的 95%/99% 分位数2. 关键信息维度系统资源CPU、内存、磁盘、网络使用情况应用性能请求延迟、吞吐量、错误率业务指标活跃用户数、订单量等自定义指标健康状态服务是否存活、依赖服务状态1. 监控黄金指标Four Golden Signals根据 Google SRE 理论重点关注延迟Latency请求处理时间流量Traffic请求速率错误率Errors失败请求比例饱和度Saturation系统资源使用程度2. 关键监控目标# 示例监控 Web 应用-请求成功率99.9%-P99 延迟 200ms-CPU 使用率 70%-内存使用率 80%-磁盘使用率 85%3. 告警规则示例groups:-name:examplerules:-alert:HighErrorRateexpr:rate(http_requests_total{status~5..}[5m]) / rate(http_requests_total[5m])0.05for:5mlabels:severity:criticalannotations:summary:High error rate detected4. 可视化建议Grafana连接 Prometheus 创建仪表盘预构建仪表盘Grafana 官网有大量社区仪表盘关键面板系统资源使用率应用 QPS 和延迟错误率和成功率业务指标趋势**###这个指标的完整解读我们可以把这个名字拆成5个部分来理解拆解后你就能看懂所有TSDB相关指标的含义部分含义prometheus_tsdbPrometheus 时间序列数据库Time Series Database模块的指标compaction数据压缩操作TSDB 会把零散的小数据块合并成更大的块优化存储和查询性能chunk_range压缩后的单个数据块覆盖的时间跨度单位是秒_bucket标识这是 Histogram直方图类型指标的分桶统计le100less than or equal to的缩写即统计时间跨度 ≤100秒 的数据块数量值 1055 的含义截至目前TSDB 中时间跨度 ≤100秒 的压缩数据块累计数量是 1055 个。Histogram 分桶指标的读法这类指标是 Prometheus 统计分布的核心方式通常会有3个配套指标prometheus_tsdb_compaction_chunk_range_seconds_bucket{le100} 1055 prometheus_tsdb_compaction_chunk_range_seconds_bucket{le1000} 12450 prometheus_tsdb_compaction_chunk_range_seconds_bucket{le10000} 32010 prometheus_tsdb_compaction_chunk_range_seconds_sum 2.3亿 prometheus_tsdb_compaction_chunk_range_seconds_count 32010你可以这么分析分布≤100秒的块1055个占比 3.3%100~1000秒的块12450-105511395个占比 35.6%1000~10000秒的块32010-1245019560个占比 61.1%平均时间跨度2.3亿 / 32010 ≈ 7186秒约2小时这个指标能反映什么系统状态1. 正常情况小时间跨度≤100秒的块占比越低越好说明压缩充分大部分数据都合并成了大块你当前 3.3% 的占比属于健康状态说明 TSDB 压缩效率高2. 异常情况需要关注如果le100的桶数量持续增长、占比超过 20%通常说明写入流量非常小数据块没有足够的素材合并成大块压缩配置不合理压缩频率过低存储的保留时间太短还没来得及压缩就被删除了3. 对生产性能的影响小时间跨度的块过多会导致查询时需要读取更多的数据块增加 I/O 开销查询延迟升高索引体积膨胀内存占用增加1. 配套监控指标你可以搜索这几个相关指标做综合判断prometheus_tsdb_compactions_total总压缩次数如果长期不增长说明压缩没生效prometheus_tsdb_compaction_duration_seconds压缩耗时如果持续过高说明磁盘性能不足prometheus_tsdb_retention_boundaries数据保留边界确认保留时间配置是否合理2. 告警规则建议-alert:PrometheusTSDBTooManySmallChunksexpr:|(prometheus_tsdb_compaction_chunk_range_seconds_bucket{le100} / prometheus_tsdb_compaction_chunk_range_seconds_count) 0.2for:1hlabels:severity:warningannotations:summary:Prometheus TSDB 小时间跨度过高压缩效率低3. 优化方向如果小桶占比过高可以调整启动参数--storage.tsdb.min-block-duration2h最小块时间避免生成过小的块--storage.tsdb.max-block-duration24h最大块时间控制合并后的块大小还有一个要看的一个面板指标。图中能看到缓存的信息然后一系列的一个 API 请求的耗时问题等。最后基本上普罗米修斯都是结合 Grafana 进行一个配套的一个开发者运维使用的。