Utilité des bibliothèques de logging

[souviron34]

Envoyé par PaloPalo

Actuellement, je fait des fprintf dans un fichier. j'y met des informations sur l'état de mon programme, les choses importante, ainsi que les erreurs.
.

Et ?

Qu'est-ce qui ne va pas avec ça ???

[Melem]

Envoyé par souviron34

Et ?

Qu'est-ce qui ne va pas avec ça ???

Ca t'oblige à héberger tes logs sur le PC local (alors que les bibliothèques de logging permettent de télécharger les informations sur un serveur) et à réécrire du code déjà écrit (notamment les fonctions de débogage).

[souviron34]

Envoyé par Melem

Ca t'oblige à héberger tes logs sur le PC local (alors que les bibliothèques de logging permettent de télécharger les informations sur un serveur) et à réécrire du code déjà écrit (notamment les fonctions de débogage).

???

Débogage de quoi ?

Je ne comprend rien : on cherche du log.

Le sujet est tellement vaste que je ne vois de solutions "adaptée".

Comme j'ai déjà demandé, c'est dans quel cadre ?

Faire du loggin de debogage avec des biblos exterrnes est de la stupidité, sauf si on utilise déjà des fonctions externes..

Et on modifie bien le code, puisqu'il faut faire des include..


Quant à l'argument du serveur, là encore c'est idiot : que ce soit un script qui fait un ftp, ou un répertoire de base solutionne le problème..

'fin bref, encore une fois pourquoi faire simple alors qu'on peut faire compliqué..

Décidément je ne me fais pas à ces raisonnements tordus..

[Melem]

Décidément je ne me fais pas à ces raisonnements tordus..

C'est tout à fait ça . En même temps, j'ai pu remarquer que tu as souvent tendance à qualifier d'inutile voire de nuisible tout ce que tu ne t'en es jamais servi de ta propre expérience ! Peux-tu par exemple répondre à cette question : Quand est-il plus avantageux d'utiliser une bibliothèque de logging plutôt que de gérer les logs soi-même ?

[souviron34]

J'avoue n'avoir jamais travaillé sur un seul projet où cela était nécessaire.

Vu la variété des projets sur lesquels j'ai travailé, c'est l'origine de mon étonnement..

D'autant plus que justement on modifie du code, on le rend dépendant d'une tierce partie : si c'est pour du débogage, réellement je n'en vois pas l'utilité. Si c'est pour autre chose, alors il faut le préciser, mais des outils existent tout fait (et sans modifier les sources) pour faire du loggin de session, ou d'accès BDD..

Donc sérieusement, et sans provocation aucune, je ne comprend pas l'utilité de chercher des choses compliquées pour faire du débogage..

[Bktero]

Le PO n'a pas dit que sa bibliothèque servait à faire du débogage non ?

Je suis moi aussi étonné, souviron, que tu n'aies jamais utilisé de telles bibliothèques. Je me suis servi pendant un an du système de log de Bouygues Télécom, qui a eu la bonne idée de faire un système similaire aux logs4j. Bon... on va les excuser en disant que, du coup, les logs sont identiques quelques soient les langages. Cette uniformité dans tout le SI aide grandement les exploitants dans leur travail. Clairement cette bibliothèque est loin de "je vais un printf dans un fichier perso". On retrouve en fait le mécanisme des log4j dont ils s'inspirent :

• fichier de dictionnaire pour affiner / modifier les messages de chaque traitement sans modifier le code source
• des niveaux d'importances pour chaque message
• un appender qui peut décider d'exclure des logs de certains niveaux ou au contraire d'en inclure en cas de problème pour avoir des logs plus verbeux
• fichier de configuration pour chaque traitement pour modifier le comportement de l'appender
• gestion de la journalisation des fichiers de logs par l'appender
• l’application se contente de balancer à l'appender le numéro du message qu'il souhaite tracer (avec les éventuels paramètres) et l'appender se débrouille

Les exploitants du SI obtiennent ainsi des logs complets avec un format défini, peuvent mettre en place des mécanismes de supervision (en générant par exemple des alertes mails si un message de niveau FATAL ou ERROR survient).

Comme le dit Melem, refaire une bibliothèque (telle que log4j pour un projet Java) serait une perte de temps.


EDIT : en recherchant, sur le net, je vois qu'il existe des paquets de log4c pour Ubuntu : https://launchpad.net/ubuntu/+source/log4c

PaloPalo, tu sembles avoir avoir réussi à les installer les log4c finakement ? http://forum.ubuntu-fr.org/viewtopic.php?id=813601

[souviron34]

