I. OneAgent はなぜ必要なのでしょうか?ByteDanceは、物理マシン、仮想マシン、コンテナなど、様々なシナリオをカバーする膨大な数のホストインスタンスとマイクロサービスインスタンスを保有しています。毎秒数千億もの観測可能なデータポイントが生成されるため、観測可能なデータの収集とパイプライン処理の面で、技術チームにとって大きな課題となっています。
バイト観測可能性追跡の現状分析 これらの問題に対処するために、技術チームは、ログ、メトリック、トレース、イベントを収集するためのソリューションを提供する OneAgent コンポーネントを構築することを決定しました。 OneAgentは、ByteDanceのオブザーバブルチームが提供する次世代オブザーバブルデータ（MTLE）取得・処理パイプラインです。OneAgentの目標は、エンタープライズおよびクラウドにとって最適なオブザーバブルインフラストラクチャとなることを目指しています。クラウド環境におけるオブザーバブルシステムへのアクセスの複雑さを軽減し、ユーザーがオブザーバブルからより多くの価値を容易に引き出せるようにします。 OneAgentの「One」は、統合と再利用を意味します。OneAgentは、観測可能なデータの取得と前処理を行うエージェントとして、システム内で以下の役割を果たすことを想定しています。
コミュニティ内の既存のオープンソース ソリューションを調査した後、最終的に、オープンソースの iLogtail を OneAgent の基盤として使用しながら、一般的な機能をオープンソース方式で直接コミュニティに提供し、iLogtail コミュニティと連携することを決定しました。 II. OneAgentアーキテクチャオープンソースプロジェクトのフレームワークをベースに、ByteDance のクラウドネイティブ オブザーバビリティ チームによって開発された OneAgent は、C++ で記述されたコア部分と、主に Go で記述されたプラグイン システム部分に分かれています。 CoreはiLogtailの中核であり、主にOneAgent自身の状態管理を担います。これには、設定の読み込みと監視、パイプラインの開始と停止、チェックポイントの保存、自己監視、アラート生成が含まれます。また、ログファイルの収集に関連するロジックも含まれています。Goプラグインシステムは、Prometheus、OpenTelemetry、SkyWalkingなどの多数のプラグインを含む、様々な可観測性エコシステムに接続し、iLogtailの適用シナリオを大幅に拡張します。 言語に基づいて、iLogtail には C++ と Go の両方のパイプラインが含まれており、cgo を介して相互に対話できます。
クラウド ネイティブの可観測性チームは現在、OneAgent の Go パイプラインを使用してメトリックとトレースのデータを収集および処理し、ログ ファイルの収集には Go Flusher プラグインを使用した C++ パイプラインを使用しています。 III. ビジネスシナリオに基づくオープンソースの修正実際の開発においては、ByteDanceの事業規模と複雑なビジネスシナリオのため、単純なオープンソース版では現実のニーズを完全に満たすことができませんでした。そのため、コアデータモデル、パイプライン、オーケストレーションスケジューリング、ビルドシステムに徹底的な改良を加えました。 ネイティブイベントデータモデルコミュニティ版のパイプラインはログをベースとし、SLS-PBデータモデルを使用しています。メトリクスとトレースデータを処理できますが、まずログに変換する必要があり、これによりパフォーマンスのオーバーヘッドや互換性の問題が発生することがよくあります。次のメトリクスを例に挙げると、メトリクスフィールドは特別に合意されたキーを使用して保存されます。メトリクスの複数のラベルは固定形式で単一のフィールドに連結され、値は文字列形式で保存されます。 これにより、いくつかの問題が発生します。
上記の問題に対処するため、新しいデータモデルに基づく2.0パイプラインを開発しました。2.0パイプラインでは、パイプラインを流れる各データはPipelineEventとして定義されます。メトリック、トレース、ログ、バイト、プロファイリングなどはすべてPipelineEventから派生した特定のイベントであり、柔軟性が大幅に向上しています。 PipelineEvent はより豊富な情報を伝達でき、データ パイプライン内の計算モデルに適しているため、一般的な処理機能が大幅に向上します。 現在、この変換はコミュニティに貢献しており、コミュニティはこの新しいデータモデルをコア処理モデルとして受け入れています。今後リリースされる新しいプラグインは新しいデータモデルをサポートする予定であり、既存のプラグインも徐々に新しいデータモデルに対応していく予定です。 まったく新しい建設ソリューションバージョン1.4.0より前のバージョンでは、コミュニティはプラグインをメインのプロジェクトリポジトリに配置することを要求していました。しかし、インターネット時代において、コードは企業にとって最も重要な資産の一つです。ByteDanceでは、社内のセキュリティとコンプライアンス要件により、一部のプラグインは社内のプライベートリポジトリに配置する必要があり、オープンソースコミュニティに貢献することができませんでした。このような状況では、社内固有のプラグインを追加するために新しいリポジトリをフォークする必要がありましたが、これは上流コミュニティから遠ざかり、オープンソースプロジェクトの新機能を活用できず、エンドユーザーからのコミュニティへのフィードバックも妨げていました。 この問題を解決するため、公式リポジトリとプライベートリポジトリのプラグインをマージしてパッケージをビルドするアーティファクトビルドメカニズムを設計しました。このソリューションでは、主にOpenTelemetry Collectorのアプローチを参考にし、YAMLファイルを使用して最終的なGoファイルをレンダリングしました。リポジトリには以下の変更を加えました。 バージョン 1.4.0 より前では、プラグインのインポートは plugins/all/all.go に配置されていました。 バージョン1.4.0以降、メインプロジェクトリポジトリに`plugins.yml`ファイルが追加されました。すべての組み込みプラグインはこのファイルに登録され、`plugins.yml`はデフォルトで組み込みプラグイン用の`all.go`ファイルを生成するために使用されます。ビルドスクリプトは複数の`*_plugins.yml`ファイルを渡すこともサポートしており、`external_plugins.yml`を使用して外部リポジトリからプラグインを読み込み、`external_all.go`ファイルを生成します。 プラグイン.yml: 外部プラグイン.yml: この機能により、企業は独自のシナリオに合わせてプラグインをより自由に開発できるようになり、開発のハードルが大幅に下がり、オープンソース プロジェクトの共同作業エクスペリエンスが大幅に向上します。 ByteDanceのプラグイン設定（匿名化） プラグイン開発これら 2 つの特性に基づいて、さまざまなシナリオで使用し、ビジネス ニーズを効果的にサポートする一連の OneAgent プラグインを開発しました。 入力プラグイン:
処理プラグイン:
アグリゲータープラグイン:
出力プラグイン:
拡張プラグイン:
前述のプラグインのいくつかは、オープンソース コミュニティにも貢献されています。 IV. OneAgentのケーススタディこのセクションでは、OneAgent を活用した ByteDance の 3 つの事例を紹介します。 ストレージドックの交換 TelegrafByteDance内のストレージサービスは、メトリックトラッキングに主にBytedMetrics 1.0 SDKを使用し、メトリック収集エージェントとしてMetrics Agent (ms2)とTelegrafを採用しています。このデータ収集チェーンは非常に長く、多くのリソースを消費するため、製品側のメトリックは収集遅延とデータ損失の問題に悩まされています。インスタンスによっては1分間に数百万のデータポイントを生成でき、収集コンポーネントは最大16コアを利用できますが、パフォーマンスの制限により監視メトリックのリアルタイムレポートが不可能となり、製品側のメトリック収集において遅延とデータ損失の問題が発生します。
上記の問題に対処するため、新しいメトリクス収集エージェントとしてOneAgentを導入しました。現在、OneAgentはTelegrafに取って代わり、収集エージェントのCPU使用率を80%削減し、監視ポイントの見逃しや遅延といった業務上の問題を解決しています。 OneAgentのローンチ結果 このサービスのユーザートラッキング方法は多岐にわたり、BytedMetrics 1.0 SDK、BytedMetrics 2.0 SDK、InfluxDB SDK、Prometheus Exporter、OpenTelemetry SDKなどが利用可能です。以前はデータ収集のために複数のエージェントを導入する必要があり、リソースの無駄遣いだけでなく運用コストの増加にもつながっていました。現在、OneAgentはBytedMetrics 1.0 SDK以外のすべてのデータを受信できるため、複数のデータ収集エージェントを統合することが可能です。 BytedMetrics 2.0 SDKへの企業の統合が徐々に進み、C++パイプラインの変革という次のフェーズが進むにつれて、OneAgentは最終的にms2に取って代わり、このビジネスにおける唯一の観測可能なデータ収集エージェントとなり、さらなるリソースの節約を実現します。これは私たちの究極の目標でもあります。 ログファイルの収集ByteDanceにおける主流のアプローチはGoマイクロサービスであり、主に侵入型のBytedLogs SDKを使用してログを記録します。SDKはUnixドメインソケットを介してローカルのTTLogAgentにレポートを送信し、ディスクレスのログ収集を可能にします。
これによって、いくつかの問題も発生します。
TTLogAgentはファイル収集機能が弱く、ログ処理の汎用性も不足しています。複数行ログの正規表現処理をサポートしておらず、すべてのユーザーが利用できるようにすることはできません。TTLogAgentとiLogtailの長所と短所を比較した結果、OneAgentのこの機能を再利用し、TTLogAgentをOneAgentのプラグインとして利用することにしました。 イベント駆動型ファイル取得 OneAgentは、ログ収集にポーリングとinotifyを組み合わせたアプローチを採用しています。これにより、inotifyの低レイテンシと低パフォーマンスオーバーヘッドを活用しながら、ポーリングによってオペレーティング環境を包括的にカバーできます。ログ収集のレイテンシをミリ秒レベルで制御できるため、ByteDanceの現在のログ収集負荷に効果的に対処できます。 変更後、TTLogAgent は OneAgent のプラグインになりました。 TTLogAgent の機能は徐々に OneAgent に移行し、最終的には TTLogAgent を廃止する予定です。 オープンソースエコシステムへの接続OneAgentはデータ収集エージェントとしてだけでなく、プロキシやゲートウェイなどのサービスとしても導入できます。ByteDanceは、ユーザーがさまざまな監視プラットフォームに接続し、社内と社外で統一された監視エクスペリエンスを実現できるよう、社内に複数のOneAgentサービスを導入しています。
V. 今後の展望今後の計画としては、OneAgentの機能強化を継続し、安定性と使いやすさを向上させていきます。同時に、オープンソースコミュニティにも積極的に参加し、開発者と協力して、業界をリードする観測可能なデータコレクターを構築していきます。
VI. 引用文献ByteDance の百万レベルメトリクスエージェントのパフォーマンス最適化の探求と実践: https://mp.weixin.qq.com/s/bl1HbC6ti6Pw2FGxgstfBw リソースを節約し、パフォーマンスを向上: 超大規模メトリックデータ収集のための ByteDance の最適化手法: https://mp.weixin.qq.com/s/spHNCBWfgOCHSomLvp5aWA OpenTelemetry コレクター コネクタ: https://github.com/open-telemetry/opentelemetry-collector/blob/main/connector/README.md クラウドネイティブオブザーバブルチーム ByteDanceのクラウドネイティブ・オブザーバビリティチームは、毎日数十ペタバイトに及ぶ観測可能なデータを収集、保存、クエリ、分析するためのエンジン基盤を提供し、企業、ビジネスプラットフォーム、そしてインフラストラクチャ向けに包括的かつ統合されたオブザーバビリティ技術サポート機能を提供することに尽力しています。同時に、チームはVolcano Engineを通じてクラウドベースのオブザーバビリティ技術機能を継続的にエクスポートしています。 |
