iLogtail オープンソース

著者 |徐克佳（イェ・モ）

2022 年 6 月末に、Alibaba Cloud iLogtail コードが完全にオープンソース化され、完全に機能する iLogtail コミュニティバージョンが正式にリリースされました。 iLogtail は Alibaba Cloud SLS の公式標準コレクターとして、長年にわたり Alibaba Group、Ant Group、およびパブリッククラウド上の多くの企業顧客に安定したサービスを提供してきました。現在、数千万のインストールがあり、毎日数十PBの観測可能なデータを収集しています。オンライン監視、問題分析・特定、運用分析、セキュリティ分析など、さまざまなシナリオで幅広く活用されています。この完全なオープンソースリリースにより、iLogtail Community Edition は、コア機能に関して初めて Enterprise Edition と完全に連携するようになりました。開発者は、Enterprise Edition に匹敵するパフォーマンスを備えた iLogtail クラウドネイティブの可観測性データコレクターを構築できます。

iLogtail の中心的な位置付けは、観測可能なデータのコレクターであり、開発者が統合されたデータ収集レイヤーを構築し、観測可能性プラットフォームがさまざまな上位レイヤーのアプリケーションシナリオを作成するのを支援します。 iLogtail は常にオープン性と共同構築の原則を順守しており、あらゆる形態のコミュニティの議論、交流、公共の構築を歓迎します。

可観測性に関する議論

人生で観察できる

可観測性とは、システムの外部出力からシステムの内部状態を推測し、測定することを指します。私たちの生活の中でも、観察できる多くの例に遭遇します。車のダッシュボードは典型的な観察可能な例です。車を運転する場合、運転の安全性は特に注意が必要な問題です。車のダッシュボードは、車の内部状態を識別するための閾値を下げます。自動車工学の専門家でなくても、ダッシュボードを通じて車の内部状態をすぐに確認できます。

さらに、私たちの日常的な医療行為も人体の観察可能な例とみなすことができます。古代では、医療水準は比較的遅れており、人体は一般的にブラックボックスでした。病気の原因は、表面的な観察、嗅覚、質問、触診によってのみ診断することができました。しかし、この方法は医師の経験に大きく依存しており、強力なデータによる裏付けが欠けていました。現代では、心電図やX線などの医療機器の発達により、人体の内部の仕組みがますます透明化され、医療水準が大幅に向上し、人々の健康に朗報をもたらしています。上記の例から、可観測性はシステムの内部状態を定性的にフィードバックできるだけでなく、最も重要なのは、システムの内部状態を定量的に実証できることであり、そのためには十分なデータ基盤、つまり観測可能なデータの品質と精度が必要であることがわかります。

機会と課題

私たちのソフトウェア業界に戻ると、数十年にわたる急速な発展を経て、開発モデル、システムアーキテクチャ、展開モデル、インフラストラクチャなど全体がいくつかの破壊的な変化を経験しました。これらの変更により、開発と展開の効率は向上しましたが、その結果、システム全体がより複雑になり、開発はより多くの人や部門に依存し、展開モデルと運用環境はより動的かつ不確実になり、観測可能なデータ収集に対する要件も高まりました。まず、開発モデルの迅速な反復の要求に適応し、DevOpsプロセスなどと高度に統合し、軽量かつ自動化された統合を通じて開発、テスト、運用保守の統合を実現する必要があります。また、分散型およびコンテナ化されたデプロイメントアーキテクチャの需要に適応し、ビジネスサービスを動的に、タイムリーに、正確に検出する機能を強化することも必要です。最後に、クラウドネイティブの開発により上流と下流の依存関係も増加したため、データソースとデータタイプに対する需要の増加にも適応する必要があります。

可観測性のデータ基盤

ログ、トレース、メトリックは可観測性データの 3 つの柱であり、基本的にさまざまな監視、アラーム、分析、トラブルシューティングのニーズを満たすことができます。ここでは、これら 3 種類のデータの特性、変換方法、適用可能なシナリオを大まかに分析します。

ログ: ソフトウェアの動作状況の伝達手段として、ログはシステムの動作状況を詳細に説明し、業務処理プロセスを復元することができます。一般的なログの種類には、操作ログ、アクセスログ、トランザクションログ、カーネルログ、フルログ、エラーログなどがあります。
メトリクス: システム内の比較的個別の特定の種類の情報の統計的集計を指します。一般的には、名前、ラベル、時間、値で構成されます。メトリクスデータの量は通常非常に少なく、コストは比較的低く、クエリ速度は比較的高速です。
トレース: 最も標準的な通話ログです。呼び出しの親子関係 (通常は TraceID、SpanID、ParentSpanID を通じて) を定義することに加えて、通常は操作のサービス、メソッド、属性、ステータス、期間などの詳細情報も定義します。

