クラウド ネイティブでの観測可能なデータ収集の実践については、この記事をお読みください。

この記事は、GOPS 2022 上海での Yu Tao 教授の講演に基づいてまとめられています。さらに興味深いコンテンツをご覧になりたい場合は、効率的な運用とメンテナンスのWeChat公式アカウントをフォローしてください。

著者について:
アリババの技術専門家、Yu Tao氏は次のように述べています。
10 年の職務経験を持ち、現在は Alibaba Log Service Observability Platform チームに所属し、iLogtail のオープンソースを担当し、ビッグ データ分析、データ収集エージェント、大規模データ アクセス ガバナンスに重点を置いています。
彼は、Baidu Statistics および Baidu Analysis Cloud 製品の研究開発を担当していました。

1. 観測可能なデータ型と値

1.1 ITシステムの可観測性

「観測可能性」は電気分野に由来し、システムが観測可能である場合、その状態は外部出力から推測できることを意味します。たとえば、自動車のエンジンの場合、通常のアラームではエンジンの全体的な状態しかわかりません。水温、気圧、速度などのダッシュボードを追加すれば、大まかに故障の方向を特定できます。この問題を解決するには、コンポーネント内の各センサーの詳細な観測データに頼る必要があります。

IT システムの分野では、可観測性は近年ますます普及してきました。それはITシステムの開発と関係があると思います。当初、ソフトウェアシステムは比較的単純で、開発作業は数人だけで完了でき、全員がシステム全体を完全に理解していました。ビジネスが複雑になり、関与するモジュールが増えると、1 人でシステム全体像を把握することが難しくなります。このとき、問題箇所を特定するために、その観測データを表示する必要があります。

ソフトウェアが複雑になるにつれて、チーム間のコラボレーションがより頻繁に行われるようになります。責任転嫁を防ぐために、チーム間のコミュニケーションやトラブルシューティングもより効率的に行う必要があります。そのため、データによる表現が必要となり、可観測性データの需要がますます高まっています。システムの基本コンポーネントがクラウドベースになるにつれて、ソフトウェアの動作環境はますます複雑になっています。スタンドアロンからコンテナ化、そしてクラウドネイティブへ。クラウド上のサードパーティまたはクラウドネイティブのインターフェースに依存するコンポーネントがますます増え、システムはますますブラックボックスのようになり、安定した運用につながらなくなります。

観測可能なデータを公開する目的は、ブラックボックス化されたものをホワイトボックス化することです。通常、可観測性データは、ログ、トレース、メトリックの 3 つのカテゴリに分類されます。

1.2 ITシステムの可観測性シナリオとアプリケーションの進化

これら 3 種類のデータの定義は比較的広く、運用と保守の分野に限定されません。たとえば、オンライン操作の分野では、アプリに埋め込まれたデータを追加することで、ユーザーの使用におけるボトルネックを観察し、ユーザーエクスペリエンスを的確に改善することが可能になります。オフライン業務の分野では、ショッピングモール内のWIFIや監視機器を利用して人の流れをカウントすることで、新規出店場所の選定や混雑管理の問題を解決することができます。交通分野では、都市交通管理の問題は地図データや車両ネットワークデータを通じて解決できます。

可観測性データの応用価値と可能性は非常に大きいことがわかります。カンファレンスのテーマである運用と保守に戻りましょう。現在、多くの企業がクラウドに移行しており、最初に行うことはアプリケーションを K8s にデプロイすることです。以下では、K8s でのビジネス展開の特性とデータ収集要件について簡単に紹介します。

2. K8sにおけるビジネス展開の特性とデータ収集要件

2.1 自動パッキングと弾性スケーリング

K8s には、自動パッケージングと柔軟な拡張および縮小の機能があります。アプリケーションのデプロイメントでは、オーケストレーションを実現するための宣言のみが必要なため、R&D 担当者のエネルギーと時間をデプロイメントに大幅に節約できます。同時に、アプリケーションの展開効率が向上するため、アプリケーションのバージョン反復が非常に高速になり、アプリケーションの混合展開が頻繁に行われ、単一ノードのリソース使用率が大幅に向上します。さまざまな要件を持つアプリケーションをさまざまな形式で展開できるようにするために、K8s は非常に豊富なコントローラーを提供し、拡張機能を提供します。一部のコントローラーは、非常に一般的で実用的な水平拡張およびローリング更新機能を提供します。これらの機能により、システム内のコンテナの作成と破棄も高速化されます。

