[FRsAG] Re: Qui pour remplacer Nagios en 2022 ?

2022-07-26 Par sujet Renaud Galante

Hello,

Ca me rassure, je ne suis pas le seul à m'interroger sur ce point.
Mais je n'ai toujours pas trouvé mieux pour le moment.

J'ai 1400 hosts et 9100 check sur nagios, avec a peu pres tout ce qui 
peut exister en protocol de supervision derrière
Un thruk par dessus pour rendre l'utilisation de l'interface web plus 
agréable, et aussi profiter de l'API rest pour interroger l'état de 
plusieurs nagios.

Et toute ma conf est généré par fabric

J'ai tenté zabbix, qui me parait un excellent outil et coté UI 
clairement plus avancé, mais l'effort de migration me parait trop lourd 
par rapport à ce que ca peut m'apporter.
Icinga2 fait le taf aussi, leur système de conf est assez sympa, mais 
quand on génère la conf, au final, ca ne sert pas à grand chose..


Je vais probablement migrer vers naemon prochainement (ca reste un fork 
de nagios, donc toute ma conf marche sans rien faire), tout simplement 
parce que thruk a besoin de livestatus, dont je ne trouve plus de trace 
depuis l’apparition de checkmk.


Librenms reste hors course pour moi dès qu'on veut faire de la 
volumétrie. Je ne l'utilise que pour les équipements réseaux en tout cas


Donc pour ma part, je vais certainement rester sur du nagios like, et 
tant pis si l'interface est naze 

Sauf si la perle rare ressort de ce thread .

Reno.

Le 26/07/2022 à 17:46, Wallace a écrit :


Bonjour,

On a tenté de remplacer Nagios / Munin / Observium par Prometheus / 
Grafana, dans les faits ce sont deux approches complètement 
différentes et certaines actions ne sont tout simplement pas possibles.


Du coup on a automatisé notre Nagios, il se base sur les mêmes 
informations que Prometheus (qu'il ne serait pas viable de faire à la 
main). Je pense effectivement comme toi à tous les checks de ports, de 
connexion smtp, imap, https, vérification de certificats, de contenu 
dans des pages web, vérification de crontabs, ...


Et au final ça marche très bien, ça consomme très peu de cpu / ram 
(Nagios est mine de rien sacrément optimisé pour encaisser beaucoup de 
charge).


Et puis le problème des agents Zabbix on le retrouve également avec 
les métrics Prometheus que beaucoup d'équipements / logiciels 
n'implémentent pas encore. Quand c'est logiciel on les a codé, quand 
c'est équipement tu peux rien faire. Donc même la partie métrologie 
n'est pas complètement remplacé encore.


Concernant l'automatisation, pas besoin d'API, c'est plus simple de 
fabriquer en IaC les fichiers de configuration et gérer les 
changements et faire un reload. Alors que vérifier par API que tout 
est comme tu le veux sur une infras conséquente ça fait tout de suite 
énormément de requêtes API qui vont durer des plombes pour vérifier la 
conformité.


Voilà notre point de vue.

Le 26/07/2022 à 17:32, Mickael MONSIEUR a écrit :

Bonjour,