3 つの間の変換関係: ログは、呼び出しチェーンのシナリオが構造化された後に実際にトレースに変換され、集計およびダウンサンプリング操作の後にメトリックになります。

オープンソースソリューションに関する議論

業界で主流となっているオープンソースソリューションは、おおまかに 5 つの部分に分けられます。

収集側: 観測可能なデータの収集といくつかのフロントエンドデータ処理機能を実行します。クラウドネイティブの発展に伴い、収集側も時代のトレンドに適応し、K8s 収集にフレンドリーなサポートを提供する必要があります。一般的な収集ターミナルには、Filebeat、FluentD/Fluent-bIt、オープンソースの iLogtail などがあります。
メッセージキュー: 収集エージェントは通常、収集したデータをストレージシステムに直接送信するのではなく、メッセージキューに書き込んでピークシフトと谷埋めの役割を果たします。これにより、トラフィックのピークによって発生するストレージシステムのダウンタイムを回避します。一般的なメッセージキューには、Kafka、RabbitMQ などがあります。
コンピューティング: メッセージキュー内のデータを消費し、処理および集約した後にストレージシステムに出力するために使用されます。より一般的なものとしては、Flink、Logstash などがあります。
ストレージおよび分析エンジン: 収集されたデータの永続的なストレージ機能と、クエリおよび分析機能を提供します。一般的なストレージ分析エンジンには、Elasticsearch、ClickHouse、Loki などがあります。
視覚化: 収集されたデータの視覚化機能を提供するには、Kibana と Grafana を使用します。

さらに、Log Service SLS は、クラウドネイティブの観測・分析プラットフォームとして、ログ、メトリック、トレースなどのデータに対して、大規模かつ低コストのリアルタイムプラットフォームサービスを提供します。 SLS は、データの収集、処理、クエリと分析、視覚化、アラーム、消費、配信などのワンストップ機能を提供します。ユーザーは、SLS に基づく完全な可観測性プラットフォームを迅速に構築できます。 SLS の公式標準コレクターとして、iLogtail Enterprise Edition はビジネスデータの収集を担当します。 iLogtail Community Edition は Enterprise Edition から開発されており、その機能とパフォーマンスは当然 Enterprise Edition のほとんどの機能を継承しています。

iLogtail開発の歴史

iLogtail の前身は、Alibaba Cloud の Shennong プロジェクトに由来しています。 2013 年の公式インキュベーション以来、iLogtail は絶えず進化を続けています。

初期の頃、iLogtail は Alibaba Cloud 自体と初期の顧客の運用と監視のニーズに直面し、主に単一マシン、小規模クラスターから大規模クラスターまでの運用と保守の監視の課題を解決しました。この時点で、iLogtail は基本的なファイル検出機能とローテーション処理機能を備えており、ログのリアルタイム収集と監視、ミリ秒レベルの遅延のキャプチャ、シングルコアで約 10M/s の処理能力を実現できました。 Web フロントエンドは、集中化された構成ファイルの自動配布、30,000 を超える展開スケール、および数千の収集構成項目をサポートし、1 日あたり 10 TB のデータの効率的な収集を実現します。

2015年、アリババはアリババグループとアントファイナンシャル事業のクラウド移行を推進し始めました。 iLogtail は、ダブル 11 やダブル 12 などのショッピングフェスティバル中に、ほぼ 1,000 のチーム、数百万の端末、大規模なデータ収集という課題に直面し、機能、パフォーマンス、安定性、マルチテナントサポートの面で大幅な改善を行う必要がありました。 2017 年頃までに、iLogtail は正規表現、区切り文字、JSON など複数の形式でログを解析できるようになりました。さまざまなログエンコーディング方式をサポートし、データのフィルタリングや感度低下などの高度な処理機能もサポートしました。シングルコア処理能力は、ミニマリストモードでは 100M/s、正規表現、区切り文字、JSON などのモードでは 20M/s 以上に向上しました。コレクションの信頼性の面では、ファイル検出のバックアップ、ローテーションキューの順序保証、ログクリーンアップ損失保護、および CheckPoint 強化を提供するポーリングメソッドを追加しました。プロセスの信頼性に関しては、例外の自動回復、クラッシュの自動報告、デーモンプロセスを追加しました。全プロセスマルチテナント分離、マルチレベルの高低水位キュー、構成レベル/プロセスレベルのフロー制御、一時的なダウングレードなどのメカニズムを通じて、100 万を超える展開規模、数千のテナント、10 万を超える収集構成項目をサポートし、1 日あたり PB レベルのデータの安定した収集を実現します。

