新世代のクラウドネイティブログアーキテクチャの設計と実践 - Loggie

オープンソースの詳細については、以下をご覧ください。

51CTO オープンソース基本ソフトウェアコミュニティ

​​https://ost..com​​

Loggieは、NetEase Yanxuanのビジネスの実際のニーズから生まれ、YanxuanとShufanの長期にわたる共同構築から成長し、NetEase Shufan、NetEase Media、中国工商銀行との緊密な協力により発展し続けました。広範なエコシステムにより、ビジネスニーズに基づいてプロジェクトを継続的に改善し、成熟させることができます。現在はオープンソースになっています: https://github.com/loggie-io/loggie。

1. 背景

Yanxuan ログ プラットフォームの初期の頃は、クラウド内のログを収集するために filebeat が使用され、クラウド外のログを収集するために flume が使用されていました。この間、私は運用と保守のトラブルシューティングに苦労しました。最もよく聞かれる質問は次のとおりです。

• 特定のログが収集されないのはなぜですか?
• 特定のログが繰り返し収集されるのはなぜですか?
• 見逃したログは回収できますか？
• 特定のログファイルが収集されないのはなぜですか?
• 特定のログ ファイルの収集速度が非常に遅い (遅延が 30 秒を超える) のはなぜですか?
• サービスが再リリースされた後、以前のログが消えてしまったのはなぜですか?
• …

さらに、2 セットのログ収集エージェントが同時に保守されるため、保守コストが高くなります。 Filebeat と Flume には、どちらも次のような重大な問題があります。

• 低い収集パフォーマンス:プロモーション期間中、一部のノードのログ出力速度は 100MB/秒を超えましたが、Filebeat の収集パフォーマンスの限界は 80MB/秒程度に過ぎず、Flume はさらに悪かったです。
• リソース使用率が高い: Filebeat は単一のノードで 100 を超えるファイルを収集し、CPU 使用率は 800% を超えます。 Flume はアイドル状態でも 200MB 以上のメモリを消費するため、プロモーション期間中は基幹業務システムへの影響を避けるためにフロー制限を有効にする必要があります。
• スケーラビリティが低い: Fliebeat の複雑なアーキテクチャと単一出力設計では、変化するビジネス ニーズに対応できません。

同時に、他のオープンソースのログ収集エージェントも調査したところ、それらはすべて、多かれ少なかれ上記の問題を抱えていることがわかりました。さらに、完全なログソリューションはおろか、運用と保守のトラブルシューティングに役立つ十分な観測性と運用と保守の手段 (ツール) もありませんでした。

そこで、私たちは独自の研究開発の道を歩み始めました。

Loggie は 2022 年初頭にオープンソース化されました: https://github.com/loggie-io/loggie

誰でも利用してコミュニティとともに成長できます!

2. 建築設計

Golang をベースにしており、従来のプロデューサー/コンシューマー モデルのマイクロカーネル設計を採用しています。パイプラインには、ソース、キュー、シンク、インターセプターの 4 つのコンポーネント概念のみがあり、インターセプターは必須ではありません。パイプラインは、構成のホット ロード、コンポーネントのホット スワップ、および相互影響を防ぐためのパイプライン間の強力な分離をサポートします。

（１）パイプライン設計

パイプライン設計の当初の目的は、主に分離でした。以前、運用保守で遭遇した深刻な問題: クラウドで Filebeat を使用して複数の業務の複数のログ ファイルを収集していましたが、ログ ファイルの 1 つの収集構成トピックが誤って削除されたため、Kafka への送信に失敗してブロックされ、物理マシン全体のすべてのログがブロックされました。したがって、相互の影響を避けるために、異なる業務や優先順位のログを分離するレーン分離方式が必要です。

拡張が簡単

パイプラインの簡潔な設計により、拡張が非常に便利になります。概念的には、パイプラインにはソース、キュー、シンク、インターセプターの 4 つのコンポーネントのみがあり、インターセプターは必須ではありません。概念が少ないほど、拡張機能の学習コストは少なくなります。さらに、スケーラビリティをさらに向上させるために、パイプライン内のすべてのコンポーネントがコンポーネントとして抽象化され、すべてのコンポーネントに一貫したライフサイクルと実装方法が備わっています。拡張が容易になるだけでなく、Loggie がコンポーネントを統一的に管理することも容易になります。

隔離とリロード

パイプラインに基づいて、構成のホットアップデートとコンポーネントのホットロードを実装しました。リローダーおよび検出コンポーネントは、K8S CRD、http リスニングなどに基づいてパイプライン ディメンションにリロードできます (予約済みインターフェイスは、zookeeper、consul、apollo などの構成センターに接続できます)。したがって、リロード機能を確保しながら、パイプライン分離の目的も達成されます。

