Collector の内部メトリクス 🔗

Collectorの内部メトリクスの完全なリストとその用途を参照してください。

内部メトリクスを使用して Collectorインスタンスを監視する 🔗

Collector の内部メトリクスを使用して、Collector の動作を監視し、パフォーマンスの問題を特定できます。

データフローを監視し、データ損失を検出する 🔗

データが正しく流れていることを確認するには、Collectorによって取り込まれたデータに関する情報には otelcol_receiver_accepted_spans、otelcol_receiver_accepted_metric_points、および otelcol_receiver_accepted_logs メトリクスを使用し、エクスポートされたデータに関する情報には otecol_exporter_sent_spans、otelcol_exporter_sent_metric_points、および otelcol_exporter_sent_logs を使用します。

otelcol_processor_dropped_spans、otelcol_processor_dropped_metric_points、otelcol_processor_dropped_logs を使用して、データ損失を検出します。小さな損失は停止と考えるべきではないので、要件に応じて、アラートを出す前に最小限の時間ウィンドウを設定します。

受信失敗の検出 🔗

otelcol_receiver_refused_spans、otelcol_receiver_refused_metric_points、otelcol_receiver_refused_logs の割合が続く場合は、クライアントに返されるエラーが多すぎることを示します。デプロイメントとクライアントの回復力によっては、これはクライアントでのデータ損失を示すかもしれません。

otelcol_exporter_send_failed_spans、otelcol_exporter_send_failed_metric_points、otelcol_exporter_send_failed_logs の割合が続く場合は、Collectorが期待どおりにデータをエクスポートできないことを示しています。再試行が可能なため、必ずしもデータ損失を意味するわけではありませんが、失敗率が高い場合は、ネットワークまたはデータを受信するバックエンドに問題がある可能性があります。

キューの長さの制御 🔗

Collectorの再試行メカニズムとして、キュー再試行メカニズム（ほとんどのエクスポーターで使用可能）を使用します：

キューの容量が十分かどうかを確認するには、再試行キューの容量をバッチ単位で示す otelcol_exporter_queue_capacity と、再試行キューの現在のサイズを示す otelcol_exporter_queue_size を比較します。

otelcol_exporter_enqueue_failed_spans、otelcol_exporter_enqueue_failed_metric_points および otelcol_exporter_enqueue_failed_log_records は、送信キューに追加できなかったスパン / メトリクスポイント / ログレコードの数を示す。キューが一杯の場合は、送信レートを下げるか、コレクターを水平方向にスケールします。

queue-retryメカニズムでは、モニタリング用のロギングもサポートされています。ログをチェックして、「sending_queueがいっぱいなのでデータをドロップしています」のようなメッセージを探してください。