Petit filtre sur l’exécutable du serveur, le pid du processus qui a pris en charge le client
Deux choses que je ne connais pas. Je connais l'adresse IP du mec qui me casse les pieds c'est tout.
tu peux quand même filtré sur le service ce qui n'est pas possible avec le syslog original et certain service (attention, j'y vais comme toi, je lance des affirmations sans vérification mais c'est ce que je viens de lire).
Tout dépend de quoi on parle
- Si c'est service au sens de daemon - ben ca va être dur de pas filtrer dessus vu que généralement ses logs vont être à part. (genre /var/log/daemon) après si j'ai décidé de les fusionner avec d'autres logs ça devient un peu mon problème.
- Si c'est service au sens d'instance - la plupart des logiciels permettent quand mêle de loguer très correctement par instance, mais même dans le cas ou ils ne permettent pas (j'ai pas d'exemple en tête) - le facteur déterminant sera probablement ailleurs (une fois de plus IP extérieure, segment de protocole qui part en vrille, activité d'un utilisateur etc.) Donc on va passer d'une complexité de O(n) à une complexité de l'ordre de O(log(n)) + O(n*p) (Avec p < 1, p étant la proportion de logs dans l'instance concernée). C'est mieux, mais pas transcendant.
Mais bon, la seul chose que tu as démontré, c'est que dans tes exemples, journald s'en sort aussi mal que syslog…
Une fois de plus je pense sincèrement que journald est meilleur que syslog, et sans systemd rattaché je serai déjà en train de le tester - mais c'est pas pour autant qu'il fait le café, ramène le journal et garanti le retour de l'être aimé. Il a des défauts - ben comme tous les programmes quoi.
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 4.
Petit filtre sur l’exécutable du serveur, le pid du processus qui a pris en charge le client
Deux choses que je ne connais pas. Je connais l'adresse IP du mec qui me casse les pieds c'est tout.
tu peux quand même filtré sur le service ce qui n'est pas possible avec le syslog original et certain service (attention, j'y vais comme toi, je lance des affirmations sans vérification mais c'est ce que je viens de lire).
Tout dépend de quoi on parle
- Si c'est service au sens de daemon - ben ca va être dur de pas filtrer dessus vu que généralement ses logs vont être à part. (genre /var/log/daemon) après si j'ai décidé de les fusionner avec d'autres logs ça devient un peu mon problème.
- Si c'est service au sens d'instance - la plupart des logiciels permettent quand mêle de loguer très correctement par instance, mais même dans le cas ou ils ne permettent pas (j'ai pas d'exemple en tête) - le facteur déterminant sera probablement ailleurs (une fois de plus IP extérieure, segment de protocole qui part en vrille, activité d'un utilisateur etc.) Donc on va passer d'une complexité de O(n) à une complexité de l'ordre de O(log(n)) + O(n*p) (Avec p < 1, p étant la proportion de logs dans l'instance concernée). C'est mieux, mais pas transcendant.
Mais bon, la seul chose que tu as démontré, c'est que dans tes exemples, journald s'en sort aussi mal que syslog…
Une fois de plus je pense sincèrement que journald est meilleur que syslog, et sans systemd rattaché je serai déjà en train de le tester - mais c'est pas pour autant qu'il fait le café, ramène le journal et garanti le retour de l'être aimé. Il a des défauts - ben comme tous les programmes quoi.