Les streams ne fonctionnent que par analyse de lignes de textes. Si tu as un outil qui permet de "suivre" un flux et de le transformer en ligne de texte, c'est tout bon !
On peut penser à docker logs -f, journalctl -f, tail -f, tail -f | jq, swaymsg -m, inotifywait -m...
Je ne connais pas vraiment kafka ni opentelemetry, mais il doit bien y avoir un utilitaire qui permet ça.
Ça fait partie des choix de design qui sont importants pour moi. J'estime que les commandes de coreutils, systemd, docker et consorts sont censées être optimisées. Et j'ai envie de limiter au maximum d'avoir dans la base de code de reaction des développements spécifiques. Je pourrais dire que c'est pour respecter la tradition UNIX, KISS, etc, mais c'est surtout pour m'éviter de maintenir du code déjà écrit ailleurs 😉
[^] # Re: streams
Posté par ppom . En réponse à la dépêche reaction, remplaçant de fail2ban. Évalué à 3.
Les streams ne fonctionnent que par analyse de lignes de textes. Si tu as un outil qui permet de "suivre" un flux et de le transformer en ligne de texte, c'est tout bon !
On peut penser à
docker logs -f,journalctl -f,tail -f,tail -f | jq,swaymsg -m,inotifywait -m...Je ne connais pas vraiment kafka ni opentelemetry, mais il doit bien y avoir un utilitaire qui permet ça.
Ça fait partie des choix de design qui sont importants pour moi. J'estime que les commandes de coreutils, systemd, docker et consorts sont censées être optimisées. Et j'ai envie de limiter au maximum d'avoir dans la base de code de reaction des développements spécifiques. Je pourrais dire que c'est pour respecter la tradition UNIX, KISS, etc, mais c'est surtout pour m'éviter de maintenir du code déjà écrit ailleurs 😉