从 Graphite 迁移到 InfluxDB

以下是网络研讨会“从 Graphite 迁移到 InfluxDB”的未编辑文本。这是提供给那些更喜欢阅读而不是观看网络研讨会的人。请注意，文本是原始的。我们对转录错误表示歉意。

演讲者
• Chris Churilo：InfluxData 产品营销总监
• Jack Zampolin：InfluxData 开发者倡导者

Chris Churilo 00:03 而且，Jack，在我们准备的时候，这里我只想和你分享一个来自 Sean Whitney 的便条，他是今天的参与者之一。他说，“感谢邀请。时间再合适不过了。”所以我真的很高兴，Sean。在我们开始之前，我想让你知道，Jack 已经做了很多这样的迁移。所以请在 Q&A 面板中提出很多问题，这样其他人也可以看到。你还可以继续使用聊天面板。我们将确保解决所有这些问题。但我们想确保这些网络研讨会对每个人都尽可能有用。就像我提到的，我们已经录制了它们，所以如果你需要的话，可以再次查看。好的。我们可能可以在这里安定下来，开始我们的网络研讨会。所以今天，我们的网络研讨会全部关于将您的 Graphite 数据库迁移到 InfluxDB 解决方案。我们今天有 Jack 做演讲。Jack 拿着球，所以我将提前让你再自我介绍一次，然后开始。

杰克·赞波林 01:13 太棒了。早上好，大家。我叫杰克·赞波林。我在InfluxData担任开发者倡导者，今天我们将讨论从Graphite迁移到Influx的过程。所以如果你在WebEx活动中心点击Graphite迁移标签页，你应该能看到幻灯片，那将是跟进的最佳位置。我还会负责问答以及聊天频道。所以如果你有任何问题，请随时在问答或聊天中提出，我会尽力回答。那么，让我们开始吧。今天我们将讨论从Graphite迁移到Influx。这个话题涉及很多内容，但首先，我们可能想要谈谈为什么我们要进行这样的转换。然后，我们将讨论不同的迁移策略。我和我们合作过的不同公司可能进行了20次这样的迁移。我这里有一些模式和不同的做法，我们将讨论这些。然后我很乐意回答任何问题。这个话题通常会吸引正在进行Graphite迁移或考虑迁移的人，所以如果你有一些针对你用例的具体问题，请留到结尾，我会很高兴回答它们。好吧。

杰克·赞波林 02:53 首先，什么是Graphite？很多人认为Graphite是一个数据库，但那被称为Whisper或任何其他东西，一个网络仪表板，这些是Graphite生态系统的一部分。但Graphite本身，我喜欢将其视为一种描述时间序列数据的协议。因此，它在2006年的Orbitz设计，2008年开源，现在它无处不在。这个协议是周期分隔的序列键，具有单独的值和时间戳。现在，这是RRDtool发起的架构。然后，它也是设计关系数据库中的时间序列数据库的一种简单方法。如果你想在一个关系数据库中做时间序列，你将需要在时间上建立索引，这是非常昂贵的。所以你想使你的表尽可能小。最小的表可能是一个序列键，我们也在上面建立索引，一个时间戳，我们也在上面建立索引，然后一个没有索引的值。所以这就是你在关系数据库中构建时间序列数据库的方式，Graphite也是这样。那么它是什么？它主要用来做什么？主机级别监控和应用程序监控。因为它是一种非常简单的数据格式，所以很容易存储生成时间序列和绘制结果的任何所需的元数据。因此，你可以在这里评分应用程序性能指标。你可以在这里存储主机级别的指标，传感器数据。人们用Graphite做各种各样的事情。所以除了协议和数据库，它还是一个工具生态系统。我也会把StatsD包括在内。