2.2 リソースの抽象化と混合使用

2つ目はリソースの抽象化です。 K8s を使用すると、異なるソフトウェアとハ​​ードウェアを持つノードを均一にスケジュールし、クラスター内で混在させることができます。これらの異種リソースをより適切に管理するために、通常は同様のリソース ノードを同じノード プールに割り当てます。たとえば、一部のノード プールは Linux システムのホストであり、一部は Windows システムのホストであり、一部は GPU を搭載したホストです。これらのノードを 1 つの K8s マスターで管理すると、マシン リソースの使用率を最大化できます。

ノード自体は物理ホストまたは仮想ノードになります。たとえば、Alibaba Cloud の ECI サービスは、実際にポッドを Virtual Kubelet にシミュレートし、タスクのスケジュールを受け入れるノードとして扱うこともできます。リソースがスケジュールされると、そのコンテナは実際には物理ノードではなくクラウド内のサーバーレス リソース上で実行されます。このリソース抽象化機能により、アプリケーションの展開の柔軟性が大幅に向上します。たとえば、ハイブリッド クラウドのシナリオでは、一部の顧客は独自のコンピュータ ルームをオフラインで構築し、安定したトラフィック ワークロードを自社構築のコンピュータ ルームに配置します。トラフィックが急増する可能性のある一部のワークロードは、弾力的なスケーリング機能を備えたクラウド ノードに配置されます。

2.3 ストレージの抽象化と柔軟なオーケストレーション

K8s はストレージに対して比較的優れた抽象化を提供し、さまざまなアプリケーションのデータ永続性要件を満たすことができます。同時に、このような抽象化により、コンテナは、ディスクがマウントされている場所など、基盤となるストレージの詳細を気にする必要がなくなり、ストレージの種類、容量、および IO 要件を宣言するだけで済みます。これにより、K8s にデプロイされたアプリケーションは、単一のマシンのディスクの制限を打ち破ることができ、ある程度、すべてのアプリケーションにストレージとコンピューティングの分離機能が提供されます。

3. K8s における観測可能なデータ収集の一般的な課題

K8s は、一連の柔軟で便利なデプロイメント機能を提供しますが、可観測性データの収集にはいくつかの課題ももたらします。以下の4つのポイントを説明します。

3.1 収集、展開、運用が複雑

K8s のデプロイメントは便利で柔軟性があるため、ノード上に多数のコンテナが存在する可能性があります。これほど多くの異種混合コンテナを収集するためにコレクション エンドを展開するにはどうすればよいでしょうか。また、これほど多くのコレクション オブジェクトを管理するにはどうすればよいでしょうか。 K8s 環境では、コンテナのデプロイメントは非常に急速に変化します。たとえば、動的にスケールアップおよびスケールダウンする場合、トラフィックが増減すると、コンテナがすぐに作成および破棄される可能性があります。ノード リソースが不足すると、コンテナーが削除されることもよくあります。これにより、コンテナのライフサイクルが非常に短くなり、データ収集の損失を回避するために、収集側はコンテナをすばやく検出する必要があります。

3.2 コンテナとノードの動作環境は多様である

コンテナ技術の発展に伴い、コンテナが実行される環境はますます多様化しています。従来、コンテナの運用・保守にはDockerが使われていました。 K8s の台頭により、Docker ランタイムは徐々に無視されるようになりました。現在、最新バージョンはすべて、Containerd ランタイムをデフォルトでサポートしているほか、CRI-O などの新しいコンテナー ランタイムもサポートしています。これらのランタイムの出現は、コレクション ノード上のコンテナー データが単一の形式ではなくなったことを意味します。同時に、異なるランタイムの通信メカニズムは異なる場合があり、対応するコンテナ コンテンツの保存パスも異なります。これには、コレクターがさまざまなランタイム環境に適応する必要があります。

