Telegraf、InfluxDB 和 Grafana 的基础设施监控基础
作者：Jay Clifford / 产品
2023年8月29日
导航至
今年早些时候，我有幸在北美开源峰会上发表了演讲。在选择主题时，我觉得是时候回到我们的根源，讨论最初将 InfluxDB 推上地图的主题：基础设施监控。
特别令人兴奋的是，有机会向开源社区展示 InfluxDB 3.0 的新功能，并解释它们对基础设施监控用例未来意义的重要性。
本博客分析了那次演讲的关键点，并深入探讨了这些主题，提供了更深入的见解和讨论。
监控与可观察性
InfluxDB 有能力处理监控和可观察性用例。3.0 不仅提高了两者的性能，还使可观察性用例在大规模上成为可能。在我们深入细节之前，让我们先澄清一下，监控和可观察性之间究竟有什么区别。
监控
监控涉及收集和分析指标、日志和事件，以跟踪系统性能。使用预定义的规则和阈值，监控过程检测潜在问题，并在阈值被突破时生成警报，从而帮助维护系统健康。您可以在各种类型的硬件和数字领域的基础设施中应用此方法。
可观察性
可观察性将监控提升到更高层次，包括对代码和基础设施的仪表化，以暴露相关数据。这使团队能够深入了解其系统行为。通过关联来自不同来源的数据，它促进了问题的诊断和根本原因的识别。这反过来又提供了有效的解决问题的见解。跟踪，它映射请求或事务通过系统组件的旅程，是可观察性的基本工具。
乍一看，监控和可观察性可能看起来服务于相同的目的，但它们从不同的角度来处理系统健康。监控是主动的，通过设置预定义的规则和阈值来确保系统在期望的参数内运行。它是确保一切“按轨道运行”，并在出现问题时发出警报。另一方面，可观察性更具有诊断性。它是了解“为什么”发生了某事，并深入了解系统行为。虽然两者都旨在维护系统健康和性能，但监控更多地关于检测已知问题，而可观察性则侧重于探索未知问题。然而，在现代系统管理的领域中，它们是互补的。共同，它们提供了一个全面的系统健康、性能和行为视图，确保了稳健性和弹性。
监控与可观察性领域
我们可以将这些概念进一步分类到几个不同的领域，每个领域都有其特定的关注点和应用。
网络监控：观察网络组件（如路由器、交换机和防火墙）的性能，以确保数据传输高效、检测瓶颈并识别安全威胁。
服务器监控：跟踪物理或虚拟服务器的性能和可用性，包括CPU使用率、内存消耗、磁盘空间和响应时间，以确保最佳性能并减少停机时间。
应用性能监控 (APM)：监控软件应用程序的性能，以识别代码、数据库或基础设施组件中的问题、瓶颈和低效之处。（应用性能监控已用蓝色突出显示，因为它也可以属于可观察性的范畴，我们将在后面讨论）。
云基础设施监控：跟踪基于云的服务（如虚拟机、存储和数据库）的性能和可用性，以优化资源分配并降低成本。
要解决的问题
现在，让我们进入有趣的部分！我发现当你有一个问题要解决时，如果你首先了解你希望采用的解决方案，那么解决起来会更容易。让我们让ChatGPT创建一个基础设施问题，该问题涉及为之前讨论的每个领域创建一个解决方案。
基于这个问题，我们可以将架构分解为我们的监控和可观察性子领域。
网络监控：监控网络流量，特别是对模型的请求。
服务器监控：跟踪 Whisper GPT 服务器（托管其主模型）的性能，重点关注CPU和GPU指标。
应用性能监控 (APM)：这包括两个方面
-
在裸机基础设施上监控我们的 Kubernetes 集群。
-
为开发者提供在 Whisper 平台上主动分析代码的工具。
云基础设施监控：利用 App Runner 或 Amazon EKS 等服务进行前端管理。
解决问题
现在，我将向您展示如何使用 TIG 堆栈（Telegraf、InfluxDB 3.0 和 Grafana）和 OpenTelemetry 解决这些问题。在我们自己超前之前，让我们先创建一个架构蓝图。
数据收集
Telegraf 是我们首选的开源数据收集代理，专门用于收集指标和事件。它配备了超过 300 个插件，用于摄入、转换和输出数据，是时间序列数据的通用代理。社区将其称为监控和可观察性数据收集的瑞士军刀，因为它可以根据插件的使用部署拉取和推送收集方法。它还配备了处理大量数据格式的功能，包括 Prometheus、JSON、XML、CSV 和 许多其他格式。
让我们看看我们可以使用的一些插件来解决我们的 Whisper GPT 问题
| 字段 | 插件 |
| 网络监控 | gNMI Net SNMP |
| 服务器监控 | CPU 磁盘 磁盘io 内存 进程 Nvidia SMI 系统 |
| APM | Kubernetes Inventory Kubernetes OpenTelemetry Prometheus |
| 云基础设施监控 | CloudWatch Kubernetes Inventory Kubernetes |
设计上，Telegraf 作用像一个数据管道，您可以通过不同的插件将其路由，以便在达到最终输出之前对数据进行处理和聚合。以下架构图很好地展示了这一点。
在本次演示的这一环节，我深入探讨了Telegraf的最佳实践和初始部署。我强烈建议您查看我们的InfluxDB大学Telegraf基础教程课程，以了解更多关于这部分的内容。
数据存储
在完成数据收集任务后，现在让我们转向基础设施监控架构中的关键部分——数据存储。
InfluxDB 3.0是一个专为处理大规模指标、跟踪和日志进行优化的专用时序数据库，适用于实时分析。这是由我们用于创建数据库引擎的三个核心开源技术驱动的：Apache Arrow、Parquet和DataFusion。如果您想了解更多关于我们如何部署这些技术的信息，我强烈建议您查看这篇博客。
在核心上，InfluxDB在应对我们的用例时提供了相当多的好处
| 好处 | 描述 |
| 写入时模式化 | 在监控用例中，这是一个显而易见的选择。模式设计是开发者在使用传统数据库时需要关注的最昂贵、耗时最长的任务之一。此外，由于Whisper GPT的发展方式不同，模式问题也不会消失。InfluxDB在初始数据导入时构建模式，从而消除了从头开始构建模式的需求。这种能力使得模式能够随着我们的解决方案一起演变。 |
| 写入和查询性能 | 在大多数监控用例中，用户需要接近实时的数据可见性，这可能来自每天生成数百个数据源和数十亿字节时序数据。InfluxDB可以每秒处理超过400万个值，同时提供毫秒级的查询返回时间。我强烈建议您查看这篇博客，以了解我们的一些性能统计数据。 |
| 单一数据存储 | 在监控和可观察性空间中，最有趣的问题之一是存储不同类型的时间序列数据：跟踪、指标和日志。大多数经验丰富的供应商为每种数据类型使用不同的数据存储技术，然后在查询时间提供接口以联合这些结果。InfluxDB 3.0允许我们将所有内容保存在单个存储中，从而降低了整体拥有成本。 |
| 查询支持 | 在InfluxDB 3.0中，我们希望强调与开发者站在同一立场。这意味着提供大多数用户（无论是现有用户还是新用户）都可以参与其中的查询语言。InfluxQL和SQL为开发者提供了与数据交互的出色选项。它们还提供了一个丰富的第三方解决方案生态系统，这些解决方案利用了这两种语言。 |
在这个环节，我再次讨论了最佳实践和InfluxDB 3.0的入门方法。我强烈建议您查看InfluxDB 3.0基础课程，以了解这些内容。
数据应用
我们已经达到了第二个里程碑。在这个阶段，我们的Whisper GPT基础设施监控流程正在收集和存储数据。
现在我们需要对这个数据进行一些处理。根据您自己的倡议或当前公司基础设施，您可能已经有了这个部分将如何发展的相当清晰的看法。为了完整性，让我们讨论一些想法。
Grafana 是一个开源的数据可视化和监控平台。它允许用户创建用于实时数据分析跟踪和跨各种数据源的指标的交互式仪表板。它是与 InfluxDB 最广泛使用的平台之一。关于利用 Grafana 和 InfluxDB 的博客和文章有成百上千篇，所以我们重点关注 3.0 中的新功能。
FlightSQL 插件为 InfluxDB 和 Grafana 之间提供了一种新的连接方法，允许用户使用原生 SQL 构建仪表板。下表提供了 Grafana 中一些有用的 SQL 查询。
注意我们如何部署 $__ 变量以使我们的查询动态化。上面的例子展示了监控我们 CPU 使用情况和最后已知总内存读数的方法。
您可以在这里找到完整的仪表板。
OpenTelemetry
我想讨论的最后一点是 OpenTelemetry。InfluxDB 3.0 为指标、日志和跟踪提供了一个数据存储。我们正努力提供使 InfluxDB 成为 OpenTelemetry 堆栈即插即用解决方案所需的集成。最终目标是提供使用 Grafana 通过一个面板来可视化和检查跟踪以及指标的能力。
我们使用 Killercoda 提供在线交互式演示，您可以在这里尝试。
最后的润色
我们构建基础设施监控平台的三个阶段里程碑。
我随意为数据操作列表添加了一些进一步的集成。让我们通过将其应用于我们的 Whisper GPT 平台来结束。
通过 Telegraf、InfluxDB 和 Grafana（即 TIG 堆栈）的集成，我们设计了一个可扩展的解决方案，擅长跨多个领域收集、存储和处理基础设施数据。
我希望这篇博客不仅使您对 InfluxDB 3.0 和基础设施监控的旅程有所启发，而且激发您对开源广阔世界的兴趣。开放架构提供了丰富的利益，您探索得越深，找到的就越多。如果您对 InfluxDB、Telegraf 或一般的基础设施监控有任何问题或评论，请通过 Slack 与我联系。我很乐意听取您的意见。