杰克·赞波林 04:56 那么，Influx是什么？它是一个时间序列数据库，但Influx也是InfluxData公司开发的一套工具的一部分，用于处理时间序列数据。所以，在可视化方面，我们有一个叫做Chronograf的工具。我们的大部分用户，我可以说，可能大多数Graphite用户，使用Grafana作为他们的可视化工具，但我们也有自己的产品。在收集方面，我们有Telegraf。在Graphite生态系统中，类似的工具可能是Diamond收集器或CollectD。这些都是常见的收集器。然后是警报或ETL，我们为此有Kapacitor。在Graphite生态系统中，你会看到Nagios或他们刚刚发布的新的Grafana警报。我们是作为任何时间序列的监控工具构建的，所以对于DevOps、金融领域。你可以想想，股市每天产生的大量时间序列数据。物联网应用程序，所以如果你有一堆传感器，并且它们正在回传数据，这些都是时间序列。然后是应用程序性能监控。

杰克·赞波林 06:09 那么，有哪些常见问题导致人们选择Graphite迁移？我应该购买或配置一台非常大的机器来运行Graphite集群并正确扩展它吗？这种策略是否可持续或与我的预期扩展需求具有成本效益？这是许多人遇到的一个问题。Graphite对硬件的要求非常高，我们稍后会具体讨论这个问题。但人们通常会达到一个点，他们的基础设施无法再支持他们不断增长的应用程序，他们需要扩展它。在那个时刻，他们会退后一步说：“Graphite现在对我们来说是正确的工具吗？”如果我要更换数据存储，这个迁移需要多少工作量？也就是说，迁移后端需要多少工作量？我的意思是，如果你正在从类似基于JSON的存储系统迁移到Oracle或相反，这里有很多摩擦，那么不同时间序列数据库之间，尤其是Influx和Graphite之间，有多少摩擦呢？

杰克·赞波林 07:17 我能否将当前系统的数据迁移到新的数据库中？那么，我能否带着我的数据迁移，还是必须将其丢弃？我能否提供一个兼容API的解决方案供客户使用？那么，我是否需要重写应用程序以发出不同类型的指标？更换数据库能否在硬件上节省我资金？如果你现在使用Graphite，你目前花费了大量资金在硬件上。然后，我能否继续使用Grafana或Graphite仪表板进行可视化？这些都是人们围绕Graphite迁移时常见的疑问。我们将具体讨论这些问题的每个方面。另外，我想重申，如果任何人有任何问题，请在问答或聊天中提出，我将在演示过程中回答它们。

杰克·赞波林 08:14 那么，推动人们迁移的主要石墨烯痛点是什么？一个是石墨烯的集群架构。所以这张图，如果你在谷歌上搜索石墨烯集群——我会把链接发到聊天中——你就会看到这个。有1、2、3、4、5、6、7个不同的进程用于运行标准石墨烯安装。单个Whisper守护进程只能真正处理大约70,000个系列和非常少量的写入指标。所以如果你在任意规模上运行石墨烯，你将需要学习如何进行集群，围绕这个构建某种自动化，这样你就可以上下扩展集群。石墨烯使用一致性哈希来分割数据，所以每次你更改集群配置，你都需要重新哈希。所以正如你所看到的，石墨烯集群架构存在许多问题，这是许多人的一大痛点。

杰克·赞波林 09:25 另一个问题是硬件成本。石墨烯需要昂贵的硬件来运行。你需要使用具有非常高的IOPS的SSD，通常大约20,000。Influx使用的IOPS明显较少，虽然我们推荐使用SSD，但你可以在旋转磁盘上运行数据库。这会导致大约50%的性能下降。但这是许多人愿意为Influx支付的价格，因为我们确实有如此出色的性能。如果我们看看这些最近的基准测试，2016年9月，贾森·迪克森在石墨烯发布了一个基准测试。我会在聊天中发那个链接。他们使用的机器是i2.4xlarge。这是一台16 CPU、122GB RAM的机器，他们有一些配置了IOPS的EBS卷。他们请求了最大IOPS，所以是20,000。这台机器每月的成本大约是2,500美元，他们获得的是大约每秒60,000个指标的写入吞吐量，跨越了600,000个不同的系列。你可以去看看那些基准测试。