機能強化：インターセプター

Interceptor は Loggie のオプション コンポーネントですが、Loggie で非常に重要な役割を果たします。 Loggie の拡張機能のほとんどは、電流制限、バック プレッシャー、ログのセグメント化、エンコードとデコード、文字エンコード、構造化などのインターセプターに基づいて実装されています。ユーザーは実際の状況に応じて対応するインターセプターを選択し、Loggie の適応性を向上させることができます。

完全な組み込みインターセプター: https://loggie-io.github.io/docs/reference/pipelines/interceptor/overview/。

3. ログ収集

ログ収集エージェントの場合、通常、次の 3 つの点の設計と実装に重点を置く必要があります。

• 効率的な収集:効率とは、高いパフォーマンスと低いエネルギー消費、つまり、より少ないサーバー リソースを占有しながらデータを迅速に収集する方法を指します。
• 公平性:たとえば、書き込まれる速度が速いファイルは、書き込まれる速度が遅いファイルのコレクションに影響を与えることはなく、最近更新されたファイルは、以前に更新されたファイルのコレクションに影響を与えることはなく、削除されたファイルは、適切に収集および解放されます。
• 信頼性:ログは失われません。これには、プロセスのクラッシュと再起動、サービスのリリース、移行、コンテナのドリフト、ダウンストリームのブロックが含まれます。

（１）効率的な収集

ログを収集する際には、次の問題が懸念されます。

• 新しく作成されたファイルを時間内に見つけるにはどうすればよいでしょうか?
• 最新の書き込みを時間内に見つけるにはどうすればよいでしょうか?
• ファイルを素早く読み取るにはどうすればいいですか?

これは実際には 2 つの問題から構成されています。

• イベント認識:ファイル イベントをタイムリーに検出します。たとえば、ファイルの作成、削除、書き込みなどです。
• ファイルの読み取り:ファイルの内容を効率的に読み取ります。ファイルの内容をできるだけ早く読み取り、ディスク IO を削減し、CPU を制御可能な状態に保ちます。

イベントの認知

ファイルイベント認識を実現するにはどうすればよいでしょうか?業界には 2 つのアプローチがあります。

• 定期的なポーリング:ディレクトリ ファイルの状態を定期的に確認します。
• OS イベント通知: OS ファイル イベントを登録し、OS から特定のファイル イベントの通知を受け取ります。

どちらの方法にも長所と短所があります。

• 予定されている投票:

• 利点: 実装が簡単、安全で信頼性が高い。
• デメリット: ポーリング時間間隔を決定するのが困難です。間隔が短すぎると CPU が消費され、間隔が長すぎるとイベントの検出が遅くなります。

• OSイベント通知:

• 利点: ファイルイベントをすぐに検出できる
• 欠点:

• 実装コストが高い（OS によって実装方法が異なるため、適応させる必要がある）。
• バグがあります: たとえば、最も一般的に使用されている Linux システム (https://man7.org/linux/man-pages/man7/inotify.7.html) にはいくつかのバグがあり、その中で最も影響が大きいのは、通知の損失、登録数の上限、ファイル名変更イベントで名前が変更されたファイル名が通知されないことです。
• 使用方法には制限があり、例えば、NFS（ネットワークファイルシステム）経由でマウントされたネットワークディスクやクラウドディスクには有効ではなく、FUSE（ユーザー空間のファイルシステム）には有効ではありません。

そのため、Loggie はこれら 2 つを組み合わせて、イベントをタイムリーに検出できる安全で信頼性の高いソリューションを実現します。

スケジュールされたポーリングと OS 通知を同時に有効にします。 OS 通知と比較的長い (loggie のデフォルトは 10 秒) スケジュールされたポーリングを使用して、両方で検出されたイベントをマージし、重複処理を減らして、両方の利点を享受できるようにします。

しかし、実際にテストしてみると、CPU 使用率が上昇することがわかりました。理由は次のとおりです。

• OS イベントが多すぎます:特にファイルの書き込み時には、対応する OS イベントが 2 つあります (chmod+write)。ファイルが頻繁に書き込まれると、OS イベントが多くなり、Loggie はシステム イベントの処理に疲れてしまいます。

では、私たちが本当に気にかけ、タイムリーに認識する必要があるイベントとはどのようなものか、再分析してみましょう。

• ファイル書き込みイベントですか?

ファイル書き込みイベントを時間内に検出できない場合はどうなりますか? 2つのケースがあります:

• ファイルが収集中の場合 (ファイル ハンドルを保持している場合)、ファイルの書き込みイベントは効果がありません。ファイルが読み取られているため、後続の書き込みも当然読み取ることができます。
• ファイルが非アクティブである場合 (つまり、ファイルが最後まで読み取られ、一定期間内に新しいコンテンツが見つからなかったか、ファイル ハンドルが解放された)、最新の書き込みコンテンツを適時に収集できるように、ファイル書き込みイベントを適時に検出できることが期待されます。

したがって、重要なのは「非アクティブ」なファイルへの書き込みイベントです。

• 新しい（スクロール）イベントをファイルしますか?

新しい出来事を時間内に発見できなかったらどうなるでしょうか?

最初のログが書き込まれてからそれが発見されるまでの間、ログの収集は遅延されます (loggie の場合、デフォルトのポーリング間隔は 10 秒なので、最大遅延は約 10 秒です)。ただし、イベントが感知されると、収集はすぐに追いつくことができます。したがって、新しいイベントを作成することはそれほど重要ではありません。

• ファイル削除事件？

削除イベントを時間内に発見できなかった場合はどうなるでしょうか?シナリオは3つあります。

• ファイルが削除された後も、不完全なファイルの収集を継続したい場合: この場合、削除イベントが必ずしも遅れる必要はありません。ファイルの収集が完了していない場合、時間内に発見された削除イベントは無意味です。ファイルの収集が完了すると、時間内に検出されない削除イベントは、ファイル ハンドルの解放遅延にのみ影響します。
• ファイルが削除された後、ディスク領域ができるだけ早く解放されることが期待されます。これにより、ファイル ハンドルの解放が遅れるだけになり、つまりディスク領域の解放が遅れることになります (約 10 秒)。
• ファイルが削除された後、ディスク領域を解放する前に、未収集のファイルに一定の許容時間が与えられることが期待されます。この状況により、ファイルの解放の最終的な遅延 = 許容時間 + イベント遅延時間が発生します。

したがって、削除イベントは重要ではありません。

• ファイル名変更事件？

上記と同じ、重要ではありません。しかし、ファイルの名前が変更されたかどうか、また名前が変更された内容を確認する方法は、確かに検討する価値のある質問です。 （まだ拡張されていません）

したがって、本当に重要なのは、非アクティブなファイル書き込みイベントです。したがって、私たちのアーキテクチャは次のように調整されます。

結果：

• これにより、ディレクトリやファイルの不要なシステム イベントの登録や監視、および対応する監視によって生成される大量のイベントが節約され、CPU 消費がさらに削減されます。
• イベント処理レイヤーでは、すべてのイベントが有効なイベントであるため、イベントのマージ手順が削除され、CPU 消費がさらに削減されます。

ファイルの読み取り

高速ファイル読み取りの原則:

1. ディスク IO の削減:つまり、毎回より多くのバイトを読み取ってメモリにバッファリングし、行ごとに処理する必要があります。
2. CPU は制御可能: GC とスレッドのスケジュールを削減します。

矛盾:

• 原則 1 は、読み取ったコンテンツを保持するために長い配列を繰り返し割り当てる必要があることを意味します。これは、大きなオブジェクトがたくさんあることを意味します。
• 原則 2 の GC が最も恐れているのは、まさに一瞬で消えてしまう大きなオブジェクトです。

したがって、ファイル読み取りの原理は次のようになります。

• 読み取りキャッシュ配列を再利用:大きなオブジェクトを再利用します。
• 読み取られたバイト数: 4k の n 倍、OS ページ キャッシュを最大限に活用します。

結果:読み取りパフォーマンスは 2G/s に達します (ローカル MacBook SSD 環境でテスト済み)。

（２）公平性

公平性: ファイル間の読み取りのバランスと、ファイル読み取りの枯渇 (読み取りが利用できない期間が長いために発生するデータ遅延) の回避に配慮しています。業界には 2 つのアプローチがあります。

• 各ファイルは読み取りスレッドに対応しており、OS は公平性を確保するためにファイルの読み取りをスケジュールします。

• 利点: 公平性を確保できます。
• デメリット: 同時に収集されるファイルが多い場合、CPU の消費量が高くなりすぎます。

• 一致したファイルは、更新イベントの逆順に 1 つずつ読み取られます。

• 利点: 実装が簡単。
• デメリット: 公平性が保証されず、以前に更新されたファイルは必然的に不足することになります。

したがって、Loggie は「タイム スライス」に基づく読み取り方法を実装します。

結果:ロガーのすべてのログ読み取りタスクを処理するために 1 つのスレッド (goroutine) のみが使用され、公平性が最大限に保証されます。

（３）信頼性

Loggie はデータが失われないようにし、少なくとも 1 回の保証を実装します。ファイル読み取りの場合、信頼性の実装には特定の特殊性があります。順序を保持する ACK が必要です。つまり、コレクション ポイント レコードの永続性の前提は、現在の ACK の前のすべての ACK が完了することです。したがって、順序保持 ACK のパフォーマンスを向上させるために、この設計にいくつかの最適化を加えました。

シンクによって送信された ack はすぐには保存されず、二重に圧縮されます。

• ACK チェーン ステージでは、最後の ACK のみが DB に送信されます。
• 送信された ACK は DB 内でさらに圧縮されます。

結果: ack 永続化のための CPU 消費量とディスク IO 時間が大幅に削減されました。

（４）性能比較

同じ状況で、Kafka に送信する場合の Filebeat との比較 (単一行、単一ファイル、同じ送信同時実行、解析シナリオなし):

• 単一ファイルの収集と比較すると、Loggie は Filebeat の CPU の約 1/4 しか消費しませんが、送信スループットは後者の 1.6 ～ 2.6 倍です。
• Filebeat の最大スループットにはボトルネックがあり、80MB/秒を超えると増加が困難ですが、Loggie の制限はより高く、複数のファイルを収集すると簡単に 200MB/秒以上に達します。

4. 運用と保守のガバナンス

Loggie をベースに、私たちは多くの運用・保守管理、アプリケーション分析を行ってきました。

（１）観察可能な

長期にわたる運用、保守、トラブルシューティングの経験に基づいて要約および改良された組み込みインジケーターにより、問題を迅速に発見して特定することができます。

ワンクリックで設定できる Grafana テンプレートが提供されています: https://github.com/loggie-io/installation/tree/main/prometheus/grafana-dashboard。

（２）完全性

ログの収集から最終的な保存までのプロセスは長くなる可能性があり、リンクに問題があるとログが失われる可能性があります。したがって、ログ収集ステータスを判断するには、ログ整合性検証メカニズムが必要です。私たちは通常、次の 2 つの問題を懸念しています。

• 特定のサービスのログデータは失われていますか?
• 失われたデータは復元できますか?

では、ログが失われたかどうかをどのように計算するのでしょうか?正確な整合性計算の基本原則:

• 計算ディメンション:マシン IP + ログファイルの一意の識別子

マシンの IP は確かですが、ログ ファイルを一意に識別するにはどうすればよいでしょうか?

ファイル名は重複する可能性があるため、ファイル名 + ファイルの inode (ファイル識別) が必要です。ただし、inode はディスク パーティション内でのみ一意であるため、ファイル名 + ファイル inode (ファイル識別子) + dev (ディスク識別子) に変更する必要があります。ただし、inode が再利用される状況もあります。ファイルが収集された後に削除されると、同じ名前のファイルに inode が再利用され、偽装された重複が発生します。したがって、ファイル コンテンツの最初の n 文字のエンコードを増やす必要があります。最終的な計算次元は、マシン IP + ファイル名 + inode + dev + {fistNBytes} です。

• ほぼリアルタイムのコンピューティング: 1時間ごとのバッチコンピューティング

小計バッチタスクを使用する主な理由は 2 つあります。

• 収集されたログはさまざまな理由で遅れる可能性があるため、ログ整合性の計算はそれほどリアルタイムである必要はありません。リアルタイムで計算すると、データが失われる可能性が高くなります。さらに、計算量が非常に大きいため、リアルタイム計算には適していません。
• 一方、より長い時間間隔 (T+1 など) を使用しない理由は、通常、ログはローテーションとクリーンアップ用に構成されているためです。間隔が長すぎると、計算された失われたログがローテーションやクリーンアップによって削除され、データを補充する機会が失われる可能性があります。

• 計算ロジック:ログ行開始オフセット + ログサイズ = 次のログ行開始オフセット
• 補足データ: Loggie のネイティブ ファイル データ読み取りインターフェイスを呼び出すことによって取得されます (読み取るオフセットとサイズを指定します)。

計算に必要なすべてのメトリックは、logggie によって収集されたログ メタデータに含まれています。

成果:シンプルで使いやすいプラットフォームの表示とデータ補足。

（３）ログ遅延

リンク全体のログの遅延を計算し、キーログも遅延に基づいてタイムリーにアラームを発行します。

エンドツーエンドの遅延計算の重要性:

• リンク マシン リソースのボトルネックの調査と分析にご協力ください。
• プロモーション期間中の合理的な拡大と縮小に関するガイダンスを提供します。
• 将来のログ増加に必要な容量を計画します。

（４）ログ品質

ログ収集後は、後続のビジネス監視アラームやビッグデータ ウェアハウスの処理、分析、計算アプリケーションに使用できます。したがって、丸太の品質がますます重要になります。では、ログの品質をどのように測定するのでしょうか?基本的に、ログは一連の処理と計算を経て、非構造化データから構造化データに変換されます。したがって、ログ構造化のプロセスにおけるログ品質スコアの計算を次のように定義します。

• ログセグメンテーション（フィールド抽出）処理：セグメンテーション失敗で1ポイント減点
• フィールドが存在しない場合は1ポイント減点されます
• 型変換処理：変換失敗で1点減点
• フィールド制約が失敗した場合は1ポイント減点されます

効果：

ログ品質管理の重要性:

• ログの品質を定量化し、サービスの進化を継続的に促進します。
• 下流のログ処理の効率を大幅に向上します。
• キーログの精度が向上しました。

（５）分析と応用

収集されたログ データに基づいて、ログの重要性をより高い次元に引き上げ、ログに真に強力なビジネス上の重要性を与える 2 つの重量級アプリケーションを開発しました。

リアルタイムのビジネス監視

次の要件を考慮してください。

• メインサイトのトランザクションが減少しているかどうかをリアルタイムで監視
• マスターステーションのUVアクセスのリアルタイム監視
• メインサイトの購入および注文状況をリアルタイムで監視
• リスク管理傍受のリアルタイム監視
• サービスQPSと異常状態のリアルタイム監視
• …

通常、これらの要件を実現するには長い開発サイクルが必要です。ただし、リアルタイムのビジネス監視に基づいて、プラットフォーム上で表示およびアラームを設定するには、わずか 5 ～ 10 分しかかかりません。

基本原則:

• 対応するビジネスログを印刷する
• プラットフォーム上で収集された対応するログを構成する
• 対応するログのデータモデルと、プラットフォーム上の対応する指標の計算ロジックを構成する（詳細、集計、その他の豊富な計算をサポート）
• アラームルールを設定する

結果：

主要なビジネス プロセスのビジネス サービス監視とアラームの開発コストを大幅に削減し、構成を通じて、ビジネスをリアルタイムで監視およびアラームする機能を備えることができます。

フルリンクビジネスモニタリング

最近ではマイクロサービスが普及しています。ユーザー操作には複数のマイクロサービス呼び出しが含まれる場合があります。次の質問について考えてみましょう。

• グローバルビジネスの観点から、該当サービスの運用状況を観察するにはどうすればよいでしょうか?
• ビジネスチェーンの観点から上流と下流の占有率と依存関係を発見するにはどうすればよいでしょうか?

フルリンクビジネスモニタリングが誕生しました。

取引リンクを例にとると、ホームページ -> 検索と推奨 -> 製品の詳細 -> カートに追加 -> 注文 -> 支払いのメインリンクから放射状に広がるいくつかの分岐リンクでは、全体的なトラフィックはどのようになっているでしょうか。 qps を呼び出す方法は?平均 rt はどのようになっていますか?エラー状態は何ですか?ビジネスチェーン全体の監視により明確な情報が提供されます。

コア実装原則:

• デフォルトでアクセスログを有効にするすべてのサービスを厳密に選択し、デフォルトですべてのサービスのアクセスログを収集します。
• プラットフォーム上のビジネスリンクプロセスに対応するサービスとインターフェースを構成する
• 主要リンクノードの監視アラームルールを構成する
• プラットフォームはワンクリックでフルリンクのリアルタイム監視アラームを生成します

ビジネスチェーン全体をリアルタイムで監視することは非常に重要です。これにより、より高い次元に立って、ビジネスプロセス全体のサービス呼び出しをグローバルな視点で検査し、チェーン内の弱いリンクや異常な状況を迅速に発見し、サービスの依存関係を最適化して、サービスの安定性を向上させることができます。

5. 結論

ロギーをベースにログプラットフォーム構造を厳選しました。ログベースの問題分析と診断に対する基本的な要求を満たすと同時に、ログの品質、問題のトラブルシューティングの効率、フルリンクの観測性と保守性の機能もさらに向上しました。一方で、機能を拡張し、アプリケーションシナリオを充実させています。簡単な設定で、ログに強力なビジネス上の意味と監視セマンティクスを持たせることができ、ビジネス リンクの異常をより高い次元で調査および監視し、リンク サービスとリソースの問題を事前に発見できるようになります。

オープンソースの詳細については、以下をご覧ください。

51CTO オープンソース基本ソフトウェアコミュニティ

​​https://ost..com​​