Verzögerung bei Protokollen, die von an CDL den Syslog-Server gesendet werden
12131
Created On 03/20/23 18:48 PM - Last Modified 06/13/23 17:49 PM
Question
Warum empfängt mein Syslog-Server nicht die neuesten Protokolle?
Environment
Sender: Data Lake
Receiver: Cortex Alle Syslog-Empfänger wie syslog-ng, Splunk, QRadar, Sentinel unter anderem.
Answer
Cortex Data Lake (CDL) beginnt mit dem Senden verfügbarer Protokolle an den Syslog-Empfänger, der im Protokollweiterleitungsprofil konfiguriert ist, sobald Sie die Konfiguration der Filter und das Speichern des Profils abgeschlossen haben.
Manchmal konnten Sie sehen, dass die Protokolle, die auf dem Syslog-Server empfangen wurden, möglicherweise nicht die neuesten waren, und Protokolle von früheren Stunden oder sogar Tagen erhielten.
Dies hängt in der Regel mit einer Art Einschränkung des Syslog-Servers zusammen, die verhindert, dass er die Menge der gesendeten Protokolle CDL verarbeiten kann.
Einige häufige Ursachen sind:
- Maximale Protokollrate: Abhängig vom Anbieter / der Anwendung, die Sie auf Ihrem Server verwenden, gibt es einige Spezifikationen in Bezug auf die maximale Protokollrate, die der Server verarbeiten kann, so dass Sie die Parameter auf Ihrem Server überprüfen und konfigurieren müssen, um eine Batchgröße von 500 Protokollen oder 2,25 (500 Protokolle x 4500 B/Protokoll = 2,25 MB MB) zu akzeptieren. Dies gilt nicht für Google Chronicle, das jeweils nur 1 MB Daten oder eine Batchgröße von 250 Protokollen akzeptiert.
- Serverleistung: Sie müssen die auf dem Server verfügbaren Ressourcen (CPU, , Datenträger usw.) überprüfen und feststellen, RAMob ein Element Leistungsprobleme verursachen könnte.
- Server kann den Datenverkehr nicht verarbeiten: Oft zeigt der Server keinen herausragenden Wert aus dem Ressourcenverbrauch, obwohl er nicht in der Lage ist, den Datenverkehr zu verarbeiten. Sie können überprüfen, ob dies der Fall ist, indem Sie den Status von Recv-Q auf Ihrem Server überprüfen. Dies kann durch Ausführen des Befehls netstat wie im folgenden Beispiel erfolgen:
> netstat -an | GREP 6415
Die Ausgabe des oben angegebenen Befehls ähnelt der unten gezeigten:
Proto Recv- Send-QQ Lokale Adresse Fremdadresse (Staat)
tcp4 3223 0 11.10.32.24.8002 11.10.32.12.64672ESTABLISHED
Der Wert für Recv- sollte 0 sein, andernfalls puffert Ihr Server den Datenverkehr im Recv-QQ, was bedeutet, dass Ihr Server nicht in der Lage ist, den gesamten empfangenen Datenverkehr zu verarbeiten. Wenn der Puffer für den Recv- erschöpft ist, führt der Syslog-Server dazu, dass die Send-on-Data-Lake-Seite zunimmt und schließlich der Datenverkehr nicht mehr gesendet wird, bis der Recv-on-Syslog-EmpfängerserverQQ CortexQ gelöscht wird.