OpenTelemetry Operator を使用して観測可能なデータを SigNoz に送信する

OpenTelemetry Operator は、OpenTelemetry コンポーネントをデプロイおよび管理するための Kubernetes Operator です。これは、Operator パターンを使用して OpenTelemetry 環境の展開、構成、管理を自動化するカスタム Kubernetes コントローラーです。

OpenTelemetry Operator は、Kubernetes 環境での OpenTelemetry Collector や OpenTelemetry Agent などのコンポーネントのデプロイと管理のプロセスを簡素化します。 CRD を通じて OpenTelemetry コンポーネントを集中管理できます。 OpenTelemetry Operator を使用すると、Kubernetes クラスター内で OpenTelemetry コンポーネントのインスタンスを簡単に作成、構成、管理できます。構成ファイルの自動作成と管理、コレクターとエージェントの構成の自動挿入、自動監視とスケーリングなど、多くの便利な機能を提供します。

展開する

ここでは、Helm Chart を使用して OpenTelemetry Operator をデプロイします。まず、Helm Chart リポジトリを追加します。

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

デフォルトでは、OpenTelemetry Operator が正しく構成されていることを確認するために、アドミッション コントローラーがデプロイされます。 APIServer が Webhook コンポーネントと通信するには、Webhook に APIServer によって信頼されるように設定された TLS 証明書が必要です。必要な TLS 証明書を生成/構成するには、いくつかの方法があります。

• 最も簡単な (デフォルトの) 方法は、cert-manager をインストールし、admissionWebhooks.certManager.create を true に設定することです。このようにして、cert-manager は自己署名証明書を生成します。
• admissionWebhooks.certManager.issuerRef 値を設定することで、独自の発行者を提供できます。タイプ (Issuer または ClusterIssuer) と名前を指定する必要があります。この方法では、cert-manager がインストールされている必要があることに注意してください。
• admissionWebhooks.certManager.enabled を false に、admissionWebhooks.autoGenerateCert を true に設定することで、自動的に生成された自己署名証明書を使用できます。 Helm は自己署名証明書と対応するシークレットを作成します。
• admissionWebhooks.certManager.enabled と admissionWebhooks.autoGenerateCert を false に設定することで、独自に生成した自己署名証明書を使用できます。 admissionWebhooks.cert_file、admissionWebhooks.key_file、admissionWebhooks.ca_file に必要な値を指定する必要があります。
• .Values.admissionWebhooks.create と admissionWebhooks.certManager.enabled を無効にすることで、パス経由でカスタム Webhook と証明書をマウントし、 admissionWebhooks.secretName にカスタム証明書シークレット名を設定できます。
• .Values.admissionWebhooks.create を無効にし、環境変数 ENABLE_WEBHOOKS: "false" を設定することで、Webhook を完全に無効にすることができます。

簡単にするために、ここでは 3 番目の方法を選択し、自動的に生成された自己署名証明書を直接使用し、次のコマンドを直接使用して、OpenTelemetry Operator をワンクリックでインストールします。

 $ helm upgrade --install --set admissionWebhooks.certManager.enabled=false --set admissionWebhooks.certManager.autoGenerateCert=true opentelemetry-operator open-telemetry/opentelemetry-operator --namespace kube-otel --create-namespace Release "opentelemetry-operator" does not exist. Installing it now. NAME: opentelemetry-operator LAST DEPLOYED: Tue Sep 5 11:23:29 2023 NAMESPACE: kube-otel STATUS: deployed REVISION: 1 NOTES: opentelemetry-operator has been installed. Check its status by running: kubectl --namespace kube-otel get pods -l "release=opentelemetry-operator" Visit https://github.com/open-telemetry/opentelemetry-operator for instructions on how to create & configure OpenTelemetryCollector and Instrumentation custom resources by using the Operator.

通常のデプロイが完了すると、対応する Pod が正常に実行されていることがわかります。

 $ kubectl get pods -n kube-otel -l app.kubernetes.io/name=opentelemetry-operator NAME READY STATUS RESTARTS AGE opentelemetry-operator-6f77dc895c-924gf 2/2 Running 0 3m30s

