This project is no longer supported.

About the new home of helm chart

• The new home of the Zabbix helm chart is: https://github.com/zabbix-community/helm-zabbix.
• In this issue it was agreed with Sebastien Dupont that the repository would get a new home.
• We are grateful to Cetic for making the infrastructure available on CircleCI to host the helm chart from the start. Now, the new versions will be hosted on Github.
• We are very grateful to Alexandre Nuttinck and Amen Ayadi, who were the first developers of the helm chart and who worked at Cetic. Your dedication and effort made it possible to install Zabbix on a Kubernetes cluster.

Zabbix is a mature and effortless enterprise-class open source monitoring solution for network monitoring and application monitoring of millions of metrics.

This Helm chart installs Zabbix in a Kubernetes cluster.

About the Zabbix version supported

• This helm chart is compatible with non-LTS version of Zabbix, that include important changes and functionalities.
• But by default this helm chart will install the latest LTS version (example: 6.0.x). See more info in Zabbix Life Cycle & Release Policy page
• When you want use a non-LTS version (example: 6.2.x), you have to set this in values.yaml yourself.

Break change 3.0.0

• Will be used Postgresql 14.x and Zabbix 6.x.
• This version removes the possibility to specify database username/password per subsection in favor of specifying all of them centrally at one place.
• Also, the names of the values have changed from upper to lowercase.
• It is now possible to start the Zabbix Server pods with replicas of more than 1. HA functionality of Zabbix will automatically be enabled and it is made sure that the database schema publication will only happen once, and not by all of the Zabbix server pods at the same time.
• More info: #54

Break change 2.0.0

• Will be used Postgresql 14.x and Zabbix 6.x.
• This version implements a central way of managing database access credentials using a secret, which then will be respected by all the components installed by this chart: zabbixserver, zabbixweb and postgresql.
• The secret must contain a number of keys indicating DB host, DB name, user and password and can direct towards a database installed within this chart, or an external database.
• The benefit of this is that now the database can respect the values in the central DB access secret and initialize accordingly.
• Last but not least, the credential secret can be chosen to be auto-generated (password will be set to a random string) at chart installation, if postgresql.enabled is set to true. With this, an easy to use "out-of-the-box" installation with as little customizations as possible is possible, while still obtaining a good level of security.
• More info: #53

Break change 1.0.0

• Will be used Postgresql 14.x and Zabbix 6.x.
• The installation of any component of chart is optional for easy integration with the official chart: https://git.zabbix.com/projects/ZT/repos/kubernetes-helm/
• More info: #42

• Kubernetes cluster 1.10+
• Helm 3.0+
• Kubectl
• PV provisioner support in the underlying infrastructure (optional).

Install requirement kubectl and helm following the instructions this tutorial.

Zabbix server is the central process of Zabbix software.

The server performs the polling and trapping of data, it calculates triggers, sends notifications to users. It is the central component to which Zabbix agents and proxies report data on availability and integrity of systems. The server can itself remotely check networked services (such as web servers and mail servers) using simple service checks Official documentation.

Zabbix Server can be operated in a High Availability mode since version 6.0 which is automatically enabled by this Helm chart when setting the Zabbix server component to run more than 1 replica. In this HA mode, all Zabbix server instances periodically send a heartbeat to the Database server (just updating a timestamp in a table) as well as which of the nodes is the "active" one. In case the active node does not send a heartbeat within a certain time, any of the remaining ones automatically take over. It is everytime possible to join new nodes to the HA cluster by just raising the amount of replicas of the Zabbix server.

zabbix-agent2 is supported in this helm chart.

Zabbix agent is deployed on a monitoring target to actively monitor local resources and applications (hard drives, memory, processor statistics etc) Official documentation.

Zabbix web interface is a part of Zabbix software. It is used to manage resources under monitoring and view monitoring statistics Official documentation.

Zabbix web service is a process that is used for communication with external web services Official documentation.

This helm chart installs Zabbix proxy with SQLite3 support

Zabbix proxy is a process that may collect monitoring data from one or more monitored devices and send the information to the Zabbix server, essentially working on behalf of the server. All collected data is buffered locally and then transferred to the Zabbix server the proxy belongs to Official documentation.

A database is required for zabbix to work, in this helm chart we're using Postgresql 14.x.

We use plain postgresql database by default WITHOUT persistence. If you want persistence or would like to use TimescaleDB instead, check the comments in the values.yaml file.

The items of section Configuration can be set via --set flag during installation or change the values according to the need of the environment in helm-zabbix/values.yaml file.

All settings referring to how the different components that this Chart installs access the Zabbix Database (either an external, already existing database or one deployed within this Helm chart) are being configured centrally under the db_access section of the values.yaml file.

By default, this Chart will deploy it's own very simple PostgreSQL database. All settings relevant to how to access this database will be held in one central unified secret with the name configured with the db_access.unified_secret_name setting.

