从零到一：GreptimeDB 与 Grafana 的无缝集成指南-51CTO.COM

引言

我们的上一篇文章中讲解到了 Prometheus-Agent + GreptimeDB，当时最大的问题是使用 GreptimeDB 作为 Grafana 的数据源，然后去看 Dashboard 有很多的都没有数据，如下图所示

图片

当时文章一经发出，就收到了来自 GreptimeDB[1] 官方人员的注意，随后，我们经过进一步的交流，如下图所示

图片

随后，我们进入群聊

图片

以下的这部分算是 get 到了终点，但是当时并没有立刻采取行动

图片

到了后面，我想着怎么给 GreptimeDB 弄一个自定义的存储，因为它的这个控制器创建完成后，就会自动创建 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 内存
     #   requests:
     #     cpu: "1"       # 最少需要 1 个 CPU
     #     memory: "1Gi"  # 最少需要 2GB 内存
  datanodeStorage:   # 我这里没有定义 StorageClassName 是因为它会去使用 default 的
    fs:
      mountPath: "/data/greptimedb"
      name: "greptimedb-storage"
      storageRetainPolicy: "Retain" # 数据卷策略
      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 了，然后如果还有更多的，就继续添加就可以了。

·····
  externalLabels:
    cluster: "cluster-test"
·····

图片

可以看到，终于有数据了。

图片

但是这又有一个问题，其实还有很多像这样类似的问题，大致解决，和上面的是一样的思路。

图片

我们添加下就可以了。

·····
  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"

结语

这个问题，还可以，不算是特别过分吧，还是跌亏有 GreptimeDB 的相关人员，不然，这个问题怎么解决？

那么我们的 Prometheus-Agent + GreptimeDB 算是不是很圆满地结束了，但是后面大概还会又些小问题，不过都是小事了。

引用链接

[1] GreptimeDB: https://greptime.com/