コンテナが実行されるノード環境には、物理​​マシン、VM、仮想ノードが含まれます。仮想ノードの展開モードは物理マシンとは異なり、特にコンテナのメタデータとデータ保存サイクルは物理マシンとは異なります。これらでは、データ収集の失敗を回避するために、収集側とノードに適切な調整計画が必要です。

3.3 単一ノード上のログサイズが大きい

さまざまな要因により、ノードのログ サイズが大きくなります。

• ハイブリッド展開と単一マシン展開では、モノリシック アプリケーションが展開される傾向があります。ただし、K8s では、1 つのノードに 50 を超えるインスタンスをデプロイすることが非常に一般的です。
• ディスク: 従来のノードはローカル ハード ディスク (HDD/SSD) を使用しており、SSD IO スループットの制限も約 500 MB/秒にすぎません。 K8s ノード (特にクラウド ノード) はクラウド ディスクを使用でき、最高仕様速度は 1 GB/秒に達します。
• ストレージ拡張機能: 単一マシンの展開では通常 NAS が使用されますが、K8s は複数の種類のストレージのマウントをサポートし、PVC を使用して柔軟な拡張を実現し、単一マシンの読み取りおよび書き込み速度と容量のボトルネックを打破します。

実際のアプリケーションでは、単一のノードで大量のログを生成するユーザーに遭遇したこともあります。たとえば、タクシー配車アプリは、アプリ追跡データ/GPS追跡データ/車両のリアルタイムバックグラウンドデータ受信を1つのノードに同時に展開し、1つのノードで200M/sを超えるログを収集します。

3.4 観測データの異質性

K8s ノード自体には、標準出力、PVC ログ、コンテナ ログなど、複数のメディアがあります。

同時に、ログ/メトリック/トレースにはさまざまなデータ入力ソースがあります。ログに関しては、アプリケーションのハイブリッド展開のため、ビジネス アプリケーション、MySQL binlog、Nginx アクセス ログなどのデータなど、複数の形式で同時にログを収集する必要があります。メトリックに関しては、通常、Prometheus メトリックを収集する必要があります。トレースに関しては、スカイウォーキングやその他の収集する必要があるデータがあります。このような複雑な収集要件では、使用要件を満たすために、単一のノードで収集するクライアントが、複数の種類の観測可能なデータを同時に収集できるようにサポートする必要があります。

こうした状況は、オンエンドのデータ収集に新たな課題をもたらします。

4. 関連する問題に対処するための解決策と実践

コレクションの展開、環境、ログスケール、異種データの4 つの側面から共有します。

4.1 コレクションの展開

展開モード

通常、K8s のエンド コレクターには 2 つのデプロイメント モードがあります。1 つは DaemonSet で、もう 1 つは Sidecar です。 DaemonSet は、ノードにコレクターをデプロイして、ノード上のすべてのコンテナのログを収集します。サイドカー モードは、ビジネス コンテナー内で並列収集コンテナーを起動し、共有ストレージを通じてビジネス コンテナーのログを収集します。

DaemonSet モードには、結合度が低く、各アプリケーションを個別に変更して展開する必要がなく、データを直接収集できるなど、いくつかの明らかな利点があります。コスト効率に優れ、ビジネス展開の数から切り離されたノード全体のデータを収集するために必要なコンテナ リソースは 1 つだけです。

Sidecar にも応用シナリオがあります。たとえば、ログの量が特に多いコンテナの場合、収集を他のコンテナから分離する必要があります。比較的高い分離性を実現でき、柔軟性にも一定の利点があります。

構成の配布

コレクション クライアントがデプロイされた後、これらのコレクション オブジェクトをどのように管理すればよいでしょうか?構成の配布が含まれます。比較的シンプルなアプローチは、K8s ConfigMap を使用して構成を配布することですが、その欠点も明らかです。

• ConfigMapにはサイズ制限がある
• 配布は柔軟ではなく、各コレクターのグループを個別に構成する必要がある

これらの問題を解決するために、ConfigServer を使用すると、グラフィカル インターフェイスをサポートした集中構成配布が可能になり、運用および保守担当者が管理および制御しやすくなります。各エージェントには識別子があり、柔軟にグループ化できます。 ConfigMap のサイズに制限されず、多数の構成をサポートできます。 1 つのノードで最大 1,000 の構成を安定してサポートできます。

