Sentry - Ichizoku

ダウンタイムの一般的な原因とウェブサイト監視のメリット

Article by: Lewis D. 本ブログの内容どの Sentry 機能が使用されているのかウェブサイト監視による過負荷の検出アップタイム監視による不良デプロイの検知アップタイム監視による依存関係問題の検知なぜアップタイム監視だけではセキュリティ脆弱性を検知できないのかユーザーに指摘される前にダウンタイムのアラートを受け取るダウンタイムは、最も都合の悪い瞬間に発生します。例えば、「クイックデプロイ」の直後や、思い切って5分間離れた時などです。トラフィックの急増によってエンドポイントの一つが集中的にダウンし、他のエンドポイントもダウンしてしまうかもしれません。あるいは、自信を持って本番環境に直送した「小さな変更」が原因かもしれません。どちらの場合も、ユーザーはサイトにアクセスできず、現在は本番環境でライブデバッグを行っています。この記事では、基本的なウェブサイト監視によって、ステータスページの更新、Slack の通知、ツイートなどの前に、より早く問題を発見できる方法を解説します。シンプルな Node.js Express アプリを用いて、監視によってパターンやボトルネックが明らかになり、ひょっとするとコーヒーを飲み終える時間を稼ぐことができる方法をご紹介します。本題に入る前に少し余談ですが、物事をシンプルにし、完全に理論的な話にならないようにするために、基本的な Node.js Express アプリを立ち上げ、完全なエンタープライズ監視スタックにすることなく、実用的な監視機能だけに接続しました。私が設定した内容は次のとおりです。 Sentry トレーシングなので、何かが壊れたときにアラートが届きます。ソースマップは Sentry Wizard 経由でアップロードされます。縮小されたスタックトレースは最悪だからです。アプリを軽量ホスティングサービスに投入 Sentry にアップタイム監視アラートを作成しました。これは、パブリックエンドポイントにpingを送信し、応答が停止した場合にアラートを出します。トレーシングとは別に動作するため、アプリがエラーを投げていなくても、全く応答していない状態を検知します。どの Sentry 機能が使用されているのかこの記事で紹介する Sentry のすべての機能とその役割を簡単にまとめたマップを以下に示します。特徴監視対象以下に使用されている箇所アップタイム監視パブリックURLまたはエンドポイントにアクセスできるかどうかエンドポイントによってサイト全体がクラッシュしたときに、最初のアラートが出され、その後、別の分離されたエンドポイントルートに対してアラートが出されます。エラー監視処理されない例外とログに記録されたエラー不適切なデプロイ後に発生したパッケージ欠如によるスタックトレース […]

アプリケーションのパフォーマンスを関数呼び出しレベルまでデバッグ ― 継続的プロファイリングとUIプロファイリングの導入

