Botmetric 旅程：选择有效的实时指标数据存储 

作者：Chris Churilo / 产品, 开发者, 用例
2017 年 5 月 17 日

此博客文章最初发布在 Medium 上 - 经 Botmetric 的 Vijay Rayapati 许可在此处发布。

Botmetric 旅程：选择有效的实时指标数据存储 （从 OpenTSDB、Cassandra 到 InfluxDB）

我们于 2014 年创立了 Botmetric，使命是为“现代 DevOps 世界提供智能云管理”。我们提供了一个智能运营平台，用于云成本管理、云安全合规性和 DevOps 自动化，使用来自各种运营来源（如云提供商、监控工具、日志等）的元数据，并应用算法来帮助企业做出决策，使其能够在云世界中高效运营。借助 Botmetric，云客户可以降低总体成本，提高安全态势，并自动化日常运营，以便他们的工程师可以专注于业务问题，而不是解决每个云运营和 DevOps 问题。

为了通过智能洞察和自适应自动化向我们的客户交付承诺的价值，我们从不同的来源收集大量时间序列数据，以便得出可操作的洞察并为 DevOps 团队提供运营生产力。在这篇文章中，我们想分享我们如何尝试和部署各种技术堆栈，如 OpenTSDB 和 Cassandra，然后转向 InfluxDB 作为我们的核心数据存储系统之一。

我们的第一次尝试（大约 2014 年）- OpenTSDB

我们正在寻找一种 时间序列数据库 解决方案，该解决方案可以扩展并与我们的 Java 堆栈良好协作。在了解了 StumbleUpon 用例以及在 Monitorama 会议上听取了几次技术讲座后，我们确定使用 OpenTSDB。我们的一些工程团队成员有在生产中使用 HBase 的经验，因此我们准备尝试并将其部署到我们的用例中。

虽然我们喜欢 OpenTSDB 的可扩展性方面，但仅仅在生产中操作该系统作为我们的主要数据源就变成了一个令人头疼的问题，需要负担 Hadoop、HBase、ZooKeeper 和 OpenTSDB 层的管理。由于 OpenTSDB 堆栈中有如此多的移动部件，并且在生产中调试问题上花费了大量时间，因此比我们的工程团队预期的花费了更多时间。因此，在 6 个月内，我们意识到它不适合像我们这样的小型而灵活的团队。数据聚合是另一个主要问题，它减慢了我们的开发速度，因为我们正在构建具有云洞察、成本分析等的仪表板。此外，2014 年 HBase 缺乏可靠的故障转移导致我们的数据可用性问题，生产中停机数小时，因此尽管我们尽一切努力稳定该系统，但我们不得不放弃。除了运营问题外，当我们开始将新 Botmetric 模块开发的某些部分从 Java 堆栈迁移出来时，我们没有可靠的 Python 客户端库，这迫使我们寻找替代方案。

我们的第二次尝试（大约 2014 年末和 2015 年初）- Cassandra 和 KairosDB

在 2014 年末，我们决定放弃 OpenTSDB，并将 Cassandra 和 KairosDB 列为存储时间序列数据的替代选择。与 OpenTSDB 相比，我们喜欢快速设置和更少的运营负担。我们还要感谢 Datastax 在他们的初创企业许可计划下为我们提供了企业版。Cassandra 为我们提供了成熟的客户端库支持，以便于集成。我们有两个用例，其中我们必须使用 KairosDB 存储时间序列数据，另一个用例是将数据直接加载到单独命名空间中的 Cassandra 中。最初的 PoC 和结果是积极的，因为它对各种数据收集器和基本数据聚合器都有良好的支持，因此我们可以快速构建新的报告功能。

虽然 Cassandra 一直为我们工作到 2016 年初，但我们遇到了很多挑战——包括批量加载数据到 Cassandra 中的问题。此外，随着我们获得了拥有大量数据的更大客户，Cassandra 集群必须通过高端机器进行垂直扩展，并通过更多节点进行水平扩展。我们每天将数亿条记录摄取到该数据存储中，并且仍然使用 CQL 在 Cassandra 之上进行应用程序级数据聚合，这对于我们大多数工程师来说都是一项耗时的练习。我们甚至编写了一个小型实用程序来将陈旧数据从 Cassandra 中存档出来，以减少查询延迟问题。我们的产品路线图计划在 Botmetric 中支持任何自定义报告，我们的最终用户应该能够使用 DIY 界面构建任何类型的报告，随着围绕报告、数据切片和切块以及自定义报告请求的用例不断增长。因此，我们再次面临构建速度更快的新问题，而我们的冲刺生产力是一个主要问题。

