イベントスキーマの設計
イベント スキーマは、データを出力するコードと、それを使用するすべてのクエリ、ダッシュボード、アラート、またはエクスポートとの間の契約です。インストルメンテーションの前に少量の設計を行うことで、数か月にわたるあいまいなデータを防ぐことができます。
結果に名前を付ける
次のような安定した名詞と過去形の結果を使用します。 api_request_completed, job_failed、または subscription_renewed。頻繁に変更される UI の文言は避けてください。 成功と失敗で同じ有用なフィールドを使う場合は、値を制限した status 多くの場合、値は個別のテーブルよりも比較しやすいです。
質問からフィールドを選択してください
計画された質問ごとに、次の操作を特定します。
- フィルターには、環境、機能、ルート、ステータスなどのフィールドが必要です。
- グループには、モデル、リリース、エラー タイプなどの制御されたディメンションが必要です。
- 計算には、明示的な単位を使用した型指定された測定値が必要です。
- 調査には、関連するイベントを結び付ける安全な識別子が必要です。
記録 latency_msではありません latency。数値は数値として、ブール値はブール値として保存します。 UTC タイムスタンプを使用します。好む route_template 生の URL を介して、 error_type 無制限の例外メッセージに対して。
識別子が個人、アカウント、リクエスト、またはジョブを表すかどうかを文書化します。フィールドに機密データが含まれる可能性がある場合は、イベントを作成する前にフィールドを省略するか、変換してください。
変化を計画する
通常、追加的な変更が最も安全です。クエリは新しい null 許容フィールドを許容できます。フィールドの名前を変更したり、フィールドのタイプを変更すると、すべてのコンシューマーが破損する可能性があります。セマンティクスが大幅に変更された場合は、 event_version、移行ウィンドウを処理するクエリを作成し、コンシューマーが移動した後にのみ古い形状を削除します。
検証のために、代表的な成功、失敗、再試行、およびタイムアウトのサンプルを保存します。インストルメンテーションの変更をリリースする前に、重要な SQL を実行してください。スキーマは、実際のブランチによって生成された値が文書化された意味と一致する場合にのみ完成します。
チェックリストを確認する
イベントに明確な所有者、ステータス値の制限されたセット、明示的な単位、安全な識別子、および保持の必要性があるかどうかを尋ねます。少なくとも 1 つの実際のクエリが各フィールドを使用していることを確認します。使用可能なという理由だけで含まれている値を削除します。