この展開方法はすでに大規模アプリケーションのニーズを満たすことができますが、いくつかのシナリオでは欠点もあります。

たとえば、ユーザーが CI/CD パイプラインにアプリケーションをデプロイする場合、ログを収集するためにログ構成を送信したいと考えています。この場合、ConfigServer API を使用するには、通信するためにカスタマイズされたコンポーネントが必要になり、あまり便利ではありません。

構成の自動化

CRD を通じて構成することもできます。これにより、ConfigServer のすべての利点を享受でき、自動化されたパイプラインでコレクション構成の配布をより適切に統合できます。標準の K8s リソースである CRD を直接使用すると、これらのパイプライン コンポーネントに追加の開発コストは必要ありません。

図に示すように、緑色のものは ログ コントローラは収集された CRD をリアルタイムで監視します。 CRD は YAML ファイルで記述されます。 YAML ファイルが追加、削除、または変更されると、これらのイベントによってログ コントローラーがトリガーされ、構成が ConfigServer に同期されます。コンテナにデプロイされた iLogtail は、ConfigServer からコレクション構成をプルし、コレクション構成の宣言的なデプロイを実現します。

この方法は、一部の特殊なシナリオでは完全には適用できません。たとえば、構成が多数あり、K8s APIServer ストレージが変更されていない場合は、APIServer への負荷も考慮する必要があります。

ジョブシナリオサポート

K8s シナリオではコンテナが急速に変化することが分かっていますが、最も典型的な例はジョブ コントローラによってデプロイされるコンテナです。 Job は一度実行すると終了するという特性があるため、Pod の追加や削除の頻度が非常に高くなります。たとえば、一部の CI/CD タスクは数秒と非常に短いため、データ損失が発生しやすくなります。たとえば、無人車両のシミュレーション シナリオでは、数千の Pod が同時に起動され、新しく追加されたコンテナーの瞬間的な同時実行性は非常に高くなります。これらはすべて、データを収集する際に考慮する必要がある要素です。

実践から得られた経験は次のとおりです。

1. ファイル ハンドルをロックするには、コンテナーをできるだけ早く検出する必要があります。
2. 検出間隔中に終了したコンテナをリコールする必要があります。一部のコンテナは、エラーのため、検出間隔中に作成されるとすぐに終了している可能性があります。この場合、次の検出では終了したコンテナを無視することはできません。データの整合性を確保するために、終了したコンテナからデータを収集する必要もあります。
3. いくつかのキー ログを標準出力に印刷する必要があります。いずれにしても、コンテナが破棄されると、コンテナ内のファイルにはアクセスできなくなります。ただし、標準出力は異なります。標準出力は Kubelet によって個別に管理され、保存戦略があります。通常、すぐには削除されません。これにより、コンテナが急速に変化するシナリオでもデータが失われることがなくなります。

4.2 動作環境

コンテナランタイム

次に、動作環境への適応についてお話します。まず、さまざまな展開モードでの一般的なオープンソース エージェントのコレクション サポートについて見てみましょう。 iLogtail のみが DaemonSet 下のコンテナ内のファイル収集をサポートします。 iLogtail はこれをどうやって実現するのでしょうか?

右の図に示すように、iLogtail は他のオープンソース ソフトウェアとは異なる方法でコンテナを検出します。 API サーバーを使用する代わりに、ローカル コンテナー ランタイムと直接通信して、コンテナーの実行中のメタデータを取得します。この情報には、コンテナ内のファイルを格納するコンテナのデータ位置情報であるオーバーレイ情報、およびマウント ポイントと対応するマウント パスが含まれます。この情報があれば、共有ボリューム方式でデータを収集する必要なく、DaemonSet を通じてこのデータを直接収集できます。

しかし、これを実現するには、さまざまなランタイムを適応させる必要があります。たとえば、Docker と Containerd は通信方法が異なり、それを自動的に検出する必要があります。標準出力形式も異なり、コンテナ内の異なる場所にファイルを保存します。これらはすべて特定の適応を必要とします。適応後は、ユーザーにとってさらに使いやすくなります。データを収集するには、コンテナ上のパスを構成するだけでよく、その他の追加作業は必要ありません。

サーバーレスサポート

