効率的なログ管理と監視のベストプラクティス

[51CTO.com クイック翻訳] クラウド運用の経験がある読者は、クラウドネイティブ アプリケーションが分散型で動的であり、そのようなアプリケーションはすべて、通常、コンテナーやサーバーレス関数などの一時的なテクノロジを使用してデプロイされることを知っているはずです。これらのクラウドネイティブ アプリケーションを管理する場合、いつでもエンドツーエンドの可視性を提供することが特に重要です。

[[265226]]

同時に、クラウドネイティブ システムの膨大なデータ フローと抽象的な複雑さのため、さまざまな予測不可能な中断やダウンタイムを制御するために、強力な監視とログ記録を確立する必要があります。この記事では、クラウド ネイティブ アプリケーションを記録および監視するときに学習して従う価値のあるさまざまなベスト プラクティスと標準について説明します。

1. ホストされたログソリューションを使用するか、独自のインフラストラクチャを構築する

まず、ローカルに展開されたシステムと同様に、ログ記録はアプリケーションの動作状態を反映する必要があるという事実に加えて、クラウドネイティブ アプリケーションでは、ログ記録ソリューションは高可用性、分散処理、インテリジェント フェイルオーバーの原則にも従う必要があります。これこそが、最新のクラウド ネイティブ アプリケーションと従来のモノリシック アプリケーションの違いです。

この目的を達成できる一般的なツールには、Elasticsearch、Fluentd、Kibana（これら 3 つは総称して EFK スタックと呼ばれることが多い）などがあります。大規模なデータ分析を処理し、結果をリアルタイムで表示するように設計されています。これらは、データに対する複雑な検索やクエリの実行をユーザーを支援するだけでなく、API に基づくオープンな統合や他のツールとの統合もサポートします。もちろん、これらのツールは業界では一般的に使用されていますが、ガバナンスの目的を満たすためにそれらをうまく統合するには、ある程度の作業が必要です。

上記のように自分でシステムを構築する方法と比較すると、ベンダーが構築し、柔軟な拡張が可能なホスト型ログ ソリューションを使用する方が便利で実用的です。一般的なものとしては、Elastic Stack (を参照) などがあります。このような既成の統合ソリューションを使用すると、クラウド内のアプリケーション データ ソースとターゲットを接続するだけで、さまざまなアプリケーション ログを簡単に取得して分析できます。その結果、独自のログ記録インフラストラクチャを構築する方法を考えるのではなく、貴重な時間を他の重要なアプリケーションの監視とログ記録に使うことができます。

2. 監視すべきものと記録すべきでないものを把握する

誰もが知っているように、監視するデータ レコードが増えるほど、本当に重要なデータを見つけるのが難しくなります。同時に、ログ管理タスクが増えると、ログの保存と管理のプロセスも複雑になります。

したがって、何を記録する必要があるかについて慎重に考える必要があります。たとえば、どのようなタイプの本番環境でも、コンプライアンスや監査の目的にとって重要なデータは完全にログに記録する必要があります。さらに、パフォーマンスやユーザー エクスペリエンスの問題の解決に役立つデータや、セキュリティ インシデントに関連するデータも継続的に監視および記録する必要があります。

では、記録する必要のないデータ カテゴリは何でしょうか?たとえば、テスト環境のデータはソフトウェア配信パイプラインの重要な部分ではないため、コンプライアンスやセキュリティ上の理由から、このようなデータは記録されません。さらに、ユーザーが「追跡しない」設定を有効にしている場合は、そのユーザーに関連付けられたデータを一切記録しません。同様に、ログ記録および保存手順がデータのセキュリティ要件を満たしていることが確実になるまで、特定の機密性の高いデータ (クレジットカード番号など) の記録は避ける必要があります。

3. ログのセキュリティと保持ポリシーを実装する

ログは機密データと接触する可能性があるため、ログ セキュリティ戦略には、クライアントの個人データや API 内部アクセス キーなどの機密データ ソースのチェックを含める必要があります。同時に、ログを第三者に送信する前に、機密データが匿名化（感度低下とも呼ばれます）または暗号化されていることを確認する必要があります。ログ データをログ管理サーバーに安全に送信するには、クライアントとサーバー間で TLS や HTTPS などのエンドポイント暗号化方式を有効にして設定する必要があることがよくあります。

