Article Zabbix #12
458
blog/2025-12-26-monitoring-externe-zabbix.md
Normal file
|
|
@ -0,0 +1,458 @@
|
|||
---
|
||||
slug: monitoring-externe-zabbix
|
||||
title: "Monitoring depuis l'extérieur avec Zabbix"
|
||||
authors: [tellserv]
|
||||
tags: [zabbix, monitoring, proxmox, vps, homelab, sécurité]
|
||||
date: 2025-12-26
|
||||
---
|
||||
|
||||
Comment j'ai mis en place un système de monitoring externe avec Zabbix pour être alerté même si mon cluster Proxmox tombe complètement, en utilisant un proxy local, un serveur VPS distant et une connexion chiffrée PSK.
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## Le paradoxe du monitoring : surveiller ce qui vous surveille
|
||||
|
||||
Quand on construit un homelab, on installe rapidement un système de monitoring. C'est essentiel : ça permet de garder un œil sur l'utilisation CPU, la RAM, l'espace disque, et d'être alerté avant qu'un service ne plante.
|
||||
|
||||
J'utilisais **Beszel** jusqu'à maintenant. Un outil simple, léger, efficace. Parfait pour un homelab. Tout roule.
|
||||
|
||||
Sauf qu'il y a un problème.
|
||||
|
||||
**Si mon cluster Proxmox tombe, Beszel tombe avec lui.**
|
||||
|
||||
Et donc, mes notifications tombent aussi. Je ne serai jamais averti que mes services sont en panne, puisque le système censé me prévenir est lui-même hors service.
|
||||
|
||||
### Les scénarios problématiques
|
||||
|
||||
Voici quelques scénarios où mon monitoring actuel devient inutile :
|
||||
|
||||
- **Panne électrique** : Plus de cluster → Plus de monitoring → Pas d'alerte
|
||||
- **Crash du nœud principal** : Celui qui héberge Beszel → Silence radio
|
||||
- **Problème réseau** : Le switch meurt → Impossible de communiquer avec le monitoring
|
||||
- **Corruption du stockage** : Le Linstor DRBD qui héberge les VMs devient inaccessible → Plus rien ne fonctionne
|
||||
|
||||
Dans tous ces cas, je ne suis **jamais notifié**. Je découvre le problème des heures (ou des jours) plus tard, quand j'essaie d'accéder à un service.
|
||||
|
||||
Pour un homelab perso, c'est ennuyeux. Pour une infrastructure critique, c'est inacceptable.
|
||||
|
||||
## La solution : une approche complémentaire
|
||||
|
||||
Plutôt que de remplacer Beszel, j'ai décidé de mettre en place une **architecture complémentaire** :
|
||||
|
||||
- **Beszel reste en place** pour le monitoring en temps réel des VMs et LXCs au quotidien. C'est simple, léger, et parfait pour surveiller l'utilisation des ressources en direct.
|
||||
|
||||
- **Zabbix vient en complément** pour le monitoring global du cluster Proxmox, l'historique sur le long terme, et surtout les **alertes critiques** (comme la chute complète du cluster).
|
||||
|
||||
Cette approche combine le meilleur des deux mondes : la simplicité de Beszel pour le quotidien, et la résilience de Zabbix pour les situations critiques.
|
||||
|
||||
### Architecture offsite avec monitoring distribué
|
||||
|
||||
Pour résoudre le problème de résilience, j'ai besoin d'une architecture qui respecte trois contraintes :
|
||||
|
||||
### 1. Le serveur de monitoring doit être **ailleurs**
|
||||
|
||||
Si mon cluster tombe, le serveur de monitoring doit rester opérationnel. La solution : l'héberger sur un **VPS**, complètement indépendant de mon homelab.
|
||||
|
||||
Même si toute mon infrastructure domestique tombe, le serveur VPS continue de tourner et peut m'envoyer une alerte.
|
||||
|
||||
### 2. Pas de port ouvert sur le homelab
|
||||
|
||||
Je ne veux **pas** ouvrir de port en entrée sur mon réseau local. Cela augmente la surface d'attaque et les risques de sécurité.
|
||||
|
||||
Je veux une architecture où :
|
||||
- Le serveur central (VPS) écoute sur un port
|
||||
- Un **proxy local** (dans mon homelab) collecte les données et les **pousse** vers le serveur
|
||||
- La connexion est **initiée depuis l'intérieur** (pas d'ouverture de port NAT)
|
||||
|
||||
C'est le proxy qui contacte le serveur, pas l'inverse. Comme ça, pas besoin de VPN ni de redirection de ports.
|
||||
|
||||
### 3. Communication chiffrée
|
||||
|
||||
Les métriques de monitoring peuvent révéler des informations sensibles :
|
||||
- Combien de serveurs j'ai
|
||||
- Quels services tournent
|
||||
- Quand je suis absent (pas d'activité)
|
||||
|
||||
Je veux que la communication entre le proxy et le serveur soit **chiffrée de bout en bout**, avec une **Pre-Shared Key (PSK)** pour éviter toute interception ou usurpation d'identité.
|
||||
|
||||
## Zabbix : la solution qui coche toutes les cases
|
||||
|
||||
Après avoir évalué plusieurs solutions (Prometheus + Grafana, Netdata, InfluxDB + Telegraf), j'ai choisi **Zabbix** pour plusieurs raisons :
|
||||
|
||||
- **Architecture proxy native** : Zabbix a été conçu dès le départ pour gérer des proxies qui collectent localement et envoient au serveur central
|
||||
- **Mode actif/passif** : Le proxy peut pousser (actif) ou être interrogé (passif)
|
||||
- **Chiffrement PSK intégré** : Pas besoin d'ajouter un tunnel VPN ou un reverse proxy
|
||||
- **Template Proxmox VE** : Support natif de l'API REST de Proxmox
|
||||
- **Interface complète** : Dashboards, alertes, notifications, graphiques... tout est inclus
|
||||
- **Solution mature** : Utilisée en entreprise depuis des années, documentation abondante
|
||||
|
||||
### L'architecture finale
|
||||
|
||||
Voici à quoi ressemble mon setup :
|
||||
|
||||

|
||||
|
||||
### Le flux de données
|
||||
|
||||
1. **Le Zabbix Proxy** (LXC sur le cluster) collecte les données :
|
||||
- Il interroge l'API REST de Proxmox pour récupérer les métriques du cluster
|
||||
- Il se monitore lui-même via l'agent local (CPU, RAM, disque)
|
||||
- Il peut aussi collecter les données d'autres agents Zabbix sur le réseau
|
||||
|
||||
2. **Le Proxy pousse les données** vers le serveur VPS :
|
||||
- Connexion HTTPS sortante (pas de port ouvert en entrée)
|
||||
- Chiffrement TLS avec Pre-Shared Key (PSK)
|
||||
- Mode "Active" : le proxy contacte le serveur, pas l'inverse
|
||||
|
||||
3. **Le Zabbix Server** (VPS) :
|
||||
- Reçoit et stocke les métriques dans PostgreSQL
|
||||
- Déclenche les alertes si un seuil est franchi
|
||||
- Expose l'interface web via Cloudflare Tunnel
|
||||
|
||||
## Mise en place : du VPS au monitoring complet
|
||||
|
||||
### Étape 1 : Zabbix Server sur le VPS
|
||||
|
||||
J'ai déployé Zabbix via Docker Compose sur mon VPS. Voici le fichier `compose.yaml` :
|
||||
|
||||
```yaml
|
||||
services:
|
||||
zabbix-db:
|
||||
image: postgres:16-alpine
|
||||
container_name: zabbix-db
|
||||
restart: always
|
||||
volumes:
|
||||
- ./zbx_db_data:/var/lib/postgresql/data
|
||||
env_file: .env
|
||||
networks:
|
||||
- zabbix-tier
|
||||
|
||||
zabbix-server:
|
||||
image: zabbix/zabbix-server-pgsql:7.0-alpine-latest
|
||||
container_name: zabbix-server
|
||||
restart: always
|
||||
depends_on:
|
||||
- zabbix-db
|
||||
env_file: .env
|
||||
ports:
|
||||
- "10051:10051"
|
||||
networks:
|
||||
- zabbix-tier
|
||||
- public-tier
|
||||
|
||||
zabbix-web:
|
||||
image: zabbix/zabbix-web-nginx-pgsql:7.0-alpine-latest
|
||||
container_name: zabbix-web
|
||||
restart: always
|
||||
depends_on:
|
||||
- zabbix-db
|
||||
- zabbix-server
|
||||
env_file: .env
|
||||
networks:
|
||||
- zabbix-tier
|
||||
- public-tier
|
||||
|
||||
tunnel:
|
||||
image: cloudflare/cloudflared:latest
|
||||
container_name: cloudflare-tunnel
|
||||
restart: always
|
||||
command: tunnel run
|
||||
env_file: .env
|
||||
networks:
|
||||
- public-tier
|
||||
|
||||
networks:
|
||||
zabbix-tier:
|
||||
internal: true
|
||||
public-tier:
|
||||
driver: bridge
|
||||
```
|
||||
|
||||
Et le fichier `.env` correspondant :
|
||||
|
||||
```bash
|
||||
# --- Configuration Base de données ---
|
||||
POSTGRES_USER=zabbix
|
||||
POSTGRES_PASSWORD=REPLACEME
|
||||
POSTGRES_DB=zabbix
|
||||
|
||||
# --- Configuration Zabbix Server ---
|
||||
DB_SERVER_HOST=zabbix-db
|
||||
ZBX_POSTGRES_USER=zabbix
|
||||
ZBX_POSTGRES_PASSWORD=REPLACEME
|
||||
|
||||
# --- Configuration Zabbix Web ---
|
||||
ZBX_DBHOST=zabbix-db
|
||||
ZBX_SERVER_HOST=zabbix-server
|
||||
PHP_TZ=Europe/Paris
|
||||
|
||||
# Clé Cloudflare
|
||||
TUNNEL_TOKEN="REPLACEME"
|
||||
```
|
||||
|
||||
:::tip[Génération d'un mot de passe fort]
|
||||
Pour générer un mot de passe fort et sécurisé pour votre base de données PostgreSQL, vous pouvez utiliser la commande OpenSSL suivante :
|
||||
|
||||
```bash
|
||||
openssl rand -base64 32
|
||||
```
|
||||
|
||||
Cette commande génère une chaîne aléatoire de 32 octets encodée en base64, ce qui produit un mot de passe de ~44 caractères extrêmement robuste. Remplacez ensuite les valeurs `REPLACEME` dans le fichier `.env` par ce mot de passe généré.
|
||||
:::
|
||||
|
||||
**Points importants** :
|
||||
- Le réseau `zabbix-tier` est **internal** : la base de données n'est pas accessible depuis l'extérieur
|
||||
- Le serveur Zabbix expose le port **10051** pour recevoir les données des proxies
|
||||
- L'interface web est accessible uniquement via **Cloudflare Tunnel** (pas d'IP publique exposée)
|
||||
|
||||
**Déploiement** :
|
||||
|
||||
```bash
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
Après quelques secondes, l'interface Zabbix est accessible. Connexion par défaut : `Admin` / `zabbix` (à changer immédiatement !).
|
||||
|
||||
### Étape 2 : Zabbix Proxy dans un LXC
|
||||
|
||||
J'ai créé un conteneur LXC Debian 13 sur le cluster Proxmox pour héberger le proxy.
|
||||
|
||||
**Configuration du LXC** :
|
||||
- CPU : 1 vCore
|
||||
- RAM : 512 MB
|
||||
- Disque : 4 GB
|
||||
- IP statique
|
||||
|
||||
**Installation complète** :
|
||||
|
||||
```bash
|
||||
# Mise à jour
|
||||
apt update && apt upgrade -y
|
||||
|
||||
# Ajout du dépôt Zabbix 7.4
|
||||
wget https://repo.zabbix.com/zabbix/7.4/debian/pool/main/z/zabbix-release/zabbix-release_7.4-1+debian13_all.deb
|
||||
dpkg -i zabbix-release_7.4-1+debian13_all.deb
|
||||
apt update
|
||||
|
||||
# Installation du proxy et de l'agent
|
||||
apt install zabbix-proxy-sqlite3 zabbix-agent2 -y
|
||||
|
||||
# Création de la base SQLite
|
||||
mkdir -p /var/lib/zabbix
|
||||
chown zabbix:zabbix /var/lib/zabbix
|
||||
zcat -f /usr/share/zabbix-proxy-sqlite3/schema.sql.gz | sqlite3 /var/lib/zabbix/zabbix_proxy.db
|
||||
chown zabbix:zabbix /var/lib/zabbix/zabbix_proxy.db
|
||||
chmod 660 /var/lib/zabbix/zabbix_proxy.db
|
||||
|
||||
# Génération de la clé PSK
|
||||
openssl rand -hex 32 | tee /etc/zabbix/zabbix_proxy.psk
|
||||
chown zabbix:zabbix /etc/zabbix/zabbix_proxy.psk
|
||||
chmod 600 /etc/zabbix/zabbix_proxy.psk
|
||||
|
||||
# Créer le répertoire de logs
|
||||
mkdir -p /var/log/zabbix-proxy
|
||||
chown zabbix:zabbix /var/log/zabbix-proxy
|
||||
```
|
||||
|
||||
**Configuration du proxy** (`/etc/zabbix/zabbix_proxy.conf`) :
|
||||
|
||||
Les paramètres essentiels :
|
||||
|
||||
```ini
|
||||
# Adresse du serveur Zabbix VPS
|
||||
Server=<IP_DE_VOTRE_VPS>
|
||||
ServerPort=10051
|
||||
|
||||
# Nom du proxy (doit correspondre à la config serveur)
|
||||
Hostname=Proxy-Homelab
|
||||
|
||||
# Base de données SQLite
|
||||
DBName=/var/lib/zabbix/zabbix_proxy.db
|
||||
DBUser=zabbix
|
||||
|
||||
# Fichiers
|
||||
LogFile=/var/log/zabbix-proxy/zabbix_proxy.log
|
||||
PidFile=/run/zabbix/zabbix_proxy.pid
|
||||
|
||||
# Optimisations LXC
|
||||
ProxyBufferMode=hybrid
|
||||
ProxyMemoryBufferSize=16M
|
||||
|
||||
# Sécurité PSK
|
||||
TLSConnect=psk
|
||||
TLSPSKIdentity=PSK-PROXY-HOME
|
||||
TLSPSKFile=/etc/zabbix/zabbix_proxy.psk
|
||||
```
|
||||
|
||||
**Configuration de l'agent** (`/etc/zabbix/zabbix_agent2.conf`) :
|
||||
|
||||
```ini
|
||||
# Le proxy est en local
|
||||
Server=127.0.0.1
|
||||
ServerActive=127.0.0.1
|
||||
Hostname=Proxy-Homelab
|
||||
|
||||
# Fichiers
|
||||
PidFile=/run/zabbix/zabbix_agent2.pid
|
||||
LogFile=/var/log/zabbix/zabbix_agent2.log
|
||||
ControlSocket=/run/zabbix/agent.sock
|
||||
```
|
||||
|
||||
**Démarrage** :
|
||||
|
||||
```bash
|
||||
systemctl enable zabbix-proxy zabbix-agent2
|
||||
systemctl start zabbix-proxy zabbix-agent2
|
||||
```
|
||||
|
||||
### Étape 3 : Déclaration du proxy sur le serveur
|
||||
|
||||
Dans l'interface Zabbix, je vais dans **Administration → Proxies** → **Create proxy**.
|
||||
|
||||
**Configuration** :
|
||||
- **Proxy name** : `Proxy-Homelab` (identique au `Hostname` du fichier de config)
|
||||
- **Proxy mode** : `Active` (le proxy contacte le serveur)
|
||||
- **Proxy address** : laisser vide
|
||||
|
||||

|
||||
|
||||
**Onglet Chiffrement** :
|
||||
- **Connexion au proxy** : sélectionner `PSK`
|
||||
- **Connexions du proxy** : cocher `PSK`
|
||||
- **PSK identity** : `PSK-PROXY-HOME`
|
||||
- **PSK** : copier le contenu de `/etc/zabbix/zabbix_proxy.psk` depuis le LXC
|
||||
|
||||

|
||||
|
||||
Après quelques secondes, le proxy apparaît comme **connecté**. La magie opère !
|
||||
|
||||
### Étape 4 : Monitoring du proxy lui-même
|
||||
|
||||
Le proxy est connecté, mais il n'est pas encore monitoré. Je crée un nouvel hôte dans Zabbix :
|
||||
|
||||
**Configuration → Hosts → Create host** :
|
||||
- **Host name** : `Proxy-Homelab`
|
||||
- **Groups** : `Linux servers`
|
||||
- **Monitored by proxy** : `Proxy-Homelab`
|
||||
- **Interface** : Agent → DNS `127.0.0.1` port `10050`
|
||||
- **Templates** : lier `Linux by Zabbix agent`
|
||||
|
||||

|
||||
|
||||
Quelques minutes plus tard, les premières métriques arrivent : CPU, RAM, disque, réseau... Le proxy se monitore lui-même !
|
||||
|
||||
### Étape 5 : Monitoring du cluster Proxmox
|
||||
|
||||
La dernière étape : monitorer Proxmox via son API REST.
|
||||
|
||||
#### Création de l'utilisateur et du token dans Proxmox
|
||||
|
||||
**Datacenter → Permissions → Users → Add** :
|
||||
- **User name** : `zabbix-monitor@pam`
|
||||
- **Expire** : `never`
|
||||
- **Enabled** : coché
|
||||
|
||||

|
||||
|
||||
**Datacenter → Permissions → API Tokens → Add** :
|
||||
- **User** : `zabbix-monitor@pam`
|
||||
- **Token ID** : `zabbix`
|
||||
- **Privilege Separation** : coché
|
||||
- **Expire** : `never`
|
||||
|
||||
**Copier le Token Secret** (il ne sera plus affiché après).
|
||||
|
||||

|
||||
|
||||
#### Attribution des permissions
|
||||
|
||||
**Datacenter → Permissions → Add → User permission** :
|
||||
|
||||
Deux entrées à créer :
|
||||
|
||||
| Path | User/API Token | Role | Propagate |
|
||||
|------|---------------|------|-----------|
|
||||
| `/` | `zabbix-monitor@pam` | `PVEAuditor` | ✓ |
|
||||
| `/` | `zabbix-monitor@pam!zabbix` | `PVEAuditor` | ✓ |
|
||||
|
||||
Le rôle **PVEAuditor** permet la lecture seule de toutes les métriques, sans aucun droit de modification.
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
#### Ajout de l'hôte Proxmox dans Zabbix
|
||||
|
||||
**Configuration → Hosts → Create host** :
|
||||
- **Host name** : `Proxmox-Cluster`
|
||||
- **Groups** : `Hypervisors`
|
||||
- **Monitored by proxy** : `Proxy-Homelab`
|
||||
- **Templates** : lier `Proxmox VE by HTTP`
|
||||
|
||||

|
||||
|
||||
**Onglet Macros** :
|
||||
|
||||
| Macro | Valeur |
|
||||
|-------|--------|
|
||||
| `{$PVE.URL.HOST}` | `192.168.100.10` (IP de votre nœud Proxmox) |
|
||||
| `{$PVE.TOKEN.ID}` | `zabbix-monitor@pam!zabbix` |
|
||||
| `{$PVE.TOKEN.SECRET}` | Le token secret copié précédemment |
|
||||
|
||||

|
||||
|
||||
**Quelques minutes plus tard** : toutes les métriques Proxmox arrivent ! CPU, RAM, stockage, nombre de VMs, nombre de LXCs, état du cluster...
|
||||
|
||||
## Résultat : un monitoring qui survit à tout
|
||||
|
||||
J'ai maintenant une infrastructure de monitoring résiliente :
|
||||
|
||||
- **Le serveur Zabbix tourne sur un VPS** : même si tout mon homelab brûle, le monitoring reste actif
|
||||
- **Le proxy local collecte les données** : il interroge Proxmox, se monitore lui-même, et pousse tout au serveur
|
||||
- **Connexion chiffrée PSK** : impossible d'intercepter ou d'usurper les communications
|
||||
- **Pas de port ouvert** : le proxy initie la connexion sortante, aucune ouverture NAT nécessaire
|
||||
- **Accessible via Cloudflare Tunnel** : pas d'IP publique exposée, accès sécurisé à l'interface web
|
||||
|
||||
### Les avantages concrets
|
||||
|
||||
**Résilience** :
|
||||
- Si le cluster tombe → Le serveur VPS m'alerte immédiatement
|
||||
- Si le VPS tombe → Le proxy continue de collecter et renvoie les données dès le retour du serveur
|
||||
- Si le réseau homelab tombe → Le serveur VPS détecte l'absence de données et m'alerte
|
||||
|
||||
**Sécurité** :
|
||||
- Pas de port ouvert en entrée sur le homelab
|
||||
- Chiffrement TLS/PSK de bout en bout
|
||||
- Accès en lecture seule à l'API Proxmox (PVEAuditor)
|
||||
- Interface web accessible uniquement via Cloudflare Tunnel
|
||||
|
||||
**Simplicité** :
|
||||
- Installation Docker Compose pour le serveur (3 commandes)
|
||||
- Installation LXC légère pour le proxy
|
||||
- Template Proxmox prêt à l'emploi dans Zabbix
|
||||
- Pas de VPN ni de configuration réseau complexe
|
||||
|
||||
## Prochaines étapes
|
||||
|
||||
Maintenant que le monitoring est en place, je peux :
|
||||
|
||||
- Configurer des **alertes personnalisées** (CPU > 80%, RAM > 90%, etc.)
|
||||
- Mettre en place des **notifications** (Discord, Gotify...)
|
||||
- Ajouter d'autres **agents Zabbix** sur mes VMs et LXCs
|
||||
- Créer des **dashboards personnalisés** pour avoir une vue d'ensemble
|
||||
- Monitorer d'autres services (bases de données, serveurs web, etc.)
|
||||
|
||||
Si mon cluster tombe en panne, je reçois maintenant une notification immédiate au lieu de découvrir le problème plusieurs heures plus tard.
|
||||
|
||||
## Conclusion
|
||||
|
||||
Avec cette architecture complémentaire, je bénéficie maintenant du meilleur des deux mondes :
|
||||
|
||||
- **Beszel** pour le monitoring quotidien, simple et efficace, avec une vue en temps réel sur mes VMs et LXCs
|
||||
- **Zabbix** pour le monitoring global du cluster, l'historique sur le long terme, et les alertes critiques qui fonctionnent même si tout mon homelab tombe
|
||||
|
||||
Cette approche me permet de garder la simplicité de Beszel au quotidien tout en ayant la résilience d'un monitoring offsite pour les situations critiques.
|
||||
|
||||

|
||||
|
||||
Si vous avez un homelab, mettre en place un monitoring offsite peut être une bonne solution pour détecter rapidement les problèmes, même en cas de panne complète de votre infrastructure locale.
|
||||
|
|
@ -0,0 +1,460 @@
|
|||
---
|
||||
slug: monitoring-externe-zabbix
|
||||
title: "External Monitoring with Zabbix"
|
||||
authors: [tellserv]
|
||||
tags: [zabbix, monitoring, proxmox, vps, homelab, security]
|
||||
date: 2025-12-26
|
||||
---
|
||||
|
||||
How I set up an external monitoring system with Zabbix to be alerted even if my Proxmox cluster goes down completely, using a local proxy, a remote VPS server, and a PSK encrypted connection.
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## The monitoring paradox: monitoring the monitor
|
||||
|
||||
When building a homelab, you quickly install a monitoring system. It's essential: it lets you keep an eye on CPU usage, RAM, disk space, and get alerted before a service crashes.
|
||||
|
||||
I was using **Beszel** until now. A simple, lightweight, efficient tool. Perfect for a homelab. Everything works great.
|
||||
|
||||
Except there's a problem.
|
||||
|
||||
**If my Proxmox cluster goes down, Beszel goes down with it.**
|
||||
|
||||
And therefore, my notifications go down too. I'll never be notified that my services are down, since the system supposed to warn me is itself out of service.
|
||||
|
||||
### Problematic scenarios
|
||||
|
||||
Here are some scenarios where my current monitoring becomes useless:
|
||||
|
||||
- **Power outage**: No cluster → No monitoring → No alert
|
||||
- **Main node crash**: The one hosting Beszel → Radio silence
|
||||
- **Network issue**: The switch dies → Unable to communicate with monitoring
|
||||
- **Storage corruption**: Linstor DRBD hosting the VMs becomes inaccessible → Nothing works
|
||||
|
||||
In all these cases, I'm **never notified**. I discover the problem hours (or days) later when I try to access a service.
|
||||
|
||||
For a personal homelab, it's annoying. For critical infrastructure, it's unacceptable.
|
||||
|
||||
## The solution: a complementary approach
|
||||
|
||||
Rather than replacing Beszel, I decided to implement a **complementary architecture**:
|
||||
|
||||
- **Beszel stays in place** for real-time monitoring of VMs and LXCs on a daily basis. It's simple, lightweight, and perfect for monitoring resource usage in real-time.
|
||||
|
||||
- **Zabbix complements it** for global Proxmox cluster monitoring, long-term history, and especially **critical alerts** (like complete cluster failure).
|
||||
|
||||
This approach combines the best of both worlds: Beszel's simplicity for daily use, and Zabbix's resilience for critical situations.
|
||||
|
||||
### Offsite architecture with distributed monitoring
|
||||
|
||||
To solve the resilience problem, I need an architecture that respects three constraints:
|
||||
|
||||
### 1. The monitoring server must be **elsewhere**
|
||||
|
||||
If my cluster goes down, the monitoring server must remain operational. The solution: host it on a **VPS**, completely independent from my homelab.
|
||||
|
||||
Even if all my home infrastructure goes down, the VPS server continues to run and can send me an alert.
|
||||
|
||||
### 2. No open ports on the homelab
|
||||
|
||||
I **don't** want to open inbound ports on my local network. This increases the attack surface and security risks.
|
||||
|
||||
I want an architecture where:
|
||||
- The central server (VPS) listens on a port
|
||||
- A **local proxy** (in my homelab) collects data and **pushes** it to the server
|
||||
- The connection is **initiated from inside** (no NAT port opening)
|
||||
|
||||
The proxy contacts the server, not the other way around. This way, no need for VPN or port forwarding.
|
||||
|
||||
### 3. Encrypted communication
|
||||
|
||||
Monitoring metrics can reveal sensitive information:
|
||||
- How many servers I have
|
||||
- Which services are running
|
||||
- When I'm away (no activity)
|
||||
|
||||
I want communication between the proxy and server to be **end-to-end encrypted**, with a **Pre-Shared Key (PSK)** to prevent any interception or identity spoofing.
|
||||
|
||||
## Zabbix: the solution that checks all boxes
|
||||
|
||||
After evaluating several solutions (Prometheus + Grafana, Netdata, InfluxDB + Telegraf), I chose **Zabbix** for several reasons:
|
||||
|
||||
- **Native proxy architecture**: Zabbix was designed from the start to handle proxies that collect locally and send to the central server
|
||||
- **Active/passive mode**: The proxy can push (active) or be queried (passive)
|
||||
- **Integrated PSK encryption**: No need to add a VPN tunnel or reverse proxy
|
||||
- **Proxmox VE template**: Native support for Proxmox REST API
|
||||
- **Complete interface**: Dashboards, alerts, notifications, graphs... everything is included
|
||||
- **Mature solution**: Used in enterprises for years, abundant documentation
|
||||
|
||||
### Final architecture
|
||||
|
||||
Here's what my setup looks like:
|
||||
|
||||

|
||||
|
||||
### Data flow
|
||||
|
||||
1. **The Zabbix Proxy** (LXC on the cluster) collects data:
|
||||
- It queries Proxmox's REST API to retrieve cluster metrics
|
||||
- It monitors itself via the local agent (CPU, RAM, disk)
|
||||
- It can also collect data from other Zabbix agents on the network
|
||||
|
||||
2. **The Proxy pushes data** to the VPS server:
|
||||
- Outbound HTTPS connection (no inbound port opening)
|
||||
- TLS encryption with Pre-Shared Key (PSK)
|
||||
- "Active" mode: the proxy contacts the server, not the other way around
|
||||
|
||||
3. **The Zabbix Server** (VPS):
|
||||
- Receives and stores metrics in PostgreSQL
|
||||
- Triggers alerts if a threshold is exceeded
|
||||
- Exposes the web interface via Cloudflare Tunnel
|
||||
|
||||
## Implementation: from VPS to complete monitoring
|
||||
|
||||
### Step 1: Zabbix Server on VPS
|
||||
|
||||
I deployed Zabbix via Docker Compose on my VPS. Here's the `compose.yaml` file:
|
||||
|
||||
```yaml
|
||||
services:
|
||||
zabbix-db:
|
||||
image: postgres:16-alpine
|
||||
container_name: zabbix-db
|
||||
restart: always
|
||||
volumes:
|
||||
- ./zbx_db_data:/var/lib/postgresql/data
|
||||
env_file: .env
|
||||
networks:
|
||||
- zabbix-tier
|
||||
|
||||
zabbix-server:
|
||||
image: zabbix/zabbix-server-pgsql:7.0-alpine-latest
|
||||
container_name: zabbix-server
|
||||
restart: always
|
||||
depends_on:
|
||||
- zabbix-db
|
||||
env_file: .env
|
||||
ports:
|
||||
- "10051:10051"
|
||||
networks:
|
||||
- zabbix-tier
|
||||
- public-tier
|
||||
|
||||
zabbix-web:
|
||||
image: zabbix/zabbix-web-nginx-pgsql:7.0-alpine-latest
|
||||
container_name: zabbix-web
|
||||
restart: always
|
||||
depends_on:
|
||||
- zabbix-db
|
||||
- zabbix-server
|
||||
env_file: .env
|
||||
networks:
|
||||
- zabbix-tier
|
||||
- public-tier
|
||||
|
||||
tunnel:
|
||||
image: cloudflare/cloudflared:latest
|
||||
container_name: cloudflare-tunnel
|
||||
restart: always
|
||||
command: tunnel run
|
||||
env_file: .env
|
||||
networks:
|
||||
- public-tier
|
||||
|
||||
networks:
|
||||
zabbix-tier:
|
||||
internal: true
|
||||
public-tier:
|
||||
driver: bridge
|
||||
```
|
||||
|
||||
And the corresponding `.env` file:
|
||||
|
||||
```bash
|
||||
# --- Database Configuration ---
|
||||
POSTGRES_USER=zabbix
|
||||
POSTGRES_PASSWORD=REPLACEME
|
||||
POSTGRES_DB=zabbix
|
||||
|
||||
# --- Zabbix Server Configuration ---
|
||||
DB_SERVER_HOST=zabbix-db
|
||||
ZBX_POSTGRES_USER=zabbix
|
||||
ZBX_POSTGRES_PASSWORD=REPLACEME
|
||||
|
||||
# --- Zabbix Web Configuration ---
|
||||
ZBX_DBHOST=zabbix-db
|
||||
ZBX_SERVER_HOST=zabbix-server
|
||||
PHP_TZ=Europe/Paris
|
||||
|
||||
# Cloudflare Key
|
||||
TUNNEL_TOKEN="REPLACEME"
|
||||
```
|
||||
|
||||
:::tip[Generating a strong password]
|
||||
To generate a strong and secure password for your PostgreSQL database, you can use the following OpenSSL command:
|
||||
|
||||
```bash
|
||||
openssl rand -base64 32
|
||||
```
|
||||
|
||||
This command generates a random 32-byte string encoded in base64, producing an extremely robust ~44 character password. Then replace the `REPLACEME` values in the `.env` file with this generated password.
|
||||
:::
|
||||
|
||||
**Important points**:
|
||||
- The `zabbix-tier` network is **internal**: the database is not accessible from outside
|
||||
- The Zabbix server exposes port **10051** to receive data from proxies
|
||||
- The web interface is accessible only via **Cloudflare Tunnel** (no exposed public IP)
|
||||
|
||||
**Deployment**:
|
||||
|
||||
```bash
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
After a few seconds, the Zabbix interface is accessible. Default login: `Admin` / `zabbix` (change immediately!).
|
||||
|
||||
### Step 2: Zabbix Proxy in LXC
|
||||
|
||||
I created a Debian 13 LXC container on the Proxmox cluster to host the proxy.
|
||||
|
||||
**LXC configuration**:
|
||||
- CPU: 1 vCore
|
||||
- RAM: 512 MB
|
||||
- Disk: 4 GB
|
||||
- Static IP
|
||||
|
||||
**Complete installation**:
|
||||
|
||||
```bash
|
||||
# Update
|
||||
apt update && apt upgrade -y
|
||||
|
||||
# Add Zabbix 7.4 repository
|
||||
wget https://repo.zabbix.com/zabbix/7.4/debian/pool/main/z/zabbix-release/zabbix-release_7.4-1+debian13_all.deb
|
||||
dpkg -i zabbix-release_7.4-1+debian13_all.deb
|
||||
apt update
|
||||
|
||||
# Install proxy and agent
|
||||
apt install zabbix-proxy-sqlite3 zabbix-agent2 -y
|
||||
|
||||
# Create SQLite database
|
||||
mkdir -p /var/lib/zabbix
|
||||
chown zabbix:zabbix /var/lib/zabbix
|
||||
zcat -f /usr/share/zabbix-proxy-sqlite3/schema.sql.gz | sqlite3 /var/lib/zabbix/zabbix_proxy.db
|
||||
chown zabbix:zabbix /var/lib/zabbix/zabbix_proxy.db
|
||||
chmod 660 /var/lib/zabbix/zabbix_proxy.db
|
||||
|
||||
# Generate PSK key
|
||||
openssl rand -hex 32 | tee /etc/zabbix/zabbix_proxy.psk
|
||||
chown zabbix:zabbix /etc/zabbix/zabbix_proxy.psk
|
||||
chmod 600 /etc/zabbix/zabbix_proxy.psk
|
||||
|
||||
# Create log directory
|
||||
mkdir -p /var/log/zabbix-proxy
|
||||
chown zabbix:zabbix /var/log/zabbix-proxy
|
||||
```
|
||||
|
||||
**Proxy configuration** (`/etc/zabbix/zabbix_proxy.conf`):
|
||||
|
||||
Essential parameters:
|
||||
|
||||
```ini
|
||||
# VPS Zabbix server address
|
||||
Server=<YOUR_VPS_IP>
|
||||
ServerPort=10051
|
||||
|
||||
# Proxy name (must match server config)
|
||||
Hostname=Proxy-Homelab
|
||||
|
||||
# SQLite database
|
||||
DBName=/var/lib/zabbix/zabbix_proxy.db
|
||||
DBUser=zabbix
|
||||
|
||||
# Files
|
||||
LogFile=/var/log/zabbix-proxy/zabbix_proxy.log
|
||||
PidFile=/run/zabbix/zabbix_proxy.pid
|
||||
|
||||
# LXC optimizations
|
||||
ProxyBufferMode=hybrid
|
||||
ProxyMemoryBufferSize=16M
|
||||
|
||||
# PSK security
|
||||
TLSConnect=psk
|
||||
TLSPSKIdentity=PSK-PROXY-HOME
|
||||
TLSPSKFile=/etc/zabbix/zabbix_proxy.psk
|
||||
```
|
||||
|
||||
**Agent configuration** (`/etc/zabbix/zabbix_agent2.conf`):
|
||||
|
||||
```ini
|
||||
# Proxy is local
|
||||
Server=127.0.0.1
|
||||
ServerActive=127.0.0.1
|
||||
Hostname=Proxy-Homelab
|
||||
|
||||
# Files
|
||||
PidFile=/run/zabbix/zabbix_agent2.pid
|
||||
LogFile=/var/log/zabbix/zabbix_agent2.log
|
||||
ControlSocket=/run/zabbix/agent.sock
|
||||
```
|
||||
|
||||
**Startup**:
|
||||
|
||||
```bash
|
||||
systemctl enable zabbix-proxy zabbix-agent2
|
||||
systemctl start zabbix-proxy zabbix-agent2
|
||||
```
|
||||
|
||||
### Step 3: Proxy declaration on server
|
||||
|
||||
In the Zabbix interface, go to **Administration → Proxies** → **Create proxy**.
|
||||
|
||||
**Configuration**:
|
||||
- **Proxy name**: `Proxy-Homelab` (identical to the `Hostname` in the config file)
|
||||
- **Proxy mode**: `Active` (proxy contacts the server)
|
||||
- **Proxy address**: leave empty
|
||||
|
||||

|
||||
|
||||
**Encryption tab**:
|
||||
- **Connection to proxy**: select `PSK`
|
||||
- **Connections from proxy**: check `PSK`
|
||||
- **PSK identity**: `PSK-PROXY-HOME`
|
||||
- **PSK**: copy the content of `/etc/zabbix/zabbix_proxy.psk` from the LXC
|
||||
|
||||

|
||||
|
||||
After a few seconds, the proxy appears as **connected**. Magic happens!
|
||||
|
||||
### Step 4: Monitoring the proxy itself
|
||||
|
||||
The proxy is connected, but not yet monitored. I create a new host in Zabbix:
|
||||
|
||||
**Configuration → Hosts → Create host**:
|
||||
- **Host name**: `Proxy-Homelab`
|
||||
- **Groups**: `Linux servers`
|
||||
- **Monitored by proxy**: `Proxy-Homelab`
|
||||
- **Interface**: Agent → DNS `127.0.0.1` port `10050`
|
||||
- **Templates**: link `Linux by Zabbix agent`
|
||||
|
||||

|
||||
|
||||
A few minutes later, the first metrics arrive: CPU, RAM, disk, network... The proxy monitors itself!
|
||||
|
||||
### Step 5: Monitoring the Proxmox cluster
|
||||
|
||||
The final step: monitoring Proxmox via its REST API.
|
||||
|
||||
#### Creating user and token in Proxmox
|
||||
|
||||
**Datacenter → Permissions → Users → Add**:
|
||||
- **User name**: `zabbix-monitor@pam`
|
||||
- **Expire**: `never`
|
||||
- **Enabled**: checked
|
||||
|
||||

|
||||
|
||||
**Datacenter → Permissions → API Tokens → Add**:
|
||||
- **User**: `zabbix-monitor@pam`
|
||||
- **Token ID**: `zabbix`
|
||||
- **Privilege Separation**: checked
|
||||
- **Expire**: `never`
|
||||
|
||||
**Copy the Token Secret** (it won't be shown again).
|
||||
|
||||

|
||||
|
||||
#### Assigning permissions
|
||||
|
||||
**Datacenter → Permissions → Add → User permission**:
|
||||
|
||||
Two entries to create:
|
||||
|
||||
| Path | User/API Token | Role | Propagate |
|
||||
|------|---------------|------|-----------|
|
||||
| `/` | `zabbix-monitor@pam` | `PVEAuditor` | ✓ |
|
||||
| `/` | `zabbix-monitor@pam!zabbix` | `PVEAuditor` | ✓ |
|
||||
|
||||
The **PVEAuditor** role allows read-only access to all metrics, without any modification rights.
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
#### Adding Proxmox host in Zabbix
|
||||
|
||||
**Configuration → Hosts → Create host**:
|
||||
- **Host name**: `Proxmox-Cluster`
|
||||
- **Groups**: `Hypervisors`
|
||||
- **Monitored by proxy**: `Proxy-Homelab`
|
||||
- **Templates**: link `Proxmox VE by HTTP`
|
||||
|
||||

|
||||
|
||||
**Macros tab**:
|
||||
|
||||
| Macro | Value |
|
||||
|-------|--------|
|
||||
| `{$PVE.URL.HOST}` | `192.168.100.10` (your Proxmox node IP) |
|
||||
| `{$PVE.TOKEN.ID}` | `zabbix-monitor@pam!zabbix` |
|
||||
| `{$PVE.TOKEN.SECRET}` | The token secret copied previously |
|
||||
|
||||

|
||||
|
||||
**A few minutes later**: all Proxmox metrics arrive! CPU, RAM, storage, number of VMs, number of LXCs, cluster status...
|
||||
|
||||
## Result: monitoring that survives everything
|
||||
|
||||
I now have a resilient monitoring infrastructure:
|
||||
|
||||
- **Zabbix server runs on VPS**: even if my entire homelab burns down, monitoring stays active
|
||||
- **Local proxy collects data**: it queries Proxmox, monitors itself, and pushes everything to the server
|
||||
- **PSK encrypted connection**: impossible to intercept or spoof communications
|
||||
- **No open ports**: proxy initiates outbound connection, no NAT opening needed
|
||||
- **Accessible via Cloudflare Tunnel**: no exposed public IP, secure web interface access
|
||||
|
||||
### Concrete advantages
|
||||
|
||||
**Resilience**:
|
||||
- If cluster goes down → VPS server alerts me immediately
|
||||
- If VPS goes down → Proxy continues collecting and resends data when server returns
|
||||
- If homelab network goes down → VPS server detects absence of data and alerts me
|
||||
|
||||
**Security**:
|
||||
- No inbound ports open on homelab
|
||||
- End-to-end TLS/PSK encryption
|
||||
- Read-only access to Proxmox API (PVEAuditor)
|
||||
- Web interface accessible only via Cloudflare Tunnel
|
||||
|
||||
**Simplicity**:
|
||||
- Docker Compose installation for server (3 commands)
|
||||
- Lightweight LXC installation for proxy
|
||||
- Ready-to-use Proxmox template in Zabbix
|
||||
- No VPN or complex network configuration
|
||||
|
||||
## Next steps
|
||||
|
||||
Now that monitoring is in place, I can:
|
||||
|
||||
- Configure **custom alerts** (CPU > 80%, RAM > 90%, etc.)
|
||||
- Set up **notifications** (email, Telegram, Discord...)
|
||||
- Add other **Zabbix agents** on my VMs and LXCs
|
||||
- Create **custom dashboards** for an overview
|
||||
- Monitor other services (databases, web servers, etc.)
|
||||
|
||||
If my cluster goes down, I now receive an immediate notification instead of discovering the problem several hours later.
|
||||
|
||||
## Conclusion
|
||||
|
||||
With this complementary architecture, I now benefit from the best of both worlds:
|
||||
|
||||
- **Beszel** for daily monitoring, simple and efficient, with real-time view of my VMs and LXCs
|
||||
- **Zabbix** for global cluster monitoring, long-term history, and critical alerts that work even if my entire homelab goes down
|
||||
|
||||
This approach allows me to keep Beszel's simplicity for daily use while having offsite monitoring resilience for critical situations.
|
||||
|
||||

|
||||
|
||||
If you have a homelab, setting up offsite monitoring can be a good solution to quickly detect problems, even in case of complete failure of your local infrastructure.
|
||||
|
||||
How do you manage monitoring of your infrastructure? Feel free to share your solutions in the comments!
|
||||
|
After Width: | Height: | Size: 546 KiB |
|
After Width: | Height: | Size: 6.7 KiB |
|
After Width: | Height: | Size: 27 KiB |
|
After Width: | Height: | Size: 8.7 KiB |
|
After Width: | Height: | Size: 5.9 KiB |
|
After Width: | Height: | Size: 22 KiB |
|
After Width: | Height: | Size: 24 KiB |
|
|
@ -0,0 +1,17 @@
|
|||
# --- Configuration Base de données ---
|
||||
POSTGRES_USER=zabbix
|
||||
POSTGRES_PASSWORD=REPLACEME
|
||||
POSTGRES_DB=zabbix
|
||||
|
||||
# --- Configuration Zabbix Server ---
|
||||
DB_SERVER_HOST=zabbix-db
|
||||
ZBX_POSTGRES_USER=zabbix
|
||||
ZBX_POSTGRES_PASSWORD=REPLACEME
|
||||
|
||||
# --- Configuration Zabbix Web ---
|
||||
ZBX_DBHOST=zabbix-db
|
||||
ZBX_SERVER_HOST=zabbix-server
|
||||
PHP_TZ=Europe/Paris
|
||||
|
||||
# Clé Cloudflare
|
||||
TUNNEL_TOKEN="REPLACEME"
|
||||
|
|
@ -0,0 +1,50 @@
|
|||
services:
|
||||
zabbix-db:
|
||||
image: postgres:16-alpine
|
||||
container_name: zabbix-db
|
||||
restart: always
|
||||
volumes:
|
||||
- ./zbx_db_data:/var/lib/postgresql/data
|
||||
env_file: .env
|
||||
networks:
|
||||
- zabbix-tier
|
||||
|
||||
zabbix-server:
|
||||
image: zabbix/zabbix-server-pgsql:7.0-alpine-latest
|
||||
container_name: zabbix-server
|
||||
restart: always
|
||||
depends_on:
|
||||
- zabbix-db
|
||||
env_file: .env
|
||||
ports:
|
||||
- "10051:10051"
|
||||
networks:
|
||||
- zabbix-tier
|
||||
- public-tier
|
||||
|
||||
zabbix-web:
|
||||
image: zabbix/zabbix-web-nginx-pgsql:7.0-alpine-latest
|
||||
container_name: zabbix-web
|
||||
restart: always
|
||||
depends_on:
|
||||
- zabbix-db
|
||||
- zabbix-server
|
||||
env_file: .env
|
||||
networks:
|
||||
- zabbix-tier
|
||||
- public-tier
|
||||
|
||||
tunnel:
|
||||
image: cloudflare/cloudflared:latest
|
||||
container_name: cloudflare-tunnel
|
||||
restart: always
|
||||
command: tunnel run
|
||||
env_file: .env
|
||||
networks:
|
||||
- public-tier
|
||||
|
||||
networks:
|
||||
zabbix-tier:
|
||||
internal: true
|
||||
public-tier:
|
||||
driver: bridge
|
||||
|
After Width: | Height: | Size: 12 KiB |
|
After Width: | Height: | Size: 11 KiB |
|
After Width: | Height: | Size: 27 KiB |
|
|
@ -0,0 +1,501 @@
|
|||
# Guide d'installation : Zabbix Proxy 7.4 avec SQLite3 sur LXC
|
||||
|
||||
Ce guide décrit l'installation et la configuration d'un Zabbix Proxy 7.4 avec SQLite3 dans un conteneur LXC, permettant de superviser un réseau local (homelab) et de transmettre les données à un serveur Zabbix distant via une connexion sécurisée PSK.
|
||||
|
||||
## Architecture
|
||||
|
||||
```
|
||||
Internet
|
||||
│
|
||||
├─ VPS (Serveur Zabbix) - <IP_SERVEUR>:10051
|
||||
│ ↕ (connexion TLS/PSK chiffrée)
|
||||
└─ LXC Homelab (Proxy Zabbix) - Proxy-Homelab
|
||||
│
|
||||
└─ Zabbix Agent 2 (127.0.0.1:10050)
|
||||
```
|
||||
|
||||
Le proxy collecte les données de votre réseau local et les transmet de manière sécurisée au serveur distant.
|
||||
|
||||
---
|
||||
|
||||
## Prérequis
|
||||
|
||||
- Conteneur LXC sous Debian 13 (ou compatible)
|
||||
- Accès root au conteneur
|
||||
- Serveur Zabbix 7.x accessible via Internet
|
||||
- Ports requis :
|
||||
- **10051** : Communication proxy → serveur (sortant)
|
||||
- **10050** : Communication agent → proxy (local)
|
||||
|
||||
---
|
||||
|
||||
## Installation
|
||||
|
||||
### 1. Mise à jour du système
|
||||
|
||||
```bash
|
||||
apt update && apt upgrade -y
|
||||
```
|
||||
|
||||
### 2. Installation du dépôt Zabbix 7.4
|
||||
|
||||
```bash
|
||||
wget https://repo.zabbix.com/zabbix/7.4/debian/pool/main/z/zabbix-release/zabbix-release_7.4-1+debian13_all.deb
|
||||
dpkg -i zabbix-release_7.4-1+debian13_all.deb
|
||||
apt update
|
||||
```
|
||||
|
||||
### 3. Installation des paquets Zabbix
|
||||
|
||||
```bash
|
||||
apt install zabbix-proxy-sqlite3 zabbix-agent2 -y
|
||||
```
|
||||
|
||||
**Pourquoi SQLite3 ?**
|
||||
- Léger et adapté aux conteneurs LXC
|
||||
- Pas besoin de serveur MySQL/PostgreSQL
|
||||
- Suffisant pour un proxy gérant quelques dizaines d'hôtes
|
||||
|
||||
---
|
||||
|
||||
## Configuration de la base de données
|
||||
|
||||
### 1. Création du répertoire et initialisation
|
||||
|
||||
```bash
|
||||
# Créer le répertoire de la base
|
||||
mkdir -p /var/lib/zabbix
|
||||
chown zabbix:zabbix /var/lib/zabbix
|
||||
|
||||
# Injecter le schéma SQLite
|
||||
zcat -f /usr/share/zabbix-proxy-sqlite3/schema.sql.gz | sqlite3 /var/lib/zabbix/zabbix_proxy.db
|
||||
|
||||
# Appliquer les permissions
|
||||
chown zabbix:zabbix /var/lib/zabbix/zabbix_proxy.db
|
||||
chmod 660 /var/lib/zabbix/zabbix_proxy.db
|
||||
```
|
||||
|
||||
### 2. Vérification
|
||||
|
||||
```bash
|
||||
ls -lh /var/lib/zabbix/zabbix_proxy.db
|
||||
```
|
||||
|
||||
Vous devriez voir un fichier d'environ 6-8 MB appartenant à `zabbix:zabbix`.
|
||||
|
||||
---
|
||||
|
||||
## Sécurisation : Génération de la clé PSK
|
||||
|
||||
La clé PSK (Pre-Shared Key) permet de chiffrer la communication entre le proxy et le serveur Zabbix.
|
||||
|
||||
```bash
|
||||
# Générer une clé hexadécimale de 32 octets
|
||||
openssl rand -hex 32 | tee /etc/zabbix/zabbix_proxy.psk
|
||||
|
||||
# Appliquer les permissions
|
||||
chown zabbix:zabbix /etc/zabbix/zabbix_proxy.psk
|
||||
chmod 600 /etc/zabbix/zabbix_proxy.psk
|
||||
```
|
||||
|
||||
**Important :** Notez le contenu de cette clé, vous en aurez besoin lors de la configuration du proxy sur le serveur Zabbix.
|
||||
|
||||
```bash
|
||||
cat /etc/zabbix/zabbix_proxy.psk
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Configuration du Proxy
|
||||
|
||||
### 1. Création du répertoire de logs
|
||||
|
||||
```bash
|
||||
mkdir -p /var/log/zabbix-proxy
|
||||
chown zabbix:zabbix /var/log/zabbix-proxy
|
||||
```
|
||||
|
||||
### 2. Configuration principale
|
||||
|
||||
Éditez le fichier `/etc/zabbix/zabbix_proxy.conf` :
|
||||
|
||||
```bash
|
||||
nano /etc/zabbix/zabbix_proxy.conf
|
||||
```
|
||||
|
||||
#### Paramètres essentiels à configurer
|
||||
|
||||
```ini
|
||||
############ CONNEXION AU SERVEUR #################
|
||||
|
||||
# Adresse IP ou DNS du serveur Zabbix
|
||||
Server=<VOTRE_SERVEUR_ZABBIX>
|
||||
|
||||
# Port du serveur (par défaut 10051)
|
||||
ServerPort=10051
|
||||
|
||||
# Nom unique du proxy (doit correspondre au nom configuré sur le serveur)
|
||||
Hostname=Proxy-Homelab
|
||||
|
||||
############ FICHIERS SYSTÈME #################
|
||||
|
||||
# Fichier de logs
|
||||
LogFile=/var/log/zabbix-proxy/zabbix_proxy.log
|
||||
|
||||
# Fichier PID
|
||||
PidFile=/run/zabbix/zabbix_proxy.pid
|
||||
|
||||
############ BASE DE DONNÉES #################
|
||||
|
||||
# Chemin vers la base SQLite
|
||||
DBName=/var/lib/zabbix/zabbix_proxy.db
|
||||
|
||||
# Utilisateur (ignoré pour SQLite, mais requis)
|
||||
DBUser=zabbix
|
||||
|
||||
############ OPTIMISATIONS POUR LXC #################
|
||||
|
||||
# Mode hybride : mémoire puis disque si nécessaire
|
||||
ProxyBufferMode=hybrid
|
||||
|
||||
# Taille du buffer mémoire (16 MB recommandé pour LXC)
|
||||
ProxyMemoryBufferSize=16M
|
||||
|
||||
############ PERFORMANCE #################
|
||||
|
||||
# Timeout des requêtes (en secondes)
|
||||
Timeout=4
|
||||
|
||||
# Log les requêtes lentes (> 3 secondes)
|
||||
LogSlowQueries=3000
|
||||
|
||||
############ OUTILS RÉSEAU #################
|
||||
|
||||
# Chemins vers fping/fping6
|
||||
FpingLocation=/usr/bin/fping
|
||||
Fping6Location=/usr/bin/fping6
|
||||
|
||||
############ STATISTIQUES #################
|
||||
|
||||
# Autoriser les statistiques internes depuis localhost
|
||||
StatsAllowedIP=127.0.0.1
|
||||
|
||||
############ FICHIERS ADDITIONNELS #################
|
||||
|
||||
# Inclure les configurations additionnelles
|
||||
Include=/etc/zabbix/zabbix_proxy.conf.d/*.conf
|
||||
|
||||
############ SÉCURITÉ TLS/PSK #################
|
||||
|
||||
# Connexion au serveur via PSK
|
||||
TLSConnect=psk
|
||||
|
||||
# Identifiant PSK (personnalisable)
|
||||
TLSPSKIdentity=PSK-PROXY-HOME
|
||||
|
||||
# Fichier contenant la clé PSK
|
||||
TLSPSKFile=/etc/zabbix/zabbix_proxy.psk
|
||||
```
|
||||
|
||||
#### Explications des paramètres clés
|
||||
|
||||
| Paramètre | Description |
|
||||
|-----------|-------------|
|
||||
| `Server` | Adresse de votre serveur Zabbix (IP ou DNS) |
|
||||
| `Hostname` | Nom unique du proxy (utilisé pour l'identification) |
|
||||
| `ProxyBufferMode=hybrid` | Utilise la RAM par défaut, bascule sur disque si plein |
|
||||
| `ProxyMemoryBufferSize=16M` | Buffer mémoire adapté pour un LXC |
|
||||
| `TLSConnect=psk` | Active le chiffrement PSK (recommandé) |
|
||||
| `TLSPSKIdentity` | Identifiant de la clé (à définir aussi sur le serveur) |
|
||||
| `TLSPSKFile` | Chemin vers le fichier contenant la clé |
|
||||
|
||||
---
|
||||
|
||||
## Configuration de l'Agent Zabbix
|
||||
|
||||
L'agent Zabbix surveille le proxy lui-même (métriques CPU, RAM, disque, etc.).
|
||||
|
||||
Éditez `/etc/zabbix/zabbix_agent2.conf` :
|
||||
|
||||
```bash
|
||||
nano /etc/zabbix/zabbix_agent2.conf
|
||||
```
|
||||
|
||||
### Paramètres essentiels
|
||||
|
||||
```ini
|
||||
############ FICHIERS SYSTÈME #################
|
||||
|
||||
PidFile=/run/zabbix/zabbix_agent2.pid
|
||||
LogFile=/var/log/zabbix/zabbix_agent2.log
|
||||
|
||||
# Désactiver la rotation automatique (géré par logrotate)
|
||||
LogFileSize=0
|
||||
|
||||
############ CONNEXION AU PROXY LOCAL #################
|
||||
|
||||
# Le proxy est en local sur le même conteneur
|
||||
Server=127.0.0.1
|
||||
ServerActive=127.0.0.1
|
||||
|
||||
# Nom d'hôte (identique au proxy pour simplifier)
|
||||
Hostname=Proxy-Homelab
|
||||
|
||||
############ SOCKET DE CONTRÔLE #################
|
||||
|
||||
ControlSocket=/run/zabbix/agent.sock
|
||||
|
||||
############ FICHIERS ADDITIONNELS #################
|
||||
|
||||
Include=/etc/zabbix/zabbix_agent2.d/*.conf
|
||||
Include=./zabbix_agent2.d/plugins.d/*.conf
|
||||
```
|
||||
|
||||
**Points importants :**
|
||||
- `Server` et `ServerActive` pointent vers `127.0.0.1` car l'agent communique avec le proxy local
|
||||
- Pas de configuration TLS/PSK nécessaire pour l'agent (communication locale)
|
||||
|
||||
---
|
||||
|
||||
## Activation et démarrage des services
|
||||
|
||||
```bash
|
||||
# Activer le démarrage automatique
|
||||
systemctl enable zabbix-proxy
|
||||
systemctl enable zabbix-agent2
|
||||
|
||||
# Démarrer les services
|
||||
systemctl restart zabbix-proxy
|
||||
systemctl restart zabbix-agent2
|
||||
|
||||
# Vérifier les statuts
|
||||
systemctl status zabbix-proxy
|
||||
systemctl status zabbix-agent2
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Vérification et logs
|
||||
|
||||
### Consulter les logs en temps réel
|
||||
|
||||
```bash
|
||||
# Logs du proxy
|
||||
tail -f /var/log/zabbix-proxy/zabbix_proxy.log
|
||||
|
||||
# Logs de l'agent
|
||||
tail -f /var/log/zabbix/zabbix_agent2.log
|
||||
```
|
||||
|
||||
### Vérifier la connexion au serveur
|
||||
|
||||
Dans les logs du proxy, vous devriez voir :
|
||||
|
||||
```
|
||||
sending configuration data to server at "203.0.113.10": datalen 123
|
||||
```
|
||||
|
||||
Si vous voyez des erreurs TLS/PSK, vérifiez :
|
||||
- La clé PSK est identique sur le proxy et le serveur
|
||||
- L'identifiant PSK correspond
|
||||
- Le firewall autorise le port 10051
|
||||
|
||||
### Commandes de diagnostic utiles
|
||||
|
||||
```bash
|
||||
# Vérifier les processus Zabbix
|
||||
ps aux | grep zabbix
|
||||
|
||||
# Vérifier les ports en écoute
|
||||
ss -tlnp | grep zabbix
|
||||
|
||||
# Logs système
|
||||
journalctl -xeu zabbix-proxy --no-pager | tail -50
|
||||
journalctl -xeu zabbix-agent2 --no-pager | tail -50
|
||||
|
||||
# Vérifier la config
|
||||
grep -E "^(Server|Hostname|DBName|LogFile|TLSConnect)" /etc/zabbix/zabbix_proxy.conf
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Configuration côté serveur Zabbix
|
||||
|
||||
Sur l'interface web de votre serveur Zabbix :
|
||||
|
||||
### 1. Créer le proxy
|
||||
|
||||
1. Aller dans **Administration → Proxies**
|
||||
2. Cliquer sur **Create proxy**
|
||||
3. Configurer :
|
||||
- **Proxy name** : `Proxy-Homelab` (identique au `Hostname` du fichier de config)
|
||||
- **Proxy mode** : `Active`
|
||||
- **Proxy address** : Laisser vide (le proxy contacte le serveur)
|
||||
- **Encryption** :
|
||||
- Cocher **PSK**
|
||||
- **PSK identity** : `PSK-PROXY-HOME`
|
||||
- **PSK** : Copier le contenu de `/etc/zabbix/zabbix_proxy.psk`
|
||||
|
||||
4. Cliquer sur **Add**
|
||||
|
||||
### 2. Assigner les hôtes au proxy
|
||||
|
||||
Pour chaque hôte de votre réseau local :
|
||||
|
||||
1. Aller dans **Configuration → Hosts**
|
||||
2. Sélectionner l'hôte
|
||||
3. Dans l'onglet **Host**, section **Monitored by proxy** :
|
||||
- Sélectionner `Proxy-Homelab`
|
||||
4. Cliquer sur **Update**
|
||||
|
||||
---
|
||||
|
||||
## Résolution de problèmes
|
||||
|
||||
### Le proxy ne se connecte pas au serveur
|
||||
|
||||
**Symptôme :** Logs montrent `cannot connect to [[203.0.113.10]:10051]`
|
||||
|
||||
**Solutions :**
|
||||
1. Vérifier la connectivité réseau :
|
||||
```bash
|
||||
ping <IP_SERVEUR>
|
||||
telnet <IP_SERVEUR> 10051
|
||||
```
|
||||
2. Vérifier le firewall du serveur (port 10051 ouvert)
|
||||
3. Vérifier le paramètre `Server=` dans le fichier de config
|
||||
|
||||
### Erreur TLS/PSK
|
||||
|
||||
**Symptôme :** `invalid PSK identity` ou `TLS handshake failed`
|
||||
|
||||
**Solutions :**
|
||||
1. Vérifier que la clé PSK est identique :
|
||||
```bash
|
||||
cat /etc/zabbix/zabbix_proxy.psk
|
||||
```
|
||||
2. Vérifier le `TLSPSKIdentity` (sensible à la casse)
|
||||
3. Sur le serveur, vérifier la configuration du proxy (PSK identity et clé)
|
||||
|
||||
### Base de données verrouillée
|
||||
|
||||
**Symptôme :** `database is locked`
|
||||
|
||||
**Solutions :**
|
||||
1. Vérifier les permissions :
|
||||
```bash
|
||||
ls -l /var/lib/zabbix/zabbix_proxy.db
|
||||
```
|
||||
2. Redémarrer le proxy :
|
||||
```bash
|
||||
systemctl restart zabbix-proxy
|
||||
```
|
||||
|
||||
### Proxy visible mais "unavailable"
|
||||
|
||||
**Symptôme :** Le proxy apparaît dans l'interface mais reste grisé
|
||||
|
||||
**Causes possibles :**
|
||||
- Le proxy ne peut pas envoyer de données (problème réseau)
|
||||
- Configuration PSK incorrecte
|
||||
- Nom du proxy ne correspond pas
|
||||
|
||||
**Solution :** Consulter les logs des deux côtés (proxy et serveur)
|
||||
|
||||
---
|
||||
|
||||
## Optimisations pour homelab
|
||||
|
||||
### Ajuster la fréquence de synchronisation
|
||||
|
||||
Pour réduire la bande passante, augmentez l'intervalle de configuration :
|
||||
|
||||
```ini
|
||||
# Dans /etc/zabbix/zabbix_proxy.conf
|
||||
ProxyConfigFrequency=600 # 10 minutes au lieu de 10 secondes
|
||||
DataSenderFrequency=5 # Envoie les données toutes les 5 secondes
|
||||
```
|
||||
|
||||
### Limiter la rétention locale
|
||||
|
||||
Pour économiser l'espace disque :
|
||||
|
||||
```ini
|
||||
ProxyOfflineBuffer=2 # Garde 2 heures de données en cas de déconnexion
|
||||
```
|
||||
|
||||
### Ajuster les pollers
|
||||
|
||||
Si vous avez peu d'hôtes (< 10), réduisez les processus :
|
||||
|
||||
```ini
|
||||
StartPollers=3
|
||||
StartPingers=1
|
||||
StartDiscoverers=1
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Sauvegarde et maintenance
|
||||
|
||||
### Sauvegarder la configuration
|
||||
|
||||
```bash
|
||||
# Sauvegarder les fichiers de config et la clé PSK
|
||||
tar -czf /root/zabbix-proxy-backup-$(date +%Y%m%d).tar.gz \
|
||||
/etc/zabbix/zabbix_proxy.conf \
|
||||
/etc/zabbix/zabbix_agent2.conf \
|
||||
/etc/zabbix/zabbix_proxy.psk
|
||||
```
|
||||
|
||||
### Sauvegarder la base de données
|
||||
|
||||
```bash
|
||||
# Copie de la base SQLite
|
||||
cp /var/lib/zabbix/zabbix_proxy.db /root/zabbix_proxy.db.backup
|
||||
```
|
||||
|
||||
### Rotation des logs
|
||||
|
||||
Créez `/etc/logrotate.d/zabbix-proxy` :
|
||||
|
||||
```
|
||||
/var/log/zabbix-proxy/zabbix_proxy.log {
|
||||
weekly
|
||||
rotate 4
|
||||
compress
|
||||
delaycompress
|
||||
missingok
|
||||
notifempty
|
||||
create 0640 zabbix zabbix
|
||||
postrotate
|
||||
systemctl reload zabbix-proxy > /dev/null 2>&1 || true
|
||||
endscript
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Conclusion
|
||||
|
||||
Vous disposez maintenant d'un proxy Zabbix fonctionnel, sécurisé par TLS/PSK, et optimisé pour tourner dans un conteneur LXC. Cette architecture permet de superviser votre réseau local tout en centralisant les données sur un serveur distant.
|
||||
|
||||
**Avantages de cette configuration :**
|
||||
- ✅ Communication chiffrée (PSK)
|
||||
- ✅ Léger (SQLite + LXC)
|
||||
- ✅ Résilient (buffer hybride)
|
||||
- ✅ Facile à maintenir
|
||||
|
||||
**Prochaines étapes suggérées :**
|
||||
- Configurer les templates et items pour vos hôtes
|
||||
- Mettre en place des triggers et alertes
|
||||
- Ajouter des graphiques personnalisés
|
||||
- Configurer les notifications (email, Telegram, etc.)
|
||||
|
||||
---
|
||||
|
||||
## Références
|
||||
|
||||
- [Documentation officielle Zabbix Proxy](https://www.zabbix.com/documentation/current/en/manual/distributed_monitoring/proxies)
|
||||
- [Zabbix 7.4 Release Notes](https://www.zabbix.com/rn/rn7.4.0)
|
||||
- [Configuration de l'encryption PSK](https://www.zabbix.com/documentation/current/en/manual/encryption/using_pre_shared_keys)
|
||||
|
After Width: | Height: | Size: 120 KiB |