OpenTelemetry Collector を使用して Kubernetes メトリック データを収集する

Kubernetes が業界で広く採用されるツールになるにつれて、可観測性ツールの需要は増加し続けています。このため、OpenTelemetry は、Kubernetes ユーザーがクラスターとサービスを監視できるようにするためのさまざまなツールを作成しました。

次に、OpenTelemetry を使用して Kubernetes クラスターを監視し始めます。 Kubernetes クラスター、ノード、ポッド、コンテナのメトリックとログの収集に重点を置き、クラスターが OTLP データを発行するサービスをサポートできるようにします。

Kubernetes は、さまざまな方法で多くの重要なテレメトリを公開します。ワークロードによって生成されたさまざまなオブジェクトとデータのログ、イベント、メトリックが保存されます。このデータを収集するには、OpenTelemetry Collector を使用します。このコレクターは、このすべてのデータを効率的に収集できます。

すべてのデータを収集するには、デーモンセットとして 1 つ、デプロイメントとして 1 つの 2 つのコレクターをインストールする必要があります。 Collector DaemonSet は、ノード、ポッド、コンテナのサービス、ログ、メトリックを収集するために使用され、Deployment はクラスターのメトリックとイベントを収集するために使用されます。

コレクターをインストールするには、コレクターの構成を容易にするためのいくつかの構成オプションが付属する OpenTelemetry Collector Helm チャートを使用します。

まず、OpenTelemetry Helm リポジトリを追加する必要があります。

 $ helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts $ helm repo update

Kubernetes テレメトリを収集する最初のステップは、OpenTelemetry Collector の DaemonSet インスタンスをデプロイして、ノードとそれらのノードで実行されているワークロードに関連するテレメトリを収集することです。 DaemonSet を使用すると、このコレクター インスタンスがすべてのノードにインストールされることが保証されます。各 DaemonSet 内のコレクター インスタンスは、実行されているノードからのみデータを収集します。

これらすべてのコンポーネントの構成は、OpenTelemetry Collector Helm Chat を通じて簡単に行えます。この Chat は、RBAC、マウント、ホスト ポートなどの Kubernetes 関連の詳細もすべて処理します。ただし、デフォルトではこの Chart はどのバックエンドにもデータを送信しないことに注意してください。

インデックスコレクション

まず、インジケーター データを収集するための Prometheus インスタンスを作成します。以下に示すように、Helm Chart を使用して Prometheus をすばやくデプロイします。

 $ helm repo add prometheus-community https://prometheus-community.github.io/helm-charts $ helm repo update

次に、prometheus-values.yaml ファイルを作成して、Prometheus Helm Chart を構成します。

 # prometheus-values.yaml kubeStateMetrics: enabled: false nodeExporter: enabled: false kubelet: enabled: false kubeApiServer: enabled: false kubeControllerManager: enabled: false coreDns: enabled: false kubeDns: enabled: false kubeEtcd: enabled: false kubeScheduler: enabled: false kubeProxy: enabled: false sidecar: datasources: label: grafana_datasource labelValue: "1" dashboards: enabled: true prometheus: prometheusSpec: enableFeatures: - remote-write-receiver prometheusOperator: enabled: true admissionWebhooks: patch: enabled: true image: registry: cnych repository: ingress-nginx-kube-webhook-certgen tag: v20221220-controller-v1.5.1-58-g787ea74b6 grafana: ingress: enabled: true ingressClassName: nginx hosts: - grafana.k8s.local

OpenTelemetry Collector を使用してメトリック データを収集し、それを Prometheus に送信するため、ここではエクスポーターをカスタマイズしないことに注意してください。さらに、コレクターメトリックを Prometheus に送信するには、リモート書き込み機能を有効にする必要があります。通常、Prometheus の起動パラメータで --web.enable-remote-write-receiver を指定するだけで済みます。ただし、Prometheus Operator を介してデプロイするため、Prometheus の CR インスタンス オブジェクトを変更し、remote-write-receiver 機能を有効にする必要があります。また、grafana.k8s.local を介して Grafana にアクセスできるように、Grafana の Ingress も有効にしました。デフォルトのユーザー名は admin、パスワードは prom-operator です。

