[Nono]

tout est redevenu à la normal sur mon autre serveur sans que je n'ai eu rien à faire, ni motif, ni reboot

[BBR]

que vois-je Nowwhat le pourfendeur de versions obsolètes qui a un serveur avec une Debian 7 !
c'était la minute délire du jour

[nowwhat]

De toute façon : même quand ça marche ........ des fois ça ne marche pas :

Le RTM concernant un des mes SYS :


http://www.test-domaine.fr/rtm.jpg

Sur le serveur, le cron rorone :

Feb  3 17:21:01 ns311465 CRON[8550]: (root) CMD (/usr/local/rtm/bin/rtm 25 > /dev/null 2> /dev/null)
Feb  3 17:22:01 ns311465 CRON[8608]: (root) CMD (/usr/local/rtm/bin/rtm 25 > /dev/null 2> /dev/null)

Des vrais stats utiles, il FAUT le faire soi même.

[janus57]

Bonjour,

avec la technique donné plus haut j'ai pas eu de panne de monitoring sur le premier serveur, l'adresse par défaut (rtm-collector.ovh.net de mémoire) doit surement tomber/avoir des difficultés de temps en temps à rediriger le flux vers le "bon" serveur (simple supposition).

Du coup avec la technique donné plus haut on tape forcément sur le serveur qui est censé gérer notre rang/baie, et du moment que ce serveur précis ne tombe pas ou ne remonte pas les infos plus haut c'est bon cela va toujours fonctionné.

Perso j'ai de nouveau le monitoring avec cette technique depuis 17H (reboot du dédié pour finitions de MAJ et "forçage" du RTM), donc depuis hier 19H-19H30 en gros.

Cordialement, janus57

[Benja]

Salut,

Pour moi tout est résolu comme par magie depuis aujourd'hui ! Sur mes 4 serveurs Kimsufi, et mon serveur SoYouStart.
Tout fonctionne parfaitement maintenant, sans que j'aie eu à faire aucune modif sur le paramétrage du serveur.

Je pense que le problème se situait sur les serveurs de monitoring.
Affaire classée, en ce qui me concerne. Merci OVH, si vous me lisez !

[janus57]

Bonjour,

perso sur un KS-1 "récent" le RTM aussi est tombé, mais pas sur mon autre KS ou je l'avais modifié à la main suite a sa MAJ avec le script de MAJ qui été foireux côté OVH (mauvais serveur de collecte).

Du coup je viens de changer le serveur de collecte sur mon second KS-1 qui le problème (en gros on prend son IP et le dernier octet c'est 251).
Pour ceux qui on la flemme :

hostname -I | cut -d' ' -f1 | awk -F'.' -vOFS='.' '{$NF=251}1;'

Ensuite on fait un

host ip.en.251

Et on modifie 2 fichiers :
/usr/local/rtm/etc/rtm-ip <= avec l'ip en .251
/usr/local/rtm/bin/rtm-update-ip.pl <= on remplace "rtm-collector.ovh.net" par le résultat de la commande, dans mon cas ce sera : mrtg-gra1-1.ovh.net

Maintenant je vais voir dans 24H si c'est résolu ou non.

Cordialement, janus57

[Nono]

je viens de voir que sur un de mes serveurs tout est rentré en ordre, sur l'autre Il m'est indiqué que RTM n'est pas installé alors que tout fonctionnait bien il y a quelques jours.

[Benja]

Oui toujours le même problème, pas de nouvelles depuis qu'on m'a répondu sur KS et SYS que l'information allait être remontée aux techniciens !

[FleuryK]

Bonjour,

Moi aussi je suis touché par ce problème malgré que le statut du serveur est sur OK et que le monitoring est sur Activé.
Au jour d'aujourd'hui RTM ne fonctionne plus, j'ai le message "RTM n'est pas disponible sur ce serveur" alors que je dois l'avoir.

Affaire à suivre ...

Cordialement.

[Nono]

Ton problème a-t-il été résolu ?
De mon côté on m'a demandé de faire quelques Tests, puis que le problème allait être remonté aux administrateurs. Mon ticket a été fermé mais j'ai toujours le même problème.

[Nono]

Merci pour le retour, de mon côté j'ai reçu à peu près le même message sur KimSufi et SoYouStart, suite à mes tickets de support :



Nono, je t'invite à ouvrir aussi un ticket de support sur KS, ça ne pourra qu'accélérer les choses !

C'est fait

[Benja]

Merci pour le retour, de mon côté j'ai reçu à peu près le même message sur KimSufi et SoYouStart, suite à mes tickets de support :

Bonjour, Une remonté a été faite à ce sujet et nos techniciens investigueront au plus vite. Sachez cependant que ceci n'impacte en rien le fonctionnement de votre service. Je vous invite à utiliser votre propre solution de monitoring le temps qu'un fixe soit apporté.

Nono, je t'invite à ouvrir aussi un ticket de support sur KS, ça ne pourra qu'accélérer les choses !

[Nono]

Hello,

Tiens je viens de voir que j'ai le même soucis avec une Debian 8 suite à un reboot ! Après l'upgrade du kernel en 3.16 !? Affaire à suivre

[Benja]

Merci de ton retour BBR, c'est donc bien un problème avec Fedora Server.
J'ai ouvert un ticket de support sur SoYouStart, où j'ai de meilleures chances de résolution que sur Kimsufi, puisque le problème est le même sur les 2 plateformes.

[BBR]

Cela fonctionne sur tous mes serveurs des différentes gammes (ks, sys et ovh), ils sont sous Proxmox, ubuntu et Debian 8.2

[Benja]

Probablement le serveur de collecte de stats de ton rack.
T'as son IP : /usr/local/rtm/etc/rtm-ip (chez moi c'est un IP qui est présent dans les règles parafeu mentionné avant).

