N+1問題を体系的に発見する
Telescopeを使ったN+1デバッグの実践的な流れを解説します。単に「同じSELECTが繰り返されている」と気づくだけでなく、修正後の確認まで一連のワークフローとして行えます。1
Requestsで遅いリクエストを見つける
/telescope を開き、Requestsタブで実行時間の長いリクエストを特定します。2
Queriesで発行されたSQLを確認する
リクエストの詳細を開くと、そのリクエスト中に実行されたすべてのSQLクエリが表示されます。同じようなSELECT文が繰り返されていたらN+1です。
3
Eager Loadingを追加して修正する
コードに
with() を追加してクエリを再確認します。クエリ数が大幅に減っていれば修正完了です。dd() やログをコードに追加することなく、この一連の流れをブラウザ上で完結できます。
タグを使った特定リクエストの追跡
Telescopeにはタグ機能があります。Telescope::tag() でエントリに任意のタグを付けると、ダッシュボードのフィルターでそのタグのエントリだけを素早く絞り込めます。
特定のユーザーIDや注文IDに関連する処理だけを追跡したいケースで非常に有効です。
/telescope/requests 画面のSearchに user:42 と入力するだけで、ユーザーID=42のリクエストだけを一覧できます。
モデルにタグを自動付与する
TelescopeServiceProvider の tags メソッドで、特定のモデルIDをすべてのエントリに付与できます。
HasTags コントラクトをモデルに実装することで、そのモデルが記録されるとき自動的にタグが付きます。
Dumpウォッチャーの活用
dump() を使うとHTMLレスポンスに出力が混入してしまい、APIのデバッグが難しくなることがあります。TelescopeのDumpウォッチャーを使うと、dump() の出力をブラウザのレスポンスから切り離してダッシュボードに記録できます。
使い方はシンプルです。/telescope の「Dump」タブを開いた状態で dump() を呼び出すだけです。
dd() とは違いアプリの実行を止めないので、連続したリクエストを流しながらデバッグする場合に便利です。
Mailpit連携でメールデバッグを快適にする
MailウォッチャーとローカルSMTPサーバーの Mailpit を組み合わせることで、メール開発のフローが大幅に改善します。イベントとリスナーのデバッグ
イベントドリブンな実装のデバッグはしばしば難しくなります。「イベントは発火しているのか」「どのリスナーが呼ばれているのか」をログを見ながら追うのは面倒です。 TelescopeのEventsウォッチャーを使うと、発行されたイベントとそのリスナーが一覧で確認できます。 リスナーが呼ばれない場合、Eventsタブでイベントのエントリを確認します。- イベントは発行されているがリスナーが表示されない → リスナーが登録されていない(
EventServiceProviderの確認) - イベント自体が発行されていない →
event()の呼び出し箇所の確認
キュージョブのデバッグ
非同期処理のデバッグはログを見るだけでは原因特定が難しいです。TelescopeのJobsウォッチャーは、ジョブのディスパッチから実行結果まで記録します。 失敗したジョブのエントリをクリックすると、スタックトレースと例外メッセージが確認できます。queue:failed テーブルとは別に、Telescopeでも確認できるため、失敗の原因調査が素早く行えます。
HTTPクライアントのデバッグ
外部APIとの通信をデバッグする際、HTTP Client Watcherが役立ちます。Http:: ファサードで行われたリクエストと、そのレスポンスが記録されます。
dd($response->json()) を書かなくてもダッシュボードで確認できます。
まとめ
Laravel Telescope ガイド
インストールとウォッチャー設定の詳細はガイドページを参照してください。
Laravel Nightwatch
本番環境の監視はNightwatchで行います。