本文へ移動
Telemetry
統合ガイド

Laravelの構造化ロギングとキュー分析

アプリケーションシークレットやペイロードを公開することなく、Laravel リクエスト、コマンド、キュー、請求結果を型指定されたイベントとして送信します。

レビュー者 Telemetry 製品チーム に . 送信するイベント、除外するデータ、コードの追加方法を確認しました. このページのレビュー担当

API キーを取得するスニペットを表示
役に立つ
  • Laravel API の信頼性
  • キュー監視
  • 請求ワークフロー分析
実装の証拠

Laravel structured logging and queue analytics でイベントを送信して確認する

制御されたアプリケーション境界で Laravel structured logging and queue analytics を使用し、イベント コントラクトを小さく保ち、集約ビューを構築する前に既知の結果を検証します。

  1. 1

    結果を選択してください

    Laravel API の信頼性

  2. 2

    契約を定義する

    route_name または job_name、ステータス、および duration_ms

  3. 3

    結果で発行する

    生の URL ではなくルート名を使用し、リクエスト入力を大量に送信しないでください。

  4. 4

    証拠を検証する

    Exercise a known fixture, then inspect job_completed for one correctly typed terminal row.

始める前に

始める前に

  • サーバー側 TELEMETRY_API_KEY
  • Laravel HTTP クライアントのタイムアウトが設定されました
  • 名前付きルートとキュージョブ

配信設定

サーバー側のインストールと初期化

Laravel の共有 HTTP クライアントまたは PHP cURL をサーバー側のキーと明示的な接続およびリクエストのタイムアウトとともに使用します。 ブラウザ バンドル、クライアントに表示される環境変数、ソース管理、ログ、および例外メッセージに取り込み資格情報が含まれないようにします。

  1. 1制限されたネットワーク動作を持つ再利用可能なサーバー側配信クライアントを 1 つ準備します。
  2. 2成功、失敗、再試行、またはタイムアウトの境界に結果イベントを追加します。
  3. 3アラートを有効にする前に、制御されたフィクスチャを送信し、保存されている行を検査します。

スニペット

1 つの構造化されたイベントから始める

ワークフローが完了、失敗、または再試行される場所にこの図形を追加します。次に、実際のフィールドからダッシュボードを構築します。

laravel

Laravel structured logging and queue analyticsイベント

php
use Illuminate\Support\Facades\Http;

// Existing job work has completed; $job and numeric $durationMs come from your worker.
try {
    $response = Http::withHeaders([
        'Authorization' => config('services.telemetry.key'),
    ])
        ->connectTimeout(1)
        ->timeout(2)
        ->post('https://api.telemetry.sh/log', [
            'table' => 'job_completed',
            'data' => [
                'job_name' => get_class($job),
                'queue_name' => $job->queue,
                'status' => 'success',
                'attempt' => $job->attempts(),
                'duration_ms' => $durationMs,
                'release' => config('app.release'),
            ],
        ]);

    if (!$response->successful()) {
        error_log('Telemetry delivery failed (non-2xx response).');
    }
} catch (\Throwable $error) {
    error_log('Telemetry delivery failed (transport or configuration error).');
}
// Continue with the original job result; do not retry the job because this send failed.

イベントスキーマ

route_name または job_name、ステータス、および duration_ms

試行、queue_name、error_type、およびリリース

request_id と安全なアカウント識別子

設定を確認する

チェックポイント 1

生の URL ではなくルート名を使用し、リクエスト入力を大量に送信しないでください。

チェックポイント 2

再試行後も保持される論理ジョブ ID を使用して、キューの試行を記録します。

チェックポイント 3

完了したアプリケーション応答を置き換えることなく、テレメトリ配信の失敗を捕捉します。

チェックポイント 4

この例はキュージョブの試行が成功した後に実行します。元のジョブ結果とエラー処理を保持してください。試行イベントだけでは、後続の配信や論理ジョブの完了を証明できません。

チェックポイント 5

接続とリクエストのタイムアウトを制限し、2xx 以外のレスポンスを確認します。キー、レスポンス本文、例外のテキストを記録せず、配信失敗をローカルで報告してください。この例は再試行せず、配信を保証しません。

検証

イベントが到着したことを証明する

既知の成功例と失敗例を実行した後、これを実行します。最終的なイベント コントラクトがスニペットと異なる場合は、フォールバック テーブル名を置き換えます。

laravel-検証

Laravel structured logging and queue analytics 検証クエリ