Suite à une mise à jour des systèmes, on a décidé de remplacer par la
même occasion notre Nagios par quelque chose d'un peu plus
"user-friendly". (et pourtant c'est un demi barbu qui parle..)

Vous me demanderez ce qu'on a contre Nagios? En 15 ans, ça n'a pas
vraiment évolué, et on aimerait bien quelque chose avec un minimum de
GUI pour l'encodage, voir une API. Et mettre 2k/an dans la version XI
pour un soft qui n'évolue presque pas... bof.

Notre besoin est plutôt simple, on a déjà Observium qui fait 90% de
nos besoins au sein de notre réseau, mais Observium ne permet pas
"facilement" de monitorer "juste" des ports TCP, du SMTP/POP/IMAP, des
réponses DNS, des réponses HTML dans une page HTTPS, l'expiration d'un
certificat TLS.

Au début on pensait à Zabbix, mais quand on voit que ça passe d'office
par un agent, on en voit pas l'utilité. Observium fait déjà tout ça en
SNMP, et certaines machines ne sont pas gérées par nous on doit juste
les monitorer de l'extérieur, donc installation impossible.

Les seules conditions qu'on a c'est : open source, sans agent, et pas
dans un langage RAM killer comme Java.

Mickael
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/


___
Liste de diffusion du %(real_name)s
http://www.frsag.org/
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

Re: [FRsAG] Grub rescue rootfs sur plusieurs disques

2021-06-04 Par sujet Renaud Galante
J'ai finalement trouvé la réponse pour faire fonctionner cela avec
virtio-scsi-pci:

https://forum.proxmox.com/threads/regression-pve-qemu-kvm-5-1-fail-to-boot-vm-grub-rescue.78811/

Il fallait que je rajoute le disque dans la liste des disques bootable,
sinon seabios ne les charge pas

Merci en tout cas !

Reno.

Le 04/06/2021 à 13:22, Renaud Galante a écrit :
> Merci pour les réponses.
>
> Je n'avais pas testé le changement de controlleur disque sur la vm.
> Je suis passé de virtio-scsi-pci (proposé par défault dans proxmox) à
> lsi et cela fonctionne, ma vm démarre bien.
>
> Je vais voir si j'arrive à trouver une explication plus précise.
>
>
> Reno.
> Le 04/06/2021 à 12:59, Pierre Bourgin a écrit :
>> autre piste: Côté hyperviseur, peut-etre une sensibilité au "BIOS"
>> émulé par proxmox ou VMware ?
>>
>> booter ta VM avec un ISO live les commandes lsblk, blkid & co
>> permettrait peut-etre aussi de se faire une idée ?
>>
>> On 6/4/21 12:55 PM, Pierre Bourgin wrote:
>>> oula, j'ai pas vu que tu atterissais dans *grub*, pardon.
>>>
>>> c'est quelle version de grub ?
>>>
>>> faut peut-etre generer grub après avoir rajouté ton 2e disque dans
>>> ta conf LVM ?
>>>
>>> On 6/4/21 12:47 PM, Pierre Bourgin wrote:
>>>> hello,
>>>>
>>>> On 6/4/21 11:59 AM, Renaud Galante wrote:
>>>>> Bonjour à tous
>>>>>
>>>>> J'ai un petit problème à vous soumettre.
>>>>>
>>>>> Au redémarrage d'une vm sous debian, j'ai le message d'erreur
>>>>> suivant dès le chargement de grub (le menu n’apparaît pas)
>>>>>
>>>>> error: disk 'lvmid//Y' not found
>>>>>
>>>>> et j’atterris dans le grub rescue.
>>>>
>>>> donc l'id LVM est bien référencé dans ton env mais pas trouvé.
>>>> Peut-etre que le disque qui contient ce qui manque n'est pas détecté ?
>>>>
>>>> Pour t'y retrouver, essaye les commandes pour déterminer si ca
>>>> vient d'un disque non vu, puis du LVM physical volume qui est censé
>>>> être dessus, puis des LVM vg et enfin du LVM lv.
>>>>
>>>>
>>>> - lsblk : liste les "block devices" qui sont visibles (disques,
>>>> partitions, LVM LV)
>>>> - blkid : liste les uuid
>>>> - pvdisplay : qu'en pense-t-il ?
>>>> - vgdisplay : qu'en pense-t-il ?
>>>> - pvscan : pleins d'options, notamment "mettre à jour le cache"
>>>> - vgscan:  (idem pvscan)
>>>>
>>>>> Pour reproduire le problème, je suis dans les conditions suivantes:
>>>>>   - Ma partition / est un LV situé sur 2 disques (il y avait un
>>>>> seul disque à l'origine, mais un deuxième a été rajouté par la
>>>>> suite suite à un soucis d'espace)
>>>>>   - Je n'ai pas de /boot dédié
>>>>>   - La VM tourne sous proxmox
>>>>>
>>>>> Le message est certainement dû au fait que le deuxième disque ne
>>>>> soit pas "lu" au démarrage. J'ai testé différentes configs pour le
>>>>> deuxième disque, à savoir coté LVM ce disque est intégré
>>>>> entièrement (donc pas de partition) ou alors un partitionnement de
>>>>> type dos et gpt,suivi d'un grub-install sur le nouveau disque
>>>>
>>>> il faut vérifier dans l'ordre: les LVM Physical Volume, puis LVM vg
>>>> et enfin LVM lv.
>>>>
>>>>> Je reproduis ce cas sur des vms vierges avec une install debian
>>>>> (buster et bullseye) toute fresh.
>>>>> Dès que je rajoute un disque supplémentaire et que je le rajoute à
>>>>> ma partition / avec toutes les opérations lvm qui vont bien, au
>>>>> reboot, j'atteris sur le grub rescue.
>>>>>
>>>>> Cependant, si je réalise cette même opération sous vmware, la vm
>>>>> redémarre bien.
>>>>>
>>>>> Mon problème est vite résolu en agrandissant directement le disque
>>>>> principal, en créant une nouvelle partition, ou en agrandissant la
>>>>> partition si cela est possible, mais je trouve cela tellement plus
>>>>> simple et sécurisant de le faire par lvm. Et cela rend la
>>>>> réduction d'espace plus simple aussi dans le cas de besoin
>>>>> d'espace temporaire et que le client est incapable de mettre
>>>>> toutes ces données à un endroit particulier.

Re: [FRsAG] Grub rescue rootfs sur plusieurs disques

2021-06-04 Par sujet Renaud Galante
Merci pour les réponses.

Je n'avais pas testé le changement de controlleur disque sur la vm.
Je suis passé de virtio-scsi-pci (proposé par défault dans proxmox) à
lsi et cela fonctionne, ma vm démarre bien.

Je vais voir si j'arrive à trouver une explication plus précise.


Reno.

Le 04/06/2021 à 12:59, Pierre Bourgin a écrit :
> autre piste: Côté hyperviseur, peut-etre une sensibilité au "BIOS"
> émulé par proxmox ou VMware ?
>
> booter ta VM avec un ISO live les commandes lsblk, blkid & co
> permettrait peut-etre aussi de se faire une idée ?
>
> On 6/4/21 12:55 PM, Pierre Bourgin wrote:
>> oula, j'ai pas vu que tu atterissais dans *grub*, pardon.
>>
>> c'est quelle version de grub ?
>>
>> faut peut-etre generer grub après avoir rajouté ton 2e disque dans ta
>> conf LVM ?
>>
>> On 6/4/21 12:47 PM, Pierre Bourgin wrote:
>>> hello,
>>>
>>> On 6/4/21 11:59 AM, Renaud Galante wrote:
>>>> Bonjour à tous
>>>>
>>>> J'ai un petit problème à vous soumettre.
>>>>
>>>> Au redémarrage d'une vm sous debian, j'ai le message d'erreur
>>>> suivant dès le chargement de grub (le menu n’apparaît pas)
>>>>
>>>> error: disk 'lvmid//Y' not found
>>>>
>>>> et j’atterris dans le grub rescue.
>>>
>>> donc l'id LVM est bien référencé dans ton env mais pas trouvé.
>>> Peut-etre que le disque qui contient ce qui manque n'est pas détecté ?
>>>
>>> Pour t'y retrouver, essaye les commandes pour déterminer si ca vient
>>> d'un disque non vu, puis du LVM physical volume qui est censé être
>>> dessus, puis des LVM vg et enfin du LVM lv.
>>>
>>>
>>> - lsblk : liste les "block devices" qui sont visibles (disques,
>>> partitions, LVM LV)
>>> - blkid : liste les uuid
>>> - pvdisplay : qu'en pense-t-il ?
>>> - vgdisplay : qu'en pense-t-il ?
>>> - pvscan : pleins d'options, notamment "mettre à jour le cache"
>>> - vgscan:  (idem pvscan)
>>>
>>>> Pour reproduire le problème, je suis dans les conditions suivantes:
>>>>   - Ma partition / est un LV situé sur 2 disques (il y avait un
>>>> seul disque à l'origine, mais un deuxième a été rajouté par la
>>>> suite suite à un soucis d'espace)
>>>>   - Je n'ai pas de /boot dédié
>>>>   - La VM tourne sous proxmox
>>>>
>>>> Le message est certainement dû au fait que le deuxième disque ne
>>>> soit pas "lu" au démarrage. J'ai testé différentes configs pour le
>>>> deuxième disque, à savoir coté LVM ce disque est intégré
>>>> entièrement (donc pas de partition) ou alors un partitionnement de
>>>> type dos et gpt,suivi d'un grub-install sur le nouveau disque
>>>
>>> il faut vérifier dans l'ordre: les LVM Physical Volume, puis LVM vg
>>> et enfin LVM lv.
>>>
>>>> Je reproduis ce cas sur des vms vierges avec une install debian
>>>> (buster et bullseye) toute fresh.
>>>> Dès que je rajoute un disque supplémentaire et que je le rajoute à
>>>> ma partition / avec toutes les opérations lvm qui vont bien, au
>>>> reboot, j'atteris sur le grub rescue.
>>>>
>>>> Cependant, si je réalise cette même opération sous vmware, la vm
>>>> redémarre bien.
>>>>
>>>> Mon problème est vite résolu en agrandissant directement le disque
>>>> principal, en créant une nouvelle partition, ou en agrandissant la
>>>> partition si cela est possible, mais je trouve cela tellement plus
>>>> simple et sécurisant de le faire par lvm. Et cela rend la réduction
>>>> d'espace plus simple aussi dans le cas de besoin d'espace
>>>> temporaire et que le client est incapable de mettre toutes ces
>>>> données à un endroit particulier.
>>>>
>>>> Je me demande donc ce qui pourrait expliquer cette différence de
>>>> comportement entre 2 techno différentes (KVM et vmware) et s'il y a
>>>> un moyen de faire fonctionner ce principe avec proxmox / kvm
>>>
>>> si il y a une différence, c'est la "présentation" des disques de
>>> l'enveloppe de virtu à l'OS qu'elle contient.
>>>
>>> si les 2 disques sont sur 2 type de controlleurs differents sous
>>> promox, peut-etre que tu n'a pas le driver du 2e controlleur dans
>>> l'initramfs de ton OS ? ce serait vraiment tordu mais bon ...
>>>
>>> Anecdote: avec RHV (kvm/qemu sauce Red Hat), il arrive que y'ai des
>>> échanges de nom de disque apres reboot vu depuis l'OS, genre sdb
>>> devient sdc, et sdc devient sdb.
>>> Heureusement avec LVM et les uuid, on survit (le nom de disque n'a
>>> presque plus d'importance)
>>>
>>>> SI quelqu'un a une idée,
>>>>
>>>>
>>>> Merci et bon vendredi à tous !
>>>>
>>>> Reno.
>>>>
>>>>
>>>> ___
>>>> Liste de diffusion du FRsAG
>>>> http://www.frsag.org/
>>>>
>>> ___
>>> Liste de diffusion du FRsAG
>>> http://www.frsag.org/

___
Liste de diffusion du FRsAG
http://www.frsag.org/


[FRsAG] Grub rescue rootfs sur plusieurs disques

2021-06-04 Par sujet Renaud Galante
Bonjour à tous

J'ai un petit problème à vous soumettre.

Au redémarrage d'une vm sous debian, j'ai le message d'erreur suivant
dès le chargement de grub (le menu n’apparaît pas)

error: disk 'lvmid//Y' not found

et j’atterris dans le grub rescue.

Pour reproduire le problème, je suis dans les conditions suivantes:
 - Ma partition / est un LV situé sur 2 disques (il y avait un seul
disque à l'origine, mais un deuxième a été rajouté par la suite suite à
un soucis d'espace)
 - Je n'ai pas de /boot dédié
 - La VM tourne sous proxmox

Le message est certainement dû au fait que le deuxième disque ne soit
pas "lu" au démarrage. J'ai testé différentes configs pour le deuxième
disque, à savoir coté LVM ce disque est intégré entièrement (donc pas de
partition) ou alors un partitionnement de type dos et gpt,suivi d'un
grub-install sur le nouveau disque

Je reproduis ce cas sur des vms vierges avec une install debian (buster
et bullseye) toute fresh.
Dès que je rajoute un disque supplémentaire et que je le rajoute à ma
partition / avec toutes les opérations lvm qui vont bien, au reboot,
j'atteris sur le grub rescue.

Cependant, si je réalise cette même opération sous vmware, la vm
redémarre bien.

Mon problème est vite résolu en agrandissant directement le disque
principal, en créant une nouvelle partition, ou en agrandissant la
partition si cela est possible, mais je trouve cela tellement plus
simple et sécurisant de le faire par lvm. Et cela rend la réduction
d'espace plus simple aussi dans le cas de besoin d'espace temporaire et
que le client est incapable de mettre toutes ces données à un endroit
particulier.


Je me demande donc ce qui pourrait expliquer cette différence de
comportement entre 2 techno différentes (KVM et vmware) et s'il y a un
moyen de faire fonctionner ce principe avec proxmox / kvm

SI quelqu'un a une idée,


Merci et bon vendredi à tous !

Reno.

___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] ISCSI vs NFS

2017-06-25 Par sujet Renaud Galante

Petite précision pour le cas proxmox.

SI on fait du iSCSI, le disque présenté aux serveurs proxmox devra être 
en LVM. Et il y aura un LV par VM.


Ce qui est naze, c'est qu'en faisant cela, on a pas de snapshot de VM 
niveau proxmox. On pourrait utiliser le LVM Thin, qui autorise les 
snapshot de VM,


sauf que le disque lv thin est considéré comme local (normal dans la 
logique lvm, un volume thin provisionning est un LV (qui en contient 
d'autre), donc actif à un instant T sur une seule ressource ...)


Donc dans ce cas, impossible de migrer la VM sur un  autre host.

Donc si tu n'as pas besoin de snapshot de VM, part sur iscsi / LVM, 
sinon, un nfs avec des disques qcow2 par VM, c'est très bien. Après; le 
iscsi, ca peut être galère au début, y'a plein de pièges dans le quel il 
ne faut pas tomber, mais ca c'est un autre débat :-D




Reno.

Le 24/06/2017 à 21:01, Colin J. Brigato a écrit :

Pour du container alors la par contre je dirais ni l'un ni l'autre ; un
container ne devrait pas avoir besoin de stockage persistent, ou alors
du stockage objet (S3 like).


:s,container,container\ Docker,

Sans animosité aucune mais les “containers” existent depuis bien avant 
l’usage spécifique "Dockeresque"d’aujourd’hui, et ceux-ci méritaient 
en général tout autant un stockage persistant, du coup.


Et sinon pour le “ou alors du stockage objet”, ca reste une couche de 
présentation :  si c’est que ca qui chiffonne et qu’on à de vieilles 
habitudes : s3fs, riofs, ou meme goofys – pour l’empreinte plus 
"container-rationel” même s’il est lent, pour ne citer qu’eux.


P’tet meme qu’on peut stocker des images disques pour [insérez une 
techno de virtu ici] et monter du S3 sur l’hyperviseur. Juste pour rire.


--Colin



___
Liste de diffusion du FRsAG
http://www.frsag.org/


___
Liste de diffusion du FRsAG
http://www.frsag.org/

[FRsAG] JBoss EAP 6.2.0 en domaine - démarrer 10 JVms ?

2015-06-23 Par sujet Renaud Galante

Bonjour à tous.

J'ai un Jboss EAP 6.2 avec un domain controller et un host controller.
Le host controller est paramétré pour démarrer 10 JVMs du même groupe 
d'application. Il n'y a aucune application de déployée, je cherche juste 
à démarrer les JVM.


Les premières JVM démarrent bien, mais arrivé à la 7ême, ca pose problème:

[Server:node7] 16:28:12,580 ERROR 
[org.jboss.as.controller.management-operation] (Controller Boot Thread) 
JBAS014612: Operation (parallel-subsystem-boot) failed - address: 
([]): java.lang.OutOfMemoryError: unable to create new native thread


J'ai vraiment du mal à comprendre la limite qui est atteinte.
Un OutOfMemory sur une JVM qui démarre et qui ne fait rien, j'ai du mal 
à comprendre.


Y'a t'il un tuning particulier à effectuer sur le host controller pour 
faire tourner 10 JVMs en même temps ?


Je précise aussi que si j'en démarre 5 au lancement du Host Controller, 
j'ai le même souci sur 2 ou 3 JVM, mais je suis capable de les relancer 
à la main après...



Pour les infos techniques:
$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.6 (Santiago)
$ java -version
java version 1.7.0_79
Java(TM) SE Runtime Environment (build 1.7.0_79-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)
$cat /proc/meminfo |grep MemTotal
MemTotal:   49370036 kB

Les JVM sont à 2Go, mais même à 1Go, j'ai le même phénomène.

Merci d'avance pour vos réponses.

PS: J'ai fait ouvrir en parallèle un ticket chez Red Hat, mais je tente 
ici au cas où pour un avoir un retour d'expérience.



--
Nul ne sera l'objet d'immixtions arbitraires dans sa vie privée, sa 
famille, son domicile
ou sa correspondance, ni d'atteintes à son honneur et à sa réputation. 
Toute personne a droit
à la protection de la loi contre de telles immixtions ou de telles 
atteintes.

Article 12 de la déclaration universelle des droits de l'homme
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] JBoss EAP 6.2.0 en domaine - démarrer 10 JVms ?

2015-06-23 Par sujet Renaud Galante

Quand on cherche, on trouve...

Donc pour info, c'était les limites de thread linux.

https://docs.jboss.org/author/display/RHQ47/Starting+Multiple+JBoss+AS+Instances



Le 23/06/2015 16:52, Renaud Galante a écrit :

Bonjour à tous.

J'ai un Jboss EAP 6.2 avec un domain controller et un host controller.
Le host controller est paramétré pour démarrer 10 JVMs du même groupe
d'application. Il n'y a aucune application de déployée, je cherche juste
à démarrer les JVM.

Les premières JVM démarrent bien, mais arrivé à la 7ême, ca pose problème:

[Server:node7] 16:28:12,580 ERROR
[org.jboss.as.controller.management-operation] (Controller Boot Thread)
JBAS014612: Operation (parallel-subsystem-boot) failed - address:
([]): java.lang.OutOfMemoryError: unable to create new native thread

J'ai vraiment du mal à comprendre la limite qui est atteinte.
Un OutOfMemory sur une JVM qui démarre et qui ne fait rien, j'ai du mal
à comprendre.

Y'a t'il un tuning particulier à effectuer sur le host controller pour
faire tourner 10 JVMs en même temps ?

Je précise aussi que si j'en démarre 5 au lancement du Host Controller,
j'ai le même souci sur 2 ou 3 JVM, mais je suis capable de les relancer
à la main après...


Pour les infos techniques:
$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.6 (Santiago)
$ java -version
java version 1.7.0_79
Java(TM) SE Runtime Environment (build 1.7.0_79-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)
$cat /proc/meminfo |grep MemTotal
MemTotal:   49370036 kB

Les JVM sont à 2Go, mais même à 1Go, j'ai le même phénomène.

Merci d'avance pour vos réponses.

PS: J'ai fait ouvrir en parallèle un ticket chez Red Hat, mais je tente
ici au cas où pour un avoir un retour d'expérience.





--
Nul ne sera l'objet d'immixtions arbitraires dans sa vie privée, sa 
famille, son domicile
ou sa correspondance, ni d'atteintes à son honneur et à sa réputation. 
Toute personne a droit
à la protection de la loi contre de telles immixtions ou de telles 
atteintes.

Article 12 de la déclaration universelle des droits de l'homme
___
Liste de diffusion du FRsAG
http://www.frsag.org/