Prometheus和Grafana是广泛使用的开源工具，有助于监测和观察。前者的功能是作为时间序列数据的数据库，同时以TSDB格式收集和存储度量信息。Prometheus最初于2012年在SoundCloud上创建，由于其高度的可扩展性和效率，最终成为科技行业中最广泛采用的监控工具之一。该系统可以熟练地收集和存储来自大量来源的数百万指标。普罗米修斯基于拉动的方法使其能够主动查询大量的目标，为DevOps收集必要的数据，这使他们能够以高度适应和灵活的方式运作于不同的服务器环境。
普罗米修斯利用一个内部的TSDB来存储数据。尽管TSDB最初是一个独立的Github仓库，但现在已经并入Prometheus项目。TSDB模块对于定义Prometheus如何管理存储至关重要。要了解它的功能，需要检查tsdb目录下的db.go文件。
为了更好地了解普罗米修斯存储，有必要调查存储的方式。
// Reference: https://blog.naver.com/PostView.nhn?blogId=alice_k106&logNo=221829384846root@sigridjin:/home/ubuntu/prometheus$ tree....├── 01E24YV8YFHGSES1WJ92FYMG6K -> Chunk & Metadata│ ├── chunks│ │ └── 000001 -> block Chunk file│ ├── index -> label for indexing & inverted index filed│ ├── meta.json -> block metadata│ └── tombstones -> is deleted? ├── 01E24YX3HF1GTZ4CPF24XZ3MKR │ ├── chunks│ │ └── 000001│ ├── index│ ├── meta.json│ └── tombstones├── lock -> lock file ├── queries.active -> saves the query in progress└── wal -> WAL (write ahead logging) files ├── 00006966 -> WAL file ├── 00006967 ├── 00006968 ├── 00006969 ├── 00006970 └── checkpoint.006965 -> restore checkpoint files └── 00000000 16 directories, 36 files普罗米修斯有两种主要的方法来存储数据。
- 本地文件系统：使用块状文件
- 内存中：使用WAL（提前写入日志）文件和内存中的缓冲区。
普罗米修斯并不像InfluxDB等数据库那样立即将记录数据存储在存储器中。相反，传入的数据被存储在内存缓冲区，直到新的记录超过当前内存页的32KB大小。在这一点上，当前页被刷新到WAL文件。数据主要存储在内存中，但会定期备份到WAL文件中。这种类型的存储空间通常被称为头块。
备份数据的WAL文件最多可以占用128MB，一旦超过这个大小，就会创建一个新的WAL文件。WAL文件的目的是为了防止在异常终止或崩溃的情况下丢失内存中的数据。当这种情况发生时，WAL目录中的checkpoint.XXXX文件作为读取WAL文件的参考点，通过重放操作恢复原始数据。
需要注意的是，网络存储可能导致检查点或WAL文件的损坏，这可能导致重大问题。这可能导致Prometheus持续无法重启，并导致新块的创建出现异常。在这种情况下，唯一的选择可能是删除数据并重新开始。因此，为了稳定起见，使用NVMe或本地存储可能是一个明智的选择。
普罗米修斯将数据存储在内存和WAL中，定期将数据冲入块状区，并删除最旧的WAL文件。每个分块块由一个带有奇怪的字符串的目录表示，如 \"01E24Y\"。该目录存储了倒置的索引文件以及特定时间窗口的记录。当查询Prometheus时，多个块状数据的记录索引被合并，为用户提供结果。由于每个索引文件和块数据都包含标签和时区，因此没有必要进行全面扫描，索引和块数据根据需要被映射到内存中。
有趣的是，块的数量不会随着时间的推移而继续增加。根据为Prometheus设置的配置选项，块可以根据保留策略被合并或删除。与此相关的两个选项包括 - storage.tsdb.min-block-duration 选项，它指的是存储在一个块中的数据的时间窗口，以及 - storage.tsdb.max-block-duration 选项，它指的是一个块中可以存储的最大时间窗口。默认值被设置为由- storage.tsdb.retention.time选项设置的块保留时间的10%。
在配置Prometheus时，确定要分配的内存和存储容量是要做出的最关键决定。最初，很难估计所需的确切容量，因为它取决于每个数据样本的大小、刮削的数量和标签的cardinality。虽然Prometheus配置可以控制目标，但Kubernetes允许通过注释进行搜刮，这使得这项任务更具挑战性，很难一目了然地看到搜刮的数量。
然而，一旦做出估计，Prometheus的内存需求就可以用健壮的感知法大致计算出来，除了通过mmap读取块状数据外，还考虑到驻留在内存中的Head Block数据。因此，一般建议分配大量的内存。如果内存的使用导致了OOM错误，可以考虑使用hashmod进行分片。
所需容量=保留时间*每秒数据摄取率*每次摄取的数据大小（通常为10-30kb）--普罗米修斯官方文档
第二个工具则是一个可视化工具，让用户根据存储在Prometheus中的数据制作仪表盘和图表，但它并不局限于单一数据源。Grafana经常与Prometheus一起使用，其主要功能是创建内容丰富的仪表盘，以图形、图表和表格显示实时指标数据。
将它们结合起来使用，可以为监控和分析微服务环境中的实时数据提供全面的解决方案，涵盖整个端到端的流程。Prometheus可以毫不费力地存储和收集大量的数据，而Grafana可以轻松地对Prometheus提供的数据进行可视化和分析。这种方法能够快速识别趋势和异常情况，并提示采取行动解决问题。普罗米修斯提供了自己的/metrics端点，可用于收集表明普罗米修斯正常运行的重要指标。这个端点允许访问指标，如块的创建/截断，这些都是有价值的监测指标。一旦理解，这些指标可以在Grafana中可视化，以便进一步分析和观察。
除了主要功能外，这两个工具还提供了许多其他功能，如内置的警报机制，使用户能够设置规则，在满足特定条件时触发通知。Grafana有丰富的插件/主题，由其他DevOps同伴开发并开放，允许用户扩大其功能，并与其他工具和服务整合。
本文来自于头条号作者：吉祥庄钢铁侠，本站旨在传播优质文章，无商业用途。