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 博客文章《Logs and Metrics and Graphs, Oh My!》更详细地介绍了日志和指标之间的区别。
如果您想从应用日志中提取 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 客户端增加 counter/gauge 需要 12-17 纳秒，具体取决于竞争情况。这对于除对延迟最敏感的代码之外的所有代码来说都是微不足道的。
我们将自己限制在 64 位浮点数，以简化设计。IEEE 754 双精度二进制浮点格式支持高达 253 的整数精度。支持原生的 64 位整数（只）在您需要高于 253 但低于 263 的整数精度时有所帮助。原则上，可以实现对不同样本值类型（包括某种大整数，甚至支持超过 64 位）的支持，但这目前不是优先事项。一个 counter，即使每秒增加一百万次，也只会在超过 285 年后才会遇到精度问题。
本文档是开源的。请通过提交 issue 或 pull request 帮助改进它。