同時に、異なるソースからのログには、異なる保持ポリシーを割り当てる必要がある場合があります。たとえば、一部のアプリケーションは、数日以内にトラブルシューティングにのみ関連する場合があります。一方、セキュリティ関連のトランザクション ログやビジネス トランザクション ログには、より長い保存期間が必要です。したがって、ログ ソースに対する保持戦略は柔軟かつきめ細やかである必要があります。

4. ログの保存

ログストレージの容量を計画する際には、高負荷時のピークトラフィックを十分に考慮する必要があります。システムがスムーズに動作している場合、アプリケーションによって毎日生成されるデータの量はほぼ一定であり、主にシステムの利用率とサービスの毎日のトランザクション量によって決まります。システムに重大なエラーが発生すると、通常、ログの量が急増します。

したがって、ログ ストレージが割り当てられたスペースの制限に達し、"スライディング ウィンドウ" 戦略を設定していない場合は、システム エラーの修復に重要なログを保存できない可能性があります。ここでのスライディング ウィンドウとは、ログ ストレージがバッファー上で周期的に動作し、アプリケーション データがストレージ領域の制限に達する前に最も古いデータを自動的に削除して、ログを保存し続けることを意味します。

「システムのダウンタイムよりも悪いことは何ですか?」と誰かが尋ねたら、私の答えは、「トラブルシューティング情報が不足しているため、ダウンタイムが長引く」ということです。ログストレージを設計する際には、スケーラビリティと信頼性を維持する必要があることがわかります。

さらに、ログストレージには別のセキュリティポリシーを装備する必要があります。さまざまなログをリアルタイムかつ集中的に中央リポジトリに送信します。犯罪者がインフラストラクチャにアクセスできる場合は、証拠の改ざんを防ぐために、ログを別の場所に送信することを検討できます (たとえば、ログ サービスに特化した SaaS を使用する)。

5. ログを確認して維持する

ログ データのメンテナンスが不十分だと、トラブルシューティングにかかる​​時間が長くなり、機密データが漏洩し、ログの保存コストが高くなる可能性があります。アプリケーションログの出力を定期的に確認し、サービスの可用性、操作性、セキュリティなどの側面を検討して、必要に応じてシステムを調整する必要があります。

意味のあるログメッセージを作成する

ログに部分的かつ「不可解な」エラー コードと情報のみが含まれている場合、運用部門はそれらの解釈に時間を費やす必要があります。読みやすく、役に立つログ メッセージだけが、迅速なトラブルシューティングの鍵となります。したがって、あらゆる種類の開発者は、貴重な診断時間を節約するために、意味のあるログ情報を提供するよう最善を尽くす必要があります。

構造化されたログ形式を使用する

構造化ログ形式 (JSON やキー/値形式など) には、タイムスタンプ、重大度、プロセス ID、トランザクション ID などのメッセージ関連のデータ フィールドを含めることができます。すべてのアプリケーションに統一されたログ形式をまだ採用していない場合は、システムがログを効率的に構造化された方法でマージ、解析、保存できるように、できるだけ早くログ生成を正規化および標準化してください。

ログレベルを設定可能にする

実際のシステムでは、一部のアプリケーション ログが長すぎる場合や、一部のアプリケーション ログに十分なサービス情報が含まれていない場合があります。したがって、調整可能なログ レベルを通じて、さまざまなログの詳細レベルを構成する必要があります。さらに、ログのレビュープロセスでは、詳細レベルと個人のプライバシーデータの非開示と、感度低下と暗号化によるセキュリティ情報の保護との間のバランスを確立することにも注意を払う必要があります。

監査ログを継続的に確認する

セキュリティ問題の迅速な解決は、監査ログの継続的なレビューにかかっています。リアルタイム ログ分析で、auditd や OSSEC エージェントなどのセキュリティ ツールを構成することにより、潜在的なセキュリティ問題を指摘するさまざまなアラート ログを生成できます。特定のアラート ログ レベルが確立されているため、運用スタッフは疑わしいアクティビティをすぐに通知されます。このリンクをたどると、auditd とさまざまな補完フレームワークの使用について詳しく知ることができます: https://sematext.com/blog/auditd-logs-auditbeat-elasticsearch-logsene/

次のログレビューチェックリストを使用します。