次に、次のコマンドを使用して、ワンクリックで Prometheus をデプロイします。

 $ helm upgrade --install prometheus prometheus-community/kube-prometheus-stack -f prometheus-values.yaml --namespace kube-otel --create-namespace Release "prometheus" does not exist. Installing it now. NAME: prometheus LAST DEPLOYED: Wed Aug 23 09:42:23 2023 NAMESPACE: kube-otel STATUS: deployed REVISION: 1 NOTES: kube-prometheus-stack has been installed. Check its status by running: kubectl --namespace kube-otel get pods -l "release=prometheus" Visit https://github.com/prometheus-operator/kube-prometheus for instructions on how to create & configure Alertmanager and Prometheus instances using the Operator.

デプロイ後のリソース オブジェクトは次のとおりです。

 $ kubectl get pods -n kube-otel NAME READY STATUS RESTARTS AGE alertmanager-prometheus-kube-prometheus-alertmanager-0 2/2 Running 0 6m3s prometheus-grafana-5d95cbc57f-v2bw8 3/3 Running 0 61s prometheus-kube-prometheus-operator-74fcfc7ff6-2bzfj 1/1 Running 0 6m19s prometheus-prometheus-kube-prometheus-prometheus-0 2/2 Running 0 6m3s $ kubectl get ingress -n kube-otel NAME CLASS HOSTS ADDRESS PORTS AGE prometheus-grafana nginx grafana.k8s.local 10.98.12.94 80 114s

ここで、メトリック データを Prometheus に送信する必要があるため、Otel コレクターでエクスポーターを構成する必要があります。 prometheus または prometheusremotewrite エクスポーターを使用できます。 OpenTelemetry Collector Helm Chart を構成するには、次の otel-collector-ds-values.yaml ファイルを使用します。

 # otel-collector-ds-values.yaml mode: daemonset tolerations: - key: node-role.kubernetes.io/control-plane effect: NoSchedule clusterRole: create: true rules: - apiGroups: - "" resources: - nodes/proxy verbs: - get - watch - apiGroups: - "" resources: - nodes verbs: - list - watch - get presets: hostMetrics: enabled: true kubernetesAttributes: enabled: true kubeletMetrics: enabled: true ports: prom: # 添加一个9090 端口，用于Prometheus 抓取enabled: true containerPort: 9090 servicePort: 9090 protocol: TCP service: # 创建一个Service，后面ServiceMonitor 会用到enabled: true config: receivers: prometheus: config: scrape_configs: - job_name: opentelemetry-collector scrape_interval: 10s static_configs: - targets: - ${env:MY_POD_IP}:8888 exporters: logging: loglevel: debug prometheus: endpoint: "0.0.0.0:9090" metric_expiration: 180m resource_to_telemetry_conversion: enabled: true # prometheusremotewrite: # endpoint: http://prometheus-kube-prometheus-prometheus:9090/api/v1/write # tls: # insecure: true processors: metricstransform: transforms: include: .+ match_type: regexp action: update operations: - action: add_label new_label: k8s.cluster.id new_value: abcd1234 - action: add_label new_label: k8s.cluster.name new_value: youdian-k8s service: pipelines: metrics: exporters: - prometheus processors: - memory_limiter # 内存限制一般放在最前面- metricstransform - k8sattributes - batch # 批量处理器放在最后receivers: - otlp - hostmetrics - kubeletstats - prometheus

上記の構成ファイルを直接使用して、OpenTelemetry Collector DaemonSet をデプロイします。

 $ helm upgrade --install opentelemetry-collector open-telemetry/opentelemetry-collector -f otel-ds-values.yaml --namespace kube-otel --create-namespace $ kubectl get pods -n kube-otel NAME READY STATUS RESTARTS AGE opentelemetry-collector-agent-22rsm 1/1 Running 0 18h opentelemetry-collector-agent-v4nkh 1/1 Running 0 18h opentelemetry-collector-agent-xndlq 1/1 Running 0 18h