Article by: Will McMullen 本番環境で何かの動作が遅くなった場合、古い習慣に陥りやすいものです。ログをいくつか追加し、メトリクスを送信し、ローカルで問題の再現を試みます。意欲があれば perf や py-spy に手を伸ばすかもしれません。トレースは役立ちますが、特にスタックの深い部分では、「なぜ遅いのか」を説明するには不十分なことがあります。つまり、開発者がアプリケーションの挙動を、直感に頼って推測せざるを得ない場面が生じます。たとえば、プロパティドリルによってレンダリングが肥大化していたり、状態変更によって不要な再レンダリングが発生していたり、あるいはサードパーティ製のライブラリが静かに 500 個のイベントリスナーを起動していたりするかもしれません。こうしたときにこそ、プロファイリングが役に立ちます。プロファイリングは症状を指摘するだけでなく、CPUを消費している関数呼び出しやファイル、行番号を正確に表示します。本日、私たちは Continuous プロファイリングと UI プロファイリングの2つの強力なプロファイラーをリリースします。実行時の動作を関数レベルで可視化し、ボトルネックを迅速に特定して解決するための機能を提供します。バックエンドのボトルネックを特定して解決する Continuous プロファイリング開発マシンでは問題なく動作していました。ステージングテストも問題なし。しかし、本番環境で実際の負荷がかかると、その重要な API エンドポイントが突然遅くなったり、バックグラウンドワーカーが予期せず大量のメモリを消費したりすることがあります。ログは正常に見え、トレースによってサービスがアクセスされたことも確認できているのに、内部のボトルネックが特定できない…。そのようなとき、開発者は再現が困難な問題や、隠れた非効率性を推測するしかありません。継続的プロファイリングは、このような状況において、バックエンドの実行状況を常時可視化を提供します。長時間実行されるワークロード、リアルタイム API、「ローカルでは問題なかった」と片付けられがちなコードパスの解析に最適です。特に、以下のような場合に役立ちます。 CPU ホットスポット：あるエンドポイントが突然 CPU 使用率が3倍に急増し、原因が分からない場合、プロファイリングは機能レベルのボトルネックを直接特定できます。バッチジョブ：何時間も静かに実行される（時にはクラウド請求を倍増させる）あの夜間処理。いまでは、それがどこで時間を費やしているのかを正確に確認できるようになりました。 ML パイプライン：あるモデルパイプラインで発生していたレイテンシのスパイクを、プロファイリングを使ってわずか 10 分ほどで、10 秒短縮しました。調べてみると、パイプラインの一部が「想定以上の処理」をしていたのです。詳細はこちらをご覧ください。アナリティクス：あなたの「インサイトエンジン」が、実際には数百万行を回すだけのループにすぎないこともあります。プロファイリングは、ログやメトリクスでは見えない非効率を、プロダクション環境に影響が出る前に発見する手助けをします。バックエンドサービスのパフォーマンスは、ブラックボックスのままである必要はありません。Continuous プロファイリングを使えば、インフラコストの最適化、API レスポンスの遅延削減、スループットの向上が可能になり、Slack が通知であふれる前に非効率を簡単に見つけられます。現在、Node.jsとPythonを標準でサポートしています。 […]

AIアシスタントに対する考え方を変えたSentryのAI

Article by: Dan Mindru ブロックチェーン、IoT、ビッグデータ… テクノロジー業界で長く働いていると、こうしたバズワードが時折現れては話題をさらい、やがて輝きを失っていく光景を何度も見ます。多くの流行が生まれては消えるのを経験してきた私は、つい懐疑的になってしまいます。今回も、「今度は何を売り込もうとしているのか」と考えてしまいました。これを「愚痴っぽい」と言う人もいれば、「エンタープライズ・アーキテクト的だ」と言う人もいます。だから、AIアシスタントを最初は単なるバズワードだと思っていたことを、どうかお許しください。所詮は、きれいな箱に入った5つの API 呼び出しにすぎないと思っていたのです。ところが、私は大きく間違っていました。 AIアシスタントとは平たく言えば、AIアシスタントは販売管理から会議のスケジュール調整、コピーライティングまでを、少ない手間で短時間にこなす有能なチームメイトのような存在です。複数のプロンプト、API 呼び出し、認証、ユーザー入力を組み合わせて構築され、必要に応じてワークフローを自動的に計画できます。万能でも低価格でもありませんが、すでに私たちの働き方を変えつつあります。さらに、AI の総コストが下がりつつある現状を踏まえると、AI 機能を実装する際の主流の選択肢になる可能性があります。詳しく知りたい方は、AI エージェントに関する記事もご覧ください。ご自身のアプリでの活用方法を解説しています。すべてが始まったバグ私は「技術的に進んでいない」と感じていたため、しばらくの間、AIアシスタントを軽視していました。それは「ただの AI」に、ほんの少し装飾を加えた程度のものだと思っていたのです。しかし、インディーハッキングでの経験から学んだのは、製品を作るうえで重要なのは先進的な技術そのものではなく、解決できる問題だということです。 AIアシスタントは間違いなく強力なツールです。ただし、大きな力には大きな責任が伴います。すべての問題を解決できるわけではなく、最速の手段とも限りません。それでも、確かに有用な使用例があります。私が信じていなかった理由のひとつは、そうした使用例を実際に見たことがなかったからなのですが、ある日、お気に入りのモニタリングプラットフォームで見つけた機能が、私の視野を大きく広げることになったのです。その機能とは、Sentry の AI Autofix（現在はベータ版ですが、まもなく一般公開されるでしょう）です。すべては、ほとんどの良い話がそうであるように、一通のメールから始まりました。私のように「バグなんて書かない」という方でも、これはきっと驚かれると思います。誤検出に違いないと考え、「Sentry で表示」をクリックして事態を確かめました。そして…　このあと何が起こったのか、きっと信じられないでしょう…。私が初めて感動した AIアシスタントAI Autofix 問題を開いた瞬間、自分の能力を過大評価していた可能性がすぐに明らかになりました。「これは、例外が規則を証明するケースに違いない」と、自分に言い聞かせます。しかし、問題ビューの右上隅にあるソリューションハブが目に入りました。原因はどう見ても間違っていて、私は思いました。「なるほど、Sentry も AI ブームに乗ってきたか。今日は大きく失望させられるかもしれないな」と。 ……冗談はさておき、最初は単なる一発のプロンプトに見えました。ですが、私の興味を強く引いたのは「Open Autofix」ボタンです。Sentry はこの問題に対して豊富なコンテキストを保持しています。コードベース、ソースマップ、例外の詳細、さらには多数の匿名ユーザープロパティまで。人間にとって Sentry が有用であるのと同じ理由で、AI にとっても有用になり得ます。そして、そのボタンを押した瞬間、この機能は単なるギミックではないと確信しました。初期分析と自己修正 […]

