网络研讨会亮点：提高临床数据准确性 - 如何使用 Node.js、AWS 和 InfluxDB 简化数据管道

作者：Bria Jones / 产品，用例
2022年8月26日

网络研讨会亮点

Pinnacle 21概述

解决方案的需求

替换要求

• 易于实施
• 能够捕获日志和指标
• 必须是一个外部托管工具
• 收集和监控APM指标

他们需要将数据托管在其他地方以确保安全和免受篡改，但不想管理另一个监控解决方案的基础设施。这一需求将帮助他们遵守CDISC建立的审计和合规要求。

为什么选择Grafana、InfluxDB和Telegraf？

Josh最初考虑InfluxDB和Grafana作为他们DevOps监控需求的潜在替代方案，因为它们具有成本效益——即使与其他供应商搭配进行日志分析，也比他们之前的方法便宜得多。由于InfluxDB的基于使用量的计划已经实施，他们评估了他们选择发送到Telegraf的每个指标，以决定什么值得付费。Pinnacle 21的另一个关键组件是Telegraf本身。对于Josh和他的团队来说，Telegraf是一个令人印象深刻且功能强大的数据摄取工具，它开箱即用的插件比他们现有的代理更多。

Pinnacle 21的客户位于AWS内部，属于他们自己的EC2安全组，并且每个客户都有两个实例——一个Web服务器和一个应用服务器。Telegraf运行在这两个实例上，将指标发布到内部的InfluxDB实例以及到GCP托管的InfluxDB云实例。Pinnacle团队为每种类型的服务器创建了一个基于策略文件的流程，该流程定义了要通过Telegraf运行哪些自动化以及要监控的内容。

Pinnacle 21的安装很简单，因为Telegraf有一个目录，允许他们编写单个插件配置。这在通过Chef自动化Telegraf安装时很有用，因为他们根据服务器有不同的策略和角色。Josh和他的团队选择让每个插件在Telegraf目录中写入配置，然后建立一个节点属性列表，列出Telegraf应该监控哪些插件。这使他们能够为每个服务器上的每个Telegraf输入定制配置。

Josh的建议：将节点属性作为散列而不是数组结构，因为数组将被深度合并并且不太容易关闭。将节点作为散列堆叠将允许在非常细粒度的级别上更好地控制要监控的内容。

然后Josh决定在Chef中设置一个初始的基线监控集，发现其中一些输入很有价值但并不值得花费。解决方案？Telegraf在每个输出插件中都有一个名为“Tag Pass”的过滤选项。团队配置了输出插件，使用特定的目的地标签，并从特定服务器排除某些标签。通过在Telegraf输入上放置标签，他们可以选择将哪些指标发送到哪些InfluxDB服务器。这也使团队能够收集特定输入的更高粒度指标，并调整他们正在收集的内容、收集频率以及发送到的位置，以更好地管理成本。

关键绩效指标和APM

下一个关键行动项是查看他们服务器的一些关键性能指标。因为他们之前使用了Datadog，所以他们已经以JSON格式编写了NGINX日志，但Josh建议解析这些日志。通过解析他们的日志，Pinnacle 21的团队能够将这些日志转换为指标，并存储在InfluxDB中。

Pinnacle 21的客户使用IBM Aspera上传大型数据集进行验证；他们已经配置了Aspera将日志写入特定路径，Telegraf可以从该路径收集使用Tail Telegraf插件。这使得团队能够生成显示特定KPI的图表——平均客户数据集大小、客户数据上传的速度、正在进行的上传数量等，这对Pinnacle 21的扩展团队能够理解数据的影响非常有帮助。

由于P21E是一个Java应用程序，他们需要使用Java代理来获取APM指标。团队选择了InspectIT Ocelot来收集JVM指标，并使用机器上的Telegraf监听器原生发布这些指标。这使得他们的工程师可以编写代码捕获单个事件，如函数运行时间和其他指标，以监控应用程序的性能并优化软件。

