エンタープライズアプリケーションをログに記録するためのベストプラクティス（サポートエンジニアの観点から）

アプリケーションログは、実行中にアプリケーションが認識する外部および内部イベントに関する情報を明らかにします。展開中にバグ、ハッキング、または異常が発生した場合、ログはインシデントの原因を分析するための最も有用で信頼できる証拠です。



誰もが気に入るような便利なメッセージをジャーナルに書く方法を見てみましょう。

1.ログに記録するもの

着信メッセージと発信メッセージ

コンポーネントがメッセージを使用して相互に対話する場合は、APIエンドポイントのURL、要求パラメーター、初期および中間IP要求、要求ヘッダー、作成者に関する情報、要求および応答本文、ビジネスコンテキストを示す受信メッセージと送信メッセージを記録する必要があります。 、タイムスタンプおよび内部処理ステップ。



各メッセージに一意の識別子（通常はAPIマネージャーまたはサービスレベルで生成される）を割り当てることが非常に重要です。これは、システム内のサービス間のメッセージ交換を追跡するために必要です。

サービスと機能の呼び出し

サービスまたは関数を呼び出すときは、主にデバッグのために、それらのコンテキストをより詳細にログに記録することが望ましいです（TRACEまたはDEBUGを使用）。これらのログは、特にデバッガーをアプリケーションに接続する権限がない場合（たとえば、テスト、ステージング、または製品前の環境にデプロイする場合）、ビジネスロジックの問題のトラブルシューティングに役立ちます。

ユーザーアクションとビジネス統計

各アプリケーションには、専門の専門家に多くの情報を提供する独自のビジネスシナリオとユーザージャーニーがあります。たとえば、特定のトランザクションに時間がかかりすぎているかどうか、またはユーザーが一部の機能に固執しているかどうかなど、これらはすべて、ユーザーエクスペリエンスの観点から非常に重要なデータです。ビジネスに関連するその他の情報（トランザクションとアクティブユーザーの数、およびそれらのステージ）は、因果関係を見つけるために重要であり、ビジネス分析にも使用できます。

データ操作（監査証跡）

セキュリティと規制上の理由から、ほとんどのエンタープライズアプリケーションでは、アクセスID（ユーザーとシステム）、使用される正確なサービスインスタンスとロール権限、タイムスタンプ、データリクエスト、スナップショットなどのすべての重要な情報を含む個別のトランザクションログが必要です。変更されたデータの新しい状態（diff）。監査証跡は、データを使用したすべての操作（アクセス、インポート、エクスポートなど）と、ユーザー、他のシステムおよびサービスによって実行されたCRUD操作（作成、読み取り、更新、削除）を記録する必要があります。

システムイベント

これらには、動作（開始、停止、再起動、および安全関連イベント）、一時モード（コールド、ウォームアップ、ホット）、サービス間通信（ハンドシェイク、接続確立ステータス-接続、切断、再接続、再試行）、識別子に関する情報が含まれます。サービスインスタンス、アクティブにサービスを提供するAPI、IPとポートの範囲をアクティブにリッスンする、ロードされた構成（ブートストラップと動的更新）、全体的なサービス状態、およびシステムの動作を理解するのに役立つその他すべて。

パフォーマンス統計

勤勉さはコンピューティングデバイスの大きな特徴ですが、完全に機能しない場合があります。いつでも、パフォーマンスの問題やサービスの突然の予期しない劣化が発生する可能性があります（主に未処理のエラーと破損したデータが原因です）。これらを判断するには、システムの全体的な状態とパフォーマンスに関する統計を公開することを常にお勧めします。これには、API呼び出しカウンター（成功および失敗）、ネットワークレイテンシ、平均ラウンドトリップ期間、メモリ消費、およびその他のアプリケーション固有の情報（通常はビジネスコンテキストによって決定されます）などの情報を含めることができます。

脅威と脆弱性

ランタイムアプリケーションとログを使用して脅威と脆弱性を開示することは、エンタープライズソフトウェア開発者が習得しなければならない技術です。通常、ハッキングやグリッチは突然発生しません。ほとんどの場合、最初は誰も気付かない兆候があります。したがって、疑わしい人間の活動（たとえば、使用されているネットワーク、要求のソース、ユーザーの役割と特権などのすべての低レベルの情報の適用による認証と検証の誤った試行）、およびシステムの動作（たとえば、リソース消費パターンのピークの増加、高負荷Webサーバー、ときどきサービス障害）。疑わしいイベントに気付いた場合は、ログにそれに関連するすべての情報が含まれていることを確認してください。完璧に、そのため、パラメータ値とアプリケーションコンテキストから取得した追加情報を含むフルスタックトレースになります。

2.ログに記録する必要がないもの

個人情報

ほぼすべてのプライバシー法（GDPR、CCPAなど）は、開発者が個人を特定できる情報をログに記録しないことを明示的に推奨しています。これには、名前、ニックネーム、性別、誕生日、住所、電子メール、電話番号、社会保障番号、およびクレジットカード番号が含まれます。

会社名と連絡先

会社名、従業員、顧客、サプライヤー情報、または会社と個人の連絡先情報を書き留めないでください。ジャーナルは、第三者との取引関係や取引を決して開示してはなりません。特定のトランザクションを追跡するには、実名の代わりにシステムで生成されたイベントIDを使用して、他のサービスに渡します。

財務データ（銀行口座、銀行カードの詳細、送金金額など）

法律により、すべての財務データは完全に削除またはマスクする必要があります。そのような情報を雑誌に開示すると、重大な法的措置（刑事責任を含む）につながる可能性があります。絶対に避けてください。

パスワード、セキュリティキーとシークレット、認証トークン

資格情報と認証トークンは機密情報と見なされるため、ログに存在することで、攻撃者はシステムの穴を簡単に見つけることができます。したがって、このデータをログに入れないでください。



注：可視性のレベルを決定する各フィールドに属性を追加すると、ログから非表示にする情報を簡単に決定できます（たとえば、表示、マスク、非表示、暗号化）。このようなメカニズムがある場合は、構成のプロパティを更新するだけで、フィールドの表示を変更できます。これは、特にテストとデバッグのために、非戦闘環境で一部のユーザー情報をログに記録する必要がある場合に適したソリューションです。または、この環境用に事前に作成された指示に従って、ログをフィルタリングし、機密フィールドを処理するパーサーを作成できます。

3.ベストプラクティス

特定のレベルのロギングをいつ使用するかを知る

ログレベルは、システム内の各要素の重大度を示すために使用されます。ほとんどのロギングフレームワークには、次のレベルがあります。

• 致命的：アプリケーションを終了させる可能性が最も高い非常に重大なエラー。これは通常、重大な障害に終わります。
• エラー：アプリケーションが引き続き機能できるエラーですが、特定の機能が低下しています。
• 警告：エラーと比較して危険性の低いイベント。通常、アプリケーションを劣化させたりクラッシュさせたりすることはありません。しかし、これらは依然として調査が必要な重要なイベントです。
• 情報：アプリケーションの動作における重要なイベントバナーと情報メッセージ。
• DEBUG: , . .
• TRACE: , , . .

Linux Syslogには、緊急、アラート、クリティカル、エラー、警告、通知、情報、デバッグなど、より深刻なレベルもあります。



ロギングの各レベルの複雑さと深さに関係なく、各シナリオで最適な量の情報を提供するために、コードでそれらを正しく構成する必要があります。たとえば、開発者がデバッグと技術分析に使用するすべてのデータはDEBUGまたはTRACEレベルで実行する必要があり、システムデータを含むバナーはINFOを下回る必要があります。

英語を使う

一部のツールとコンソールは、特定のUnicode文字を使用したログの出力と保存をサポートしていません。したがって、ローカリゼーションやその他の改善は難しい場合があります。英語に固執し、メッセージを書くために常に広くサポートされている文字セットを使用してください。

2020-11-11 13:52:18 DEBUG  App:36 - Loading adapters..
2020-11-11 13:52:21 DEBUG  Adapters:10 - Loading adapter docs/v1
2020-11-11 13:52:22 DEBUG  Adapters:16 - Loading adapter mongo/v1
2020-11-11 13:52:26 DEBUG  Docs:38 - docs adapter initialized
2020-11-11 13:52:27 DEBUG  Mongo:38 - mongo adapter initialized
2020-11-11 13:52:22 DEBUG  Adapters:20 - Successfully loaded all

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

開発者向けのメッセージを追加する（簡潔で意味のある）