Vercel マーケットプレイスに新カテゴリー追加・Sentry 対応開始

Article by: Cody De Arkland 来年にかけて、これまでの10年間よりも多くの人々がアプリケーションを構築・出荷するようになるでしょう。あらゆる経験レベルの開発者によって「ローンチ」されるアプリケーションが増えるにつれ、「何が壊れたのか」「なぜ壊れたのか」、そしてそれを修正するための明確な道筋を理解することが、ますます重要になります。こうした背景から、Sentry は Vercel の新たな Observability Marketplace カテゴリーにおいて、最初のプラットフォームとしてローンチされました。 Sentry は、ソフトウェアを構築するすべての人が、メトリックの行をたどってデバッグを強いられたり、特別なダッシュボードビューを手作業で作成して問題の原因を探ったりすることなく、安心してソフトウェアを出荷できるようにしたいと考えています。 Sentry を開発が生まれる現場へソフトウェアの開発速度が加速する中で、コードが壊れることは避けられません。そこで、Vercel を通じて Sentry を簡単に利用できるようにすることで、開発者は壊れたコードを迅速に修正するための最短ルートを手に入れることができます。私たちは、開発者が最も利用するエコシステムへの継続的な投資を通じて、最良の開発者体験を提供することに注力しています。これにより、開発チームはソフトウェアの出荷において最も重要な部分に集中できるようになります。この開発者体験の大部分は、Next.js のような主要なプラットフォームにおいて、可能な限り摩擦のない体験を提供できているかどうかにかかっています。開発者は、1 行のコマンドを実行するだけで Next.js 上で Sentry を導入できます。これにより、クライアント・サーバー・エッジにわたる設定が自動的に行われ、コードのソースマップが生成され、エラー境界も実装されます。 Next.js アプリケーションでは、初回の設定コマンドを実行するだけで、エラーモニタリング、リプレイ、トレーシングが自動的に構成されるようになっています。これにより、アプリケーションの遅延や複雑なハイドレーションエラー、RSCに関する問題まで、あらゆる不具合を開発チームが迅速にデバッグできるようになります。しかし、これで終わりではありません！現在、Next.js に特化した新しいインサイトダッシュボードの開発に取り組んでいます。これは、Next.js を利用する開発者に対し、フレームワーク特有の視点からの環境モニタリング機能を提供することを目的としています。フレームワーク固有のインサイトページは、特定のフレームワークに投資した開発者に、監視プラットフォームから最も価値を得ている情報に密接に一致するインサイトを提供するように設計されています。私たちは、従来型の監視ツールについて、非常に多くの冗談を言ってきました。というのも、それらはしばしばユーザーを複雑なダッシュボードに縛りつけ、過剰に複雑なデータの解釈を強いるからです。そのため、一見すると Next.js 専用のダッシュボードは、かえって過去に戻るように感じられるかもしれません。ですが、ぜひ私たちの意図を聞いてください。開発者や運用チームが、Sentry の各機能からより多くのコンテキストを得られることに、私たちは強い関心を持っています。 Next.js アプリケーションは、フロントエンドとバックエンド、RSC、SSRといった技術のユニークな組み合わせを特徴としています。これらの特性に最適化されたビューを構築することで、開発者や運用チームがアプリケーション全体の状況をより深く理解し、適切な判断を下すための助けとなります。 Vercel マーケットプレイスでの Sentry Native 統合本日（April 8, […]

