使用OpenTelemetry Operator將可觀測數(shù)據(jù)發(fā)送到SigNoz
OpenTelemetry Operator 是一個用于部署和管理 OpenTelemetry 組件的 Kubernetes Operator。它是一個自定義的 Kubernetes 控制器,使用 Operator 模式自動化了 OpenTelemetry 環(huán)境的部署、配置和管理過程。
OpenTelemetry Operator 簡化了在 Kubernetes 環(huán)境中部署和管理 OpenTelemetry Collector、OpenTelemetry Agent 等組件的流程。它可以通過 CRD 對 OpenTelemetry 組件進(jìn)行集中化的管理。使用 OpenTelemetry Operator,可以輕松地在 Kubernetes 集群中創(chuàng)建、配置和管理 OpenTelemetry 組件的實例。它提供了許多有用的功能,例如自動創(chuàng)建和管理配置文件、自動注入收集器和代理配置、自動監(jiān)視和擴展等。
部署
這里我們使用 Helm Chart 來部署 OpenTelemetry Operator,首先添加 Helm Chart 倉庫:
$ helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
$ helm repo update
默認(rèn)情況下會部署一個準(zhǔn)入控制器,用于驗證 OpenTelemetry Operator 的配置是否正確,為了使 APIServer 能夠與 Webhook 組件進(jìn)行通信,Webhook 需要一個由 APIServer 配置為可信任的 TLS 證書。有幾種不同的方法可以用來生成/配置所需的 TLS 證書。
- 最簡單的(默認(rèn))方法是安裝 cert-manager 并將 admissionWebhooks.certManager.create 設(shè)置為 true。這樣,cert-manager 就會生成一個自簽名的證書。
- 可以通過配置 admissionWebhooks.certManager.issuerRef 值來提供自己的頒發(fā)者。需要指定類型(Issuer 或 ClusterIssuer)和名稱。請注意,此方法還是需要安裝 cert-manager。
- 可以通過將 admissionWebhooks.certManager.enabled 設(shè)置為 false 并將 admissionWebhooks.autoGenerateCert 設(shè)置為 true 來使用自動生成的自簽名證書。Helm 將創(chuàng)建一個自簽名證書和一個對應(yīng)的 Secret。
- 可以通過將 admissionWebhooks.certManager.enabled 和 admissionWebhooks.autoGenerateCert 設(shè)置為 false 來使用自己生成的自簽名證書。需要向 admissionWebhooks.cert_file、admissionWebhooks.key_file 和 admissionWebhooks.ca_file 提供必要的值。
- 可以通過禁用 .Values.admissionWebhooks.create 和 admissionWebhooks.certManager.enabled 來通過路徑掛載自定義 Webhooks 和證書,同時在 admissionWebhooks.secretName 中設(shè)置自定義證書 Secret 名稱。
- 可以通過禁用 .Values.admissionWebhooks.create 并將 env var 設(shè)置為 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.
正常部署完成后可以看到對應(yīng)的 Pod 已經(jīng)正常運行:
$ 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 相關(guān)的 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(默認(rèn)模式)
OpenTelemetryCollector 類型的 CustomResource 暴露一個名為 .Spec.Mode 的屬性,該屬性可用于指定收集器是否應(yīng)作為 DaemonSet、Sidecar 或 Deployment(默認(rèn))運行。
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 協(xié)議接收 OTLP 跟蹤數(shù)據(jù),對數(shù)據(jù)進(jìn)行批處理并將其記錄到控制臺。應(yīng)用該資源對象后,OpenTelemetry Operator 將創(chuàng)建一個名為 simplest 的 Deployment,該 Deployment 將運行一個 OpenTelemetry Collector 實例,該實例將使用上面的配置來接收、處理和導(dǎo)出跟蹤數(shù)據(jù)。
$ 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 工具,然后將示例跟蹤發(fā)送到這個收集器進(jìn)行測試:
$ go install github.com/open-telemetry/opentelemetry-collector-contrib/cmd/telemetrygen@latest
然后轉(zhuǎn)發(fā) OTLP 服務(wù)的 gRPC 端口:
$ kubectl port-forward service/simplest-collector 4317
在另一個終端中,執(zhí)行以下命令以使用 telemetrygen 發(fā)送跟蹤數(shù)據(jù):
$ telemetrygen traces --traces 1 --otlp-endpoint localhost:4317 --otlp-insecure
然后我們可以查看采集器對應(yīng)的日志,正常可以看到如下所示的日志:
$ 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
DaemonSet 模式
同樣,OpenTelemetry Collector 實例可以使用 DaemonSet 模式部署,這確保所有(或部分)節(jié)點運行收集器 pod 的副本。 對于 DaemonSet,只有 Spec.Mode 屬性會更新為 daemonset。而前面的 otelcol YAML 示例中的配置可以保持原樣,也可以根據(jù)需要進(jìn)行更新。
DaemonSet 適用于諸如日志收集守護程序、存儲守護程序和節(jié)點監(jiān)控守護程序等任務(wù)。在這些情況下,需要在每個節(jié)點上運行一個收集器實例,以便從每個節(jié)點收集數(shù)據(jù),前面其實我們已經(jīng)介紹過。
Sidecar 模式
通過將 pod 注解 sidecar.opentelemetry.io/inject 設(shè)置為 true 或來自同一命名空間的具體 OpenTelemetryCollector 的名稱,可以將具有 OpenTelemetry Collector 的 sidecar 注入到基于 pod 的工作負(fù)載中。
如下所示是創(chuàng)建一個以 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
該示例將創(chuàng)建一個名為 my-sidecar 的 OpenTelemetry Collector sidecar,該 sidecar 將從 Jaeger 接收跟蹤數(shù)據(jù)并將其記錄到控制臺。
$ kubectl get opentelemetrycollectors
NAME MODE VERSION READY AGE IMAGE MANAGEMENT
my-sidecar sidecar 0.83.0 11s managed
接下來,我們使用一個 jaeger 示例鏡像來創(chuàng)建一個 Pod,并將 sidecar.opentelemetry.io/inject 注解設(shè)置為 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
應(yīng)用該 Pod 后,OpenTelemetry Operator 會將上面定義的 my-sidecar 采集器作為 sidecar 注入到 Pod 中,該容器將運行一個 OpenTelemetry Collector 實例,該實例將使用上面的配置來接收、處理和導(dǎo)出跟蹤數(shù)據(jù)。
$ kubectl get pods myapp
NAME READY STATUS RESTARTS AGE
myapp 2/2 Running 0 110s
這里我們可以轉(zhuǎn)發(fā)下 myapp pod 的 8080 端口:
$ kubectl port-forward pod/myapp 8080:8080
然后在另一個終端中,使用 curl 發(fā)送 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/myapp
OpenTelemetry 自動埋點注入
OpenTelemetry Operator 除了可以管理 OpenTelemetry Collector 之外,還可以注入和配置 OpenTelemetry 自動追蹤庫。
埋點資源配置
目前,支持 Java、NodeJS、Python 和 DotNet 語言的埋點。當(dāng)以下注解應(yīng)用于工作負(fù)載或命名空間時,將啟用儀器化。
- 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 環(huán)境變量。
注解的可能值有:
- true - 從命名空間注入和埋點資源。
- my-instrumentation - 當(dāng)前命名空間中 Instrumentation CR 實例的名稱。
- my-other-namespace/my-instrumentation - 另一個命名空間中 Instrumentation CR 實例的名稱和命名空間。
- false -不注入。
在使用自動插樁之前,我們需要使用 SDK 和插樁的配置來配置一個 Instrumentation 資源。
Instrumentation 由以下屬性組成:
- exporter.endpoint -(可選)將遙測數(shù)據(jù)發(fā)送到 OTLP 格式的地址。
- propagators - 使所有數(shù)據(jù)源能夠共享底層上下文機制,用于在事務(wù)的整個生命周期中存儲狀態(tài)和訪問數(shù)據(jù)。
- sampler - 通過減少收集和發(fā)送到后端的跟蹤樣本數(shù)量來引入的噪音和開銷的機制。 OpenTelemetry 提供兩種類型:StaticSampler 和 TraceIDRatioBased。
- 語言屬性,即 java、nodejs、python 和 dotnet - 根據(jù) pod 注解中設(shè)置的語言,使用自動插樁的自定義鏡像。
安裝 SigNoz
下面我們準(zhǔn)備使用 SigNoz 來作為 OTLP 接收器。SigNoz 是一個開源 APM,它可以幫助開發(fā)人員監(jiān)控他們的應(yīng)用程序并解決問題,是 DataDog、NewRelic 等的開源替代品。開源應(yīng)用程序性能監(jiān)控 (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
隔一會兒時間就可以看到對應(yīng)的 Pod 已經(jīng)正常運行:
$ 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 了:
第一次訪問的時候需要創(chuàng)建一個 admin 賬號,根據(jù)頁面提示創(chuàng)建即可。創(chuàng)建后就可以進(jìn)入 SigNoz 的主界面了:
此外 SigNoz 還會采集 Kubernetes 集群的日志數(shù)據(jù),我們可以在 Logs
頁面查看:
到這里 SigNoz 就部署完成了。
注入 OpenTelemetry SDK 環(huán)境變量
我們可以通過使用 inject-sdk 來配置 OpenTelemetry SDK,以應(yīng)用于目前無法自動插樁的應(yīng)用程序。這會注入環(huán)境變量,例如 OTEL_RESOURCE_ATTRIBUTES、OTEL_TRACES_SAMPLER 和 OTEL_EXPORTER_OTLP_ENDPOINT,可以在 Instrumentation 中進(jìn)行配置,但實際上不會提供 SDK。
下面我們來創(chuàng)建一個將 OTLP 接收器作為輸入和輸出的 Sidecar,將遙測數(shù)據(jù)發(fā)送到 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 導(dǎo)出器的 endpoint 地址為 http://signoz-otel-collector.kube-otel.svc.cluster.local:4317,這是上面我們安裝的 Signoz 采集器的地址,當(dāng)然也可以替換成你自己的 OTLP 接收器地址。
$ kubectl get opentelemetrycollectors
NAME MODE VERSION READY AGE IMAGE MANAGEMENT
my-sidecar sidecar 0.83.0 102s managed
使用 Sidecar
接下來可以創(chuàng)建一個 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 設(shè)置為 true,這樣可以在 Kubernetes 中配置工作負(fù)載的自動埋點。它會將 OTLP 數(shù)據(jù)發(fā)送到 Sidecar,而 Sidecar 會將數(shù)據(jù)傳遞給 SigNoz 收集器。
比如下面的應(yīng)用程序:
$ 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} 注解即可對已部署的工作負(fù)載啟用自動檢測功能。
應(yīng)用上面的資源對象后,OpenTelemetry Operator 將創(chuàng)建一個名為 my-sidecar 的 OpenTelemetry Collector sidecar,該 sidecar 將從應(yīng)用程序接收跟蹤數(shù)據(jù)并將其發(fā)送到 SigNoz 采集器。
同樣我們將該應(yīng)用程序的 8080 端口轉(zhuǎn)發(fā)到本地:
$ 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
現(xiàn)在我們在瀏覽器中訪問 http://localhost:8080 后就可以來生成遙測數(shù)據(jù)了。
然后我們可以在 SigNoz 中查看到對應(yīng)的 Trace 數(shù)據(jù)。
最后讓我們來清理下這些資源對象:
$ kubectl delete deployment/spring-petclinic
$ kubectl delete instrumentation/my-instrumentation
$ kubectl delete otelcol/my-sidecar
無需 Sidecar 的自動埋點
OpenTelemetry Operator 還支持無需 Sidecar 的自動埋點。同樣我們這里創(chuàng)建將 OTLP 數(shù)據(jù)發(fā)送到 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
注意現(xiàn)在我們定義的 Instrumentation 實例中定義了 exporter.endpoint 屬性,這樣就可以將 OTLP 數(shù)據(jù)發(fā)送到 SigNoz 采集器了。
接下來我們只需要為我們在 K8s 中部署的 Java 工作負(fù)載設(shè)置 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
應(yīng)用部署后則只有一個容器,同樣我們將該應(yīng)用程序的 8080 端口轉(zhuǎn)發(fā)到本地:
$ 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 后就可以來生成遙測數(shù)據(jù)了。
如果在日志數(shù)據(jù)中加入了 traceId 和 spanId,我們就可以在 SigNoz 中將 trace 和 logs 數(shù)據(jù)關(guān)聯(lián)起來了。SigNoz 還有報警、Dashboard 等功能,更多功能可以參考 SigNoz 官方文檔(https://signoz.io/docs/)。