# Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵 Navigation: [[index]] | [[sources/_index]] ## 概要 [[池田将士]] が [[SRE NEXT]] 2023 で発表した、[[Warningアラート]] の確認作業を自動化する実践資料である。Warning アラートは即時対応対象ではないが、週次振り返りでログやメトリクスを確認する作業がトイルになりやすいため、[[prepalert]] によってアラート発生時点で初期判断材料を自動収集する。資料は [[Mackerel]] と AWS を前提に、Webhook → Lambda → SQS → 各種データソース → Mackerel アラートメモという流れと、振り返り時間短縮・収集内容拡充・早期発見の効果を示す。 ## 主要メッセージ - Warning アラートは「すぐには重大事故につながらないが、可能性がある」警告であり、Slack メンションやオンコール付きの Critical アラートとは扱いが異なる。(Source: [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]], p.5-7) - AWS WAF の月次稼働率 99.95% を前提に、ALB の 1 分間レスポンスで 5xx が 1 件以上なら 1 週間で 5 件の Warning アラートが出ても不思議ではない、と頻度の高さを説明する。(Source: [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]], p.8) - Warning アラート調査は、手作業・週次反復・戦術的・長期価値の薄さ・サービス成長への比例という性質を持ち、トイル化しやすい。(Source: [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]], p.10) - [[prepalert]] は Mackerel のアラート Webhook を受け、Lambda と SQS を介して CloudWatch Logs Insights、S3 select、Redshift data API、プラグインプロバイダから情報を取得し、Mackerel のアラートメモへ結果を貼る。(Source: [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]], p.12-13) - 導入後は、週次定例前に初期判断情報がそろうため、振り返り時間を短縮できる。例ではレスポンスタイム p99 > 1.5 秒の Warning に対し、画像アップロード API 1 件が 17.9 秒だったことをメモで確認し、エラーバジェット残量を踏まえて放念できる。(Source: [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]], p.15) - 収集内容は運用で増やせる。ALB Target 5xx > 0 の例では、Nginx パス別集計から始め、アプリケーションログ、ALB ログ、Aurora MySQL 由来の基幹 DB 情報へ拡張した。(Source: [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]], p.17) - 15 秒タイムアウト事例では、ALB ログはあるが Nginx とアプリケーションログがない状況から、App Mesh の 15 秒タイムアウト設定と Envoy の 503 応答に気づいた。(Source: [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]], p.18-19) - FCKeditor への脆弱性攻撃事例では、アプリケーション側では有効な攻撃になっていないが 5xx が返ってエラーバジェットを消費していたため、WAF で遮断してアプリケーションへ到達させない対策を入れた。(Source: [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]], p.20-22) ## 視覚的に重要な図表 **p.8 Warning アラート頻度の根拠** ![[_attachments/warning-alert-driven-log-metric-collection/page-008.png]] AWS WAF の月次稼働率 99.95% と Mackerel の Warning アラート一覧を並べ、ALB 5xx の Warning がそこそこの頻度で出る前提を示す。 **p.12 prepalert の全体像** ![[_attachments/warning-alert-driven-log-metric-collection/page-012.png]] Mackerel の Webhook から Lambda、SQS、prepalert、CloudWatch Logs Insights、S3 select、Redshift data API、プラグインプロバイダへ分岐し、結果をアラートメモへ戻す制御フローを示す。 **p.15 振り返り時間短縮の例** ![[_attachments/warning-alert-driven-log-metric-collection/page-015.png]] レスポンスタイム p99 > 1.5 秒の Warning に対し、画像アップロード API が 17.9 秒だったことを自動メモで判断できる例を示す。 **p.18 15 秒タイムアウト調査の観測** ![[_attachments/warning-alert-driven-log-metric-collection/page-018.png]] ALB ログのみ存在し、Nginx アクセスログとアプリケーションエラーログがないため、ALB と ECS タスクの間で何かが切断しているという仮説が立つ。 **p.20 FCKeditor 攻撃によるエラーバジェット消費** ![[_attachments/warning-alert-driven-log-metric-collection/page-020.png]] `POST /FCKeditor/editor/filemanager/connectors/asp/connector.asp` と Perl5 の Multipart パーサエラーから、別系統向け攻撃が 500 を誘発していることを示す。 **p.23 まとめ** ![[_attachments/warning-alert-driven-log-metric-collection/page-023.png]] Warning アラートの初期判断調査はトイルであり、Webhook 起点でログ・メトリクスを自動収集すると、人が集めなくても判断材料がそろうとまとめる。 ## 口頭説明・補足 YouTube 自動字幕では、登壇冒頭に資料が小さいため SpeakerDeck の QR コードを見てほしいという補足がある。また、池田はカヤックでデータエンジニアとして多種多様なメトリクスやログ配送を扱い、`shimesaba` と `prepalert` を作っていると自己紹介する。自動字幕は誤認識を含むため、数値・固有名・図表はスライド画像を優先する。 ## 概念・実体への接続 - [[Warningアラート]]: Severity が Warning のアラートを、即時対応不要だが放置できない警告として扱う。 - [[アラート管理]]: アラートの発火後に補助情報を自動収集する、調査準備層の介入点。 - [[サービスレベル目標]] / [[エラーバジェット]]: 5xx や p99 レイテンシの Warning が SLO 違反・予算消費とつながる。 - [[Mackerel]]: Warning/Critical の通知差、Webhook、アラートメモの表示先として使われる。 - [[prepalert]]: Mackerel と AWS をつなぐトイル削減ツール。 ## 限界・不確実点 - YouTube 自動字幕は取得できたが、英語字幕取得は HTTP 429 で失敗した。日本語自動字幕は誤認識があるため、本文の数値・固有名はスライド画像を根拠にした。 - p.15 の Mackerel 画面内スクリーンショットは小さく、細部のアラート名や伏せ字部分は読み取らない。 - `prepalert` の詳細設計は本発表では扱わず、Kayac Techblog と GitHub README への導線に留まる。