Alertes mail graylog non envoyées

[LeiJ1]

Bonjour,

J'ai paramétré des alertes sur mon flux de données afin de recevoir un mail en cas d'erreur 500.
Cela a bien fonctionné dans le passé et cela fonctionne bien aujourd'hui donc pas de soucis au niveau du paramétrage.

Le 15/10 entre 8h et 16h UTC j'ai reçu 5000 erreurs 500 dans graylog. Pour autant, notre serveur mail n'a rien reçu.

Comment m'assurer que les alertes fonctionnent correctement ?

[PierreD]

Bonjour @LeiJ1,

Merci pour l'intérêt que vous portez à Logs Data Platform.
Pourriez-vous m'indiquer le nom de votre service LDP afin que je puisse entamer un diagnostic ?

Cordialement,

[LeiJ1]

Bonjour,

Merci de la réponse rapide.
Il s'agit de ldp-qm-80879.

[PierreD]

Bonjour,

Je vous confirme l'indisponibilité du service d'alertes pendant cette période.
Celui-ci a été rétabli hier (le 15) à 18h20.

Nous allons faire le nécessaire pour que cela ne se reproduise pas.

Sincèrement désolé pour la gène occasionnée.

[LeiJ1]

Bonjour,

Je comprends que des problèmes puissent arriver mais il est tout de même très déplaisant de voir qu'un système d'alerte ne soit pas en capacité d'alerter lorsque celui-ci rencontre un problème...

Comment peut-on suivre automatiquement l'état de ce service ?

[PierreD]

Bonjour,

Malheureusement en l'état, je ne peux pas vous proposer mieux que cette section de la page travaux: http://travaux.ovh.net/?project=29&status=all&perpage=50 sur laquelle nous indiquons aussi les incidents de notre service.
Nous avons mis à jour notre système de supervision pour couvrir le cas que vous avez rencontré et allons d'ici peu aussi sonder la chaine toutes les 5 minutes.
En cas de dysfonctionnement on déclenchera une tâche travaux.

[LeiJ1]

Bonjour,

Merci pour la réactivité.

Pour information le Kafka sur lequel les logs sont envoyés par logstash est indisponible depuis ce matin 9h30 UTC. Voici les logs retourné par logstash depuis le manager OVH : http://prntscr.com/l7irtf

[VincentT1]

Bonjour,

Ce message est trompeur ici, le serveur kafka est bien présent, mais rejette le message. Le plus probable est qu'une partie de vos logs que vous tentez d'envoyer est plus gros qu'une des limites autorisées:

• Taille totale du message supérieur à 1 MBytes.
• Champ supérieur à 4096 Bytes.
• Contenue du champ supérieur à 32766 Bytes.

Nous vous recommandons l'utilisation du filtre logstash truncate pour limiter la taille maximal de vos messages, par exemple:
truncate {
fields => ["message"]
length_bytes => 30000
}

Cordialement,

[LeiJ1]

Bonjour,

Effectivement le problème était dû à la longueur d'un message.
En revanche, tous nos logs étaient bloqués à cause de cela (le reste des logs envoyés à logstash n'étaient pas envoyés à kafka).

Y a t-il un paramétrage que l'on peut modifier pour limiter les tentatives d'envoi ou alors tout de même envoyer les autres logs s'il y en a 1 qui rencontre un problème ?

[VincentT1]

Bonjour,

Nous vous recommandons dans votre usage de truncate également les champs "json_message" et "response_content_urls", tel que:
truncate {
fields => ["message","json_message","response_content_urls"]
length_bytes => 30000
}

Par défaut logstash recommence à l'infini (1 message en retry ne bloque pas le reste de la queue), mais si trop de messages s'accumulent dans la queue output, elle peut-être saturée et ne plus traiter de message (il faut un dépassement de 1GiB de le queue).
Aujourd'hui nous appliquons la politique par défaut de retry à l'infini quand un problème d'envoi vers kafka est détecté.
Des modifications sont en cours dans le plugin kafka-output https://github.com/logstash-plugins/logstash-output-kafka/pull/194 pour gérer ce cas (quand le message est trop large pour ne pas le renvoyer à l'infini), quand cette modification sera présente upstream, nous l'appliquerons sur la plateforme.

[LeiJ1]

Bonjour,

Nous avons fais la modification, merci du conseil.
Avec le truncate nous devrions avoir plus de mal à atteindre 1Go dans la queue.