C'est sans doute alors des pratiques d'une entreprise en particulier, mais cetainement pas une chose générale :

Envoyé par Bktero

• fichier de dictionnaire pour affiner / modifier les messages de chaque traitement sans modifier le code source

En quoi ça peut s'appeler une biblothèque de logging ?

C'est exactement la même chose qu'une internationalisation bien pensée : un fichier de texte par exemple identifiaint les libellés des champs, boutons, menus, erreurs, messages d'aide, etc etc..

C'est un truc général d'une appli.

Ce n'est en rien un truc "de logging"

Envoyé par Bktero

• des niveaux d'importances pour chaque message

kif-kif..

N'impote quelle application un tant soit peu industrielle prévoit des types comme INFO, WARNING, ERROR,, FATAL_ERROR, etc etc..

Si elle ne les a pas, c'est la conception de l'application qu'il faut repenser, pas patcher avec un outil externe...

Envoyé par Bktero

• un appender qui peut décider d'exclure des logs de certains niveaux ou au contraire d'en inclure en cas de problème pour avoir des logs plus verbeux

kif-kif ci-dessus + le point plus bas sur la gestion...

N'importe quelle application industrielle utilise des defines de niveaux comme ceux indiqués précédemment..

D'autre part, une sélection dans un fichier de log se fait par un outil eterne, comme un script ou équivalent. Conceptuellement c'est une application différente.. Pourquoi cela devrait être intégré dans la même ???

Envoyé par Bktero

• fichier de configuration pour chaque traitement pour modifier le comportement de l'appender

ça c'est du paramétrage d'application, et cela est la plupart du temps prévu. Si ça ne l'est pas, là encore il faut revoir la conception..

Envoyé par Bktero

• gestion de la journalisation des fichiers de logs par l'appender

ça c'est fait par des outils externes à l'application, en général des scripts, dépendant la plupart du temps du SI gérant les applis opérationnelles et non du développement.. (et dépendant de l'OS et des structures / répertoires / équipes / rôles / liaisons internes à l'entreprise)

Envoyé par Bktero

• l’application se contente de balancer à l'appender le numéro du message qu'il souhaite tracer (avec les éventuels paramètres) et l'appender se débrouille

Encore une fois, c'est simplement partager un fichier de config et s'y référer par numéro...



Enfin, je me répète, dans AUCUN environnement industriel dans lequel j'ai travaillé il n'y a eu besoin de ce genre de choses, car la CONCEPTION était réfléchie.

Alors visiblement il semble que dans les Télécom (si ce que tu cites est vrai) ce ne soit pas le cas, mais je n'y vois AUCUN avantage, à part le fait de se lier à quelque chose de tierce et donc de diminiuer la facilité de maintenance / portabilité.. Ah bien sûr, comme ça on ne remet pas en cause la mauvaise conception d'une appli...

Enfin, utiliser ceci sur une application EN COURS DE DEVELOPPEMENT est une aberration conceptuelle..

[Bktero]

De ce que tu me dis, tu as utilisé des systèmes semblables aux log4j. Simplement ton application a codé son propre mécanisme de log. C'est un choix technique comme un autre;

Quand tu démarres un projet, tu choisis les outils que tu vas utiliser, tu peux choisir un outil pour gérer les logs comme tu choisis ta bibliothèque graphique. Je ne vois pas le rapport entre la mauvaise conception et l'utilisation de bibliothèques tierces. "Non j'utilise pas OpenGL pour ne pas être dépendant d'OpenGL" ?

Je suis d'accord avec toi que tout changer en cours n'est peut-être pas une bonne idée et qu'il y aurait fallu y penser avant.

[souviron34]

Envoyé par Bktero

De ce que tu me dis, tu as utilisé des systèmes semblables aux log4j. Simplement ton application a codé son propre mécanisme de log. C'est un choix technique comme un autre;
.

C'est pas un choix technique..

ça fait partie de l'étape dl'analyse / conception de l'application..

Il faut réfléchir au futur, que ce soit en terme d'internationalisation, de maintenance, de souplesse..

C'est bien pour ça que je parle de problème de conception..

Et puisque dans le cas d'ici le programme est déjà là, c'est encore plus facile d'insérer directement des fonctions "projet" style fprintf (même "ornée") que de faire apple à une biblothèque externe, dont on ne connaîtra pas la pérennité, la maintenance, l'évolution, le portage..

[Mandraxx]

Bonjour,

Je suis votre conversation depuis un moment et y'a un truc que je ne comprends pas dans ton argumentaire Souviron : en quoi la décision de prendre ou non une bibliothèque OpenSource au lieu de la réécrire ne constitue pas un choix technique ?

