prometheus 中文文档
v2.17
v2.17
  • Prometheus 中文文档
  • introduction
    • 概述
    • 初识 Prometheus
    • 与替代品比较
    • 常见问题
    • 路线图
    • 相关资源
    • 相关术语
  • concepts
    • 数据模型
    • 数据指标类型
    • 作业和实例
  • prometheus
    • 快速开始
    • 安装
    • 配置
      • 配置
      • 定义记录规则
      • 告警规则
      • 模板示例
      • 模板参考
      • 规则的单元测试
    • 查询
      • Prometheus 查询
      • 运算符
      • 函数
      • 查询示例
      • HTTP API
    • 存储
    • 联合
    • 管理 API
    • Prometheus 2.0 迁移指南
    • API 稳定性保证
  • visualization
    • 表达式浏览器
    • Grafana 对 Prometheus 的支持
    • 控制台模板
  • operating
    • 安全模型
    • 集成
  • instrumenting
    • 客户端库
    • 编写客户端库
    • 推送数据指标
    • 数据导出及相关集成
    • 编写数据导出器
    • 公开的格式
  • alerting
    • 告警概述
    • Alertmanager
    • 配置
    • 发送告警
    • 通知模板参考
    • 通知模板示例
    • 管理 API
  • practices
    • 指标和标签命名
    • 控制台和仪表盘
    • 工具
    • Histogram and Summary
    • 告警
    • 记录规则
    • 什么时候使用 Pushgateway
    • 远程写调试
  • guides
    • 使用 cAdvisor 监控 docker 容器数据指标
    • 使用基于文件的服务发现来发现数据采集目标
    • 实现一个 Go 应用
    • 使用 Node Exporter 监控 Linux 主机指标
    • 使用基本身份验证保护 Prometheus API 和 UI 端点
    • 理解并使用 multi-target exporters 模式
    • 使用 TLS 加密 Prometheus API 和 UI 端点
    • 使用 Prometheus 查询日志
由 GitBook 提供支持
在本页

这有帮助吗?

  1. practices

控制台和仪表盘

上一页指标和标签命名下一页工具

最后更新于5年前

这有帮助吗?

在仪表盘上显示尽可能多的数据可能很诱人,尤其是当像 Prometheus 这样的系统提供了对应用程序进行如此丰富的检测的能力时。由于信息太多,这可能会导致控制台无法理解,即使系统专家也很难从中提取其含义。

对于操作控制台,不要尝试表现您拥有的所有数据,而要考虑最可能的故障模式是什么,以及如何使用控制台来区分它们。利用您的服务结构。例如,如果在线服务系统中的服务树很大,那么较低服务中的延迟就是一个典型的问题。与其在单个大型仪表板上显示每个服务的信息,不如为每个服务构建单独的仪表板,其中包括与之通信的每个服务的延迟和错误。然后,您可以从顶部开始,然后逐步处理出现问题的服务。

我们发现以下准则非常有效:

  • 控制台上的图形不能超过5个。

  • 每个图形上的绘图(线)不得超过5个。如果它是堆积/面积图,您可以绘制更多

  • 使用提供的控制台模板示例时,请避免在右侧表中输入超过 20-30 个条目

如果您发现自己超出了这些限制,则可以降低不太重要的信息的可视性,并可能将某些子系统拆分为一个新的控制台。例如,您可以对汇总的数据(而不是细分的数据)进行图形化处理,将其移至右侧表,甚至在很少有用的情况下甚至完全删除数据 - 您始终可以在中查看它!

最后,一组控制台很难服务多个主机。调用时您想知道的内容(发生了什么故障?)与开发功能时想要的内容(多少人碰到了极端案例X?)有很大的不同。在这种情况下,两组独立的控制台会很有用。

表达式浏览器