1. ログメッセージはユーザーにとって意味がありますか?
2. ログ メッセージにはトラブルシューティングに役立つコンテキストが含まれていますか?
3. ログ メッセージは構造化されており、次の内容が含まれていますか。

• タイムスタンプ
• 重大度/ログレベル
• メッセージ本文
• トラブルシューティング情報のその他の特徴的なフィールド

1. サードパーティのログ解析および構造化サービス (ログ エージェントの構成) が必要ですか?
2. ログレベルは設定可能ですか?
3. ログ メッセージには個人データまたはセキュリティ関連のデータが含まれていますか?
4. 監査ログの確認やアラートログの調整に関するルールはありますか?
5. アラームログは設定されていますか?

6. ログ分析を単独で行わず、すべてのデータソースを接続する

ログ記録は全体的な監視戦略に組み込む必要があります。つまり、本当に効果的な監視を実現するには、他の種類の監視方法 (イベント ベース、アラート ベース、追跡ベースの監視タイプなど) を使用してログ記録を補完し、システム内の状況を常に「全体像」で把握できるようにする必要があります。ログ データはローカルな問題について非常に詳細な情報を提供できますが、相互に関連したグローバルなステータス情報を提供できないことがよくあります。最初から問題を効果的に見つけるには、さまざまな集約レベルでインジケーターとイベントを使用する必要があります。

ログを単独で見るのではなく、APM、ネットワーク監視、インフラストラクチャ監視などの他の種類の監視ツールを使用して、ログの「欠点」を補う必要があることがわかります。さまざまなツールを 1 つのウィンドウ ビューに柔軟に統合することで、すべての監視情報をワンストップで簡単に取得でき、トレンド チャートも取得できます。

7. GitOpsの触媒としてのログ記録を確認する

継続的インテグレーションが CI/CD パイプラインの開始時にトリガーされることが増えているため、GitOps では、製品の品質とセキュリティ認証を損なうことなく、ソフトウェア配信を自動化し、反復速度を実現する必要があります。忙しい DevOps チームにとって、自動化されたパイプラインと頻繁なリリースのためのツールとしてログ記録を採用するのは簡単です。

もちろん、業界には、ログ記録が DevOps と CI/CD の促進剤であるという別の見方もあります。一般に、開発パイプラインのすべてのステップを自動化するには、エラー コード、問題のある依存関係、リソース不足、その他の要因など、問題が発生する場所とその主な原因を視覚化する必要があります。問題の原因は数多く考えられますが、ログを記録することで、問題を見つけて解決するための基準が確実に得られます。

8. あらゆるイベントタイプでリアルタイムのフィードバックを得る

自動テストやヘッドレス テストなどの新しい方法により、開発者は、コード変更が提出されたとき、または提出される前に、R&D 環境で各コード行の変更の影響に関するリアルタイムのフィードバックを得ることができます。したがって、テストがシフトレフトされ、パイプラインの開始点に重点が置かれるようになると、可視性を高め、GitOps を有効にするためにログ記録が重要になります。適切なテストとログ記録がなければ、リリースとデプロイメントが完全に制御不能になる可能性があると言っても過言ではありません。

9. ログを使用して自動化の機会と傾向を特定する

同時に、ログ記録はパイプラインの早い段階で問題を発見し、チームの貴重な時間と労力を節約するのに役立つだけでなく、自動化の機会を見つけるのにも役立ちます。障害が発生したときにトリガーされるカスタム アラートを設定したり、アラートに対してさまざまな自動アクションを事前に設定したりできます。 Slack のカスタム スクリプトや Jenkins の自動化プラグインなど、さまざまなログを使用して GitOps プロセスの自動化を推進できます。

要約する

要約すると、ログ記録はクラウドネイティブ アプリケーションの構築と管理に不可欠な部分です。ログ記録が成功すると、アプリケーションの状態が反映されるだけでなく、それに応じてスケーリングや反復処理も行われます。同時に、ログを単独で分析するのではなく、他のクラウドネイティブ アプリケーション タイプの監視ソリューションと統合して、共同で監視と測定を実現する方法を学ぶ必要があります。さらに、ログ記録により GitOps の自動化が促進され、イベント タイプのリアルタイム フィードバックを実現することもできます。

原題: 効率的なログ管理と監視のベストプラクティス、著者: Twain Taylor & Stefan Thies

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。