Je comprend ta position par rapport à la dépendance vis-à-vis d'applications tierces et à leur maintenance mais l'intégration technique de l'OpenSource (comme le produit syslog) est indéniablement un choix purement technique puisqu'on peut décider à tout moment de créer un fork pour intégrer la maintenance en interne dans le cas où le produit viendrait à disparaître.

Alors pourquoi réinventer la poudre quand elle existe ?
IBM par exemple (une référence industrielle avec son siècle d'expérience) a créé un département spécialisé dans l'intégration de produits tiers : ils sont capables d'absorber une fonctionnalité technique en 6 mois et d'en assurer la maintenance de façon pérenne en interne.
Chez eux, intégrer une application tierce devient donc une tâche technique de 6 mois de charge ne présentant aucune contrainte de dépendance.

Quand au sujet principal qui est l'utilisation de systèmes de logs standardisés dans des environnements industrialisés, c'est fortement répandu (Télécom certes, mais aussi IBM, Oracle, Administrations, Cap Gemini, Athos, AKKA, etc.) : le contrôle interne de certaines grandes entreprises exige même l'utilisation bibliothèques de logs précises avec des patterns normés pour les audit de sécurité.

Enfin, là où je te rejoins, c'est qu'une telle usine à gaz n'est absolument pas nécessaire en développement (un bon #define avec printf pour virer le code de debug à la release et basta).

@+

[souviron34]

Bonjour

Envoyé par Mandraxx

Je suis votre conversation depuis un moment et y'a un truc que je ne comprends pas dans ton argumentaire Souviron : en quoi la décision de prendre ou non une bibliothèque OpenSource au lieu de la réécrire ne constitue pas un choix technique ?

Tu y réponds toi-même plus bas :

Enfin, là où je te rejoins, c'est qu'une telle usine à gaz n'est absolument pas nécessaire en développement (un bon #define avec printf pour virer le code de debug à la release et basta).

D'une part, la nécessité de log aux diverses étapes du soft et de diffrents niveaux devrait apparaître à la phase d''analyse/conception .

D'autre part, que ce soit open-source ou non, on ajoute une dépendance (a fortiori quand c'est open-source) on ne connait pas - et il faut étudier - les dépendances, problèmes ou non de portabilité, de compatibilité, etc etc,

Si c'est open-source, il faut - en plus - se taper de vérifier qu'il n'y a pas de bugs ou de hacks et que par exemple la doc et/ou les entêtes correspondent à la norme de développement en vigueur au sein du projet/ de l'entreprise.

Enfin, la fonctionalité recouverte est simple, et suffisamment dépendante des implantations/politiques diverses des SI ou des entreprises pour nécessiter du tayloring intensif en utilisant soi-disant un outil standardisé : dans telle entreprise ce sera sur un serveur à part, fonctionnant sous Windows. Dans telle autre ce sera un répertoire, exploré par des scripts shells, sous Linux ou tel "flavour" de unix, dans telle autre on s'en fiche, dans telle autre on écrase les logs au fur et à mesure, dans telle autre les logs sont pour toutes les applis et centralisés, dans telle autre les logs sont pour chaque usager...

Envoyé par Mandraxx

(comme le produit syslog) est indéniablement un choix purement technique puisqu'on peut décider à tout moment de créer un fork pour intégrer la maintenance en interne dans le cas où le produit viendrait à disparaître.

Il faut modifier tous les fichiers sources, tout recompiler..

Dans un environnement de développement, cela veut dire refaire tous les tests de régression.. Ce qui coûte du temps et de l'argent de de la mobilisation de personnel..

Envoyé par Mandraxx

Alors pourquoi réinventer la poudre quand elle existe ?

Parce que ce n'est pas ré-inventer la poudre..

Ce n'est qu'une mini-fonctionalité dans un gros système, qui encore une fois a été (ou aurait dû être) identifiée au départ.

Comme son implantation est simple (via un printf, éventuellement enrobé d'un define ou d'un appel à une fonction), et pensée adaptée dès le départ, c'est plutôt réinventer la poudre que d'intégrer quelque chose comme ça..

Envoyé par Mandraxx

