客户亮点：索引交易所如何使用InfluxDB平台现代化其DevOps实践

作者：Caitlin Croft / 产品，用例，开发者
2021年5月18日

在InfluxData工作最美好的事情之一就是结识全球的InfluxDB社区成员。通过我们的社区Slack、社交媒体、团队成员以及虚拟/现场活动，我们总是很有趣地遇见新用户。我最近遇到了David Ko，他是索引交易所的DevOps工程师。索引交易所是全球数字媒体广告的市场，我最近与David在Zoom上聊天，讨论他们在索引交易所如何使用InfluxDB。

Caitlin： 请告诉我们一些关于您自己和您在索引交易所职业生涯的信息。

David： 我在索引交易所工作了超过八年，目前是一名运维工程师。在我的职业生涯中，我做了大量的DevOps、敏捷和站点可靠性工程。在这段时间里，我遇到了各种用于各种目的的工具。最近，我专注于监控索引交易所收集的基础设施（应用程序和服务器）数据。

成立于2001年的多伦多，索引交易所现已发展成为世界上最大的独立广告市场之一。本质上，我们是一家以工程为首选的公司，致力于民主化数字广告，让创作者、讲述者和新闻室能够与世界分享他们的内容和服务。我们通过促进在线广告的展示来实现这一点。查看我们的网站以了解更多信息。

例如，当我们中的任何一个人访问一个网站时，页面上通常会有顶部或侧边的横幅广告。对于每次页面加载，都会有一个寻找要放置的广告的请求。它们可能来自我们的平台；对于每次广告请求，都会有一个自动拍卖，通常称为实时竞价。我们询问我们的广告供应商是否想要对这个请求进行投标。我们收集任何请求的投标——最高出价者获胜，他们的广告将被放置在网站上。只要有广告投标的拍卖，就会有大量的数据流入和流出。其中一些数据包括

• 投标金额
• 投标获胜者
• 供应商名称
• 广告放置网站的URL
• 整个广告拍卖/投标过程的持续时间
• 是否有错误

Caitlin： 索引交易所的监控是如何随着时间演变的？

大卫：我们并非总是拥有监控工具；之前，我们主要依赖电子邮件警报。索引交易所决定退后一步，战略性地重新思考我们的监控方法。我们发现，在做出进一步改变之前，我们需要全面地审视我们的监控解决方案。我们最初使用了一些开源工具。

我们最初实施了Zabbix，它为我们提供了我们所寻求的大部分功能。我们能够从我们的服务、网络设备和服务器中获取指标。团队能够使用Zabbix设置警报。随着这次转型，索引交易所开始探索包括Docker和Kubernetes在内的其他技术，用于我们的微服务。随着时间的推移，很明显Zabbix已不足以满足需求；Zabbix无法支持所需粒度的指标收集；它并不是收集Kubernetes微服务指标的正确工具。

我们开始探索其他选项，并开始更多地了解时间序列数据库。一旦我们了解了TSDB的基础知识，我们就开始探索我们可用的选项，包括：OpenTSDB、Apache Cassandra、Prometheus和InfluxDB。我们最终选择了InfluxDB，这个专门构建的时间序列数据库，因为它最适合长期存储指标。

随着索引交易所的团队开始更多地使用微服务和容器，很明显Zabbix不是一个足够的监控工具。Zabbix的设计是每个指标都与一个物理设备相关联，但这与Kubernetes不兼容。在使用容器时，很难预测哪个容器会一直运行。我们开始采用Prometheus，尽管我们发现它很容易设置和部署，但我们使用InfluxDB存储任何超过24小时的指标。我们从Prometheus设置了一个到InfluxDB的远程存储系统——这样，Prometheus和K8s只存储24小时内的容器指标。这是我们支持Kubernetes中的微服务的方法。

在使用TICK Stack之前，我们还使用MySQL数据库来支持Zabbix的存储需求。我们意识到这超出了我们的需求。对于我们想要用Zabbix完成的事情来说，这太多了——这是我们发现InfluxDB的大约时间。我们很快开始比Zabbix更喜欢它，因为我们不再需要处理MySQL了！与Zabbix的等效输入、处理和聚合插件以及输出插件相比，我们非常喜欢所有的Telegraf插件。它远远没有Telegraf灵活或有用。

