nutzt hier jemand checkmk zusammen mit Log Analyse - z.B. Graylog oder Logstash/Elasticsearch?
Hier gibt es ja einige Überschneidungen damit Logs nicht doppelt eingesammelt werden und die Analyse Logik nicht doppelt gepflegt werden muss.
Hierzu möchte ich ein paar Erfahrungen oder Denkanstöße sammeln.
Beispiel
Szenario: Fehlgeschlagene Loginversuche pro Quelle und/oder Benutzer in einer gewissen Zeiteinheit.
Generell möchte man im Log-System alle versuchten und erfolgreichen Logins für einen längeren Zeitraum archivieren. Die Info das von IP x im Zeitraum y zig Loginversuche fehlgeschlagen sind möchte ich aber zeitnah im Monitoring als Alarm haben.
Die Logs doppelt einzusammeln und zu verarbeiten erscheint mir unschön. Anders als Logstash hat aber Graylog z.B. keine Möglichkeit die Daten per SNMP oder Syslog nach Verarbeitung an checkmk weiter zu leiten.
Graylog liefert da in der Tat nichts selbst mit aus.
Heißt, man müsste selbst ein Plugin dazu entwickeln (für Graylog) oder im App Store von Graylog etwas passendes suchen.
Wir loggen failed logins per rsyslog ins graylog.
Dort werde ich einen Alert konfigurieren (failed logins / minute )
und per Graylog API abfragen ob der getriggert hat.
Dazu werde ich mir wahrscheinlich einen “Special Agent” schreiben,
oder auf dem graylogserver ein check_mk/plugin ablegen welches per curl auf localhost die API befragt
Vielleicht werde ich die Graylog Alareme sogar per piggiback einzelenen Host zuordnen.
Aber es ist noch nichts fertig.
Analog plane ich das btw für Grafana Alerts, d.h. Special Agent fragt Grafana API nach getriggerten Alerts.
wir sind übrigens grad dabei die ersten Graylog Feature für Checkmk zu implementieren.
Das was @mimimi anspricht haben wir, meine ich, zumindest schon für Elasticsearch.
Aufgrund der mangelnden Optionen in Graylog selbst, wäre das vermutlich ein guter Anwendungsfall. Ich behalt’s mal im Hinterkopf.
Danke für eure Hinweise. @mimimi, der Ansatz mit Special Agent war auch das was mir bisher am sinnvollsten erscheint.
Allerdings hoffe ich noch auf Ideen / Erfahrungen aus der Praxis. Weniger für eine konkrete technische Umsetzung, eher was die grundsätzliche Architektur angeht bevor ich mich hier fest lege.
Ich kann das hinter Graylog liegende Elasitc Search nicht so leicht befragen, weil es in einem abgeschottem Netz liegt. Will ich aber auch gar nicht, weil ich dann z.B. den “Indices to query” angeben muss und was ist ein und wir haben davon 248. Ok, Wildcards werden wahrscheinlich funktionieren.
Bei einer Suche in Graylog muss ich mich nicht darum scheren in welchem Index das Gesuchte liegt.
Das Graylog Web GUI ist eine Single Page Javascript App, die quasi auch nur die API befragt.
Ich habe das mal mit dem Firefox und Wireshark mitgeschnitten: An Graylog geht bei einer Suche ein GET an /api/search/universal/relative?query= und zurück kommt JSON.
Darauf werde ich aufbauen.
An die konfigurierten Graylog Alerts kommt mann über /api/streams/alerts
hast Du das aus der API Doku oder erfolgreich alerts abfragen können?
Soweit mir bekannt funktioniert das aktuell nur über den API explorer aber nicht über ein GET.
Mein Plan ist das sich unsere User selbst Alerts in Graylog anlegen.
Die Alerts, die in Graylog aufpoppen/triggern und unresolved sind möchte ich in check_mk sichtbar machen, mit einem Service Icon Link am check will ich dann den Absprung zum Graylog ermöglichen um den Alarm quittieren zu können.
Aber ich glaube ich verstehe was du meinst, ein Alert ist in Graylog kein Item was ich mit check_mk inventarisieren kann, sondern die getriggerten Graylogs Alerts sind Events, richtig ?
Kann sein das das so ist, leider habe ich momentan keine Zeit um das Thema weiter zu verfolgen.
Das Alerm Zeugs in Graylog ist für mich eh verwirrend, man muss sich erste einen Stream anlegen und dort eine oder mehrere Condition anlegen. Ich hoffe das man irgendwie abfragen kann ob diese Condition getriggert hat und diese quasi als check item für checkmk verwenden. Ich weiss es noch nicht ob es geht.
Schade, das hilft doch nicht weiter. Diese /api/streams//alerts/check
triggered flags haben auch Event Charakter und sind nicht Status basiert.
Nach N Minuten wegen des “Execute search every N minutes” ändert sich das “triggered” wieder auf false, ohne das irgendjemand irgendetwas quittieren müsste.
Warscheinlich werde ich mir was basteln müssen was im Graylog per “Notification Type” -> “HTTP Notification” einen passiven check im check_mk auf CRIT setzt wenn eine Condition triggert. Oder nutze einen Consul Key/Value Store, den wir sowieso hier haben, um aus den Events ein Status zu machen.
Das ist leider alles komplizierter als ich mir das vorgestellt habe.
Hm, wir haben so ein ähnliches Problem wo wir Alerts aus Splunk irgendwie in CMK haben wollen.
Momentan löst jetzt Splunk bei einem Alert ein “logger …” Command aus welches den Alert per Syslog an die Event-Console schickt. Ist aber auch nicht so elegant. Ein Service auf dem Host wäre netter.
geht mir auch immer so …