IBM par exemple (une référence industrielle avec son siècle d'expérience)

Quand au sujet principal qui est l'utilisation de systèmes de logs standardisés dans des environnements industrialisés, c'est fortement répandu (Télécom certes, mais aussi IBM, Oracle, Administrations, Cap Gemini, Athos, AKKA, etc.) : le contrôle interne de certaines grandes entreprises exige même l'utilisation bibliothèques de logs précises avec des patterns normés pour les audit de sécurité.

Toutes ces entreprises ne sont pas des modèles ni de rentabilité, ni de simplicité...

Que ce soit Orace ou IBM ne sont pas réputées pour faire des choses légères
et bon marché..

Quant aux grandes SSII, leur objectif n'est pas la simplification/efficience d'un projet, mais la plus grande rentabilité du pool de consultants..

La position que je défend est pour un projet donné, pour une entreprise donnée..

[Mandraxx]

Envoyé par souviron34

Tu y réponds toi-même plus bas :

Oui : pour du debug mais c'est par rapport à ce que dit Bktero que je ne comprends pas... En effet pour superviser de la production, les traces de niveau info / warning / errors sont très fortement utilisées.

Après, peut-être que je généralise un peu trop vite ....

Envoyé par souviron34

D'une part, la nécessité de log aux diverses étapes du soft et de diffrents niveaux devrait apparaître à la phase d''analyse/conception .

Entièrement d'accord. On parle bien de nécessité donc de fonction de contrainte (au sens NF X-50-150) => choix fonctionnel.

Envoyé par souviron34

D'autre part, que ce soit open-source ou non, on ajoute une dépendance (a fortiori quand c'est open-source) on ne connait pas - et il faut étudier - les dépendances, problèmes ou non de portabilité, de compatibilité, etc etc,

C'est sûr.

Envoyé par souviron34

Si c'est open-source, il faut - en plus - se taper de vérifier qu'il n'y a pas de bugs ou de hacks et que par exemple la doc et/ou les entêtes correspondent à la norme de développement en vigueur au sein du projet/ de l'entreprise.

Je parle bien d'OpenSource, pas du monde libre, la qualité d'un logiciel OpenSource est exactement la même qu'un CloseSource, il est juste maintenable par le client.

Quant à l'idée reçue que le libre est moins fiable que le commercial, c'est faux : il existe de bons logiciels libres, de mauvais logiciels libres, de bons logiciels commerciaux et de mauvais logiciels commerciaux... Bref toutes les combinaisons possibles .

Envoyé par souviron34

Enfin, la fonctionalité recouverte est simple, et suffisamment dépendante des implantations/politiques diverses des SI ou des entreprises pour nécessiter du tayloring intensif en utilisant soi-disant un outil standardisé : dans telle entreprise ce sera sur un serveur à part, fonctionnant sous Windows. Dans telle autre ce sera un répertoire, exploré par des scripts shells, sous Linux ou tel "flavour" de unix, dans telle autre on s'en fiche, dans telle autre on écrase les logs au fur et à mesure, dans telle autre les logs sont pour toutes les applis et centralisés, dans telle autre les logs sont pour chaque usager...

C'est justement pour cela qu'il existe des bibliothèques adaptables comme celles dont on parle pour découpler le code applicatif de l'environnement système : cela permet d'avoir une approche n-tiers et par conséquent d'accroître la conformité du produit vis à vis des exigences générales de portabilité et de compatibilité (deux des 10 concepts fondateurs du Génie Logiciel) qui sont de plus en plus intégrées aux cahier de charges fonctionnels des projets.
Bien entendu, là encore, si ces exigences ne sont pas au cahier des charges....

C'est là que le choix d'intégrer ou non ce genre de bibliothèque devient purement technique.

Envoyé par souviron34

Il faut modifier tous les fichiers sources, tout recompiler..

Dans un environnement de développement, cela veut dire refaire tous les tests de régression.. Ce qui coûte du temps et de l'argent de de la mobilisation de personnel..

Cela coûte-t-il plus cher que de développer la fonctionnalité ? Il n'y a pas de réponse de toute faite : ça dépend des exigences fonctionnelles.
Sur certains projets, ça sera intéressant, sur d'autres, non.

Ici, c'est la dimension financière qui va jouer et qui va arbitrer les différentes solutions techniques pour répondre au exigences fonctionnelles.

Envoyé par souviron34

Parce que ce n'est pas ré-inventer la poudre..

Ce n'est qu'une mini-fonctionalité dans un gros système, qui encore une fois a été (ou aurait dû être) identifiée au départ.

Comme son implantation est simple (via un printf, éventuellement enrobé d'un define ou d'un appel à une fonction), et pensée adaptée dès le départ, c'est plutôt réinventer la poudre que d'intégrer quelque chose comme ça..

Ok.... je généralise trop...

Envoyé par souviron34

Toutes ces entreprises ne sont pas des modèles ni de rentabilité, ni de simplicité...

