跳至主要內容
整合指南

Laravel 結構化記錄和佇列分析

將 Laravel 請求、命令、佇列和計費結果作為型別化事件傳送,而不會暴露應用程式機密或有效負載。

審閱者 Telemetry產品團隊 上 . 我們檢查了要傳送的事件、要排除的資料和程式碼新增方式. 誰負責審查此頁面

有用於
  • 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準備一個具有有限網路行為的可重用伺服器端交付客戶端。
  2. 2在成功、失敗、重試或超時邊界處新增結果事件。
  3. 3在啟用警示之前傳送受控裝置並檢查儲存的行。

片段

從一個結構化事件開始

在工作流程完成、失敗或重試的位置新增此形狀。然後從真實的欄位建置儀表板。

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-verification

Laravel structured logging and queue analytics 驗證查詢

sql
SELECT *
FROM job_completed
ORDER BY timestamp_utc DESC
LIMIT 20;
確認每個邏輯結果的一個終端行,以及預期狀態、識別符號、單位和 UTC 時間。
檢查推斷的架構並驗證重試不會更改欄位型別或生成新的邏輯事件 ID。
在儲存的欄位中搜尋憑據、原始有效負載、提示、私有內容和無限制的錯誤訊息。
在將儀表板視為完整之前,請執行提供程式超時、攝取拒絕和處理程序關閉。

實施參考

在啟用新的生產路徑之前,請檢查事件合約、資料安全指南和上游主要文件。

在哪裡記錄事件

保持結果事件小且可恢復

該模式提供了

  • 除了上游工作流程之外,還有一個有界的、SQL 就緒的結果。
  • 用於儀表板、警示和跨事件關聯的穩定欄位。
  • 用於驗證成功、失敗、重試和超時行為的夾具驅動路徑。

該模式不提供

  • OTLP 匯出器、自動收集管道或詳細追蹤和診斷日誌的替代品。
  • 僅因為有效負載包含事件 ID,所以僅傳送一次。
  • 收集原始提供商有效負載、使用者內容、憑證或受監管資料的權限。

事件結構描述範例

在將查詢或程式碼片段適應生產之前,請檢查行粒度、發出邊界、所需型別、隱私類、範例有效負載和驗證清單。

相關產品功能

繼續此工作流程 儀表板

將經過驗證的產品或收入查詢轉變為集中的決策介面。

相關 SQL 查詢範例

更多 SQL 範例

針對此工作流程中的結構化欄位執行查詢,檢查範例結果,並將有用的答案轉換為儀表板或警示。

瀏覽所有查詢範例

按實施系列瀏覽

比較相關整合模式

與此整合配對的範本

更多整合