Bizarrement, cette IP n'est sur le même subnet que mon serveur :

# cat /usr/local/rtm/etc/rtm-ip 
37.187.231.251

Alors que l'IP de mon serveur est sur 91.121.139.x. Je vais whitelister cette IP sur firewalld, on ne sait jamais.

Attention avec Fedora savoir si c'est iptables qui gère ton FW ou FirewallD ! Je suppose que par défaut c'est FirewallD mais je ne sais pas ce qu'a fait OVH !

Oui c'est bien firewalld, comme mentionné plus haut

Et à la commande : firewall-cmd --state

# firewall-cmd --state
running

Par défaut, OVH ne paramétré AUCUN règle parafeu, donc tout les destinations et portes sont 'ouvertes'.

Hmm a priori, sur Fedora ils avaient bien mis firewalld actif par défaut, avec ces règles :

Mais bon, ça n'empêche pas les connexions sortantes d'après ce que je comprends, d'autant que le manager affiche mon uptime, donc comme je l'ai dit plus haut, je suppose que la communication se fait.

je suis quasiment sur qu'il s'agit d'un soucis avec le serveur 'rtm' de collecte.

Je pense aussi.

Même SElinux est disabled ?

Ah non, il est enforcing. Je peux tenter de le désactiver.

Pour finir, même problème avec le serveur que j'ai chez SoYouStart, qui est aussi sur Fedora 23. Le manager, qui est sensiblement le même, affiche bien la même erreur, et impossible de consulter les graphes.

Par contre quand je vous demandais si vous pouviez voir de votre côté si les graphes s'affichent, je ne parle pas de ceux qui sont sous Fedora 23, mais de tout le monde ! Je suis intéressé de savoir si ces graphes s'affichent sur votre manager pour vos serveurs sous d'autres distros.

[sloomy]

Bonjour @nowwhat,

Hum ! je sais pas, j'ai pas de fedora installée version OVH !
Même SElinux est disabled ?

Cdlt
Bruno

[nowwhat]

@sloomy: je ne pense pas que Benja à betonné son parafeu (iptables ou FirewallD ) .... (et ainsi interdit tout comm UDP vers l'IP listé /usr/local/rtm/etc/rtm-ip) pour venir en suite ici pour dire que le rtm ne fonctionne pas ....

Par défaut, OVH ne paramétré AUCUN règle parafeu, donc tout les destinations et portes sont 'ouvertes'.

A l'autre coté, c'est du déjà vu ça, car cette raison a été invoqué souvent sur le (ce) forum

je suis quasiment sur qu'il s'agit d'un soucis avec le serveur 'rtm' de collecte.

[nowwhat]

(double post)

[sloomy]

Bonjour,

Attention avec Fedora savoir si c'est iptables qui gère ton FW ou FirewallD ! Je suppose que par défaut c'est FirewallD mais je ne sais pas ce qu'a fait OVH !

Je te renvoie à la documentation ici : https://fedoraproject.org/wiki/FirewallD

Et à la commande : firewall-cmd --state

Cdlt
Bruno

[nowwhat]

...
Je pense plutôt à un problème général d'affichage sur le manager Kimsufi.

Probablement le serveur de collecte de stats de ton rack.
T'as son IP : /usr/local/rtm/etc/rtm-ip (chez moi c'est un IP qui est présent dans les règles parafeu mentionné avant).

