OVH Community, your new community space.

Fiabilité des alertes "OVH service Monitoring"


Flavien
02/07/2015, 14h32
La discussion avance !

Le support m'a confirmé qu'ils n"arrivaient pas à joindre le port 25 de ma machine. Intéressant. Laquelle machine a pourtant reçu 8000 mails dans la journée venant de la planète entière, et aucun restart de postfix à l'horizon.

Et c'est pas un pépin de FW car je vois même pas de paquet SYN dans mes captures. Et au niveau routage c'est bon car leurs paquets ICMP passent et j'y réponds. Tout comme leur DNS. Et j'ai du RTM qui remonte jusque dans le manager.

Je suspecte donc un problème de filtrage réseau quelque part dans l'infra interne OVH entre leurs machines internes et mon serveur.

Il y a des règles de filtrage dans leur infra sur le port 25 car ils ont les moyens de bloquer les machines identifiées comme envoyant du spam. Hypothèse : Si ca se trouve ils ont flaggé certains de leurs serveurs de monitoring comme spammeurs !!! Mais ils s'en appercevraient car ils auraient beaucoup de machines avec un SMTP soit disant down.

Moi je dis : #yapluka monitorer le monitoring.

Flavien
22/06/2015, 11h54
C'est confirmé de mon côté, j'ai bien épluché un tcpdump, c'est assez clair :

* de l'ARP
* du RTM
* du PING
* un peu de DNS (?)
* et c'est tout.

Donc aucune tentative de connection sur mon port 25. Et pourtant j'ai des alertes.

J'ai mis tous les détails dans le ticket 2015061219019135 : c'est pas sur le forum public qu'on va trouver la solution : c'est dans l'infra interne OVH. Donc laissons bosser les gens dont c'est le job.

Je vous tiens au courant quand j'aurai du nouveau. Pour le moment je recois mes alertes régulièrement et je crois les doigts que mon serveur ne tombe pas car je n'ai pas d'autre système de monitoring que celui d'ovh sur ce service.

Flavien
16/06/2015, 09h34
La conf firewall est OK : si mon port 25 était bloqué je ne recevrais plus de mail.
N'oublions pas que j'ai fait un tcpdump : Celui-ci capture les paquest en amont du firewall. Il montre qu'il n'y a aucune tentative de connection sur mon port 25 venant des machines indiquées.

Donc le monitoring est cassé sur mon KS : ils n'arrivent pas à me joindre pour un pb de routage (peu probable : leurs pings marchent), ils ont un firewall qui bloque leurs probes (le VAC ferait des siennes ? On parle du SMTP, ca pourrait être lié...), ou ils n'essaient pas parceque le job est planté/mal configuré (pourquoi pas), donc bref, le statut de mon serveur est toujours down pour eux, donc je recois des alertes. Alors qu'en réalité tout marche bien.

Je ne vois plus que trois solutions pour OVH :

1/ Trouver ce qui coince de leur côté et que ca remarche (yes ! yes ! yes !)
2/ Montrer que ses machines essaient de me joindre et que c'est moi qui ne réponds pas. J'attends le tcpdump avec impatience; quand je fais une bourde dans mon diagnostic j'aime bien le savoir.
3/ Supprimer le monitoring des services de son offre puisqu'il ne le supporte pas. (bof. pas très cohérent avec la tendance...)

BBR
12/06/2015, 16h44
j'sais pas, j'ai plusieurs serveurs, j'en ai eu pas mal d'autres avant ceux-là, jamais eu de problème avec le monitoring, ah si quelques faux positifs sur le port 25 mais franchement pas de quoi en faire un drame, tu as 2 autres serveurs sur lesquels ça fonctionne, alors compare tes règles de firewall et ta config avec celles qui marchent.

