プロンプトと適用されるコンテキスト
あなたの会社ではJava、Go、JavaScript、PHPのサービスが稼働しています。現在は環境変数と各言語固有のSDK起動フラグに依存しています。プラットフォームチームは、OTEL_CONFIG_FILE で指定されるOpenTelemetry宣言的構成ファイルを導入し、リソース属性、サンプリング、エクスポーター、プロセッサーを段階的に標準化したいと考えています。移行、互換性、検証、ロールバックの計画を設計してください。
2026年3月、OpenTelemetryは宣言的構成のJSONスキーマ、ファイルYAML表現、インメモリモデル、プラグインコンポーネント機構、パース/作成操作、および OTEL_CONFIG_FILE の安定版を発表しましたが、各言語の実装成熟度には依然として差があります。この面接ではYAMLの暗記ではなく、バージョン間の構成ガバナンスが評価されます。
面接官の評価ポイント
- 安定した仕様と、各言語における実装の安定性とを区別できているか。
- スキーマ、SDKバージョン、エクスポーターのエンドポイント、パーミッションに関する互換性マトリクスを定義できるか。
- 従来の環境変数と新しいファイルによって、暗黙的な上書きやエクスポーターの重複が発生するのを防止できるか。
- トレースの欠落、高カーディナリティデータの生成、コストの急増を招くことなく、移行の完全性を証明できるか。
優れた回答は、構成をリンティング、合成テスト、カナリア、比較、迅速なロールバックを備えたバージョニング済みアーティファクトとして扱います。不十分な回答は「すべてをYAMLに記述する」と述べるにとどまります。
回答前の明確化のための質問
- どの言語がターゲットフィールドをサポートし、どの言語が環境変数を維持する必要がありますか？これにより移行バッチが決定されます。
- ファイルはイメージに組み込まれるのか、ボリュームとしてマウントされるのか、実行時にダウンロードされるのか？ソースによって署名、パーミッション、ロールバック速度が変わります。
- アプリケーションコードは既存の環境変数を読み取っていますか？その場合、優先順位と非推奨期間が設定されるまで削除は安全ではありません。
- 移行中の一時的なデュアルライトは許可されますか？コストは増加しますが、比較検証の証拠が得られます。
30秒回答フレームワーク
「各言語の実装ステータスと構成ソースを棚卸しし、バージョニングされた最小スキーマと互換性マトリクスを定義します。ジェネレーターが言語非依存のYAMLをレンダリングし、CIでスキーマ、パーミッション、エンドポイント、カーディナリティを検証します。未サポートの言語は従来の環境変数パスを維持します。業務トラフィックのない合成サービスで検証後、言語とリスクごとにカナリアリリースを実施し、送信・ドロップ・サンプリング数、レイテンシ、コストのメトリクスを比較します。すべてのアーティファクトにバージョンとロールバックポインターを付与します。パースに失敗した場合、ランチャーはテレメトリーなしでサイレントに起動するのではなく、以前のアーティファクトまたは従来のフラグを維持します。」
ステップごとの詳細回答
1. ケイパビリティマトリクスと境界の構築
構成をリソース、サンプリング、レシーバー、プロセッサー、エクスポーター、プラグインコンポーネントに分割します。言語ごとにSDKバージョン、サポート対象フィールド、デフォルト値、環境変数マッピング、未知のフィールドの挙動を記録します。データモデルやパース/作成機構が安定していても、各言語の実装が同等に成熟しているとは限りません。
2. 単一ソースと優先順位の定義
宣言的ファイルを新規サービスのプライマリソースとし、既存サービスは環境変数を維持します。移行期間中は優先順位を明示的に定義します。明示的なファイルフィールドはプラットフォーム生成のデフォルトを上書きし、未サポートのフィールドはサイレントに無視されるのではなく、アダプターによって拒否またはマークされます。監査用に秘匿化された有効構成スナップショットを出力します。
repo template -> rendered config -> schema validation -> signed artifact
| |
env defaults --------------------------> runtime loader各サービスが独自にYAMLを組み立てることは避けます。共通設定はプラットフォームテンプレートが管理し、サービス側はレビュー済みの小規模なオーバーライドのみを宣言できるようにします。
3. アーティファクトとリリースパスの設計
アーティファクトにはバージョン、対象言語、SDK範囲、エクスポーターエンドポイント、シークレット参照、互換性宣言が必要です。CIでスキーマを検証後、最小限のサービスを起動して構成をロードし、エクスポーターへの接続を確立します。本番環境では不変のダイジェストと署名を使用し、ロールバック時は以前に検証済みのダイジェストへ切り替えます。
4. 従来の変数と重複エクスポーターの処理
移行前に環境変数インジェクション、サイドカー、コード内構成を収集します。ファイルと変数が共存する場合はステージングで優先順位をテストし、同一シグナルに対して2つのエクスポーターが存在することを禁止します。従来の変数は非推奨期日とアラートを設定した明示的なフォールバックとして保持します。そうしないと、2つの構成システムが無期限に共存することになります。
5. 合成テレメトリーによるセマンティクス検証
言語ごとに固定のトレース、メトリクス、ログのサンプルを生成します。サービス名、リソース属性、スパン名、サンプリング、バッチサイズ、エクスポーターターゲットを確認します。「プロセスが起動した」だけで完了とせず、Collectorまたはバックエンドで入出力カウント、レイテンシ、拒否理由、高カーディナリティラベルを比較します。
6. バッチでのカナリア展開と停止条件の定義
まずは1つのビジネスクロー、1つの言語、低トラフィックのインスタンスを選択し、旧バージョンのコントロールグループを保持します。パースエラー、テレメトリー欠落、エクスポート失敗、CPU/RSSの増加、バックエンド書き込みコスト、業務p99の悪化が発生した場合は停止します。言語の実装が不完全な場合は、見かけの統一性を無理に求めず、従来のパスを維持してギャップを記録します。
7. ロールバックと長期的なガバナンス
ランチャーは、新しいファイル、従来の変数、明示的なテレメトリー無効化の3つの状態をサポートする必要があります。パース失敗時に「空だが成功」としてSDKが起動してはなりません。署名済みの以前のアーティファクトまたは従来の変数へフォールバックし、アラートを発報します。SDKアップグレードごとにマトリクスを再実行し、環境変数を段階的に廃止します。
高品質な回答例
まず言語とSDKのケイパビリティマトリクスを作成し、安定した宣言的スキーマと実装の成熟度を区別します。プラットフォームはバージョニングされたテンプレートとサービスレベルの小規模なオーバーライドを提供します。レンダリング後、CIでスキーマ、パーミッション、エンドポイント、カーディナリティ、最小限の起動を検証し、署名済みの不変アーティファクトを生成します。移行中は従来の環境変数を明示的なフォールバックとして残し、ファイルと変数の設定によって重複エクスポーターが作成されないよう有効構成を記録します。4言語すべてで固定テレメトリーサンプルを検証後、言語とビジネスリスクに応じてカナリア展開を行います。停止条件にはパース失敗、ドロップ率、エクスポート失敗、リソースオーバーヘッド、コスト悪化が含まれます。ファイルに障害が発生した場合、ランチャーは以前のアーティファクトまたは従来の変数に戻り、決してサイレントに未計測のインスタンスにならないようにします。SDKのアップグレード時にはマトリクスを再評価し、非推奨化を進めます。
よくある間違い
- 間違い → スキーマが安定しているためすべての言語を一括移行する → 仕様が安定していても、各実装で全フィールドが揃っているとは限りません。対策： 言語とSDKのケイパビリティマトリクスを維持する。
- 間違い → 優先順位を決めずにファイルと変数を共存させる → エクスポーターやサンプラーが二重にインスタンス化される可能性があります。対策： 優先順位を宣言し、秘匿化された有効スナップショットを出力する。
- 間違い → プロセスの起動のみを確認する → スパンのドロップ、カーディナリティの爆発、誤ったエンドポイントへの送信が発生する可能性があります。対策： 固定の合成テレメトリーでカウントとコストを比較する。
- 間違い → パース失敗後にサイレントに空の構成を使用する → 障害発生時にオブザーバビリティの盲点が生まれます。対策： 署名済みの以前のアーティファクトまたは従来の変数にフォールバックし、アラートを発報する。
フォローアップ質問と回答
ある言語に必要なエクスポーターフィールドが不足している場合はどうしますか？
無理に統一しないでください。そのサービスは従来の変数パスのまま維持し、フィールドのギャップとリスクを記録した上で、必要に応じて監査済みアダプター経由でのみ移行します。完全なスキーマがサポートされているかのように見せかけるのではなく、部分的な互換性として扱います。
プラットフォームのサンプリングポリシーがチームによって上書きされるのをどう防ぎますか？
オーバーライド可能なフィールドをホワイトリスト化し、レンダリング後にポリシーチェックを実行して、有効なサマリーと変更オーナーを記録します。プラットフォーム側で、高コストなエクスポーター、機密エンドポイント、サンプリング上限を強制する必要があります。
構成のロードには成功したもののバックエンドコストが倍増した場合はどう対処しますか？
言語、バージョン、サンプリング、バッチ処理、リトライ、リソース属性ごとに切り分けます。まずエクスポーターの重複と高カーディナリティラベルを確認します。即座にバックエンドのキャパシティを追加するのではなく、カナリアを一時停止し、アーティファクトをロールバックし、構成を修正した上で、同じ合成ワークロードを再実行します。