我们想将主要由最终用户用于洞察、多维度临时报告的大部分数据迁移到搜索存储中，以便我们可以减少对 Cassandra 的依赖，在此过程中，我们的首选是 Elasticsearch。从 2015 年末开始，我们已开始将大量关于云基础设施、账单和使用记录等的元数据迁移到其中，以便从我们的 SaaS 平台更轻松、更快速地查询数据。

虽然数据存储是我们工作的核心引擎，但 Botmetric SaaS 平台是 25 多个微服务的整合，这些微服务专注于我们产品平台内的特定用例，包括我们的通用平台服务。随着我们的 SaaS 平台随着更多客户的增长而扩展并分解为基于微服务的架构，我们需要从我们的微服务、组件使用情况及其监控指标等流式传输数据到一个可靠的存储，该存储可用于 Botmetric 运营洞察，除了支持我们产品用例的时间序列数据需求之外。

最终，一个有效实时数据存储（大约 2015 年末和 2016 年初）- InfluxDB

Botmetric 平台收集大量不同性质的数据（实时、批量拉取（如爬虫）、事件数据拉取和基于推送的事件等）和不同维度的数据（分钟、小时、每天、每周、每月）。尽管在生产中使用 Cassandra 和 KairosDB 超过一年，但我们对可靠的时间序列和实时数据存储的搜索仍未实现。

与其他 SaaS 工具相比，Botmetric 平台的一个独特之处在于我们强大的自动化框架，供 DevOps 团队调用基于实时事件或计划工作流程的自动化操作。目前，我们每天为我们的客户执行数千个作业来处理他们的任务——随着我们扩展大型企业客户的获取，预计这将达到数百万个任务，并且应该跟踪所有 Botmetric 自动化的元数据，以便我们可以通知最终用户并提供对已完成和未完成事项的可见性。我们的技术架构师 Yuvaraj 从 2015 年初开始就是 InfluxDB 的内部拥护者，我们部署了 InfluxData TICK 堆栈和 Grafana 来监控我们的微服务事件（这是另一个故事，关于为什么在我们的微服务架构和 docker 在我们的生产环境中采用后，我们从 Datadog 迁移到 TICK 堆栈）。

关于 InfluxDB 最棒的事情是它的简单性、易用性、对各种客户端库的支持以及出色的查询聚合能力。并且缺乏像 OpenTSDB 或 KairosDB+Cassandra 等的运营开销。我们非常喜欢我们所看到的——TICK 堆栈部署为我们的 SaaS 平台指标收集和事件监控所做的事情。此外，InfluxDB 将简单性从开发带到生产运营，并为我们的工程团队减少了开销，因为它是一个简单的软件包，没有多层管理的复杂性。与 Cassandra CQL 的复杂性相比，从 InfluxDB 查询数据和数据聚合要容易得多，并且某些数据集的自动过期支持进一步减少了 DevOps 清理旧数据所需的工作量，无需单独的实用程序。

我们已经淘汰了整个 KairosDB+Cassandra 集群，并用 InfluxDB 和 Elasticsearch 取代了它。我们甚至使用 InfluxDB (TICK) + Grafana 监控我们的 Cassandra 集群，直到它被逐步淘汰！

今天，InfluxDB 和 TICK 堆栈是 Botmetric 技术格局中的核心组件，并将进一步发展成为我们的核心数据存储；我们为 Telegraf 贡献了几个补丁，并将继续采用 InfluxDB 作为我们的核心数据存储，因为我们构建新的实时用例，这些用例本质上是事件驱动的。

作为工程师或架构师，今天，如果您正在选择、评估或寻找实时数据存储，那么 InfluxDB 是救星；它的简单性令人惊叹，肯定会加快您的应用程序开发时间。如果 InfluxDB 是您的关键数据存储，那么其简单的运营管理就显得更加重要，这样您就不需要在任何生产调试期间绞尽脑汁，并且他们积极的社区支持将非常有帮助。

我们经常将 InfluxDB 称为“高速实时指标数据存储”的良好选择，对于大多数用例，您的搜索应该到此为止 :)