Flavien
12/06/2015, 16h39
Citation Envoyé par BBR
si les alertes te posent problème, tu peux désactiver le monitoring ^^
C'est bien ce que je disais : c'est une fonctionnalité qui fait partie du package. Ca marche sur 3 de mes autres serveurs. C'est tombé en rade sur celui-là sans qu'on ne demande rien à personne il y a 10 jours, donc la solution c'est de désactiver la fonctionnalité. Normal ?

BBR
12/06/2015, 15h50
si les alertes te posent problème, tu peux désactiver le monitoring ^^

Flavien
12/06/2015, 15h47
Dans la capture je ne vois que de l'ICMP et de l'ARP. Rien d'autre.
Aucune tentative de connection sur le port 25 de la part de ces machines... Qui en concluent que je ne suis pas joignable et m'alertent.

J'espère que mon service va pas tomber, parceque c'est pas les alertes OVH qui vont me faire me bouger, là...
"au loup" "je cours, je cours" "non non c'est une blague"
"au loup" "je cours, je cours" "non non c'est une blague"
"au loup" "je cours, je cours" "non non c'est une blague"
"au loup" "je cours, je cours" "non non c'est une blague"
"au loup" "ouais ca va hein, t'es gentil mais bon..."
MIAM !


Flavien
12/06/2015, 15h46
Dans la capture je ne vois que de l'ICMP et de l'ARP. Rien d'autre.
Aucune tentative de connection sur le port 25 de la part de ces machines... Qui en concluent que je ne suis pas joignable et m'alertent.

J'espère que mon service va pas tomber, parceque c'est pas les alertes OVH qui vont me faire me bouger, là...
"au loup" "je cours, je cours" "non non c'est une blague"
"au loup" "je cours, je cours" "non non c'est une blague"
"au loup" "je cours, je cours" "non non c'est une blague"
"au loup" "je cours, je cours" "non non c'est une blague"
"au loup" "ouais ca va hein, t'es gentil mais bon..."
MIAM !


Flavien
12/06/2015, 11h37
Toujours des alertes. Je mets un tcpdump avec toutes les IP en question :

nohup tcpdump -n -i eth0 -w /tmp/monitoring-ovh.cap -s 3000 net 213.186.50.98 or net 37.187.231.251 or net 213.186.33.62 or net 92.222.184.0/24 or net 92.222.185.0/24 or net 92.222.186.0/24 or net 167.114.37.0/24 or net 213.186.45.4 or net 213.251.184.9 or net 37.59.0.235 or net 8.33.137.2 or net 213.186.33.13 or net x.x.x.249 or net x.x.x.250 or net x.x.x.251 > /dev/null &

Flavien
11/06/2015, 09h35
OK. J'ajoute les règles pour autoriser l'ICMP. On va voir...

Je vous tiens au courant, je recois des alertes suffisament régulièrement pour ne pas oublier !

Fabian
10/06/2015, 13h34
La configuration du monitoring a changé.

Voilà la communication qui a été faite sur les mailing list et que je poste ici pour que tu puisses corriger les règles :

Bonjour,
Nous évoluons la plateforme de monitoring qui surveillent vos
serveurs, vos VM, vos IP FO, vos Public Cloud. La nouvelle
plateforme est installé dans 4 zones de Datacentres et surveille
l’ensemble des IP que nous administrons dans 3 directions:
- par le routeur A (le 1er gros routeurs qui gère une zone)
- par le routeur B (le 2eme gros routeurs qui gère une zone)
- par le réseau interne entre les datacentres (on l’appelle 97)
Chaque zone surveille l’ensemble des IP à partir d’une nouvelle
/24 qu’il faut whitelister sur vos infrastructures.

La mesure s’effectue aujourd’hui tous les 5 à 15 secondes et
le but est d’avoir les points tous les 2 à 3 secondes dans le
futur.

En suite, les mesures entrent dans un bigdata où on assemble
les données et on trouve les paterns c’est à dire ce qui est en
commun:
- les IP appartenant au même client
- les IP qui sont sur le même serveur
- les IP qui sont dans la même baie
- les IP qui sont sur le même routeur