【PHP】パフォーマンスを改善する方法

Article by: Richard C. 本ブログの内容前提条件プロファイリングとは？ SPX を使った PHP プロファイリングトレーシングとは？ OpenTelemetry を使った PHP のトレーシングフロントエンドを含む分散トレーシングオンラインサービスを使ったプロファイリングとトレーシングクリーンアップ PHP のパフォーマンスを改善するヒント次のステップ PHP アプリは一見シンプルに見えますが、何かが遅くなり始めると状況は一変します。ページの読み込みに数秒余計にかかったり、原因がはっきりしないままサーバーコストが増加していたりしませんか？そんなときに役立つのがパフォーマンスモニタリングです。このガイドでは、PHP アプリケーションのパフォーマンスを監視・改善する方法を解説します。プロファイリングやトレーシングを使ってコードのボトルネックを特定し、アプリを最適化する方法を学びましょう。Docker を使っている場合でも、すでにローカルに PHP をインストールしている場合でも、例に沿って進めることができます。このガイドの内容は PHP 8 に対応しており、将来的な変更の程度によってはそれ以上のバージョンにも適用可能です。前提条件本ガイドに含まれるすべてのコード例は、Docker を使って任意のホスト OS 上で実行できます。Docker をお持ちでない場合は、こちらからダウンロードしてください。すでに PHP がインストールされている場合、Docker は不要です。次のセクションでは、プロファイリングとトレーシングを使って処理が遅いコード部分を特定する方法を紹介します。最後には、サイトのパフォーマンスを改善するためのベストプラクティスのチェックリストも掲載しています。プロファイリングとは？アプリケーションのプロファイリングとは、パフォーマンスデータを記録し、改善の余地があるコードを特定するために分析することです。パフォーマンス指標には、アプリがユーザーのために機能を実行するのにかかる時間、実行中に使用される CPU、メモリ、ディスク、ネットワーク帯域などが含まれます。これらすべての指標の値が低いほど、ユーザー体験が向上し、サーバーコストの削減にもつながります。記録された結果を分析することで、意図よりも高い値の指標を特定し、その原因となっているコード行を見つけます。 […]

【Sentry トレーシング】Next.js [Object] not found エラーを調査

Article by: David Y. 本ブログの内容サンプルアプリケーションのセットアップエラーの再現エラーの調査エラーの修正 Next.js アプリケーションでエラーを特定するための Sentry トレーシング設定 Sentry トレーシングで可能なその他の機能ローカル開発中は、ブレークポイントや console.log があなたの正気を保ってくれるかもしれませんが、本番環境の問題はまったく別の話です。本番環境では、エラーが複数のマイクロサービスに分散していたり、難読化されたコードに隠れていたりします。それらを追跡するのは至難の業です。そこで活躍するのが Sentry のトレースとスパンです。フルスタックかつ分散された環境において、ネットワークリクエスト、API 呼び出し、DB 取得などすべてを簡単に可視化できます。 Sentry の分散トレーシングは、Next.js アプリを通過する各ネットワークリクエスト、API 呼び出し、データベースクエリを明確かつ実用的に可視化します。推測に頼ることなく、パフォーマンスのボトルネックや複雑な障害が発生している箇所を正確にマッピングできます。分散トレーシングにより、例えばデータベースのレコード欠落や想定外のペイロードを返すエンドポイントなど、エラーの根本原因をすばやく特定し、エラーがユーザー体験全体にどう影響するかを正確に把握できます。さらに優れているのは、他人のコードをあさったり、リポジトリの権限を待ったりすることなく、本番トラフィックをデバッグできる点です。 Sentry が新たなエラーを検知した瞬間や、インサイトに予期しないスパイクが表示されたとき、特定のトレース ID に絞り込み、各リクエストを特定し、コールスタックが崩れ始めた正確な場所を突き止めることが可能なのです。分散トレーシングなら、以下のような状況でも簡単にデバッグできます。ソースコードへの読み書き権限がない場合デバッグ用のコードを追加でデプロイできない場合エラーメッセージがあいまいで不明瞭な場合複数のマイクロサービスが原因の特定を難しくしている場合本ガイドでは、ソースコードを見ることなく本番環境の問題を効果的にデバッグするために、Sentry のトレーシング機能を活用する方法をご紹介します。手元でセットアップして進められる、サンプルのコース管理アプリを用意しました。サンプルアプリケーションのセットアップこのコース管理アプリケーションは、TypeScript で記述されており、React フレームワークである Next.js を採用しています。型安全性の確保には tRPC を、データの永続化には PostgreSQL […]