さらに、OpenTelemetry 関連の CRD が 2 つ自動的に追加されます。

 $ kubectl get crd |grep opentelemetry instrumentations.opentelemetry.io 2023-09-05T03:23:28Z opentelemetrycollectors.opentelemetry.io 2023-09-05T03:23:28Z

この時点で、OpenTelemetry Operator がデプロイされます。

構成

OpenTelemetry Operator は、CRD を通じて OpenTelemetry コンポーネントを管理できます。利用可能な展開モードは 3 つあります。

• デーモンセット
• サイドカー
• デプロイメント（デフォルトモード）

OpenTelemetryCollector タイプの CustomResource は、コレクターを DaemonSet、Sidecar、または Deployment (デフォルト) として実行するかどうかを指定するために使用できる .Spec.Mode というプロパティを公開します。

展開モード

以下に示すように OpenTelemetryCollector CRD をサブスクライブして、OpenTelemetry Collector をデプロイメント モードでデプロイできます。

 $ kubectl apply -f - <<EOF apiVersion: opentelemetry.io/v1alpha1 kind: OpenTelemetryCollector metadata: name: simplest spec: mode: deployment config: | receivers: otlp: protocols: grpc: http: processors: batch: exporters: logging: service: pipelines: traces: receivers: [otlp] processors: [batch] exporters: [logging] EOF

上記の otelcol の例では、gRPC および HTTP プロトコルを使用して OTLP トレース データを受信し、データをバッチ処理してコンソールに記録します。リソース オブジェクトを適用した後、OpenTelemetry Operator は simplest という名前のデプロイメントを作成します。このデプロイメントは、上記の構成を使用してトレース データを受信、処理、およびエクスポートする OpenTelemetry Collector インスタンスを実行します。

 $ kubectl get opentelemetrycollectors NAME MODE VERSION READY AGE IMAGE MANAGEMENT simplest deployment 0.83.0 1/1 3m22s otel/opentelemetry-collector-contrib:0.83.0 managed $ kubectl get pods NAME READY STATUS RESTARTS AGE simplest-collector-6d9886f5d-shgdb 1/1 Running 0 3m30s $ kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 179d simplest-collector ClusterIP 10.108.169.24 <none> 4317/TCP,4318/TCP 3m43s simplest-collector-headless ClusterIP None <none> 4317/TCP,4318/TCP 3m43s simplest-collector-monitoring ClusterIP 10.103.173.212 <none> 8888/TCP 3m43s

次に、以下の手順に従って Telemetrygen ツールをインストールし、サンプル トレースをこのコレクターに送信してテストします。

 $ go install github.com/open-telemetry/opentelemetry-collector-contrib/cmd/telemetrygen@latest

次に、OTLP サービスの gRPC ポートを転送します。

 $ kubectl port-forward service/simplest-collector 4317

別のターミナルで、次のコマンドを実行して、telemetrygen を使用してトレース データを送信します。

 $ telemetrygen traces --traces 1 --otlp-endpoint localhost:4317 --otlp-insecure

その後、コレクターに対応するログを表示できます。通常、次のログが表示されます。

 $ kubectl logs -l app.kubernetes.io/name=simplest-collector 2023-09-05T06:18:43.299Z info TracesExporter {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 1, "spans": 2}

最後に、otelcol インスタンスを必ずクリーンアップしてください。

 $ kubectl delete otelcol simplest

デーモンセットモード

同様に、OpenTelemetry Collector インスタンスは DaemonSet パターンを使用してデプロイでき、これによりすべてのノード (またはそのサブセット) がコレクター ポッドのコピーを実行することが保証されます。 DaemonSet の場合、Spec.Mode プロパティのみが daemonset に更新されます。前の otelcol YAML の例の構成はそのままにしておくことも、必要に応じて更新することもできます。

DaemonSet は、ログ収集デーモン、ストレージ デーモン、ノード監視デーモンなどのタスクに適しています。このような場合、各ノードからデータを収集するには、各ノードでコレクター インスタンスを実行する必要があります。これは、すでに紹介しました。

サイドカーパターン

OpenTelemetry Collector を備えたサイドカーは、ポッド アノテーション sidecar.opentelemetry.io/inject を true に設定するか、同じ名前空間の具体的な OpenTelemetryCollector の名前を設定することで、ポッドベースのワークロードに挿入できます。

