使用OpenTelemetry Operator將可觀測數據發送到SigNoz
OpenTelemetry Operator 是一個用于部署和管理 OpenTelemetry 組件的 Kubernetes Operator。它是一個自定義的 Kubernetes 控制器，使用 Operator 模式自動化了 OpenTelemetry 環境的部署、配置和管理過程。
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 將創建一個自簽名證書和一個對應的 Secret。
- 可以通過將 admissionWebhooks.certManager.enabled 和 admissionWebhooks.autoGenerateCert 設置為 false 來使用自己生成的自簽名證書。需要向 admissionWebhooks.cert_file、admissionWebhooks.key_file 和 admissionWebhooks.ca_file 提供必要的值。
- 可以通過禁用 .Values.admissionWebhooks.create 和 admissionWebhooks.certManager.enabled 來通過路徑掛載自定義 Webhooks 和證書，同時在 admissionWebhooks.secretName 中設置自定義證書 Secret 名稱。
- 可以通過禁用 .Values.admissionWebhooks.create 并將 env var 設置為 ENABLE_WEBHOOKS: "false" 來完全禁用 Webhooks。
為了簡單我們這里可以選擇第三種方式，直接使用自動生成的自簽名證書，直接使用下面的命令一鍵安裝 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：
$ 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 種不同的部署模式可用：
- DaemonSet
- Sidecar
- Deployment（默認模式）
OpenTelemetryCollector 類型的 CustomResource 暴露一個名為 .Spec.Mode 的屬性，該屬性可用于指定收集器是否應作為 DaemonSet、Sidecar 或 Deployment（默認）運行。
Deployment 模式
我們可以訂閱一個如下所示的 OpenTelemetryCollector CRD，用來部署一個 Deployment 模式的 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 的 Deployment，該 Deployment 將運行一個 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 simplestDaemonSet 模式
同樣，OpenTelemetry Collector 實例可以使用 DaemonSet 模式部署，這確保所有（或部分）節點運行收集器 pod 的副本。 對于 DaemonSet，只有 Spec.Mode 屬性會更新為 daemonset。而前面的 otelcol YAML 示例中的配置可以保持原樣，也可以根據需要進行更新。
DaemonSet 適用于諸如日志收集守護程序、存儲守護程序和節點監控守護程序等任務。在這些情況下，需要在每個節點上運行一個收集器實例，以便從每個節點收集數據，前面其實我們已經介紹過。
Sidecar 模式
通過將 pod 注解 sidecar.opentelemetry.io/inject 設置為 true 或來自同一命名空間的具體 OpenTelemetryCollector 的名稱，可以將具有 OpenTelemetry Collector 的 sidecar 注入到基于 pod 的工作負載中。
如下所示是創建一個以 jaeger 作為輸入并將輸出記錄到控制臺的 Sidecar 的示例：
$ 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該示例將創建一個名為 my-sidecar 的 OpenTelemetry Collector sidecar，該 sidecar 將從 Jaeger 接收跟蹤數據并將其記錄到控制臺。
$ 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 采集器作為 sidecar 注入到 Pod 中，該容器將運行一個 OpenTelemetry Collector 實例，該實例將使用上面的配置來接收、處理和導出跟蹤數據。
$ kubectl get pods myapp
NAME READY STATUS RESTARTS AGE
myapp 2/2 Running 0 110s
這里我們可以轉發下 myapp pod 的 8080 端口：
$ kubectl port-forward pod/myapp 8080:8080然后在另一個終端中，使用 curl 發送 HTTP 請求：
$ curl http://localhost:8080
Hello from Vert.x!然后可以查看 Sidecar 容器的輸出日志，正常可以看到如下所示的 Trace 日志：
$ 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 pod:
$ kubectl delete otelcol/my-sidecar
$ kubectl delete pod/myappOpenTelemetry 自動埋點注入
OpenTelemetry Operator 除了可以管理 OpenTelemetry Collector 之外，還可以注入和配置 OpenTelemetry 自動追蹤庫。
埋點資源配置
目前，支持 Java、NodeJS、Python 和 DotNet 語言的埋點。當以下注解應用于工作負載或命名空間時，將啟用儀器化。
- instrumentation.opentelemetry.io/inject-java: "true" — 對于 Java。
- instrumentation.opentelemetry.io/inject-nodejs: "true" — 對于 NodeJS。
- instrumentation.opentelemetry.io/inject-python: "true" — 對于 Python。
- instrumentation.opentelemetry.io/inject-dotnet: "true" — 對于 DotNet。
- instrumentation.opentelemetry.io/inject-sdk: "true" - 僅適用于 OpenTelemetry SDK 環境變量。
注解的可能值有：
- true - 從命名空間注入和埋點資源。
- my-instrumentation - 當前命名空間中 Instrumentation CR 實例的名稱。
- my-other-namespace/my-instrumentation - 另一個命名空間中 Instrumentation CR 實例的名稱和命名空間。
- false -不注入。
在使用自動插樁之前，我們需要使用 SDK 和插樁的配置來配置一個 Instrumentation 資源。
Instrumentation 由以下屬性組成：
- exporter.endpoint -（可選）將遙測數據發送到 OTLP 格式的地址。
- propagators - 使所有數據源能夠共享底層上下文機制，用于在事務的整個生命周期中存儲狀態和訪問數據。
- sampler - 通過減少收集和發送到后端的跟蹤樣本數量來引入的噪音和開銷的機制。 OpenTelemetry 提供兩種類型：StaticSampler 和 TraceIDRatioBased。
- 語言屬性，即 java、nodejs、python 和 dotnet - 根據 pod 注解中設置的語言，使用自動插樁的自定義鏡像。
安裝 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 了：
第一次訪問的時候需要創建一個 admin 賬號，根據頁面提示創建即可。創建后就可以進入 SigNoz 的主界面了：
此外 SigNoz 還會采集 Kubernetes 集群的日志數據，我們可以在 Logs 頁面查看：
到這里 SigNoz 就部署完成了。
注入 OpenTelemetry SDK 環境變量
我們可以通過使用 inject-sdk 來配置 OpenTelemetry SDK，以應用于目前無法自動插樁的應用程序。這會注入環境變量，例如 OTEL_RESOURCE_ATTRIBUTES、OTEL_TRACES_SAMPLER 和 OTEL_EXPORTER_OTLP_ENDPOINT，可以在 Instrumentation 中進行配置，但實際上不會提供 SDK。
下面我們來創建一個將 OTLP 接收器作為輸入和輸出的 Sidecar，將遙測數據發送到 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這里我們重新定義了一個 Sidecar 模式的采集器，注意定義的 OTLP 導出器的 endpoint 地址為 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使用 Sidecar
接下來可以創建一個 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在這個資源對象中，我們將 pod 的注解 instrumentation.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我們只需在 Pod 中添加 instrumentation.opentelemetry.io/inject-{language} 注解即可對已部署的工作負載啟用自動檢測功能。
應用上面的資源對象后，OpenTelemetry Operator 將創建一個名為 my-sidecar 的 OpenTelemetry Collector sidecar，該 sidecar 將從應用程序接收跟蹤數據并將其發送到 SigNoz 采集器。
同樣我們將該應用程序的 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無需 Sidecar 的自動埋點
OpenTelemetry Operator 還支持無需 Sidecar 的自動埋點。同樣我們這里創建將 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 工作負載設置 pod 注解 instrumentation.opentelemetry.io/inject-java 為true 即可。
如下所示是一個帶有自動埋點的 spring petclinic 的示例：
$ 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應用部署后則只有一個容器，同樣我們將該應用程序的 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 中將 trace 和 logs 數據關聯起來了。SigNoz 還有報警、Dashboard 等功能，更多功能可以參考 SigNoz 官方文檔(https://signoz.io/docs/)。