Alibaba がコアビジネスの完全なクラウド移行を推進し、iLogtail ログサービス (SLS) が Alibaba Cloud 上で正式に商用化されるにつれて、iLogtail はクラウドネイティブを全面的に採用し始めました。多様化するクラウド環境、急速に発展するオープンソースエコシステム、そして業界顧客からの大量の要求に直面し、iLogtail の開発の焦点は、クラウドネイティブへの適応方法、オープンソースプロトコルとの互換性、断片化された要求への対応方法などの問題の解決に移りました。 2018 年に iLogtail は docker コンテナコレクションを正式にサポートし、2019 年には containerd コンテナコレクションをサポートし、2020 年にはメトリックコレクションを完全にアップグレードし、2021 年にはトレースのサポートを追加しました。 iLogtail は、コンテナ化、K8S Operator の管理と制御、拡張可能なプラグインシステムを完全サポートすることで、数千万のデプロイメント、数万の社内外の顧客、数百万の収集構成項目をサポートし、1 日あたり数十 PB のデータの安定した収集を実現します。 2021 年 11 月、iLogtail はオープンソースへの第一歩を踏み出し、Golang プラグインコードをオープンソース化しました。オープンソース化されて以来、何百人もの開発者の注目を集め、多くの開発者がプロセッサおよびフラッシャープラグインを提供してきました。 2022 年 6 月に、C++ コアコードが正式にオープンソース化されました。それ以降、開発者はこのバージョンに基づいて完全なクラウドネイティブの観測可能なデータ収集ソリューションを構築できます。

iLogtailコアの利点

主な利点 - 軽量、効率的、安定性、信頼性

軽量

インフラストラクチャとして、観測可能なデータ収集エージェントをすべてのマシンに展開する必要があることがよくあります。たとえば、Alibaba には現在数百万台のマシンがインストールされており、毎日数十 PB の観測可能なデータを生成しています。したがって、メモリや CPU を少しでも節約すると、比較的大きなコスト上のメリットが得られます。特に、K8s Sidecar モードでは、iLogtail が業務コンテナと一緒にデプロイされるため、メモリに対する要件がより厳しくなり、業務規模の拡大に伴って iLogtail のデプロイ量も増加します。設計の初期段階から、iLogtail のリソース使用量に重点を置きました。メイン部分を C++ で実装し、プラグイン部分を Golang で実装することを選択しました。また、メモリと CPU の両方が同様のエージェントよりも優位になるように、いくつかの技術的な詳細を最適化しました (詳細については以下を参照)。

効率的な収集

ログ収集の場合、より一般的な方法はポーリングメカニズムです。これは、ログファイルが更新されたかどうかを定期的に検出してログ収集をトリガーするアクティブな検出収集方法です。同様に、オペレーティングシステムのイベント通知に依存するパッシブ監視イベントモードもあります (オペレーティングシステムには特定の要件があります)。一般的なイベント通知メカニズムは、Linux カーネルバージョン 2.6.13 で導入された inotify メカニズムです。ポーリングは、イベント通知よりも実装がはるかに簡単で、クロスプラットフォームを自然にサポートし、システム制限が少なくなっています。ただし、ポーリングでは収集の遅延とリソースの消費量が多く、ファイルサイズが大きい場合はポーリング時間が長くなり、収集の遅延が発生する可能性が高くなります。

収集効率とクロスプラットフォームのサポートのバランスをとるために、iLogtail はログ収集にポーリングと inotify を組み合わせたモードを採用しています。 inotify の低レイテンシと低パフォーマンス消費を活用するだけでなく、ポーリングを通じてオペレーティング環境の包括性も考慮します。

iLogtail は、イベントの形式でログ読み取り動作をトリガーします。このうち、ポーリングと inotify は 2 つの独立したモジュールであり、これらによって生成された作成/変更/削除イベントをそれぞれポーリングイベントキューと Inotify イベントキューに格納します。

ポーリングモジュールは、DirFilePolling と ModifyPolling の 2 つのスレッドで構成されます。 DirFilePolling は、ユーザー設定に従ってフォルダーを定期的に走査し、ログ収集設定を満たすファイルを変更キャッシュに追加する役割を担います。 ModifyPolling は、変更キャッシュ内のファイルステータスを定期的にスキャンし、以前のステータス (Dev、Inode、変更時間、サイズ) と比較する役割を担います。更新が見つかった場合、変更イベントが生成されます。

inotify はイベント監視メソッドです。ユーザー設定に応じて、対応するディレクトリとサブディレクトリを監視します。監視対象ディレクトリに変更があると、カーネルは対応する通知イベントを生成します。

イベントハンドラスレッドは、2 つのイベントキューを内部イベントキューにマージし、対応する作成/変更/削除イベントを処理して実際のログ収集を実行します。

さらに、ポーリングと inotify メカニズムの効率的な調整を確実にするためにいくつかの技術的手段も使用し、iLogtail の全体的な運用効率をさらに向上させました。

