本文へ移動
統合ガイド

Sidekiq ジョブ Telemetry

ワーカーの結果を変えず、ジョブの引数をコピーせずに、Sidekiq のジョブブロックの結果と所要時間を記録します。

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

役に立つ
  • Sidekiq 再試行監視
  • ジョブの実行時間
  • バックグラウンドジョブの信頼性
実装の証拠

Sidekiq job telemetry でイベントを送信して確認する

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

  1. 1

    結果を選択してください

    Sidekiq 再試行監視

  2. 2

    契約を定義する

    job_id、job_name、queue_name、attempt、status、duration_ms、release

  3. 3

    結果で発行する

    初期化ファイルでサーバーミドルウェアを登録します。同じ論理 jid は Sidekiq の再試行でも維持されます。最初の試行は 1、retry_count が 0 なら試行 2 です。無効な再試行メタデータは不明のままにします。

  4. 4

    証拠を検証する

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

始める前に

始める前に

  • 書き込み権限を持つサーバー側の TELEMETRY_API_KEY
  • この例を config/initializers/telemetry_sidekiq.rb に置き、各ワーカープロセスで一度読み込みます
  • Sidekiq::ServerMiddleware を備えた Sidekiq 7 以降

配信設定

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

サーバー側キーと明示的なオープンおよび読み取りタイムアウトを備えた小さな Net::HTTP ラッパーを使用します。 ブラウザ バンドル、クライアントに表示される環境変数、ソース管理、ログ、および例外メッセージに取り込み資格情報が含まれないようにします。

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

スニペット

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

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

sidekiq

Sidekiq job telemetryイベント

ruby
# config/initializers/telemetry_sidekiq.rb
require "sidekiq"
require "json"
require "net/http"
require "uri"

module TelemetrySidekiqAttempts
  def self.delivery_failed
    warn "Telemetry job event delivery failed."
  rescue StandardError
    # A broken diagnostic sink must not change the job outcome.
  end

  def self.log(fields)
    key = ENV["TELEMETRY_API_KEY"]
    return if key.nil? || key.empty?

    uri = URI("https://api.telemetry.sh/log")
    request = Net::HTTP::Post.new(uri)
    request["Authorization"] = key
    request["Content-Type"] = "application/json"
    request.body = { table: "job_attempt_completed", data: fields }.to_json
    http = Net::HTTP.new(uri.host, uri.port)
    http.use_ssl = true
    http.open_timeout = 1
    http.read_timeout = 1
    http.write_timeout = 1
    http.max_retries = 0
    response = http.start { |client| client.request(request) }
    delivery_failed unless response.is_a?(Net::HTTPSuccess)
  rescue StandardError
    delivery_failed
  end
end

class TelemetryOutcomeMiddleware
  include Sidekiq::ServerMiddleware

  def call(_job_instance, job, queue)
    started = Process.clock_gettime(Process::CLOCK_MONOTONIC)
    status = "not_returned"
    begin
      result = yield
      status = "returned"
      result
    rescue StandardError
      status = "raised"
      raise
    ensure
      begin
        retry_count = job["retry_count"]
        attempt = if !job.key?("retry_count")
          1
        elsif retry_count.is_a?(Integer) && retry_count >= 0
          retry_count + 2
        end
        TelemetrySidekiqAttempts.log({
          job_id: job["jid"],
          job_name: job["class"],
          queue_name: queue,
          attempt: attempt,
          status: status,
          duration_ms: ((Process.clock_gettime(
            Process::CLOCK_MONOTONIC
          ) - started) * 1000).round(2),
          release: ENV["APP_RELEASE"]
        })
      rescue StandardError
        TelemetrySidekiqAttempts.delivery_failed
      end
    end
  end
end

Sidekiq.configure_server do |config|
  config.server_middleware do |chain|
    chain.add TelemetryOutcomeMiddleware
  end
end

イベントスキーマ

job_id、job_name、queue_name、attempt、status、duration_ms、release

ジョブの引数、結果本文、例外メッセージ、アプリケーションのアカウント情報は含めません

設定を確認する

チェックポイント 1

初期化ファイルでサーバーミドルウェアを登録します。同じ論理 jid は Sidekiq の再試行でも維持されます。最初の試行は 1、retry_count が 0 なら試行 2 です。無効な再試行メタデータは不明のままにします。

チェックポイント 2

ジョブブロックが返ったことは、後続処理の配信完了を証明しません。StandardError は raised と記録し、そのまま再送出します。それ以外の戻らない終了は not_returned のままにします。

チェックポイント 3

この例はキュー待機時間、再試行の上限到達、Active Job 独自の再試行ポリシーを測定しません。それぞれの確認済みライフサイクルフックで記録してください。

チェックポイント 4

所要時間は単調時計を使い、同期送信の時間を除きます。送信中もワーカーを占有するため、処理の遅延は増えます。

チェックポイント 5

通信、非 2xx 応答、エンコード、メタデータ、診断の失敗を閉じ込めます。キーがなければ送信を省略し、ジョブの結果や元の例外を変えません。

チェックポイント 6

接続・読み取り・書き込みのタイムアウトはそれぞれ一秒で、厳密な総時間制限ではありません。送信の再試行、永続キュー、終了時の排出処理はありません。損失が許されない場合はアプリケーションが管理するアウトボックスを使ってください。

検証

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

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

sidekiq-検証

Sidekiq job telemetry 検証クエリ

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

実装の参考資料

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

イベントを記録する場所

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

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

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

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

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

イベントスキーマの例

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

関連製品の機能

このワークフローを続行します アラート

レビューされた信頼性クエリを、所有するしきい値と応答のワークフローにプロモートします。

関連する SQL レシピ

その他のSQL例

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

すべてのレシピを参照する
クエリ例のコレクションバックグラウンドジョブ SQL

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

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

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

さらなる統合