Instana におけるデータ取り込みの最適化
現代の可観測性プラクティスにおいて、アプリケーションのパフォーマンスとインフラストラクチャの信頼性を維持するためには、データ取り込みを効率的に管理することが不可欠である。 Instana では、トレース、インフラストラクチャ、エンドユーザー監視、合成監視、ロギング、サーバーレス環境など、様々な監視ソースにわたるデータ取り込みを最適化できます。 この戦略は、計測フィルタリング、センサー設定、ポーリングレートの調整、選択的監視といった実践的な手法を提供し、ノイズの低減、パフォーマンスの向上、可観測性の効率維持を実現します。
トレースから取り込まれたデータを管理する
効率的なトレースデータ管理は、入念な計測設計から始まる。 スパンを選択的に有効化、無効化、またはフィルタリングすることで、チームは取り込み量を削減し、ノイズを最小限に抑え、関連するトレースのみを保持できます。同時に、重要なワークフローに対する可視性を維持します。
以下のトレース取り込み制御機能を利用できます:
エンドポイントを無視する
ノイズやデータ量を削減するため、重要度の低い操作のトレースを抑制します。
属性でスパンをフィルタリングする
URL、メソッド、ステータスコード、ヘッダー、クエリパラメータ、SQL文、エラーメッセージなどの属性に基づいて、スパンを除外します。
スタックトレースの取得を制限する
スタックトレースの詳細度を制御して、ノイズを減らし、パフォーマンスを向上させます。
選択した計測機能を無効にする
監視する必要のない、選択したテクノロジー、ライブラリ、またはプロセスのトレースを削除します。
ホストエージェントモードを変更する
ホストエージェントをインフラストラクチャモードに切り替えると、そのホスト上のすべてのトレーサーが無効になります。
プログラムでトレースを無効にする
ヘッダーなどのアプリケーションロジックを使用して、選択したトレースを
X-INSTANA-S header非表示にします。
トレーサー固有のサポート、バージョン要件、および設定構文については、 「トレーサーの取り込み制御」 を参照してください。
ホストレベルでの監視を軽減したい場合は、 「プロセスの無視」 を参照してください。
インフラから取り込まれたデータを管理する
デフォルトでは、 Instana は自動検出によりすべてのセンサーを有効にしますが、設定ファイルを使用して必要に応じて無効にすることができます。 ほとんどのセンサーは設定可能なポーリングレートをサポートしていますが、 Azure センサーは例外です。 より大型のセンサーはフィルタリング機能もサポートし、監視対象エンティティを制限することで、不要なデータ取り込みの削減に貢献します。 さらに、設定ファイルでポーリング間隔を調整することで、データ収集を微調整し、パフォーマンスを最適化できます。 以下の例は、エージェント設定ファイル内の ibmmq プラグインセクションの設定概要を示しています:
com.instana.plugin.ibmmq:
enabled: true
poll_rate: 75
詳細については、 「ポーリングレートの設定」 を参照してください。
高データ取り込みに貢献するセンサー
以下の表は、特定の種類のセンサーで摂取量が高くなる理由を説明しています:
| センサー・タイプ | 例 | 高摂取の理由 |
|---|---|---|
| メッセージングシステムセンサー | IBM MQ, TibcoEMS | 環境における中心的な役割と多数のエンティティ(キュー、トピックなど)の存在により、膨大なデータを生成する 彼らは監視する。 |
| プラットフォームセンサー | Kubernetes vSphere, PCF | 頻繁な更新と詳細なメトリクスが、大量のデータ取り込みに寄与する。 |
| Prometheus センサー | Prometheus | 設定可能なポーリング間隔により、データ取り込みの調整が可能になります。 詳細については、 「 Kubernetes 環境の設定」を参照してください。 |
特定のセンサーからのデータ取り込み量が多い理由
メッセージングシステムは通常、大量のトランザクションとエンティティを処理するため、必然的に膨大なデータが生成される。 同様に、幅広いエンティティと多様なメトリクスを監視するセンサーは、データ取り込み量の増加に寄与する。 これを緩和するため、一部のセンサーでは設定ファイル内で正規表現の使用をサポートしており、チームが監視対象エンティティをフィルタリングし、その数を制限できるようにしています。
最適化ストラテジー
エンティティ・フィルタリング
設定ファイルで正規表現を使用することで、エンティティのサブセットのみを監視できます。
ポーリングレートの調整
ポーリング間隔の設定が可能なセンサーについては、頻度を調整することでデータ量を削減できます。 ポーリング間隔の設定に関する詳細については、以下の設定セクションを参照してください:
クラウド管理サービス ( AWS, Azure, GCP )
クラウドタグを使用して、監視対象からマネージドサービスインスタンスを選択的に含めたり除外したりできます。 以下の例はクラウドタグの使用方法を示しています:
com.instana.plugin.aws.rds: include_tags: # Comma separated list of tags in key:value format (For example, env:prod,env:staging)com.instana.plugin.aws.rds: exclude_tags: # Comma separated list of tags in key:value format (For example, env:dev,env:test)選択的監視
Instana どのプロセスやコンテナを監視するかを制御するための、オプトインおよびオプトアウトの仕組みをサポートしています。 デフォルトでは、エージェントはオプトアウトモードで動作します。 が
INSTANA_SELECTIVE_MONITORING設定されていないか、OPT_OUTに設定されている場合、エージェントは明示的に除外しない限り、すべてのプロセスを監視します。- プロセスおよびコンテナレベルの制御
設定を使用して、特定のプロセスやコンテナを監視対象に含めるか除外することができます。 詳細については、 「 Instana の選択的監視」 を参照してください。
モニター・モード 説明 エージェント環境 プロセス環境 結果 オプトアウト デフォルトで監視されるすべてのプロセス 未設定、または INSTANA_SELECTIVE_MONITORING=OPT_OUT設定なし プロセスは監視される オプトアウト デフォルトで監視されるすべてのプロセス 未設定、または INSTANA_SELECTIVE_MONITORING=OPT_OUTINSTANA_MONITORING=falseそのプロセスは無視される オプトイン デフォルトではプロセスは監視されません INSTANA_SELECTIVE_MONITORING=OPT_IN設定なし そのプロセスは無視される オプトイン デフォルトではプロセスは監視されません INSTANA_SELECTIVE_MONITORING=OPT_ININSTANA_MONITORING=trueプロセスは監視される - Kubernetes 名前空間ラベル(名前空間のオプトアウトおよびオプトイン用)
Instana Kubernetes
instana-workload-monitoringネームスペースレベルでラベルを使用してワークロード監視を制御できます。 このラベルは、名前空間が監視対象に含まれるか除外されるかを決定します:instana-workload-monitoring=false→ オプトアウト: ネームスペース内のすべてのワークロードで監視が無効化されます。instana-workload-monitoring=true→ オプトイン: ネームスペース内のワークロードに対して監視が有効化されます。
エンドユーザー監視(EUM)からのデータ取り込みを管理する
ブラウザのタブごとに収集されるデータ量には、あらかじめ定義された制限があります(これらは Instana のデフォルト設定であり、変更することはできません)。 EUMからのデータ取り込みを管理するには、以下のオプション機能の一部を有効化または無効化するかどうかを決定できます:
- カスタムイベント。 たとえば、 User-Timingの API マーカーをカスタムイベントに自動変換する機能を無効にします。
- ビューまたはページの遷移
- ユーザー情報
- 異常終了
合成データからのデータ取り込みを管理する
Instana における合成テストからのデータ取り込みを最小化するには、以下のアプローチを検討してください:
- ブラウザテストでの動画録画を無効化(デフォルト設定)
- スクリーンショットの取得を制限する。スクリーンショットは通常、テストが失敗した場合にのみ撮影されるため
- 間隔サイズ( Instana ではスケジューリング頻度(分単位)として知られる)を増加させることで実行テスト数を減らし、テスト頻度を増加させる
- 合成監視が不要な場合、テスト実行を停止する
ログソースからのデータ取り込みを管理する
Instana ログソースからのデータ取り込みを制御するオプションを提供します:
- OpenTelemetry ログ
ログのボリュームは、ログ記録に寄与する OpenTelemetry ソースの数を制限することで管理できます。 これにより、不要なデータ取り込みを減らし、全体的な効率が向上します。
- トレース・ログ
Instana トレーサーは、サポートされている技術全体でロギング計測機能を無効化する柔軟性を提供します。 以下の設定は、 Java、 Node.js、 Go、 PHP、および Ruby に対してトレーサーレベルで適用されます。
Instana でサーバーレス監視から取り込まれたデータを管理する
Instana 現在、サーバーレス技術に対するサポートは限定的であり、主に AWS Lambda 関数に重点を置いています。 データ取り込みを最適化し、関連コストを効果的に管理するには、以下の戦略を検討できます:
- Lambda関数のバージョンを管理する
デフォルトでは、 Instana は各Lambda関数の直近5バージョンを監視します。 この数を減らすことで監視コストを削減できます。 Instana 最大20バージョンの監視をサポートしますが、通常、バージョン数が少ないほどデータ量とコストが削減されます。 詳細については、 「Lambda バージョンの取得とメトリクスの無効化」 を参照してください。
- ポーリング間隔の調整
Lambdaメトリクスのデフォルトのポーリング間隔は5分(300秒)です。 この間隔を長くするとデータ収集の頻度が減り、これにより取り込みコストの最小化に役立ちます。 詳細については、 「ポーリングレートの変更」 を参照してください。
おわりに
計測機能の完全な制御を求めるユーザー向けに、 Instana はネイティブ計測機能の代わりに OpenTelemetry を使用する柔軟性を提供します。 これにより、監視データの収集と管理をよりカスタマイズ可能にします。 詳細については、 OpenTelemetry をご覧ください。
これらの戦略は、組織が Instana におけるデータ取り込みを最適化し、可観測性に重点を置きながら効率性を向上させるのに役立ちます。 これにより、可観測性データの管理がより効率的で効果的なアプローチへと導かれます。