コンテナの多様な実行ノード環境について説明しました。 Serverless のようなシナリオをどのようにサポートするのでしょうか? Serverless には物理ノードがなく、DaemonSet をデプロイできません。一方、Sidecar は標準出力を収集できないため、どちらも完璧なソリューションではありません。より複雑な状況は、HPA が Virtual Kubelet を通じて実装されるシナリオです。一部のコンテナはすでに物理ノード上で実行されており、DaemonSet を使用してログを収集しています。ただし、エラスティック スケーリングが発生すると、仮想ノード上にコンテナーが作成され、DaemonSet コンテナーは存在しなくなります。しかし、それでもログを収集する必要がある場合はどうすればよいでしょうか?

どのように行うか見てみましょう。 Virtual Kubelet は、新しいコンテナを作成する要求を受信すると、ECI を介してコンテナを作成し、ECI 内でビジネス コンテナと iLogtail コンテナを同時に実行します。 iLogtail コンテナ ユーザーは、hidecar モードと呼ばれるこのモードに気づいていません。

ECI 内のビジネス コンテナの情報 (マウント ポイントやホスト上のコンテナ内のファイルの場所など) は、静的ファイルを通じて iLogtail に送信されます。この場合、iLogtail の動作モードは DaemonSet の動作モードと非常に似ています。静的ファイルを通じてコン​​テナを検出し、iLogtail コンテナにマウントされた ECI ルート ディレクトリを通じて ECI ノード上のビジネス コンテナ ログを収集します。

このように、ユーザーは DaemonSet のみを使用して、意識することなく ECI Serverless コンテナのログをスムーズに収集できるようになります。データ損失を回避するために、ECI は iLogtail がビジネス コンテナーよりも遅く終了信号を受信するようにします。

4.3 単一ノード上のログサイズが大きい

シングルコレクション終了

まず、iLogtail の収集パフォーマンスは、さまざまなオープンソース コレクターの中でも比較的優れています。ミニマリストモードでは440MB/秒に達します。ただし、デフォルトの展開では通常、iLogtail リソースが制限され、最大速度に到達できない可能性があります。この時点でログ遅延が発生する場合は、以下の側面から判断できます。

• クライアント。リソースを増やし、iLogtail の並列処理と送信のパラメータを調整できます。
• サーバー側。ログ サービスには容量を自動的に拡張する機能がありますが、ログ バックログなどの特殊なシナリオでは自動拡張に遅延が発生する場合があり、手動で調整する必要があります。
• ネットワークリンク。送信側と受信側の帯域幅が十分かどうかを確認します。途中にプロキシがある場合は、VIP と SLB が上限に達していないか確認します。国境を越えた伝送が関係する場合は、グローバル アクセラレーションを有効にしたり、エンタープライズ クラウド ネットワークを使用したりして、リンクを改善する必要がある場合があります。

複数の取得端末

上記の最適化を実行しても、クライアントのボトルネックによってログの遅延が発生する場合はどうすればよいでしょうか? Sidecar デプロイメントのアイデア (1 つのノードで複数のコレクション コンテナーを実行する) を使用して、スループットの大きいログを分割し、複数のコンテナーにデプロイできます。このように、単一ノードの収集容量は DaemonSet コレクターの上限によって制限されません。

4.4 異種データのサポート

プラグインフレームワーク

iLogtail が最初に作成されたときは、主にファイル ログの収集に使用されていました。サービス全体がクラウドに移行するにつれて、クラウド上に構築されるオープン エコシステムがますます増え、アクセスする必要のあるデータもますます増えました。 iLogtail は、SLS への書き込みに加えて、サードパーティのログ ライブラリへの書き込みもサポートします。

多数の入出力要件に対応するために、拡張を容易にする iLogtail のプラグイン フレームワークを作成しました。 C++ 部分は主にファイルの処理、コレクション構成の受け入れ、データの送信、その他のコア機能を実行します。プラグインは他の入力ソースに接続する役割を担います。たとえば、Binlog と Syslog はプラグインを通じて実装されます。同時に、サードパーティのデータソースへの接続もプラグイン入力を介して行われます。変換プロセス中に、一部の iLogtail 処理機能がプラグイン化されたため、処理は Parse に限定されなくなりました。代わりに、複数の処理プラグインをエンド側で柔軟に組み合わせて、エンド側で軽量な処理パイプラインを実現できます。

