1. 内容整体设计与思路拆解1.1 为什么是Grafana而不是别的监控工具干监控这块的人多少都跟自研报表、邮件告警、半夜爬起来看日志的破事打过交道。早期团队规模小的时候一台服务器挂了大家靠人工盯等到容器化、微服务一上来几十个服务同时跑靠肉眼根本盯不过来。这时候Grafana的价值就非常直接它把不同系统的数据集中到一块用图表、仪表盘和告警把状态变化呈现出来能让我们在指标异常的第一时间知道“哪里出了问题严重到什么程度”。Grafana本身不负责采集数据它是一个可视化与告警平台。它通过数据源插件去对接Prometheus、Loki、InfluxDB、MySQL、Elasticsearch等后端然后把这些数据统一渲染成图表。很多人把它跟Prometheus搞混其实Prometheus负责拉取和存储监控指标Grafana负责把指标“画”出来并触发告警两者配合是当前云原生监控领域最常见的一套组合。我在实际项目中为什么一直推荐Grafana而不是直接用Prometheus自带的表达式浏览器最核心的原因是效率。Prometheus自带的UI只能看单条表达式的结果没法把CPU、内存、请求量、错误率放在同一个页面上对比。而Grafana的仪表盘可以自由布局把几十个指标放在一个View里业务同学和研发同学打开一个链接就能看到全局状态。这对故障排查和跨团队协作帮助非常大。1.2 Grafana的核心组件与工作逻辑在用Grafana之前先要理解它的几个核心概念整理下来其实就是五个词数据源、仪表盘、面板、变量、告警。数据源告诉Grafana去哪里读数据比如Prometheus地址是http://localhost:9090Loki地址是http://localhost:3100。数据源可以配置多个同一个仪表盘里可以混用不同数据源。仪表盘一个仪表盘就是一整页可视化布局由多个面板组成对应一个监控主题比如“订单服务监控”、“数据库性能总览”。面板仪表盘里的每个图表或数字卡片都是一个面板常见的面板类型有时间序列图、柱状图、仪表盘图、表格、日志面板等。变量在仪表盘顶部定义下拉框比如环境、实例IP、服务名面板里的查询可以直接引用变量实现“一个仪表盘看所有环境”的效果。告警针对查询结果设定阈值满足条件后通过钉钉、邮件、企业微信或Webhook通知到人。Grafana的整体工作逻辑是用户先配置数据源然后建立仪表盘在仪表盘的面板里写查询语句最后把面板的查询结果与告警规则挂钩。整个链路非常清晰只要理解了这个流程后面再怎么扩展新数据源、新面板都是同一套思路。1.3 关于标题“快速掌握Grafana常用方法”的核心需求拆解这个标题背后其实是三类人最常见的诉求。第一类是刚开始接触监控的运维小白只想知道“怎么把Grafana跑起来接入Prometheus显示几个系统指标”第二类是开发同学想把Spring Boot应用的自定义指标暴露出来在Grafana里做成业务大盘最好有现成的模板ID直接用第三类是已经用了一段时间Grafana但发现日志查询、报告导出、告警配置这些功能用得还不顺手的进阶用户。所以围绕这三类诉求我把文章的实操路径拆成四条主线部署线Prometheus Grafana从零安装覆盖二进制包安装和Docker Compose两种方式。数据接入线从Prometheus采集Node指标到Spring Boot应用暴露Micrometer指标再到Grafana数据源接入。日志线Alloy采集日志送往LokiLoki存储到对象存储桶最终在Grafana里查询展示这就是近期很多人关注的轻量级Loki日志系统方案。使用线模板ID的导入方式、PDF报告生成、告警通道配置、常见问题排查。下面每一章都按这条主线往下拆尽量做到每一步都有具体命令和参数让读者照着敲就能跑起来。2. Prometheus与Grafana部署从选型到落地2.1 二进部署与Docker Compose部署怎么选安装Grafana和Prometheus网上教程一大堆但很多教程默认你只用其中一种方式实际项目里情况要复杂得多。我通常按使用场景区分生产环境、需要持久化配置和网络隔离的推荐二进制包配合systemd管理启动参数明确升级方便。本地开发、测试环境、临时演示的推荐Docker Compose一把梭几条命令就能把Prometheus、Grafana、Node Exporter全拉起来。如果你只是想快速跑通一个Demo我用Docker Compose的方式演示一次。新建一个目录比如monitor-stack创建docker-compose.yml文件内容如下version: 3.8 services: prometheus: image: prom/prometheus:latest container_name: prometheus ports: - 9090:9090 volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - prometheus_data:/prometheus command: - --config.file/etc/prometheus/prometheus.yml - --storage.tsdb.retention.time15d grafana: image: grafana/grafana:latest container_name: grafana ports: - 3000:3000 environment: - GF_SECURITY_ADMIN_PASSWORDadmin123 volumes: - grafana_data:/var/lib/grafana node-exporter: image: prom/node-exporter:latest container_name: node-exporter ports: - 9100:9100 volumes: prometheus_data: grafana_data:在同一个目录下创建prometheus.yml配置文件global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090] - job_name: node static_configs: - targets: [node-exporter:9100]然后在monitor-stack目录下执行docker compose up -d等容器全部启动后Prometheus的界面是localhost:9090Grafana的界面是localhost:3000默认账号密码是admin/admin第一次登录会要求修改密码我示例里通过环境变量直接把默认密码改成了admin123。这里有个细节值得注意prometheus.yml里的node-exporter地址我写的是容器名而不是localhost。因为Compose网络里容器之间要依靠服务名互相访问如果写localhostPrometheus容器访问的是它自己的9100端口肯定连不上Node Exporter。这是新手最容易踩的坑之一。2.2 Prometheus架构原理用7张图讲明白采集、存储、查询很多人问Prometheus的架构到底是什么样的网上有一组流传很广的架构图核心其实可以压缩成几个关键环节。第一个环节是指标暴露。被监控的服务通过HTTP接口暴露/metrics端点Prometheus用一个叫Exporter的组件去拉取这些指标。Node Exporter暴露的是主机层面的指标比如CPU、内存、磁盘、网络MySQL Exporter暴露的是数据库指标JMX Exporter暴露的是JVM指标。第二个环节是抓取。Prometheus按配置的scrape_interval周期性地向目标发送HTTP请求拉取文本格式的指标数据。默认抓取间隔是15秒如果业务指标变化很快可以调成5秒但会带来存储压力的上升。第三个环节是存储。Prometheus把抓到的时序数据写入本地TSDB按时间维度组织数据会做压缩和采样。通过--storage.tsdb.retention.time参数控制保留时长我示例里配的15天也就是最多保存15天的历史数据超过的部分会被自动清理。第四个环节是查询。PromQL是Prometheus的查询语言Grafana里的每个面板本质上就是在执行一段PromQL表达式。比如查询CPU使用率100 - (avg by (instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100)这段表达式的意思是统计最近5分钟内CPU空闲时间的增长率求平均后乘以100得到空闲率再用100减去它得到使用率。第五个环节是告警。Prometheus根据alerting rules周期性地评估表达式如果满足触发条件就推送给Alertmanager再由Alertmanager分发到各个通知渠道。Grafana 8.0之后自己也内置了统一的告警引擎可以直接在Grafana侧配置告警规则不需要依赖Alertmanager。第六个环节是联邦与远程存储。当监控规模大到单机TSDB扛不住时可以用联邦集群把多个Prometheus的查询结果汇总到上层Prometheus或者接入Thanos、VictoriaMetrics做远程存储。第七个环节是可视化。这就是Grafana发挥价值的地方它通过Prometheus数据源接口发起PromQL查询把结果渲染成图表。想真正掌握这套架构不需要死记每一层而是要搞清楚一点数据从“被采集”到“被查询”到“被告警”中间经过了哪些环节每个环节的延迟和失败可能导致什么现象。比如抓取间隔长图表就会出现阶梯状抓取目标挂了图表会出现断点存储保留时间短历史查询会返回无数据。理解了这层因果关系排查问题就有的放矢。2.3 Grafana数据源接入与基础配置Grafana启动后第一步是登录第二步是添加数据源。添加数据源的操作路径是左侧菜单进入Connections选择Data sources点击Add data source选择Prometheus填写URL为http://localhost:9090如果Grafana跑在Docker里要写http://prometheus:9090点击Save test页面提示Success即表示连接成功。这里有一个配置上的细节如果Grafana和Prometheus在同一个宿主机上但Grafana跑在容器里那么URL不要写localhost因为容器内的localhost指向容器自身。正确做法是在Docker Compose里配置DNS或者直接用宿主机内网IP。早期我在这上面浪费过不少时间页面一直报“Bad Gateway”后来才发现是localhost的问题。数据源添加完成后建议先到Explore页面验证一下查询。进入左侧菜单的Explore数据源选择Prometheus在查询框输入up点击Run query如果能看到一系列up{jobnode-exporter}的结果且值为1说明Prometheus到Node Exporter的数据链路已经通了。看到结果再去做仪表盘会顺畅很多。3. 仪表盘模板、Spring Boot监控与告警实战3.1 常用监控模板ID从哪找怎么用Grafana官方有一个仪表盘市场叫Grafana Dashboards网址是grafana.com/grafana/dashboards上面有大量社区贡献的模板。每个模板都有一个唯一的ID比如Node Exporter Full模板的ID是1860Spring Boot模板的ID是19004。用模板的步骤在Grafana左侧菜单进入Dashboards点击New选择Import。在Import页面输入模板ID比如1860点击Load。系统会识别出模板依赖的数据源让你选择一个已有的数据源这里选择刚才配置好的Prometheus。点击Import仪表盘就创建好了。导入之后要注意两件事第一是版本兼容问题老模板可能在Grafana 9以上版本出现面板渲染异常需要手动调整面板类型第二是数据源变量问题有些模板默认数据源变量叫DS_PROMETHEUS导入时要确保它匹配到你实际配置的数据源名称否则所有图表都会显示No data。如果是新项目我建议先导入官方模板看效果再基于模板去修改。自己从零开始创建面板当然也可以但模板能极大缩短搭建时间而且社区模板对PromQL表达式的写法通常比新手自己写的更规范。3.2 Spring Boot 3.0应用接入监控从Actuator到GrafanaSpring Boot应用要接入Grafana核心是两步暴露指标然后把指标让Prometheus抓走。第一步在pom.xml里引入依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-actuator/artifactId /dependency dependency groupIdio.micrometer/groupId artifactIdmicrometer-registry-prometheus/artifactId /dependencySpring Boot 3.0用的是Micrometer 1.xmicrometer-registry-prometheus会暴露一个/actuator/prometheus端点Prometheus从这个端点拉取JVM、HTTP请求、线程池等指标。第二步在application.yml里配置端点暴露management: endpoints: web: exposure: include: health,info,prometheus,metrics metrics: tags: application: order-service这里给所有指标加了一个application标签值叫order-service。这个标签非常有用当多个Spring Boot服务同时接入时可以用它区分不同服务的指标。第三步Prometheus配置里增加一个抓取任务scrape_configs: - job_name: spring-boot-app metrics_path: /actuator/prometheus static_configs: - targets: [192.168.1.100:8080]注意这里target是应用服务器的IP和端口。如果应用部署在Kubernetes里还需要用到服务发现那是另外一个复杂的话题这里先不展开。第四步在Grafana里导入Spring Boot Dashboard模板模板ID是19004数据源选择Prometheus。导入后你就能看到JVM堆内存、非堆内存、GC次数、HTTP请求QPS、线程池活跃数等面板。我在实际项目中还喜欢自定义几个业务指标。比如在代码里加一个计数器统计下单接口的调用次数RestController public class OrderController { private final Counter orderCounter; public OrderController(MeterRegistry registry) { this.orderCounter Counter.builder(order.create.total) .description(Total order created) .register(registry); } PostMapping(/order) public String createOrder() { orderCounter.increment(); return ok; } }这样Grafana里可以直接用rate(order_create_total[5m])画出每秒下单量对业务监控很有价值。技术指标只能告诉我们服务“活着”业务指标才能告诉我们业务“在跑”。3.3 告警规则编写与通知渠道配置Grafana的告警配置入口在新版里是左侧菜单的Alerting点进去后可以创建告警规则。一个完整的告警规则包含这几个要素查询条件从哪个数据源执行什么PromQL表达式。评估频率每隔多久检查一次。触发条件表达式的结果满足什么条件时告警。静默时间同一告警在指定时间内不重复发送。通知渠道告警触发后推送到哪里。以一个最简单的磁盘使用率告警为例查询表达式100 - (node_filesystem_avail_bytes{fstype!~tmpfs|overlay,mountpoint/} / node_filesystem_size_bytes{fstype!~tmpfs|overlay,mountpoint/} * 100)这个表达式算的是根分区使用率。在告警规则里设置阈值比如“当值大于85时触发”评估间隔设1分钟持续5分钟也就是至少连续5次评估都超阈值才告警这样可以避免瞬时抖动造成的误报。通知渠道配置在Alerting的Contact points里。添加一个企业微信或钉钉的Webhook地址格式大致是https://oapi.dingtalk.com/robot/send?access_tokenxxxxxxxx把Webhook地址填进去保存后回到告警规则里关联这个Contact point。告警消息里可以通过模板变量把当前值、主机地址、告警时间带出来让收到通知的人不用登录Grafana就能知道基本上下文。有一个常见的坑告警规则里的for参数设置太短导致告警频繁触发和恢复通知群被刷屏。我建议生产环境至少设置5分钟评估频率设1到2分钟。告警不是越快越好而是要准。4. 轻量级Loki日志系统Alloy到Loki到对象存储4.1 为什么用Loki而不是ELKGrafana Stack除了监控指标还包含日志系统。前面提到热搜里有“alloy → loki → 对象存储桶 → grafana部署”这其实就是一套完整的轻量级日志方案。很多团队一上来就想上ELK结果三台Elasticsearch节点的资源占用就能把小项目组吃穷。如果日志量没那么大其实Loki是更合适的选择。Loki的设计理念是“只索引日志的元数据标签不索引日志全文”所以它把日志内容压缩后存储索引很小占用的磁盘和内存远低于Elasticsearch。查询的时候再通过标签和过滤表达式把日志捞出来。对中小团队来说这个优点非常实际一套Loki Alloy Grafana的部署内存占用可能在几百兆左右而同样的场景用ELK至少需要4到8GB内存起步。4.2 二进制Alloy部署与日志采集配置Alloy是Grafana开源的采集器可以把他理解为前身Promtail的更通用继承者。它既能采集日志也能采集指标和追踪但本文重点说日志。先下载Alloy二进制包官方GitHub Release里有各平台的压缩包。以Linux amd64为例wget https://github.com/grafana/alloy/releases/download/v1.2.0/alloy-linux-amd64.zip unzip alloy-linux-amd64.zip mv alloy-linux-amd64 /usr/local/bin/alloy chmod x /usr/local/bin/alloyAlloy的配置采用一个叫River的声明式语言跟HCL有点像。创建一个config.alloy文件logging { level info } loki.source.file app_logs { targets [{__path__ /var/log/myapp/app.log}] forward_to [loki.write.default.receiver] } loki.write default { endpoint { url http://localhost:3100/loki/api/v1/push } }这段配置的含义是Alloy去监听/var/log/myapp/app.log这个文件把新增的日志内容推送到Loki的HTTP接口。这里有一个关键点如果要为日志打上标签可以在loki.source.file里加labels参数loki.source.file app_logs { targets [{__path__ /var/log/myapp/app.log}] forward_to [loki.write.default.receiver] labels { service order-service, env prod } }启动Alloyalloy run config.alloy启动完成后Alloy默认监听端口是12345可以打开http://localhost:12345查看Alloy的UI界面里面能看到当前配置的采集任务和运行状态。4.3 Loki服务端部署与对象存储桶集成Loki本身的部署最简单的方案是下载二进制单文件。到Loki的GitHub Release页面下载与系统匹配的压缩包解压后得到一个loki二进制文件和一个本地配置示例loki-local-config.yaml。我这里说一个接入对象存储桶的配置方式。如果日志量比较大希望把日志长期保存在对象存储里而不是本地磁盘那就在Loki配置里把storage_config指向对象存储。以兼容S3协议的对象存储为例loki配置的片段大致是这样schema_config: configs: - from: 2024-01-01 store: tsdb object_store: s3 schema: v13 index: prefix: loki_index_ period: 24h storage_config: aws: s3: http://minio:9000 bucketnames: loki-data access_key_id: minioadmin secret_access_key: minioadmin insecure: true filesystem: directory: /loki/index注意这里把object_store设为s3同时指定了S3兼容端点我示例里是MinIO。索引文件仍然写在本地文件系统日志块数据写到对象存储桶。如果不想用对象存储可以直接把object_store留空让Loki全部写到本地磁盘storage_config: filesystem: directory: /loki/chunks但本地磁盘方案要注意容量规划。Loki默认的日志保留时间可以配置limits_config: retention_period: 168h retain_period: 240hretention_period控制数据保留时长比如168小时就是7天。超过时间的数据Loki后台会自动清理。启动Loki./loki -config.fileloki-local-config.yaml默认监听3100端口可以用curl http://localhost:3100/ready检查健康状态返回ready说明启动成功。4.4 在Grafana里查询日志日志链路通到Grafana之后使用方式很直观。在数据源里添加Loki类型URL填http://localhost:3100保存测试。进入Explore页面数据源选择Loki在查询框里可以选标签过滤比如{serviceorder-service}这个语句会返回所有service标签为order-service的日志。如果日志量很大可以加上关键词过滤{serviceorder-service} | ERROR这条语句过滤出含有ERROR关键字的日志。LogQL的语法很灵活|是包含!~是正则不匹配| json可以解析JSON格式的日志字段。我在日常排障时最常用的操作是先按服务名过滤再加上时间范围选择然后input关键字。比如查订单服务的超时日志就是{serviceorder-service} | timeout。Loki查询速度快跟以前登录服务器grep日志文件相比效率提升非常明显。5. 监控报告自动生成与日常实用技巧5.1 如何把Grafana面板导出为PDF监控报告有些管理场景需要定期把监控数据生成报告比如每周发一封包含系统资源趋势的邮件。Grafana本身提供了一个基于png的渲染报告功能但配置稍微有点绕。最简单的方式是通过Grafana Image Renderer插件。在Grafana的Docker部署里可以在docker-compose.yml里加上渲染器服务grafana-renderer: image: grafana/grafana-image-renderer:latest ports: - 8081:8081然后在Grafana的环境变量里声明渲染器地址environment: - GF_RENDERING_SERVER_URLhttp://grafana-renderer:8081/render - GF_RENDERING_CALLBACK_URLhttp://grafana:3000/重启Grafana后在仪表盘页面右上角就有Share的入口选择PDF或者PNG就可以导出当前仪表盘的内容。对于定时发送报告的场景Grafana的Reporting功能可以直接配置定时任务。在左侧菜单进入Reporting新建报告选择要导出的仪表盘设置发送频率每天、每周、每月填写收件人邮箱系统会按计划渲染并发送报告。注意免费版这个功能可能受限如果你用的是开源版可以尝试第三方工具比如Grafana Report Pro或者用脚本定时调用Grafana的HTTP API搭配无头浏览器截图再把图片拼成PDF。后者适合有一定开发能力的团队。5.2 常用快捷操作与调试技巧日常使用Grafana有几个操作能让效率翻倍。第一个是模板变量联动。在仪表盘设置里定义变量instance查询语句为label_values(node_uname_info, instance)这样顶部会出现一个下拉框选择不同的IP就能切换查看不同主机的数据。多级联动可以做到选择某个服务后自动过滤出该服务所在的实例。第二个是面板图例的简化。如果一个图表里图例太多可以在面板的Legend设置里勾选“只显示最值”或者“隐藏值为0的图例”这样图表看起来干净很多信息层次清晰。第三个是Explore与Dashboard的互相跳转。在Explore里调试好一条PromQL或LogQL后可以直接点击Add to dashboard把查询加到已有仪表盘不用回到仪表盘编辑页面重新写表达式。第四个是用Annotation标记事件。在仪表盘面板设置里可以添加Annotation比如把每次发布版本的开始时间和结束时间画到时间序列图上配合指标曲线观察发布前后的变化能快速判断“是不是发布导致的性能抖动”。第五个是善用Grafana的快捷键。按d可以快速跳转到仪表盘列表按e进入编辑模式按v查看当前仪表盘的JSON模型。对于想用代码管理仪表盘配置的团队仪表盘JSON就是基础设施即代码的基础。6. 常见问题与排查技巧实录6.1 数据源连接失败现象Grafana页面提示Bad Gateway或者Connection refused。排查步骤确认数据源地址能否从Grafana所在主机访问。如果Grafana在Docker里检查是否使用了容器名而非localhost检查Docker网络是否正常。测试目标端口是否监听。在宿主机执行curl http://localhost:9090/-/healthy如果Prometheus健康检查返回OK说明Prometheus本身没问题。检查Grafana是否配置了代理。如果公司网络环境有HTTP代理Grafana请求外网数据源可能被代理拦截需要在Grafana配置里排除相关地址。6.2 仪表盘图表显示No data这种现象最常见的原因是标签匹配条件不对。导入的模板默认按某个标签过滤比如jobnode但你实际配置的job_name是node-exporter那肯定查不到数据。解决方法是到面板编辑页面查看查询表达式里用的标签值然后到Explore里用同样表达式验证。另外还有一个容易被忽略的点Prometheus的抓取间隔和数据保留策略。如果数据保留时间是15天你选了最近30天的时间范围超过保留期的部分自然就是No data而不是数据源出了问题。调整时间范围或者增大保留时间即可。6.3 告警风暴告警风暴通常有两个原因。一是阈值设置不合理或者评估周期过短导致系统在正常波动时反复触发和恢复。二是没有配置静默和分组两条相关告警各自发一遍通知渠道被刷爆。建议做法给告警规则设置for参数比如持续5分钟再触发。使用Grafana告警的分组功能把同主机、同服务的告警聚合为一条通知。配置静默时间窗口比如维护窗口期内不发送告警。为通知消息加上当前值和阈值方便接收人快速判断严重程度。6.4 Loki日志查询慢或者日志不显示日志采集链路里常见的坑有三个Alloy读文件的路径不对或者文件被logrotate改名后Alloy没跟上新文件。解决方法是检查Alloy配置里的__path__并确认Alloy UI里的tailer状态必要时重启Alloy。Loki的超时配置过小日志量大的查询容易超时。在Loki配置里可以调大query_timeout比如30秒。Grafana时间范围选得太小Loki默认只查询所选时间范围的数据如果日志时间戳和系统时间偏差大会查不到。检查日志里的时间戳字段是否正常。6.5 几个我踩过的坑第一个是权限问题。用二进制方式部署Grafana时默认admin账号权限非常大建议创建独立的只读账号给普通研发同事查看避免误操作修改仪表盘。第二个是面板版本管理。多人同时编辑一个仪表盘容易互相覆盖建议在Grafana配置里开启版本历史或者用Provisioning方式把仪表盘JSON放到Git仓库管理。第三个是资源规划。Grafana和Loki虽然轻量但如果面板数量多、查询频繁Grafana的内存也会涨得很快。生产环境建议给Grafana至少2GB内存Loki至少1GB内存Prometheus本地存储的磁盘IO性能直接影响查询速度尽量用SSD。7. 最后再分享一点我的个人经验从最早用Grafana只是“看几个图”到现在扛起指标监控、日志检索、告警通知三条线我最大的感受是工具本身不难难的是把链路理清楚。很多人一上来就急着搭面板结果数据源还没通、标签对不上折腾一整天也看不到数据。正确的顺序永远是先确认数据存在再去做展示。Prometheus的Targets页面、Grafana的Explore页面都是验证数据链路的起点把这两步走稳了后面全是顺水推舟。另外想提醒的是Grafana的生态里模板很丰富但模板不能直接用完就扔。导入模板后一定要结合自己的业务调整PromQL里涉及的时间范围、阈值、标签否则就是一个“看起来很专业实际跟业务脱节”的空壳仪表盘。比如模板默认监控的请求量口径是20秒窗口你的业务高峰期是分钟级波动那就需要手动把[5m]改成[1m]。这个系列后续我还会补充Alloy采集Kubernetes容器日志的细节、Prometheus远程存储的选型以及Grafana告警与自动化运维平台的联动方式。先用好今天这套基础链路等你的监控数据量慢慢起来再逐步去碰更复杂的架构会比较稳妥。