UPDATE 2: Am răspuns la aceasta prin noua mea întrebare la linkul de mai jos. Cauza principală este comportamentul telegraf, unde implicit deconectează conexiunea TCP la 5 secunde după ultimul mesaj primit. Acest lucru poate fi prin proiectare, cu toate acestea, am o problemă cu documentația lor, care a făcut ca acest lucru să fie dificil de identificat ca o potențială remediere.
Poate că această întrebare poate fi acum ștearsă?
UPDATE 1: în loc să editez această întrebare pe larg, făcând ca răspunsurile actuale să nu aibă sens, am pus o nouă întrebare pe baza informațiilor noi pe care le-am primit ca urmare a postării acestei întrebări.
syslog-ng / telegraf: EOF a apărut când inactiv - incompatibil?
Folosesc syslog-ng Open-Source Edition (OSE) v3.31.2 într-o stivă docker-compose.
Am mesaje syslog care sosesc prin rețea de la diverse gazde prin UDP (la care sunt constrâns deoarece clienții mei folosesc Boost::Log și acest lucru nu acceptă syslog peste TCP, doar UDP) și am syslog-ng setat să redirecționeze acestea către un alt serviciu din aval. Se întâmplă să fie telegraf care utilizează un intrări.syslog modul, dar nu sunt sigur că asta contează încă.
Configurația mea arată așa:
@versiunea: 3.29
@include „scl.conf”
Opțiuni {
linii de culoare (1);
};
sursă s_network {
udp(ip(0.0.0.0) port(514));
};
destinație d_file {
fisier("/var/log/messages");
};
destinație d_telegraf {
syslog(portul „telegraf”(6514) transport(tcp));
};
Buturuga {
sursa(s_network);
destinație(d_telegraf);
destinație(d_file);
};
Am setat în mod explicit globalul linii de culoare valoare la 1. Cred că aceasta este valoarea implicită, dar vreau să fiu sigur. Doresc ca mesajele de jurnal să fie redirecționate imediat ce sunt primite.
De cele mai multe ori acest lucru funcționează - „linii” individuale de jurnale ajung în syslog-ng prin UDP 514 și sunt imediat scrise în fișier /var/log/messages, și în aproape toate cazurile sunt, de asemenea, trimise imediat către telegraf pe portul TCP 6514.
Problema pe care o văd este că, destul de des, syslog-ng reține multe rânduri de jurnalele de intrare până la aproximativ 30-60 de secunde, apoi le livrează către telegraf într-o bucată mare. Nu pare să existe prea multe modele în asta, dar se întâmplă des. Lucrul ciudat este că /var/log/messages fișierul are intrările de jurnal lipsă scrise imediat, doar livrarea în rețea este întârziată. M-am gândit că linii de culoare (1) ar evita această tamponare, dar nu pare să o facă.
Am folosit Wireshark pentru a determina unde este întârzierea și este în ieșirea pachetelor de la syslog-ng, între syslog-ng și portul TCP 6514 telegraf.
M-am întrebat dacă acesta ar putea fi un algoritm al lui TCP Nagle - dacă da, există o modalitate de a activa opțiunea de socket TCP_NO_DELAY pentru driverul de destinație syslog al lui syslog-ng?
În cele din urmă, ceea ce caut este un serviciu syslog rapid, cu latență scăzută, care poate agrega și retransmite jurnalele cât mai repede posibil pentru revizuire în timp real în aval.
EDIT: Am încercat să trec la transportul UDP între syslog-ng și telemetrie și acest lucru pare să fie mult mai receptiv, iar întârzierile lungi și ocazionale au dispărut. Cu toate acestea, acest lucru va face dificilă asigurarea conexiunii în viitor.