Que ce soit Orace ou IBM ne sont pas réputées pour faire des choses légères
et bon marché..

Quant aux grandes SSII, leur objectif n'est pas la simplification/efficience d'un projet, mais la plus grande rentabilité du pool de consultants..

La position que je défend est pour un projet donné, pour une entreprise donnée..

Certes ...

[souviron34]

Envoyé par Mandraxx

En effet pour superviser de la production, les traces de niveau info / warning / errors sont très fortement utilisées.

certes

Mais comme je l'ai déjà dit, en tous cas dans les environnements industriels dans lesquels j'ai pu travailler, quand il y a besoin un petit script shell explore les divers fichiers de log et extrait ça facilement...

Et ces fichiers de log contiennent déjà les niveaux et types de messages...

Si cela a été pensé au départ.. Ce qui revient au problème de conception

Alors j'ai peut-être été dans des milieux "avertis", mais que ce soit dans des boîtes industrielles , dans de la R&D industrielle dans laquelle j'ai été ou dans des environnements scientifiques ou de Centre de Recherche en Informatique, cela a toujours été prévu dès le départ, et codé au fur et à mesure..

Définir des catégories d'erreur/de messages est une tâche faisant intégralement partie de la conception..

Comme mentionné plus haut, l'écriture d'un petit script, outre le fait que cela ne modifie en rien les applications (qui peuvent être - très - lourdes) , est souple vis-à-vis de changement de politique / hardware / services ...

Envoyé par Mandraxx

Cela coûte-t-il plus cher que de développer la fonctionnalité ? Il n'y a pas de réponse de toute faite : ça dépend des exigences fonctionnelles.
Sur certains projets, ça sera intéressant, sur d'autres, non.

Euh....

Code C :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
void Affiche_Message ( char *Message, int Type )
{
  FILE *fichier ;
 
  switch ( Type )
   {
       case ERROR :
             fichier = stderr ;
             break ;
 
       default :
             fichier = stdout ;
             break ;
   } 
 
  fprintf ( fichier, "%s : %s\n",TypeMessage[Type], Message );
}

n'est pas d'un coût de fabrication ou d'utilisation gigantesque...

(et là j'ai simplifié, mais ajouter 2 ou 3 types de fichiers de plus n'est pas franchement plus compliqué)


Note : si une initilisation est bien faite, on peut même simplifier pour faire :

Code C :

1
2
3
4
void Affiche_Message ( char *Message, int Type )
{
  fprintf ( Fichiers[Type], "%s : %s\n",TypeMessage[Type], Message );
}

[Mandraxx]

Envoyé par souviron34

certes

Mais comme je l'ai déjà dit, en tous cas dans les environnements industriels dans lesquels j'ai pu travailler, quand il y a besoin un petit script shell explore les divers fichiers de log et extrait ça facilement...

Et ces fichiers de log contiennent déjà les niveaux et types de messages...

Si cela a été pensé au départ.. Ce qui revient au problème de conception

Alors j'ai peut-être été dans des milieux "avertis", mais que ce soit dans des boîtes industrielles , dans de la R&D industrielle dans laquelle j'ai été ou dans des environnements scientifiques ou de Centre de Recherche en Informatique, cela a toujours été prévu dès le départ, et codé au fur et à mesure..

Définir des catégories d'erreur/de messages est une tâche faisant intégralement partie de la conception..

Comme mentionné plus haut, l'écriture d'un petit script, outre le fait que cela ne modifie en rien les applications (qui peuvent être - très - lourdes) , est souple vis-à-vis de changement de politique / hardware / services ...

Ok, sur la partie applicative, je te suis parfaitement.

Envoyé par souviron34

Euh....

Code C :

n'est pas d'un coût de fabrication ou d'utilisation gigantesque...

(et là j'ai simplifié, mais ajouter 2 ou 3 types de fichiers de plus n'est pas franchement plus compliqué)

Chouette ! de la mécanique !
Dans ma boîte, la contrainte fonctionnelle est la suivante : sur un S.I. donné, on a 15000 users / 130 serveurs et 200 administrateurs en 3 niveaux d'assistance (local, régional, national).

Tout incident doit être tracé et archivé 10 jours, les trois niveaux doivent avoir accès aux traces qui les concernent : local sur le serveur, régional sur toute la région et national accès complet...

Bon, maintenant, admettons que j'ai bien pensé à tout en specification conception : mon dév est propre et il faut juste adapter l'implantation de Affiche_Message pour répondre au besoin...