“我最近一直在使用Telegraf，我确实看到了服务器代理的强大和灵活性。现在我们可以玩转很多不同的输入插件和输出插件，而无需自己制作。” 大卫·科，DevOps工程师，索引交易所

凯特林： 你们为什么选择了InfluxData的InfluxDB平台？

大卫：我们团队中有人关注监控趋势和现代工具和堆栈；他们开始注意到的一个常见流行话题是时间序列数据库。随着近年来它们变得越来越流行，这位团队成员开始注意。他们开始询问是否有人了解TSDB。一旦他们了解了时间序列数据库，这是增长最快的数据库类别之一，他们开始探索可用的选项。

我们喜欢InfluxDB有一个开源版本和企业版本，这意味着如果需要的话，可以得到支持。我们几年前开始使用InfluxDB OSS，最近开始使用InfluxDB Enterprise。

凯特林： 索引交易所如何使用InfluxDB？

大卫：索引交换操作团队期望我们为其他工程和产品团队采用DevOps实践奠定基础。在监控InfluxDB方面，我们团队设置了一个用于存储实时数据的InfluxDB集群。我们还使用了Kapacitor来设置关于存储在InfluxDB集群中的数据的警报。

我们开发了文档、指南和培训视频，以帮助团队理解InfluxDB平台。我们还设有开放的Slack频道，用于任何问题、反馈等。我们旨在帮助团队理解工具并改进他们可用的工具。团队可以ping我们以获取设置警报和自动化指标收集的帮助——我们随时提供帮助！我们约30人的团队支持整个工程团队；操作团队主要位于加拿大多伦多，工程团队位于多伦多、蒙特利尔和基奇纳-滑铁卢。我们还在波士顿、旧金山、伦敦、巴黎、悉尼和其他地方设有非工程团队成员。

产品工程团队的需求影响着我们的项目。然而，最近，我们开始与业务商业方面的团队成员合作。我们想了解他们的分析师如何使用数据，并更好地了解他们的需求和需求。我们的分析师有时对理解CPU使用率或同一数据中心同一机架上的特定服务器感兴趣。分析团队可能需要理解几个月或几年的历史数据。大量此类数据目前存储在InfluxDB中；我们使用Telegraf代理收集包括CPU内存在内的指标。Telegraf正在收集包括CPU、磁盘和其他数据在内的基本服务器指标。我们使用Python脚本来将我们的数据写入InfluxDB。

我们仍在使用Prometheus；我们还没有完全淘汰它。这将需要一些时间。我们最终希望使用TICK Stack中的所有功能。我们越来越熟悉TICK脚本。不久我们将开始学习Flux并计划升级到InfluxDB 2.0。它将比依赖Prometheus更有用。

除了收集每次广告出价/拍卖的指标外，我们还对了解其基础设施的状态感兴趣。有时这就像是否该组件处于活动状态并正常工作一样基本。对Index Exchange来说，了解诸如“完成此任务需要多长时间”之类的具体信息也很重要。另一个常见的问题是：在过去10分钟内，特定数据中心发生的特定错误发生了多少次。我们喜欢了解在过去的10分钟内，从给定数据中心发生的错误数量和错误类型。能够量化过去10分钟内从给定数据中心发生的错误数量，有助于我们的团队理解和解决这些问题。通过使用InfluxDB的数据结构，每个数据中心都是一个标签。错误类型也是一个标签。InfluxDB每秒大约处理60,000个指标！

索引交换的数据中心是裸机环境；我们基本上有自己的私有云解决方案。我们对我们的内部基础设施解决方案感到自豪。它为我们提供了所需的自主权，这对于数据安全尤其重要。我们记录了每一笔广告交易，而不仅仅是赢得广告出价的广告数据——还有关于每次出价的数据，这导致了数TB的数据被使用和处理。使用和处理的数据量可能轻易达到数TB，甚至可能达到PB。我是在概括，但几年前有一个关于一年内处理的广告流量数据的演示，其数量超过了银河系的星星数量。

• 此架构图仅代表我们两个远程数据中心。
• Index Exchange在全球范围内拥有八个数据中心。
• 它们的数据流都是一样的。

Caitlin: 请告诉我们关于Index Exchange的数据可视化和警报。