【Python】エラーと例外処理の実践的なヒント

Article by: Abdul D 本ブログの内容 Python におけるエラーと例外 − その違いとは Python におけるエラー Pythonにおける例外なぜ Python において例外・エラー処理が重要なのか Sentry は Python アプリのエラー監視にどのように役立つのか Python のコードで、原因か分からないエラーメッセージに遭遇したことはありませんか？それはあなただけではありません。経験豊富な開発者でさえ例外に直面するため、効果的に対処する方法を理解することが重要です。基本的な構文エラーはコードエディタやデバッグツールによって早期に検出できますが、より複雑な問題は実行時に発生することが多く、体系的な例外処理のアプローチが求められます。経験の有無にかかわらず、すべての Python 開発者が例外処理を習得することで恩恵を受けられます。本ガイドでは、エラーと例外の違いを理解し、一般的な例外の種類を確認したうえで、Python アプリケーションにおける適切な対処方法を学びます。また、Sentry を使ってリアルタイムで例外を監視・追跡する方法についても解説し、アプリケーションのパフォーマンスと安定性に関する詳細なインサイトを得る手段を紹介します。 Sentry トレーシング Python におけるエラーと例外 − その違いとは完璧なコードを書くことは非現実的な期待であり、すべての開発者はコーディングミスによる予期しない動作に直面するものです。これらの問題は一般的にエラーと例外の2つに分類されます。エラーはプログラムの実行を完全に妨げる根本的なコーディングミスです。エラーは通常コンパイル時に検出され、修正されるまでコードは実行されません。例外はエラーの一種であり、プログラムの実行中（ランタイム）に予期しない状況、例えばゼロ除算のような場合に発生します。 result = 10 / 0 # Raises ZeroDivisionError エラーとは異なり、例外はコード内で捕捉して処理することができます。エラー処理 vs デバッグ […]

JavaScript にも Debug ID が必要

Article by: Abhijeet Prasad 数か月前、Sentry は Debug ID 用の新しい NPM 組織（名前空間）を作成し、その配下に複数のパッケージを公開しました。https://www.npmjs.com/org/debugids これは、JavaScript Debug ID がエコシステム全体で正式に認知されるための大きな一歩です。同時に、Sentry がオープンスタンダードを牽引し、合意形成に取り組む成熟度を示しています。 ———————————————————————————– 💡 要点まとめ Debug ID は JavaScript ファイルとそのソースマップを結びつける決定論的かつグローバルに一意な値です。 Sentry は Debug ID を Sentry 独自の機能にとどまらず、JavaScript エコシステム全体で広く利用される概念にしようとしています。 Debug ID をソースマップ仕様に追加するため、tc39 に公式提案を提出し、ブラウザ API も含めた標準化を推進しています。誰でもツールやアプリに Debug ID 機能を追加できるよう、各種プラグイン・ツール・ポリフィルを公開済みです。また、バンドラーやソースマップツールへの対応を JavaScript コミュニティと協力して進めています。詳しく知りたい方は、ぜひ読み進めてください。 Debug ID とは何か現代のウェブサイト開発者は、JavaScript […]

【ダッシュボードのアップデート】クリック数削減、操作性向上、ウィジェット作成の高速化