........ et surtout qu'il affiche l'uptime du serveur ! Je prends ça comme une preuve que le serveur de monitoring communique correctement avec mon serveur.

Bien vu.
Les paquets UDP arrivent donc bien chez "/usr/local/rtm/etc/rtm-ip" et le up time n'est pas utilisé pour nourrir des stats, mais simplement pour te l'afficher.

...C'est pour ça que je serais intéressé si l'un d'entre vous pouvait me confirmer (ou non) que les graphes s'affichent bien pour lui ?

Je ne pense pas qu'un Fedora est installé souvent.
Je pense carrément que le soucis n'est pas ton serveur, ni les logiciels, mais à l'autre coté. "Chez eux".

[Benja]

Pour l'ICMP pas de problème, le serveur répond au ping de partout.
En ce qui concerne les IP xxx.yyy.zzz.250 et .251, et les ai autorisées, sans succès.
En désespoir de cause, j'ai carrément désactivé le firewall sur l'une des machines pendant une dizaine de minutes, ce qui devrait lui laisser le temps de transférer des données aux serveurs de monitoring, et j'ai toujours le même message.

Je pense plutôt à un problème général d'affichage sur le manager Kimsufi. Ce qui renforce ma conviction, c'est que le manager m'affiche bien "statut du serveur : OK" , et surtout qu'il affiche l'uptime du serveur ! Je prends ça comme une preuve que le serveur de monitoring communique correctement avec mon serveur.

C'est pour ça que je serais intéressé si l'un d'entre vous pouvait me confirmer (ou non) que les graphes s'affichent bien pour lui ?

[BBR]

ou ici mais il me semble qu'il n'est pas complet (anciens guides) http://guide.ovh.com/firewall

[BBR]

non par défaut tout est ouvert du moins sur les distributions que j'ai déjà utilisées
ça vient de chez ovh, cherche dans leurs docs https://docs.ovh.com/

[Benja]

Merci pour ton listing iptables, c'était configuré par défaut sur ta machine ?

Je t'avoue que je débute avec firewalld, qui remplace maintenant iptables sur Fedora (bien qu'on puisse revenir à iptables).
Je vais voir si je peux adapter ça, mais ça m'intéresse de savoir d'où ça vient déjà

[BBR]

je ne connais pas Fedora, tu adapteras

##RTM et ping OVH
/sbin/iptables -A INPUT -i eth0 -p icmp --source proxy.ovh.net -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p icmp --source 37.187.231.251 -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p icmp --source a2.ovh.net -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p icmp --source 92.222.184.0/24 -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p icmp --source 92.222.185.0/24 -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p icmp --source 92.222.186.0/24 -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p icmp --source 167.114.37.0/24 -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p icmp --source proxy.p19.ovh.net -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p icmp --source proxy.rbx.ovh.net -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p icmp --source proxy.sbg.ovh.net -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p icmp --source proxy.bhs.ovh.net -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p icmp --source ping.ovh.net -j ACCEPT
/sbin/iptables -A OUTPUT -p udp --dport 6100:6200 -j ACCEPT

#Mettre le debut IP du serveur a la place des xxx
/sbin/iptables -A INPUT -p icmp --source xxx.xxx.xxx.250 -j ACCEPT
/sbin/iptables -A INPUT -p icmp --source xxx.xxx.xxx.251 -j ACCEPT

[Benja]

Non, je n'ai rien autorisé de particulier, à quels services / ports penses-tu ?
Est-ce qu'ils ne devraient pas être autorisés par défaut sur les OS installés par OVH ?

Voici les seuls services autorisés :

# firewall-cmd --list-services 
dhcpv6-client http ssh