杰克·赞波林 10:53 Influx，我们最近发布的基准测试是对OpenTSDB的。我还会把链接发到聊天中。你预计Influx的写入吞吐量会更高，确实如此。我们看到了大约每秒180,000个指标的吞吐量，但这是在更少的系列上。所以我会说这两个测试的性能大致相当，但你看到了硬件上巨大的差异。我们使用了两个4xlarge机器，每个机器有四个CPU、16GB内存。测试是在实例SSD上进行的。所以我们甚至不需要配置IOPS，没有这些。那里的每月机器成本大约是350美元。所以你可以看到在那里运行你的基础设施的成本差异非常大，这对大多数运行石墨烯的人来说是一个主要的痛点。

杰克·赞波林 12:02 然后还有数据模型。我们之前谈到了为什么石墨烯的数据模型是这样的。这是时间序列数据库长期以来一直被设计的方式。那么这个数据模型的弱点是什么？没有标签。你所拥有的以周期分隔的字符串包含元数据，你可以把它们看作标签。但这需要使用正则表达式来查询，无论你使用哪种后端，这都将非常昂贵。除了没有标签外，你实际上只能得到一个测量值或你使用的系列键的一个值，这并不好。这会导致重复数据的过度重传。如果我们看那个例子，有三个石墨烯点。我们有一个环境、主机名，然后可能是一些其他东西——那个主机名在三个周期分隔的部分中。然后是CPU，这是我们正在测量的，然后基本上我们可以称之为Influx中的字段值，用户、优先级和系统。还有另一个不好的地方是，在Whisper中，每个键都存储在不同的文件中，所以你会到达这样一个点，你必须扩展你的集群来获得更多的打开文件句柄。这不是大多数人希望的情况。这又把你带回到了我们之前谈到的集群架构。

杰克·赞波林 13:33 然后如果我们将这个数据模型与行协议进行对比，行协议数据模型是测量逗号标签集空格字段集空格时间戳。如果你注意到了标签集和字段集，你可以在任何给定的写入操作上拥有任意多的标签和字段。标签和字段之间的区别是标签是索引的，字段存储在磁盘上。并且 Influx 允许多个字段每个点。如果你看到下面的示例点，它相当于上一页最后三个点。我已经将其转换为 Influx。你可以看到字符更少，如果你有 maybe 10 个这样的（比如运行 Sensu 系统检查插件的情况），它们都会压缩成一个指标。这在网络传输以及存储方面都是一项相当大的节省，所以非常不错。你看这里，那是测量 CPU 然后是一系列标签，然后我们有三个字段，里面包含了所有这些数据。这导致了数据传输更加充分。

杰克·赞波林 14:48 所以现在我们知道了人们为什么要从 Graphite 转变，并经历那个痛苦的数据迁移过程，他们通常会选择哪些不同的路径？我看到人们通常走三条不同的路径。第一条是只需用 InfluxDB 替换你的 Graphite 后端。这是一种影响最小的迁移。那么它的优势在哪里？不需要任何基础设施的改变。你不需要改变你收集数据的地方。任何使用 StatsD 或 Graphite 协议进行仪表化的应用程序都不需要重构。没有新的协议或代码让你的开发者去学习。这仅仅是在改变你的数据存储。

[沉默]

杰克·赞波林 15:44 那里的缺点是你没有利用 InfluxDB 的高级功能。在 Influx 中，标签是一个相当关键的功能，在查询语言中，你将大量使用标签。如果你只是使用 Influx 作为 Graphite 后端，你就无法利用这些功能。另一个主要缺点是，这条路径的工具主要是社区支持的，维护工作不连续。例如——我们将在下一页看到——有一个适配器允许你为 Influx 编写 Graphite 查询。这本质上是在与框架作斗争，如果你在 Rails 或其他大型框架中工作过，你就知道与框架作斗争是什么感觉。这不是一件有趣的事情。此外，它向 Influx 写入一个非常非优化的模式。它需要正则表达式才能在环境中进行有效的查询。这导致查询速度变慢，内存使用率更高，写入速度更慢。

