Um Fehlertoleranz zu erreichen, führe ich Haproxy zwischen Thruk und mehreren Nagios-Backends mit dem Livestatus-Plugin aus. Thruk hat kein Verbindungstimeout, daher führt ein „totes“ Backend dazu, dass Thruk ewig zum Laden braucht, was normalerweise zu einem Timeout von Apache führt (das über fcgi einen Proxy zu Thruk herstellt).
Ich habe ein Problem, wenn Thruk einen externen Befehl sendet. Der Client erwartet keine Antwort vom Server und schließt daher die Verbindung sofort, nachdem er seine Daten gesendet hat. Dies führt anscheinend dazu, dass Haproxy die Verbindung trennt, wenn noch keine Verbindung zum Remote-Server hergestellt wurde. Dies führt zu Protokolleinträgen wie diesen:
127.0.0.1:48350 [07/Apr/2014:12:39:17.268] thruk_backend_nagios2_6557_6559 thruk_backend_nagios2_6557_6559/nagios2 0/-1/0 0 CC 0/0/0/0/0 0/0
Das CC bedeutet anscheinend, dass der Client die Verbindung unerwartet geschlossen hat, während haproxy versuchte, eine Verbindung zum Backend-Server herzustellen. Sobald dies geschieht, versucht haproxy nicht weiter, die Verbindung zum Backend herzustellen, was bedeutet, dass die vom Client gesendeten Daten verloren gehen.
Ich dachte, dass die TCP-Smart-Accept/Connect-Optionen helfen könnten, aber sie hatten keine Wirkung.
Kann ich hier etwas anderes tun, als den Client zu ändern oder eine Art Store-and-Forward-TCP-Proxy zwischen Thruk und Haproxy hinzuzufügen? Gibt es eine Option für Haproxy, die die Client-Anforderung puffert und sie nach dem Herstellen der Verbindung an den Server weiterleitet, selbst wenn der Client nicht da ist?