🚨

2日間詰まったエラー → Sentryで可視化

に公開
AI
Sentry
zennfes2025infra
tech

TL;DR

  • 症状: 本番で Net::ReadTimeout / RedisClient::CannotConnectError / JSON::ParserError が多発
    再試行が雪だるま式に増加。
  • 仮説: アプリのバグではなくリソース枯渇（メモリ）起因のタイムアウト。
  • 施策: SentryのDiscoverでSidekiq向けの単一ウィジェットを作成し傾向を可視化
    → ダッシュボードで常時監視 → Renderのメモリを 512MB→2GB に増強。
  • 効果: 失敗率 33% → 0〜5%、P95処理時間 38分 → 15分、Redis接続エラーほぼ0件。

この記事は「Sentryを“通知箱”で終わらせず、最低限のウィジェットだけで原因切り分けに使う」ための、実運用で効いた最小構成をまとめたものです。

誰のための記事か

以下の課題を感じている人

  • タイムアウトや外部APIエラーが散発し、原因が特定しにくい
  • Sentryを入れているが、通知がくるだけで意思決定につながらない

この記事で得られること

  • 失敗が「どの工程で」「なぜ」起きているかを、SentryのDiscoverで把握する手順
  • サーバー側のメトリクスと突き合わせ、アプリ由来かリソース由来かを切り分ける思考法

背景

対象は、30〜60分の音声を処理するAI分析ジョブ。
Rails + Sidekiqをデプロイ。ある週を境に失敗率が 33% まで上昇し、再試行が積み上がって処理遅延の悪循環に入りました。
ログは断片的（timeout/broken pipe）で、本番再現も難しく、原因の当たりが付けられない状態でした。

課題

根本課題はエラーが工程横断で混ざって見えることでした。
まずは「どこで」落ちているかをSentryで可視化します。

手順1: Discoverでウィジェットを作る（実際にやったこと）

SentryのDiscoverで、Sidekiqエラーの傾向を把握するための単一ウィジェットを作成し、これだけで十分な示唆が得られました。設定は次のとおりです（そのまま再現可能）。

  • Display Name: Errors by Job (Sidekiq)
  • Dataset: Errors
  • Type: Bar
  • Visualize: count()
  • Filter: sidekiq（Sidekiq関連のイベントに絞り込み）
  • Group by: error.type
  • Sort by: High to low（count()）
  • Limit: 5 results

このウィジェットをダッシュボードに追加し、期間を「24時間/7日間」で切り替えながら見るだけで、Net::ReadTimeout と RedisClient::CannotConnectError が突出していること、かつ同じタイミングで増減していることが分かりました。

手順2: 監視のしかた

  • 期間は「Last 24 hours」を基準にし、急増があれば「Last 7 days」で傾向を確認。
  • 週次で「前週比のエラー種別トップ5」が入れ替わっていないかを見る。
  • アラートは最小限: 「5分間で同一 error.type が5件超」でSlack通知（プロジェクト共通のルールでOK）。

手順3: サーバーメトリクスと突き合わせ、原因を分解

Sentryウィジェットでエラー種別のスパイクを確認したら、サーバー側のメトリクスと照合して「アプリ要因か・リソース要因か」を切り分けます。

サーバー側で最低限見る指標（しきい値は目安）

  • メモリ使用率: 連続して80–90%に張り付き → スワップやGCでレイテンシ増大のサイン
  • Worker再起動数: 急増 → OOMやデプロイ設定の問題
  • 応答時間のスパイク: Sentryの error.type スパイクと同時かを比較

観測結果から「外部API不安定」ではなく「メモリ逼迫によるタイムアウト」が主因と判断し、Web/Workerを 512MB→2GB に増強しました。
メモリの使用状況が80%から20%になりました。

結果（Before/After）

  • RedisClient::CannotConnectError: 0件に収束
  • Net::ReadTimeout: ほぼ消失
  • 処理時間: 平均 30分 → 15分、P95 38分 → 15分
  • 失敗率: 33% → 0〜5%

CPU最適化よりも、メモリ不足起因の遅延（GC/スワップ）の解消が効きました。

運用を習慣化する（最小の運用）

Sentry側（アプリ視点）

  • 週次で error.type のトレンドを見る（本記事のウィジェットを固定でOK）
  • アラート: 「5分間に同一 error.type が5件超」でSlack通知

サーバー側（基盤視点）

  • メモリ90%超を継続検知で警告
  • Worker再起動数を週次レビュー
  • レイテンシ急増はDatadog等に転送して相関を見る

この2点運用だけでも、「アプリの欠陥」か「リソースの不足」かを短時間で切り分けできます。

Sentry設定時の落とし穴（避けたいアンチパターン）

  • 可視化を凝りすぎる → まずは単一ウィジェットで傾向把握がおすすめです。
    効果が出てから拡張がよさそうに感じます。
    Sentryはできることが多い分設定に凝ると時間がかかってしまいそう。
  • 「通知を止める」運用 → 通知は減らすのでなく“要件を満たした時だけ鳴る”ように設計

学び

  1. 原因はコードにないことも多い。
    種類別の件数推移だけでも、基盤要因の兆候は見える。

  2. 可視化は“最小で始める”。
    単一ウィジェットでも「何が増えているか」が分かれば十分動ける。

Discussion