可观测性代理在运行时可能会消耗大量资源。 为避免Agent占用过多资源导致不必要的额外成本，您可以监控Agent的资源使用情况，确保其资源消耗在合理范围内。
从衡量可观测性代理开销到成本，按 bCameron Gain是Revecom Media的创始人兼首席分析师。 他对电脑的痴迷始于 80 年代初，当时他入侵了 Space Invaders 游戏机，在当地的游戏厅每天只玩 25 美分。 然后。 我们最近研究了如何将 OpenTelemetry Collector 用作监视遥测的筛选器。 它适用于多个应用程序或微服务，尤其是出于安全原因。 因此，OpenTelemetry Collector 属于可观测性代理的范畴。 可观测性代理（如 OpenTelemetry Collector）包括 Fluent bit、vector 等。 可观测性代理在可观测性的工作机制中起着关键作用。 它们处理数据传输，以确保准确传输遥测数据。 代理通常提供数据收集、数据处理和数据传输，并在监视系统性能方面发挥关键作用。 它们有助于识别未知问题，以便在性能问题发生之前对其进行故障排除和缓解。 这是可观测性功能的标准。 这样，当用于数据收集时，可观测性代理会收集从一个或多个源发送给它的数据。 除了接收数据外，它还将数据发送到端点，例如 grafana 面板的可视化效果。 有了它，您可以配置某些类型的日志、跟踪和指标的集合，以实现可观测性。 最初，如果已部署将遥测数据直接发送到可观测性平台的检测应用程序，则可以选择不使用可观测性代理。 收集器在监视无法检测到的应用程序时非常有用。 由于这也是一个非常常见的用例，因此在监控无法检测到的应用程序时，收集器也很有用，谷歌软件开发人员Braydon Kains告诉The New Stack。
Google Cloud 在可观测性日@ragecage64@kubecon @cloudnativefdn @nybooks可观测性代理图片twitter.com/wgacudsxxf如果没有可观测性收集器功能，则需要为这些功能单独配置每个后端或用户监控，这可能会很麻烦。 相反，可观测性收集器充当所有微服务的单个端点，通过收集器促进的统一点简化对应用程序和微服务的访问。 使用 Observability Agent 作为收集器，您可以集中查看和管理微服务，从而在 Grafana 等平台上提供统一的视图。 虽然 Grafana 提供了某些不使用 OpenTelemetry 收集器的替代方法，但收集器大大简化了此过程。 但是，可观测性代理可能会消耗大量资源。 为了解决这个问题，它们本身也可以或正在被监控，以确保它们不会过度消耗资源，从而避免不必要的成本。 换句话说，OpenTelemetry Collector、Fluent Bit、Vector 等都表现出了强大的鲁棒性和执行各种任务的能力，同时实现了卓越的结果，但它们的相对性能可能有所不同。bc gain (@bcamerongain) november 6， 2023
大多数最流行的代理都有 Kubernetes 过滤器和处理器，它们从 Kubernetes API 获取元数据以丰富日志和数据。 正如 Google 软件开发人员 Braydon Kains 在他自己的 KubeCon + CloudNativeCon 演讲中所说的那样，“开销有多大：如何评估可观测性代理性能”，除了 OpenTelemetry，Fluent Bits 和 Vectors 也越来越受欢迎。 “如果可用的默认值不能满足您的需求，每个代理也有办法构建自定义处理，”凯恩斯在会后告诉 The New Stack。 “这样做的最大挑战是，在每秒处理数 TB 数据的管道上执行任何操作都会对您的开销产生倍增效应。 特别是对于正则表达式日志或 JSON 日志解析，其影响可能会迅速增长，“Kains 说。 “如果你不能足够快地发送数据，我强烈建议增加工作线程的数量，或者尽可能利用代理的线程实现。 根据 Kains 的说法，导出是管道中唯一可以轻松并行化的步骤。 大多数后端可以处理稍微无序的时间戳，例如，Fluent Bit 提供的一项功能是设置 8 个工作线程，以创建一个包含 8 个工作线程的线程池，这些线程池同时发送数据。 Kains 说，这可以通过将数据调度到线程池并让其中一个工作线程处理较慢的部分来显着提高管道的效率，以防默认进程运行不足。 Kains 说，组织通常需要独立确定哪个代理最适合他们以及预期的开销。 “做到这一点的唯一方法是尝试运行它。 如果可以复制生产环境，请安装代理，对其进行配置并监控指标，“凯恩斯说。 “这是获得答案的最佳方式。 ”
如果复制生产环境具有挑战性，Kains 建议考虑使用日志生成器或抓取测试工作负载，例如 Prometheus。 AWS 的 Logbench 是用于测试日志管道的良好日志生成器。 对于 prometheus 抓取，请设置一个带有文本抓取副本的模拟服务器。 “如果您期望使用高基数方案，尤其是对于数据库指标，请强制使用高基数方案来对代理的性能进行压力测试。 如果对评估结果不满意，请考虑减少工作或卸载工作以减少资源使用。 聚合节点和后端处理还可以帮助管理资源使用情况，“Kains 说。 “如果您遇到不可接受的性能或发现回归，请向维护人员提出问题，并提供复制问题的详细信息和相关的性能数据，例如图表、CSV、Linux 性能报告或 pprof 配置文件。 “Kains 在 Google 的团队使用 Google Cloud Operations，它合并了两个代理，使用 Fluent Bit 进行日志收集，使用 OpenTelemetry 进行指标和跟踪。 在后台，该团队维护一个配置层，用于为 OpenTelemetry 和 Fluent Bit 生成配置。 这些配置主要针对虚拟机（如普通虚拟机）上的用户进行优化，并使用 OpenTelemetry 确保高效的指标收集。
Kains 说，前段时间，我们有兴趣看看 OpenTelemetry 日志是否可以用作 Ops 代理而不是 Fluent Bits。 “这将使我们能够在OpenTelemetry Collector上完全统一，”Kains说。 “当时，OpenTelemetry 日志还不够成熟，无法处理 Fluent Bit 的吞吐量和内存使用，因此我们选择不继续前进，”Kains 说。 “我们还没有更新这些基准，所以很难说今天的情况会怎样。 ”
但是，对于大多数普通用户来说，依靠 Google 基础架构对代理进行基准测试将非常昂贵且对最终用户来说过于复杂。 “我运营的基准社区无法复制，”凯恩斯说。 “这是我打算在新的一年里承诺的事情，修改我们的基准测试和性能评估策略和技术，使它们是开源的，不依赖于任何谷歌的专业知识或基础设施。 但是，使用 AWS Log Bench 甚至 Kains 团队创建的脚本，可以手动为代理生成日志负载，并直接通过 VM 上的工具（如 HTOP）观察和比较指标，并使用可以从 PROC 或类似内容收集信息的脚本收集指标，Kains 说。 “我想创建可以开源的指南或工具，使这种基准测试更容易被技术水平较低的用户使用，”凯恩斯说。 “我还没有确切的计划，但我希望在未来几个月内有更多的话要说。 ”