以下は、jaeger を入力として受け取り、出力をコンソールに記録するサイドカーを作成する例です。

 $ kubectl apply -f - <<EOF apiVersion: opentelemetry.io/v1alpha1 kind: OpenTelemetryCollector metadata: name: my-sidecar spec: mode: sidecar config: | receivers: jaeger: protocols: thrift_compact: processors: exporters: logging: service: pipelines: traces: receivers: [jaeger] processors: [] exporters: [logging] EOF

この例では、Jaeger からトレース データを受信して​​コンソールに記録する、my-sidecar という名前の OpenTelemetry Collector サイドカーを作成します。

 $ kubectl get opentelemetrycollectors NAME MODE VERSION READY AGE IMAGE MANAGEMENT my-sidecar sidecar 0.83.0 11s managed

次に、Jaeger サンプルイメージを使用して Pod を作成し、sidecar.opentelemetry.io/inject アノテーションを true に設定します。

 $ kubectl apply -f - <<EOF apiVersion: v1 kind: Pod metadata: name: myapp annotations: sidecar.opentelemetry.io/inject: "true" # 注入otelcol sidecar spec: containers: - name: myapp image: jaegertracing/vertx-create-span:operator-e2e-tests ports: - containerPort: 8080 protocol: TCP EOF

Pod を適用した後、OpenTelemetry Operator は、上記でサイドカーとして定義された my-sidecar コレクターを Pod に挿入します。コンテナーは、上記の構成を使用してトレース データを受信、処理、エクスポートする OpenTelemetry Collector インスタンスを実行します。

 $ kubectl get pods myapp NAME READY STATUS RESTARTS AGE myapp 2/2 Running 0 110s

ここで、myapp ポッドのポート 8080 を転送できます。

 $ kubectl port-forward pod/myapp 8080:8080

次に、別のターミナルで curl を使用して HTTP リクエストを送信します。

 $ curl http://localhost:8080 Hello from Vert.x!

その後、Sidecar コンテナの出力ログを表示できます。通常、トレース ログは次のように表示されます。

 $ kubectl logs pod/myapp -c otc-container # ....... 2023-09-05T06:45:56.648Z info TracesExporter {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 1, "spans": 4} 2023-09-05T06:45:56.648Z info TracesExporter {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 1, "spans": 5} 2023-09-05T06:46:04.638Z info TracesExporter {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 1, "spans": 4} 2023-09-05T06:46:04.638Z info TracesExporter {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 1, "spans": 5}

最後に、Sidecar および myapp ポッドを忘れずにクリーンアップしてください。

 $ kubectl delete otelcol/my-sidecar $ kubectl delete pod/myapp

OpenTelemetry自動追跡インジェクション

OpenTelemetry Collector の管理に加えて、OpenTelemetry Operator は OpenTelemetry 自動トレース ライブラリを挿入して構成することもできます。

埋設ポイントリソース構成

現在、Java、NodeJS、Python、DotNet 言語がサポートされています。次のアノテーションがワークロードまたは名前空間に適用されると、インストルメンテーションが有効になります。

• instruments.opentelemetry.io/inject-java: "true" — Java の場合。
• instruments.opentelemetry.io/inject-nodejs: "true" — NodeJS の場合。
• instruments.opentelemetry.io/inject-python: "true" — Python の場合。
• instruments.opentelemetry.io/inject-dotnet: "true" — DotNet の場合。
• instruments.opentelemetry.io/inject-sdk: "true" - OpenTelemetry SDK 環境変数にのみ適用されます。

注釈に使用できる値は次のとおりです。

• true - 名前空間からリソースを注入して埋め込みます。
• my-instrumentation - 現在の名前空間内の Instrumentation CR インスタンスの名前。
• my-other-namespace/my-instrumentation - 別の名前空間内の Instrumentation CR インスタンスの名前と名前空間。
• false - 挿入しません。

自動インストルメンテーションを使用する前に、SDK とインストルメンテーション構成を使用してインストルメンテーション リソースを構成する必要があります。

インストルメンテーションは次のプロパティで構成されます。

