Prometheus 是一个具有活跃生态系统的开源系统监控和告警工具包。它是 Kubernetes 直接支持的唯一系统，并且是 云原生生态系统 中事实上的标准。请参阅概览。
请参阅比较页面。
主 Prometheus 服务器作为单个单体二进制文件独立运行，没有外部依赖项。
是的。
云原生是一种灵活的运营模式，打破了旧的服务边界，以允许更灵活和可扩展的部署。
Prometheus 的 服务发现 与大多数工具和云集成。其维度数据模型和扩展到数千万的活动系列使其能够监控大型云原生部署。运行服务时总是需要进行权衡，Prometheus 认为可靠地向人类发出警报高于一切。
是的，在两台或多台单独的机器上运行相同的 Prometheus 服务器。相同的告警将由 Alertmanager 进行去重。
Alertmanager 通过互连多个 Alertmanager 实例来构建 Alertmanager 集群来支持高可用性。集群的实例使用通过 HashiCorp 的 Memberlist 库管理的 gossip 协议进行通信。
这通常更多的是一种营销说法。
Prometheus 的单个实例可能比某些将自己定位为 Prometheus 长期存储解决方案的系统更高效。您可以使用数千万个活动系列可靠地运行 Prometheus。
如果您的需求超出此范围，则有多种选择。Robust Perception 博客上的 扩展和联合 Prometheus 是一个很好的起点，我们的集成页面上列出的长期存储系统也是如此。
大多数 Prometheus 组件是用 Go 编写的。有些也用 Java、Python 和 Ruby 编写。
Prometheus GitHub 组织中所有已达到 1.0.0 版本的存储库都广泛遵循 语义版本控制。重大更改通过增加主要版本来表示。实验性组件可能会有例外，这些组件会在公告中明确标记。
即使尚未达到 1.0.0 版本的存储库，通常也相当稳定。我们的目标是为每个存储库建立适当的发布流程并最终发布 1.0.0 版本。无论如何，重大更改将在发行说明中指出（标记为 [CHANGE]），或者为尚未正式发布的组件明确传达。
通过 HTTP 拉取提供了许多优势
总的来说，我们认为拉取比推送稍微好一些，但在考虑监控系统时，不应将其视为主要因素。
对于必须推送的情况，我们提供 Pushgateway。
简短回答：不要！请改用 Grafana Loki 或 OpenSearch 之类的工具。
更长的回答：Prometheus 是一个用于收集和处理指标的系统，而不是事件日志系统。Grafana 博客文章 日志和指标和图表，我的天哪！ 提供了有关日志和指标之间差异的更多详细信息。
如果您想从应用程序日志中提取 Prometheus 指标，Grafana Loki 专为此而设计。请参阅 Loki 的 指标查询文档。
Prometheus 最初由 Matt T. Proud 和 Julius Volz 私下启动。其大部分初始开发由 SoundCloud 赞助。
Prometheus 在 Apache 2.0 许可下发布。
经过广泛研究，已确定“Prometheus”的正确复数形式是“Prometheis”。
如果您记不住这一点，“Prometheus 实例”是一个很好的解决方法。
是的，向 Prometheus 进程发送 SIGHUP 或向 /-/reload 端点发送 HTTP POST 请求将重新加载并应用配置文件。各个组件会尝试优雅地处理失败的更改。
是的，可以使用 Alertmanager。
我们支持通过 电子邮件、各种原生集成以及任何人都可以向其中添加集成的 webhook 系统发送告警。
是的，我们建议在生产环境中使用 Grafana。还有控制台模板。
为了避免任何时区混淆，尤其是在涉及到所谓的夏令时时，我们决定在 Prometheus 的所有组件中内部专门使用 Unix 时间，并使用 UTC 进行显示。可以在 UI 中引入一个经过仔细选择的时区。欢迎贡献。请参阅 issue #500 以了解此工作的当前状态。
有很多客户端库可用于使用 Prometheus 指标检测您的服务。有关详细信息，请参阅客户端库文档。
如果您有兴趣为新语言贡献客户端库，请参阅暴露格式。
是的，Node Exporter 在 Linux 和其他 Unix 系统上公开了大量机器级别的指标，例如 CPU 使用率、内存、磁盘利用率、文件系统满载程度和网络带宽。
是的，SNMP Exporter 允许监控支持 SNMP 的设备。对于工业网络，还有一个 Modbus exporter。
是的，使用 Pushgateway。另请参阅监控批处理作业的最佳实践。
请参阅导出器和集成列表。
是的，对于您无法使用 Java 客户端直接检测的应用程序，您可以使用JMX Exporter，它既可以独立运行，也可以作为 Java Agent 使用。
客户端库和语言的性能可能会有所不同。对于 Java，基准测试表明，使用 Java 客户端递增计数器/仪表需要 12-17 纳秒，具体取决于争用情况。对于除了最延迟敏感的代码之外的所有代码，这都可以忽略不计。
我们将自己限制为 64 位浮点数以简化设计。IEEE 754 双精度二进制浮点格式支持高达 253 的整数精度。如果您需要高于 253 但低于 263 的整数精度，支持本机 64 位整数将（仅）有所帮助。原则上，可以实现对不同样本值类型的支持（包括某种大整数，支持甚至超过 64 位），但这不是目前的优先事项。即使每秒递增一百万次，计数器也将在 285 年后才会遇到精度问题。
此文档是开源的。请通过提交问题或拉取请求来帮助改进它。