Maintenant, si je te dis que je peux répondre à tous ces besoins fonctionnels avec 2 lignes de conf syslog et 5 lignes de conf logrotate et qu'en plus, ça mènera les traces au plus près de celui qui en a besoin sans nécessiter une connexion WAN interactive.

Ma question : n'ai-je pas intérêt à utiliser cette bibliothèque en lieu et place de fprintf ? (en intégrant ma dépendance dans la fonction Affiche_Message : cela va de soit mais c'est mieux en le disant... )

Après, si je reviens sur cette idée :

Envoyé par souviron34

Comme mentionné plus haut, l'écriture d'un petit script, outre le fait que cela ne modifie en rien les applications (qui peuvent être - très - lourdes) , est souple vis-à-vis de changement de politique / hardware / services ...

On peut effectivement définir une batterie de pipes comme étant des points d'accès à l'application et greffer un shell qui va les lire pour alimenter syslog via la commande logger => ça découple encore plus le système et ça accroît donc sa compatibilité mais qu'est-ce que ça donne en termes de performances par rapport à une liaison statique avec le coeur ?

Donc choix technique : il faut trouver l'optimal entre découplage et performance.

@+

P.S. : Voilà comment j'utilise syslog de mon côté, mon header :

Code :

1
2
/* Logs a complex message */ 
int loggerf(char* type, char* msg, ...);

Mon module que je lies systématiquement à toutes mes applis C :

Code :

1
2
3
4
5
6
7
8
9
10
 
int logger(char* type, char* msg) {     
  char buffer[BUFSIZ]; 
  openlog(NULL,LOG_CONS|LOG_NDELAY|LOG_PID,LOG_DAEMON);          
  strcat(format,LAST_LEVEL_SYS_FORMAT);     
  snprintf(buffer,BUFSIZ,format,type,msg);          
  syslog(LOG_DAEMON,buffer);     
  closelog();     
  return(0); 
}

[souviron34]

Envoyé par Mandraxx

Maintenant, si je te dis que je peux répondre à tous ces besoins fonctionnels avec 2 lignes de conf syslog et 5 lignes de conf logrotate et qu'en plus, ça mènera les traces au plus près de celui qui en a besoin sans nécessiter une connexion WAN interactive.

Ma question : n'ai-je pas intérêt à utiliser cette bibliothèque en lieu et place de fprintf ? (en intégrant ma dépendance dans la fonction Affiche_Message : cela va de soit mais c'est mieux en le disant... )

Et si quelqu'un du national en visite en local a besoin de consulter le national ?

Et si quelqu'un de local a besoin de consulter le national ?- bug - appel juridiqiue - problème particulier ?

ou du "local" d'à côté ?

De plus, si vraiment tu veux être souple tout en minimisant les accès réseaux, il y a des outils style CORBA...

Enfin, si pour une raison ou une autre - tiens, il y a 1 semaine, panne électrique due au gel, ou ... - sur une région, un serveur (local par exemple) down, etc, comment il fait, le local ?? Ou, à l'inverse, le national ??

Maintenant, calcule le nombre d'heures que tous les devs ont mis pour lire la doc de l'outil, que tous les sysadmin ont mis pour lire la doc de configuration, et que toutes les équipes de maintenance ont mis pour lire la doc de maintenance, en plus de la doc de l'appli...

Et le nombre d'heures passées à trouver où se situe un bug, savoir si c'est de la config de l'outil sur tel site, de la config de l'appli, de l'outil, ou de l'appli...




PS: j'ajouterais que tu fais des open/close à chaque message.. Pas très eficace...

[Mandraxx]

Envoyé par souviron34

Et si quelqu'un du national en visite en local a besoin de consulter le national ?

Et si quelqu'un de local a besoin de consulter le national ?- bug - appel juridiqiue - problème particulier ?

ou du "local" d'à côté ?

De plus, si vraiment tu veux être souple tout en minimisant les accès réseaux, il y a des outils style CORBA...

Enfin, si pour une raison ou une autre - tiens, il y a 1 semaine, panne électrique due au gel, ou ... - sur une région, un serveur (local par exemple) down, etc, comment il fait, le local ?? Ou, à l'inverse, le national ??

Oui : ça revient à ce que tu disais, problème de spec (ces cas ne sont pas pris en compte ou les risques sont jugés acceptables).

Envoyé par souviron34

Maintenant, calcule le nombre d'heures que tous les devs ont mis pour lire la doc de l'outil, que tous les sysadmin ont mis pour lire la doc de configuration, et que toutes les équipes de maintenance ont mis pour lire la doc de maintenance, en plus de la doc de l'appli...

Tout à fait d'accord : ces coûts doivent entrer dans l'enveloppe dont je parlais quand je disais qu'il faut comparer le coût d'intégration au coût de développement.