イベントのマージ: ポーリングイベントと inotify イベントがイベント処理動作を複数回トリガーするのを防ぐために、iLogtail はイベント処理の前に繰り返し発生するポーリング/inotify イベントをマージして、無効なイベント処理動作を減らします。
ポーリングの自動ダウングレード: システムがサポートしており、十分なリソースがある場合、レイテンシとパフォーマンス消費の点で、inotify はポーリングよりも優れています。そのため、ディレクトリに対して inotify が正常に動作できる場合、ディレクトリのポーリングは自動的にダウングレードされ、ポーリング間隔は CPU にほとんど影響を与えないレベルまで大幅に短縮されます。

ログシーケンシャルコレクション

逐次ログ収集は、ログ収集が提供する必要のある基本的な機能であり、ログ収集における難しい点でもあります。以下のシナリオを考慮する必要があります。

さまざまなログローテーションメカニズムに適応する: ログローテーションとは、ログが特定の条件 (時間またはファイルサイズ) を満たすと、ログの名前を変更して圧縮し、書き込みを続行するために新しいログファイルを作成する必要があることを意味します。さらに、異なるログライブラリによってローテーションされるファイルの形式は異なります。時間で終わるものもあれば、数字で終わるものなどもあります。
さまざまな収集パス構成方法に適応: 優れたログ収集エージェントは、ユーザーの構成方法を強制的に制限してはなりません。特に、ログ収集ファイル名を指定する場合、さまざまなユーザーの構成習慣に適応する必要があります。パスの完全一致か、*.log や *.log* などのあいまい一致かに関係なく、ログのローテーション中に収集される量が多すぎたり少なすぎたりしてはなりません。

ログファイルを順次収集するには、まずファイルの一意の識別子を定義する必要があります。ファイルシステムでは、ファイルは dev+inode の組み合わせによって一意に識別できることはわかっています。ファイルの移動操作によりファイル名が変更される可能性はありますが、ファイルの削除や作成は行われず、dev+inode は変更されません。したがって、dev+inode を使用すると、ファイルがローテーションされているかどうかを簡単に判断できます。ただし、dev+inode では、ファイルの一意性を同時に保証することしかできません。ファイルの急速な削除と作成に関しては、前後の 2 つのファイルの dev+inode は同じになる可能性が高くなります。したがって、純粋に dev+inode によってローテーションを判断することは現実的ではありません。 iLogtail は、ログファイルの最初の 1024 バイトのハッシュをファイル署名として使用するファイル署名の概念を導入します。 dev+inode+署名が一貫している場合にのみ、ファイルはローテーションされたファイルであると見なされます。さらに、iLogtail では、ファイルの順次収集を保証するファイルローテーションキューも導入されています。

収集の信頼性

基本的な観測可能なデータ収集コンポーネントとして、iLogtail はリソースとパフォーマンスを考慮するだけでなく、信頼性も重要な指標となります。 iLogtail は、一部の異常なシナリオに対しても十分な設計上の配慮がなされており、ネットワークの異常、突然のトラフィックの増加、プロセスの再起動などのシナリオでも、通常の収集タスクを完了できることが保証されています。

ログ処理がブロックされました

問題の説明: iLogtail を多数の異なるビジネスマシンに導入する必要があります。運用環境は複雑かつ変化しやすいものです。アプリケーションログがバースト的に書き込まれたり、ネットワークが一時的にブロックされたり、サーバーのクォータが不足したり、CPU/ディスクの負荷が高くなったりすることは避けられません。このような状況が発生すると、ログ収集の進行がログ生成の進行よりも遅れやすくなります。このとき、iLogtail は、合理的なリソース制約の下でこれらのログを可能な限り保持し、ネットワークが復旧したときやシステム負荷が減少したときにこれらのログをサーバーに収集し、収集のブロックによってログ収集の順序が乱れないようにする必要があります。

解決：

iLogtail は、ログ収集がブロックされているときに、収集されていないログファイルがファイルシステムによってリサイクルされるのを防ぐために、ローテーションされたログのファイル記述子を内部的に開いたままにします (ファイル参照カウントが少なくとも 1 になるように、ファイルローテーションキュー内のファイル記述子は常に開いたままになります)。同時に、ファイルローテーションキューを順次読み取ることで、ログ収集順序とログ生成順序が一致することが保証されます。
ログ収集の進行がログ生成の進行より長時間遅れ続け、リサイクルメカニズムがない場合、ファイルローテーションキューが無限に大きくなり、ディスクが上書きされる可能性があります。したがって、iLogtail はファイルローテーションキューに上限を設定します。サイズが上限を超えると、以降のリーダーの作成は禁止されます。このような極端な状況が継続的に発生した場合にのみ、ログ収集が失われます。もちろん、問題が拡大する前に、iLogtail はアラームを通じてユーザーに通知し、介入して問題を適時に解決するよう促します。

