Re: [FRnOG] [TECH] Collecteur de logs réseau
+1 pour ne pas confondre 'time series" (TSDB) fait pour accumuler des metrics (compteurs,etc) genre utilisation cpu ou température avec l'indexation et le stockage de logs (document database). Sinon pour convertir des logs en metrics, il y a mtail ( https://github.com/google/mtail ) ou grok-exporter ( https://github.com/fstab/grok_exporter ) mtail est particulièrement simple et efficace, on peut matcher la chaine 'Port x disconnected' par exemple pour extraire le 'x' et en faire un metric. On Mon, Nov 19, 2018 at 2:39 AM DUVERGIER Claude mailto:frnog...@claude.duvergier.fr>> wrote: Je m'incruste... > Comme je disais il ne faut pas. Il faudrait plutôt commencer par > transformer tes logs/déclencheurs en métriques. Après tout devient > plus clair. Je suis assez d'accord avec cette idée mais il n'est pas toujours aisé de transformer un message d'événement : * "Port x disconnected" * "User x logged-in" * etc. En métrique : * "port_x_connected=false" * "port_x_disconnection_count=42" * "user_x_logged=true" * "user_x_login_count=666" Soit parce qu'on a pas le contrôle sur le générateur de l'événement (équipement fermé) soit parce qu'on pense que ça n'est pas à l'application instrumenté de se souvenir des événements -nombre d'authentification- pour les transformer en métriques). Donc je me demande si vous n'auriez pas 2/3 suggestions de solution (logiques ou logicielles) à ce "problème"... -- Duvergier Claude Le 18/11/2018 à 17:41, Raphael Mazelier a écrit : > >> >> Pas d'accord. ES est tellement plus gourmand, en stockage, IO et CPU, >> par rapport à une time-series basique, que c'est totalement >> disproportionné. > > Désolé mon petit José mais je crois qu'on confond un peu tout la ;) > > ES et une TSDB ce sont bien évidement deux type d'outils complètement > différends qui sont parfois employé/dévoyé de leur fonction originale. > > > En très gros résumé : > > - on stocke des métriques dans un tsdb et on fait des graphs et de > l'alerting avec. Prometheux/Influxdb sont les candidats du moment. > > - on on stocke des documents indexés dans ES, parfait pour stocker des > logs structurés et faire des queries dedans. > > Ce qui embrouille tout c'est que l'on essaye de faire des graphs et de > l'alerting avec des logs, ce qui est théoriquement assez faux. > >> >> C'est pratique à mettre en place et exploitable à petite échelle, mais >> à mon avis pas satisfaisant dès que tu as une vraie prod. Et je suis >> vraiment preneur d'avis dessus, vu que je vais devoir y bosser à >> nouveau prochainement. > > ES est le truc le plus scalable du monde. Je connais des petites société > smart qui exploitent sereinement des clusters de plusieurs Peta. > >> >> Reste à assurer la corrélation d’évènements, et le déclenchement >> d'alertes sur certains combos, mais là on rentre dans du compliqué. >> Tendance obligatoirement du code custom. Sauf si vous avez trouvé >> autre chose ? > > Comme je disais il ne faut pas. Il faudrait plutôt commencer par > transformer tes logs/déclencheurs en métriques. Après tout devient plus > clair. > > Cdt, > > -- > Raphael Mazelier > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Ordinateur refroidi au Stroh
> Pierre Emeriaud a écrit : > pfff, truc de petits joueurs ça. Balance ta chaleur dans ta dalle de béton, > c'est plus efficace : Ah ouai ouai, en Sibérie c'est le nec plus ultra du overclocking. Pas besoin de clim dans ton datacenter, t'às qu'à ouvrir la fenêtre. > Jérôme Nicolle a écrit : > Bon, comme tu as parlé de glycol, on est obligé de parler de watercooling - > au moins dans les grandes > lignes. Et tu vas être déçu, passer sous la température ambiante impose de > sales bricolages. Exactement l'inverse de ce que je voulais lire, mais bon je m'y attendais aussi. > Sur tous mes montages en refroidissement liquide j'ai utilisé du 3M Fluorinet Un très bon produit avec une longue histoire : c'est le successeur de ce qui était utilisé dans la série des Cray, on peut tremper la carte mère dedans pour refroidir. C'est pas bon marché, ceci dit. Très bon produit, mais cher. Le glycol antifreeze que tu mets dans ta bagnole, à condition de pas immerger le biniou dedans, c'est nettement plus accessible. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Collecteur de logs réseau
Je m'incruste... > Comme je disais il ne faut pas. Il faudrait plutôt commencer par > transformer tes logs/déclencheurs en métriques. Après tout devient > plus clair. Je suis assez d'accord avec cette idée mais il n'est pas toujours aisé de transformer un message d'événement : * "Port x disconnected" * "User x logged-in" * etc. En métrique : * "port_x_connected=false" * "port_x_disconnection_count=42" * "user_x_logged=true" * "user_x_login_count=666" Soit parce qu'on a pas le contrôle sur le générateur de l'événement (équipement fermé) soit parce qu'on pense que ça n'est pas à l'application instrumenté de se souvenir des événements -nombre d'authentification- pour les transformer en métriques). Donc je me demande si vous n'auriez pas 2/3 suggestions de solution (logiques ou logicielles) à ce "problème"... -- Duvergier Claude Le 18/11/2018 à 17:41, Raphael Mazelier a écrit : > >> >> Pas d'accord. ES est tellement plus gourmand, en stockage, IO et CPU, >> par rapport à une time-series basique, que c'est totalement >> disproportionné. > > Désolé mon petit José mais je crois qu'on confond un peu tout la ;) > > ES et une TSDB ce sont bien évidement deux type d'outils complètement > différends qui sont parfois employé/dévoyé de leur fonction originale. > > > En très gros résumé : > > - on stocke des métriques dans un tsdb et on fait des graphs et de > l'alerting avec. Prometheux/Influxdb sont les candidats du moment. > > - on on stocke des documents indexés dans ES, parfait pour stocker des > logs structurés et faire des queries dedans. > > Ce qui embrouille tout c'est que l'on essaye de faire des graphs et de > l'alerting avec des logs, ce qui est théoriquement assez faux. > >> >> C'est pratique à mettre en place et exploitable à petite échelle, mais >> à mon avis pas satisfaisant dès que tu as une vraie prod. Et je suis >> vraiment preneur d'avis dessus, vu que je vais devoir y bosser à >> nouveau prochainement. > > ES est le truc le plus scalable du monde. Je connais des petites société > smart qui exploitent sereinement des clusters de plusieurs Peta. > >> >> Reste à assurer la corrélation d’évènements, et le déclenchement >> d'alertes sur certains combos, mais là on rentre dans du compliqué. >> Tendance obligatoirement du code custom. Sauf si vous avez trouvé >> autre chose ? > > Comme je disais il ne faut pas. Il faudrait plutôt commencer par > transformer tes logs/déclencheurs en métriques. Après tout devient plus > clair. > > Cdt, > > -- > Raphael Mazelier > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Collecteur de logs réseau
Pas d'accord. ES est tellement plus gourmand, en stockage, IO et CPU, par rapport à une time-series basique, que c'est totalement disproportionné. Désolé mon petit José mais je crois qu'on confond un peu tout la ;) ES et une TSDB ce sont bien évidement deux type d'outils complètement différends qui sont parfois employé/dévoyé de leur fonction originale. En très gros résumé : - on stocke des métriques dans un tsdb et on fait des graphs et de l'alerting avec. Prometheux/Influxdb sont les candidats du moment. - on on stocke des documents indexés dans ES, parfait pour stocker des logs structurés et faire des queries dedans. Ce qui embrouille tout c'est que l'on essaye de faire des graphs et de l'alerting avec des logs, ce qui est théoriquement assez faux. C'est pratique à mettre en place et exploitable à petite échelle, mais à mon avis pas satisfaisant dès que tu as une vraie prod. Et je suis vraiment preneur d'avis dessus, vu que je vais devoir y bosser à nouveau prochainement. ES est le truc le plus scalable du monde. Je connais des petites société smart qui exploitent sereinement des clusters de plusieurs Peta. Reste à assurer la corrélation d’évènements, et le déclenchement d'alertes sur certains combos, mais là on rentre dans du compliqué. Tendance obligatoirement du code custom. Sauf si vous avez trouvé autre chose ? Comme je disais il ne faut pas. Il faudrait plutôt commencer par transformer tes logs/déclencheurs en métriques. Après tout devient plus clair. Cdt, -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] Panne SFR nationale ??
Merci Jérôme pour ce retour -Message d'origine- De : Jérôme Nicolle Envoyé : dimanche 18 novembre 2018 04:42 À : frnog@frnog.org Objet : Re: [FRnOG] [MISC] Panne SFR nationale ?? Xavier, Globalement leur réponse paraît correcte et proportionnée. Il y a eu un double incident affectant 1-4% de la SIG voix, et 1-3% des accès fixes, de ce que j'ai pu voir. Et c'est remonté progressivement dans la journée, tendance presque conforme aux SLA contractuels. Franchement rien à redire sur ce coup là, sauf potentiellement quelques cas résiduels… @+ Le 15/11/2018 à 18:05, Xavier ROCA a écrit : > Salut Alain, > > Les deux selon leur communication que voici : > > [Suivi de l'Incident Générique] > Nous avons rencontré un Incident Générique sur tout la France impactant les > services Data Fixe, Voix Fixe depuis le 15/11/2018 01:30. Nos équipes se sont > immédiatement mobilisés en conf de crise pour remonter l'ensemble des > services. > Les services voix sont remontés progressivement entre 8h40, pour un > rétablissement complet avant 10h. > Nous avons appliqué la solution mis en place avec le constructeur pour > résoudre l'incident majeur ce qui a permis de réduire considérablement > l'impact en début d'après-midi. Le reste de l'impact a nécessité une > intervention sur site et nous constatons le retour progressif des sites > restants. Le rétablissement définitif devrait avoir lieux avant 18h. > Prochain point de situation à 18h00 > Nous vous assurons de notre engagement afin de rétablir les services le plus > rapidement possible. > Cdt, > [STC 2*8 SFR Business] > > > > > > -Message d'origine- > De : Alain Bieuzent Envoyé : jeudi 15 > novembre 2018 17:46 À : Xavier ROCA ; 'frnog-misc' > Objet : Re: [FRnOG] [MISC] Panne SFR nationale > ?? > > Salut Xavier, > > Panne voix ou data ? > > A+ > > On 15/11/2018 17:43, "[NAME]" <[ADDRESS]> wrote: > > Bonjour, > > > > Etant en copie du suivi d’incident (STC) pour certains clients en contrat > avec SFR, je vois passer des mails depuis ce matin sur une panne qui > selon > SFR est nationale. > > Apparemment depuis 01h30 ce jour et pas complétement résolue, prochain > point > vers 18h00 > > > > Ce qui m’étonne c’est le silence sur ce sujet ici, la liste serait > devenue > très sage ? > > Certains confirment ou c’est juste un gros prétexte sortie à un de leur > très > gros client ? > > > > Xavier > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > > > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Jérôme Nicolle +33 6 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Ordinateur refroidi au Stroh
Le dim. 18 nov. 2018 à 05:07, Jérôme Nicolle a écrit : > > Sur l'échangeur, le mythe veut qu'on recycle des radiateurs d'Opel > Corsa, mais c'est clairement pas le plus pratique. Je préfère mettre > plusieurs petits radiateurs commerciaux d'overclocker en parallèle > (genre du 120x120 à 120x360), ils sont globalement mieux finis et ça pue > pas l'huile cramée. pfff, truc de petits joueurs ça. Balance ta chaleur dans ta dalle de béton, c'est plus efficace : https://forums.overclockers.com.au/threads/concrete-slab-water-cooler-loop-hooked-up.800958/ Sinon y'a toujours la solution géothermie : https://mcuoneclipse.com/2013/07/13/hacking-the-heating-system-for-cooling-geothermal-drilling-with-extra-benefits/ --- Liste de diffusion du FRnOG http://www.frnog.org/
