Helm-charts: [prometheus-kube-stack] Grafana is not persistent

Created on 1 Dec 2020  路  8Comments  路  Source: prometheus-community/helm-charts

Describe the bug
I installed the prometheus-community/kube-prometheus-stack chart.
and then I defined panels and alerts on grafana.
when I delete the grafana pod - all the data is deleted from grafana - there is no persistency.
I wanted to use this solution: https://github.com/prometheus-operator/prometheus-operator/issues/2558#issuecomment-565119967
but to my surprise - no pv or pvc was created by the prometheus-kube-stack chart.

how can I make my Grafana persistent ?

Version of Helm and Kubernetes:

Helm Version:

$ helm version
version.BuildInfo{Version:"v3.0.3", GitCommit:"ac925eb7279f4a6955df663a0128044a8a6b7593", GitTreeState:"clean", GoVersion:"go1.13.6"}

Kubernetes Version:

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.0", GitCommit:"641856db18352033a0d96dbc99153fa3b27298e5", GitTreeState:"clean", BuildDate:"2019-03-25T15:53:57Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.13-eks-2ba888", GitCommit:"2ba888155c7f8093a1bc06e3336333fbdb27b3da", GitTreeState:"clean", BuildDate:"2020-07-17T18:48:53Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}

Which chart: prometheus-kube-stack

Which version of the chart: 12.3.0

How to reproduce it (as minimally and precisely as possible): Install prometheus-kube-stack and define a panel in grafana, then delete the grafana pod

bug lifecyclstale

Most helpful comment

There is a setting for prometheus and alertmanager

storage: volumeClaimTemplate: spec: accessModes: [ "ReadWriteOnce" ] storageClassName: sc-mirror resources: requests: storage: 300Mi

I think we should have the same for grafana ?

All 8 comments

There is a setting for prometheus and alertmanager

storage: volumeClaimTemplate: spec: accessModes: [ "ReadWriteOnce" ] storageClassName: sc-mirror resources: requests: storage: 300Mi

I think we should have the same for grafana ?

This is not a bug as data persistence is not enabled by default. You can either claim a PersistentVolume in your custom values.yaml file like @survivant suggested or export your dashboards as JSON definition files and create a ConfigMap with the JSON-formatted data for each custom dashboard. This way with each new release of the stack via helm, the modifications within Grafana do not persist but your exported dashboards get redeployed with everything else.

@ofiryy I update the yaml: values.yaml add:

grafana:
  persistence:
    enabled: true

to fix the grafana persistent problem.

@blademainer but we still can't choose our storage class

@survivant prometheus-community/kube-prometheus-stack chart uses the grafana/grafana chart as a dependency. So any values you can pass to grafana/grafana you can pass to the grafana object in this chart. Or am I misunderstanding the issue being raised?

This works for me

grafana:
  enabled: true

  persistence:
    enabled: true
    type: pvc
    storageClassName: default
    accessModes:
    - ReadWriteOnce
    size: 4Gi
    finalizers:
    - kubernetes.io/pvc-protection

@BertelBB thank you. I don't know what I did wrong at that time.. but it works fine. Now, I need to find a workaround for https://github.com/prometheus-community/helm-charts/issues/437

I'm not sure the workflow of expecting all the grafana settings to get zapped on the next stopping of a pod has got the best interests of the enterprise in mind. I get the argument of exporting the charts as JSON and storing into configMaps to make them deployment agnostic, but there are other settings not related to charts that we don't want to have disappear when a pod crashes either (such as user login information, settings around alerting, and so forth). So, unless there is a best practice for storing all of that into configmaps as well (and a good user UI for how to do that, which doesn't require kubectl and a Kubernetes admin), it seems shortsighted to think that Grafana can live in an enterprise environment as an application that doesn't require persistence. It seems the opposite would be true.

I too am wringing out the kinks of my Prometheus install and ran into this exact same problem of grafana not supporting persistence out of the box. It was rather alarming to learn that after I began building out dashboards, I lost that work when I tested out the failover scenarios of the pod going down. I did not see a persistence piece in the grafana part of the values.yaml and didn't know that this would turn grafana into an app with a temporary persistence layer.

In hind sight, I should have done my pod failover test first before beginning to "persist" data in grafana to learn about this annoying default. I do wish that the helm chart can be upgraded to have a section under grafana that allows the ability to define the persistence layer...even if its commented out.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.

Was this page helpful?
0 / 5 - 0 ratings