コレクション構成の更新/プロセスのアップグレード

問題の説明: 構成を更新またはアップグレードする場合、コレクションを中断してコレクションコンテキストを再初期化する必要があります。 iLogtail では、構成の更新やプロセスのアップグレード中にログがローテーションされた場合でも、ログが失われないようにする必要があります。

解決：

構成の更新/アップグレードプロセス中にログデータが失われないようにするために、iLogtail は、構成が再ロードされる前、またはプロセスがアクティブに終了する前に、現在のすべての収集状態をローカルチェックポイントファイルに保存します。新しい構成アプリケーション/プロセスが開始されると、最後に保存されたチェックポイントが読み込まれ、チェックポイントを通じて以前の収集状態が復元されます。
ただし、古いバージョンのチェックポイントが保存されてから新しいバージョンのコレクションリーダーが作成されるまでの期間中は、ログのローテーションが発生する可能性があります。したがって、チェックポイントをロードするときに、新しいバージョンでは、対応するチェックポイントのファイル名と dev+inode が変更されたかどうかがチェックされます。

ファイル名、dev+inode、署名が変更されていない場合は、チェックポイントに基づいてリーダーを直接作成できます。

ファイル名と dev+inode が変更された場合、対応する dev+inode が現在のディレクトリから検索されます。見つかった場合は、署名が比較され、変更されたかどうかが確認されます。署名が変更されない場合は、ファイルがローテーションされたとみなされ、新しいファイル名に従ってリーダーが作成されます。署名が変更された場合、ファイルは削除されて再作成されたとみなされ、チェックポイントは無視されます。

プロセスクラッシュ、ダウンタイム、その他の異常な状況

問題の説明: プロセスがクラッシュまたはダウンした場合、iLogtail はデータ損失を回避し、繰り返しの収集を最小限に抑えるためのフォールトトレラントメカニズムを提供する必要があります。解決：

プロセスがクラッシュまたはダウンした場合、終了前にチェックポイントを記録する機会はありません。したがって、iLogtail は収集の進行状況をローカルコンピューターに定期的にダンプします。通常のログファイルの状態を復元するだけでなく、ローテーションされたログを検索して、ログ損失のリスクを最小限に抑えます。

主な利点 - パフォーマンスと分離

ロックフリー設計とタイムスライススケジューリング

業界の主流エージェントは、データを読み取るために構成ごとに独立したスレッド/Go ランタイムを割り当てますが、iLogtail はデータを読み取るために 1 つのスレッドのみを構成します。主な理由は次のとおりです。

データ読み取りのボトルネックとなるのはコンピューティングではなくディスクです。構成されたすべてのイベント処理とデータ読み取りを完了するには、単一のスレッドで十分です。
シングルスレッド処理のもう 1 つの利点は、イベント処理とデータ読み取りをロックフリー環境で実行できるため、マルチスレッド処理よりもコスト効率が優れていることです。
iLogtail データ読み取りスレッドは、1 秒あたり 200 MB を超えるデータ読み取りを完了できます (SSD の速度はさらに速くなる可能性があります)。

ただし、シングルスレッドの場合、複数の構成間でリソースの割り当てが不均等になるという問題が発生します。単純な FCFS (First Come First Serve) 方式を使用すると、書き込み速度が非常に速いファイルが処理ユニットを占有すると、ファイルが処理されてリソースがアクティブに解放されるまで実行が継続されます。この方法では、収集された他のファイルが枯渇する可能性があります。

そのため、さまざまな構成間のスケジュールを可能な限り公平にし、コレクションファイルの枯渇現象の発生を防ぐために、タイムスライスベースのコレクションスケジューリングソリューションを採用しました。 iLogtail は、ポーリングイベントと Inotify イベントをロックフリーイベントキューにマージし、各ファイル変更イベントがログの読み取りをトリガーします。各読み取りは最後のレコードのオフセット位置から開始され、一定の時間スライス内で EOF までテキストを読み取ろうとします。タイムスライス内に読み取りが完了すると、イベント処理が完了し、イベントが削除されたことを意味します。それ以外の場合、イベントは再びキューの最後にプッシュされ、次の呼び出しを待機します。

上記の設計により、iLogtail は高いパフォーマンスでデータを収集できるようになります。詳細な比較データについては、https://developer.aliyun.com/article/850614 をご覧ください。

マルチテナント分離