C'est pourquoi, je ne remets aucunement en cause les phases d'analyse / conception dont tu parles : elles sont indispensables et c'est en partie leur rôle que de déterminer si oui ou non, on va intégrer une bibliothèque tierce.

Envoyé par souviron34

Et le nombre d'heures passées à trouver où se situe un bug, savoir si c'est de la config de l'outil sur tel site, de la config de l'appli, de l'outil, ou de l'appli...

C'est effectivement le défi majeur d'un nouveau métier de l'informatique : l'urbaniste S.I.
En tant qu'architecte, je travaille avec l'un d'eux très régulièrement et leur compétence est indispensable pour organiser les systèmes d'informations.
Ce qu'on fait en tant que développeur au niveau applicatif (organiser le code), ils le font au niveau environnemental (organiser les systèmes) : leur point de vue est souvent très intéressant.

Envoyé par souviron34

PS: j'ajouterais que tu fais des open/close à chaque message.. Pas très eficace...

C'est vrai, merci !
M'en va corriger ça : cette discussion passionnante va en plus optimiser mes programmes

[souviron34]

Envoyé par Mandraxx

C'est effectivement le défi majeur d'un nouveau métier de l'informatique : l'urbaniste S.I.
En tant qu'architecte, je travaille avec l'un d'eux très régulièrement et leur compétence est indispensable pour organiser les systèmes d'informations.
Ce qu'on fait en tant que développeur au niveau applicatif (organiser le code), ils le font au niveau environnemental (organiser les systèmes) : leur point de vue est souvent très intéressant.

Faudrait savoir : tu es architecte ou tu es développeur ???

Enfin le terme "urbaniste" est un nouveau buzz word, qui recouvre ce qu'avant on appelait architecte/CP..

Quand on conçoit un système, quand on en est l'architecte, on se doit de penser à ça.. Il semble qu'on taylorise de plus en plus pour inventer de nouveaux titres, de nouvelles fonctions...

Pour moi (en tous cas dans les génrations de gens que j'ai cotoyé jusqu'à aujourdhui), un architecte est un "urbaniste" et réciproquement...

C'est un peu comme les "techniciens de surface" pour ne pas dire homme/femme de ménage..

[Mandraxx]

Envoyé par souviron34

Faudrait savoir : tu es architecte ou tu es développeur ???

Anciennement développeur devenu architecte mais je suis nostalgique !

Envoyé par souviron34

Enfin le terme "urbaniste" est un nouveau buzz word, qui recouvre ce qu'avant on appelait architecte/CP..

Je pensais comme toi avant, mais j'ai dernièrement revu ma position : d'un point de vue compétence, je suis d'accord : c'est plus d'un point de vue organisationnel que c'est différent.
Je vois l'urbaniste comme le chef d'une équipe d'architectes : c'est l'architecte qui a le plus de "bouteille" en somme.

Envoyé par souviron34

Quand on conçoit un système, quand on en est l'architecte, on se doit de penser à ça.. Il semble qu'on taylorise de plus en plus pour inventer de nouveaux titres, de nouvelles fonctions...