Puis on cherche les anti-patern, c’est à dire les dysfonctionnements
pas de ping ou une grosse latence.

L’ensemble de 2 nous donnent les alertes où on peut voir de
micro problèmes sur un switch ou un serveur ou un routeur ou un
lien entre 2 routeurs. Et donc on va pouvoir créer les tasks travaux
très rapidement et quasiment en temps réel mais surtout informer
uniquement les clients qui sont concernés par le dysfonctionnement
directement dans le ManagerV6 et les Apps.

Pour que la mesure soit bonne, merci de mettre à jour les iptables
sur vos serveurs et les VM. On ping toutes les /16 inconditionnellement.

Dans quelques semaines, nous allons vous fournir la mesure
en temps réel dans l’API et le ManagerV6, comme le MRTG.

Le projet est plus vaste. On va attaquer en suite, 3 nouvelles
parties du projet « mon »:
- mesurer les vracks totalement privates en ICMP avec une sonde
private (comme nous le faisons avec le mutu) en respectant
le PCI-DSS
- revoir totalement le MON-TCP avec HTTP/HTTPS pour commencer
- monitorer toutes les IP d’Internet (!!) à partir de chaque DC à
travers tous les fournisseurs de transit qu’on a sur chaque
routeurs. Cela va créer plus de 40-50 vues sur chaque /24
dans le monde ce qui nous permettra de voir les pannes
mondiales mais surtout trouver par quel routeur et par quel
fournisseur de transit on a la meilleur route vers chaque IP
dans le monde. Puis monitorer cette performance 24/24.

Amicalement
Octave

/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 INPUT -i eth0 -p icmp --source IP.250 -j ACCEPT # IP = aaa.bbb.ccc obtenue selon la règle precedente
/sbin/iptables -A INPUT -i eth0 -p icmp --source IP.249 -j ACCEPT # temporaire, seulement pour serveurs HG
/sbin/iptables -A INPUT -i eth0 -p icmp --source IP.251 -j ACCEPT # IP pour system de monitoring

Flavien
08/06/2015, 16h42
Citation Envoyé par Flavien
test
Citation Envoyé par Fabian
As tu configuré le monitoring dans le manager v3 en mode simple ou en expert ?

En expert tu peux mentionner la réponse du serveur, ce qui permettra d'adapter en fonction de ta configuration.
Fabian
Je n'ai aucune configuration particulière à mettre.
Mon tcpdump ne montre pas de tentative de connection de la part de x.x.x.251.

Histoire de provoquer un refresh je suis allé sur l'interface, j'ai supprimé le monitoring en question et j'en ai créé un autre, en mettant un autre email. Je recois maintenant les alertes sur le nouvel email... Mais toujours aucune trace de tentative de connexion.

Flavien.

Fabian
08/06/2015, 11h45
As tu configuré le monitoring dans le manager v3 en mode simple ou en expert ?


En expert tu peux mentionner la réponse du serveur, ce qui permettra d'adapter en fonction de ta configuration.

Fabian

Flavien
05/06/2015, 13h50
test

Flavien
05/06/2015, 13h45
J'ai un tcpdump qui tourne depuis hier :
# nohup tcpdump -n -i eth0 -w /tmp/monitoring-ovh -s 3000 host x.x.x.251 > /dev/null &

Je vois du trafic RTM en udp toutes les minutes
Je vois de l'arp pour chopper la MAC du serveur x.x.x.251 juste avant.
J'ai fait un test bidon "telnet x.x.x.251 80" et je vois les paquets SYN (sans réponse bien sûr).
Bref. La capture semble valide.

Par contre, je ne vois aucune tentative de connection de cette machine vers mon port 25...

Pas étonnant que mon service soit considéré comme en erreur s'il n'essaie pas !

Une piste ?