Article by: Alexandra Cota 本番環境のメトリクスを確認していると、突然ダッシュボードにエラーのスパイクが表示されます。このとき最初に考えるのは「この状況を調べるために新しいビューをどのように作ろう」ではなく、「どうすればすぐに原因を突き止められるのか」でしょう。実際、先月私たちのエンジニアリングチームの一つがAPIのレスポンスタイムに異常なパターンを発見した際にも、まさに同じ状況が起こりました。彼らはゼロからアドホッククエリを実行するのではなく、以前のインシデント後に作成していたカスタムダッシュボードを活用しました。エラーとトレースデータの傾向を関連付けることで、彼らはすぐに原因を特定しました。それはインデックスの欠落による非効率なクエリ実行でした。迅速に修正を加えた結果、レスポンスタイムはすぐに正常に戻り、何時間も手作業で調査する必要はありませんでした。ダッシュボードは単なる静的なレポートではありません。チームが異常を素早く検知し、シグナル同士の関連性を見つけ、問題の根本原因に素早くたどり着くための動的なツールです。過去数か月の間に、ダッシュボードの構築、管理、操作を改善するためのさまざまなアップデートを行いました。ウィジェットビルダーの刷新から、ダッシュボードの整理・保護方法の新機能まで、設定にかける時間を減らし、本当に重要なことに集中できるようになりました。より直感的なウィジェット作成ウィジェットはダッシュボードの基本要素であり、私たちはウィジェットビルダーを刷新し、ウィジェットの作成・編集をより簡単かつ直感的にし、ワークフローとの統合性も高めました。サイドパネルデザイン：ページ遷移せずにウィジェットの作成・編集が可能です。ライブプレビュー：設定を調整すると即座に反映され、余計なスクロールや固定ヘッダーの操作は不要です。シンプルなレイアウト：視覚的な煩雑さを抑え、必要なステップが一目で分かり、クエリを素早く作成できます。ウィジェットライブラリの改善：ビルダーのスペースを圧迫することなく、ゼロからウィジェットを作るか、プリセットから始めるかを選択可能です。ダッシュボードを意図した通りに維持するリリース当日、チームはクリティカルリリースダッシュボードを注視し、問題が拡大する前に検知しようとしています。エラー、レイテンシ、スループット。必要な情報はすべてそろっているはずです。しかし、状況が悪化し始めたとき、失敗率のチャートが消えていたり、フィルターが変更されていたり、レイテンシのウィジェットがp95ではなくp50を表示していることに気づきます。実は、誰かがダッシュボードを編集していたのです。その結果、問題を素早く把握するどころか、表示を元に戻すために右往左往し、貴重なインシデント対応の時間を無駄にしてしまいます。ダッシュボードは、他チームによる意図しない変更が加えられることなく、自分たちが最も重視するインサイトを正しく反映すべきです。今回の更新により、誰がダッシュボードを編集できるかを制御できるようになりました。これにより、クリティカルリリース用のダッシュボードをロックしたり、自分のチームだけに編集権限を付与したりすることが可能です。新たに追加された「編集アクセス」セレクターにより、適切な制御が可能になり、明確な権限の線引きがチーム間の円滑なコラボレーションを実現します。お気に入り登録とダッシュボード整理チェックアウトフロー、認証フロー、主要APIエンドポイントなど、ダッシュボードの数が増えていくと、目的のダッシュボードを素早く見つけることが重要になります。そこで、ダッシュボードのお気に入り機能を導入しました。重要なダッシュボードをリストの上部にピン留めすることができます。ダッシュボード詳細ページまたはダッシュボード一覧ページで⭐アイコンをクリックするだけで、よく使うダッシュボードがいつでもすぐアクセスできるようになります。さらに、テーブルビューも追加し、ダッシュボードの整理・管理をよりコンパクトに行えるようにしました。以下の2つのビューを切り替えられます。グリッドビュー：カード形式のビジュアルレイアウトテーブルビュー：コンパクトな表形式始め方 Sentry のダッシュボードを使えば、単なる監視にとどまらず、すぐに問題解決へとつなげることができます。トランザクションの失敗が急増しているのを見つけた際、どのデータベースクエリが遅延を引き起こしているのか、どの例外がコード内で発生しているのかを即座に掘り下げることができます。ハイレベルなメトリクスと実装の詳細が直接つながっているため、頻繁に画面を切り替えることなく、問題の特定・診断・修正が可能になります。これらの改善は、モニタリングとデバッグをよりシンプルにするという私たちの継続的な取り組みの一環です。そしてこれは始まりにすぎません。今後数か月間でさらに多くの改善が予定されています。この機能は Business プランと Enterprise プランのすべてのユーザーが利用できます。ぜひダッシュボードで自分だけの画面を作ってみてください。まだ Sentry のアカウントをお持ちでない方もご安心ください。無料トライアルやデモリクエストですぐに始められます。 Original Page: Dashboard updates: Fewer […]