タイムスライスベースの収集スケジュールにより、データの読み取り時に各構成のログが公平にスケジュールされることが保証され、マルチテナント分離の基本的な公平性は満たされますが、分離には役立ちません。たとえば、複雑な処理やネットワークの異常により一部の収集構成がブロックされた場合、ブロックされた構成は引き続き処理され、最終的にキューが上限に達してデータ読み取りスレッドがブロックされ、他の正常な構成に影響を及ぼします。この目的のために、さまざまなコレクション構成間での読み取り、解析、および送信手順の効果的な調整を実現するために、複数レベルの高水位および低水位のフィードバックキューのセットを設計しました。異なる構成間の分離をより適切に実現するために、iLogtail は構成ごとにキューのセットを作成します。

マルチレベル: iLogtail は通常、収集から出力まで、読み取り、解析、送信という 3 つのステップを経ます。 iLogtail は隣接する各ステップの間にキューを設定します。
高水位と低水位: 各キューには、高水位と低水位が 2 つ設定されています。水位が高い場合は緊急を要しないデータの書き込みを停止し、低水位に戻った場合にのみ再度書き込みを許可します。
フィードバック: 現在のキューからデータを読み取る準備をするときに、次のレベルのキューのステータスが同期的にチェックされます。次のレベルのキューの水位が高い場合は、読み取りがスキップされます。現在のキューが高水位から低水位までのデータを消費すると、関連付けられている前のレベルのキューに非同期的に通知されます。

極端なシーン処理

主にイベント処理、データ読み取りロジック、データ送信制御など、いくつかのブロッキングシナリオの信頼性も考慮する必要があります。

イベント処理はデータの読み取りとは関係ありません。読み取り関連のキューがいっぱいの場合でも、通常どおり処理されます。ここでの処理は主にファイルメタを更新し、ローテーションファイルをローテーションキューに配置します。これにより、構成ブロックの場合にファイルがローテーションされてもデータが失われないことが保証されます。
構成に関連付けられた解析キューがいっぱいの場合、イベントがキューの最後に戻されると、無効なスケジュールが増え、CPU がアイドル状態になります。したがって、解析キューがいっぱいになると、iLogtail はイベントを専用のブロックされたキューに配置します。解析キューは非同期フィードバックを受信すると、ブロックされたキュー内のデータをイベントキューに戻します。
Sender 内の各構成済みキューは SenderInfo に関連付けられており、構成の現在のネットワークが正常かどうか、クォータが正常かどうか、および許可される最大送信速度が記録されます。毎回、Sender は SenderInfo のステータス (ネットワーク障害の再試行、クォータ制限の再試行、ステータスの更新、フロー制御、その他のロジックを含む) に従ってキューからデータを取得します。

コアな利点 - プラグイン拡張機能

iLogtail プロセスは 2 つの部分で構成されます。1 つは C++ で記述されたメインのバイナリプロセスで、管理と制御、ファイル収集、C++ 高速処理機能を提供します。もう1つはGolangで書かれたプラグイン部分で、プラグインシステムを通じて処理能力の拡張とより豊富な上流・下流のエコシステムサポートを実現します。

上流および下流のエコロジー: プラグインシステムの拡張により、iLogtail は現在、ログ、メトリック、トレースなどの多くのデータソースへのアクセスをサポートしています。ファイル収集に加えて、データソースは HTTP、MySQL Binlog、Prometheus、Skywalking、syslog などの標準プロトコルもサポートします。データ出力エコシステムもSLSからKafka、gPRCなどへと徐々に拡大しており、今後はClickHouse、ElasticSearchなどもサポートしていく予定です。
処理能力の拡張: iLogtail は PipeLine 設計を採用しています。データは入力プラグインを通じて収集され、収集構成で設定されたプロセッサによって処理され、アグリゲータープラグインによってパッケージ化され、最終的にフラッシャーを通じてログストレージシステムに送信されます。データ処理環境には、データのセグメンテーション、フィールドの抽出、フィルタリング、データの拡張などの側面が含まれており、すべてのプラグインを自由に組み合わせることができます。さらに、iLogtail は、正規表現、JSON、セパレーターなどの特定の形式に対して C++ アクセラレーション機能も提供します。
迅速な反復: 開発者は、独自のニーズに応じて対応するプラグインをカスタマイズして開発することもできます。各プラグインは互いに独立しているため、開発者はインターフェース仕様に従って開発するだけでよく、参入障壁が低くなります。プロセッサプラグインインターフェイスを例にとると、処理プラグインをすばやく提供するには、次のインターフェイスを実装するだけで済みます。

 //プロセッサはフィルタにもなる
型プロセッサインターフェース{
 // init は、ソケット、ミューテックスなどのシステム リソースの初期化を要求します...
 初期化(コンテキスト)エラー

//説明は入力に対して1文の説明を返します
 説明( )文字列

//指定されたメトリックにフィルターを適用します
 ProcessLogs ( logArray [ ] *プロトコル.Log ) [ ] *プロトコル.Log
 }

コアな利点 - K8s コレクション機能

