Bonjour @MartinKirch,
Merci pour l'intérêt que vous portez à Logs Data Platform.
Il s’agit d’un problème bien connu de la gestion de socket réseau en développement. Ce dernier peut avoir principalement deux causes: un timeout défini trop court ou une coupure de la connexion non détectée par la socket entre la source et la destination. Cela arrive principalement quand le flux réseau circule dans des infrastructure complexes (présence de load balancer, de proxy...).
Pour pouvoir détecter une coupure de la connexion, et ainsi anticiper la perte de log, il faudrait effectuer une lecture dans le socket avant chaque écriture ce qui est lourd. Pour les librairies développées et proposées par OVHcloud (logging-gelf https://pypi.org/project/logging-gelf et logging-ldp https://docs.ovh.com/fr/logs-data-platform/logging-ldp), nous avons fait un compromis en activant les options SOL_SOCKET/SO_KEEPALIVE sur le socket ainsi que de la configuration au niveau protocole du KEEPALIVE, sur ce qui couvre la majorité des cas.
Pour être sûr de ne perdre aucun log, il faut utiliser un système d’acquittement (ACK) autre que TCP tel que le propose filebeat https://docs.ovh.com/fr/logs-data-platform/filebeat-logs.
Pour votre cas, une perte de 2% me parait élevé. Sur base de nos observations, nous estimons que rsyslog/syslog-ng ou logging-gelf atteint au maximum entre 0.005% et 0.75% de perte.
Cordialement,
