常见问题
最后更新于
这有帮助吗？
Prometheus 是具有活跃生态系统的开源系统监视和警报工具包。请参阅。
请参阅页面。
Prometheus 主服务独立运行，没有外部依赖。
可以，在两台或多台独立的机器上运行相同的 Prometheus 服务。相同的告警将由 进行重复数据删除。
关于 ，您可以在 中运行多个实例，并配置 Prometheus 服务器向每个实例发送通知。
实际上，存在多种缩放和联合 Prometheus 的方法。阅读 Robust Perception 的 博客开始使用。
大多数 Prometheus 组件使用 Go 编写的。有些使用 Java，Python 和 Ruby 编写。
通常，即使尚未达到 1.0.0 版的仓库也相当稳定。我们的目标是为每个仓库制定适当的发布流程并最终发布 1.0.0。在任何情况下，都会在发行说明中指出重大更改(由[CHANGE]标记)，或者对于尚未正式发行的组件进行明确传达。
通过 HTTP 拉取数据的方式有很多优点：
开发更改时，可以在笔记本电脑上运行监控。
您可以更轻松地判断目标是否已关闭。
您可以手动转到目标并使用 Web 浏览器检查其运行状况。
总体而言，我们认为拉取数据比推送数据略好，但在考虑使用监控系统时，不应将其视为重点。
现在，它已由众多公司和个人维护和扩展。
可以，将SIGHUP信号发送到 Prometheus 进程或将 HTTP POST请求发送到/-/reload 端点将重新加载并应用配置文件。各种组件将尝试优雅地处理失败的更改。
目前，支持以下外部系统发送告警信息：
邮件
通用 webhook
尽管 TLS 和身份验证是经常需要的功能，但我们故意没有在 Prometheus 的任何服务端组件中实现它们。两者都有太多不同的选项和参数(仅TLS就有 10 多个选项)，我们决定专注于构建最佳监视系统，而不是在每个服务器组件中都支持完全通用的 TLS 和身份验证解决方案。
Prometheus GitHub 组织中所有已达到版本 1.0.0 的仓库都大致遵循。 重大更改以主要版本的增量表示。实验性组件可能会出现例外，声明中会明确标明例外情况。
对于必须推送的情况，我们提供了 。
简短的回答：不要使用 Prometheus 处理日志！请改用类似于 工具
更长的答案：Prometheus 是一个收集和处理指标的系统，而不是事件记录系统。Raintank 博客文章 提供了有关日志和指标之间差异的更多详细信息。
如果您想从应用程序日志中提取 Prometheus 指标，Google 的 可能会有所帮助。
Prometheus 最初由 和 私人创立。它的大部分初始开发是由 赞助的。
Prometheus 是根据 许可发布的。
经过，已经确定 "Prometheus" 的正确复数是 "Prometheis"。
可以，使用 。
可以，我们建议您使用 用于生产。也有内置的。
为避免任何形式的时区混乱，特别是在涉及所谓的夏时制时，我们决定在 Prometheus 的所有组件中内部专门使用 Unix time 和 UTC 进行显示。可以将精心完成的时区选择引入 UI。 欢迎贡献。 有关此工作的当前状态，请参阅 。
有许多客户端库可使用 Prometheus 指标来检测您的服务。有关详细信息，请参见文档。
如果您有兴趣贡献新语言的客户库，请参见
可以， 在 Linux 和其他 Unix 系统上暴露了大量的计算机级别指标，例如CPU使用率，内存，磁盘使用率，文件系统完整性和网络带宽。
可以， 允许监控支持 SNMP 的设备。
可以，使用 。另请参阅监视批处理作业的。
请参阅。
可以，对于不能直接使用 Java 客户端进行检测的应用程序，可以将 单独使用或作为 Java 代理使用。
客户端库和语言之间的性能可能会有所不同。对于 Java，表明，取决于争用情况，使用Java客户端增加计数器/表将花费 12-17ns。除了对延迟最关键的代码之外，所有其他代码都可以忽略不计。
不完全关闭造成的。在接收到SIGTERM信号之后，Prometheus 必须彻底关闭，这对于频繁使用的服务器可能需要一段时间。如果服务器崩溃或被强制杀死(例如，由于 OOM 被内核杀死或在等待 Prometheus 关闭时，您的运行级别系统不耐烦)，则必须执行崩溃恢复，在正常情况下，恢复时间应少于一分钟，但在某些情况下要花很长时间。有关详细信息，请参见。
请参阅有关配置 的部分以获取可用内存量。
您的存储设备负担重。阅读有关，以了解如何调整设置以获得更好的性能。
我们将自己限制在 64 位浮点数以简化设计。支持最大精度为2^53的整数精度。仅当需要大于$2^53但小于2^63的整数精度时，支持本机 64 位整数(仅)会有所帮助。原则上，支持不同的样本值类型(包括某种大整数，甚至支持64位以上)都可以实现，但目前不是优先事项。计数器即使每秒增加一百万次，也只会在超过 285 年后才会出现精度问题。
注意：Prometheus 团队在 2018 年 8 月 11 日的开发峰会上已改变了立场，该现已支持对 TLS 和服务端点中的身份验证的支持。更改代码后，将更新此文档。
如果您需要 TLS 或身份验证，我们建议在 Prometheus 前面放置一个反向代理。例如，参见。
这仅适用于入站连接。 Prometheus 支持，并且其他创建出站连接的 Prometheus 组件也具有类似的支持。