• exporter.endpoint - (オプション) OTLP 形式でテレメトリ データを送信するアドレス。
• プロパゲーター - トランザクションのライフサイクル全体にわたって状態を保存し、データにアクセスするための基盤となるコンテキスト メカニズムをすべてのデータ ソースで共有できるようにします。
• サンプラー - 収集されバックエンドに送信されるトレース サンプルの数を減らすことで発生するノイズとオーバーヘッドを削減するメカニズム。 OpenTelemetry は、StaticSampler と TraceIDRatioBased の 2 つのタイプを提供します。
• 言語プロパティ (java、nodejs、python、dotnet など) - ポッド注釈で設定された言語に基づいて、自動インストルメント化されたカスタム イメージを使用します。

SigNozをインストールする

次に、SigNoz を OTLP 受信機として使用します。 SigNoz は、開発者がアプリケーションを監視し、問題をトラブルシューティングするのに役立つオープンソースの APM です。これは、DataDog、NewRelic などのオープンソースの代替品です。オープンソースのアプリケーション パフォーマンス監視 (APM) および観測可能性ツールです。

SigNoz を使用するには、当然ながら最初にインストールする必要があります。同様に、Helm Chart を使用して SigNoz をデプロイすることもできます。

 $ helm repo add signoz https://charts.signoz.io # 配置一个全局的StorageClass 对象$ helm upgrade --install signoz signoz/signoz --set global.storageClass=cfsauto --namespace kube-otel --create-namespace Release "signoz" does not exist. Installing it now. coalesce.go:175: warning: skipped value for zookeeper.initContainers: Not a table. NAME: signoz LAST DEPLOYED: Tue Sep 5 15:14:34 2023 NAMESPACE: kube-otel STATUS: deployed REVISION: 1 NOTES: 1. You have just deployed SigNoz cluster: - frontend version: '0.28.0' - query-service version: '0.28.0' - alertmanager version: '0.23.3' - otel-collector version: '0.79.6' - otel-collector-metrics version: '0.79.6' 2. Get the application URL by running these commands: export POD_NAME=$(kubectl get pods --namespace kube-otel -l "app.kubernetes.io/name=signoz,app.kubernetes.io/instance=signoz,app.kubernetes.io/compnotallow=frontend" -o jsnotallow="{.items[0].metadata.name}") echo "Visit http://127.0.0.1:3301 to use your application" kubectl --namespace kube-otel port-forward $POD_NAME 3301:3301 If you have any ideas, questions, or any feedback, please share on our Github Discussions: https://github.com/SigNoz/signoz/discussions/713

しばらくすると、対応する Pod が正常に実行されていることがわかります。

 $ kubectl get pods -n kube-otel NAME READY STATUS RESTARTS AGE chi-signoz-clickhouse-cluster-0-0-0 1/1 Running 0 7m17s signoz-alertmanager-0 1/1 Running 0 13m signoz-clickhouse-operator-557bdb6b69-tl6qd 2/2 Running 0 13m signoz-frontend-756fc84cfb-kn6gk 1/1 Running 0 13m signoz-k8s-infra-otel-agent-85bw7 1/1 Running 0 13m signoz-k8s-infra-otel-agent-8l49k 1/1 Running 0 13m signoz-k8s-infra-otel-deployment-86798ddf86-fskll 1/1 Running 0 13m signoz-otel-collector-6675cb6b-mbzkt 1/1 Running 0 13m signoz-otel-collector-metrics-c6b457469-554sj 1/1 Running 0 13m signoz-query-service-0 1/1 Running 0 13m signoz-zookeeper-0 1/1 Running 0 13m $ kubectl get svc -n kube-otel NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE chi-signoz-clickhouse-cluster-0-0 ClusterIP None <none> 9000/TCP,8123/TCP,9009/TCP 11m signoz-alertmanager ClusterIP 10.110.225.12 <none> 9093/TCP 19m signoz-alertmanager-headless ClusterIP None <none> 9093/TCP 19m signoz-clickhouse ClusterIP 10.106.164.155 <none> 8123/TCP,9000/TCP 11m signoz-clickhouse-operator-metrics ClusterIP 10.109.230.187 <none> 8888/TCP 19m signoz-frontend ClusterIP 10.99.154.149 <none> 3301/TCP 19m signoz-k8s-infra-otel-agent ClusterIP 10.104.11.195 <none> 13133/TCP,8888/TCP,4317/TCP,4318/TCP 19m signoz-k8s-infra-otel-deployment ClusterIP 10.96.76.96 <none> 13133/TCP 19m signoz-otel-collector ClusterIP 10.109.84.177 <none> 14250/TCP,14268/TCP,8888/TCP,4317/TCP,4318/TCP 19m signoz-otel-collector-metrics ClusterIP 10.96.121.34 <none> 13133/TCP 19m signoz-query-service ClusterIP 10.105.122.9 <none> 8080/TCP,8085/TCP 19m signoz-zookeeper ClusterIP 10.100.202.59 <none> 2181/TCP,2888/TCP,3888/TCP 19m signoz-zookeeper-headless ClusterIP None <none> 2181/TCP,2888/TCP,3888/TCP 19m

