Discussion :

[Ajocin]

Bonjour à tous,

je cherche la meilleur solution pour lire des fichiers de logs en continue et sans blocage (sur une serveur debian), les parser et écrire le résultat dans une base de données ou tout simplement écrire dans un autre fichier ou encore les pousser vers une url.
Ca serait comme implémenter un tail mais avec des fonctions de filtres en sortie.
Ce petit utilitaire doit tourner en permanence pour ne rater aucune ligne ou rotation des logs, et donc ne pas prendre trop de resources.
Je souhaiterai le faire en C/C++.
Est-ce que vous avez des resources, idées ou suggestions SVP ?

En vous souhaitant une excellente journée !

[smarlytomtom]

Salut Ajocin.

Ce que je ferais c'est un programme tout simple qui fait du "std::getline" sur ton fichier et que tu lances en démon sur la machine. Tu ouvres le fichier au lancement du démon et tu le ferme seulement quand tu shutdown le démon.

tu peux également utiliser des API spécifiques à linux si tu es certain de ne pas devoir faire tourner le programme sur un autre OS !

Si ça t'intéresse le sujet semble être largement couvert sur stackoverflow (si l'anglais ne te donne pas des aigreurs d'estomac bien entendu).

[bacelar]

Moi, ce que je comprends pas, c'est pourquoi ce faire chier avec un fichier et pas juste customiser le syslog ?

[smarlytomtom]

Moi, ce que je comprends pas, c'est pourquoi ce faire chier avec un fichier et pas juste customiser le syslog ?

Parce que comme il le précise il souhaite le faire ainsi...

[bacelar]

Pourquoi faire simple quand on peut faire compliquer.

[Bktero]

Beaucoup de gens disent "je veux faire un programme qui fait ça", alors qu'en fait leur vrai besoin est "je veux un moyen de faire ça"

Perso, je ne coderai rien dans un premier temps et je regarderai ce qui existe de tout fait. Je n'ai pas de riche idée à proposer. Une première question est déjà : quel est l'OS ciblé ?

[camboui]

C'est dit: serveur debian

Pour le reste, je ne suis que moyennement d'accord avec les critiques.
Nous sommes dans un forum de programmation et pas de stratégie, d'analyse, de choix d'outil, que sais-je.
Même si parfois cela nous paraît abscons, toutes les demandes sont respectables. Le but est peut-être simplement didactique, éducatif, pédagogique, expérimental, etc, ce n'est jamais perdu.

[bacelar]

Ma remarque, c'est aussi et surtout pour éviter le syndrome du marteau de Maslow pour un programmeur débutant, "tout ce règle par un nouveau programme".

[smarlytomtom]

C'est dit: serveur debian

Pour le reste, je ne suis que moyennement d'accord avec les critiques.
Nous sommes dans un forum de programmation et pas de stratégie, d'analyse, de choix d'outil, que sais-je.
Même si parfois cela nous paraît abscons, toutes les demandes sont respectables. Le but est peut-être simplement didactique, éducatif, pédagogique, expérimental, etc, ce n'est jamais perdu.

+1... Ici la question était claire et je pense que l'auteur a été effrayé aux vues de sa réponse...

[koala01]

Salut,

A vrai dire, je serais plutôt de l'avis de bacelar sur ce coup là...

Car nous sommes face à une personne qui demande, je cite

Je cherche la meilleur solution pour lire des fichiers de logs en continue et sans blocage (sur une serveur debian), les parser et écrire le résultat dans une base de données ou tout simplement écrire dans un autre fichier ou encore les pousser vers une url.

Nous avons beau être dans la section dédiée à au développement C++, le fait est que des solutions à son problème existent déjà, et qu'elles n'ont d'ailleurs pas forcément été développées en C++.

Et donc, il semble "logique" de se dire que, plutôt que de se faire chier à perdre "un temps bête" à développer une micro application qui fournisse ce service, il puisse être largement plus intéressant de se tourner vers quelque chose qui existe déjà et qui est -- sans doute -- déjà fourni par la distribution utilisée.

C'est d'autant plus vrai que voici la première question posée par Ajocin qui débarque à peine sur le forum, et que l'on ne sait absolument rien de lui / d'elle : est-il/elle plus orienté vers le développement ou sur la gestion de son serveur au jour le jour Se pourrait-il qu'il se soit simplement dirigé vers cette section "par dépit", ne sachant pas trop où aller la poser ailleurs

En plus, de mon temps, quand un nouveau membre se faisait connaître, on commençait par lui souhaiter la bienvenue. Et personne n'a pris la peine de le faire jusqu'à présent.

Je vais donc commencer par corriger ce point

Bonjour, Ajocin et bienvenue sur le forum.

Ensuite, nous pourrons passer aux explications:

Le fait est que, a priori, debian (de même que n'importe quelle distribution de linux, d'ailleurs) vient systématiquement avec un système de gestion des logs que tu devrais sans doute pouvoir configurer pour qu'il envoie les log là où tu le désire.

