Article by: Sasha Blumenfeld, Gabriel Lopes
Sentry もダウンタイムとは無縁ではありません。実は私たちはかつて、誤ったマイグレーションによって自社のアプリケーションを停止させてしまったことがあります。重要なデータベーステーブルにフィールドを追加しようとしたところ、そのマイグレーションがテーブル全体をロックしてしまったのです。このテーブルは Sentry の動作に不可欠だったため、アプリ全体が停止してしまいました。ウェブサイトは読み込めず、データの取り込みも止まり… すべてが完全に止まってしまいました…
私たちはすぐに問題のクエリを特定して停止させましたが、もし主要なページにアップタイムモニタリングを設定していれば、もっと早く異常に気づけたかもしれません。これこそが、Uptime Monitoring を開発した理由です。
開発者が障害の原因を突き止めようと右往左往しているその1秒ごとに、ユーザーはページをリロードし、苛立ち、あるいは離れていきます。にもかかわらず、通常の対応プロセス（あるツールでアラートを受け取り、別のツールでログを調べ、何が起きたかを手作業でつなぎ合わせる）は遅くて苦痛を伴います。
私たちはトラブルシューティングの断片化が復旧を遅らせることを身をもって体験しました。だからこそ、障害が発生した瞬間に検知し、その修正に必要なコンテキストまで一か所で得られる仕組みを作ったのです。
Sentry の Uptime Monitoring は、単に「何かが落ちた」と通知するだけではありません。バグのあるコード、失敗したAPI、またはまったく別の原因かどうかを特定し、根本原因へと導きます。
Sentry Uptime Monitoringは、すべてのユーザーにご利用いただけるようになりました。すべてのプランに1つの無料モニターが含まれています。ユーザーが気づく前に、あなた自身でダウンタイムを検知しましょう。
Sentry の Uptime Monitoring
Sentryはサイトの稼働状況を監視し、ダウンタイムが検出された際に通知します。
設定されたURLに対して60秒ごとに HTTP リクエストでヘルスチェックを行い、Web サービスを能動的に監視します。タイムアウト、DNS 解決エラー、不正なレスポンスなど、問題が検出されれば即座に通知されます。
9月末のベータリリース以降、すでに約10万件のアクティブなアップタイムアラートが作成されました。さらに、皆さまからの要望が多かった機能も多数追加し、より使いやすくなっています。
- チェック履歴
「すべてが崩れる前にサイトが正常に動いていた証拠があれば…」と思ったことはありませんか？今ならあります。チェック履歴を使えば、過去のアップタイムチェックを確認したり、パフォーマンストレンドを追跡したり、ダウンタイムと他の問題との関連を見つけ出すことができます。詳しくはこちら - アップタイム問題詳細画面のUXを改善
インシデント調査時により多くの情報が得られるよう、問題詳細ページを全面的に刷新しました。これにより、チェック履歴のタイムライン表示、すべてのアップタイムチェックのクイックビュー、関連リクエストのトレースビューにアクセスできるようになっています。 - 分散トレーシング対応
アップタイムチェックが失敗したとき、探偵のように手がかりを追いかけたくはありませんよね。バックエンドサービスがSentry SDK でインスツルメントされていれば、リクエストのトレースをアップタイムチェックに自動的に関連付けます。そのため、必要なスパンや問題にすぐにジャンプでき、手作業で情報をつなぎ合わせる必要はありません。 - 地理的に分散されたチェック
午前3時の誤検知ほど、気分を台無しにするものはありません。ダウンタイムの見逃しと不要なアラートの両方を減らすため、現在は複数のロケーションからアップタイムチェックを実施しています。異なる地域で3回連続してチェックが失敗した場合にのみ、ダウンタイムとして認識される仕組みです。そのため、本当に対応が必要なときだけ、アラートが届きます。 - モニター設定の追加オプション
すべてのサービスが同じではないように、モニタリングのニーズも一様ではありません。今では、各スタックに最適な形で、チェック間隔やタイムアウトの設定をカスタマイズできるようになりました。
よくあるダウンタイムの原因 — Uptime Monitoring がどう役立つか
壊れたコードのプッシュ
一見無害に思えた変更をプッシュした結果、システム全体が危機的状況に陥ったという経験を、誰しも一度はお持ちではないでしょうか。あるチームでは、非同期ジョブ内の単純な型エラーが原因で、購入処理用の配信システムがクラッシュし、あわや大惨事という事態になりました。1つのジョブだけが失敗するはずが、クラッシュによってキュー全体がブロックされ、以降のすべてのジョブが実行されなくなったのです。
そしておなじみの JavaScript の典型的なミスといえば、1ページを更新したつもりが、サイト全体を壊してしまうことです。ある開発者はそれを痛い形で学びました。テストではすべて問題なく見えていたにもかかわらず、ほんの小さな見落としが大きな混乱を引き起こしたのです。そのコードは、特定の要素が常に存在すると仮定し、すべてのページで実行されていました。nullチェックがなかったため、該当の要素が存在しないページは即座にクラッシュが発生しました。
このコードは、なぜかPRレビューと社内テストを通過してしまいました。というのも、テスト対象となっていたのは、更新されたページのみだったからです。
問題が発覚したのは金曜の夕方。ちょうど大規模なオンラインセールの直前でした。そこからは、必死のデバッグ、徹夜の修正作業、そして「たった1つのif文が週末を台無しにした」という現実に直面することとなりました。
こうしたことは、誰にでも起こり得ます。しかし、Uptime Monitoringがあれば、もっと早く気づけたかもしれません。だからこそ、被害を最小限に抑えることができるのです。
依存関係の問題（サードパーティAPIなど）
外部 API に依存してアプリケーション全体を構築しておきながら、APIが最悪のタイミングでダウンする。これほど困ることはありません。
さらに悪いのは、まだ無料プランを使っていたことを忘れていてレート制限に引っかかるケースです。コントロールできない外部要因に依存していたせいで、アプリ全体が突然フリーズしてしまうのです。
皮肉なことに、これは私たちの「ダウンタイムシミュレーター」に実際に起こった出来事でした。このツールは、Uptime Monitoring の動作検証用に開発した小さなアプリケーションです。
先日、そのシミュレーターで Uptime Monitoring 機能をテストしていたところ、予期しない500エラーが発生しました。トレースビューでリクエストを追跡し、関連する問題やそのコンテキストを確認したところ、ホスティングプロバイダーが、無料プランであることを理由にRedisの使用をレート制限していたことが判明しました。🤦♀️
外部依存先のモニタリングと、レート制限がアプリケーションのパフォーマンスに与える影響の理解は、影響を回避するための有効な手段です。
インフラ障害や DDoS 攻撃
原因が自分のコードでも依存先でもないこともあります。
もしかすると誰かが悪意あるトラフィックであなたのサーバーを攻撃しているのかもしれません。ボットネットの標的になっている可能性もあれば、スクレイパーの軍団が今日こそ全力で叩こうと決めたのかもしれません。どのような理由だとしても、サイトは極端に遅くなり、ユーザーは次々と離脱していってしまいます。
Sentry は、単に「サイトが落ちた」と知らせるだけではなく、点と点をつないで状況を把握できるようにします。もしDDoS攻撃を受けていた場合、Sentry は使用量のスパイクを可視化し、関連する問題にフラグを立て、何が起きたのかを理解するためのコンテキストを提供します。
最近、あるお客様が「スパマーを10分以内に特定し、阻止できた」という事例を共有してくださいました。
Slack でエラーの急増を通知されたあるエンジニアは、最初は start_time の処理に問題があると疑いました。しかしSentryのJSON を確認したところ、コードは None 値を正しく処理していることが確認できました。関連イベントを調べる中で、同一ユーザー ID に対して異なるセッション ID が複数記録されており、どれも質問には一切回答していない「セッション終了イベント」が見つかりました。すべての兆候が、ボットによる活動を示していました。
9分以内に、Sentry は素早くデバッグに必要なコンテキストを提供し、ボット行為を確認し、システム全体に影響が及ぶ前に対処することができました。
Uptime Monitoring を始めよう
Uptime Monitoring は自動的に有効化され、設定は不要です。エラーデータ内で最も頻繁に登場するホスト名に対して常時モニタリングが行われ、最も重要なサービスが継続的に監視されます。
特定のURLに対して、カスタムのアップタイムモニタリングアラートを作成することも可能です。HTTP メソッド、ヘッダー、ボディパラメータなど、リクエストの詳細も自由に設定できます。「アラートルール」タブで最新の稼働状況（Up または Down）を確認し、期待されるレスポンスコードに応じてアラートをカスタマイズし、ダウンタイムが検出されると、Slack で即時通知を受け取ることができます。
カスタムアラートを作成するには
- 「アラート」セクションに移動し、「アラートルールを作成」をクリック
- 「Uptime Monitor」を選択して、アップタイムアラートを作成
- 定期的なアップタイムチェックを行うために、URLとリクエストメソッドを指定してアラートを設定
すべてのプランに1つの無料モニターが含まれており、追加のモニターは1つあたり月額1ドルです。
ぜひお試しいただき、ご感想をお聞かせください。フィードバックは GitHub で共有するか、Discord でのディスカッションにご参加いただけます。
Sentryをまだご利用でない方は、無料でサインアップするか、デモをリクエストしてご利用を開始してください。
Original Page: Your App Might Be Down; Let’s Fix It – Introducing Sentry Uptime Monitoring
IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
