Zabbix disponibilté

Support Debian
#1

J’utilise Zabbix version 7.06, agent2 en mode actif et le template « Linux by Zabbix agent active » , la plupart de mes « hosts » ont un icône de disponibilité en gris.

D’après ce lien 11 Unreachable/unavailable host interface settings

les défauts à l’origine de cet état sont vus dans les logs du serveur en filtrant « failed » et le nom du « host ».

Pour un host, j’avais un défaut « vfs.file.contents[ »/sys/class/net/enp1s0/speed"]" , j’ai désactivé l’élément concerné mais mon état reste en gris et je ne vois plus de défaut « failed » dans les logs (avec DebugLevel=5)

La doc ne serait pas totalement à jour? Et dans ce cas un lecteur a-t-il une idée pour définir l’origine de cet état?

Merci d’avance.

#2

Ce Template requiert une connexion agent en mode passif :wink: et non actif, très peux d’item fonctionne ne mode actif.

Le failed relevé n’a rien à voir avec l’état gris, ce dernier veux simplement dire que ton agent est non reconnu (pas de connexion avec ton agent) …

1 J'aime
#3

Yes, une coquille directement corrigée dans le post initial.

Les données remontent, il y a donc bien une connexion.

241211-Data

#4

J’allais faire un test avec une VM, mais en mettant à jour de 7.0 vers 7.2 j’ai merdé ma migration et la base de données ne va pas :frowning:

La question que je voulais te poser @PmGs, c’est pourquoi tu veux absolument être en agent actif?

#5

Une fois remis mon zabbix en service (oubli de restart les process et des différences de conf du server et de l’agent).
Je suis maintenant en version Zabbix 7.2

Je viens de créer un serveur de test avec l’agent en mode actif.
Pour se faire je n’ai rien fait d’autre que:
image

Je n’ai même pas mis l’adresse IP.
par contre, dans la configuration de l’agent, j’ai bien précise le Hostname=dsrvtest01

Ce qui est explicitement le nom que j’ai donné au Host dans la conf zabbxi (image ci-dessus).
Mon host en bien en agent actif, et l’icone ZBX est en vert:

image

La conf de l’agent:

PidFile=/run/zabbix/zabbix_agent2.pid
LogType=file
LogFile=/var/log/zabbix/zabbix_agent2.log
LogFileSize=10
SourceIP=<ip de la machine de test>
Server=<ip du serveur zabbix>
ListenPort=10050
ListenIP=0.0.0.0
ServerActive=<ip du serveur zabbix>
Hostname=dsrvtest01
Include=/etc/zabbix/zabbix_agent2.d/*.conf
PluginSocket=/run/zabbix/agent.plugin.sock
ControlSocket=/run/zabbix/agent.sock
Include=/etc/zabbix/zabbix_agent2.d/plugins.d/*.conf
1 J'aime
#6

Merci @Zargos c’était effectivement un problème d’installation (de l’agent)

Sur le host en question* l’installation de l’agent en debian 12 standard m’avait installé la version 6, après purge et après l’installation de l’agent 7.0 le répertoire /run/zaabix n’a pas été créé. Je l’ai vu dans les logs de l’agent, probablement que la doc que j’ai citée dans mon post initial était pour le passif.

*et je ne sais pas pourquoi sur la machine, toujours en debian 12, qui fonctionnait, ce répertoire existait déjà … probablement un essai non documenté ou une installation un peu différente.

Sinon

parceque :

  • quand je découvre qqc de nouveau j’aime pousser mes tests à fond pour découvrir / comprendre et au final choisir.

  • J’envisage une fréquence de remontée faible mais des capacités d’alertes rapides

#7

Les packages Zabbix fournis par Debian ne sont pas bon. J’ai arrêté de les utiliser car il y a avait trop d’écart avec ceux fournis par Zabbix qui eux, marchent très bien.

La différence entre le passif et l’actif, c’est que dans le premier c’est le serveur qui va chercher les données, dans le second, l’agent détermine les points de contrôles et ensuite il les envoie.
Le problème c’est que si un check de l’agent prend du temps, il ne pourra pas envoyer les autres données tant qu’il n’aura pas fini ce check (sachant qu’on peut avoir plusieurs process agent pour les check mais un seul pour envoyer les données). Et coté serveur, il ne peut y avoir qu’un seul process par agent.
image

Dans certaines topologie de supervision on fera faire à l’agent à la fois du passif et de l’actif en fonction des points de contrôles qu’on veux avoir (du passif pour des check bases sur des scripts par exemple et l’actif pour le check de la mémoire ou du cpu).
Le passif consomme plus de ressources sur le serveur que l’actif; c’est aussi là que se situe la principale différence.

C’est contradictoire, si ta remontée est à faible fréquence, alors tes alertes le seront aussi.
Ce n’est pas l’agent qui donne les alertes mais le serveur.
Il ne peut donc pas générer des alertes s’il n’a pas les données pour les déterminer.

1 J'aime
#8

Merci pour ces explications.

J’ai cru comprendre / imaginé qu’un agent pouvait envoyer une donnée/info d’alerte au besoin … mais je n’en suis pas encore là dans mes essais … à suivre.

#9

Avec les trap snmp oui. Mais coté sécu c’est pas top, et il faut faire très attention avec car on a vite fait de se flooder avec des alertes :slight_smile: