從零到一：GreptimeDB 與 Grafana 的無縫集成指南
引言
我們的上一篇文章中講解到了 Prometheus-Agent + GreptimeDB，當時最大的問題是使用 GreptimeDB 作為 Grafana 的數(shù)據(jù)源，然后去看 Dashboard 有很多的都沒有數(shù)據(jù)，如下圖所示
圖片
當時文章一經(jīng)發(fā)出，就收到了來自 GreptimeDB[1] 官方人員的注意，隨后，我們經(jīng)過進一步的交流，如下圖所示
圖片
圖片
隨后，我們進入群聊
圖片
圖片
以下的這部分算是 get 到了終點，但是當時并沒有立刻采取行動
圖片
圖片
圖片
圖片
圖片
到了后面，我想著怎么給 GreptimeDB 弄一個自定義的存儲，因為它的這個 控制器 創(chuàng)建完成后，就會自動創(chuàng)建 PV 和 PVC 然后掛載，10G 的存儲，但是我想要自定義，如下 YAML。
apiVersion: greptime.io/v1alpha1
kind: GreptimeDBStandalone
metadata:
name: greptimedb
namespace: greptimedb-admin
spec:
base:
main:
image: greptime/greptimedb:v0.11.2
# resources:
# limits:
# cpu: "1" # 最大可使用的 2 個 CPU
# memory: "1Gi" # 最大可使用 4GB 內(nèi)存
# requests:
# cpu: "1" # 最少需要 1 個 CPU
# memory: "1Gi" # 最少需要 2GB 內(nèi)存
datanodeStorage: # 我這里沒有定義 StorageClassName 是因為它會去使用 default 的
fs:
mountPath: "/data/greptimedb"
name: "greptimedb-storage"
storageRetainPolicy: "Retain" # 數(shù)據(jù)卷策略
storageSize: "30Gi"然后我們部署看看；
jacobleo@Jacobs-MacBook-Air greptimedb % kg pvc -A
NAMESPACE NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE
greptimedb-admin greptimedb-storage-greptimedb-standalone-0 Bound pvc-160dd148-b272-439f-b8e1-f480def01bfc 30Gi RWO local-path <unset> 36s
monitoring grafana-pvc Bound pvc-5cd3dc87-bda9-45aa-b02c-f54112b49a2b 30Gi RWO local-path <unset> 5h3m
monitoring prometheus-k8s-db-prometheus-k8s-0 Bound pvc-e6daef05-4ff1-42bf-b4f0-2b459d3a6f12 1Gi RWO local-path <unset> 5h2m
monitoring prometheus-k8s-db-prometheus-k8s-1 Bound pvc-e294d11d-4099-4ba8-ade8-24eed34f79de 1Gi RWO local-path <unset> 5h2m可以看到是 30G，并沒有我們上面說的那個問題，原來是我搞錯了，我們下面這個關于存儲的問題就解決了。
圖片
圖片
這邊當時也挺搞笑的，哈哈！
圖片
圖片
圖片
圖片
圖片
圖片
圖片
圖片
圖片
圖片
圖片
我們這里添加下：
這里添加就 work 了，然后如果還有更多的，就繼續(xù)添加就可以了。
·····
externalLabels:
cluster: "cluster-test"
·····
圖片
可以看到，終于有數(shù)據(jù)了。
圖片
但是這又有一個問題，其實還有很多像這樣類似的問題，大致解決，和上面的是一樣的思路。
圖片
我們添加下就可以了。
·····
externalLabels:
cluster: "cluster-test"
workload_type: "deployment, stateful"
·····弄了半天，還是不行，在此希望有大佬出主意，非常感謝，作為回報，我會把你記在心里！
可以看下我們最終的 YAML 文件；
apiVersion: v1
kind: ServiceAccount
metadata:
name: prometheus-agent
namespace: greptimedb-admin
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: prometheus-agent
rules:
- apiGroups: [""]
resources:
- namespaces
- secrets
- persistentvolumeclaims
verbs: ["get", "list", "watch"]
- apiGroups: ["monitoring.coreos.com"]
resources: ["servicemonitors", "podmonitors", "prometheuses"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources:
- nodes
- nodes/metrics
- services
- endpoints
- pods
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources:
- configmaps
verbs: ["get"]
- apiGroups:
- discovery.k8s.io
resources:
- endpointslices
verbs: ["get", "list", "watch"]
- apiGroups:
- networking.k8s.io
resources:
- ingresses
verbs: ["get", "list", "watch"]
- nonResourceURLs: ["/metrics"]
verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: prometheus-agent
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: prometheus-agent
subjects:
- kind: ServiceAccount
name: prometheus-agent
namespace: greptimedb-admin
---
apiVersion: monitoring.coreos.com/v1alpha1
kind: PrometheusAgent
metadata:
name: prometheus-agent
namespace: greptimedb-admin
spec:
image: quay.io/prometheus/prometheus:v3.0.1
replicas: 1
serviceAccountName: prometheus-agent
enableFeatures:
- agent
remoteWrite:
- url: "http://greptimedb.kubernetes.click/v1/prometheus/write?db=public"
queueConfig:
capacity: 5000
maxSamplesPerSend: 10000
batchSendDeadline: 5s
serviceMonitorSelector: {}
serviceMonitorNamespaceSelector: {}
podMonitorNamespaceSelector: {}
podMonitorSelector: {}
resources:
limits:
cpu: "2"
memory: "4Gi"
requests:
cpu: "1"
memory: "2Gi"
externalLabels:
cluster: "cluster-test"
workload_type: "deployment, stateful"結(jié)語
這個問題，還可以，不算是特別過分吧，還是跌虧有 GreptimeDB 的相關人員，不然，這個問題怎么解決？
那么我們的 Prometheus-Agent + GreptimeDB 算是不是很圓滿地結(jié)束了，但是后面大概還會又些小問題，不過都是小事了。
引用鏈接
[1] GreptimeDB: https://greptime.com/