Instead of letting the Chart automatically generate such a secret with a random password (which will NOT be recreated on upgrade/redeploy), you can supply such a secret yourself. Use db_access.unified_secret_autocreate=false in such a case and read the comments in values.yaml for how the values inside the secret should be set.

If you want to connect your Zabbix installation to a Postgres database deployed using the CrunchyData PGO Operator, you can use the secret that PGO generates for your DB automatically directly to connect Zabbix to it, by just referring to its name with the db_access.unified_secret_name setting to it.

There is also the possibility to set all DB relevant settings directly inside the db_access section of the values.yaml file by using the settings noted there (db_server_host, postgres_user, etc). If doing so, you still can use one single secret to told just and only the database password. If you want to do so, supply the db_access.postgres_password_secret and db_access.postgres_password_secret_key settings, accordingly.

While the default database configuration shipped with this Chart is fine for most (very small, for testing only) Zabbix installations, you will want to set some specific settings to better match your setup. First of all, you should consider enabling Postgresql database persistence (postgresql.persistence.enabled), as otherwise all your changes and historical data will be gone as soon as you remove the installation of Zabbix. Additionally, you might want to tune Postgresql by supplying extra postgresql runtime parameters using the postgresql.extraRuntimeParameters dictionary:

postgresql:
  enabled: true
  persistence:
    enabled: true
    storage_size: 50Gi
  extraRuntimeParameters:
    max_connections: 250
    dynamic_shared_memory_type: posix
    shared_buffers: 4GB
    temp_buffers: 16MB
    work_mem: 128MB
    maintenance_work_mem: 256MB
    effective_cache_size: 6GB
    min_wal_size: 80MB

Alternatively, you can add your own configuration file for postgresql (using a ConfigMap and the postgresql.extraVolumes setting) to mount it into the postgresql container and referring to this config file with the postgresql.extraRuntimeParameters set to:

postgresql:
  extraRuntimeParameters:
    config.file: /path/to/your/config.file

• Ingress: The ingress controller must be installed in the Kubernetes cluster.
• IngressRoute: The custom resource definition if you use the Traefik ingress controller.
• Route: The ingress controller used by Red Hat Openshift, based on HAProxy
• ClusterIP: Exposes the service on a cluster-internal IP. Choosing this value makes the service only reachable from within the cluster.
• NodePort: Exposes the service on each Node’s IP at a static port (the NodePort). You’ll be able to contact the NodePort service, from outside the cluster, by requesting NodeIP:NodePort.
• LoadBalancer: Exposes the service externally using a cloud provider’s load balancer.

Access a Kubernetes cluster.

Add Helm repo:

helm repo add cetic https://cetic.github.io/helm-charts

Update the list helm chart available for installation (like apt-get update). This is recommend before install/upgrade a helm chart:

helm repo update

Export default values of chart helm-zabbix to file $HOME/zabbix_values.yaml:

helm show values cetic/zabbix > $HOME/zabbix_values.yaml

Change the values according to the environment in the file $HOME/zabbix_values.yaml.

See the example of installation in kind in this tutorial.

Test the installation/upgrade with command:

helm upgrade --install zabbix cetic/zabbix \
 --dependency-update \
 --create-namespace \
 -f $HOME/zabbix_values.yaml -n monitoring --debug --dry-run

Install/upgrade the Zabbix with command:

helm upgrade --install zabbix cetic/zabbix \
 --dependency-update \
 --create-namespace \
 -f $HOME/zabbix_values.yaml -n monitoring --debug

View the pods.

kubectl get pods -n monitoring

After deploying the chart in your cluster, you can use the following command to access the zabbix frontend service:

View informations of zabbix services.

kubectl describe services zabbix-web -n monitoring

Listen on port 8888 locally, forwarding to 80 in the service APPLICATION_NAME-zabbix-web. Example:

kubectl port-forward service/zabbix-zabbix-web 8888:80 -n monitoring

Access Zabbix:

• URL: http://localhost:8888
• Login: Admin
• Password: zabbix

View the pods.

kubectl get pods -n monitoring

View informations of pods.

kubectl describe pods/POD_NAME -n monitoring

View all containers of pod.

kubectl get pods POD_NAME -n monitoring -o jsonpath='{.spec.containers[*].name}*'

View the logs container of pods.

kubectl logs -f pods/POD_NAME -c CONTAINER_NAME -n monitoring

Access prompt of container.

kubectl exec -it pods/POD_NAME -c CONTAINER_NAME -n monitoring -- sh

View informations of service Zabbix.

kubectl get svc -n monitoring
kubectl get pods --output=wide -n monitoring
kubectl describe services zabbix -n monitoring

To uninstall/delete the zabbix deployment:

helm uninstall zabbix -n monitoring

Apache License 2.0

The following tables lists the configurable parameters of the chart and their default values.