我正在使用 Prometheus 2.9.2 来监控大型节点环境。 作为在我们的环境中测试 Prometheus 最大规模的一部分,我在我们的测试环境上模拟了大量指标。
我的管理服务器有 16GB 内存和 100GB 磁盘空间。
在规模测试期间,我注意到 Prometheus 进程消耗越来越多的内存,直到进程崩溃。
我注意到 WAL 目录很快就被大量数据文件填满,而 Prometheus 的内存使用量却在上升。
管理服务器每15秒抓取一次节点,存储参数全部设置为默认值。
我想知道为什么会发生这种情况,以及如何/是否可以防止进程崩溃。
谢谢!
内存不足崩溃通常是由于查询过于繁重而导致的。这可以在您的规则之一中设置。 (该规则甚至可能在 grafana 页面上运行,而不是在 prometheus 本身上运行)
如果您有大量指标,则规则可能会查询所有指标。一种快速解决方法是准确指定要使用特定标签而不是正则表达式查询的指标。
本文解释了为什么 Prometheus 在数据摄取过程中可能会使用大量内存。如果您需要减少 Prometheus 的内存使用量,那么以下操作可以提供帮助:
Prometheus 配置中增加
scrape_interval
。附注另请看看我从事的项目 - VictoriaMetrics。与 Prometheus 相比,它可以使用更少的内存。有关详细信息,请参阅此基准测试。
因为标签的组合取决于你的业务,组合和块可能是无限的,目前prometheus的设计没有办法解决内存问题!!!但我建议你将小块压缩成大块,这样会减少块的数量。
巨大的内存消耗有两个原因:
在index/index.go中,你会看到:
type Reader struct {
b ByteSlice
// Close that releases the underlying resources of the byte slice.
c io.Closer
// Cached hashmaps of section offsets.
labels map[string]uint64
// LabelName to LabelValue to offset map.
postings map[string]map[string]uint64
// Cache of read symbols. Strings that are returned when reading from the
// block are always backed by true strings held in here rather than
// strings that are backed by byte slices from the mmap'd index file. This
// prevents memory faults when applications work with read symbols after
// the block has been unmapped. The older format has sparse indexes so a map
// must be used, but the new format is not so we can use a slice.
symbolsV1 map[uint32]string
symbolsV2 []string
symbolsTableSize uint64
dec *Decoder
version int
}
我们使用了 prometheus 2.19 版本,内存性能明显更好。 本博客重点介绍了此版本如何解决内存问题。我强烈建议使用它来改善您的实例资源消耗。