杰克·赞波林 16:44 所以如果你正在采取这条迁移路径，你想要哪些工具？InfluxDB 提供了一个 Graphite 服务。这个服务只是接收 Graphite 点并将其直接写入数据库。这样就可以将 Influx 作为 Whisper 的直接一对一替代品使用。你甚至不需要改变客户端的数据发射方式。我们的数据收集代理 Telegraf 也提供了一个 Graphite 服务。所以如果你需要从一个 VPC 转发数据到另一个 VPC，你可以使用 Telegraf Graphite 服务来处理这件事，或者处理你那里的其他 Graphite 基础设施。我还提到了之前的查询适配器，这里有它的链接。我见过一些客户使用过它。它维护得不是很好，并且会导致写入一些非常不规范的模式。所以这是一个问题，一个快速的投票，这里有人考虑这种只替换后端类型的迁移吗？我会暂停一下，让你有时间回答。所以肖恩说他正在考虑为某些服务进行这种类型的迁移。

杰克·赞波林 18:06 这就引出了我们接下来要讨论的迁移类型，可以称作分阶段迁移。第一个案例是许多人都不愿意做的事情。我看到过一两个客户实施了这种方案，但结果并不理想。他们最终不得不进行分阶段迁移，并丢弃了他们构建的大量工具。那么，如何实现分阶段迁移呢？这里的优点是，它不需要对现有的基础设施进行任何立即的更改。您在StatsD或Graphite中配置的所有应用程序都不需要重构。开发人员可以方便地学习新的协议和代码。有许多维护良好的工具可供使用，包括我们编写和维护的工具，以帮助实现这一过渡。您将获得成本节省的优势。在数据库层，系统维护的工作量会显著减少。我们之前提到了集群，这使您能够立即利用Influx的多维数据结构中的标签功能，满足您新的用例需求。并且它还允许您逐渐过渡到旧数据。

杰克·赞波林 19:27 那么，这种方法的缺点是什么呢？遗留应用程序可能需要进行重构。如果它们以Graphite协议的形式发布度量标准，如果您完全切换到行协议，您可能最终希望——您可能希望最终将所有应用程序都切换到行协议。如果您有使用Graphite协议的遗留应用程序，那么这些应用程序将需要重构。您首先要做的事情之一就是需要使用新的收集器更新基础设施。如果您使用CollectD，从Graphite迁移到Influx进行主机级度量指标的最大优势是从CollectD切换到Telegraf，我们为Telegraf提供了一系列的仪表板。Telegraf比CollectD占用更低的内存和CPU。这里有众多优势，但如果您没有完全配置的部署系统，切换该基础设施可能比较困难。另一个缺点是您需要学习Influx查询语言。有许多工具可以做到这一点，如果您已经使用Grafana，Grafana还提供了Influx查询构建器，允许您完成这项工作。所以这不是一个大问题，但这些是这种迁移方式的缺点。

杰克·赞波林 20:49 那您会用什么工具来完成这个迁移呢？Telegraf 有很多工具可以完成这类迁移。Telegraf 是我们的数据收集器，我觉得它就像瑞士军刀或者多功能工具。如果您需要监控某个基础设施或从某个随机地方获取一些指标，Telegraf 可能会有一些东西可以帮助您。它可以无缝地收集来自您堆栈任何部分的系统级和应用级指标。所以，就系统指标而言，我们有标准的CPU和内存以及许多其他东西。然后在应用级指标方面，我们为数据库和队列等常见基础设施提供了插件。有一个StatsD服务器；它可以作为Influx指标的指标转发器。它能够解析Graphite的输出行协议，您也可以在InfluxDB上的Graphite服务中这样做。现有Telegraf插件可以高效地编写InfluxDB模式。这就是为什么在迁移时，切换到Telegraf是最大的胜利之一，因为如果您使用Sensu、CollectD或其他Graphite收集器，所有指标都存储在那里。将所有系统级指标从Graphite风格切换到Telegraf可以让您立即将所有系统指标转换为Influx风格。您将看到查询的便捷性提高，对基础设施的可见性增强，而且使用上的便捷性也是一个非常大的优势。

