Elixir Phoenix Telemetry Integration: 境界から検証された行まで
制御されたアプリケーション境界で Elixir Phoenix Telemetry Integration を使用し、イベント コントラクトを小さく保ち、集約ビューを構築する前に既知の結果を検証します。
- 1
結果を選択してください
フェニックス API の信頼性
- 2
契約を定義する
route_template、メソッド、status_code、ステータス、duration_ms、リリース
- 3
境界を計測する
アプリケーションの起動中に 1 回接続し、端末の Phoenix エンドポイントまたはルーターのディスパッチ停止イベントを処理します。 System.convert_time_unit/3 を使用してネイティブの期間単位を変換します。
- 4
証拠を検証する
Exercise a known fixture, then inspect your_event_table for one correctly typed terminal row.
始める前に
前提条件と境界
- Phoenix エンドポイント テレメトリが有効になり、ハンドラーを 1 回インストールする監視対象アプリケーション プロセス
- 接続タイムアウトと応答タイムアウトが制限されているサーバー側 HTTP クライアント
- リクエストパラメータと接続コンテンツを除外したルートテンプレート、ステータス、および制御されたエラーの分類
配信設定
サーバー側のインストールと初期化
サーバー側キー、制限された HTTP タイムアウト、および明示的な再試行制限を備えた監視対象クライアント プロセスを使用します。 ブラウザ バンドル、クライアントに表示される環境変数、ソース管理、ログ、および例外メッセージに取り込み資格情報が含まれないようにします。
- 1制限されたネットワーク動作を持つ再利用可能なサーバー側配信クライアントを 1 つ準備します。
- 2成功、失敗、再試行、またはタイムアウトの境界に結果イベントを追加します。
- 3アラートを有効にする前に、制御されたフィクスチャを送信し、保存されている行を検査します。
スニペット
1 つの構造化されたイベントから始める
ワークフローが完了、失敗、または再試行される場所にこの図形を追加します。次に、実際のフィールドからダッシュボードを構築します。
Elixir Phoenix Telemetry Integrationイベント
defmodule MyAppWeb.TelemetryOutcome do
def attach do
:telemetry.attach(
"telemetry-phoenix-request-outcome",
[:phoenix, :endpoint, :stop],
&__MODULE__.handle_stop/4,
nil
)
end
def handle_stop(_event, measurements, metadata, _config) do
conn = metadata.conn
event = %{
route_template: conn.private[:phoenix_route] || "unmatched",
method: conn.method,
status_code: conn.status,
status: if(conn.status < 500, do: "success", else: "failed"),
duration_ms:
System.convert_time_unit(measurements.duration, :native, :millisecond),
release: System.get_env("APP_RELEASE", "development")
}
# Supervise this app-owned client and give it bounded HTTP timeouts.
MyApp.TelemetryIngest.enqueue("phoenix_request_completed", event)
end
endイベント契約
route_template、メソッド、status_code、ステータス、duration_ms、リリース
request_id、account_id、環境、node_role、および承認された場合の制御された error_type
conn.params、クエリ文字列、リクエストまたはレスポンスの本文、セッション、認可ヘッダー、スタック トレース、または無制限のメタデータはありません
実装のチェックポイント
チェックポイント 1
アプリケーションの起動中に 1 回接続し、端末の Phoenix エンドポイントまたはルーターのディスパッチ停止イベントを処理します。 System.convert_time_unit/3 を使用してネイティブの期間単位を変換します。
チェックポイント 2
Phoenix および Plug の停止イベントは完全な分散スパンを構成するものではなく、Plug ではエラー後に停止イベントが発行されないケースが文書化されています。その診断境界に対する例外およびトレース ツールを保持します。
チェックポイント 3
監視された制限された配信パスを通じて非同期に転送するため、テレメトリ HTTP 遅延によってユーザー要求が延長されたり、アプリケーション メールボックスが不安定になったりすることがありません。
検証
イベントが到着したことを証明する
既知の成功例と失敗例を実行した後、これを実行します。最終的なイベント コントラクトがスニペットと異なる場合は、フォールバック テーブル名を置き換えます。
Elixir Phoenix Telemetry Integration 検証クエリ
SELECT *
FROM your_event_table
ORDER BY timestamp_utc DESC
LIMIT 20;実装の参考資料
新しい運用パスを有効にする前に、イベント契約、データ安全性に関するガイダンス、上流の主要ドキュメントを確認してください。
生産境界
結果イベントを小さく、回復可能なものに保つ
このパターンが提供するのは、
- 上流のワークフローの横にある、制限付きの SQL 対応の結果。
- ダッシュボード、アラート、およびイベント間の相関関係の安定したフィールド。
- 成功、失敗、再試行、タイムアウトの動作を検証するためのフィクスチャ駆動のパス。
このパターンでは提供されません
- OTLP エクスポーター、自動収集パイプライン、または詳細なトレースと診断ログの代替。
- ペイロードにイベント ID が含まれているという理由だけで、1 回だけ配信されます。
- 生のプロバイダー ペイロード、ユーザー コンテンツ、資格情報、または規制されたデータを収集する許可。
イベントスキーマの開始点
このワークフローのイベント コントラクト
クエリまたはスニペットを運用環境に適用する前に、行粒度、出力境界、必要なタイプ、プライバシー クラス、サンプル ペイロード、および検証チェックリストを確認してください。
関連製品の機能
このワークフローを続行します アラート
レビューされた信頼性クエリを、所有するしきい値と応答のワークフローにプロモートします。
関連する SQL レシピ
SQL で次の質問に答えてください
このワークフローの構造化フィールドに対してクエリを実行し、結果の例を検査して、有用な回答をダッシュボードまたはアラートに変換します。
ルートごとの API リクエスト スループットの計算
1 分あたり最も多くのリクエストを処理している API ルートはどれですか?
レシピを開くルート別のAPIエラー率の計算
意味のある 5xx エラー率が最も高いのは、どの API ルートですか?
レシピを開くp50、p95、p99 API レイテンシの計算
テール レイテンシが最も悪いエンドポイントはどれですか?
レシピを開くルートごとの API タイムアウト率の計算
ユーザーに影響を与えるほど頻繁にタイムアウトになる API ルートはどれですか?
レシピを開く依存関係の比較 p95 レイテンシー
テール レイテンシーと失敗率が最も悪いダウンストリームの依存関係はどれですか?
レシピを開く顧客の影響によるエラーのフィンガープリントのランク付け
最も多くの顧客アカウントに影響を与えるエラー グループはどれですか?
レシピを開く実装ファミリーごとに参照する
関連する統合パターンを比較する
この統合と組み合わせるテンプレート
さらなる統合
Node.js および Express 構造化ログ
安定したルート テンプレート、ステータス コード、リクエスト レイテンシ、および安全な相関フィールドを備えた Express ルート結果を計測します。
オープンガイドPython および FastAPI 構造化ロギング
非同期 Telemetry クライアントと正規化されたルート名を使用して、FastAPI リクエストの結果と待機時間をキャプチャします。
オープンガイドPino 構造化イベント分析
Pino 診断ログを、Node.js リクエスト、ジョブ、および製品の信頼性分析のために、制限された Telemetry 結果イベントと組み合わせます。
オープンガイド