Je n'ai fait qu'ajouter http à la liste des services, je n'ai rien supprimé. Enfin si, j'ai supprimé cockpit, qui était vraisemblablement une erreur de packaging d'OVH et qui empêchait de sauvegarder les règles de firewall. Mais je ne pense pas que cockpit ait quoi que ce soit à voir avec ça.

[BBR]

si tu as un firewall, as-tu autorisé tout ce qui concerne ovh et son monitoring ?

[Benja]

T'as vérifié sir ce cron s'eécute aussi réelement ?

Chez moi (Un OS 'normal') =
cat /var/log/cron.log

Je me trouve avec des milliers des linges (une chaque minute) qui m'indique que c'est fait.

Idem, il s'exécute bien.

Le doc de ce ficheir est :
/usr/local/rtm/bin/rtm
!!
Ouvre le avec un traitement de texte, par exemple 'nano':
nano /usr/local/rtm/bin/rtm

J'ai déjà ouvert ce script par curiosité, mais je n'ai pas envie de prendre le temps de comprendre ce qu'il fait. Il est mis en place par OVH, je suppose qu'il est censé fonctionner.

Va faire les test : installe le OS normal (Debian bien sur) et regarde si cette fois ci le rtm fonctionne ...

Le problème, c'est que je n'ai pas envie de réinstaller aucun de mes serveurs, qui sont déjà installés avec leurs jobs respectifs.
Et en commander un nouveau juste pour tester... Vu le peu d'urgence, je crois que je préfère encore attendre une hypothétique réponse du support !

Merci pour tes pistes en tout cas. Si j'ai des news, je les posterai ici.

[nowwhat]

Bonjour Bruno,

J'ai lu les 2 liens ci-dessus, le guide et le post de blog.

La seule partie qui semble concerner le monitoring c'est l'installation et l'appel via cron du rtm, or ça semble déjà être installé sur mon serveur par défaut :

# cat /etc/crontab
...
*/1 * * * * root /usr/local/rtm/bin/rtm 41 > /dev/null 2> /dev/null

T'as vérifié sir ce cron s'eécute aussi réelement ?

Chez moi (Un OS 'normal') =
cat /var/log/cron.log

Je me trouve avec des milliers des linges (une chaque minute) qui m'indique que c'est fait.

Et si j'exécute cette commande manuellement, ça semble fonctionner :
...

Le doc de ce ficheir est :
/usr/local/rtm/bin/rtm
!!
Ouvre le avec un traitement de texte, par exemple 'nano':
nano /usr/local/rtm/bin/rtm
Le script (perl, très basique) se aute explique.

Par contre:

Et pourtant dans mon manager, Utilisations du serveur, toujours la même erreur :

Fedora, Debian ou autre, le script est la même.
Je pense que ton erreur "d'affichage des stats dans le Manager" est lié à un soucis coté serveur-de-récup-des-données-rtm - C'st un serveur géré par KS. Et ça, c'est un soucis pour OVH (KS), pas pour toi.

Le truc chiant est que, en tant que utilisateur d'un KS, il est difficile de tirer leur attention (ils ont leur boite au lettres, standard téléphonique, twitter et système ticket plein avec des "A l'aide - ça marche pas - je ne comprend pas - je ne fait pas d’erreur, c'est vot truc qui marche pas - .etc) donc le temps de traitement est longue.
Il faut faire un ticket, et bien leur expliquer ce qui se passe.

Va faire les test : installe le OS normal (Debian bien sur) et regarde si cette fois ci le rtm fonctionne ...

D’ailleurs, il faut classer ces scripts rtm pour leur vrai valeur : des gadgets.
Je ne dit pas qu'il faut le couper - le rtm s'occupe d'autre chose que "faire des stats" - surtout, garde le.
Mais pour les stats, faut pas demander que quelqu'un te le fasse, il faut le faire soi même. c'est mieux, plus instructive (donc : utile) et plus fun.

mes stats : https://www.test-domaine.fr/munin/pa...org/index.html

[Benja]

Bonjour Bruno,

J'ai lu les 2 liens ci-dessus, le guide et le post de blog.

La seule partie qui semble concerner le monitoring c'est l'installation et l'appel via cron du rtm, or ça semble déjà être installé sur mon serveur par défaut :

# cat /etc/crontab
...
*/1 * * * * root /usr/local/rtm/bin/rtm 41 > /dev/null 2> /dev/null

Et si j'exécute cette commande manuellement, ça semble fonctionner :

