Instana 使用 Apache Cassandra 查询数十亿指标
合作伙伴信息
-
可观察性与指标
-
150 多名员工
-
每秒数百万指标
-
五个生产区域，每个区域有 15 个节点
-
在 AWS 和 GCP 上运行
优势
-
用于固定查询的分布式模型
-
由小型团队维护的复杂数据建模
-
Cassandra TTL 作为内置数据模型
-
易于实施保留策略
-
实时查询数百万指标
-
Cassandra 3.0 时间窗口压缩策略，便于轻松查看时间窗口
Instana 是一家位于伊利诺伊州芝加哥的 IBM 公司，为现代应用程序提供应用程序性能管理软件，具有 CI/CD 管道可见性，支持闭环 DevOps 自动化。Instana 通过实时收集数十亿指标每天，并使用 Apache Cassandra 大规模存储和处理数据，提供丰富的上下文智能和基于 AI 的问题解决能力。其高性能、高规模架构在混合云中以一秒钟的间隔捕获 100% 的事务，涵盖大型分布式应用程序。
Instana 的监控工具（也称为 Instana）收集主机级数据，例如 CPU 和内存使用情况，并映射在主机上运行的进程。该工具监控到应用程序层，跟踪一个请求在系统中的传递过程。
挑战
Instana 的客户群正在增长，新用户对产品的期望更高。用户不想等待一分钟才能看到结果，他们希望实时看到结果。
Instana 目前在五个区域运营，每个区域有四个集群，运行着数千个传感器。每个传感器每秒可以发送 1,000 个或更多指标：“我们需要一些东西来存储这些数据并进行查询。我们始终知道要从哪个传感器获取查询数据，并且它被限制在某个时间范围内。这就是我们选择 Cassandra 的原因，因为它具有时间序列数据模型，”Instana 的员工站点可靠性工程师 Marcel Birkner 说。
对于 Instana 团队来说，Apache Cassandra 非常出色地满足了其特定用例。
客户评价
Cassandra 运行良好；它运行得非常顺畅。我们从未丢失过数据，而且问题很容易解决。坦率地说，没有 Cassandra，我们就无法运行 Instana。
员工站点可靠性工程师，Instana
当我们开始使用 Instana 时，就像初创公司通常会做的那样，尤其是在我们的情况下，我们监控了 100 种不同的技术和 1,000 个不同的库，使用 Cassandra 的微服务架构意味着当单个组件出现故障时，我们可以进行优雅降级。
员工软件工程师，Instana
高容量查询的强大性能
监控复杂的系统需要以一秒钟的粒度报告指标。Instana 与传感器配合使用，这些传感器收集系统性能数据并报告不同的指标，例如 CPU 使用率或微不足道的 GC 时间。通常，一个环境可以有数千个传感器，每个传感器每秒可以发送 1,000 个或更多指标。对于单个用户来说，结果是大量数据。
除了大量数据摄取之外，用户还必须能够查询其数据，通常侧重于单个传感器，并受时间范围约束。Cassandra 时间序列数据模型非常适合这种需求。
优雅降级
Instana 面临着单体架构无法解决的数据建模挑战。最值得注意的是，该应用程序监控了数百种技术和数千个库，用户将这些库混合到数百万种配置中。只有由 Apache Cassandra 支持的微服务架构才能在数据接收系统的一部分停止工作或被弃用时实现优雅降级。
时间窗口压缩
早期，一个很大的挑战是找到合适的窗口和其他压缩设置。如果没有合适的策略，这很快就会失控。压缩过程合并键、合并列、清除墓碑、合并 SSTable 以及在合并的 SSTable 中创建新的索引。如果简单地使用这种方法，在写入新的汇总数据点时，每秒可能会产生数百万次插入操作。在某个时候，一个集群只有一个表，其中包含 30,000 个 SSTable，团队不得不运行手动压缩才能将其缩减到可管理的大小。
一秒钟数据分辨率的规模对于长期存储或涵盖相当长一段时间（例如，查看过去三个月的内存使用情况）的查询来说没有意义。对于这种用例，Instana 希望汇总数据，这表明数据如何以五秒钟间隔平均。选择为用户修复时间窗口视图，显示一秒钟、一小时、一天和一周的视图。汇总数据具有不同的保留策略，而 Cassandra TTL（生存时间）非常适合数据模型。
Instana 的用户发出时间窗口请求以查看其 Instana 数据，这使得 Cassandra 成为完美匹配。Cassandra 3.0 的时间窗口压缩策略使 Instana 能够对磁盘上的数据进行分组，这些数据将在时间窗口分组中查看。
