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

監視せなあかんし、五大紙だけにオオカミってな🐺🐺🐺🐺🐺

 監視せなあかんし、五大紙だけにオオカミってな🐺🐺🐺🐺🐺

🐺👀

sadnessOjisan

January 26, 2023
Tweet

More Decks by sadnessOjisan

Other Decks in Programming

Transcript

  1. 今日話すこと 3 • 日経では Sentry, StatusCake, PagerDuty などのア ラート基盤(後に詳解)を導入しているが、アラートとし て扱わなくてもいいようなノイズが多く、

    オオカミ少年 問題を引き起こしている • 10~12月の3ヶ月開発を止めてあらゆる負債を返済 する時間を確保したので、そのときにオオカミ少年問 題にも取り組んだ • オオカミ少年問題の原因はどこにあって、どのように 減らすかを考える
  2. 10

  3. 日経電子版の光 13 • 大幅機能アップデートのタイミングで 何度かリプレイスしており、JSP → Handlebars → (p)react +

    NodeJSで自作SSR と作り替えており、VCL(Fastly Varnishの記述言語) のRust 刷新(C@Eへの 移行)や電子版外では Next.js の運用も始まっている • 3ヶ月丸々負債返済活動をさせてくれる ほど理解を得られたり、技術選定を現場判断で行えるので ハードスキルとしての技術力を伸ばすには本当に良い環境 • Developer Experience を大事にしている We are hiring.
  4. 光があるところには影がある 14 • とはいえ、リプレイスはユーザー影響の大きいページ のみがメインであり、まだ旧基盤のコードもたくさん 残っている • 旧基盤のコードは基本的にメンテしなくていいのだ が、昔の人が入れた Sentry

    は動き続け、載せ替え たデプロイ先の GKE からは Cloud Monitoring は 計測を続け、Datadog はwarn warn warn🐶 • 監視チャンネルのアラートが暴発しているので直して いく
  5. 何が監視チャンネルに送っているのか 15 名前 用途 送っているか Datadog コンテナのログの集積地 ❌ Elasticsearch +

    Kibana アクセスログの集積。 HTTP Status ごとの 集計などが可能になる。オリジンの前段に も対応 ❌ Sentry アラート目的 ⭕ StatusCake 外形監視 ⭕ Pager Duty Status Cake の結果を電話で通知 ⭕ Cloud Monitoring GKE 基盤のログが集まる ⭕ CloudWatch AWS 基盤のログが集まる ⭕
  6. CDN Monitoring Log GKE req / res req / res

    Sync manifests Observe Push Integrate Send log Send log APIGW req / res Push attach Origin Servers 全体感 repo repo repo repo ・ ・ ・ 一覧 ページ req / res 詳細 ページ 検索 ページ ・ ・ ・
  7. Cloud Watch の設定を見返す 21 • エラー通知がたくさんチャンネルに流れてきていた。 Elastic Beanstalk の設定によって送られてく るエラーで何が何だか分からない

    • 元々AWS->GCP移行した後にセカンダリとして動作させていた AWS 環境へのデプロイが、デプロ イプロセスで行うヘルスチェクリクエストで必ず失敗するため、デプロイのたびに常にアラート が流 れている • マルチクラウドする場合も Elastic Beanstalk は使わないので、AWS 系のアラートはそれ用のチャ ンネルに分離した。見なくてもいい運用にもした
  8. Cloud Logging の設定を見返す 23 • Cloud Logging は GCP のサービス

    • GKE を使うとロギングされアラートの作成も行えて監視にも使える • コンテナのエラーログだけでなく、コンテナの ハードウェア的なメトリクスも監視できる • 我々の無邪気な console.error が通知され続ける
  9. Cloud Monitoring の分析大変 25 • Incidents 一覧からサービス名・ア ラート名で集計したい • しかし

    Incidents ダンプできない • サポートに問い合わせると「画面をク ロールするとできます」「Slackとかに 集積するといいですよ」と言われる 😵 クロールするぞ!󰝢
  10. 2段階認証で守られたページをクロール 26 • Incidents ページはページネーションUIだが連番 IDではない • 2段階認証はレスポンスのクッキーそのまま使い まわせば突破できる •

    Incidents のページのレスポンスをジッと眺める と token をリクエストに付与して、得たレスポン スから nextToken を得られる 連鎖的に呼べば引き抜ける
  11. Sentry と被るので消す 28 • Container Error Log の内容はほとんどが Sentry でもカバーできるので、アラートの対象外とする

    • なのでハードウェアのメトリクス、コンテナリスタートの異常値だけをアラートとして受け取るようにす る
  12. Sentry に来ているアラートを見返す 30 • アラートチャンネルに常駐する • Issue を event 数で

    sort して、Slack連携されているIssueを全部見る • 無視していいものか判断する
  13. retry による発火 35 • 電子版のアプリケーションサーバーはサービス間通信が失敗することが前提で設計しており、 retry 機構がある • retry に成功したとしても失敗した

    try が FetchError として Slack に通知される • HTTP通信のログとしてみると正常系としてレスポンスできているのにアラートが上がる • 全体で失敗しなければアラートではなくワーニングにすべきだった。 Sentry SDK にもログレベル は存在するので活用すべき
  14. tcpdump を使うためには 37 • 普通に tcpdump コマンドを使えばいいが、稼働しているサーバーは TLSで暗号化されているた め覗けない •

    暗号化を解く必要がありそのための仕組みとして –tls-keylog がある • が、このオプションが使えるのは Node v12.3 からであり、それより前のバージョンで動いている ものにはデバッグを仕掛けられない 日頃から最新にしておきましょう、ということで
  15. Node バージョンアップ計画を実施 38 • 全サービスの Node.js のバージョンを最低でも 16, 理想的には 18

    に上げる計画を負債返済活 動期間に実施していた • 各バージョンでの regression test tool を作ってアップデート • node-gyp error, node-sass から dart-sass へ, もろもろのパッケージの deprecated と戦う
  16. そもそもエラー返ってるけど大丈夫? 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:
  17. エラーにはメタ情報を付与する 41 • name, message, trace の情報を持ち回る • name を指定しなければ

    Sentry の Issue タイトルが Error だけになって分類が大変 • message を指定しなければ undefined だ けになって何の Error か分からない • Custom Error の定義がおすすめ
  18. エラーを握りつぶさない 42 • ランタイムから上がってきたエラーはそのまま持ち回ること • Stack Trace の保持や Error Cause

    の作成などを心がけること • Error Cause は強力なのでサポートされている Node v18 を使おう
  19. ログレベルを使い分ける 45 • SentryはError以外の定義を使える ◦ Console: log, debug, info, warn,

    error ◦ Sentry: captureException, captureMessage, fatal, error, warning, log, info, debug • どういうときにどのレベルを使うかの話し合いもチームでしておこう • レベルごとにSlackに送るか、電話をかけるかという設定を行える
  20. 3ヶ月の成果 48 • Sentryに詳細なメタデータもログとして出るようになった • 毎日10回以上通知されていたアラートを 1日1,2件に抑えられた • チームメンバーが alert

    チャンネルの通知を元に朝8時に 5分で本当のインシデントに対応できた • 結果として開発者体験の向上に貢献
  21. アラート改善活動で自分がしたこと 49 • 契約中のSaaSの設定、manifest yaml の反映 • アラートログをdumpして集計し、アラートの傾向を分析 • エラーログが出た箇所を読み、原因を特定し、アラートとして扱うべきか判断する

    • Sentry, Datadog, Kibana 色々なツールを組み合わせてリクエスト一つ一つを分析する • 情報のないアラートに適切な情報が出るようにする • フロントエンド起因でなさそうであれば適宜バックエンドのコードを確認したり MTGをセットする アプリケーションからプラットフォームまで、運用という 観点から広く関われて楽しい!
  22. 54