sql
SELECT *
FROM job_completed
ORDER BY timestamp_utc DESC
LIMIT 20;
論理結果ごとに 1 つのターミナル行を、予想されるステータス、識別子、単位、および UTC 時刻とともに確認します。
推論されたスキーマを検査し、再試行によってフィールド タイプが変更されたり、新しい論理イベント ID が生成されたりしないことを確認します。
保存されたフィールドで認証情報、生のペイロード、プロンプト、プライベート コンテンツ、および無制限のエラー メッセージを検索します。
ダッシュボードを完了として扱う前に、プロバイダーのタイムアウト、取り込みの拒否、およびプロセスのシャットダウンを実行します。

実装の参考資料

新しい運用パスを有効にする前に、イベント契約、データ安全性に関するガイダンス、上流の主要ドキュメントを確認してください。

PHP HTTP ガイドデータ型と null 値許容性Laravel HTTP クライアントLaravelのロギングLaravelキュー

イベントを記録する場所

結果イベントを小さく、回復可能なものに保つ

このパターンが提供するのは、

  • 上流のワークフローの横にある、制限付きの SQL 対応の結果。
  • ダッシュボード、アラート、およびイベント間の相関関係の安定したフィールド。
  • 成功、失敗、再試行、タイムアウトの動作を検証するためのフィクスチャ駆動のパス。

このパターンでは提供されません

  • OTLP エクスポーター、自動収集パイプライン、または詳細なトレースと診断ログの代替。
  • ペイロードにイベント ID が含まれているという理由だけで、1 回だけ配信されます。
  • 生のプロバイダー ペイロード、ユーザー コンテンツ、資格情報、または規制されたデータを収集する許可。
配信と冪等性バッチ処理とシャットダウン取り込みのトラブルシューティング

イベントスキーマの例

このワークフローのイベントスキーマ

クエリまたはスニペットを運用環境に適用する前に、行粒度、出力境界、必要なタイプ、プライバシー クラス、サンプル ペイロード、および検証チェックリストを確認してください。

収益業務9 フィールド

invoice_payment_completed

端末支払いの試行は 1 回。

スキーマを見る

関連製品の機能

このワークフローを続行します ダッシュボード

検証された製品または収益のクエリを、焦点を絞った意思決定の表面に変えます。

探索 ダッシュボードお客様の事例を読む

関連する SQL レシピ

その他のSQL例

このワークフローの構造化フィールドに対してクエリを実行し、結果の例を検査して、有用な回答をダッシュボードまたはアラートに変換します。

すべてのレシピを参照する
API の信頼性初心者

ルート別のAPIエラー率の計算

リクエストが 20 件以上ある API ルートのうち、5xx エラー率が最も高いのはどれですか？

レシピを開く
バックグラウンドジョブ初心者

バックグラウンドジョブの再試行と失敗率を測定する

どのバックグラウンド ジョブが再試行を最も多く消費するか、または依然として失敗するのはどれですか?

レシピを開く
収益と請求中級者

支払い失敗時の回復を測定する

どの支払い失敗が回復し、どのくらいの収益が依然としてリスクにさらされているのでしょうか?

レシピを開く
クエリ例のコレクションAPI の信頼性 SQLバックグラウンドジョブ SQL収益と請求 SQL

実装ファミリーごとに参照する

関連する統合パターンを比較する

アプリケーション フレームワーク Telemetry の統合

この統合と組み合わせるテンプレート

バックグラウンドジョブ失敗モニター

最初の実行から再試行と失敗に至るまで、キュー、cron、インポート、請求同期、および Webhook ジョブの健全性をキャプチャします。

テンプレートを開く

API エラーと遅延モニター

リクエストの量、ステータス コード、ルートの遅延、障害が発生したエンドポイント、および顧客に影響を与える API インシデントを監視します。

テンプレートを開く

さらなる統合

Rails の Ruby 構造化イベント分析

アプリケーションの結果を変えずに、Telemetry HTTP API で Rails コントローラーのリクエスト観測値を記録します。

オープンガイド

Azure 関数 Telemetry

Azure Functions HTTP、タイマー、キュー、呼び出し、再試行、待機時間、リリース、顧客への影響のコンテキストを含むイベント トリガーの結果を追跡します。

オープンガイド

Django と Celery の構造化イベント監視

Celery タスクの各試行の状態を記録し、再試行を最終的な失敗と混同せず、タスクの結果を変更しません。

オープンガイド