インストール後、コマンド kubectl get cm -n kube-otel opentelemetry-collector-agent -oyaml を使用して、現在のコレクターの構成情報を表示できます。

 exporters: logging: loglevel: debug prometheus: endpoint: 0.0.0.0:9090 metric_expiration: 180m resource_to_telemetry_conversion: enabled: true extensions: health_check: {} memory_ballast: size_in_percentage: 40 processors: batch: {} k8sattributes: extract: metadata: - k8s.namespace.name - k8s.deployment.name - k8s.statefulset.name - k8s.daemonset.name - k8s.cronjob.name - k8s.job.name - k8s.node.name - k8s.pod.name - k8s.pod.uid - k8s.pod.start_time filter: node_from_env_var: K8S_NODE_NAME passthrough: false pod_association: - sources: - from: resource_attribute name: k8s.pod.ip - sources: - from: resource_attribute name: k8s.pod.uid - sources: - from: connection memory_limiter: check_interval: 5s limit_percentage: 80 spike_limit_percentage: 25 metricstransform: transforms: action: update include: .+ match_type: regexp operations: - action: add_label new_label: k8s.cluster.id new_value: abcd1234 - action: add_label new_label: k8s.cluster.name new_value: youdian-k8s receivers: hostmetrics: collection_interval: 10s root_path: /hostfs scrapers: cpu: null disk: null filesystem: exclude_fs_types: fs_types: - autofs - binfmt_misc - bpf - cgroup2 - configfs - debugfs - devpts - devtmpfs - fusectl - hugetlbfs - iso9660 - mqueue - nsfs - overlay - proc - procfs - pstore - rpc_pipefs - securityfs - selinuxfs - squashfs - sysfs - tracefs match_type: strict exclude_mount_points: match_type: regexp mount_points: - /dev/* - /proc/* - /sys/* - /run/k3s/containerd/* - /var/lib/docker/* - /var/lib/kubelet/* - /snap/* load: null memory: null network: null kubeletstats: auth_type: serviceAccount collection_interval: 20s endpoint: ${K8S_NODE_NAME}:10250 otlp: protocols: grpc: endpoint: ${env:MY_POD_IP}:4317 http: endpoint: ${env:MY_POD_IP}:4318 prometheus: config: scrape_configs: - job_name: opentelemetry-collector scrape_interval: 10s static_configs: - targets: - ${env:MY_POD_IP}:8888 service: extensions: - health_check - memory_ballast pipelines: metrics: exporters: - prometheus processors: - memory_limiter - metricstransform - k8sattributes - batch receivers: - otlp - hostmetrics - kubeletstats - prometheus telemetry: metrics: address: ${env:MY_POD_IP}:8888 # ...... 省略其他

上記の構成情報は、OpenTelemetry Collector の実際のランタイム構成情報です。ここではメトリックに関連する構成のみを保持します。上記の構成ファイルから、4 つのレシーバーが定義されていることがわかります。

• ホストメトリックスレシーバー
• kubeletstats シンク
• otlp 受信機
• プロメテウスレシーバー

4 つのプロセッサ:

• バッチプロセッサ
• メモリリミッタープロセッサ
• k8attributes プロセッサ
• メトリック変換プロセッサ

輸出業者 2 社:

• ログエクスポート
• プロメテウスエクスポーター

他のコンポーネントを詳しく見てみましょう。

otlp 受信機

otlp シンクは、OTLP 形式でトレース、メトリック、ログを収集するための最適なソリューションです。アプリケーション テレメトリを他の形式で送信している場合は、コレクターにも対応するレシーバーが存在する可能性が高くなります。これについては以前にも詳しく紹介しました。ここでは、それぞれポート 4317 と 4318 でリッスンする 2 つのプロトコル、http と grpc を定義します。構成は次のようになります。

 receivers: otlp: protocols: grpc: endpoint: ${env:MY_POD_IP}:4317 http: endpoint: ${env:MY_POD_IP}:4318

ホストメトリックスレシーバー

hostmetrics シンクは、CPU 使用率、ディスク使用率、メモリ使用率、ネットワーク トラフィックなどのホスト レベルのメトリックを収集するために使用されます。ここでの設定は次のとおりです。

 receivers: hostmetrics: collection_interval: 10s root_path: /hostfs scrapers: cpu: null disk: null filesystem: exclude_fs_types: fs_types: - autofs - binfmt_misc - bpf - cgroup2 - configfs - debugfs - devpts - devtmpfs - fusectl - hugetlbfs - iso9660 - mqueue - nsfs - overlay - proc - procfs - pstore - rpc_pipefs - securityfs - selinuxfs - squashfs - sysfs - tracefs match_type: strict exclude_mount_points: match_type: regexp mount_points: - /dev/* - /proc/* - /sys/* - /run/k3s/containerd/* - /var/lib/docker/* - /var/lib/kubelet/* - /snap/* load: null memory: null network: null

構成では、collection_interval を通じて 10 秒ごとにメトリックが収集され、ルート パス /hostfs を使用してホスト ファイル システムにアクセスするように指定されています。

hostmetrics シンクには、さまざまな種類のメトリックを収集するための複数のスクレーパーが含まれています。たとえば、CPU グラバーは CPU 使用率メト​​リックの収集に使用され、ディスク グラバーはディスク使用率メト​​リックの収集に使用され、メモリ グラバーはメモリ使用率メト​​リックの収集に使用され、ロード グラバーは CPU 負荷メトリックの収集に使用されます。この構成ファイルでは、ファイル システムの使用状況メトリックを収集するファイル システム スクレーパーのみを有効にします。

ファイルシステム クローラー構成では、特定のファイルシステム タイプとマウント ポイントをメトリック収集から除外することを指定します。具体的には、ファイルシステム タイプ autofs、binfmt_misc、bpf、cgroup2 などが除外されます。また、マウント ポイント /dev/*、/proc/*、/sys/*、/run/k3s/containerd/*、/var/lib/docker/*、/var/lib/kubelet/*、/snap/* も除外されます。これらの除外により、関連するファイルシステムの使用状況メトリックのみが収集されます。

kubeletstats シンク

Kubelet Stats Receiver は、kubelet 上の API サーバーからメトリックを取得するために使用されます。通常、CPU 使用率、メモリ使用率、ネットワーク トラフィックなど、Kubernetes ワークロードに関連するメトリックを収集するために使用されます。これらのメトリックを使用して、Kubernetes クラスターとワークロードの健全性とパフォーマンスを監視できます。

Kubelet Stats Receiver は、デフォルトでポート 10250 で公開される安全な Kubelet エンドポイントと、ポート 10255 で公開される読み取り専用 Kubelet エンドポイントをサポートします。 auth_type が none に設定されている場合、読み取り専用エンドポイントが使用されます。 auth_type が次のいずれかの値に設定されている場合、セキュア エンドポイントが使用されます。

• tls は、受信者に認証に TLS を使用するように指示し、ca_file、key_file、および cert_file フィールドを設定する必要があります。
• serviceAccount は、この受信者に、デフォルトの ServiceAccount トークンを使用して kubelet API に認証するように指示します。
• kubeConfig は、シンクに、認証に kubeconfig ファイル (KUBECONFIG 環境変数または ~/.kube/config) を使用し、APIServer プロキシを使用して kubelet API にアクセスするように指示します。
• initial_delay (デフォルト = 1 秒) は、受信機が開始するまで待機する時間を定義します。

さらに、次のパラメータを指定できます。

• collection_interval (デフォルト = 10 秒)、データ収集間隔。
• insecure_skip_verify (デフォルト = false)、証明書の検証をスキップするかどうか。

デフォルトでは、生成されるすべてのメトリックは、kubelet の /stats/summary エンドポイントによって提供されるリソース ラベルに基づいています。シナリオによっては、これでは不十分な場合があります。したがって、他のエンドポイントを利用して追加のメタデータを取得し、それをメトリック リソースの追加タグとして設定することができます。現在サポートされているメタデータは次のとおりです。

• container.id - /pods 経由で公開されるコンテナ状態から取得されたコンテナ ID ラベルを使用してメトリックを強化します。
• k8s.volume.type - /pods 経由で公開される Pod 仕様からボリューム タイプを収集し、ボリューム メトリックのラベルとして使用します。エンドポイントがボリューム タイプ以外の情報を提供する場合、その情報も使用可能なフィールドとボリューム タイプに基づいて同期されます。たとえば、aws.volume.id は awsElasticBlockStore から同期され、gcp.pd.name は gcePersistentDisk から同期されます。

メトリックに container.id ラベルを追加する場合は、extra_metadata_labels フィールドを使用して有効にします。次に例を示します。

 receivers: kubeletstats: collection_interval: 10s auth_type: "serviceAccount" endpoint: "${env:K8S_NODE_NAME}:10250" insecure_skip_verify: true extra_metadata_labels: - container.id

extra_metadata_labels が設定されていない場合、追加のメタデータを取得するための追加の API 呼び出しは行われません。

デフォルトでは、このコレクターはコンテナ、ポッド、ノードからメトリックを収集します。 metric_groups を設定することで、収集するデータ ソースを指定できます。指定できる値にはコンテナ、ポッド、ノード、ボリュームなどがあります。たとえば、レシーバーからノードとポッドのメトリックのみを収集する場合は、次の構成を使用できます。

 receivers: kubeletstats: collection_interval: 10s auth_type: "serviceAccount" endpoint: "${env:K8S_NODE_NAME}:10250" insecure_skip_verify: true metric_groups: - node - pod

Downward API を介して、Kubernetes クラスターに K8S_NODE_NAME 環境変数を挿入できます。

プロメテウスレシーバー

Prometheus シンクは、Prometheus 形式でメトリック データを受信します。このシンクは、可能な限り Prometheus の代替品となることを目的としていますが、現在、次の高度な Prometheus 機能はサポートされていません。

• アラートマネージャ
• アラート構成.再ラベル構成
• リモート読み取り
• リモート書き込み
• ルールファイル

このシンクは、Prometheus によるサービスのスクレイピングに代わるドロップイン代替品です。サービス検出を含む、scrape_config 内のすべての Prometheus 構成をサポートします。 Prometheus を起動する前に YAML 構成ファイルに記述するのと同じように、たとえば次のようになります。

 prometheus --config.file=prom.yaml

注意: コレクター構成は環境変数の置換をサポートしているため、Prometheus 構成内の $ 文字は環境変数として解釈されます。 Prometheus 設定で $ 文字を使用する場合は、$$ でエスケープする必要があります。

たとえば、コレクターが Prometheus インジケーター データを受信できるようにするには、次の構成を使用できます。使い方はPrometheusと同じです。 scrape_configs にタスクを追加するだけです:

 receivers: prometheus: config: scrape_configs: - job_name: opentelemetry-collector scrape_interval: 10s static_configs: - targets: - ${env:MY_POD_IP}:8888 - job_name: k8s kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] regex: "true" action: keep metric_relabel_configs: - source_labels: [__name__] regex: "(request_duration_seconds.*|response_duration_seconds.*)" action: keep

ここで追加した opentelemetry-collector タスクは、OpenTelemetry Collector のポートであるポート 8888 のデータをキャプチャすることです。このポートを service.telemetry で定義したので、このレシーバーを介して OpenTelemetry Collector 自体のインジケーター データをキャプチャできます。

バッチプロセッサ

バッチ プロセッサは、トレース、メトリック、またはログを取得し、それらをバッチで処理します。バッチ処理により、データの圧縮率が向上し、データの転送に必要な外部接続の数を減らすことができます。このプロセッサは、サイズベースと時間ベースの両方のバッチ処理をサポートします。

各コレクターにバッチ プロセッサを構成することを強くお勧めします。バッチ プロセッサは、memory_limiter およびその他のサンプリング プロセッサの後のパイプラインで定義する必要があります。これは、データ サンプリングの後にバッチ処理を実行する必要があるためです。

バッチ プロセッサでは次のパラメータを設定できます。

• send_batch_size (デフォルト = 8192): トレース、メトリック、またはログ レコードの数がこの数に達すると、タイムアウトに関係なく、バッチがすぐに送信されます。 send_batch_size はトリガーとして機能し、バッチ サイズには影響しません。パイプライン内の次のコンポーネントに送信されるバッチのサイズに制限を適用する必要がある場合は、send_batch_max_size を構成できます。
• タイムアウト (デフォルト = 200 ミリ秒): バッチ サイズに関係なく、一定の時間が経過すると、バッチはすぐに送信されます。ゼロに設定すると、データは直ちに送信されるため send_batch_size は無視され、send_batch_max_size によってのみ制限されます。
• send_batch_max_size (デフォルト = 0): バッチサイズの上限。 0 はバッチ サイズに上限がないことを意味し、このプロパティにより、大きなバッチが小さな単位に分割されることが保証されます。 send_batch_size 以上である必要があります。
• metadata_keys (デフォルト = 空): 設定すると、このプロセッサは client.Metadata 内の値の異なる組み合わせごとにバッチ インスタンスを作成します。
• metadata_cardinality_limit (デフォルト = 1000): metadata_keys が空でない場合、この設定により、プロセスの有効期間中に処理されるメタデータ キー値の一意の組み合わせの数を制限します。

たとえば、次の構成には、デフォルトのバッチ プロセッサと、カスタム設定の 2 番目のバッチ プロセッサが含まれています。バッチ プロセッサ batch/2 は、最大バッチ サイズを強制するために項目を分割することなく、10 秒間に最大 10,000 個のスパンを、メトリック データ ポイントを、またはログ レコードをバッファリングします。

 processors: batch: batch/2: send_batch_size: 10000 timeout: 10s

次の構成では、人為的な遅延を発生させることなく、最大バッチ サイズ制限として 10,000 スパン、メトリック データ ポイント、またはログ レコードが適用されます。

 processors: batch: send_batch_max_size: 10000 timeout: 0s

メモリリミッタープロセッサ

メモリ制限ハンドラは、コレクターのメモリが不足するのを防ぐために使用されます。コレクターによって処理されるデータの量とタイプは環境に固有であり、コレクターのリソース使用率は構成されたプロセッサにも依存するため、メモリ使用量をチェックすることは重要です。

memory_limiter ハンドラを使用すると、メモリ使用量を定期的にチェックし、定義された制限を超えると、データを拒否し、GC を強制してメモリ消費を削減できます。 memory_limiter はソフト メモリ制限とハード メモリ制限を使用します。ハード制限は常にソフト制限以上になります。

メモリ使用量は時間の経過とともに変化し、ハード制限はプロセス ヒープによって割り当てられるメモリの最大量です。この制限を超えると、メモリ制限操作がトリガーされます。ソフト制限は、メモリ使用量がハード制限を下回り、通常の操作が再開されるしきい値です。

たとえば、ハード制限 limit_mib が 100 MiB に定義され、ソフト制限が 80 MiB の場合、spike_limit_mib は 20 MiB になります。メモリ使用量がハード制限を超えると、プロセッサはデータの受け入れを拒否し、ガベージ コレクションを強制してメモリを解放しようとします。メモリ使用量がソフト制限を超えると、プロセッサはメモリ制限モードに入り、メモリ使用量がソフト制限を下回ると、通常の操作が再開され、データは拒否されなくなり、強制ガベージ コレクションは実行されなくなります。

メモリ制限モードでは、プロセッサによって返されるエラーは非永続的なエラーです。受信側でこのエラーが発生すると、同じデータの送信を再試行します。

各コレクターでバラスト拡張機能と memory_limiter プロセッサを構成することを強くお勧めします。バラスト拡張は、コレクターに割り当てられたメモリの 1/3 ～ 1/2 に設定する必要があります。 memory_limiter プロセッサは、パイプラインで定義される最初のプロセッサ (レシーバーの直後) である必要があります。これは、バックプレッシャーが適切なシンクに送信され、memory_limiter がトリガーされたときにデータ損失の可能性を最小限に抑えられるようにするためです。

メモリ リミッターの主な構成オプションは次のとおりです。

• check_interval (デフォルト = 0 秒): メモリ使用量をチェックする間隔を指定します。たとえば、5 秒に設定すると、メモリ使用量が 5 秒ごとにチェックされることを意味します。
• limit_mib (デフォルト = 0): プロセス ヒープに割り当てられるメモリの最大量 (MiB 単位)。通常、プロセスの合計メモリ使用量は、ハード制限を定義するこの値よりも約 50MiB 高くなります。
• spike_limit_mib (デフォルト = limit_mib の 20%): メモリ使用量測定間で予想される最大スパイク。この値は limit_mib より小さくなければなりません。ソフト制限値は、limit_mib - spike_limit_mib と等しくなります。 spike_limit_mib の推奨値は limit_mib の約 20% です。
• limit_percentage (デフォルト = 0): プロセス ヒープ用に割り当てるメモリの最大合計量。この構成は cgroups を備えた Linux システムでサポートされており、docker などの動的プラットフォームで使用することを目的としています。このオプションは、使用可能なメモリの合計に基づいてメモリ制限を計算するために使用されます。たとえば、合計メモリが 1GiB で 75% に設定すると、750MiB に制限されます。固定メモリ設定 (limit_mib) はパーセンテージ設定よりも優先されます。
• spike_limit_percentage (デフォルト = 0): メモリ使用量測定間で予想される最大スパイク。この値は limit_percentage より小さくなければなりません。このオプションは、使用可能なメモリの合計に基づいて spike_limit_mib を計算するために使用されます。たとえば、合計メモリが 1 GiB の場合、25% に設定するとピークは 250 MiB に制限されます。このオプションは、limit_percentage と一緒にのみ使用されます。

k8sattributes プロセッサ

Kubernetes プロパティ プロセッサを使用すると、K8s メタデータを使用して、トレース、メトリック、およびログ リソース プロパティを自動的に設定できます。 k8sattributes プロセッサが Kubernetes クラスター内の Pod に適用されると、Pod の名前、UID、開始時刻、その他のメタデータなど、Pod のメタデータからいくつかの属性が抽出されます。これらのプロパティはテレメトリ データとともにバックエンドに送信されるため、テレメトリ データを分析およびデバッグするときに、データがどのポッドからのものであるかをよりよく理解できます。

k8sattributes プロセッサでは、pod_association 属性はテレメトリ データを Pod に関連付ける方法を定義します。たとえば、Pod が複数のテレメトリ データを送信する場合、これらのテレメトリ データは同じ Pod に関連付けられるため、その後の分析やデバッグ中にどの Pod からのテレメトリ データであるかをより適切に把握できます。

たとえば、ここで定義するプロセッサは次のとおりです。

 k8sattributes: extract: metadata: # 列出要从k8s中提取的元数据属性- k8s.namespace.name - k8s.deployment.name - k8s.statefulset.name - k8s.daemonset.name - k8s.cronjob.name - k8s.job.name - k8s.node.name - k8s.pod.name - k8s.pod.uid - k8s.pod.start_time filter: # 只有来自与该值匹配的节点的数据将被考虑。 node_from_env_var: K8S_NODE_NAME passthrough: false # 表示处理器不会传递任何不符合过滤条件的数据。 pod_association: - sources: - from: resource_attribute # from 表示规则类型name: k8s.pod.ip - sources: - from: resource_attribute # resource_attribute 表示从接收到的资源的属性列表中查找的属性名称name: k8s.pod.uid - sources: - from: connection

抽出オプションには、Kubernetes から抽出されるメタデータ属性がリストされます。この場合、これには Namespace、Deployment、StatefulSet、DaemonSet、CronJob、Job、Node、Pod 名、Pod UID、および Pod 開始時間が含まれます。フィルター プロパティは、名前が K8S_NODE_NAME 環境変数の値と一致するノードのデータのみを考慮するように指定します。パススルー オプションは false に設定されており、これはプロセッサがフィルター基準を満たさないデータをパススルーしないことを意味します。

最後に、pod_association オプションは、Kubernetes から抽出された Pod メタデータをテレメトリ データに関連付ける方法を定義します。この構成ファイルでは、pod_association プロパティによって、k8s.pod.ip、k8s.pod.uid、connection の 3 つの関連付けソースが定義されます。

• 最初の相関ソースは k8s.pod.ip であり、相関のソースとして Pod IP を使用します。つまり、同じ Pod IP から送信されたすべてのテレメトリは同じ Pod に関連付けられます。
• 2 番目の相関ソースは k8s.pod.uid であり、相関ソースとして Pod UID を使用します。つまり、同じ Pod UID から送信されたすべてのテレメトリは同じ Pod に関連付けられます。
• 3 番目の関連付けソースは接続であり、関連付けのソースとして接続情報を使用します。つまり、同じ接続から送信されるすべてのテレメトリは同じ Pod に関連付けられます。

Pod アフィニティ ルールが構成されていない場合、リソースは接続された IP アドレスによってのみメタデータに関連付けられます。

これらの関連付けソースを使用すると、pod_association プロパティによってテレメトリ データが正しい Pod に関連付けられることが保証され、テレメトリ データの分析とデバッグがより便利かつ正確になります。

収集されるメタデータは、追加されるリソース プロパティのリストを定義する定義済みのメタデータ構成によって決定されます。リスト内の項目の名前は、追加されるリソース プロパティとまったく同じです。デフォルトでは次のプロパティが追加されます。

• k8s.名前空間名
• k8s.ポッド名
• k8s.pod.uid
• k8s.pod.開始時間
• k8s.デプロイメント名
• k8s.ノード名

メタデータ構成を使用してこのリストを変更できます。すべての属性を追加できるわけではありません。 pod_association の resource_attribute にはメタデータのプロパティ名のみを使用する必要があります。空の値または存在しない値は無視されます。

さらに、k8sattributesprocessor は、ポッドと名前空間のラベルと注釈を通じてリソース属性を設定することもできます。

メトリック変換プロセッサ

メトリック変換プロセッサを使用すると、メトリックの名前を変更したり、タグ キーと値を追加、名前変更、または削除したりできます。また、タグまたはタグ値全体にわたるメトリックのスケーリングと集計を実行するためにも使用できます。次の表は、1 つ以上のメトリックに適用できるサポートされている操作の完全なリストを示しています。

ここで追加する構成は次のとおりです。

 metricstransform: transforms: action: update include: .+ match_type: regexp operations: - action: add_label new_label: k8s.cluster.id new_value: abcd1234 - action: add_label new_label: k8s.cluster.name new_value: youdian-k8s

つまり、すべてのメトリックにラベル k8s.cluster.id と k8s.cluster.name が追加されます。

ログエクスポート

ログ エクスポータ。データを標準出力にエクスポートするために使用され、主にデバッグ段階で使用されます。

プロメテウスエクスポーター

Prometheus エクスポーターはエンドポイントを指定し、このエンドポイントを介して受信者から受信したインジケーター データをエクスポートできるため、Prometheus はこのエンドポイントからデータを取得するだけで済みます。 prometheusremotewrite エクスポーターは、インジケーター データを指定されたアドレス (Prometheus リモート書き込みプロトコルをサポートするアドレス) に直接リモートで書き込みます。 (テストの結果、リモート書き込みエクスポーターの現在のバージョンには特定の問題があることが判明しました)

ここでの設定は次のとおりです。

 prometheus: endpoint: 0.0.0.0:9090 metric_expiration: 180m resource_to_telemetry_conversion: enabled: true

• エンドポイント: パス /metrics を通じてメトリックが公開されるアドレス。つまり、上記のアドレスを通じてメトリック データにアクセスします。ここでは、ポート 9090 でメトリック データを公開します。
• metric_expiration (デフォルト = 5 分): メトリックが更新されずに公開される期間を定義します。
• resource_to_telemetry_conversion (デフォルトは false): true に有効にすると、すべてのリソース プロパティがデフォルトでメトリック ラベルに変換されます。

最終的には、Prometheus のポート 9090 で OpenTelemetry Collector によって公開されたインジケーター データを収集できます。以下に示すように、ServiceMonitor オブジェクトを作成するだけです。

 apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: otel-prom namespace: kube-otel labels: release: prometheus spec: endpoints: - interval: 10s port: prom # 我们在helm values 中定义了一个prom 的Service 端口path: metrics selector: matchLabels: component: agent-collector app.kubernetes.io/instance: opentelemetry-collector

作成後、OpenTelemetry Collector によって公開されたインジケーター データを Prometheus で見つけることができます。

収集されたインジケーターには、前に定義したプロセッサによって追加された次のような多くのタグが含まれます。

これらのインジケーター データを Grafana 経由でクエリすることもできます。

さらに、OpenTelemetry Collector のデプロイメント モードを展開して、他のインジケーター データを収集することもできます。