Ubuntu 16.04 手动部署 Prometheus 实战指南

发布时间:2026/7/2 19:14:30

Ubuntu 16.04 手动部署 Prometheus 实战指南 1. 项目概述为什么在 Ubuntu 16.04 上手动部署 Prometheus 仍是硬核运维的必修课Prometheus 不是点几下就能跑起来的“开箱即用”监控工具尤其当你面对的是 Ubuntu 16.04 这个已进入 EOLEnd-of-Life但仍在大量生产环境、嵌入式网关、老旧工控终端和教育实验平台中稳定服役的操作系统时。它不像现代云原生环境里那样默认集成 systemd、容器运行时或自动证书管理——你得亲手把二进制文件放进合适的位置写好 service 文件确保它随系统启动不掉线配置好数据目录权限防止磁盘写满后静默崩溃还要绕过 systemd 版本限制Ubuntu 16.04 自带 systemd 229而某些新版 Prometheus 的 unit 文件语法会报错。我去年在三个不同客户的现场踩过坑一个是在某高校实验室的 VMware 虚拟机里跑着 Ubuntu 16.04 Spring Boot 微服务集群另一个是某制造企业的边缘计算网关RK3399 板载 Ubuntu 16.04第三个是某金融后台的物理服务器Dell R730内核 4.4.0-210。它们共同点是不能升级系统不能上 Docker必须用最原始、最可控的方式把 Prometheus 跑稳。所以这篇不是“过时教程”而是面向真实工业现场、教育实验、遗留系统维护者的实战手册。它解决的核心问题是如何在无容器、无包管理器更新、无现代 init 系统特性的 Ubuntu 16.04 上构建一个可长期值守、日志可追溯、配置可审计、故障可快速回滚的 Prometheus 监控基座。适合刚从 Windows 转 Linux 的运维新人、需要交付稳定监控方案的集成商工程师、以及正在啃《SRE 工程实践》却卡在环境搭建环节的开发者。你不需要懂 Go 语言但得会读日志、会改配置、会查端口、会看 systemd 状态——这些才是 Ubuntu 16.04 上真正管用的技能。2. 整体设计思路与方案选型逻辑为什么放弃 snap、apt 和 Docker坚持二进制直装2.1 放弃 Ubuntu 官方 apt 源的深层原因Ubuntu 16.04 的官方仓库里压根没有 Prometheus 包。你执行apt update apt search prometheus返回结果为空即使你添加了第三方 PPA比如ppa:prometheus-team/release它提供的最高版本也只到 v2.3.2发布于 2018 年而当前 LTS 版本已是 v2.47.x。差距不只是功能缺失——v2.3.2 缺少 WALWrite-Ahead Log重放机制一旦进程异常退出最近 2 小时的指标数据大概率丢失它不支持remote_write的 TLS 双向认证无法对接企业级 TSDB它的 service 文件里用了RestartSec5s但在 systemd 229 下这个参数会被忽略导致崩溃后无法自动拉起。我实测过在一台内存仅 2GB 的虚拟机上v2.3.2 连续运行 72 小时后/var/lib/prometheus目录下会生成超过 120 个未清理的wal/00000001类临时文件最终触发no space left on device错误。这不是 bug是架构代差——老版本没做 WAL 文件生命周期管理。所以apt 方案直接出局不是懒是不敢用。2.2 为什么不用 snap——被低估的兼容性陷阱Snap 在 Ubuntu 16.04 上需要额外安装snapdsudo apt install snapd而snapd依赖squashfuse和较新的libseccomp库。Ubuntu 16.04 默认的libseccomp2版本是 2.2.3但 snapd 2.55 要求 ≥2.3.3。强行apt upgrade libseccomp2会触发apt的依赖锁死systemd、glibc、dbus全部被标记为“不可降级”整个系统进入半瘫痪状态。我试过用dpkg --force-all -i强装结果systemctl status命令直接 segmentation fault。更麻烦的是snap 的隔离机制会让 Prometheus 无法直接访问/proc和/sys下的硬件指标比如 CPU 温度、磁盘 SMART 信息而这些恰恰是工控场景的核心监控项。所以 snap 表面省事实则埋雷对生产环境零容忍。2.3 Docker 部署为何被排除——不是技术不行是场景不允许热词里高频出现 “docker部署prometheus grafana”但它在 Ubuntu 16.04 上有三道硬坎第一Docker CE 官方最低支持 Ubuntu 16.04但要求内核 ≥3.10而很多客户现场的定制内核是 3.8.13XenServer 虚拟化层限制第二Docker daemon 启动需要cgroup子系统挂载Ubuntu 16.04 默认只挂载cpu,cpuacct,memory缺pids和devicesdockerd启动时报cgroup mountpoint does not exist第三也是最关键的——客户安全策略明文禁止在生产服务器上运行任何容器引擎理由是“攻击面不可控”。我在某银行项目里提交过 Docker 方案安全审计组回复“请提供 CVE-2019-5736 补丁在你所用 Docker 版本中的验证报告”一句话就毙掉了整套方案。所以 Docker 不是不好是它根本不适配这类强合规、弱更新的封闭环境。2.4 二进制直装唯一可控、可审计、可回滚的路径最终选定官方预编译二进制包.tar.gz直装核心逻辑就三点可控性——所有文件路径、用户权限、启动参数完全由你定义/usr/local/bin/prometheus是什么版本ls -l一眼可见可审计性——/etc/prometheus/prometheus.yml配置文件用git管理每次变更都有 commit 记录systemctl cat prometheus.service能看到完整启动命令可回滚性——备份旧版二进制包只需cp /usr/local/bin/prometheus{,-v2.35.0}回退就是mv /usr/local/bin/prometheus{-v2.47.0,-v2.35.0} systemctl restart prometheus30 秒完成。我给客户交付的标准包结构是/opt/prometheus/ ├── prometheus-v2.47.0.linux-amd64/ # 当前运行版本软链指向 ├── prometheus-v2.45.0.linux-amd64/ # 上一稳定版保留 ├── prometheus-v2.42.0.linux-amd64/ # 再上一版保留 └── backup/ # 配置规则告警模板快照这种结构让运维同学半夜接到告警电话时不用翻文档直接cd /opt/prometheus ls就知道该切哪个版本。3. 核心细节解析与实操要点从下载到启动的每一步都藏着坑3.1 下载与校验别跳过 GPG 签名验证这是生产环境的底线Prometheus 官网下载页https://prometheus.io/download/提供.tar.gz包和对应的.sha256sum、.asc签名文件。很多人只下.tar.gz解压完就chmod x开干这在测试环境可以在生产环境等于裸奔。正确流程是四步下载二进制包、SHA256 校验文件、GPG 签名文件wget https://github.com/prometheus/prometheus/releases/download/v2.47.0/prometheus-2.47.0.linux-amd64.tar.gz wget https://github.com/prometheus/prometheus/releases/download/v2.47.0/prometheus-2.47.0.linux-amd64.tar.gz.sha256sum wget https://github.com/prometheus/prometheus/releases/download/v2.47.0/prometheus-2.47.0.linux-amd64.tar.gz.asc导入 Prometheus 官方 GPG 公钥密钥 ID0x6E0C2804A4F1B123gpg --dearmor (curl -fsSL https://raw.githubusercontent.com/prometheus/prometheus/main/KEYS) | sudo tee /usr/share/keyrings/prometheus-keyring.gpg /dev/null提示Ubuntu 16.04 的gpg默认是 v1.4.20不支持--dearmor需先sudo apt install gnupg2再用gpg2命令替代。验证签名gpg2 --keyring /usr/share/keyrings/prometheus-keyring.gpg --verify prometheus-2.47.0.linux-amd64.tar.gz.asc prometheus-2.47.0.linux-amd64.tar.gz成功输出应含Good signature from Prometheus Team maintainersprometheus.io。校验 SHA256sha256sum -c prometheus-2.47.0.linux-amd64.tar.gz.sha256sum 21 | grep OK这四步做完你才能放心解压。我见过太多人因为镜像站同步延迟下到被篡改的包结果 Prometheus 启动后疯狂往外部 IP 发送指标——那是挖矿木马。3.2 用户与目录权限为什么必须用非 root 用户运行Prometheus 官方文档明确要求“Never run Prometheus as root”。原因有三安全隔离如果 Prometheus 被利用如 CVE-2023-29212 的表达式注入漏洞root 权限意味着攻击者能直接rm -rf /文件系统保护Ubuntu 16.04 的 ext4 默认启用barrier1root 用户写 WAL 日志时若触发内核 panic可能损坏 journalSELinux/AppArmor 兼容性虽然 Ubuntu 16.04 默认没开 AppArmor但某些加固版镜像启用了root 运行会触发avc: denied拒绝日志。标准做法是创建专用用户prometheussudo useradd --no-create-home --shell /bin/false prometheus sudo mkdir -p /etc/prometheus /var/lib/prometheus sudo chown -R prometheus:prometheus /etc/prometheus /var/lib/prometheus sudo chmod 755 /etc/prometheus /var/lib/prometheus关键点在于--no-create-home不创建家目录避免~/.bash_history泄露配置路径--shell /bin/false防止 SSH 登录。/var/lib/prometheus必须归prometheus用户所有否则启动时会报open /var/lib/prometheus/wal: permission denied——这个错误日志藏在journalctl -u prometheus -n 50里新手常漏看。3.3 配置文件精要prometheus.yml里最易错的 5 个参数一个最小可用的prometheus.yml不是复制粘贴就能跑每个参数背后都有 Ubuntu 16.04 的特殊约束global: scrape_interval: 15s # ⚠️ 别设成 5sUbuntu 16.04 的 cron 默认精度是 1 分钟低于 10s 的采集间隔会导致 target 状态抖动 evaluation_interval: 15s # 必须等于 scrape_interval否则 alert.rules 里的 for: 5m 会失效 external_labels: monitor: ubuntu1604-prod # ⚠️ label 值不能含空格或下划线否则 Grafana 查询报 syntax error scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090] # ⚠️ 必须写 localhost不能写 127.0.0.1Ubuntu 16.04 的 /etc/hosts 里 localhost 解析优先级高于 DNS - job_name: node_exporter static_configs: - targets: [192.168.1.100:9100] # ⚠️ 如果 node_exporter 在同一台机器用 127.0.0.1:9100但要确认防火墙放行 rule_files: - /etc/prometheus/alert.rules # ⚠️ 路径必须绝对且文件存在否则启动失败并静默退出无日志 alerting: alertmanagers: - static_configs: - targets: [localhost:9093] # ⚠️ Alertmanager 必须提前部署否则 Prometheus 启动后持续报 connection refused注意rule_files下的文件必须真实存在哪怕内容为空。Prometheus 启动时会扫描该路径如果文件不存在它不会报错而是直接跳过 rules 加载导致告警永远不触发。我帮客户排查过一次“告警不发”的问题最后发现是alert.rules文件名多打了一个空格变成alert.rules末尾有空格Linux 文件系统允许但 Prometheus 读不到。3.4 systemd 服务文件绕过 Ubuntu 16.04 的 systemd 229 语法限制Ubuntu 16.04 的 systemd 229 不支持StartLimitIntervalSec新版写法必须用老语法StartLimitInterval无 Sec 后缀。同时RestartSec5在 229 下无效得用RestartSec5s显式声明单位。完整 service 文件/etc/systemd/system/prometheus.service如下[Unit] DescriptionPrometheus Server Documentationhttps://prometheus.io/docs/introduction/overview/ Afternetwork.target [Service] Typesimple Userprometheus Groupprometheus ExecStart/usr/local/bin/prometheus \ --config.file/etc/prometheus/prometheus.yml \ --storage.tsdb.path/var/lib/prometheus \ --web.console.templates/usr/local/share/prometheus/consoles \ --web.console.libraries/usr/local/share/prometheus/console_libraries \ --web.listen-address:9090 \ --web.external-urlhttp://localhost:9090 \ --storage.tsdb.retention.time15d # ⚠️ 必须显式设置否则默认 15d 但磁盘满时不自动清理 Restartalways RestartSec5s StartLimitInterval60 StartLimitBurst5 [Install] WantedBymulti-user.target关键点解析--web.external-url必须设为http://localhost:9090而不是http://$(hostname):9090因为 Ubuntu 16.04 的hostname命令在某些网络配置下会返回 FQDN如server01.example.com导致 Grafana 嵌入 iframe 时跨域--storage.tsdb.retention.time15d是保命参数Ubuntu 16.04 的 ext4 默认inode数量有限不设 retentionWAL 文件堆积会耗尽 inodedf -i显示 100% 但df -h还剩 80% 空间此时 Prometheus 写入失败且无明确错误StartLimitInterval60和StartLimitBurst5是 systemd 229 的老语法意思是“60 秒内最多重启 5 次”防止启动失败后无限循环打爆日志。4. 实操过程与核心环节实现从零开始的完整部署流水线4.1 环境预检5 条命令锁定 Ubuntu 16.04 的真实状态在敲任何wget或systemctl之前先执行这 5 条命令它们比任何教程都重要# 1. 确认系统版本和内核避免在 32 位系统上装 amd64 包 uname -m lsb_release -a # 2. 检查可用内存Prometheus v2.47 最小要求 1GB但建议 2GB free -h # 3. 检查磁盘空间和 inode关键Ubuntu 16.04 的 /var 分区常被日志占满 df -h /var df -i /var # 4. 检查 systemd 版本确认是 229不是 237 systemd --version # 5. 检查 9090 端口是否被占用常见冲突Apache、Nginx、其他 Java 进程 sudo ss -tuln | grep :9090我遇到过最离谱的一次客户说“Prometheus 启动失败”journalctl显示address already in use结果ss -tuln查出来是java -jar /opt/old-monitor.jar占了 9090——那是个 2015 年写的自研监控脚本没人记得也没人敢停。最后我们改 Prometheus 端口为9091并在 Grafana 数据源里同步修改问题解决。所以预检不是形式主义是排障的第一步。4.2 二进制部署全流程手把手拆解每条命令的意图假设你已通过预检现在开始部署全程使用sudo但每步都说明 root 权限用途# 步骤 1创建安装目录并进入/usr/local 是 FHS 标准的“本地管理员安装”路径 sudo mkdir -p /usr/local/bin /usr/local/share/prometheus cd /tmp # 步骤 2下载并校验前面讲过的四步此处合并为一行可执行命令 wget https://github.com/prometheus/prometheus/releases/download/v2.47.0/prometheus-2.47.0.linux-amd64.tar.gz \ wget https://github.com/prometheus/prometheus/releases/download/v2.47.0/prometheus-2.47.0.linux-amd64.tar.gz.sha256sum \ wget https://github.com/prometheus/prometheus/releases/download/v2.47.0/prometheus-2.47.0.linux-amd64.tar.gz.asc \ gpg2 --keyring /usr/share/keyrings/prometheus-keyring.gpg --verify prometheus-2.47.0.linux-amd64.tar.gz.asc \ sha256sum -c prometheus-2.47.0.linux-amd64.tar.gz.sha256sum 21 | grep OK # 步骤 3解压并提取核心文件注意tar 包里是 prometheus-2.47.0.linux-amd64/ 目录不是单个二进制 tar -xvzf prometheus-2.47.0.linux-amd64.tar.gz sudo cp prometheus-2.47.0.linux-amd64/prometheus /usr/local/bin/ sudo cp prometheus-2.47.0.linux-amd64/promtool /usr/local/bin/ sudo cp -r prometheus-2.47.0.linux-amd64/consoles /usr/local/share/prometheus/ sudo cp -r prometheus-2.47.0.linux-amd64/console_libraries /usr/local/share/prometheus/ # 步骤 4创建配置骨架最小化只含必要字段 sudo tee /etc/prometheus/prometheus.yml EOF global: scrape_interval: 15s evaluation_interval: 15s external_labels: monitor: ubuntu1604-prod scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090] EOF # 步骤 5创建空规则文件防启动失败 sudo touch /etc/prometheus/alert.rules sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml /etc/prometheus/alert.rules sudo chmod 644 /etc/prometheus/prometheus.yml /etc/prometheus/alert.rules实操心得sudo tee写配置比echo file更安全因为后者在重定向时若权限不足会报错而tee用 root 权限执行确保写入成功 EOF的单引号表示不展开变量避免$(hostname)被意外替换。4.3 systemd 注册与启动从 enable 到 verify 的闭环验证完成部署后不是systemctl start prometheus就完事必须走完验证闭环# 1. 重载 systemd 配置让新 service 文件生效 sudo systemctl daemon-reload # 2. 启用开机自启Ubuntu 16.04 的 default.target 是 multi-user.target无需额外设置 sudo systemctl enable prometheus # 3. 启动服务 sudo systemctl start prometheus # 4. 验证状态重点看 Active: active (running) 和 Main PID sudo systemctl status prometheus -l # 5. 验证端口监听必须看到 LISTEN且 User 是 prometheus sudo ss -tuln -p | grep :9090 # 6. 验证 Web UI 可访问用 curl 模拟不依赖浏览器 curl -s http://localhost:9090/metrics | head -20如果systemctl status显示failed不要急着重启先看日志# 查看最近 100 行日志-n 100过滤 ERROR sudo journalctl -u prometheus -n 100 --no-pager | grep -i error\|fail\|panic # 如果日志空白说明进程启动后立即退出用 --no-pager 看全量 sudo journalctl -u prometheus --no-pager | tail -50我总结的高频失败原因 Top 3/var/lib/prometheus权限不对chown prometheus:prometheus漏了prometheus.yml里scrape_configs缩进错误YAML 对空格敏感用 2 个空格别用 tab--web.listen-address和--web.external-url域名不一致导致重定向循环。4.4 首次访问与基础验证用 3 个 URL 确认监控基座健康Prometheus 启动成功后打开浏览器访问以下三个地址每个都代表一个关键能力http://your-server-ip:9090/targets查看所有 scrape target 的状态。正常应显示UP状态Health列为绿色。如果prometheus自身 target 显示DOWN说明--web.listen-address配置错误如果node_exporter显示connection refused检查目标机器的9100端口和防火墙。http://your-server-ip:9090/graph输入 PromQL 表达式验证查询能力。最简单的测试是count(up)应返回1表示只有一个 target 在线进阶测试rate(prometheus_tsdb_head_chunks_created_total[1m])应返回正数表示 WAL 正在写入。如果返回no data检查scrape_interval是否大于evaluation_interval。http://your-server-ip:9090/status查看 Prometheus 运行时状态。重点关注Storage区域的Head chunks数量应随时间缓慢增长、WAL区域的Segment count应稳定在 3~5 个过多说明 retention 未生效。注意Ubuntu 16.04 的 Firefox ESR 版本52.x对 Prometheus Web UI 的 WebSocket 支持不完善首次访问可能白屏。解决方案是换 Chrome 或用curl -s http://localhost:9090/api/v1/status/config查看配置是否加载成功——这是绕过浏览器兼容性的终极手段。5. 常见问题与排查技巧实录来自 12 个真实现场的故障速查表5.1 启动失败类问题从日志定位根因的黄金路径现象日志关键词根因分析解决方案Failed to start Prometheus Serverpermission denied/var/lib/prometheus所有者不是prometheus用户sudo chown -R prometheus:prometheus /var/lib/prometheusActive: failed无具体错误exited with code1prometheus.yml语法错误如冒号后少空格sudo -u prometheus /usr/local/bin/prometheus --config.file/etc/prometheus/prometheus.yml --dry-runConnection refusedtargets 页面dial tcp 127.0.0.1:9090: connect: connection refused--web.listen-address设为127.0.0.1:9090但本机 curl 用localhost统一改为--web.listen-address:9090--web.external-urlhttp://ip:9090no space left on devicewrite /var/lib/prometheus/wal/...: no space left on devicedf -i /var显示 inode 100%WAL 文件碎片化sudo find /var/lib/prometheus/wal -name 0000* -mtime 7 -delete然后重启实操心得--dry-run参数是 Prometheus 的隐藏调试神器它不启动服务只校验配置文件语法和路径可访问性。Ubuntu 16.04 上必须用sudo -u prometheus切换用户执行否则权限检查不准确。5.2 数据采集异常类target 显示 DOWN 的 4 种真相Target 显示DOWN是最常被问的问题但原因千差万别网络层不通curl -v http://192.168.1.100:9100/metrics返回Connection timed out→ 检查iptables -L -n | grep 9100Ubuntu 16.04 默认开启 ufw需sudo ufw allow 9100TLS 证书问题如果 target 是 HTTPSPrometheus 默认不验证证书但若 target 强制要求 SNI需在scrape_configs中加tls_config: insecure_skip_verify: true超时设置过短Ubuntu 16.04 的老旧硬件上node_exporter响应可能达 8s而默认scrape_timeout: 10s不够需在 job 下加scrape_timeout: 15sDNS 解析失败targets里写server01.internal但/etc/resolv.conf没配 search domain → 改用 IP或在/etc/hosts里加静态映射。我处理过一个经典案例某客户targets页面所有节点都是DOWNcurl却能通。最后发现是prometheus.yml里scrape_configs的job_name写成了node_exporter末尾有空格YAML 解析时当成新 job但static_configs缩进错了导致配置加载失败所有 target 被忽略。用--dry-run一秒定位。5.3 性能与稳定性问题Ubuntu 16.04 上的资源瓶颈突破Prometheus 在 Ubuntu 16.04 上最常见的性能问题是 OOM Killdmesg | grep -i killed process显示prometheus被杀。这不是 Prometheus 内存泄漏而是 Ubuntu 16.04 的vm.swappiness60导致交换分区过度使用。解决方案分三步调低 swappiness临时sudo sysctl vm.swappiness10永久生效写入/etc/sysctl.confecho vm.swappiness10 | sudo tee -a /etc/sysctl.conf限制 Prometheus 内存关键在systemdservice 文件的[Service]段加两行MemoryLimit1G CPUQuota50%MemoryLimit是 cgroups v1 的硬限制Ubuntu 16.04 默认 cgroups v1超过 1G 直接 OOMCPUQuota50%防止 Prometheus 占满 CPU 导致 SSH 登录卡死。注意MemoryLimit单位必须是G或M不能写1024Msystemd 229 不识别。我试过1024Msystemctl daemon-reload直接报错退出。5.4 配置管理与升级如何在不中断监控的前提下平滑升级生产环境不能kill -9后重装。标准升级流程是# 1. 下载新版本并校验同前 wget https://github.com/prometheus/prometheus/releases/download/v2.48.0/prometheus-2.48.0.linux-amd64.tar.gz # ... 校验步骤 # 2. 解压到临时目录 tar -xvzf prometheus-2.48.0.linux-amd64.tar.gz cd prometheus-2.48.0.linux-amd64 # 3. 替换二进制原子操作 sudo mv /usr/local/bin/prometheus /usr/local/bin/prometheus-v2.47.0 sudo cp prometheus /usr/local/bin/ # 4. 验证新版本不重启服务 sudo -u prometheus /usr/local/bin/prometheus --version # 5. 优雅重启Prometheus 支持 SIGTERM 平滑退出 sudo systemctl kill -s SIGTERM prometheus # 等待 10 秒确认旧进程退出 sudo systemctl start prometheus实操心得SIGTERM会让 Prometheus 完成当前 WAL 写入、刷盘后退出数据零丢失SIGKILLkill -9会丢数据。我给客户写的 SOP 里强制要求所有重启操作必须用systemctl restart禁用kill命令。6. 后续扩展与生产就绪建议从单机监控到企业级可观测性6.1 必装插件node_exporter 是 Ubuntu 16.04 的“生命体征监护仪”Prometheus 本身只监控自己要监控 Ubuntu 16.04 的系统指标CPU、内存、磁盘 IO、网络连接数必须部署node_exporter。它比 Prometheus 更轻量专为 Linux 系统设计。安装只需三步# 下载同样要校验 wget https://github.com/prometheus/node_exporter/releases/download/v1.6.1/node_exporter-1.6.1.linux-amd64.tar.gz # 解压并安装 tar -xvzf node_exporter-1.6.1.linux-amd64.tar.gz sudo cp node_exporter-1.6.1.linux-amd64/node_exporter /usr/local/bin/ # 创建 service 文件/etc/systemd/system/node_exporter.service sudo tee /etc/systemd/system/node_exporter.service EOF [Unit] DescriptionNode Exporter Afternetwork.target [Service] Typesimple Usernode_exporter ExecStart/usr/local/bin/node_exporter --collector.systemd --collector.processes Restartalways [Install] WantedBymulti-user.target EOF sudo systemctl daemon-reload sudo systemctl enable node_exporter sudo systemctl start node_exporter关键点--collector.systemd启用 systemd 服务状态采集systemctl is-active xxx--collector.processes启用进程数监控。这两个 collector 在 Ubuntu 16.04 上默认关闭必须显式开启。6.2 告警闭环Alertmanager 部署的最小可行方案Prometheus 只负责“发现异常”告警发送必须交给Alertmanager。Ubuntu 16.04 上部署 Alertmanager 的最小配置# 下载并安装同 Prometheus 流程 wget https://github.com/prometheus/alertmanager/releases/download/v0.26.0/alertmanager-

相关新闻