Il y a de ça aussi (c'est l'effet de la dynamique commerciale qui veut réinventer des concepts là où la seule application d'une expertise est nécessaire).
Mais cet engouement pour les nouveaux termes cache parfois des concepts réels réutilisés dans un but commercial sans qu'il y ait compréhension du métier (juste parce que ça sonne bien) : peu d'architectes sont familiers avec les concepts de quartiers/zones/ilots. C'est notre urbaniste qui m'a fait découvrir ces concepts que je commence doucement intégrer.

Envoyé par souviron34

Pour moi (en tous cas dans les génrations de gens que j'ai cotoyé jusqu'à aujourdhui), un architecte est un "urbaniste" et réciproquement...

C'est vrai car leur culture est la même

Envoyé par souviron34

C'est un peu comme les "techniciens de surface" pour ne pas dire homme/femme de ménage..

Je vois plus ça comme un sous ensemble, une spécialité : dans notre métier vu de l'extérieur, tout le monde est informaticien ; ça va du vendeur de PC à l'ingénieur système en passant par le programmeur...

[souviron34]

On ne va pas épiloguer sur les fonctions (il y a plusieurs threads parlant de ça sous "Général Développement -> Débats", "Général Développement -> Conception", et "Emploi"), car c'est HS ici.

Cependant tu viens de donner exactement les raisons pour lesquelles je pense que ce n'est pas un choix technique mais un problème de conception.. (comme tu le mentionnes toi-même)

Et , pour lier les 2 aspects,

Je vois l'urbaniste comme le chef d'une équipe d'architectes : c'est l'architecte qui a le plus de "bouteille" en somme.

eh ben voui, et c'est là que réside le point que je fait : dans une approche "normale", c'est justement l'architecte/CP qui a le plus de bouteille qui est censé établir l'architecture globale..

C'est ce que je voulais dire et que tu explicites : maintenant on "éclate" les rôles et on donne des "diplômes " de CP ou d'"architecte" qui fait qu'on prend dans des fonctions demandant de l'expérience des gens qui n'ont pas de "bouteille", du coup on est obligé d'inventer un nouveau poste

"L'urbaniste" n'est donc en rien une profession à part entière, à mon sens, c'est le reste qui n'est pas adapté..

Comme je disais, dans les projets sur lesquels j'ai été, la reponsabilité de l'architecture globale avait été confiée à des gens brillants, n'ayant pas de diplômes particuliers (des anciens programmeurs, des anciens ingénieurs généralistes, des anciens scientifiques, des anciens responsables de BD...), mais ayant une bonne expérience, ayant monté en taille de projet et de complexité, et donc doués d'un recul et d'une "vision" à grande échelle autant que d'une vision à petite, bref des gens compétents

Ceci est comme je le disais HS par rapport ce thread, mais c'est une spécificité française (et dans une moindre mesure belge et suisse par proximité), due en très grande partie à l'importance des grosses banques, compagnies d'assurances, mutuelles, et grosses soicétés de service dans le milieu français, additioné d'une mentalité où un grade est perçu comme un titre, en France, au lieu d'être une fonction, et additionné enfin de tentatives de solutions politiques au problème du chômage des jeunes par la multiplication des formations et des diplômes.. [* voir note]

Cherche voir sur un site américain par exemple MOA, MOE, Urbaniste, et même des trucs comme "scrum master" etc.. Tu n'en trouveras pas..Pour BPM tu trouveras uniquement un très petit nombre, liés uniquement à IBM et quelques banques..

Parce que chez eux ce sont des fonctions, pas des titres..

Maintenant, par rapport au problème du thread, que "l'incompétence" (entre guillemets) soit du domaine de la mauvaise conception ou d'un mauvaix choix de personnes / organisationnel, il n'en reste pas moins que je ne la qualifierais pas de "choix technique"..

Et que donc, je maintiens ma position que utiliser un outil "externe" et modifier les sources pour faire du logging est une aberration conceptuelle...

Mais je pense qu'on va s'arrêter là sur ce sujet, non ?

[*] Note : et ça touche tous les domaines Maintenant, pour être concierge il va falloir un diplôme : Désormais devenir gardien d'immeuble s'apprend à l'école

[Melem]

Bonjours à tous.

Vu la longueur de actuelle de la discussion, j'avoue que je n'ai pas du tout lu les messages précédents. Je n'ai d'ailleurs pas l'intention de participer à ce débat, faute de temps. Je me permets juste de poster quelques liens trouvés sur internet au sujet du logging, sans nécessairement être d'accord avec (ni contre) leurs arguments.

En premier lieu donc, voici déjà ce que pense Microsoft du logging :

When an error occurs, the system administrator or support representative must determine what caused the error, attempt to recover any lost data, and prevent the error from recurring. It is helpful if applications, the operating system, and other system services record important events, such as low-memory conditions or excessive attempts to access a disk. The system administrator can then use the event log to help determine what conditions caused the error and identify the context in which it occurred. By periodically viewing the event log, the system administrator may be able to identify problems (such as a failing hard disk) before they cause damage.

Many applications record errors and events in proprietary error logs, each with their own format and user interface. Data from different applications can't easily be merged into one complete report, requiring system administrators or support representatives to check a variety of sources to diagnose problems.

Event logging provides a standard, centralized way for applications (and the operating system) to record important software and hardware events. The event logging service records events from various sources and stores them in a single collection called an event log. The Event Viewer enables you to view logs; the programming interface also enables you to examine logs.

Le site du géant de la sécurité informatique SANS propose également de nombreux articles intéressants sur le logging, dont son rôle et son importance dans le domaine de la sécurité. Il suffit d'aller sur leur page d'accueil et de taper logging dans le formulaire de recherche pour les trouver tous. Parmi les plus intéressants dans les premiers résultats retournés :

• The Importance of Logging and Traffic Monitoring for Information Security
• Cisco Pix: Logging and Beyond
• Detecting Attacks on Web Applications from Log Files

Qu'en dites-vous de cela ?