🐺👀
監視せなあかんし五大紙だけにオオカミってな日本経済新聞社 デジタル編成ユニットNikkei Tech Talk #3Yuta IDE#nikkei_tech_talk
View Slide
自己紹介{"名前": "Yuta IDE","所属": ["デジタル編成ユニットWebチーム","技術戦略ユニット"],"職務": "電子版のWeb開発","マイブーム": “料理"}2
今日話すこと3● 日経では Sentry, StatusCake, PagerDuty などのアラート基盤(後に詳解)を導入しているが、アラートとして扱わなくてもいいようなノイズが多く、オオカミ少年問題を引き起こしている● 10~12月の3ヶ月開発を止めてあらゆる負債を返済する時間を確保したので、そのときにオオカミ少年問題にも取り組んだ● オオカミ少年問題の原因はどこにあって、どのように減らすかを考える
オオカミ少年問題とは4いわゆるアラート疲れアラート疲れは、オペレータが頻繁に多くのアラートにさらされることで、アラートに鈍感になってしまう場合に起こります。オペレータが偽のアラートに慣れてしまうとどんどん鈍感になっていきアラートへの応答時間が悪化します。これによりアラートシステムの全体的な有効性が低下します。https://www.oreilly.co.jp/books/9784873119847/
俺たちのイカれたオオカミを紹介するぜ5
俺たちのイカれたオオカミを紹介するぜ6
実はオオカミではありませんでした7
8https://www.pakutaso.com/20190409116post-20652.html
9https://www.pakutaso.com/20190437112post-20552.html
10
11闇
日経電子版の闇12● Webチームだけで30個以上の稼働中のレポジトリを管理しており、中には誰も知らない古いサービスもある● Sentryなどの導入はされているものの運用を引き継がれていない.って言うと本当に人事に怒られそうなので……
日経電子版の光13● 大幅機能アップデートのタイミングで何度かリプレイスしており、JSP → Handlebars → (p)react +NodeJSで自作SSR と作り替えており、VCL(Fastly Varnishの記述言語) のRust 刷新(C@Eへの移行)や電子版外では Next.js の運用も始まっている● 3ヶ月丸々負債返済活動をさせてくれるほど理解を得られたり、技術選定を現場判断で行えるのでハードスキルとしての技術力を伸ばすには本当に良い環境● Developer Experience を大事にしているWe are hiring.
光があるところには影がある14● とはいえ、リプレイスはユーザー影響の大きいページのみがメインであり、まだ旧基盤のコードもたくさん残っている● 旧基盤のコードは基本的にメンテしなくていいのだが、昔の人が入れた Sentry は動き続け、載せ替えたデプロイ先の GKE からは Cloud Monitoring は計測を続け、Datadog はwarn warn warn🐶● 監視チャンネルのアラートが暴発しているので直していく
何が監視チャンネルに送っているのか15名前 用途 送っているかDatadog コンテナのログの集積地 ❌Elasticsearch + Kibana アクセスログの集積。 HTTP Status ごとの集計などが可能になる。オリジンの前段にも対応❌Sentry アラート目的 ⭕StatusCake 外形監視 ⭕Pager Duty Status Cake の結果を電話で通知 ⭕Cloud Monitoring GKE 基盤のログが集まる ⭕CloudWatch AWS 基盤のログが集まる ⭕
CDNMonitoringLogGKEreq / resreq / resSync manifestsObserve PushIntegrateSend logSend logAPIGWreq / resPushattachOrigin Servers全体感 reporeporeporepo・・・一覧ページreq /res詳細ページ検索ページ・・・
一個一個設定を見直していくぞ！17
まずは軽めなものから18
Status Cake の設定を見返す19● 外形監視ツール● 疎通に加え、ドメインや証明書の期限チェックもしてくれる● これはオオカミ少年になっていなかった
Pager Duty の設定を見返す20● オンコールツール● 問題が起きた時にあらかじめ登録しておいた電話番号に電話がかかってくる● 当番性があるので当番が電話を受け取る設定にしている● Status Cake と連動させており、Status Cake の検知で電話がかかる。そのため Status Cake の設定がOKならこれもOK
Cloud Watch の設定を見返す21● エラー通知がたくさんチャンネルに流れてきていた。Elastic Beanstalk の設定によって送られてくるエラーで何が何だか分からない● 元々AWS->GCP移行した後にセカンダリとして動作させていた AWS 環境へのデプロイが、デプロイプロセスで行うヘルスチェクリクエストで必ず失敗するため、デプロイのたびに常にアラートが流れている● マルチクラウドする場合も Elastic Beanstalk は使わないので、AWS 系のアラートはそれ用のチャンネルに分離した。見なくてもいい運用にもした
ここからヘビー級のエラー22
Cloud Logging の設定を見返す23● Cloud Logging は GCP のサービス● GKE を使うとロギングされアラートの作成も行えて監視にも使える● コンテナのエラーログだけでなく、コンテナのハードウェア的なメトリクスも監視できる● 我々の無邪気な console.error が通知され続ける
じゃあ消せばいいじゃん？24● アラートをignoreする設定を入れる？● 本当に見ないといけないアラートもignoreされてしまわない？● 放置してもいいアラートでもスパイクしたら対処しないといけなくならない？放置していいエラーかどうか分析する必要がある
Cloud Monitoring の分析大変25● Incidents 一覧からサービス名・アラート名で集計したい● しかし Incidents ダンプできない● サポートに問い合わせると「画面をクロールするとできます」「Slackとかに集積するといいですよ」と言われる😵クロールするぞ！
２段階認証で守られたページをクロール26● Incidents ページはページネーションUIだが連番IDではない● 2段階認証はレスポンスのクッキーそのまま使いまわせば突破できる● Incidents のページのレスポンスをジッと眺めると token をリクエストに付与して、得たレスポンスから nextToken を得られる連鎖的に呼べば引き抜ける
雑な正規表現とreduceで集計する27ほとんどが Container Error log
Sentry と被るので消す28● Container Error Log の内容はほとんどが Sentry でもカバーできるので、アラートの対象外とする● なのでハードウェアのメトリクス、コンテナリスタートの異常値だけをアラートとして受け取るようにする
CPU利用率等はアラート対象にすべきか29https://www.oreilly.co.jp/books/9784873118642/● これらのメトリクスは誰かを叩き起こすには値しません。● 「そのサーバーはやるべき処理はしているんだろ？」「それなら何も問題はないじゃないか」● 電子版はCDNで9割以上捌くので、CPUやメモリ利用率が高まるのは注視すべき事項と言える。電話までは行かないがSlackに通知するくらいはしておく。
Sentry に来ているアラートを見返す30● アラートチャンネルに常駐する● Issue を event 数で sort して、Slack連携されているIssueを全部見る● 無視していいものか判断する
一筋縄では行きませんでした！31
32どうやってデバッグしろ言うねん！（解決方法は後ほど紹介）
苦労したエラー３選33
Bingbot34● 存在しないエンドポイントへのアクセスだが、出鱈目なパスというわけではない● ユーザーがそのリンクを辿っているのなら無効なリンクが残っていると言うことで対処すべき事案● kibana で該当リクエストを探し出して HTTPRequest を見てみると全て Bing の botだった○ 全てbotだったのでignore
retry による発火35● 電子版のアプリケーションサーバーはサービス間通信が失敗することが前提で設計しており、retry 機構がある● retry に成功したとしても失敗した try が FetchError として Slack に通知される● HTTP通信のログとしてみると正常系としてレスポンスできているのにアラートが上がる● 全体で失敗しなければアラートではなくワーニングにすべきだった。Sentry SDK にもログレベルは存在するので活用すべき
node-fetch timeout36● 何も情報がなくてサーバー内部のエラーか、ネットワーク経路のエラーか分からない● 大多数のリクエストは成功しているのでネットワーク起因の問題もあり得る● 原因切り分けの一つの選択肢としてtcpdump。 パケットキャプチャしてデバッグする○ 結局原因分からなくてまだ調査中
tcpdump を使うためには37● 普通に tcpdump コマンドを使えばいいが、稼働しているサーバーはTLSで暗号化されているため覗けない● 暗号化を解く必要がありそのための仕組みとして –tls-keylog がある● が、このオプションが使えるのは Node v12.3 からであり、それより前のバージョンで動いているものにはデバッグを仕掛けられない日頃から最新にしておきましょう、ということで
Node バージョンアップ計画を実施38● 全サービスの Node.js のバージョンを最低でも 16, 理想的には 18 に上げる計画を負債返済活動期間に実施していた● 各バージョンでの regression test tool を作ってアップデート● node-gyp error, node-sass から dart-sass へ, もろもろのパッケージの deprecated と戦う
そもそもエラー返ってるけど大丈夫？39● コードを読んでみたところ、該当箇所のエラーが原因で Navigation Request に対して InternalServerError が返っていることが判明● しかし正常系のHTMLはCDNにあり、stale-if-error を設定しているのでユーザーからすると壊れない○ stale-if-error: RFC5861 HTTP Cache-Control Extensions for Stale Contentで追加された Cache-Control Header の一種。HTTP リクエストに失敗した時にキャッシュを使える● Fastly様様 :pray:
オオカミかどうかの識別をするためにすべきこと40
エラーにはメタ情報を付与する41● name, message, trace の情報を持ち回る● name を指定しなければ Sentry の Issueタイトルが Error だけになって分類が大変● message を指定しなければ undefined だけになって何の Error か分からない● Custom Error の定義がおすすめ
エラーを握りつぶさない42● ランタイムから上がってきたエラーはそのまま持ち回ること● Stack Trace の保持や Error Cause の作成などを心がけること● Error Cause は強力なのでサポートされている Node v18 を使おう
オオカミ少年問題を起こさないためにすべきこと43
アラートの定義をする44● Sentryなどに（個人的には）なんでもかんでもまず送るのは正しいと思うが、アラートするかどうかはまた別○ My Opinion: ログを保存するだけでコストがかかるが、それはなんでもかんでも送るほどエラーを連発している状態が問題であって、送る姿勢は間違いではないと考えている。普通のログもストレージに対してであればドンドン送っていいと思う。● 電話をするほどの事態とは、Slackに流すほどの事態とはという合意をチームで持っておこう
ログレベルを使い分ける45● SentryはError以外の定義を使える○ Console: log, debug, info, warn, error○ Sentry: captureException, captureMessage, fatal, error, warning, log, info, debug● どういうときにどのレベルを使うかの話し合いもチームでしておこう● レベルごとにSlackに送るか、電話をかけるかという設定を行える
運用手順書を作る46● そもそもアラートの扱いや運用の合意がないことが問題なので、運用手順書を作っておこう○ アラートが上がった時の初動について○ アラートは誰が対処するか○ アラートの調査ログはどこに集約するか○ アラートをクローズするための条件● Sentry SDK の使い方の共有や、ログレベルの合意も忘れずに！
まだ完走していないけど感想47
３ヶ月の成果48● Sentryに詳細なメタデータもログとして出るようになった● 毎日10回以上通知されていたアラートを1日1,2件に抑えられた● チームメンバーが alert チャンネルの通知を元に朝８時に5分で本当のインシデントに対応できた● 結果として開発者体験の向上に貢献
アラート改善活動で自分がしたこと49● 契約中のSaaSの設定、manifest yaml の反映● アラートログをdumpして集計し、アラートの傾向を分析● エラーログが出た箇所を読み、原因を特定し、アラートとして扱うべきか判断する● Sentry, Datadog, Kibana 色々なツールを組み合わせてリクエスト一つ一つを分析する● 情報のないアラートに適切な情報が出るようにする● フロントエンド起因でなさそうであれば適宜バックエンドのコードを確認したりMTGをセットするアプリケーションからプラットフォームまで、運用という観点から広く関われて楽しい！
アラート改善活動の醍醐味50● 古いアプリケーションを含めて、日経のサービスがどう動いているかを知れる● サービスがどう動いているかを、チームや職能の垣根を越えて知れる● 運用を考えることでチームや組織という点に目が向くようになるアプリケーション開発だけではできなかった成長の機会
これでアラートが正常化してめでたしめでたし！？51
🌍💥52
📞53
54
＿人人人人人人人人人人人人人人＿＞ On Call 当番をすっぽかす ＜￣^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^￣55
マナーモードでも特定の番号から電話がなるようにする設定を忘れずに！56
sadnessojisan
chatwork_hr
yatasunshine
iimokoy
_tanako
pospome
kazuhitoyokoi
mkeeda
hschwentner
okaharuna
suzukihoge
tomokusaba
monicaribeiro
akmur
samanthasiow
notwaldorf
andyhume
sugarenia
jnunemaker
paulrobertlloyd
mongodb
erikaheidi
dougneiner
rocio
philhawksworth