次に、次のメソッドを使用して SigNoz にアクセスできます。

 $ export POD_NAME=$(kubectl get pods --namespace kube-otel -l "app.kubernetes.io/name=signoz,app.kubernetes.io/instance=signoz,app.kubernetes.io/compnotallow=frontend" -o jsnotallow="{.items[0].metadata.name}") $ kubectl --namespace kube-otel port-forward $POD_NAME 3301:3301

その後、http://127.0.0.1:3301 経由で SigNoz にアクセスできます。

初めてアクセスする場合は、管理者アカウントを作成する必要があります。ページの指示に従って作成してください。作成後、SigNoz のメイン インターフェイスに入ることができます。

さらに、SigNozはKubernetesクラスターからログデータも収集し、   Logs  ページビュー:

この時点で、SigNoz がデプロイされています。

OpenTelemetry SDK環境変数を挿入する

inject-sdk を使用すると、現在自動的にインストルメント化されていないアプリケーションで動作するように OpenTelemetry SDK を構成できます。これにより、OTEL_RESOURCE_ATTRIBUTES、OTEL_TRACES_SAMPLER、OTEL_EXPORTER_OTLP_ENDPOINT などの環境変数が挿入されます。これらは Instrumentation で構成できますが、実際には SDK は提供されません。

OTLP シンクを入力と出力として受け取り、テレメトリ データを SigNoz コレクターに送信し、コンソールにログを記録するサイドカーを作成しましょう。

 $ kubectl apply -f - <<EOF apiVersion: opentelemetry.io/v1alpha1 kind: OpenTelemetryCollector metadata: name: my-sidecar spec: mode: sidecar config: | receivers: otlp: protocols: http: grpc: processors: batch: exporters: logging: otlp: endpoint: http://signoz-otel-collector.kube-otel.svc.cluster.local:4317 tls: insecure: true service: pipelines: traces: receivers: [otlp] processors: [batch] exporters: [logging, otlp] metrics: receivers: [otlp] processors: [batch] exporters: [logging, otlp] EOF

ここでは、サイドカー モードでコレクターを再定義します。定義された OTLP エクスポータのエンドポイント アドレスは http://signoz-otel-collector.kube-otel.svc.cluster.local:4317 であり、これは上記でインストールした Signoz コレクターのアドレスであることに注意してください。もちろん、独自の OTLP 受信アドレスに置き換えることもできます。

 $ kubectl get opentelemetrycollectors NAME MODE VERSION READY AGE IMAGE MANAGEMENT my-sidecar sidecar 0.83.0 102s managed

サイドカーの使用

次に、Instrumentation インスタンスを作成します。

 $ kubectl apply -f - <<EOF apiVersion: opentelemetry.io/v1alpha1 kind: Instrumentation metadata: name: my-instrumentation spec: propagators: - tracecontext - baggage - b3 sampler: type: parentbased_always_on java: image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-java:latest nodejs: image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-nodejs:latest python: image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-python:latest dotnet: image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-dotnet:latest EOF $ kubectl get instrumentation NAME AGE ENDPOINT SAMPLER SAMPLER ARG my-instrumentation 7s parentbased_always_on

このリソース オブジェクトでは、ポッド アノテーションの instruments.opentelemetry.io/inject-java と sidecar.opentelemetry.io/inject を true に設定し、Kubernetes でのワークロードの自動インストルメンテーションを有効にします。 OTLP データを Sidecar に送信し、Sidecar はそのデータを SigNoz コレクターに渡します。