コンテナオーケストレーション分野の標準として、Kubernetes (K8s) はますます多くのシナリオに適用されるようになっています。 iLogtail は、K8s での完全なデータ収集機能も提供します。

展開モード

Kubernetes シナリオでは、iLogtail は主に 3 つの動作モードを使用します。

DaemonSetアプローチ

モード: 各 K8s ノードに iLogtail をデプロイし、iLogtail を使用してノード上のすべてのコンテナのログをログシステムに収集します。

利点: 操作と保守が簡単、リソース消費が少ない、コレクションコンテナーの標準出力とテキストファイルのサポート、柔軟な構成。

欠点: iLogtail はノード上のすべてのコンテナのログを収集する必要があります。コンテナ間の分離が弱く、多数のビジネスを持つクラスターではパフォーマンスのボトルネックが発生する可能性があります。

サイドカー方式:

モード: iLogtail コンテナは POD 内のビジネスコンテナとともに実行され、POD 内のビジネスコンテナによって生成されたログを収集します。

利点: サイドカー方式では、ログを収集する必要があるコンテナーごとにサイドカーコンテナーが作成され、マルチテナントの分離とパフォーマンスが向上します。

デメリット: 多くのリソースを消費します。

展開方法:

モード: ビジネスコンテナーが PVC を使用してログディレクトリをマウントする場合、または K8s メタデータを取得するために API サーバーにグローバルに接続する必要がある場合は、データ収集のためにクラスターに単一コピーの iLogtail デプロイメントをデプロイすることを選択できます。

収集原則

K8s の登場以来、docker ランタイムが主流となってきましたが、K8s が dockershim を削除するにあたり、K8s ではコンテナランタイムとして containerd または CRI-O を優先することを公式に推奨しています。 Dockerのシェアは依然として主流ではあるものの、年々減少傾向にあります。 containerd と cri-o の地位は年々急速に高まっています。したがって、包括的な K8s サポートの観点から、iLogtail は主流のランタイムをサポートする必要があります。現在、Docker と Containerd の 2 つのコンテナエンジンのデータ収集をサポートしています。 K8Sは、強力な操作とメンテナンスの展開、弾性スケーリング、および障害回復機能を提供し、分散システムの開発と管理を大幅に促進します。ただし、これにより、観察可能なデータを収集することの難しさも増加します。特に、いくつかの機械学習トレーニングタスクなど、いくつかの短いジョブシナリオでは、ライフサイクルが数分または数秒でさえあるため、収集する必要があるコンテナを迅速かつ正確に発見することが重要です。

自動コンテナの発見とリリース

ilogtailホストのコンテナランタイム（Docker Engine/containd）の靴下にアクセスして、コンテナ情報を取得します。

Dockerイベントと漸進的な取得メカニズムを監視することにより、コンテナの追加と放出をタイムリーに検出できます。

コンテナコンテキスト情報取得

コンテナレベルの情報：コンテナ名、ID、マウントポイント、環境変数、ラベル

K8S階層情報：ポッド、名前空間、ラベル。

コンテナフィルタリングと分離：コンテナコンテキスト情報に基づいて、コレクションコンテナフィルタリング機能を提供し、異なる収集コンテナに異なる収集構成を適用できます。
メタ情報協会：コンテナコンテキスト情報とコンテナ環境変数に基づいて、ログ内のK8Sメタ情報を濃縮する機能を提供します。
コレクションパスディスカバリー

標準出力：ILOGTAILは、追加の手動構成を必要とせずに、コンテナメタデータに基づいて異なるランタイムの標準出力形式とログパスを自動的に識別できます。

コンテナ内のファイル：オーバーレイおよびオーバーレイ2ストレージドライバー用に、iLogTailはログタイプとコンテナランタイムに基づいてコレクションパスを自動的にスプライスできます。これはシンプルで効率的です。

さらに、CICD自動化された展開と運用とメンテナンスの要件が高いユーザーの場合、iLogTailはK8Sのネイティブサポートも提供し、CRDを通じてコレクション構成管理をサポートします。現在、この機能はエンタープライズバージョンでのみ利用可能であり、将来的に徐々にオープンになります。このソリューションでは、iLogtail K8SはAliyunlogconfigという名前の新しいCustomResourcededefinition拡張機能を追加します。同時に、Alibaba-Log-Controllerが開発され、AliyunlogConfigイベントを監視し、IlogTailコレクション構成を自動的に作成してログコレクションを完了しました。

Enterprise Edition vs Community Edition

違いの比較

ilogtailがオープンソースになった後、現在2つのバージョンのブランチがあります。

Enterprise Edition：Alibaba Cloud SLSの公式Webサイトからダウンロードできます。主にSLSを提供します。
コミュニティエディション：GitHubリポジトリ、リリースページからダウンロードします。