Flavien
04/06/2015, 15h06
Citation Envoyé par Fabian
L'ip du monitoring sera l'ip du serveur.251 cf http://guides.ovh.com/firewall
Il faudrait voir dans les logs de ton serveur de mail, si l'ip arrive à se connecter.
Fabian
Ca tourne depuis ce matin :
# nohup tcpdump -n -i eth0 -w /tmp/monitoring-ovh -s 3000 host x.x.x.251 > /dev/null &

Je vois toutes les minutes du trafic udp qui part de chez moi : c'est le real time monitoring
Je vois du trafic ARP pour chercher la mac de la 251 juste avant. Logique.
Si je fais un volontaire : telnet X.X.X.251 80, alors je vois les paquets partir (et pas de réponse, normal. ). Donc mon tcpdump a l'air correct aussi.
Par contre, il n'y a rien d'autre. En particulier rien sur le port 25 depuis/vers cette IP.
Si j'avais un pb de firewall je verrais quand même les paquets dans le tcpdump. Je ne pense pas que ca vienne de là.

Et à part ca, je recois toujours plein de mail de plein de gens :
# grep "Jun 4 .*connect from" /var/log/mail/mail.log | wc -l
3141

Et j'ai recu une erreur tout à l'heure :

| IP | Proto | Port | Time [sec] | Status | Timestamp | Reason
+-----------------+---------+--------+-----------------+---------+---------------------------+-
| x.x.x.x | smtp | 25 | 45.002 | FAILURE | Thu Jun 4 14:40:01 2015 | Timeout
'-----------------+---------+--------+-----------------+---------+---------------------------+-



Je suis dispo pour faire plus de tests si nécessaire.

Flavien
04/06/2015, 11h44
Citation Envoyé par Fabian
L'ip du monitoring sera l'ip du serveur.251 cf http://guides.ovh.com/firewall
Il faudrait voir dans les logs de ton serveur de mail, si l'ip arrive à se connecter.

Fabian
J'ai un tcpdump qui tourne depuis 9:00 :
# nohup tcpdump -n -i eth0 -w /tmp/monitoring-ovh.cap -s 3000 host X.X.X..251 > /dev/null &
Je vois toutes les minutes quelques paquets UDP qui partent vers la 251 : c'est le real time monitoring ovh; ports 6100 à 6200.
Un peu d'ARP juste avant pour chopper la mac de la 251.
Je fais volontairement un telnet depuis ma machine vers le port 80 de X.X.X.251, et je le vois bien dans mon tcpdump.
...
Et c'est tout. Aucune tentative sur mon port 25 depuis la 251. Pas étonnant qu'elle me croie down si elle n'essaie pas !

Et à 10:36 j'ai pourtant recu un reminder comme quoi mon 25 était injoignable.

Je suis dispo pour d'autres tests si ca peut aider.

Flavien.