Sur ma debian, le fichier de configuration est le fichier /etc/rsyslog.conf, qui ressemble à quelque chose comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
#  /etc/rsyslog.conf	Configuration file for rsyslog.
#
#			For more information see
#			/usr/share/doc/rsyslog-doc/html/rsyslog_conf.html
 
 
#################
#### MODULES ####
#################
 
module(load="imuxsock") # provides support for local system logging
module(load="imklog")   # provides kernel logging support
#module(load="immark")  # provides --MARK-- message capability
 
# provides UDP syslog reception
#module(load="imudp")
#input(type="imudp" port="514")
 
# provides TCP syslog reception
#module(load="imtcp")
#input(type="imtcp" port="514")
 
 
###########################
#### GLOBAL DIRECTIVES ####
###########################
 
#
# Use traditional timestamp format.
# To enable high precision timestamps, comment out the following line.
#
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
 
#
# Set the default permissions for all log files.
#
$FileOwner root
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022
 
#
# Where to place spool and state files
#
$WorkDirectory /var/spool/rsyslog
 
#
# Include all config files in /etc/rsyslog.d/
#
$IncludeConfig /etc/rsyslog.d/*.conf
 
 
###############
#### RULES ####
###############
 
#
# First some standard log files.  Log by facility.
#
auth,authpriv.*			/var/log/auth.log
*.*;auth,authpriv.none		-/var/log/syslog
#cron.*				/var/log/cron.log
daemon.*			-/var/log/daemon.log
kern.*				-/var/log/kern.log
lpr.*				-/var/log/lpr.log
mail.*				-/var/log/mail.log
user.*				-/var/log/user.log
 
#
# Logging for the mail system.  Split it up so that
# it is easy to write scripts to parse these files.
#
mail.info			-/var/log/mail.info
mail.warn			-/var/log/mail.warn
mail.err			/var/log/mail.err
 
#
# Some "catch-all" log files.
#
*.=debug;\
	auth,authpriv.none;\
	news.none;mail.none	-/var/log/debug
*.=info;*.=notice;*.=warn;\
	auth,authpriv.none;\
	cron,daemon.none;\
	mail,news.none		-/var/log/messages
 
#
# Emergencies are sent to everybody logged in.
#
*.emerg				:omusrmsg:*

Peut être te suffirait il de modifier ce fichier (attention, tu dois avoir les droits admin: le faire sous root pour le faire) pour arriver au résultat que tu souhaites

Au pire, certains utilitaires comme swatch pourraient sans doute te venir bien à point, si tu veux effectivement pouvoir envoyer certaines parties de log vers une adresse distante( voir la page wiki associée à syslog).

Maintenant, si tu tiens vraiment à t'amuser à développer ton propre programme pour y arriver, rien ne t'empêche de le faire, mais tu risques d'être confronté à de nombreux problèmes parmi lesquels nous pouvons certainement citer:

• le fait que tu devras créer un nouveau démon, qu'il s'agira de configurer "dans les règles de l'art", en respectant les prescription du sysètme linux
• le fait que tu devras avoir recours aux appels systèmes pour repérer les modifications apportées aux fichiers log que tu veux surveiller
• le fait que tu devras mettre en place "tout un protocole" d'envoi et de réception des informations par internet, ou, plus vraisemblablement, utiliser un protocole bien spécifique pour ce faire
• j'en passe, et sans doute de meilleures ...

Comme je l'ai dit plus haut, nous ne savons absolument rien de toi, vu que tu débarques à peine sur le forum. Tu es, peut-être, déjà suffisamment habitué au développement sous linux que pour y arriver sans problème, mais le simple fait que tu poses la question m'incite à penser que ce n'est pas le cas.

En outre, le simple fait que tu parles de C/C++ m'incite à penser que, du point de vue même de la programmation, tu es sans doute encore un débutant. Ce n'est pas un reproche, car nous l'avons tous été, mais bien une constatation dont il faudra tenir compte.

Si tu dois commencer par apprendre un langage quelconque -- qu'il s'agisse de C, de C++, de java ou de n'importe quel autre langage -- avant de pouvoir mettre ton système au point, dis toi que tu n'arriveras sans doute à rien de très concret avant six bons mois à un an! Un tel délais est-il raisonnable de ton point de vue Ne préférerais tu pas avoir recours à une solution "toute faite" qui te permettrait sans doute de mettre tout cela en place en quelques heures à peine

Nous sommes tout à fait prêts à t'aider si tu décides de développer ta propre solution, tant au point de vue du code en lui-même qu'en t'expliquant les règles qui régissent le monde "linux" pour ce genre de choses. Mais nous ne pourrons pas développer cette solution pour toi parce que cela reviendrait à te faire un cadeau empoisonné.

Notre manière de travailler revient d'avantage à te fournir les explications dont tu as besoin qu'à faire le travail à ta place. Il faudra donc que tu poses des questions, que tu nous montres régulièrement ton travail, surtout si tu rencontre des problèmes à la compilation, pour que nous puissions t'orienter "dans la bonne direction".

La question finale, à laquelel tu sera le(la ) seul(e) à pouvoir répondre est : souhaites tu te lancer dans l'aventure d'un tel développement, sachant que tu risques d'être parti(e) pour plusieurs mois à suer à grosses goutttes