Access Grafana deployed via Helm
To access Grafana on Kubernetes via Helm deployment, first run `helm get notes my-grafana -n monitoring` to get access instructions. Retrieve the admin password with `kubectl get secret --namespace monitoring my-grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo`. Export the pod name with `export POD_NAME=$(kubectl get pods --namespace monitoring -l "app.kubernetes.io/name=grafana,app.kubernetes.io/instance=my-grafana" -o jsonpath="{.items[0].metadata.name}")`. Set up port forwarding with `kubectl --namespace monitoring port-forward $POD_NAME 3000`. Then navigate to `127.0.0.1:3000` in your browser and sign in with username `admin` and the decoded password.
Enable persistent storage in Grafana Helm charts
Edit the `values.yaml` file and locate the `persistence` section. Change `enabled: false` to `enabled: true`. By default, the storage type is `pvc` (PersistentVolumeClaim). Run `helm upgrade my-grafana grafana-community/grafana -f values.yaml -n monitoring` to apply the changes. Enabling persistent storage is recommended for production environments to ensure data persists across container restarts and failures.
Install plugins via Grafana Helm charts
Edit the `values.yaml` file and find the `plugins:` section. List the plugins you want to install as array items, for example: `- alexanderzobnin-zabbix-app` and `- grafana-clock-panel`. Maintain correct indentation. Run `helm upgrade my-grafana grafana-community/grafana -f values.yaml -n monitoring` to install the plugins. Verify installation by navigating to UI -> Administration -> Plugins in the Grafana web interface.
Customize Grafana Helm chart configuration
Grafana Helm charts use a `values.yaml` file to customize configuration. The file allows you to specify values for various parameters such as image versions, resource limits, service configurations, and more. These values replace placeholders in the Kubernetes manifests. You can provide configuration values via the `values.yaml` file or in-line using Helm during install or upgrade commands. Multiple YAML files can be used if needed for different configuration changes.
Configure private CA certificate in Grafana Helm deployment
Create a ConfigMap containing the certificate with `apiVersion: v1`, `kind: ConfigMap`, and include the certificate in the `data` section under a key like `ca.pem`. Deploy it with `kubectl apply --filename grafana-ca-configmap.yaml --namespace monitoring`. In the Helm `values.yaml` file, add an `extraConfigmapMounts:` section with entries containing `name`, `mountPath` (e.g., `/etc/ssl/certs/ca.pem`), `subPath`, `configMap` (the ConfigMap name), and `readOnly: true`. Run `helm upgrade my-grafana grafana-community/grafana --values values.yaml --namespace monitoring` to apply the changes.
Check Grafana logs from Kubernetes Helm deployment
For single-container deployments, run `kubectl logs --namespace=monitoring deploy/my-grafana`. For multi-container deployments, run `kubectl logs --namespace=monitoring deploy/grafana -c my-grafana` to get logs only from the Grafana container.
Persistent storage recommendation for production
By default, Grafana Helm charts use ephemeral storage, and all data will be lost if the container is stopped, restarted, or crashes. It is highly recommended to enable persistent storage in Grafana Helm charts for production environments to ensure that dashboards, data sources, and other data persist and are not lost in case of container restarts or failures.
systemd capabilities configuration for Grafana low port binding
In the systemd override configuration file, add the following settings under [Service]: CapabilityBoundingSet=CAP_NET_BIND_SERVICE, AmbientCapabilities=CAP_NET_BIND_SERVICE, and PrivateUsers=false. The PrivateUsers=false setting is required because a private user cannot have process capabilities on the host's user namespace, making CAP_NET_BIND_SERVICE ineffective if PrivateUsers is enabled.
systemd override for Grafana on port < 1024
To start Grafana on a port lower than 1024 using systemd, you must add a systemd unit override. Run 'sudo systemctl edit grafana-server.service' to create an override file, or manually create /etc/systemd/system/grafana-server.service.d/override.conf.
Git Sync Terraform prerequisites
Before setting up Git Sync with Terraform, you need: a Grafana Cloud account or on-premises Grafana instance, Administrator permissions in your Grafana stack/instance, and Terraform 1.11 or later installed. Save all Terraform configuration files in the same directory.
Git Sync service account permissions required
The service account token used for Git Sync Terraform configuration must have either Admin permission or the 'Provisioning:Repositories' writer permission.
Git Sync Terraform provider configuration
To configure Git Sync via Terraform, create a main.tf file with the Grafana provider configuration. The provider requires: source set to 'grafana/grafana', version >= 4.28.1, url pointing to your Grafana stack (e.g., https://my-stack.grafana.net/), auth set to a service account token, and stack_id if using Grafana Cloud. Use 'url' and 'auth' parameters, not 'cloud_api_url' and 'cloud_access_policy_token' for Grafana Cloud.
Git Sync Terraform example configuration
Example Terraform configuration for Grafana provider:
terraform {
required_providers {
grafana = {
source = "grafana/grafana"
version = ">= 4.28.1"
}
}
}
provider "grafana" {
url = "https://<your-stack>.grafana.net/"
auth = var.grafana_service_account_token
stack_id = var.grafana_stack_id
}
Git Sync Terraform resources required
Two resources are needed to configure and manage Git Sync: the repository resource (grafana_apps_provisioning_repository_v0alpha1) which configures the Git repository to sync Grafana resources, and the connection resource (grafana_apps_provisioning_connection_v0alpha1) which configures Git provider credentials.