Instana のベストプラクティス OpenTelemetry ログ記録
OpenTelemetry （OTEL） コレクターに一般的なログ取り込みを適用するには、既知の機能と制限事項に基づいた以下のベストプラクティスに従ってください。
アプリケーション・ログ
ログ監視・分析プラットフォームの価値は、取り込まれるログの品質にかかっています。 したがって、ログの構造は、問題の診断におけるログメッセージの有用性に大きく影響する可能性があります。
タイムスタンプ、ログレベル、エラーコード、およびコンテキスト情報について一貫した形式を提供する、明確に定義されたロギングのセマンティクスを使用してください。 このアプローチは、アプリケーションの動作に関するより深い洞察を得るのに役立ち、根本原因の分析を支援します。
標準のロギング機能により、構造化されたロギングを実現できます。 例としては、 Java 用のSimple Logging Facade（ SLF4J ）や API を使用する各種 Java ロギングフレームワーク、およびキーバリュー形式のロギングをサポートする Golang の slog パッケージなどが挙げられます。
必要な情報のみをログに記録し、アプリケーションに何の価値ももたらさない過剰なログの生成は避けるようにしてください。 ログが過剰になると、パフォーマンスへの影響が生じたり、メモリやネットワークへの負荷が増大したり、 Instana によるログデータの不必要な保持や分析を引き起こしたりする可能性があります。
OpenTelemetry コレクターログの収集
属性抽出
OTEL Collectorは、や log.file.name などの基本的なログ関連情報を記録する一般的な log.iostreamログ属性をサポートしています。
ログのコンテキストを充実させるには、 リソース属性とログレコード属性を追加してください。 これらの属性は、次の2つのコンテキストのいずれかに属します：
- リソースログのコンテキスト ：ログに関するメタデータ（例：.
hostname）が含まれます。 - ログレコードのコンテキスト ：各ログエントリ固有のデータ（例：.
log file path）が含まれます。
リソースおよび属性プロセッサを使用して、ハードコードされたフィールドを追加します。 トランスフォーム ・プロセッサを使用して、設定ベースのアプローチにより、変数値を持つ動的属性を設定します。
特定の属性を追加または変更する必要があるかどうか確信が持てない場合は、属性を追加または変更しないでください。 不要な属性を追加すると、OTEL Collector における各ログメッセージの処理時間が長くなる可能性があります。
ログメッセージの相関関係
Instana 十分なコンテキスト情報とログレコードの属性を使用して、ログメッセージとそれを生成したエンティティを関連付け、両者の間に関連性を確立します。 Instana ペイロード内の指定された属性を使用して、ベストエフォート方式でリンクを構築します。 最も直接的な関連付けはプロセスID（PID）を用い、最も間接的な関連付けはホストマシンを用いる。
OTEL Collectorを、OTEL Collectorと同じホスト上で実行されている Instana エージェントにログデータを直接送信するように設定します。 この設定では、 Instana エージェントのホストが、監視対象のアプリケーションが配置されているホストとして自動的に設定されます。これにより、ログとの直接的な関連付けが最小限に抑えられます。
複数のホスト上のOTELコレクターが、同じ Instana エージェントにログを送信するように設定しないでください。 そうすると、ログのホスト情報が正しく割り当てられなくなる可能性があります。 その結果、 Instana はログメッセージを期待どおりに照合することができません。
コンテナとクラスタの相関関係
コンテナ化されたアプリケーション環境では、 K8sattributes プロセッサによって取得される Kubernetes 属性（例： container.id）に対するエンティティリンクが直接サポートされています。 この container.id 属性は、 Instana のネイティブセンサーである[ DockerLog および ContainerD によって監視されているコンテナエンティティとログを照合するために使用されます。 同様に、この k8s.pod.uid 属性は、ログを、 Kubernetes センサー によって登録された対応する Kubernetes ポッドエンティティに関連付けるために使用されます。 コンテナ化されたアプリケーションでは、PIDを取得しても意味がありません。 各コンテナには独自のPIDネームスペースが割り当てられ、そのネームスペース内では、プロセスに1から始まるPIDが割り当てられます。 その結果、コンテナ化された container.id アプリケーションにとって最も直接的な連携手段を提供します。
クラスタ環境に関する詳細については、 「クラスタの監視 」のドキュメントを参照してください。
Instana 以下のコンテナまたはクラスタの相関フィールドをサポートしており、これらを属性として取得できます：
container.idk8s.pod.uidk8s.job.uidk8s.cronjob.uidk8s.node.uidservice.instance.id
AWS のデプロイメントについては、以下の属性を取得できます：
aws.ecs.container.arnfaas.id
ログデータのエクスポート
OTELのログペイロードの例は、 公式のOTELドキュメントで確認できます。そこでは、属性は「 リソース属性 」と「 ログレコード属性」の2つのカテゴリに分類されています。 詳細については、 「属性抽出 」のセクションを参照してください。
この種のペイロードは、および gRPCHTTP エクスポーターを通じて生成されます。 Instana エージェントおよび Instana バックエンド（ OTLP -Acceptor）は、otlphttp および otlp エクスポーターを通じてこれらの入力タイプをサポートしています。 ログを Instana エージェントに直接送信することで、コンテナ、ポッド、ホストなどの発信元エンティティとのログメッセージの相関付けがより容易になります。 詳細については、 「コンテナとクラスタの相関関係 」のセクションを参照してください。
ログペイロードのフィルタリング
アプリケーションログの生成の性質上、アプリケーションはログを通じて、クレジットカード番号や認証情報などの機密性の高い個人識別情報（PII）を意図せず漏洩させてしまう可能性があります。 Instana に送信されるログペイロードに機密情報が含まれないようにするには、 フィルター プロセッサを使用してください。 このプロセッサをOTELロギングパイプライン構成の早い段階で配置することで、破棄されて Instana に到達することのないログメッセージを、他のパイプラインプロセッサが不必要に処理することを防ぐことができます。
ログメッセージのバッチ処理
バッチプロセッサはログメッセージをキューに入れ、 Instana へ一括送信します。 バッチプロセッサを使用することで、データ送信に必要な送信接続数を減らし、ネットワーク負荷を軽減するとともに、送信データの圧縮効率を向上させます。 このプロセッサを、ロギング・プロセッサ・パイプラインの最後に配置してください。 この配置により、ログレコードの内容の処理、フィルタリング、またはサンプリング操作が、バッチペイロードの構築前に実行されることが保証されます。
バッチプロセッサのパフォーマンスは、設定されたバッチサイズによって異なります。 バッチサイズが小さすぎると、送信されるリクエストの数が増え、ネットワークトラフィックが増加します。 一方、バッチサイズが大きすぎると、メモリ負荷が高まり、メモリ不足（OOM）エラーが発生するリスクが高まります。
(例えば 5000) と send_batch_max_size ( send_batch_size 例えば 10000) のように、互いに十分に離れた値を選択してください。 これにより、ログファイルに例外スタックトレースの対応する行が追加される場合、それらがすべて送信される前に同じバッチにまとめられる可能性が高まります。 例外のスタックトレースに含まれるログ行が、異なるバッチに追加された場合（あるいはバッチ処理されずに個別に送信された場合）、Unbounded Analytics では元の順序で表示されない可能性があります。
バッチのサイズ timeout を、通常の条件下でバッチ send_batch_size が指定されたサイズまで拡張できるようにしつつ、データ流入が通常より少ない場合でも、ユースケースに必要な時間枠内にログメッセージが送信されるように設定してください。
プロセッサ構成 batch の詳細については、 OpenTelemetry コレクタを参照してください。
デフォルトのバッチプロセッサの設定は、多くのクライアントサイドのシナリオにおいて問題なく機能します。 ただし、特に高スループットなシナリオにおいては、シナリオごとのメモリおよびネットワーク使用量への影響を考慮するため、設定オプションについて理解しておくことをお勧めします。 また、 exporterhelper プラグインを使用して、エクスポート機能のパフォーマンスを微調整することもできます。
不要なログの記録を削減する
アプリケーションが冗長なログや価値の低いログを生成し、 Instana に送信している場合は、それらのログが Instana に到達する前に、 フィルター プロセッサを使用して削除してください。 ログのカテゴリ全体を完全に削除することも、 probabilisticsampler プロセッサを使用して生成されたログのサンプルを取得することもできます。 この措置により、ネットワークの負荷が軽減され、ノイズを低減することで取り込まれたログの品質が向上し、処理およびストレージのコストを削減できます。
データの圧縮
ログ収集のシナリオに応じて、ペイロードの圧縮を検討してください。 すべてのログ収集シナリオにおいて、圧縮率や圧縮比が大きなメリットをもたらすとは限りません。
OTEL CollectorがCPUボトルネック（ディスク、メモリ、ネットワークは変動要因であるのに対し、CPUが制約要因となっている状態）にあり、かつ高速なネットワーク上で動作している場合は、パフォーマンス向上のためにデータ圧縮を無効にしてください。 そのような場合、圧縮による効果は限定的です。 通信速度が遅いネットワークでは、圧縮機能を有効にして、送信する必要のあるデータ量を減らしてください。 ログのバッチサイズを小さくすることで、圧縮アルゴリズムがパターンを特定する可能性が低くなります。 その結果、バッチ処理のデータ量が多い場合と比べて圧縮率が低下し、CPU使用率が上昇します。これは、圧縮アルゴリズムの負荷は増大するものの、圧縮可能な構造が少なくなってしまうためです。
圧縮率は、データに含まれる情報量やランダム性を示す指標であるログデータエントロピーに依存します。 したがって、「エントロピーが低い」ログほど繰り返しが多く、より高い圧縮率を実現できる。 「エントロピーが高い」ログはパターンが少なく、結果として圧縮率が低くなります。
圧縮オプションの詳細については、使用するデータ転送方法に応じて、 HTTP のペイロード圧縮および gRPC のペイロード圧縮を参照してください。
gzip 圧縮アルゴリズムのみをサポートしています。データ暗号化
本番環境では、常に暗号化を有効にしてください。 OTEL Collectorがローカルの Instana エージェントにデータを送信する場合、 Instana エージェントとバックエンド間の TLS 暗号化通信を有効にするには、 以下の手順に従ってください。