杰克·赞波林 22:38 在Telegraf部分下面，我解释了Graphite解析的工作原理。现在，深入探讨这一点超出了本次演示的范围，如果任何人对此Graphite解析有疑问，我鼓励您在结束时提出。但简而言之，它处理Graphite点。所以，正如我们所看到的，prod sequencer 142，ingen dot com，CPU user，然后是一个值和一个时间戳。这是我们之前查看的点，它输出行协议。为了做到这一点，它通过一个模板传递。您可以看到那个引号字符串是过滤器模板。所以，任何匹配prod dot star的Graphite指标，我们希望传递到以下模板中。它将那些小点分隔的各个部分取出来，您可以将它们命名为标签。所以对于prod在这三个主机字符串中，我们将其添加为标签。所以prod是我们的环境。然后sequencer 142，ingen dot com是我们的主机名。我们还从这里提取测量名称。所以我们看到CPU是我们的测量。然后我们的字段是一切在CPU之后，我们将它考虑为字段名。所以如果我们有三个点，user、nice和system，它们看起来都像这样，并且我们通过那个模板传递，它将输出以下行协议。我们看到CPU environment equals prod，host equals sequencer 142，ingen dot com。我们的user值、nice值和system值都在一个时间戳下。

杰克·赞波林 24:36 您也可以在StatsD点使用相同的模板格式，所以如果您有一些想要拆分的StatsD周期分隔字符串，我们也可以做到。如果您使用Datadog，Datadog有标签功能，所以您可能想导入在Datadog上使用的标签，然后也许还可以从您周期分隔的指标名称中解析一些额外的数据。所以无论您从哪种形式的Graphite或StatsD迁移，我们都可以使用这个工具来帮助您。这对于像肖恩的情况一样，那些分阶段的迁移非常出色，在您的全新项目中，您正在使用Influx上线，但您正在缓慢迁移现有的环境。那么在我们讨论替换您环境中所有Graphite指标之前，我们可以讨论一下目前正在经历或对这种分阶段迁移方法感兴趣的人吗？此外，如果您有任何问题，现在提问将是一个很好的时机。

杰克·赞波林 25:47 我们接下来要讨论的最后一类迁移是替换和替换，即替换您生态系统中所有Graphite指标。那么我们怎么做？它的优势和劣势是什么？优势在于您可以直接使用InfluxData TICK堆栈的最新功能，添加像Kapacitor这样的警报工具，或者使用Chronograf的新版本来编写Kapacitor警报，或者使用Telegraf插件的一些现成仪表板。这些都可以直接使用，无需任何额外配置。有许多维护良好的工具可以帮助您完成这个过渡。我们之前提到的一切，以及一些其他的工具。因此，您将获得成本节省。您将减少必须对系统进行的维护工作。您可以在Influx中利用多维数据结构的标签。您还可以提高数据分辨率，非常容易地将更多数据写入系统。很多人使用Graphite，因为他们的服务器负载过高。与重新散列或通过添加更多硬件来增长集群相比，他们会降低数据分辨率。我不需要每10秒的分辨率数据。我只需要每分钟或每5分钟的分辨率数据。转向Influx将允许您恢复这种分辨率并非常容易地提高系统的负载。单个服务器，Influx的开源版本可以处理每秒数十万，甚至接近一百万的写入。因此，它非常高效。