ログが少なすぎると、すべての重要なイベントのコンテキストを再作成するために必要な情報を取得できません。また、ログを記録しすぎると、パフォーマンスが低下します。巨大なログファイルを書き込むと、I / Oとディスクストレージリソースの消費量が増加します。ファイルシステムがそれをサポートしていない場合、システム全体のパフォーマンスが低下します。



メッセージを最適化するには、システムの機能的および非機能的な期待を明確に理解し、メッセージの望ましい品質と量を計画する必要があります。各ジャーナルは、意味があり、文脈に適している必要があります。常に簡潔に、要点を述べてください。

2020-11-11 13:52:27 DEBUG  Users:18 - Successfully created new user (RecordID: 5f5a0d594d17e22b848ee570)2020-11-11 13:52:27 ERROR  Users:34 - Failed to update DB (E: inactive user, RecordID: 5f5a0d594d17e22b848ee570)

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

頻繁に使用される長いメッセージの参照識別子、エイリアス、および簡略化されたテンプレートを作成します

毎回完全な説明を書く代わりに、参照識別子または簡略化されたテンプレートを作成して、ログに長く繰り返される説明を表すようにしてください。これにより、メッセージの総数と長さが減少し、特定の情報を非表示にする柔軟性も向上します。たとえば、テキストログに脆弱性を記述する代わりに、専門の専門家だけが現在のシナリオを理解できるように、エイリアスまたは識別子を使用することをお勧めします。

2020-11-11 13:52:27 ERROR  DB:22 - Failed to write (E:ORA-01017)// ORA-01017 denotes "invalid username/password; logon denied" error message

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

正しいタイムスタンプを使用する

タイムスタンプを使用すると、イベントのシーケンスを理解できます。タイムスタンプは、デバッグと分析に必要です。時間を固定するときは、隣接するイベントを簡単に識別できるように、最も詳細な値（たとえば、ミリ秒またはマイクロ秒のレベル）を使用することをお勧めします。また、タイムスタンプがyyyy-mm-dd HH：mm：ss形式のメッセージの先頭にあることを確認してください。サーバーのデフォルト時間（UTC）を使用していない限り、常にタイムゾーンを指定してください。

// with default server time (UTC)2020-11-11 13:52:12 INFO  XYZ Integration API Manager v2.0.0// with timezone (e.g. PST - Pacific Standard Time)2020-11-11 13:52:12PST INFO  XYZ Integration API Manager v2.0.0

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

ログデータのソースまたは発信元を提供します（DEBUG、TRACE、ERRORの場合）

これは、対応するメッセージにつながった場所を明確に識別するのに非常に役立ちます。一部のロギングフレームワークでは、ソースを最も詳細なレベル（行番号付きのファイル名まで）で指定できますが、多くの場合、クラス、関数、またはファイル名のみに言及するだけで十分です。

2020-11-11 13:52:12 INFO  app - XYZ Integration API Manager v2.0.0
2020-11-11 13:52:15 INFO  app - Loading configurations..
2020-11-11 13:52:18 INFO  app - *** InstanceID APIM_V2_I02
2020-11-11 13:52:18 INFO  app — *** BaseURL http://10.244.2.168:3000
2020-11-11 13:52:19 INFO  app - *** LogLevel 05 (DEBUG)
2020-11-11 13:52:12 DEBUG  App:22 - Initializing Swagger UI..
2020-11-11 13:52:14 DEBUG  App:28 - Generating schemata..
2020-11-11 13:52:14 DEBUG  App:30 - Initializing REST services..
2020-11-11 13:52:15 DEBUG  App:32 - Generating documentation..
2020-11-11 13:52:18 DEBUG  App:36 - Loading adapters..
2020-11-11 13:52:21 DEBUG  Adapters:10 - Loading adapter docs/v1
2020-11-11 13:52:22 DEBUG  Adapters:16 - Loading adapter mongo/v1
2020-11-11 13:52:26 DEBUG  Docs:38 - docs adapter initialized
2020-11-11 13:52:27 DEBUG  Mongo:38 - mongo adapter initialized
2020-11-11 13:52:22 DEBUG  Adapters:20 - Successfully loaded all
2020-11-11 13:52:31 INFO  app - Started listening...

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

