Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Warningアラートを放置しない!アラート駆動でログやメトリックを自動収集する仕組みによる恩恵

ikeda-masashi
September 29, 2023

 Warningアラートを放置しない!アラート駆動でログやメトリックを自動収集する仕組みによる恩恵

SRE Next 2023 の発表スライドです

ikeda-masashi

September 29, 2023
Tweet

More Decks by ikeda-masashi

Other Decks in Technology

Transcript

  1. Warningアラートは結構な頻度ででる。 例えば、Application Load Balancer(ALB)に AWS WAFを設定している場合。 すべてWarningアラート https://aws.amazon.com/jp/waf/sla/ 月次稼働率 99.95%

    なので 『ALBの1分間のレスポンスで5xxが1件以上』なら、 1週間で5件Warningアラートが発生しても不思議ではない
  2. Warningアラートにまつわるトイル アラートの確認の為にログやメトリックを調べたりする行為は 以下の性質を持ちやすい • 手作業である • 週次定例のたびに繰り返される • 戦術的である •

    長期的には直接的な価値をもたらさない • サービスの成長に比例して増加する しかし、確認作業はマニュアル化しやすく、自動化可能である。 つまり、Warningアラートの調査はトイルになりがち
  3. 仕組みを入れたことによる恩恵 - 振り返り時間短縮 1. 週次定例中にWarningアラートを振り返りきることができる 重大な事故に繋がりそうであるか?という初期判断に必要な情報が 出揃っている状態なので、スムーズに振り返りができる。 この場合、『response timeのp99が1.5秒より長い』 というWarningアラートに対して、

    『その期間のリクエストのパスごとにレスポンスタイムを集計した 結果、 画像アップロードのAPIが1件 17.9秒かかっている。』 という情報がメモに自動的に書かれた状態にある 大きめの画像をアップロードした場合に 長く時間がかかるということがわかっているので、 エラーバジェットがまだあるので放念する。 ということがすぐ意思決定できる。
  4. 仕組みを入れたことによる恩恵 - 収集内容の拡充 例: 『ALB Target 5xx Request > 0

    』のWarningアラートに関して • Nginxのupstream側が5xxであった 『Applicationのログ情報』を見る必要があるので追加 • NginxはHTTP 499 Client Closed Requestのケースが有る ALB側がTimeoutで切断しているか確認するために 『ALBのLog情報』を追加 • 影響するユーザーがどれくらいいるのかを判断したくなった。 Applicationが使用している 『Aurora MySQL由来の基幹DB情報』を追加 導入初期: 『Nginxのログをパス別に集計した結果』のみ
  5. 仕組みを入れたことによる恩恵 - 早期に問題を発見 • 謎の15秒タイムアウト犯人捜索事件簿 Nginxのログがない ApplicationのError Logもない ALBのLogだけある •

    ALBのログはある。 • ALBによればTarget(接続先)が503を返している • しかし、接続先のNginxはアクセスログがない。 • 他のアラートも15秒できっちり揃っている。 • ALBのタイムアウトは15秒より長く設定している 一体誰が接続を切っているんだ (・・?
  6. 仕組みを入れたことによる恩恵 - 早期に問題を発見 • 謎の15秒タイムアウト犯人捜索事件簿 Timeout!!!!! 実はApp Meshの設定由来だった。 マイクロサービスのプロダクトで、 コントロールプレーンにEnvoyがいました。

    EnvoyがTaskにくる通信を Proxyしているのようですが、 Nginxが何かしらの理由で通信できなかったようで す。 その結果、envoyがHTTP Status 503を返していた ようです。 App Meshの15秒タイムアウト設定に 気がついてなかった!!!
  7. 仕組みを入れたことによる恩恵 - 早期に問題を発見 • 他システム向けの脆弱性攻撃でエラーバジェット損失!事件簿 Caught exception in engine "End

    of stream encountered while parsing part body at /home/app/xxxxxxxxxxxx/local/lib/perl5/HTTP/Entity/Parser/MultiPart.pm line 157. POST /FCKeditor/editor/filemanager/connectors/asp/connector.asp ASP.NET版のFCKeditorへの攻撃のようですね。 Perl5のアプリケーションでHTTPリクエストの ボディとして解釈できずに500エラーになったようです。 https://jvndb.jvn.jp/ja/contents/2009/JVNDB-2009-002835.html Perl5のパーサーが優秀なので、 有効な攻撃にはなっていないが、 しかし、5xxエラーを返しているので エラーバジェットは無駄に削れている。
  8. まとめ • アラートにはSeverityがWarningの物がある。 ◦ すぐには重大な事故に繋がらないが、可能性があるもの ◦ そこそこの頻度で発生する。 ◦ Warningアラートの初期判断のための調査はトイルである。 •

    Warningアラートにまつわるトイル削減のために仕組みを入れた。 ◦ アラートが発生したらWebhookを受け取り、ログやメトリックスを自動 収集する仕組み ◦ 危ないかどうか?の初期判断ための情報は人が集めなくてもいい状態へ • 仕組みを入れた結果いくつかの恩恵があった。 ◦ Warningアラートの振り返り時間の短縮 ◦ 初期判断のための情報拡充 ◦ 重大な事故に繋がる前に、早期に問題を発見できたことも