matt23 a écrit 40 commentaires

Ta mesure de l'activité du projet via le dépot public est une fumisterie.
Ce projet est développé par C-S, en interne, et, peu à peu, il passe en en libre. Le dépot sf ne sert visiblement qu'a publier les sources rendues libre.

Pour mesurer l'activité autour de ce projet, il va falloir attendre un peu et voir si les promesses sont tenues :
http://www.projet-vigilo.org/site/feuille_de_route

Pour les changements sur Centreon, j'attends d'avoir du temps libre pour y regarder et donner mon avis.

Rarement vu quelque chose d'aussi mal codé que ce machin.

Des bugs très très génants (perte de données de performance par exemple), des bugs d'interfaces, des bugs dans la gestion des process nagios.

Bref, on est très très loin de la qualité de Nagios.

Sans parler du script d'installation, une véritable boucherie, avec des choix pour le moins discutable.

Je conseillerai plutot de regarder Lilac, pour la configuration, et PNP (PNP is Not Perfparse) pour la gestion des données de performances.

Sinon, le projet Vigilo http://www.projet-vigilo.org/site/ semble très prometeur.

Par ailleurs "sujétion", ça n'existe pas, même phonétiquement.

heu ... http://fr.wiktionary.org/wiki/suj%C3%A9tion

Par exemple l'amiante est connue pour être dangeureuse depuis les années 60/70 (les premiers cas ont été même remarqués dans les années 30)

Bien avant en fait, cf., par exemple, http://www.politis.fr/article1480.html

C'est exactement pour remplacer ce genre de hack, plus ou moins maison, plus ou moins propre (pour te citer), que cette fonctionnalité vient d'être ajoutée :) enjoy !

The Postmaster Always Rings Twice

"Je me demande surtout pourquoi les pages qui parlent de ces outils évitent généralement de dire la vérité, à savoir que ces outils sont aussi utilisés par des criminels."

c'est vrai ça, pas comme La Poste (par exemple), n'est-ce pas ?

Je n'ai pas fini de lire ce doc, mais il y a une typo(?) qui est répétée tout le long du document: nsloockup s'écrit nslookup (to look).

DISTINCT n'est pas un tri. Si la colonne est un index, COUNT DISTINCT va simplement compter le nombre de clés dans l'index, ce qui normalement est très rapide (avec MyISAM en tout cas - fais un EXPLAIN SELECT pour t'en convaincre).

DISTINCT est un tri. Il ne retourne pas les enregistrements identiques, il les détecte et les exclus du résultat. Que ce soit rapide ne veut pas dire que c'est plus rapide que la consultation d'un compteur (un champ de type entier dans une table forums pour cet exemple). Faire une somme a également un coût. Que tu veuilles payer ce coût à chaque consultation d'un total, plutôt que quand il change, c'est Poussif By Design.
Par ailleurs, il y a quelques chances que ton index possède une contrainte UNIQUE, auquel cas, l'utilisation de DISTINCT relève de la perversion.

ses concurrents imposent d'utiliser un trigger pour mettre en cache la valeur en question

Ses concurrents n'imposent pas de passer par un COUNT, cela ne veut pas dire qu'ils imposent de passer par un trigger.

Tourner sept fois sa langue dans sa bouche avant d'intervenir me semble plus approprié dans ton cas.

Dans ton cas, je me renseignerais sur ce que font les concurrents avant de proposer des solutions que, visiblement, tu peines à justifier.

Tu as le droit de t'esclaffer bruyamment

Merci.

mais mettre un trigger sans raison valable c'est faire de l'optimisation prématurée, et aussi rendre ta BD plus difficile à gérer puisque plus compliquée.

Non.

Après chacun est maître de ses propres développements et a le droit de concevoir des usines à gaz si ça lui chante :-)

Oui.

(soit dit en passant, le moindre des respects quand on répond à un thread est d'exprimer ses idées en français au lieu de se contenter d'un lien vers un message humoristique)

Alors, à ma droite: https://linuxfr.org//comments/897074.html#897074
une solution qui met à jour un compteur lors de l'insertion et de la suppression d'une ligne. Le compteur est consultable sans autre opération que la lecture.

Puis à ma gauche: https://linuxfr.org//comments/897299.html#897299 une solution qui va utiliser une fonction d'agrégat (COUNT) sur une opération de tri des résultats d'une requête (DISTINCT) chaque fois que l'on voudra connaître la valeur de ce compteur.

Cette deuxième solution est cocasse. Le contournement poussif d'une limitation absurde propre à MySQL. Il me semble urgent d'en rire.

Enfin quelque chose de sérieux et robuste dans MySQL.

https://linuxfr.org//comments/896989.html#896989

J'ai fait quelques tests de NDOutils, extension servant à stocker les événements générés par Nagios dans une base (My)SQL. Le schéma de base de NDOutils utilise InnoDB. Qui dit transactions, dit journal de ces transactions. Lorsque tu as un volume conséquent de transactions, disons entre 20 et 30 requêtes/seconde, le volume des ces journaux est important, environ 8GO/jour dans ce cas. Logiquement, j'espère, j'en suis venu à tweaker la configuration de Mysql pour ne pas conserver ces 8GO. Et là, petite surprise: tu peux jouer sur deux paramètres: la taille des fichiers (max_binlog_size) et le nombre de jours pendant lesquels tu les conserves (expire_logs_days). Ce nombre de jour est un entier comprit entre 0 et 99, 0 désactive la suppression des logs de manière automatique. Tu peux tout de même passer des requêtes pour supprimer les journaux.

Là ou pour moi c'est une, mauvaise, surprise, c'est dans la comparaison avec PostgreSQL. j'avais eu à configurer la gestion des journaux sur un PostgreSQL, et tu pouvais, de mémoire, jouer sur: la taille d'un fichier, le nombre total de fichiers (avec une rotation automatique) et, éventuellement, une commande shell à éxecuter automatiquement juste avant la suppression d'un journal: par exemple, copier le journal sur un système de fichier réseau, faire un scp, ...

Avec PostgreSQL, tu n'as aucun mal à prévoir la taille totale des journaux: taille d'un fichier x nombre de fichiers. Avec MySQL, c'est impossible. De plus, si tu veux conserver les journaux, il te faut une moulinette qui va mêler SQL et commandes shell.

Ce point particulier illustre bien pourquoi je préfère PostgreSQL à Mysql: la moindre fonctionnalité un tant soit peu intéressante de MySQL souffre de limitations franchement absurdes.

J'ai joué avec tout ça cette semaine, donc en 2008, avec le mysql d'une debian stable. Si on me montre comment mieux gérer ces journaux, j'en serais particulièrement heureux !

vivement le service minimum généralisé !

les anglais ont débarqué, les jeunes vont devoir passer par derrière, tu sais ...