介绍
指标、日志和链路跟踪是端到端可观察性的核心支柱。尽管对于获得云原生架构的完整可见性至关重要，但端到端的可观察性对于许多 DevOps 和 SRE 团队来说仍然遥不可及。这是由于多种原因造成的，所有这些原因都以工具为共同点。由于超大规模云提供商和容器化微服务的使用不断增加，日志管理市场必须解决这一工具难题，才能实现其预计的从2020 年的 19 亿美元到 2026 年的 41 亿美元的扩张。
将自动化、可观察性和智能融合到 DevOps 管道、指标监控和管理中，可以提高 DevOps 和 SRE 团队对软件的可见性，并提高软件的整体质量。虽然存在多种现成的指标监控选项，但 Prometheus 和 InfluxDB 是市场领导者。本文研究了这两种流行的监控解决方案，以揭示它们独特的用例和常见的用户困难。
Prometheus VS InfluxDB - 快速介绍
Prometheus是一款功能强大的开源监控工具，提供实时指标数据。InfluxDB 是一个时间序列数据库，可以有效地存储和查询这些数据。它们是适用于现代应用程序的强大监控堆栈，但有一些人们应该知道的限制，正如我们将在这篇博客文章中看到的那样。
Prometheus是什么？
Prometheus是一个用于跟踪和收集指标的开源时间序列数据库。Prometheus 包含用户定义的多维数据模型和称为 PromQL 的多维数据查询语言。
Prometheus 时间序列数据库进行了 3 次重大修订。Prometheus 的初始版本将所有时间序列数据和标签元数据存储在 LevelDB 中。通过保存每个时间序列的时间序列数据并实现增量压缩，V2 修复了 V1 的几个问题。V3 中添加了预写日志记录和改进的数据块压缩，以取得更多进步。
什么是 InfluxDB？
Influx DB是一个用Go语言编写的开源时间序列数据库。它每秒可以存储数十万个点的数据。InfluxDB 经历了四次关键修订——从 0.9.0 版本（包含 ）LevelDB-based LSMTree scheme到现在更新的版本（1.3包含WAL TSM file TSI file-based scheme.
已知限制
虽然 Prometheus 在实时监控和警报方面表现出色，但由于其数据保留限制，它在长期数据存储方面遇到了困难，这对于需要全面历史数据分析的用户来说可能并不理想。
InfluxDB 虽然处理时间序列数据的能力很强，但没有对高基数数据集的原生支持，这使得它在处理大量独特数据点时效率低下且成本高昂。
Prometheus 和 InfluxDB 在分布式计算方面都有其局限性：Prometheus 缺乏对集群的原生支持，使得扩展更加复杂，而 InfluxDB 的集群仅在企业版中可用，限制了开源版本的可扩展性。
Prometheus的局限性
Prometheus 可轻松与大多数现有基础组件集成。Prometheus支持多维数据采集和查询。这对于微服务的监控尤其有利。Prometheus 在指标和日志管理方面的有效性通过其自然包含在 Kubernetes 监控基础设施中得到了证明。尽管 Prometheus 具有明显的有效性，但它仍存在以下缺点：
规模
Prometheus 没有长期存储（LTS）——它不是为水平扩展而设计的。这是一个重大的负面影响，特别是对于大多数大型企业环境而言。
随着 Kubernetes 容器中服务数量的增加和指标使用量的增加，您的集群随后会扩展，并且您的服务的副本数量也会增加。因此，您必须监控和管理更多的集群指标，以确保容器高效运行。遗憾的是，这种不断升级的使用会耗尽您的 Prometheus 服务器。
Prometheus 中存储的时间序列数量与内存使用密切相关，随着时间序列数量的增加，OOM Kill 开始发生。虽然增加资源配额限制在短期内是有益的，但从长远来看是无效的，因为没有任何 pod 可以在某个时刻扩展到超过节点的内存容量。
此问题有解决方法。使用不同的第三方 LTS 解决方案（例如Levitate、Thanox 或 Cortex）在多个 Prometheus 服务器上划分各种指标。然而，这些只会让本已复杂的集群变得更加复杂。尤其是当您有大量指标时。最后，这使得故障排除变得具有挑战性。
轮询
Prometheus 轮询器必须可以访问所有指标端点，以符合 Prometheus 使用的基于拉取的方法。推断需要更复杂的安全网络配置，现有复杂的基础设施变得更加复杂。
高级数据库功能
Prometheus 不支持无缝监控和指标聚合所需的某些数据库功能，例如存储过程、查询编译和并发控制。
InfluxDB 的局限性
InfluxDB 有两个主要限制。
基数和内存消耗
InfluxDb 使用整体数据存储将索引和指标值存储在单个文件中。因此，数据相对消耗更多的存储空间。这可能会导致高基数问题。
缺乏强大的警报和可视化
InfluxDB 没有警报和数据可视化组件。因此，它必须与Grafana等可视化工具集成。不幸的是，当它与 grafana 集成时，高延迟率是另一个问题，如下评论所证明：
Prometheus 与 InfluxDB 之间的快速比较
Prometheus 和 InfluxDB 之间的异同凸显了它们在各种场景中的独特实用性。
Prometheus 与 InfluxDB 的详细分析
以下是两种监控方案的比较和差异：
数据采集
InfluxDB 是一个基于推送的系统。它需要应用程序主动将数据推送到 InfluxDB 中。将数据写入 InfluxDB 系统时，三个参数（视图组织、视图存储桶和视图身份验证令牌）至关重要。
另一方面，Prometheus 是一个基于拉动的系统。Prometheus 定期获取应用程序在某个端点发布的指标。然后，Prometheus 使用拉取机制从指定目标收集这些指标。目标可以是 SQL Server、API 服务器等。
压缩
Prometheus 和 InfluxDB 使用 delta-of-delta 压缩算法来压缩时间戳，类似于 Facebook 的 Gorilla 时间序列数据库使用的算法。
一体化
在与远程存储引擎集成时，Prometheus 使用 HTTP 和 RESTful API 上的缓冲区编码来读取和写入协议。同时，InfluxDB 采用 HTTP、TCP 和 UDP API，使用快速压缩的协议缓冲区编码。
数据模型
Prometheus 将数据存储为时间序列。一个指标和一组键值标签定义了一个时间序列。Prometheus 支持以下数据类型：计数器、仪表、直方图和摘要。
InfluxDB 将数据存储在分片组中。在InfluxDB中，字段数据类型必须在以下范围内保持不变；否则，写入数据时会报类型冲突错误：相同SeriesKey 相同字段 相同分片。InfluxDB 支持以下数据类型：Float、Integer、String 和 Boolean。
数据存储
时序数据库的存储引擎应该能够使用时间线直接扫描给定时间戳范围内的数据，大批量写入时序数据，并使用测量和一些标签间接查询给定时间戳范围内所有匹配的时序数据。
InfluxDB 使用由 WAL、TSM 和 TSI 文件组成的 trident 解决方案在整体数据存储中存储索引和指标值。系列关键数据和时间序列数据在 InfluxDB 中保持不同，并写入各种 WAL。这是数据的存储方式：
尽管 Prometheus 和 InfluxDB 都使用键/值数据存储，但两个平台之间的实现方式差异很大。InfluxDB 将索引和指标存储在同一个文件中，而 Prometheus 使用 LevelDB 作为索引，每个指标都存储在其文件中。
查询语言
InfluxDB 使用 InfluxQL（一种常规 SQL 语法），而 Prometheus 使用 PromQL 进行查询。
缩放
无需担心独立扩展节点，因为 InfluxDB 的节点是连接的。由于Prometheus节点的独立性，需要独立的可扩展性能力。