nowwhat
04/06/2015, 08h40
Citation Envoyé par Flavien
...
Comment est fait le test en question ? C'est juste un nmap sur mon port 25 ou ca va un peu plus loin dans le proto SMTP ? Genre un EHLO puis un QUIT par exemple ?
regarde dans ton log de ton serveur '25' (c'est ton serveur mail)

Fabian
03/06/2015, 17h32
L'ip du monitoring sera l'ip du serveur.251 cf http://guides.ovh.com/firewall
Il faudrait voir dans les logs de ton serveur de mail, si l'ip arrive à se connecter.

Fabian

Flavien
03/06/2015, 16h25
Ca continue... Et pourtant ca marche !!!
Je suis le seul ?
Comment est fait le test en question ? C'est juste un nmap sur mon port 25 ou ca va un peu plus loin dans le proto SMTP ? Genre un EHLO puis un QUIT par exemple ?

Je peux mettre un tcpdump si qqn connait l'IP du service de monitoring.

Flavien
02/06/2015, 12h09
Oui, je le teste moi-même avec un script expect qui cause SMTP depuis 3 autres IP (un autre kimsufi, un serveur du boulot et depuis mon isp perso). Et ca marche.

Et parallèlement je vois dans les logs et dans munin en local que je recois bien plusieurs centaines de mails par jour, tout au long de la journée, de plein d'IP différentes, comme d'habitude.

Donc de mon point de vue le service fonctionne. C'est pour ca que je me demande si le monitoring est bien fonctionnel.

D'un autre côté, si d'un seul coup le monitoring était en rade et prévenait tous les clients, ca se verrait dans les tableaux de bord internes OVH et ils feraient quelque chose ! Donc ca penche pour : "c'est ma machine à moi qui merde et pas le monitoring".

Ou alors c'est un bug dans le monitoring et je suis le seul à tomber dessus (parceque le SHA512 de mon IP est un palyndrome ou que sais-je... )

Flavien
02/06/2015, 12h01
Citation Envoyé par Fabian
Bonjour,

Merci de mentionner une info comme le nom du serveur, l'ip concernée, ou un numéro de commande/facture.

Fabian
Voici le numéro de facture : FR13111154

nowwhat
02/06/2015, 11h01
Bonjour,

Dès que t'as la moindre doute, il suffit de tester ton serveur toi même.
Parmi les milliers des possibilités de tester son serveur mail (il en existe plein sur le net=) : http://www.dnsinspect.com
Ou : utilise ton FAI pour te balancer un mail ......
Ou un webmail (genre gmail/outlook, hotmail ou pire)

Il est moins utile de tester l'accès vers ton serveur avec Munin, car ce test n'indus pas le chemin VERS ton serveur (entre ton serveur et un serveur mail en face il y a un truc nommé Internet qui consiste à plusieurs routeurs - si UN déconne - pour le serveur en face ton serveur n'est plus accessible [ si Internet ne trouve pas un autre chemin ])

Check quand même si t'as pas un fail2ban (outil quasi obligatoire qui devrait aussi protéger ton "porte 25") pour qu'il n'a pas bloqué l'IP du serveur d'OVH qui fait le monitoring.
Je te donne une autre explication, si tu peut garder un secret : je DDOS le serveur OVH de Monitoring. Ce serveur ne va plus recevoir les réponses des serveurs qu'il test. certains serveurs seront carrément reboot à ce moment là. (mais ... shuuut hein, faut pas le dire )

Conclusion : ce service monitoring est utile, cert, mais il ne faut pas paniquer quand il te mail - il faut vérifier d'abord. Asticuex sera d'avoir plusiers service de moniotoring.
ET sache que, quoi qu'il arrive, ces services te donnent une indication de ton serveur ET le chemin jusqu'à ton serveur.

Fabian
02/06/2015, 10h58
Bonjour,

Merci de mentionner une info comme le nom du serveur, l'ip concernée, ou un numéro de commande/facture.

Fabian

Flavien
02/06/2015, 10h36
Bonjour,

J'ai un serveur qui fait relais email (ordre de grandeur : 1000 emails forwardés par jour). Il a donc son port 25 ouvert.

OVH le monitore et depuis 3 jours je recois des alertes :

Nous vous rappelons que certains services ne fonctionnent pas correctement sur le serveur. Le
statut actuel:
.----------------------------------------------.
| OVH Service Monitoring [REMIND]
.-----------------+---------+--------+---------.
| IP | Proto | Port | Status
+-----------------+---------+--------+---------+
| 91.121.xx.xx | smtp | 25 | FAILURE
'-----------------+---------+--------+---------'


Pourtant, de mon point de vue tout continue à marcher... Je n'ai rien vu de spécial dans le monitoring munin (genre cpu qui s'affole de temps à autre, saturation de queue postfix...). Du coup, je commence à mettre en doute du test que fait OVH : est-il fiable ?
Est-ce que vous avez l'IP source depuis laquelle ils font le test ? Je pourrais mettre un tcpdump et regarder ce qui se passe. (oui, monitorer le monitoring... )