各ジャーナルはシステム内で一意である必要があります

ほとんどの初心者は同じ間違いを犯します。サンプルメッセージをコピーして別のファイルに貼り付け、システムのさまざまな部分からの同じ行から最終ログを収集します。この場合、イベントをトリガーした特定の場所を追跡することは困難です。単語のセットを変更できない場合は、少なくともメッセージのソースに言及して、最終ファイルの行が互いに異なるようにします。さらに、ロギングが親クラスによって処理される場合は、初期化中に識別子を送信し、それを使用して子クラスの動作に関するメッセージを記録します。

2020-11-11 13:52:18 DEBUG  App:36 - Loading adapters..
2020-11-11 13:52:21 DEBUG  Adapters:10 - Loading adapter docs/v1
2020-11-11 13:52:22 DEBUG  Adapters:16 - Loading adapter mongo/v1
2020-11-11 13:52:26 DEBUG  Docs:38 - docs adapter initialized
2020-11-11 13:52:27 DEBUG  Mongo:38 - mongo adapter initialized
2020-11-11 13:52:22 DEBUG  Adapters:20 - Successfully loaded all

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

追跡されたIDまたはメッセージトークンをメッセージに追加します

イベントまたはメッセージがシステムに到達すると、通常、一意の識別子が割り当てられます。他の処理ステージに渡して、システム内のイベントの移動を追跡できます。これは、デバッグ、同時処理、およびデータ駆動型操作に役立ちます。理想的には、システムはすべてのモジュールとサービス内で一意のイベント識別子を持っている必要があります。

