Fhem -> Splunk

[daubsi]

Hallo,

ich weiss nicht, wer hier alles "Splunk" kennt: Das ist eine Bigdata Anwendung, die beliebige text-basierte Informationen entgegennimmt und über Elastic Search/Full-text search beliebige Auswertungen ermöglicht. Damit wären also use-cases wie Durchschnittsverbrauch, Trends, Min/Max Graphen usw. einfachst möglich.

Verbreitet ist es vor allem im Unternehmenseinsatz, aber es gibt auch eine kostenlose Version für Zuhause (http://www.splunk.com).
U.a. kann Splunk z.B. problemlos Syslog Events verarbeiten oder Dateien monitoren. Bis 250MB/d (ja, pro _TAG_) ist es kostenfrei. Das sollte für die allermeisten Fälle im privaten Umfeld ausreichen Schaut es Euch einfach mal an. Wenn man mal gesehen hat, wie mächtig diese schnellen Volltextsuchen sind, ist man angefixt

Ich würde gerne alle meine FHEM Loggingdaten via Splunk verarbeiten. Da bei mir FHEM auf einem RPI läuft habe ich irgendwie mind. 1x/Jahr den Fall, dass sich die SD Karte verabschiedet und Auswertungen bei der textbasierten fhem.log Variante quälend langsam sind, wenn die Datenmenge steigt. DbLog habe ich bereits versucht, aber irgendwie läuft das auch nicht 100% stabil bei mir. Teilweise wird geloggt, teilweise nicht. Ich möchte am liebsten GAR KEIN lokales Logging aus den zuvor genannten Gründen, sondern einfach alles Richtung Splunk schicken.

Ih wollte daher mal fragen, ob es vielleicht in Richtung Splunk schon irgendwelche Aktivitäten gibt. Im Grunde muss es kein dediziertes Splunk-Modul sein, es würde auch reichen ein Remote-Syslog zu ermöglichen. Etwas in die Richtung findet sich schon hier: https://forum.fhem.de/index.php?topic=24445.0

Kann mir jemand sagen, wie der aktuelle Stand bzgl. remote Logging ist? Was wäre zu tun, wenn man analog "FileLog" und "DbLog" einen "SplunkLog" Typ integrieren möchte? Ich bin nicht gerade der Perl-Experte, aber ich habe schon ein eigenes MBus Modul für meinen Wasserzähler geschrieben. Mit etwas Geduld könnte ich das also vlt. hinkriegen.

Danke und Grüße,
Markus

[betateilchen]

Eigentlich kann das ja nicht so kompliziert sein, man müsste nur dafür sorgen, dass alle events einen http Request auslösen um den json String  an den HTTP Event Collector endpoint zu schicken.

http://dev.splunk.com/view/event-collector/SP-CAAAE6P

Irgendwie habe ich aber grade Bauchschmerzen, wenn ich dabei an die Themen blocking und performance denke.

[herrmannj]

ich kenne splunk als siem und bin mir nicht sicher ob sie jetzt optimal hier ist ...

vg
joerg

[daubsi]

Hallo,

es war am Ende leichter als gedacht.
Ich habe mich dabei des Tipps aus dem verlinkten Syslog Post bedient:

In die fhem.cfg folgende Zeilen aufnehmen:

define syslog_open notify global:INITIALIZED { \
  use Sys::Syslog;; \
  openlog("fhem","ndelay","local0");;\
  return;;\
}
define syslog notify .* { \
  syslog("info","$NAME: $EVENT") \
    if defined &syslog;;\
  return;;\
}

Dann einen Splunk listening port konfigurieren. Ich habe mich für 8514\tcp entschieden. Mit UDP wollte es irgendwie nicht funktionieren...

Splunk Menü->Settings->Data Inputs->TCP (siehe Anhang define_data_input.png)
Ich habe einen neuen Index "fhem" gemacht und einen neuen Sourcetype "fhem" definiert, der auf syslog basiert.

Dann in die rsyslog config Datei /etc/rsyslog.d/splunk.conf folgenden Eintrag machen:

local0.*                @@192.168.0.1:8514

Fhem durchstarten, rsyslog durchstarten (service rsyslog restart)

Auf dem Splunk server kann man nun mit einem tcpdump auf Port 8514 verifizieren, dass Einträge ankommen - oder einfach direkt in Splunk schauen

Mit dem visual field extractor in Splunk kann man sich nun noch das Fhem Event schön parsen, siehe visual_field_extractor.png

Nun in sie Search App wechseln und einfach mal los suchen:

"index=* sourcetype=fhem device=LandisGyr FORWARD" sucht alle Einträge aus diesem Index, für das FHEM Device LandisGyr und dort das Reading "FORWARD"

"index=* sourcetype=fhem device=LaCrosse_2A T:" sucht alle Einträge aus diesem Index, für das FHEM Device Lacrosse 2A und dort das Reading T (Temperatur).

index=* sourcetype=fhem device=* device=ESAx000WZ_4750 reading=actual | timechart span=1m sum(value) usenull=f

zeichnet ein Zeitdiagramm für den Wert des aktuellen Stromverbrauchs pro Zeiteinheit von meinem ESA Funkstromzähler...

Was ich noch nicht geschafft habe, ist die local0 syslog Einträge NUR an den Splunkserver zu schicken und nicht noch zusätzlich in das lokale syslog auf dem RPI bzw. das fhem.log... da muss ich noch ein bisschen googeln...

[daubsi]

ich kenne splunk als siem und bin mir nicht sicher ob sie jetzt optimal hier ist ...

vg
joerg

Hallo Jörg,

nein, Splunk ist nicht wirklich ein SIEM im klassischen Sinne wie Arcsight oder Logrhythm... Es ist quasi "alles und nichts"... Die Stärke liegt in der komplettten Flexibilität was Du da reinpackst... Logs, Mails, Dateien, Events, ... - Du kannst alles parsen, durchsuchen und vor allem Visualisieren...

[daubsi]

Hier der erste Graph nach ein paar Minuten == ein paar erhaltenen Events für den Zulauf und Rücklauf der Heizung

index=* sourcetype=fhem device=* device=LandisGyr reading=FORWARD OR reading=RETURN | timechart avg(value) by reading span=1m usenull=f

[herrmannj]

Interessanter Ansatz.

Wo siehst Du denn die Vorteile (fhem) vs file oder dblog ?

vg
joerg

[daubsi]

Hi,

naja im Wesentlichen die Mächtigkeit der Auswertemöglichkeiten und die Visualisierungen bei exzellenter Performance. Geht vermutlich auch alles irgendwie mit fhem Bordmitteln, aber nachdem ich gerade auch beruflich damit zu tun habe...

[betateilchen]

es war am Ende leichter als gedacht.
Ich habe mich dabei des Tipps aus dem verlinkten Syslog Post bedient:

Damit Du es noch einfacher hast, hab ich mal schnell ein Modul zusammengeschraubt

Allgemeine Syntax:

Code Auswählen Erweitern

define <name> rsyslog <ident> <logopt> <facility> <regexp>

Für Dein obiges Beispiel:

Code Auswählen Erweitern

define rsl rsyslog fhem ndelay local0 .*

ACHTUNG: Das Modul ist echt quick&dirty. Aber Du kannst Dir damit die beiden notify sparen.

Mit

Code Auswählen Erweitern

apt-get install libsys-syslog-perl

läßt sich das benötigte perl-Modul auf Debian Systemen nachinstallieren.

In meinem syslog sieht das dann so aus:

Code Auswählen Erweitern


Mar 19 23:13:48 fhem-vm-8 fhem: d1: blub
Mar 19 23:13:48 fhem-vm-8 fhem: at_d1: Next: 23:14:48
Mar 19 23:14:48 fhem-vm-8 fhem: d1: blub
Mar 19 23:14:48 fhem-vm-8 fhem: at_d1: Next: 23:15:48
Mar 19 23:15:16 fhem-vm-8 fhem: global: DELETED at_d1
Mar 19 23:15:22 fhem-vm-8 fhem: global: DELETED d1
Mar 19 23:15:23 fhem-vm-8 fhem: global: SAVE


Nachtrag: Das Modul 92_rsyslog.pm liegt derzeit in ./contrib und kann per svn ausgecheckt werden.

[herrmannj]

oh, ok. Meine Frage hatte drei Gründe

ich..
* beabsichtige mich mit splunk (als siem) zu beschäftigen
* wollte hören ob eine unstrukturierte db Dir Vorteile bringt
* wollte hören ob Du Auswertungen suchst die Du mit fhem Bordmitteln nicht findest

Wofür nimmst Du splunk beruflich ?

vg
joerg

[daubsi]

Damit Du es noch einfacher hast, hab ich mal schnell ein Modul zusammengeschraubt

Hallo Betateilchen!

Das ist ja super! Vielen Dank!
Kannst Du mir auch sagen, wie ich gleichzeitig verhindere, dass auch noch parallel das normale fhem.log beschickt wird?

Danke und VG
Markus

[daubsi]

oh, ok. Meine Frage hatte drei Gründe

ich..
* beabsichtige mich mit splunk (als siem) zu beschäftigen
* wollte hören ob eine unstrukturierte db Dir Vorteile bringt
* wollte hören ob Du Auswertungen suchst die Du mit fhem Bordmitteln nicht findest

Wofür nimmst Du splunk beruflich ?

vg
joerg

Hallo Hermann,

nun der Vorteil von Splunk für unsere Anforderungen ist, dass wir eine grosse Anzahl von Logdaten haben (eine SEHR GROSSE Anzahl ), unter denen Verknüpfungen und Korrelationen gebildet werden sollen. Beispielsweise möchte man z.B. wissen was ein bestimmter Accountname oder eine IP so im Netz gemacht hat, auf welchen Systemen sie im Log auftaucht usw. Das ist, wie Du Dir jetzt vlt. vorstellen kannst, mit Splunk banal, da Du nur die IP eingeben musst und - ein genügend performantes System vorausgesetzt - in Sekunden Gigabyte weise Logdateien durchsuchen kannst und Dir die Informationen anzeigen kannst. Sowas ist mit einer strukturierten klassischen DB natürlich nicht so einfach, weil Du dort ja für die zu bildenden Relationen ganz genau weisst, was du mit was verbindest. Geht sicherlich auch, ist aber nicht so "schnell" wie bei Splunk. Das Ganze hat natürlich auch Nachteile. Man kann sich ziemlich schnell verzettelen, wenn man nicht von Anfang an, sich eine Strategie überlegt, wie man seine Suchen, Alarme, Reports, Dashboard sauber entwickelt...

Als Siem würde ich es jedoch nicht bezeichnen. Zwar gibt es von vielen Herstellern Add-on Apps, z.B. die "Security App" und native Appa der Hersteller wie Checkpoint, Paloalto, Bluecoat usw. aber die liefen natürlich einen recht beengten, wenn auch hübsch anzusehenden Blick.

Ein Siem ist aber schon ein bisschen mehr. Der Platzhirsch unter den SIEMs ist m.E. Arcsight, sowohl was die Professionalität, aber auch den Preis angeht...

VG
Markus

[betateilchen]

Kannst Du mir auch sagen, wie ich gleichzeitig verhindere, dass auch noch parallel das normale fhem.log beschickt wird?

Die FileLog Definition in fhem löschen.

[daubsi]

Hallo betateilchen,

da Du ja offenbar ziemlich fit mit den Internas von FHEM bist.
Was wäre denn zu tun, wenn man jetzt kein globales Syslog aktivieren möchte, sondern selektiv pro Device, mit z.B. anderem Zielhost bzw. Facility bzw. Auswahl welche Readings geloggt werden sollen - eben analog zu einem DbLog oder Filelog.

Ist das auch so einfach realisierbar?

A propos Zielhost: Bietet das Perl Syslog Modul denn die Möglichkeit direkt an einem Remoteserver zu loggen? Oder geht das immer erst an die lokale Instanz und dort wird entschieden, ob etwas weitergeleitet wird oder nicht?

VG
Markus

[betateilchen]

• Die selektive Auswahl mit mehreren Instanzen ist nicht möglich, das läßt das Sys::Syslog erstmal in dieser Form nicht zu. Eventuell könnte man das lösen, wenn man für jeden Logeintrag die Verbindung öffnet und danach wieder schließt. Wie sich das auf die Performance auswirkt? Keine Ahnung. Es darf jedenfalls zu jedem Zeitpunkt immer nur ein offenes openlog() existieren.
• Ob ein logging an remote Server direkt möglich ist, muss ich mal erkunden. Mit dem Sys::Syslog habe ich mich noch nicht intensiver beschäftigt. Meine Vermutung ist aber, dass es immer über die lokale syslog Instanz laufen wird. Von remote Servern war mir gestern beim Lesen nichts aufgefallen.