異常検知アラートがオープンベータで利用可能に　より賢いモニタリング・誤検知を削減

Article by: Rachel Wang, Aayush Seth 数週間前、私たちはアーリーアダプター向けに異常検知アラートを導入しました。そして本日（2025/3/25）、異常検知アラートが正式にオープンベータとなり、Trial、Business、Enterpriseプランの全Sentryユーザーが利用可能になったことをお知らせします。異常検知アラートとは？ Sentryでは、特定のメトリクスが予想された閾値から逸脱した際に通知されるメトリクスベースのアラートを設定できます。例えば、エラー率が一定の閾値を超えたときや、主要なアプリケーションパフォーマンス指標が特定の範囲を外れたときにアラートを作成できます。強力ではありますが、メトリクスのアラート閾値を手動で設定するのは複雑な作業になりがちで、しばしばノイズの多いアラートや、最悪の場合は問題の見逃しにつながることもあります。従来、Sentryでメトリクスアラートを設定するには、適切なバランスを見つけるためにかなりの推測と試行錯誤が必要であり、さらにデータについての深い理解も求められていました。アラート詳細ページでユーザーのクエリによって定義されたカスタムメトリクスアラートで発生した異常アラートの例です。チャート上では赤色で表示され、アルゴリズムが異常な挙動を検知するとアラートが発報されます。異常検知アラートは、予想されるパターンを自動的に学習することで、この複雑さを解消し、ユーザーは設定や推測なしでアラートを作成できます。静的な閾値を手動で定義する代わりに、異常検知アラートは過去のデータを利用して予測される傾向を判断します。これにより、誤検知が減り、アプリケーション監視時のシグナルとノイズの比率が改善されます。さらに、静的な閾値は状況の変化によってすぐに古くなったり無意味になったりしますが、異常検知アラートは時間とともに動的に調整され、昼夜や平日・週末といった季節性や、持続的な成長といった長期トレンドも考慮します。これによりビジネスやアプリケーションが変化しても、アラートは常に適切な状態が保たれます。仕組み異常検知アラートは、Matrix Profiling と Prophet Forecasting という2つのアルゴリズムの組み合わせを活用しています。 Matrix Profiling：最新のデータポイントが過去のパターンと比べてどれほど「意外」かを検出します。現在と過去のデータ系列間のユークリッド距離に基づいて異常を評価します。 Prophet Forecasting：季節性や長期的なパターンを考慮しながら期待されるトレンドのモデルを構築し、データポイントが予測範囲から外れたときに逸脱として検出します。ハイブリッド検知：両方のアルゴリズムが異常を検知した場合、または片方が高い確信度で異常を検知した場合に、システムは異常アラートを発報します。この組み合わせたアプローチにより、誤検知（偽陽性）と見逃し（偽陰性）の両方を最小限に抑えます。今すぐ試してみよう異常検知アラートは現在、Trial、Business、Enterpriseプランのすべてのユーザーにオープンベータ版として提供されています。始めるには、左側のナビゲーションバーの Alerts タブに移動し、Create Alert をクリックしてください。次にメトリクスを選択し、検知方法として Anomaly を選び、必要に応じて感度を調整すれば、あとは Sentry が処理してくれます。異常検知アラートの設定方法については、ドキュメントに詳しい情報があります。異常検知アラートのパブリックベータ版公開は、私たちのチームにとって大きな節目であり、今後もこの機能の安定化に取り組んでいきます。皆さんのフィードバックもぜひお聞かせください。ぜひ試して、ご意見をお寄せください！ Original Page: Anomaly Alerts Now in Open Beta: Smarter […]

Archives: Sentry