这对于Pinnacle 21来说非常重要，因为某些数据集可能需要数小时甚至数天来验证。以COVID-19数据集为例——验证数据所需时间越长，获得新治疗方案批准的时间也越长。通过让工程师能够快速评估和优化应用程序的性能，最终可以加快验证过程。

HTTP监控替代品

最初，团队考虑将Telegraf作为他们HTTP监控系统的替代品，虽然Telegraf可以完成这项工作，但最终他们选择了带有Node.js应用程序的AWS Lambda实例。Node对他们来说是正确的选择，因为它的基于事件的基础架构。Josh使用Node.js客户端将指标直接发布到InfluxDB，并从多个区域触发每分钟执行的AWS CloudWatch事件。他们使用Grafana进行警报，创建热图，并可视化来自全球的响应时间、故障和错误代码等数据。

技巧和窍门

Josh为那些开始使用InfluxDB进行监控之旅的人提供了一些有用的技巧和窍门。首先，他建议从评估需求和确定总体目标开始。由于Telegraf功能强大，很容易迷失在各种插件中。Josh指出，向多个InfluxDB实例发送数据是一个强大的冗余选项，也是当其中一个实例出现问题时备份的好选项。接下来，他强调使用使用仪表板来衡量使用情况和管理成本的重要性。他建议缓慢添加指标以评估它们对使用情况的影响，特别是如果有一大批服务器。最后，他推荐使用Flux，因为它是一种强大且功能齐全的语言。

Josh提到他将会检查InfluxDB大学来提高他的Flux技能，如果你对学习更多关于Flux或其他InfluxDB主题感兴趣，从这里开始学习！

问答

问题： 贵组织是否有云优先的倡议？

回答：在Pinnacle 21部门，我们非常重视云优先，这主要是一种创业心态，我认为创始人需要托管这种软件，而CTO最后一件需要做的事情就是管理更多的基础设施来维持业务的运行。我真的很喜欢云优先，所以我在很多事情上坚持这种方法，比如我们推出的InfluxDB、日志监控解决方案。但我也并不害怕内部运行事物。有时我认为两种方式都有其好处。所以这取决于团队规模和资源。我们目前正在招聘，随着我们获得更多的DevOps工程师，我们将有更大的能力支持内部托管的事物。

问题： 你提到了一些你希望做的事情——关于你使用InfluxDB收集的指标，你清单上的首要任务是什么？

回答：我非常乐意开始用Flux查询替换我们现有的部分InfluxQL查询，并改进一些我们现有的仪表盘。我认为我们可以从一些比较信息中受益，比如我们可以比较某个客户或性能周与上周的数据。我认为这里确实有很强的力量。我喜欢改进HTTP监控方面的一些事情。现在它很好，但我认为它还可以更好，更多的是在Grafana方面，而不是在InfluxDB方面。我一直在尝试使用Grafana OnCall，对此非常满意。我们还没有在生产中使用它，但我们已经在开发中使用它了，我想把所有东西都切换到那个平台上。它允许你直接在Slack中确认警报。它允许你更好地配置停机时间。这是我们现有解决方案的一个挑战之一，如果我们知道我们正在对特定实例进行维护，由于难以静音这些警报或安排停机时间，我们会对该实例收到大量的警报。因此，Grafana OnCall使这变得更简单，并且仍然与InfluxQL或Flux兼容。

问题： 我们的社区喜欢Grafana，但你有没有看过InfluxDB中的可视化工具？

回答：是的。当我在构建新的查询时，我会使用InfluxDB Cloud UI，并在那里编写查询，可视化它们，确保它们是我想要的样子。当我查看使用仪表盘时，我会使用InfluxDB Cloud UI。我认为其中的一些可视化还不够强大，只是因为Grafana在InfluxDB Cloud上已经领先了一步。但这是一个很棒的系统。它已经比我所见到的Datadog的一些功能更强大。例如，你不仅有折线图这样的可视化，还有不同类型的可视化。所以，是的，我们在InfluxDB Cloud UI本身就有一些仪表盘。

了解更多关于Pinnacle 21如何使用InfluxDB的信息，请点击这里。