杰克·赞波林 27:43 那么，这种方法的劣势是什么？它可能需要对客户端指标进行重大更改。如果您没有控制客户端，或者也许有些客户端由不同的部门控制，可能很难要求他们更改。在这种情况下，您可能需要回顾分阶段迁移并考虑一些这些工具。它要求开发人员立即学习新工具。所以在分阶段迁移的情况下，人们可以慢慢地进入新的Influx系统，并在将其切换之前与几个项目一起工作。它还需要立即更改基础设施。所以如果您注意到，对于较小的、更敏捷的软件团队，这些要求并不是劣势。所以如果您在一个可以控制客户端、您的开发人员对使用新工具感到兴奋，并且您可以轻松更改您的基础设施或类似现代DevOps环境（如Ansible、Kubernetes等）的地方，这些劣势就会消失，完全替换实际上是更好的。

杰克·赞波林 29:10 那么你会使用哪些我们还没有讨论过的工具呢？其中一个就是我们的API客户端库。我会在文档中放一个链接。我们有Go、C#、Java、PHP、Ruby、Python、Node、Rails，以及一些社区贡献的库。这些客户端库将允许您将应用程序的指标直接发送到数据库。您可以为Telegraf编写插件。比如说，您有一个需要提取的自定义应用程序。它从状态端点发出一些JSON。Telegraf作为瑞士军刀，可能已经有了一个可以帮助您的插件，但如果没有，编写自己的Telegraf插件非常简单。这是我找到的最好的Go项目入门方式。当我刚开始时，我编写了一些Telegraf插件来学习Go。它是接口和其他概念的很好的介绍。一旦您编写了它，您就不再需要担心了。我们还有一些社区工具。我们的开发者维护了一个名为Awesome InfluxDB的仓库，这是一个列出与Influx在不同环境中工作的酷炫社区编写工具的列表。所以如果您正在寻找与某个随机基础设施一起工作，并且没有立即找到，请在Awesome InfluxDB上查看，看看是否有人为它编写了东西。Mark也经常更新那个。

杰克·赞波林 30:57 所以，还有一些事情没有完全融入到那个叙述中，那就是其他数据源和工具。比如说，您有一堆传感器或一些特殊需求，我们如何处理这些呢？所以其他工具，如果您正在连接到现有环境的队列系统，Telegraf既是消费者又是生产者。这意味着您不需要为这些指标数据编写任何消费者或生产者程序。您可以直接通过队列传递，让Telegraf在两端处理它。我们支持的队列系统有Kafka、RabbitMQ AMQP、NSQ、MQTT和NATS。我相信我们还有一个Kinesis输出插件。所以是一个Kinesis的生产者，但不是消费者。特别是在高容量使用案例中，许多客户发现这非常实用，并且节省了他们大量的时间。

杰克·赞波林 32:03 所以我们还有——现在我们正在转换话题，我们正在谈论设备轮询。我们有Telegraf SNMP插件。这是一个性能良好的SNMP轮询程序。它在许多大型电信公司中大规模使用。这里的规模是指超过10,000个设备。这是一项非常有效的工具。还有另一个我觉得之前没有提到的工具是Whisper-migrator。如果您有现有的Whisper数据库并想要迁移数据，您可以使用Whisper-migrator来完成。艾略特刚刚问了一个问题。如果我们愿意尝试新的工具，但我们一直使用Logstash进行日志分析，您的建议是什么？所以如果您想使用InfluxDB进行日志分析，我们确实有一些东西。一个是Telegraf logparser。您可以使用与Logstash相同的groks和标签，但是您需要解析其中的键值对并将它们插入到Influx中。所以这是其中一种方法。我们也在研究更多支持将日志迁移到Influx的方法。这回答了您的问题吗，艾略特？太棒了。所以这就是我的演讲结束，现在是提问时间。请将问题发到问答或聊天中，我想我会在这里待到大约11点。

克里斯·丘里洛 33:49 谢谢，杰克。正如您提到的，请随时在问答中提出您的问题，或者聊天窗口也可以。我们还会在这里等待几分钟，等待您的问题。如我之前提到的，这是录音。所以我会今天结束时发布这个，这样您可以再次查看。