プロンプトとコンテキスト
チームは異なるロギングライブラリやエージェントを使用しており、レベルはTRACEやDEBUGからCRITICALまで多岐にわたります。これらをOpenTelemetryのSeverityNumberおよびSeverityTextにマッピングし、ソース情報を保持し、例外、サンプリング、クエリ、バージョン移行を処理する方法を説明してください。
面接官がテストしていること
- 標準化されたSeverityNumber、ソースのSeverityText、およびログ本文の区別。
- 数値範囲が重要度を表し、同じ名前のレベルであってもシステム間で同一の意味を持つとは限らないことの理解。
- 例外イベント、リソース属性、トレース/スパンの相関、およびコレクターの変換の組み合わせ。
- 未知のレベル、サンプリングバイアス、クエリ互換性、アラートしきい値、およびリプレイ検証への配慮。
尋ねるべき確認の質問
- 各ソースのレベルは何を意味し、どのような数値範囲を使用し、カスタムレベルを定義していますか？
- 元のレベル文字列、ロギングライブラリ、およびバージョンを保持する必要がありますか？ダウンストリームのクエリはどのフィールドを使用しますか？
- 例外は個別のイベントですか、それとも通常の本文テキストですか？また、トレース、スパン、またはリクエストIDにリンクする必要がありますか？
- マッピングによってアラート、サンプリング、ストレージコスト、または保持コンプライアンスが変わりますか？過去のログはどのようにリプレイされますか？
30秒での回答
各ソース用のセマンティックディクショナリを構築し、元のSeverityTextとソースメタデータを保持しながら、意味をOpenTelemetryのSeverityNumber範囲にマッピングします。例外には標準の例外セマンティクスとトレース/スパンの相関を使用し、スタックトレースをレベルフィールドに詰め込むべきではありません。コレクターがレコードの変換と検証を行い、未知のレベルは可観測性のあるフォールバックパスに従います。ロールアウト前に、すべての履歴を暗黙的に再定義するのではなく、代表的なサンプルや障害サンプルをリプレイして、アラートしきい値、サンプリング、クエリ、コストを確認します。
ステップごとの詳細解説
1. 標準フィールドの定義
OpenTelemetry Logs Data Modelは、SeverityNumberとSeverityTextを分離しています。Numberはモデル内での比較をサポートし、Textはプロデューサーの元の名前または表示名を保持します。本文、属性、リソース、タイムスタンプはその他のセマンティクスを保持します。マッピングテーブルには、変換コード内にすべてを隠すのではなく、ソース、元のレベル、ターゲット範囲、および根拠を記録する必要があります。
2. ソースをセマンティック範囲にマッピング
WARN、ERROR、またはFATALは、フレームワークによって異なる運用アクションをトリガーする可能性があります。意味に基づいて範囲にマッピングし、未確認のレベルは未定義または低信頼性として保持し、元の値をSeverityTextまたは制御された属性に配置します。各ソースのドキュメントとサンプルが検証されるまで、システム間で生数値を比較しないでください。
3. 例外と相関の処理
OpenTelemetryの例外セマンティクスでは、例外タイプ、メッセージ、スタックトレースのフィールドを推奨しており、重要度は例外がアプリケーションの障害を引き起こすかどうかに応じて選択されます。クエリが1つのリクエストからのレコードを区別できるように、ログにはtrace ID、span ID、サービス、およびデプロイバージョンを含める必要があります。スタックトレースは診断データであり、他のログと同様の機密データ制御および保持制御が必要です。
4. 取り込み、アラート、移行の検証
Collectorまたはエッジエージェントでマッピング、フィールド検証、および互換性変換を実行し、無効な値と破棄理由を記録します。過去のサンプルと模擬障害をリプレイして、アラートしきい値、サンプリング、クエリ結果、およびストレージコストを検証します。アップグレード中は、マッピングバージョンとソースフィールドを保持して、アラートの意味を暗黙的に変更するのではなく、コンシューマーがバージョンごとに履歴を解釈できるようにします。
模範回答
Java、Python、Nginx、およびその他のソース向けに文書化されたセマンティックマッピングを作成し、元の名前をSeverityTextと制御された属性に保持しながら、OpenTelemetryのSeverityNumberをターゲットにします。数値は同じモデル内でのみ比較され、未知またはカスタムのレベルはアラート付きの低信頼性パスに従います。例外はOpenTelemetryの例外フィールドを使用し、トレース/スパンおよびサービスバージョンにリンクします。Collectorが変換、検証、およびメトリクスを処理します。過去のサンプルと障害サンプルをリプレイして、アラート、サンプリング、クエリ、コストをテストします。監査可能性のために、マッピングバージョンとソースフィールドは利用可能なまま維持されます。
よくある間違い
- セマンティクスを確認せずに、各ソースのERROR、WARN、またはFATALを1対1でマッピングする。
- SeverityNumberのみを保持し、元のレベルとソースバージョンを破棄する。
- 例外データを本文に含め、スタックトレースのクエリを困難にしたり、安全な保持を損なったりする。
- トレース/スパンの相関を省略し、リクエストレベルのコンテキストを失う。
- 失敗したマッピングを暗黙的に破棄するか、メトリクスやアラートなしで強制的にINFOにする。
- バージョンやリプレイ記録なしに、マッピング変更後に過去のアラートを再計算する。
フォローアップの質問と回答
未知のレベルにはどの数値を使用すべきですか？
強制的にERRORにするのではなく、元のテキストを保持し、未知または低信頼性としてマークします。ビジネス上の順序付けが必要な場合は、文書化されたデフォルト範囲を定義し、マッピングバージョンを記録し、未知の割合を監視して、ソースのセマンティクスを修正します。
サンプリングによって重要度の分布が変わることはありますか？
はい。重大なレコードと例外イベントを優先し、サンプリング決定と入力分母を記録し、サンプリング前後の分布を比較します。そのコンテキストなしに、サンプリングされたカウントを真のエラー率として提示すべきではありません。
古いクエリの互換性をどのように維持しますか？
変換レイヤーでソースフィールドと古いエイリアスを一時的に保持し、バージョン管理されたビューまたはクエリ関数を公開します。移行中は、違いが理解されるまでアラートとレポートをデュアルライトまたはリプレイし、その後に古いフィールドを廃止します。