90DaysOfDevOps Day 83：Grafana 数据可视化实战——基于 kube-prometheus 与 Prometheus Operator 部署监控面板-平芜编程栈

文档/教程

【免费下载链接】90DaysOfDevOps

This repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.

项目地址：https://gitcode.com/gh_mirrors/90/90DaysOfDevOps

点击查看免费下载

Grafana 是开源领域最常用的指标可视化工具，与 Prometheus 搭配几乎是云原生监控的事实标准。本文基于 90DaysOfDevOps 项目 Day 83 原文（本仓库同时提供越南语版本），完整梳理 Grafana 与 Kibana 的定位差异，并带你用kube-prometheus在 minikube 上从零搭建「Prometheus 采集 + Grafana 可视化 + Alertmanager 告警」的完整观测链路。学完本文，你将掌握 Grafana 的部署、数据源接入、面板创建、模板复用与告警转发全流程，并能在本地集群直接复现。

Grafana 与 Kibana：并非同一种工具

在可观测性（Observability）章节中，我们已经在 ELK / EFK 部分大量接触了 Kibana，但 Kibana 与 Grafana 并不相同，也并非完全竞争的关系：

Kibana 的核心能力是数据查询与（日志）分析：用户通过多种方式在 Elasticsearch 索引的数据中检索特定事件或字符串，用于根因分析（root cause analysis）与诊断，并基于这些查询使用图表、表格、地理地图等可视化能力；
Grafana 最初正是 Kibana 的一个 fork，其目标是补齐 Kibana 当时不提供的指标（metrics）监控支持；
两者最大的分野是Logging（日志）vs Monitoring（监控）：Grafana 面向系统 CPU、内存、磁盘、I/O 利用率等指标的分析与可视化，不支持全文检索；而 Kibana 运行在 Elasticsearch 之上，主要用于分析日志消息。

在实践中，Prometheus 与 Grafana 常常成对出现，但 Grafana 也可以对接 Elasticsearch、Graphite 等数据源。与 Kibana 一样，Grafana 部署简单且部署位置灵活，支持 Linux、macOS、Windows、Docker 以及从源码构建等多种方式。在本仓库中，Day 78 的 Prometheus 实战和 Day 80 的 ELK Stack 实战分别铺垫了监控与日志两条主线，Day 83 正是把两者统一到可视化层的关键一环。

为什么需要 Grafana：让指标可交互、可扩展

Prometheus 本身有 Web UI 可用于查询指标，但直接在 Prometheus 或任何指标工具中逐个翻查指标既笨重也不具备扩展性。Grafana 的价值在于：把 Prometheus 数据库采集、存储的指标变成可交互的可视化界面，并支持针对环境创建自定义图表（charts）、图形（graphs）与告警（alerts）。

仓库佐证：本仓库 Monitoring 目录同时收录了 EFK Stack 的 efk-stack.yaml 与 Elastic Stack 的 docker-compose.yaml，分别对应日志链路与搜索分析链路；而本文的 Grafana 则负责指标链路的可视化层，三者合起来即覆盖「指标 + 日志 + 可视化」的完整可观测性视图。

环境准备：启动 minikube 并克隆 kube-prometheus

本次演练使用本地minikube 集群。如果你没有跟随前面的章节操作，可以先用以下命令启动一个新集群：

minikube start

随后将prometheus-operator/kube-prometheus项目克隆到本地并进入目录——该项目提供了「Prometheus Operator + Prometheus + Grafana + Alertmanager」的一整套可运行清单（manifests）：

git clone https://github.com/prometheus-operator/kube-prometheus.git cd kube-prometheus

提示：kube-prometheus是一个由 Prometheus Operator 驱动的一站式部署集，它把通常需要手工拼装的监控组件（Prometheus 服务器、Grafana、Alertmanager、各种 exporter 与告警规则）以统一的 manifest 形式组织起来，是云原生场景下最常见的监控栈装配方式。

部署监控栈：创建命名空间与全部组件

克隆完成后，第一步是在 minikube 集群中创建监控所需的基础资源（命名空间、CRD 等）。这里分两步执行：

1. 创建基础资源（namespace 与 CRD）：

kubectl create -f manifests/setup

2. 部署 Demo 所需的全部监控组件：

kubectl create -f manifests/

正如原文演示所展示，第二条命令会在集群内一次性部署大量不同类型的资源（Prometheus、Grafana、Alertmanager、kube-state-metrics、node-exporter 等），这也是 Operator 模式「以少量 manifest 管理复杂组件」的直观体现。

部署后需要等待 Pod 初始化完成并进入运行状态，可用如下命令持续观察：

kubectl get pods -n monitoring -w

当一切就绪后，逐项核对部署结果：

