文档/教程【免费下载链接】90DaysOfDevOpsThis 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 搭配用于监控系统 CPU、内存、磁盘与 I/O 等指标数据。本文以 90DaysOfDevOps 第 83 天文档2022/Days/day83.md为主线在 minikube 集群上完整演示如何通过 kube-prometheus 一键部署 Prometheus Operator Grafana并手把手配置 Prometheus 数据源、创建自定义面板与导入社区 Dashboard最终打通 Alertmanager 告警通道帮助读者掌握一套可直接复用的云原生监控可视化实战方案。Grafana 与 Kibana指标可视化与日志分析的分野在本系列可观测性章节中我们已经大量接触了 Kibana也花了不少篇幅讲解监控Nagios、Prometheus与日志ELK/EFK两条技术线。但值得强调的是Grafana 与 Kibana 并不相同也并非完全互相竞争它们解决的是两类不同的问题。Kibana 的核心能力是数据查询与分析。它运行在 Elasticsearch 之上通过多种方式在已索引的数据中搜索特定事件或字符串用于根因分析和故障诊断基于这些查询用户可以利用 Kibana 的可视化功能通过图表、表格、地理地图等多种形式呈现数据。Grafana 最初是 Kibana 的一个分支其目标是补足 Kibana 当时并不提供的指标metrics监控支持。因此 Grafana 的定位是分析与可视化指标类数据——如系统 CPU、内存、磁盘和 I/O 利用率——它不支持对日志做全文检索。在生产实践中我们最常见的组合是 Prometheus Grafana也常会看到 Grafana 与 Elasticsearch、Graphite 搭配出现。两者的关键差异一句话概括就是Logging vs Monitoring。本系列此前的路径也正是如此展开的先用 Nagios 与 Prometheus 覆盖监控再通过 ELK Stack 与 EFK Stack 覆盖日志。与 Kibana 一样Grafana 的部署也相当简单且部署位置自由支持 Linux、Mac、Windows、Docker甚至从源码构建。它横跨虚拟化、云与云原生三大平台是运维与开发人员都应掌握的核心工具。为什么需要 GrafanaPrometheus 数据可视化Prometheus 已经在本系列中单独介绍过但既然这两个工具总是成对出现我们有必要搭建一个环境实际看看收集到的指标能以怎样的形态展示出来。监控环境的重要性不言而喻但如果只盯着 Prometheus 自带的 Web UI 逐条翻看指标既繁琐也无法规模化。Grafana 的价值正是把 Prometheus 数据库中采集和存储的指标转化为可交互的可视化界面并基于这些可视化能力创建自定义图表、图形与告警规则。本实战将在 minikube 集群上完成依赖kube-prometheus项目提供的整套清单manifests。kube-promopleus 中的组件以多个资源清单组合的形式存在涵盖 Prometheus Operator、Prometheus、Alertmanager、Grafana 以及对应的 ServiceMonitor 等一次kubectl create即可整体落盘。部署准备拉取 kube-prometheus 清单首先将 kube-prometheus 项目克隆到本地并进入目录git clone https://github.com/prometheus-operator/kube-prometheus.git cd kube-prometheus如果你没有跟随本系列前面章节准备集群可以先用minikube start启动一个新集群minikube start创建命名空间与部署全套监控组件kube-prometheus 将资源拆分为setup与主清单两部分需要按顺序创建。先部署命名空间与 CRDCustomResourceDefinition等基础设施kubectl create -f manifests/setup接着部署演示所需的全套组件。这一步会创建大量资源包括 Prometheus Operator、Prometheus、Alertmanager、Grafana、kube-state-metrics 以及各类 ServiceMonitor 与规则kubectl create -f manifests/随后需要等待所有 Pod 进入 Running 状态。使用-w参数持续监听变化kubectl get pods -n monitoring -w全部就绪后确认所有 Pod 均处于 Running 且健康状态kubectl get pods -n monitoring部署过程中还会创建若干 Service供后续演示使用可通过以下命令查看kubectl get svc -n monitoring最后查看新创建的 monitoring 命名空间下所有资源验证整体部署完整性kubectl get all -n monitoring从源码结构看kube-prometheus 的这一套清单在设计上刻意将监控组件收拢到独立的monitoring命名空间使其与业务负载隔离这也是生产环境中部署 Prometheus Operator 生态的常见惯例。访问 Grafana端口转发与首次登录打开一个新的终端将 Grafana 服务转发到本地 3000 端口kubectl --namespace monitoring port-forward svc/grafana 3000在浏览器中访问http://localhost:3000会提示输入用户名和密码。默认凭据如下Username: admin Password: admin首次登录时系统会强制要求设置新密码。进入首页后可以看到若干可探索的入口以及帮助快速上手的资源。请留意首页上的Add your first data source和create your first dashboard两个小组件后续步骤会用到它们。配置 Prometheus 数据源你会发现 Grafana 的数据源列表中已经存在一个 Prometheus 数据源。但由于我们使用的是 minikubePrometheus 服务并没有直接暴露在宿主机网络上因此需要再开一个终端将 Prometheus 服务同样转发到本地kubectl --namespace monitoring port-forward svc/prometheus-k8s 9090回到 Grafana 首页进入Add your first data source小组件选择Prometheus作为数据源类型。在数据源配置页中填写地址http://localhost:9090并将访问方式Access下拉框切换为Browser浏览器直接访问因为端口转发只绑定在本地 localhost 上由浏览器直连才能访问到。滚动到页面底部点击Save test。只要 Prometheus 的端口转发工作正常就会看到测试通过的提示。创建第一个 Dashboard用 Metrics Browser 查询指标回到 Grafana 首页找到Create your first dashboard入口选择Add a new panel。新面板默认会使用 Grafana 自身的数据源我们需要将其切换为我们刚刚创建的Prometheus-1数据源点击面板编辑页上方的数据源下拉框并选择 Prometheus-1。切换完成后点击Metrics browser会列出 Prometheus 从 minikube 集群采集到的一长串指标覆盖节点、容器、API Server 等各类维度。这里演示选择一个与系统资源相关的指标cluster:node_cpu:ratio{}。该指标反映集群节点的 CPU 使用比例可以用来验证 Prometheus 与 Grafana 之间的数据链路是否真正打通。对可视化效果满意后点击右上角的Apply按钮即可将这张图添加到 Dashboard。之后可以按需继续添加更多图表组合出自己需要的监控视图。导入社区 Dashboard无需从零造轮子除了从零创建面板Grafana 还提供了成千上万个社区预置 Dashboard我们完全不必重复造轮子。在搜索框中输入Kubernetes会看到大量开箱即用的预构建 Dashboard 可供挑选。本演示选择了Kubernetes API ServerDashboard并将其数据源切换为我们新添加的 Prometheus-1即可看到下图所示的各项指标展示。扩展告警接入 Alertmanager除了可视化本套部署还包含了 Alertmanager。可以利用它把告警发送到 Slack 或其他集成渠道。操作方式同样是端口转发然后通过 Web UI 配置kubectl --namespace monitoring port-forward svc/alertmanager-main 9093浏览器访问http://localhost:9093在 Alertmanager 的 Web UI 中即可查看告警分组、静默规则以及配置的接收端Receiver状态。结合 Grafana 面板中创建的告警规则即可形成指标采集 → 可视化 → 阈值告警 → 渠道通知的完整闭环。小结至此本系列可观测性章节告一段落。回看这一路这个主题的覆盖面相当广——从 Nagios、Prometheus 到 ELK/EFK再到今天的 Grafana 与 Alertmanager——但无论指标metrics、日志logging还是链路追踪tracing我们都需要对未来庞大且时刻变化的分布式环境有清晰的洞察尤其是在前面章节所讲的大量自动化能力加持下环境的变动会更加剧烈可观测性的价值也会更加凸显。接下来我们将进入数据管理Data Management部分探讨 DevOps 原则如何同样适用于数据管理领域。继续阅读 Day 84。相关资源与延伸阅读本系列可观测性章节中的相关文档与资源Day 78监控概述与 NagiosDay 80ELK Stack 日志栈实战Day 82EFK Stack 日志栈实战EFK Stack 部署清单Elastic Stack 的 Docker Compose 部署配置赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis 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点击查看免费下载相关推荐OpenTelemetry Go SDK 配置热更新指南免重启动态调整采样率、导出器与资源属性OpenTelemetry Go SDK 配置热更新指南免重启动态调整采样率、导出器与资源属性 凌晨两点上游服务集中报错需要把 trace 采样率从 0.可观测性Feast Operator 服务部署与可观测性实战server/serving 配置、Prometheus 指标与 MCP 接入Feast Operator 服务部署与可观测性实战server/serving 配置、Prometheus 指标与 MCP 接入 本指南围绕 Feast OMLOps后端数据工程Vision-Agents 可观测性实战用 Prometheus Grafana 采集并可视化语音与视觉 Agent 的实时指标Vision Agents 可观测性实战用 Prometheus Grafana 采集并可视化语音与视觉 Agent 的实时指标 本篇技术指南以 VisiAgent 框架音视频计算机视觉上一篇3大核心功能茉莉花插件让Zotero中文文献管理效率提升300%下一篇如何快速配置Zotero中文文献管理插件茉莉花插件完整使用指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考