Warningアラートを放置しない！ アラート駆動でログやメトリックを 自動収集する仕組みによる恩恵 SRE NEXT 2023 【TrackB】2023.09.29 15:50 - 16:10 面白法人カヤック 池田将士 @mashiike

@mashiike その他事業部 SREチーム データエンジニア 主にデータのお悩み事相談や 多種多様なメトリックを眺める https://github.com/mashiike/shimesaba Mackerelを使ったSLI/SLO/エラーバジェット計算ツール https://github.com/mashiike/prepalert アラートに関するトイル削減ツール 趣味: ● 利茶 (聞茶) ● ネトゲ ● 睡眠

主にWeb技術を得意とする ゲームやコミュニティなど 多種多様な事業を展開する おもちゃ箱のような会社。

アジェンダ！ ● Warningアラートとは？・Warningアラートにまつわるトイル ● アラート駆動でログやメトリックを自動収集する仕組みの恩恵 ● まとめ

アラート 人間が即座にアクションを起こして対応し、 状況を改善しなければならなことが生じている、 あるいは生じようとしていることを知らせます。 書籍版 SREサイトリライアビリティエンジニアリング p10 より 通常、アラートにはSeverity(重要度)をつけて人間に通知します。 Warningアラートとは、このSeverityがWarningであるものを本発表では 意味します。

SeverityがWarningのアラートは一般には、 『即座にアクションを起こす必要は無いが、 これから重大なことが生じようとしている可 能性があるので警告しておく』という意味合 いのものが多いと思います。 ● リクエスト 5xx エラー 1件 ● 平均レスポンスタイム500ms ※監視サービス Mackerelでの設定例 Warningアラートの実例

Severityによる取り扱いの差 Warningアラート Criticalアラート Slackにメンションなし ひっそりと channelメンションや オンコール付き

Warningアラートは結構な頻度ででる。 例えば、Application Load Balancer(ALB)に AWS WAFを設定している場合。 すべてWarningアラート https://aws.amazon.com/jp/waf/sla/ 月次稼働率 99.95% なので 『ALBの1分間のレスポンスで5xxが1件以上』なら、 1週間で5件Warningアラートが発生しても不思議ではない

Warningアラートの確認 だいたい週次定例でWarningアラートについて振り返ります。 例えば、ALBのログをもとに、なぜエラーになったのかを確認します。 右側はなにか潜んでる可能性がありますね。 理由によっては、対策が必要になります。 Warningアラートの放置は重大な事故につながる可能性があります。 こっちはWAFのエラーなんで アプリケーションのエラーじゃないですね。 こっちはALBの後ろにいるNginxが500と 504を返してるみたいですね。 あとそれとは別の理由のもありますね 【ハインリッヒの法則】 1 29 300 重大な事故 軽微な事故 事故未遂

Warningアラートにまつわるトイル アラートの確認の為にログやメトリックを調べたりする行為は 以下の性質を持ちやすい ● 手作業である ● 週次定例のたびに繰り返される ● 戦術的である ● 長期的には直接的な価値をもたらさない ● サービスの成長に比例して増加する しかし、確認作業はマニュアル化しやすく、自動化可能である。 つまり、Warningアラートの調査はトイルになりがち

● 週次定例の時間をオーバーして 振り返れないものが出る ● 調査Issueがたくさんできる。 ● 調べる人が固定化されがち ● etc… トイルのもたらす現象

github.com/mashiike/prepalert アラート駆動でログやメトリックを自動収集する仕組み - OSS『prepalert』- MackerelとAWSを使ってる方は、ぜひ使ってみてください！

OSS『prepalert』の概要 アラートが発生したら、 Webhook経由でLambda関数が起動！ Redshift,S3,Cloudwatchなどにアクセスし その結果をMackerelのアラートのメモに貼る！ 導入前 導入後

アラート駆動でログやメトリックを自動収集する仕組み - OSS『prepalert』- Prepalert自体については本発表ではあまり触れないので、続きはブログで

仕組みを入れたことによる恩恵 - 振り返り時間短縮 1. 週次定例中にWarningアラートを振り返りきることができる 重大な事故に繋がりそうであるか？という初期判断に必要な情報が 出揃っている状態なので、スムーズに振り返りができる。 この場合、『response timeのp99が1.5秒より長い』 というWarningアラートに対して、 『その期間のリクエストのパスごとにレスポンスタイムを集計した 結果、 画像アップロードのAPIが1件 17.9秒かかっている。』 という情報がメモに自動的に書かれた状態にある 大きめの画像をアップロードした場合に 長く時間がかかるということがわかっているので、 エラーバジェットがまだあるので放念する。 ということがすぐ意思決定できる。

仕組みを入れたことによる恩恵 - 収集内容の拡充 2. 初期判断に必要な情報が拡充される。 週次定例中に判断するには情報が足りないとなったら、 『prepalert』の設定に書き足せば良いだけなので、 『この情報もほしい』というのが増えた。

仕組みを入れたことによる恩恵 - 収集内容の拡充 例: 『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のログをパス別に集計した結果』のみ

仕組みを入れたことによる恩恵 - 早期に問題を発見 ● 謎の15秒タイムアウト犯人捜索事件簿 Nginxのログがない ApplicationのError Logもない ALBのLogだけある ● ALBのログはある。 ● ALBによればTarget(接続先)が503を返している ● しかし、接続先のNginxはアクセスログがない。 ● 他のアラートも15秒できっちり揃っている。 ● ALBのタイムアウトは15秒より長く設定している 一体誰が接続を切っているんだ (・・?

仕組みを入れたことによる恩恵 - 早期に問題を発見 ● 謎の15秒タイムアウト犯人捜索事件簿 Timeout!!!!! 実はApp Meshの設定由来だった。 マイクロサービスのプロダクトで、 コントロールプレーンにEnvoyがいました。 EnvoyがTaskにくる通信を Proxyしているのようですが、 Nginxが何かしらの理由で通信できなかったようで す。 その結果、envoyがHTTP Status 503を返していた ようです。 App Meshの15秒タイムアウト設定に 気がついてなかった！！！

仕組みを入れたことによる恩恵 - 早期に問題を発見 ● 他システム向けの脆弱性攻撃でエラーバジェット損失！事件簿 ALB Target 5xx > 0 のWarningアラート。 500で、見知らぬPath、見知らぬエラーログ。 09:10:20.67568+09:00

仕組みを入れたことによる恩恵 - 早期に問題を発見 ● 他システム向けの脆弱性攻撃でエラーバジェット損失！事件簿 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エラーを返しているので エラーバジェットは無駄に削れている。

仕組みを入れたことによる恩恵 - 早期に問題を発見 ● 他システム向けの脆弱性攻撃でエラーバジェット損失！事件簿 ALBに到達したうえで5xxエラーなると SLO違反でエラーバジェットが削れます。 なので、 WAFで対策を入れました。 Application側には到達しません また、これがWAFの設定を 見直すいい機会にもなりました。

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

Kayac Techblogもよろしく!