どんな場面で検討するか
Azureと対応するアプリ/サーバーのメトリクス・ログ・トレースを集め、障害の調査と通知をつなぎたい場合。インフラの正常性と業務処理の成否を別々に観測する基盤。
組織で使う条件
収集停止、調査用ID、個人情報の除去、日量/費用、通知の過不足を監視する。アラート発生/解消と実際の復旧を区別し、担当の確認記録を残す。
採用前に試すこと
- 検証APIから正常100件と合成エラーを送り、相関IDとメトリクス/ログの収集を設定する。
- エラーと収集停止を別々に発生させ、通知条件・ログ検索・原因追跡ができることを確かめる。
- 回復後の解消を確認し、検証用通知先の到達と日量・保持・アラートの費用根拠を記録する。
合格と判断する条件
- 合成エラーと欠測が別の状態で把握でき、要求IDから原因ログへ辿れる。
- 設定した時間内に検証通知が届き、保存日量と保持期間を見積もれる。
見落としたくない点
- 全ログを無差別に長期保存する用途は、調査価値と費用・機密情報を先に整理する。ログが届かない状態をエラー0として正常判定しない。
- 全ログを無差別に長期保存する用途は、調査価値と費用・機密情報を先に整理する。ログが届かない状態をエラー0として正常判定しない。