Sentry ハックウィークの舞台裏 壊すための口実
Article by: Hector Dearman, Nico Hinderling, Nelson Osacky Sentry ハックウィーク（社内開発週間）では、多くの「Sentaurs（Sentryのメンバー）」が、今後何年にもわたって価値をもたらす Sentry サービスの有用な拡張機能の構築にこの機会を活用しました。 しかし、私たちは違いました。 私たちは、混乱を引き起こし、クラッシュを誘発し、バグをあぶり出す機会として、初めて参加する Sentry ハックウィーク を利用しました。もっともらしさを最大化するために、プロジェクトの説明は「SaaS アプリケーション向けの LLM 主導型 Web ファジング」とし、愛称は「Gremlins（グレムリン）🧌」と名づけました。 Gremlins は、予測不能なユーザー操作を実行することでバグを発見するよう設計された、AI 駆動のファジングエージェントです。従来型のファジングが苦戦するのは、現代のアプリケーションがフロントエンド、バックエンド、データベース、補助的なサービスなど複数のコンポーネントにまたがっているためです。入力は単一のデータバッファではなく、ユーザー操作のシーケンスになっています。 Gremlins はこれを、Web エージェントを通じて意図的に混沌を作り出し、Sentry の SDK を活用してエラーを検出し、プロファイリング／トレーシングデータを収集し、セッションリプレイを取得して、何が明らかになったかを確認することで解決します。 グレムリンが見つけられるものは、実際のユーザーも同様に遭遇し得ます。 Gremlin ワークフロー 大まかには、Gremlins はシンプルな手順に従います。 ユーザーが対象サイトを設定し、必要に応じてエージェント設定を追加する エージェント（群）をサイトに放つ Gremlins があぶり出したエラーを Sentry が捕捉する 設定は軽量で、ユーザーは次の項目を指定できます。 対象サイト 任意のテスト指示（例：「設定ページを壊してみて」） 認証情報 Gremlins の数 など […]
エラーメッセージを（偶然）営業マシンに変えてしまった
Article by: Dan Mindru Dan Mindru はフロントエンド開発者／デザイナーであり、Morning Maker Show の共同ホストでもあります。現在、PageUI、Clobbr、CronTool など複数のアプリケーションを開発中です。 毎日のように多くの AI スタートアップが生まれているのは、実に驚くべきことだと感じています。 私たちソフトウェアエンジニアの多くは、自らのソフトウェアが実際に何をしているのかを知りたがります。計画を立て、レビューを行い、自動テストを実施して、想定どおりに動作しているかを検証します。さらに念のため、手動テストも一巡行います。ただし、AIは例外です。 何か月も何か月もテストを重ねた末、私は落ち着かない状況に置かれることになりました。私のプロダクトは概ね正常に動作していたものの、タスクの遂行に完全に失敗することがあったのです。 実際、約90％の確率では正しく動作しました。しかし、成功率を0％から80％に到達するまでに1か月、80％から90％、あでは 3か月、そして90％から100％にするには、少なくとも12か月はかかりそうに思えました。 現在のスピード感では、「AIの時間」における12か月は、通常の時間でいうところのほぼ1世紀に相当します。ですから、毎日のように新たなスタートアップが登場する理由がすぐに理解できたのです。 結局のところ、皆すぐにローンチするのです 🤷♂️ その後、私たちは12,000人のユーザーを獲得しました。ここから、それがどのように私に有利に働いたのかを説明していきます。あわせて、最大の問題が何だったのかについてもお話ししますが、おそらく想像もつかないはずです。 どのように始まったのか 私はウェブサイト制作を変革するスタートアップを立ち上げたいと考えました。PageAI は、シンプルな説明文から本番運用レベルの Web サイトを、計画・デザイン・コーディングまで行うことができるビルダーです。聞こえは非常に壮大ですが、エラーもそれに匹敵するほど壮大でした。 予想どおり、うまくいかないこと（実際に起きたこと）も数多くありました。どのように壊れるか、すべてを把握していたわけではありませんが、少なくとも AI の出力を完全には信用できないことは分かっていました。これはセキュリティだけでなく、デザインやコード品質の観点からも同様です。 そのため、失敗を受け入れた上で、適切に対処できるようにする必要がありました。 ここで直面したのが、古典的な「鶏が先か卵が先か」の問題です。多くの人に使ってもらわない限り、どのような失敗が起こるかは明らかになりません。一方で、自分たちだけでそれを洗い出そうとすれば、資金が尽き、時代遅れのプロダクトをリリースする危険があります（ちなみに PageAI は自己資金で運営していたため、QA のスケールにも厳しい制限がありました）。 そこで、他の多くのスタートアップと同様に、私たちもローンチすることにしました。 とはいえ、私もそこまで奇抜ではありません。ローンチ前に、AI のエラーを囲い込み、可能な限り緩和しようとしました。私たちが実際に行ったことは以下のとおりです。 自前のパーサーを実装し、生成されたコードを解析したうえで「再構築」し、怪しい／危険な出力をすべてスキップ 出力を保護するために、プロンプト、チェック、エージェントフローを強化 クラッシュを防ぐために、フロントエンドで追加の処理とサンドボックス化を実装 ローンチはあらゆる指標でうまくいき、最初の1週間で2,000人のユーザーを獲得しました。 ところが、その後は静まり返っていました。誰からもクレームがないのです。何かがおかしい… 少なくとも10人に1人は問題に直面すると思っていたのに。これが最初の問題でした。 ❌ 問題1：どれほど深刻かが見えていなかった エラーが発生していることは把握できていましたが、ユーザーがわざわざその問題を報告してくれることはほとんどありませんでした。試してみてエラーが出たら、黙って競合サービスに移ってしまう。良くない状況です。 ✅ […]
【Sentry＆エッジデプロイメント】レイテンシの測定と改善方法
Article by: Kyle Tryon 本ブログの内容 レイテンシの特定 なぜエッジコンピューティングが重要なのか エッジで計算するには？ TL;DR Google の研究者たちが 2017 年に行った調査によると、次のような結果が得られました。 ページの読み込み時間が 1 秒から 3 秒になると、ユーザーが離脱する確率は 32% 増加する。 これは8年以上も前の話です。そして正直なところ、それからユーザーの忍耐力が増したとは考えにくいでしょう。 Web Vitals とは、Google が定義した一連のパフォーマンス指標で、ユーザー体験を測定するためのものです。たとえば次のような要素に着目しています。 LCP（Largest Contentful Paint）：主要コンテンツが読み込まれるまでの時間 INP（Interaction to Next Paint）：ページが入力に反応するまでの速さ CLS（Cumulative Layout Shift）：アプリの視覚的な安定性（＝コンテンツが予期せずずれ動くかどうか） わずか 1 秒の遅延でさえ売上の減少や登録機会の損失につながる可能性があるため、あらゆる観点からレイテンシ（遅延）を調査することが重要です。 どれだけ最適化されたアプリケーションであっても、プルリクエスト（PR）だけでは解決できないボトルネックが少なくとも1つは存在します。それが「距離（distance）」です。 レイテンシの特定 見えないものは、直すことができません。 たとえば、あなたのサービスがアメリカ国内の単一サーバー上で稼働している場合、アジアやヨーロッパといったより遠方にいるユーザーは、単純にリクエストの移動距離が長くなるため、読み込み速度が遅くなるのは自然なことです。 ここでは、Sentry を使って地域ごとのレイテンシの影響を測定・可視化するための基本的なセットアップ手順を紹介します。 テスト環境の構築 今回は、フロントエンドアプリとバックエンド API […]
【Laravel】デバッグとログ記録
Article by: Kyle Tryon 本ブログの内容 サンプルプロジェクトのセットアップ Monolog を使った Laravel のログ記録 Laravel をデバッグするために使うべきツール Laravel アプリのパフォーマンス問題をトラブルシュートし修正する 本番環境で Sentry を使って Laravel をデバッグ・ロギングする Laravel をよりスマートにデバッグする ロジックエラー、失敗した HTTP リクエスト、気付かれずに消えるバックグラウンドジョブ。ソフトウェアはあらゆる「楽しい」形で壊れます。強靭なシステムと脆いシステムの違いは、エラーを完全に回避できるかどうかではありません。何が問題だったのかを、いかに素早く、明確に把握し、修正できるかにかかっています。 Laravel はしっかりとした基盤を提供します。構造化ログ、リアルタイムでの内部観察、そして組み込みのパフォーマンス監視。開発やステージング環境では、dd()、Log::debug()、Monolog、Telescope、Debugbar、Xdebug といったツールを使って、内部を覗き込むことができます。しかし、本番環境はまったく別物です。 本番環境でフロントエンドとバックエンド両方のエラー、遅延、そして再現が難しいエッジケースにわたる完全な可視性を確保するために、Sentry は Laravel アプリに統合され、必要な時に必要なコンテキストを、異なるサービスを横断して提供します。 このガイドでは、いくつかの Laravel デバッグツールについて説明します。それぞれが何をするのか、どのような場面で使うべきか、そしてログを掘り返したり環境ごとに何が悪かったのかを推測したりせずに、適切なインサイトを得る方法を解説します。 前提条件 すでにお使いのコンピュータに Laravel 12 がインストールされている場合は、それを使用できます。 ただし、このガイドでは別のアプローチを取り、Docker コンテナ内でサンプルを実行します。Docker を使うことで、この記事内のコードはあらゆるオペレーティングシステム上で実行でき、セキュアなサンドボックス内で個人ファイルから安全に分離され、特定のバージョンの Laravel、Node、PHP をインストールする必要もありません。 また、このガイドでは Git がインストールされていることを前提としていますが、必要であればサンプルリポジトリを手動でダウンロードして解凍することもできます。 サンプルプロジェクトのセットアップ Laravel […]
ダウンタイムの一般的な原因とウェブサイト監視のメリット
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を標準でサポートしています。 […]
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、メモリ、ディスク、ネットワーク帯域などが含まれます。これらすべての指標の値が低いほど、ユーザー体験が向上し、サーバーコストの削減にもつながります。 記録された結果を分析することで、意図よりも高い値の指標を特定し、その原因となっているコード行を見つけます。 […]
【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 […]