# /usr/local/rtm/bin/rtm 41
rtm mINFO_PART_root_mount|/
rtm mINFO_PART_root_usage|1
rtm mINFO_PART_root_inodes|1
rtm mINFO_MEM_memusage|-102
rtm mCHECK_vm|
rtm mINFO_MEM_swapusage|0
rtm mINFO_LOAD_loadavg1|0.48
rtm mINFO_LOAD_loadavg2|0.11
rtm mINFO_LOAD_loadavg3|0.08
rtm mINFO_CPU_usage|1
rtm mCHECK_oops|
rtm mHW_HDD_scsi_status|OK
rtm mINFO_LOAD_processesactive|0
rtm mINFO_LOAD_processesup|158
rtm mINFO_MEM_top_mem_01_name|/usr/sbin/named -u named
rtm mINFO_MEM_top_mem_01_size|699916
rtm mINFO_MEM_top_mem_02_name|/usr/lib/polkit-1/polkitd --no-debug
rtm mINFO_MEM_top_mem_02_size|529328
rtm mINFO_MEM_top_mem_03_name|/usr/sbin/abrtd -d -s
rtm mINFO_MEM_top_mem_03_size|433592
rtm mINFO_MEM_top_mem_04_name|/usr/bin/python3 -Es /usr/sbin/firewalld --nofork --nopid

(je n'ai aucune idée de ce à quoi correspond le numéro 41 après la commande.)

Et pourtant dans mon manager, Utilisations du serveur, toujours la même erreur :

Pac error : no rrd file found

Je commence à soupçonner la distrib Fedora 23, qui est en NEW, et dont la template OVH est peut-être fautive car pas encore assez testée (j'ai déjà rapporté une erreur de configuration de firewalld par défaut à OVH sur cette template).

Est-ce que l'un d'entre vous pourrait aller au même endroit dans son manager, et voir s'il a la même erreur, ou si les graphes s'affichent bien ?

[sloomy]

Bonjour,

http://guide.ovh.com/RealTimeMonitoring

et

https://nipil.org/2013/10/01/serveur...fi-2g-ovh.html

Oui j'ai triché

Cdlt
Bruno

[Benja]

Non c'est bien sur le manager: quand tu es sur la page d'un serveur, clique sur "voir" en face de "Real time monitoring".
Puis "Utilisations du serveur" dans le menu de gauche. C'est bien un service Kimsufi, je n'ai rien installé de particulier, et j'ai le même problème sur mes 4 serveurs sous "Fedora 23 Server (NEW)".

Bruno, tu peux m'en dire plus ? Est-ce qu'on est censés installer quelque chose de particulier, ou ouvrir un service en particulier dans firewalld?
Je pensais que les templates d'installation OVH installaient tout ça par défaut, pour que le monitoring fonctionne immédiatement.

[nowwhat]

...
J'ai posé la question au support, mais ...............

Ils ont pas du comprendre la question.
Savoir qu'eux, ils ont au moins la possibilité de savoir de quel serveur il s'agit, nous nous n'avons même pas ça.
Un soucis de MTGR ?

je vais dans Utilisations du serveur

C'est ou ça ? Un sorte d’interface sur ton serveur ? Le Manager ?
Si c'est sur ton serveur, et il s'agit d'un logiciel, inutile de contacter le support KS, ils sont la pour réparer le hardware (ton serveur), ils ont pas écrit le logiciel, et ne la connaissent pas.

Sinon, lui : https://www.google.fr/search?q=Pac+e...rxiha9p47C_oAw est au courant déjà depuis août 2015.

[sloomy]

Bonjour,

Tu as bien installé l'outil et les règles dans le FW qui vont bien ?

Cordialement,
Bruno

[Benja]

Bonjour,

J'ai installé plusieurs serveurs avec la distro Fedora 23 Server avec noyau OVH, et je ne peux consulter les graphes d'utilisation CPU / RAM sur aucun d'entre eux : lorsque je vais dans Utilisations du serveur, des messages d'erreur apparaissent en rouge en bas à droite de l'écran :

Pac error : no rrd file found

Pourtant sur la page d'accueil du serveur, j'ai bien :

Statut du serveur OK
Monitoring Activé

Quel peut être le problème ?

J'ai posé la question au support, mais ...............

Merci par avance pour vos éclaircissements !