たとえば、次のアプリケーション:

 $ kubectl apply -f - <<EOF apiVersion: apps/v1 kind: Deployment metadata: name: spring-petclinic spec: selector: matchLabels: app: spring-petclinic replicas: 1 template: metadata: labels: app: spring-petclinic annotations: sidecar.opentelemetry.io/inject: "true" instrumentation.opentelemetry.io/inject-java: "true" spec: containers: - name: app image: cnych/spring-petclinic:latest EOF

Instrumentation.opentelemetry.io/inject-{language} アノテーションを Pod に追加するだけで、デプロイされたワークロードの自動インストルメンテーションを有効にすることができます。

上記のリソース オブジェクトを適用した後、OpenTelemetry Operator は、アプリケーションからトレース データを受信して​​ SigNoz コレクターに送信する、my-sidecar という名前の OpenTelemetry Collector サイドカーを作成します。

同様に、アプリケーションのポート 8080 をローカル マシンに転送します。

 $ kubectl get pods NAME READY STATUS RESTARTS AGE spring-petclinic-6bcb946c8-jgbfz 2/2 Running 0 28m $ export POD_NAME=$(kubectl get pod -l app=spring-petclinic -o jsnotallow="{.items[0].metadata.name}") $ kubectl port-forward ${POD_NAME} 8080:8080

これで、ブラウザで http://localhost:8080 にアクセスしてテレメトリ データを生成できるようになりました。

その後、SigNoz で対応する Trace データを表示できます。

最後に、これらのリソース オブジェクトをクリーンアップしましょう。

 $ kubectl delete deployment/spring-petclinic $ kubectl delete instrumentation/my-instrumentation $ kubectl delete otelcol/my-sidecar

サイドカーなしの自動追跡

OpenTelemetry Operator は、サイドカーを必要とせずに自動追跡もサポートします。ここでは、OTLP データを SigNoz エンドポイントに送信する Instrumentation インスタンスも作成します。

 $ kubectl apply -f - <<EOF apiVersion: opentelemetry.io/v1alpha1 kind: Instrumentation metadata: name: my-instrumentation spec: exporter: endpoint: http://signoz-otel-collector.kube-otel.svc.cluster.local:4317 propagators: - tracecontext - baggage - b3 sampler: type: parentbased_traceidratio argument: "0.25" java: image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-java:latest nodejs: image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-nodejs:latest python: image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-python:latest dotnet: image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-dotnet:latest EOF

ここで、定義した Instrumentation インスタンスに exporter.endpoint プロパティを定義して、OTLP データを SigNoz コレクターに送信できるようにしていることに注意してください。

次に、K8s にデプロイした Java ワークロードのポッド アノテーション instruments.opentelemetry.io/inject-java を true に設定する必要があります。

以下は、自動追跡ポイントを備えたスプリング ペットクリニックの例です。

 $ kubectl apply -f - <<EOF apiVersion: apps/v1 kind: Deployment metadata: name: spring-petclinic spec: selector: matchLabels: app: spring-petclinic replicas: 1 template: metadata: labels: app: spring-petclinic annotations: instrumentation.opentelemetry.io/inject-java: "true" spec: containers: - name: app image: cnych/spring-petclinic:latest EOF $ kubectl get instrumentation NAME AGE ENDPOINT SAMPLER SAMPLER ARG my-instrumentation 14s http://signoz-otel-collector.kube-otel.svc.cluster.local:4317 parentbased_traceidratio 0.25

アプリケーションがデプロイされると、コンテナーは 1 つだけになります。同様に、アプリケーションのポート 8080 をローカル コンピューターに転送します。

 $ kubectl get pods NAME READY STATUS RESTARTS AGE spring-petclinic-9f5fffc88-zt4qx 1/1 Running 0 4m45s $ export POD_NAME=$(kubectl get pod -l app=spring-petclinic -o jsnotallow="{.items[0].metadata.name}") $ kubectl port-forward ${POD_NAME} 8080:8080

次に、ブラウザで http://localhost:8080 にアクセスしてテレメトリ データを生成します。

ログ データに traceId と spanId を追加すると、SigNoz でトレースとログのデータを関連付けることができます。 SigNozにはアラームやダッシュボードなどの機能もあります。詳しい機能については、SigNoz の公式ドキュメント (https://signoz.io/docs/) を参照してください。