# 检查所有 Pod 均处于 Running 且健康状态 kubectl get pods -n monitoring # 查看本次部署的服务（后续演示会用到） kubectl get svc -n monitoring # 查看 monitoring 命名空间下部署的所有资源 kubectl get all -n monitoring

访问 Grafana：端口转发与首次登录

新开一个终端，将 Grafana 服务转发到本地 3000 端口：

kubectl --namespace monitoring port-forward svc/grafana 3000

浏览器访问http://localhost:3000，会提示输入用户名和密码。kube-prometheus 默认凭据为：

Username: admin Password: admin

首次登录时会被要求设置一个新密码。登录后的首页会展示若干可探索的入口以及官方资源，请特别留意"Add your first data source"（添加第一个数据源）与"create your first dashboard"（创建第一个仪表盘）两个小部件，后面都会用到。

接入 Prometheus 数据源：数据源、访问模式与连通性测试

部署 kube-prometheus 时，集群内已经为 Grafana 预先注册了一个 Prometheus 数据源。但由于我们使用的是 minikube，Prometheus 服务并不能直接从浏览器访问，因此需要先把 Prometheus 也转发到本地：

kubectl --namespace monitoring port-forward svc/prometheus-k8s 9090

然后在 Grafana 首页点击"Add your first data source"小部件，选择Prometheus，填写：

URL：http://localhost:9090（即上面端口转发后的本地地址）
Access（访问模式）：下拉框选择Browser（浏览器）——这点很关键，它意味着 Grafana 后端不直接访问 Prometheus，而是由你的浏览器经端口转发链路去拉取数据，是本地演练场景下绕过网络隔离的常用做法

页面底部点击"Save & test"（保存并测试）。只要 Prometheus 的端口转发正常工作，就会看到连接成功的提示：

创建第一个 Dashboard：用 PromQL 展示节点 CPU 指标

回到 Grafana 首页，找到"Create your first dashboard"（创建第一个仪表盘），选择"Add a new panel"（添加新面板）。

默认情况下新面板从 Grafana 自带数据源抓取数据，需要把面板的数据源切换到我们刚创建的数据源（例如命名为Prometheus-1）。切换后在Metrics browser（指标浏览器）中可以看到来自 Prometheus、与 minikube 集群相关的长长指标列表——这正是 Prometheus 通过 kube-prometheus 的采集配置自动抓取到的指标全集。

演示中我们选择一条能反映系统资源的指标来验证集成是否打通：

cluster:node_cpu:ratio{}

该指标聚合了集群各节点的 CPU 使用率比例，返回集群中节点的相关细节，从而证明「Prometheus 采集 → Grafana 可视化」链路已经工作。

面板配置满意后，点击右上角Apply（应用），该图表即被添加到仪表盘。之后可以继续添加更多图表与其他可视化，逐步构建出自己需要的监控视图：

复用社区 Dashboard：不必从零造轮子

除了手工创建面板，Grafana 还提供了数以千计的预构建 Dashboard 模板，可以直接导入使用，避免重复造轮子：

在 Dashboard 搜索/导入界面搜索Kubernetes，即可看到一长串预构建的 Kubernetes 相关面板；
本演示选择Kubernetes API Server面板，将其数据源切换为我们新增的Prometheus-1数据源，即可立刻看到一批 API Server 相关的指标展示。

这种「模板 + 自有数据源」的组合方式，是 Grafana 在生产环境中快速落地的核心技巧：先用社区成熟面板覆盖常见观测目标，再按需微调或叠加自定义面板。

告警：通过 Alertmanager 转发到 Slack 等外部集成

kube-prometheus 默认部署了Alertmanager，可以利用它把告警发送到 Slack 或其他外部集成。为此需要将 Alertmanager 服务转发到本地：

kubectl --namespace monitoring port-forward svc/alertmanager-main 9093

然后浏览器访问http://localhost:9093即可查看 Alertmanager 的告警界面（Silences、Alerts、Status 等）。在真实场景中，只需在 Alertmanager 配置中声明 Slack、邮件等接收器（receiver）的路由规则，Prometheus 触发的告警就会自动送达对应渠道。

小结：可观测性章节收官与下一步

至此，可观测性（Observability）章节告一段落。本章涵盖面极广——从 Nagios 到 Prometheus 的监控（metrics），再到 ELK / EFK 的日志（logging），最后以 Grafana 完成指标的可视化与告警（alerting）。正如 Day 83 原文所强调的：无论指标、日志还是追踪（tracing），在环境因自动化而剧烈变化、规模不断扩张的背景下，掌握环境内正在发生什么，是运维与平台工程角色的核心功课。下一节将进入数据管理（Data Management），讨论 DevOps 原则如何适用于数据治理领域，见 Day 84。