[87d4s-a98d7-9a8742jsd] Request Body: {
 "request_id": "87d4s-a98d7-9a8742jsd",
 "app_id": "TX001",
 "option_val": "IBM",
 "req_type_id": "0013",
 "data": {...........}
[87d4s-a98d7-9a8742jsd] Sending request to RefData: href="http://10.244.2.168:8280/v1

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

遷移点で識別子を一致させる

場合によっては、特にあるシステムから別のシステムにイベントを送信するときに、他のシステムで採用されている規則に従って識別子が変更されます。このような移行ポイントでは、必要なコンテキストを追加して、古い識別子と新しい識別子の対応を別のメッセージで明示的に示す必要があります。

[1000508] ***** Incoming request from 10.244.2.168:3000 *****
[1000508] Origin Id: 87d4s-a98d7-9a8742jsd -> System ID: 1000508
[1000508] Transaction successfully added to Rabbit Queue

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

すべてのサービスインスタンスの識別子を指定します

ほとんどのエンタープライズシステムは分散コンピューティングプラットフォームであり、さまざまなアプリケーション構成、リソース、バージョン、およびネットワークプロパティを持つ同じサービスのインスタンスが多数あります。インスタンスに識別子を割り当て、サービス間通信に使用することをお勧めします。

2020-11-11 13:52:12 INFO  app - XYZ Integration API Manager v2.0.0
2020-11-11 13:52:15 INFO  app - Loading configurations..
2020-11-11 13:52:18 INFO  app - *** InstanceID APIM_V2_I02
2020-11-11 13:52:18 INFO  app — *** BaseURL http://10.244.2.168:3000
2020-11-11 13:52:19 INFO  app - *** LogLevel 05 (DEBUG)

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

アクティブなログレベルを構成する

アクティブなログレベルは、展開環境に応じて変更する必要があります。本番環境では、INFOレベルまでのログを出力することをお勧めします。他の環境では、開発チームと保守チームが必要とする詳細レベルに応じて、ログはDEBUGまたはTRACEレベルまで出力されます。

// Active Log Level = DEBUG2020-11-11 13:52:12 INFO  app - XYZ Integration API Manager v2.0.0
2020-11-11 13:52:15 INFO  app - Loading configurations..
2020-11-11 13:52:18 INFO  app - *** InstanceID APIM_V2_I02
2020-11-11 13:52:18 INFO  app — *** BaseURL http://10.244.2.168:3000
2020-11-11 13:52:19 INFO  app - *** LogLevel 05 (DEBUG)
2020-11-11 13:52:12 DEBUG  App:22 - Initializing Swagger UI..
2020-11-11 13:52:14 DEBUG  App:28 - Generating schemata..
2020-11-11 13:52:14 DEBUG  App:30 - Initializing REST services..
2020-11-11 13:52:15 DEBUG  App:32 - Generating documentation..
2020-11-11 13:52:18 DEBUG  App:36 - Loading adapters..
2020-11-11 13:52:21 DEBUG  Adapters:10 - Loading adapter docs/v1
2020-11-11 13:52:22 DEBUG  Adapters:16 - Loading adapter mongo/v1
2020-11-11 13:52:26 DEBUG  Docs:38 - docs adapter initialized
2020-11-11 13:52:27 DEBUG  Mongo:38 - mongo adapter initialized
2020-11-11 13:52:22 DEBUG  Adapters:20 - Successfully loaded all
2020-11-11 13:52:31 INFO  app - Started listening...// Active Log Level = INFO2020-11-11 13:52:12 INFO  app - XYZ Integration API Manager v2.0.0
2020-11-11 13:52:15 INFO  app - Loading configurations..
2020-11-11 13:52:18 INFO  app - *** InstanceID API_V2_I02
2020-11-11 13:52:18 INFO  app — *** BaseURL http://10.244.2.168:3000
2020-11-11 13:52:19 INFO  app - *** LogLevel 04 (INFO)
2020-11-11 13:52:31 INFO  app - Started listening...

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

エラーとクラッシュに十分なコンテキストを提供する

エラーと障害には、最も徹底的な調査が必要です。これを行うには、アプリケーションは、主題の専門家に必要な情報と、テクノロジーおよびビジネスコンテキストを提供する必要があります。たとえば、リクエストまたはメッセージを処理できなかった場合、エラーに加えて失敗したリクエストの本文をログに記録すると非常に便利です。

[1000508] ***** Incoming request from 10.244.2.168:3000 *****[1000508] Origin Id: 87d4s-a98d7-9a8742jsd -> System ID: 1000508[1000508] Failed to validate msg body (E: Uncaught ReferenceError: missing params - option_val)[1000508] Failed Message: {
 "request_id": "87d4s-a98d7-9a8742jsd",
 "app_id": "TX001",
 "req_type_id": "0013",
 "data": {...........}
}

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

証拠を使用してデータトランザクションをバックアップします（想定しないでください！）

すべてのデータ操作について、それが成功したことを当然のことと考えないでください。常に証拠を使用して終了条件を確認してください。たとえば、データベースでレコードを作成、更新、または削除すると、変更されたレコードのカウンターと更新されたレコード自体が返されます。予想されるカウンターまたは結果を常に確認してください。別の例：レコードをデータ構造（キューなど）に挿入するときに、そのサイズが増加しているかどうかを確認します。システムが同時操作を使用しているが、キューがそれらをサポートしていないとします。そうすると、いくつかのレコードが失われる可能性があり、コード内のそのような隠れたエラーを検出する唯一の方法は、長さを確認することです。

DEBUG  BatchWriter:28 - Successfully connected to DB. Trying to insert 24 accounts...DEBUG  BatchWriter:35 - Successfully inserted 24 accounts. Total DB rows affected: 24

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

機密データを暗号化またはマスクする

通常、法律では、ユーザーおよび内部システムの機密情報をマスクおよび/または暗号化することが義務付けられています。規制要件は、業界や職場によって異なる場合があります。すべてのニュアンスを見つけて、アプリケーションに正しい手順を実装します。場合によっては、運用を開始する前に、ロギング戦略をセキュリティサービスに送信し、承認または認証を取得する必要があります。

[1000508] ***** Incoming request from 10.244.2.168:3000 *****[1000508] Origin Id: 87d4s-a98d7-9a8742jsd -> System ID: 1000508[1000508] Request Body: {
”user_id”:”XXXXXXXXXX”,
”personal_details”:{
  ”firstName”:”XXXXXXXXXX”,
  ”lastName”:”XXXXXXXXXX”,
  ”DOB”:”XXXXXXXXXX”,
  ”gender”:”Male”,
  ”proffessional”:”Software Architect”,
  ”industry”:”IT”,
  ”SSN”:”XXXXXXXXXX”
},
”address_history”:[
  {”streetAdress”:”Street No 1″,”zipcode”:”XXXXX”,”state”:”CA”},
  {”streetAdress”:”Street No 2″,”zipcode”:”XXXXX”,”state”:”NY”},  
  {”streetAdress”:”Street No 2″,”zipcode”:”XXXXX”,”state”:”AL”}
],
”card_info”:[
  {”type”:”amex″,”card_number”:”XXXXXXXXX”,”credit_limit”:”XXXXX”},
  {”type”:”visa″,”card_number”:”XXXXXXXXX”,”credit_limit”:”XXXXX”}
]
}

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

ログファイルの命名、ローテーションポリシー、ストレージサイズ、およびバックアップ手順を構成します

ログをファイルに書き込む場合は、実行中のアプリケーションに影響を与えない別のディスクにログが保存されていることを確認してください（たとえば、リモートサーバーにボリュームを割り当てて、アプリケーションサーバーに接続できます）。また、ジャーナルの頻度とファイルがどのように大きくなるかを調べます。理想的なサイズとファイル数を維持するために、正しい命名規則（たとえば、作成時に名前にタイムスタンプを追加する）を使用したログローテーションポリシーがあることを確認してください。また、古いログを安全な場所にバックアップするためのメカニズムと、ストレージを定期的にクリーンアップするためのメカニズムも必要です。業界によっては、時間指定のバックアップ（通常は数か月または数年ごと）を設定して、期間の終了時に以前のすべてのファイルを削除できます。

[ec2-user@ip-XXX-XX-X-XXX logs]$ ls
..
APIM_V2_I02-2020-11-20_04:38:43.log
APIM_V2_I02-2020-11-23_02:05:35.log
APIM_V2_I02-2020-11-24_04:38:17.log
APIM_V2_I02-2020-11-27_03:28:37.log
APIM_V2_I02-2020-11-27_12:06:45.log
...

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

4.

エンタープライズアプリケーション開発者の間で非常に一般的な方法は、ログを収集するために一元的にアクセス可能なサーバーまたは場所を作成することです。通常、このようなアグリゲーターは、アプリケーションだけでなく、デバイスやオペレーティングシステム（Linux Syslogなど）、ネットワーク、ファイアウォール、データベースなどのログも追跡します。さらに、ログファイルをアプリケーションサーバーから分離し、ログをより多くの場所に保存できるようにします。保護された、整然とした効率的なフォーマットを長期間。一部の業界（銀行や金融など）では、攻撃者が両方の場所にアクセスして同時に活動の証拠を削除できないように、ローカルストレージと中央ストレージの両方にログを保存する必要があります。したがって、2つのストア間のデータの冗長性とデータの不一致は、侵入を見つけるのに役立ちます。

パーサーを作成し、ログを慎重に追跡します

パーサーとフィルターを作成する機能は、ほとんどのログ監視ツール（いわゆるセキュリティ情報とイベント管理（SIEM）の統合）に組み込まれてい ます。パーサーは、ログをより合理化された形式で保持するのに役立ち、クエリデータははるかに簡単かつ高速になります。また、適切に編成されたデータを監視および異常検索システムに転送して、予防的な監視と将来のイベントの予測を行うことができます。これらのツールは、時系列に基づいてリアルタイムでデータをグラフ化するのに非常に強力です。

重大なインシデントのアラートとプッシュ通知を設定する

ほとんどすべてのログ監視ツールでは、特定のレベルに特定のしきい値を設定できます。システムがこれらの値に達すると、ツールはそれらを事前に検出し、データのログ記録を支援し、アラート、プッシュ通知API（Slack Audit Logs APIなど）、電子メールなどを介してsysadminに通知します 。自動プロセスを開始するように事前構成することもできます。動的スケーリング、システムバックアップ、ロードスリングなどがあります。ただし、商用ログ監視ソフトウェアに投資する場合は、そのようなツールは中小規模のソフトウェアシステムではやり過ぎになる可能性があるため、よく見てください。

5.推奨ツール

ロギングフレームワーク

JavaScript / TypeScript： Log4js / pino

Java： Log4j

Golang： Logrus Serverless-

関数： aws-lambda-powertools-python / 自作

ログの調査、集約、および監視

CLIツール：less、vim

クラウドツール：Fluentd、AWS CloudWatch

SIEMツール：SolarWinds、Splunk、McAfee ESM、DataDog、IBM QRadar

その他：ELKスタック（ElasticSearch、Logstash、Kibana、Beats）、Loggly