OpenObserve HA模式安裝配置
前面我們了解到 OpenObserve 的架構支持單節點和 HA 兩種模式,接下來我們來了解下 OpenObserve 的 HA 模式是如何使用的。
OpenObserve 可以在裸機服務器、虛擬機、Kubernetes 和其他平臺上以 HA 模式安裝和運行,但目前官方提供的使用 Helm Chart 的安裝方式,所以需要提前準備一個可用的 Kubernetes 集群。
由于 HA 模式不支持本地磁盤存儲,因此必須配置對象存儲(例如 s3、minio、gcs 等等),這里我們就以 minio 為例進行說明。
首先添加 openobserve 的 helm 倉庫:
$ helm repo add openobserve https://charts.openobserve.ai
$ helm repo update
# 或者直接 clone chart 倉庫
$ git clone https://github.com/openobserve/openobserve-helm-chart.git
然后可以使用下面的命令來獲取 helm chat 包:
$ tree openobserve-helm-chart
openobserve-helm-chart
├── Chart.lock
├── Chart.yaml
├── LICENSE
├── README.md
├── charts
│ ├── etcd-8.10.1.tgz
│ ├── etcd-8.11.4.tgz
│ └── minio-5.0.7.tgz
├── index.yaml
├── publish.sh
├── templates
│ ├── NOTES.txt
│ ├── _helpers.tpl
│ ├── alertmanager-deployment.yaml
│ ├── alertmanager-service.yaml
│ ├── compactor-deployment.yaml
│ ├── compactor-hpa.yaml
│ ├── compactor-service.yaml
│ ├── configmap.yaml
│ ├── ingester-hpa.yaml
│ ├── ingester-service.yaml
│ ├── ingester-statefulset.yaml
│ ├── ingress.yaml
│ ├── issuer.yaml
│ ├── querier-deployment.yaml
│ ├── querier-hpa.yaml
│ ├── querier-service.yaml
│ ├── router-deployment.yaml
│ ├── router-hpa.yaml
│ ├── router-service.yaml
│ ├── secret.yaml
│ ├── serviceaccount.yaml
│ ├── zplane-deployment.yaml
│ ├── zplane-ingress.yaml
│ └── zplane-service.yaml
└── values.yaml
2 directories, 34 files
整個包里面還包括 etcd 和 minio 兩個依賴的 helm chart 包,創建一個 oo-values.yaml 文件,然后添加如下內容:
auth:
ZO_ROOT_USER_EMAIL: "root@example.com"
ZO_ROOT_USER_PASSWORD: "root321"
# 啟用了 minio 不用設置這個
# ZO_S3_ACCESS_KEY: "console"
# ZO_S3_SECRET_KEY: "console123"
config:
# ZO_S3_SERVER_URL: "http://minio:9000" # 啟用了 minio 不用設置這個
ZO_S3_BUCKET_NAME: "openobserve"
ZO_S3_REGION_NAME: "us-east-1"
ZO_S3_PROVIDER: "minio" # 只有在使用 minio 進行對象存儲時才需要設置這個,如果啟用了minio,將會自動設置。
ZO_TELEMETRY: "false" # 發送匿名遙測信息以改進OpenObserve,您可以將其設置為false來禁用。
# ZO_ETCD_ADDR: "openobserve-etcd-headless.openobserve.svc.cluster.local:2379" # etcd endpoint,啟用 etcd 會自動配置
ZO_DATA_DIR: "./data/" # 指定數據目錄,主要是 WAL 日志
ZO_WAL_MEMORY_MODE_ENABLED: "false" # 開啟內存模式,開啟后不再寫入本地文件,wal的數據直接在內存中,然后從內存轉存到對象存儲,為了解決某些云服務器,本地磁盤性能很差的問題,但是需要大內存。
ZO_WAL_LINE_MODE_ENABLED: "true" # wal的寫入模式,一般寫入數據的時候都會批量寫入,但是這有個潛在的風險。比如你一次寫入了10k數據,如果我一次性寫入wal,有可能遇到系統崩潰,掉電,這一批數據不知道斷在哪兒,wal文件會出錯。可能寫入了一半。如果開啟line模式,就是雖然你是一次給了我10k數據,我寫入wal的時候,一行行的調用write接口,這樣wal損壞的可能性小一些,但是性能稍微差一些。
replicaCount: # 可以根據需要調整副本數
ingester: 1
querier: 1
router: 1
alertmanager: 1
compactor: 1
ingester:
persistence: # 持久化 data 目錄,主要是 WAL 日志
enabled: true
size: 10Gi
storageClass: "cfsauto" # 指定可用的 storage class
accessModes:
- ReadWriteOnce
ingress:
enabled: true
className: "nginx"
annotations:
nginx.ingress.kubernetes.io/enable-cors: "true"
nginx.ingress.kubernetes.io/connection-proxy-header: keep-alive
nginx.ingress.kubernetes.io/proxy-connect-timeout: "600"
nginx.ingress.kubernetes.io/proxy-send-timeout: "600"
nginx.ingress.kubernetes.io/proxy-read-timeout: "600"
nginx.ingress.kubernetes.io/proxy-body-size: 32m
hosts:
- host: oo.k8s.local
paths:
- path: /
pathType: ImplementationSpecific
etcd:
enabled: true # 指定 etcd 是否啟用
replicaCount: 1 # 奇數
persistence:
size: 20Gi
storageClass: "cfsauto" # 指定可用的 storage class
accessModes:
- ReadWriteOnce
minio:
enabled: true # 指定 minio 是否啟用
region: "us-east-1"
rootUser: rootuser
rootPassword: rootpass123
drivesPerNode: 1
replicas: 2
mode: distributed # or standalone
buckets:
- name: openobserve
policy: none
purge: false
persistence:
enabled: true
size: 10Gi
storageClass: "cfsauto" # 指定可用的 storage class
accessModes:
- ReadWriteOnce
consoleIngress:
enabled: true
ingressClassName: "nginx"
annotations:
kubernetes.io/ingress.allow-http: "true"
nginx.ingress.kubernetes.io/secure-backends: "true"
nginx.ingress.kubernetes.io/whitelist-source-range: 0.0.0.0/0
path: /
hosts:
- minio.k8s.local
在這個文件中我們指定了管理員的郵箱和密碼,還有對象存儲的相關配置,然后指定了 etcd 和 minio 的相關配置,要注意 auth 和 config 部分的配置,如果啟用了 minio,那么 ZO_S3_ACCESS_KEY、ZO_S3_SECRET_KEY、ZO_S3_SERVER_URL 這些配置都可以省略,因為這些配置項會自動設置,包括如果啟用了 etcd,ZO_ETCD_ADDR 參數也會自動配置。
另外我們可以看到 ingester 組件我們配置了數據持久化,這主要是為了對 WAL 日志數據的持久化,關于 WAL 主要有兩種模式:
- ZO_WAL_MEMORY_MODE_ENABLED: 內存模式,開啟后不再寫入本地文件,wal 的數據直接在內存中,然后從內存轉存到對象存儲,為了解決某些云服務器,本地磁盤性能很差的問題,但是需要大內存。
- ZO_WAL_LINE_MODE_ENABLED: WAL 的寫入模式,默認開啟,一般寫入數據的時候都會批量寫入,但是這有個潛在的風險。比如你一次寫入了 10k 數據,如果我一次性寫入 wal,有可能遇到系統崩潰,掉電,這一批數據不知道斷在哪兒,wal 文件會出錯。可能寫入了一半。如果開啟 line 模式,就是雖然你是一次給了我 10k 數據,我寫入 wal 的時候,一行行的調用 write 接口,這樣 wal 損壞的可能性小一些,但是性能稍微差一些。
所以如果我們使用內存模式的話理論上可以不用持久化數據目錄,但有一種情況會落盤,就是當內存中還有數據的時候程序接收到關閉指令,會把內存中的數據 dump 到磁盤,下次啟動的時候再轉移到對象存儲中去。
更多配置可以參考官方文檔關于環境變量的說明:https://openobserve.ai/docs/environment-variables/。
然后使用如下命令即可一件安裝 OpenObserve:
$ helm upgrade --install openobserve -f oo-values.yaml --namespace openobserve ./openobserve-helm-chart
Release "openobserve" does not exist. Installing it now.
NAME: openobserve
LAST DEPLOYED: Thu Aug 10 15:31:37 2023
NAMESPACE: openobserve
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
1. Get the application URL by running these commands:
http://oo.k8s.local/
安裝后我們可以查看一下 OpenObserve 的 Pod 狀態:
$ kubectl get pods -n openobserve
NAME READY STATUS RESTARTS AGE
openobserve-alertmanager-7957d8fb79-xzh8z 1/1 Running 4 (31m ago) 32m
openobserve-compactor-d679d4765-gpkgk 1/1 Running 4 (31m ago) 32m
openobserve-etcd-0 1/1 Running 0 32m
openobserve-ingester-0 1/1 Running 0 4m31s
openobserve-minio-0 1/1 Running 0 32m
openobserve-minio-1 1/1 Running 0 32m
openobserve-querier-56456d48c5-dth52 1/1 Running 4 (31m ago) 32m
openobserve-router-7bd4fcbc6c-nrmbs 1/1 Running 3 (32m ago) 32m
prometheus-756c8c78f5-gkwl8 1/1 Running 0 2d
$ kubectl get svc -n openobserve
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
openobserve-alertmanager ClusterIP 10.102.247.215 <none> 5080/TCP 71m
openobserve-compactor ClusterIP 10.96.24.228 <none> 5080/TCP 71m
openobserve-etcd ClusterIP 10.103.96.225 <none> 2379/TCP,2380/TCP 71m
openobserve-etcd-headless ClusterIP None <none> 2379/TCP,2380/TCP 71m
openobserve-ingester ClusterIP 10.108.17.186 <none> 5080/TCP 71m
openobserve-minio ClusterIP 10.108.196.221 <none> 9000/TCP 71m
openobserve-minio-console ClusterIP 10.103.65.90 <none> 9001/TCP 71m
openobserve-minio-svc ClusterIP None <none> 9000/TCP 71m
openobserve-querier ClusterIP 10.99.221.44 <none> 5080/TCP 71m
openobserve-router ClusterIP 10.101.230.112 <none> 5080/TCP 71m
$ kubectl get ingress -n openobserve
NAME CLASS HOSTS ADDRESS PORTS AGE
openobserve nginx oo.k8s.local 10.98.12.94 80 53m
openobserve-minio-console nginx minio.k8s.local 10.98.12.94 80 53m
可以看到 OpenObserve 的幾個組件 Router、Querier、Ingester、Alertmanager、Compactor、Minio、Etcd 都已經正常運行了,此外我們為 MinIO 和 OpenObserve 都添加了 Ingress,只需要將 oo.k8s.local 和 minio.k8s.local 映射到 Ingress 控制器即可訪問。
比如現在我們可以通過 minio.k8s.local 來訪問 MINIO 的 UI 界面:
使用用戶名 rootuser 和密碼 rootpass123 即可登錄成功。
可以看到指定的 openobserve bucket 也已經創建成功了:
同樣我們也可以通過 oo.k8s.local 來訪問 OpenObserve 的 UI 界面:
只是現在還沒有任何數據:
接下來我們只需要將前面日志、指標、鏈路追蹤的數據發送到新的 OpenObserve 地址 http://openobserve-router.openobserve.svc.cluster.local:5080 即可,比如前面我們已經部署的 Fluentd,只需要將日志輸出地址修改即可:
# fluentd.yaml
# ...... 省略部分配置
output.conf: |-
<match **>
@type http # 使用http插件
endpoint http://openobserve-router.openobserve:5080/api/default/K8sLogs/_json # 指定接收日志的地址
content_type json
json_array true
<auth>
method basic
username root@example.com
password root321
</auth>
<buffer>
flush_interval 2s # 每2秒發送一次
</buffer>
</match>
然后重啟 fluentd 即可,隔一會兒就可以在 OpenObserve 的 UI 界面中看到日志數據了:
同樣對于 Prometheus 也是一樣的,只需要修改 Prometheus 的配置文件中的遠程寫入地址即可:
remote_write: # 寫入到遠程 OO,url 是遠程寫入接口地址
- url: http://openobserve-router.openobserve:5080/api/default/prometheus/api/v1/write
basic_auth:
username: root@example.com
password: root321
對于鏈路追蹤數據也是一樣的,只需要修改 OpenTelemetry Collector 的配置文件中的遠程寫入地址即可。
最后我們可以去 MINIO 中驗證下數據是否已經寫入到對象存儲中了:
不過需要注意的是數據并不是實時上傳到對象存儲中的,默認 10 分鐘或者 WAL 達到 32MB 后會上傳一次。
到這里 OpenObserve 的 HA 模式就部署完成了,我們可以根據需要設置各個組件的副本數量進行橫向擴展,也可以啟用 HPA 來自動擴縮容。
其他更多功能請參考官方文檔 https://openobserve.ai/docs/ 以了解更多相關信息。