iLogtail 可観測性データ エコシステム サポート

現在、iLogtail のエコシステムは、ログに関しては常に強力です。コンテナ データ収集のサポートに加えて、Windows イベントや eBPF などのデータ ソースも追加されました。メトリクスに関しては、Telegraf と Prometheus のデータ ソースがあり、OpenTelemetry データ形式へのアクセスも進行中です。 Trace は主に Skywalking データにアクセスします。出力面では、Alibaba CloudのSLSをサポートするほか、Kafka書き込みにも対応し、CKやESなどで直接利用できるようにフォーマット変換もサポート。CKやESへの直接書き込みサポートも現在計画中とのこと。

eBPF に基づく非侵入型収集

以下では、eBPF のアクセスおよび可観測性収集方法について説明します。端末上でのトレースとメトリック データへのアクセスには、通常、SDK を使用してアプリケーション内のデータを追跡する必要があります。 Java Agent を使用するなど、ポイントを埋め込まずにデータを収集する方法もありますが、特定の言語に限定されます。非侵入的習得を他の言語に拡張する方法はありますか? eBPF テクノロジーはそのような可能性を提供します。

ilogtail の実装では、eBPF の収集原則はユーザー状態とカーネル状態に分割されます。カーネル状態は主に Kprobe モジュールを使用して、特定のルールを使用してシステム コール データをキャプチャし、それを解凍し、構成に関連付け、フィルター処理し、フィルター処理された解析データをユーザー状態に送信します。

ユーザー状態で取得されるデータには通常、一部の ID 情報しか含まれず、不完全です。 ilogtail はいくつかのプラグインを使用して、エンド側でプロセスやコンテナなどのメタ情報を収集し、この情報をカーネル状態で収集されたデータと関連付け/集約し、完全なデータをバックエンドに送信します。

クライアント側の状況は大体こんな感じです。完全なコレクション ソリューションは、サーバーの全体的な機能と組み合わせる必要もあります。データ収集用の DaemonSet の iLogtail に加えて、完全なソリューションには、より詳細なクラスターおよびコンテナー情報を取得するために Deployment の iLogtail の展開も必要です。このデータを使用すると、完全なホスト監視を構築できます。さらに、クラウドからクラウド資産情報を取得し、別の結合を実行して、より完全な K8s リンク トポロジを取得できます。

これらのデータを集約して処理すると、指標データが得られ、それを使用してグラフ表示用のダッシュボードを作成できます。ゴールデンインデックスと組み合わせたり、SLS インテリジェント検査サービスを適用したりすると、アラームイベントを取得できます。これらのイベントを処理すれば、完全な運用と保守のクローズドループを実現できます。

5. オープンソースと将来の展望

iLogtail はオープンソースになりました。誰でも議論と開発に参加できます。以降の計画は4つの部分に分かれます。

• エコシステムの拡張: Kafka Flusher はすでに 2.0 をサポートしており、OTLP は 1.0 の予備サポートを備えており、ClickHouse Flusher と GRPC Input/Output はどちらも計画段階にあります。
• フレームワークの強化: iLogtail はログから開発されており、データ モデル全体がログに偏っています。時系列データまたはトレース データは、プライベート プロトコルを通じてログ サービスの SLS にバインドされます。オープンソースについては、オープンであり、より優れたアーキテクチャサポートを備えていることを期待しています。
• eBPF : レイヤー 4 プロトコルの比較的完全な分析を提供し、トラフィックの監視に使用できます。 7 層プロトコルでは、Http/Redis/データベース タイプのプロトコルがサポートされています。共通 RPC フレームワークについては、まだコミュニティによって構築されていません。
• グローバル制御: 構成ソリューションを制御する機能。 Log Service には商用版のサポートがあり、この機能をオープンソースにも導入したいと考えています。現在、制御プロトコルと制御サービスの予備バージョンが利用可能です。将来的にはフロントエンドを構築し、K8s Operator や iLogtail 独自の可観測性データなどの機能を統合したいと考えています。

Github: https://github.com/alibaba/ilogtail