IlogTailはオープンソースであり、テクノロジー共有と開発者の共同構築の原則を順守しています。したがって、そのコア関数は完全にオープンソースです。したがって、そのコアコレクション機能（コレクションおよび処理機能、パフォーマンス、信頼性など）は、エンタープライズバージョンの機能に完全に匹敵すると考えることができます。コミュニティバージョンよりもエンタープライズバージョンの利点は、主にAlibaba Cloudの基本的な機能の統合にあります。

Alibaba Cloud SLSの公式標準コレクターとして、SLSとシームレスに統合されています

SLSプラットフォームは、ILOGTAILに強力な管理および制御機能とリッチAPIサポートを提供します。

SLSは、ログ、メトリック、およびトレースに統一されたストレージおよび分析機能を提供します。 IlogTail Enterprise Editionを使用してSLSにデータを収集すると、さまざまな上層層アプリケーションをより適切に構築できます。 SLSの助けを借りて、ログコンテキストのプレビューなどの高度な機能を1回実装できます。

SLSプラットフォームの助けを借りて、サードパーティエージェントの管理および制御機能を実現できます。たとえば、SLSは将来、DeepFlowと深く統合されます。

観測可能性プラットフォームとして、SLSは、観察可能なデータストレージと分析の機能を搭載するだけでなく、アーキテクチャの展開を簡素化できるトラフィックパイプラインの役割を果たします。

SLS用のCloudLensは、iLogtailの収集ステータスとデータフローを監視するための便利な手段を提供します。

サポートされているオペレーティングシステムとシステムアーキテクチャはより豊富で、Enterprise EditionはWindowsシステムとARMアーキテクチャをサポートしています。

Alibaba Cloud Serviceサポート

自動化されたインストールおよび展開機能は高くなっています。 Alibaba Cloudの操作およびメンテナンスサービスの助けを借りて、iLogTailはバッチに自動的にインストールできます。

Alibaba Cloud ECS、ACK、ASK、EMRなどと高度に統合されており、ワンクリックでインストールして展開できます。収集されたデータにすばやくアクセスして、組み込まれた分析できます。

エンタープライズエディションサービス保証

SLSは、エンタープライズアプリケーションシナリオの最も完全でタイムリーなドキュメント/ベストプラクティスサポートを公式に提供します

タイムリーな専門家サービス（作業注文、グループサポート）および需要の受け入れ。

大規模/複雑なシナリオに対する専門的なサポート：K8Sショートジョブ、シングルノードの高トラフィックログ、大規模なコレクション構成など。

SLSに基づくクラウドネイティブの観測可能性プラットフォーム

SLSは、ログ、メトリック、トレースに統一されたストレージおよび分析機能を提供し、トラフィックパイプラインとしても機能します。強力なデータ処理機能を備えています。 SLSに基づいて、クラウドネイティブの観測可能性プラットフォームをすばやく構築できます。インテリジェントアラームセンターとインテリジェントアルゴリズムサービスは、プラットフォームのインテリジェンスレベルをさらに強化します。このプラットフォームに基づいて、ユーザーはさまざまなITOPS、DEVOPS、SECOPS、およびBusinessOpsの上位レベルのアプリケーションを便利かつ効率的に構築できます。 SLSの公式標準コレクターとして、IlogTail Enterprise EditionはSLSデータアクセスの分野で主導的な役割を果たし、大量のアクセストラフィックを搭載しています。

オープンソースコミュニティの見通し

テクノロジーの共有は、常にilogtailの哲学でした。より多くの開発者が共同構築に参加することを期待し、歓迎します。開発者と協力して、IlogTailの上流および下流のエコシステムを豊かにしたいと考えています。開発者エクスペリエンスを向上させるために、iLogTailのコア機能とフレームワーク機能を改善し続け、開発のしきい値をさらに低下させ、テストシステムの構築を強化し、開発者に必要な技術サポートを提供します。コレクション構成を効率的に管理する方法は、常に観察可能なコレクターにとって苦痛です。この目的のために、近い将来、サーバー側のグローバルコントロールソリューションとIlogtail監視ソリューションもオープンします。また、開発者は、共同構築に参加し、統一された制御エコシステムを一緒に構築することも歓迎します。最後に、IlogTailは、観測可能性フィールドの標準としてOpentelemetryを積極的に採用します。 K8Sネイティブエクスペリエンスも私たちが追求しているものであり、IlogTailオペレーターを立ち上げることも計画しています。

ilogtailについて

iLogTailは、Alibaba Cloud SLSが提供する観察可能なデータコレクターです。サーバー、コンテナ、K8、埋め込みシステムなどの複数の環境で実行できます。数百種類の観察可能なデータ（ログ、監視、トレース、イベントなど）のコレクションをサポートし、数千万個のインストールを持っています。現在、iLogtailは公式に開放されています。建設に使用して参加してください。