Prometheus这套监控工具上手的时候很容易觉得别扭，和传统那种客户端主动推送数据到中心服务器的方案完全不一样。它采用拉取模式，由Prometheus主动去各个被监控节点抓取指标。目标机器只需要开放一个HTTP接口，以文本格式输出各项运行数据，Prometheus按设定周期拉取内容，存入自身的时序数据库。理解这套拉取逻辑，后续部署操作就容易理顺。
准备一台Linux主机部署Prometheus服务端，基础配置就可以跑起来；但如果监控节点数量多，或是打算长期保存指标数据，内存和磁盘资源就要预留充足。去官方站点下载对应系统的二进制包，解压后会得到prometheus可执行程序以及prometheus.yml配置文件。这个yml文件是整套服务的核心，global段用来设置全局抓取间隔与规则评估周期，scrape_configs填写待采集的目标地址，alerting配置告警接收对象，rule_files指向告警规则文件。初次部署不用一次性补齐全部配置，默认自带抓取服务端自身的任务，优先保证服务正常启动。
直接在前台执行 ./prometheus --config.file=prometheus.yml，浏览器访问服务器9090端口，出现查询页面，就代表服务端启动成功。此时它只会采集本机数据，页面里能查到所有prometheus_前缀指标。下一步接入外部服务器，Prometheus本身没办法直接读取目标主机CPU、内存信息，每台被监控节点都需要部署exporter。node_exporter是最普遍的选择，专门采集主机层面指标，CPU、内存、磁盘、网络、文件系统、系统负载都包含在内。解压运行程序后监听9100端口，访问http://目标IP:9100/metrics，页面会输出大量node_开头指标。访问失败就优先检查防火墙，确认9100端口放行。
回到Prometheus服务端修改prometheus.yml，在scrape_configs区块新增任务。job_name设置为node，static_configs内部填写targets列表，把所有部署node_exporter的机器IP和端口录入。保存文件后重启Prometheus；启动时添加--web.enable-lifecycle参数，也能直接用curl发送POST请求到/-/reload实现配置热加载。打开9090页面，进入Status下的Targets页面，目标状态显示UP代表采集正常。状态为DOWN时，悬停查看报错信息，大多是网络不通或者端口拦截。
指标采集完成，就可以查询数据。查询语法是PromQL，新手不用一次性吃透全部用法，掌握少量常用表达式就能应付基础场景。读取主机CPU使用率：100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)。内存使用率计算方式为node_memory_MemAvailable_bytes除以node_memory_MemTotal_bytes再乘以100。磁盘剩余空间查看node_filesystem_avail_bytes，网络流量使用rate(node_network_receive_bytes_total[5m])。表达式输入查询框，切换Graph页面就能查看趋势曲线。刚部署时曲线长度很短，因为采集的数据量不足，等待数小时再观察会更完整。
单纯查看曲线不够，故障发生后还需要主动告警。Prometheus告警分为两层，先在Prometheus内部配置告警规则判定触发条件；条件满足之后推送告警信息给Alertmanager，由Alertmanager完成告警分组、抑制以及消息分发。规则一般单独放在alert.rules.yml，在prometheus.yml的rule_files参数引用这个文件。一条基础规则示例，告警名称InstanceDown，表达式up == 0，for设为1m，代表节点持续失联一分钟才触发告警。labels字段标记严重等级，annotations填写告警摘要和详细描述。Alertmanager需要单独下载安装，配置文件定义route和receivers，支持邮件、企业微信、Slack等渠道。新手可以先用邮件，填写正确SMTP信息即可。
自带的查询面板功能简单，想要更美观直观的可视化图表，可以部署Grafana。Grafana添加Prometheus作为数据源，导入现成仪表板模板，Node Exporter Full模板ID为1860，各类主机指标会自动生成图表。Grafana可以和Prometheus部署在同一台主机，也能分开部署。默认监听3000端口，首次登录用户名和密码都是admin，登录之后务必修改密码。
部署完成后还有几个容易忽略的关键点。服务器时间同步对Prometheus很重要，多台机器时间偏差过大，会造成时序数据错乱，部署chrony或者ntp服务做时间校准。数据保存周期默认15天，可以在启动参数通过--storage.tsdb.retention.time调整到30天或者更长，磁盘容量需要同步扩容。安全层面，9090、9100、9093、3000这类端口不要直接暴露公网，至少搭配反向代理和身份认证。如果监控节点规模持续变大，手动在static_configs填写地址效率低，可以改用文件服务发现，对接Consul、Kubernetes等动态发现组件。不过这属于后期优化，先把核心服务器监控起来，确认指标曲线、告警通知正常工作，再逐步扩容。