David: 我们仍在确定最适合我们数据可视化的方法。我们正在有限范围内使用Chronograf和Grafana。由于我们使用了大量的TICK脚本，使用Chronograf探索数据非常棒。使用Chronograf来可视化和分析已经存储在InfluxDB中的数据非常酷。我们还在Grafana中有很多图表供团队使用。所以目前，Chronograf和Grafana的组合对我们来说效果很好。

我们目前使用Kapacitor进行警报和数据计算。随着我们对TICK脚本的了解越来越多，我们开始探索一些你不希望用连续查询完成的更复杂任务。我们仍在确定最佳实践，但我们想确保我们不仅仅是在用传统DevOps的方式做事！

我们还使用Slack和Alerta。我们所有的TICK脚本都传送到Alerta，然后到Slack，因为我们希望从多个来源获得各个层面正在进行的所有警报的全景视图。

向团队提供我们目前拥有的数据可视化，以便了解我们的位置以及如何更好地优化我们的运营，这是一件非常好的事情。这些图表也揭示了我们的数据中的空白和我们可以解决的问题点。

Caitlin: Index Exchange的DevOps团队接下来有什么计划？

David: 我们希望探索新技术和方法，例如我们正在学习更多关于Google Site Reliability Engineering的实践。他们的一种技术是创建服务级别指标（SLI）和服务级别目标（SLO）——我们希望将这些方法整合到我们的InfluxDB实践中。SLI简单地通知团队他们的服务表现如何。SLI通常是良好事件和总事件的比率。通过将无错误的请求数量除以总请求数量，组织可以确定其SLI。SLO是你希望该百分比保持在其内的阈值。Index Exchange计算这些SLI并将它们存储在InfluxDB中。我们通过设置使用TICK脚本的警报来创建SLO。

随着时间的推移，我们希望微调我们的警报。目前，我们只在CPU使用等指标上设置了基本的警报。如果特定组数据中心的CPU使用移动平均数高于某个阈值，我们会收到通知。这类警报意味着我们的广告服务器无法足够有效地处理拍卖，这将影响收入。在未来，我们希望有更高级的警报。例如，广告拍卖的平均时间约为100毫秒——如果我们注意到它们在150毫秒时超时，我们希望能够主动修复延迟的根本原因。

我们对学习InfluxDB 2.0的相关知识很感兴趣，并正在考虑升级。参加2020年北美InfluxDays活动InfluxDays North America 2020真是太棒了，我在那里学习了新的概念，包括InfluxDB IOx。它作为InfluxDB 2.0的后台听起来非常有兴趣！我们已经遇到了高基数问题，因此我想看看InfluxData是如何应对非常高的基数这一常见问题的。我当然很期待看到InfluxDB的未来，以及我们如何在Index Exchange实施最新的InfluxDB版本！

凯特林： 你有没有想分享的InfluxDB技巧和窍门？

大卫：我们最近在InfluxDB集群中遇到了级联故障，因为我们把所有其他数据库的副本因子都设置为三个，但实际上我们的节点大小是四个。当我们开始向InfluxDB中投入更多数据时，一切正常。然而，我们最终向集群中推入足够的数据，导致级联故障。我们对InfluxDB不够熟悉，以至于不明白发生了什么。我们与InfluxData的支持团队进行了沟通，并迅速了解到副本因子实际上比我们想象的更重要，而建议的副本因子数字是有其优化原因的。如果你是第一次配置InfluxDB集群，我强烈建议尽可能多地利用InfluxData的支持团队！是的，文档中有很多内容，但有些信息可能不够清晰，也可能会有错误的假设。最好让InfluxData的支持工程师首先帮助你了解这些。

我还建议阅读InfluxData的文档，了解他们的建议，并考虑对你和组织最有利的选择。在规划容量、设计数据模式时，你应该考虑InfluxDB的最佳实践，同时考虑对你和组织的要求最合适的方案。

凯特林： InfluxDB是如何影响你的职业生涯的？

大卫：在实施过程中，我越来越多地了解了DevOps实践，特别是在监控和理解基础设施指标方面。虽然我之前已经了解时间戳数据的概念，但没有什么比推出InfluxDB更能让我感到舒适和熟悉了！

如果你想分享你的InfluxDB故事，请点击这里。