分散タスクの優れたロギングプラクティスは何ですか？

次の設定があります。

複数のワーカーを作成し、計算を実行し、計算が完了した後に終了します。

そのため、毎回異なるインスタンスがタスクを実行するため、各ホストには独自のログファイルがあり、ファイルの膨大なリストが作成されます。

それは良い習慣ですか？そうでない場合、この特定のユースケースでタスク処理を記録するより良い方法は何でしょうか？

PS：私のインフラストラクチャはサーバーレスです。したがって、今のところ、（AWS）CloudWatchにログインしています。ただし、AWSとは独立して質問に回答し、可能な限りサーバーレス設定に合わせてください。

「サーバーレス」とは、ほとんどの場合、比較的単純なマイクロサービス、通常は小さなwebappまたはRESTフロントエンドに自動的に接続される単一の機能を持っていることを意味します。従来のWebサービスで使用するのと同じ概念が適用されます。通常は、リモートsyslogとElasticSearchライターが混在しています。

ネットワークまたはリモートsyslogは古くから存在し、その周りにはかなり堅牢なツールセットがあります。中央のsyslogサーバーを実行する必要がありますが、プロトコルは非常に単純であり、ログの送信に使用できるすべての言語の純粋なクライアントライブラリがあります。リモートsyslogの一般的な問題の1つは、伝統的にUDPに基づいていることです。これは、負荷が高いと、一部のログメッセージが失われる可能性があることを意味します。これはカスケードオーバーロードの回避に役立ちますが、注意する必要があります。一部の新しいsyslogデーモンもTCPベースのプロトコルをサポートしていますが、クライアントサポートはあまり統一されていないため、調査を行ってください。

最近ではあるが非常に人気のあるものは、ElasticSearchへのロギングです。これは、KibanaダッシュボードとLogstash Takelit（多くの場合ELK、ElasticSearch + Logstash + Kibanaと呼ばれる）のために便利です。AmazonはホストされたElasticSearchオプションも提供しているため、開始が多少簡単になっています。ESは比較的単純なREST APIを使用するため、HTTPクライアントを備えたすべての言語（読み取り：すべて）でESにログを記録できますが、部分的なシステム停止の場合はネットワーク操作のブロックに注意してください（つまり、アプリは、成功することはなく、ユーザーリクエストの処理を停止するロギングコールでスタックすることはありません）。

より複雑なロギングトポロジは想像力によってのみ制限されますが、最近では、非常に複雑なログ配布システムの連結点として、Kafkaデータベース/キュー/コールしたいものを何でも使用することがわかります。

「サーバーレス」側では、通常、ネットワークレベルでこれらのシステムと直接統合する必要があるため、ローカルファイルに書き込むのではなく、サービス/機能からsyslogまたはESにログデータを直接送信します（ただし、ローカルデバッグと開発にも使用できます）。

この答えは、スケーラビリティの考慮事項に関するものです。ワーカーの数が多い場合、および/または複数のワーカーが同時に高率でログを生成できる場合。

はい、複数のログファイルを同時に使用することをお勧めします。

複数のワーカーからのログを単一のログファイルにリアルタイムで結合しようとすると、問題が発生します。

• メッセージの損失を防ぐためにブロッキングメカニズムを使用すると、ワーカーの速度が低下します
• ログメッセージは、結合されたログファイルで順不同で表示される可能性があります
• ログを結合する集中ログ機能は、書き込み速度が制限されるため過負荷になる可能性があり、メッセージは失われます

シャーディングログファイル（同時にアクティブな複数のログファイルを使用）は、それ自体が高性能でスケーラブルな集中ログサービスを提供するホスティングプロバイダーによって使用される手法です。たとえば、ログをファイルにエクスポートする場合、GoogleのStackDriver Loggingは複数のシャードログファイルを生成します。Google Cloud Storageのログエントリから：

あなたはときにログをエクスポートクラウドストレージバケットに、のStackdriverログは、バケットに一連のファイルを書き込みます。ファイルは、ログの種類と日付ごとにディレクトリ階層に編成されます。ログタイプは、などの単純な名前syslogまたはのような複合名にする ことができますappengine.googleapis.com/request_log。これらのログがという名前のバケットに保存されているmy-gcs-bucket場合、ディレクトリの名前は次の例のようになります。

my-gcs-bucket/syslog/YYYY/MM/DD/
my-gcs-bucket/appengine.googleapis.com/request_log/YYYY/MM/DD/

1つのバケットに、複数のログタイプのログを含めることができます。

リーフディレクトリ（DD/）には複数のファイルが含まれ、各ファイルには、ファイル名で指定された期間のエクスポートされたログエントリが保持されます。ファイルは分割され、その名前は分割番号で終わるか、 SnまたはAn（n = 0、1、2、...）です。たとえば、以下に格納される可能性のある2つのファイルを次に示しますdirectory my-gcs-bucket/syslog/2015/01/13/。

08:00:00_08:59:59_S0.json
08:00:00_08:59:59_S1.json

これら2つのファイルには、syslog0800 UTCから始まるすべてのインスタンスのログエントリが含まれています。すべてのログエントリを取得するには、各期間のすべてのシャード（この場合はファイルシャード0および1）を読み取る必要があります。書き込まれたファイルシャードの数は、ログエントリの量に応じて期間ごとに変化します。

このような高性能のロギングサービスは、ファイルへのロギングに代わるものを提供することもできるため、関心がある場合はログファイルの管理を完全に回避できます。

• ログをデータベースに直接挿入します。たとえば、Stackdriver Loggingはログを直接Google BigQueryにプッシュできます
• ログを処理エンジンに直接プッシュします。たとえば、Stackdriver LoggingはログをGoogle Pub / Subトピックにプッシュできます

最後に、リアルタイムのログファイルのマージが複数のログファイルを持つ必要がない場合、オフラインログ管理に役立ちます：

• プログレッシブログバックアップ、圧縮、アーカイブ、および最終的な廃棄スキームを簡単に考案
• 複数セットのログ（ログファイル）の並列処理が可能であり、ボトルネックの影響を軽減/回避
• ファイルの分割と再書き込みは不要