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
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.
ich kenne splunk als siem und bin mir nicht sicher ob sie jetzt optimal hier ist ...
vg
joerg
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...
Zitat von: herrmannj am 19 März 2016, 21:38:09
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...
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
Interessanter Ansatz.
Wo siehst Du denn die Vorteile (fhem) vs file oder dblog ?
vg
joerg
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... ;-)
Zitat von: daubsi am 19 März 2016, 21:43:24
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:
define <name> rsyslog <ident> <logopt> <facility> <regexp>Für Dein obiges Beispiel:
define rsl rsyslog fhem ndelay local0 .*ACHTUNG: Das Modul ist echt quick&dirty. Aber Du kannst Dir damit die beiden notify sparen.
Mit
apt-get install libsys-syslog-perlläßt sich das benötigte perl-Modul auf Debian Systemen nachinstallieren.
In meinem syslog sieht das dann so aus:
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.
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
Zitat von: betateilchen am 19 März 2016, 23:08:17
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
Zitat von: herrmannj am 19 März 2016, 23:09:49
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
Zitat von: daubsi am 19 März 2016, 23:54:23
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.
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
- 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.
Zitat von: betateilchen am 20 März 2016, 09:41:59
- 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.
Hm, das wäre vermutlich zuviel des guten... fhem soll ja auch noch was anderes machen, als nur handles öffnen und schliessen ;-)
Aber, dass man das auf FHEM Objekt Ebene konfiguren könnte welche Readings usw. das hältst Du für möglich?
Zitat von: daubsi am 20 März 2016, 09:55:50
Aber, dass man das auf FHEM Objekt Ebene konfiguren könnte welche Readings usw. das hältst Du für möglich?
Klar, das ist doch Standard. Du kannst eine regexp angeben, die festgelegt, welche events geloggt werden. Das funktioniert auch jetzt schon.
Bei mir sieht die regexp zum Loggen in DbLog beispielsweise so aus:
(.*:lumi.*|GW1_.*|.*:batVoltage.*|.*:measured-temp.*|.*:desired.*|.*:actuator.*|.*:valve.*|.*:Bb]attery:.*|.*:temperature.*|.*:humidity.*|.*:dewpoint.*|.*:pressure.*|Melder.*:.*|RM_.*:.*|sunDummy.*:.*|out_Regen.*:.*|.*_SenPwr.*|gds.*)
Zitat von: betateilchen am 20 März 2016, 09:58:26
Klar, das ist doch Standard. Du kannst eine regexp angeben, die festgelegt, welche events geloggt werden. Das funktioniert auch jetzt schon.
Bei mir sieht die regexp zum Loggen in DbLog beispielsweise so aus:
(.*:lumi.*|GW1_.*|.*:batVoltage.*|.*:measured-temp.*|.*:desired.*|.*:actuator.*|.*:valve.*|.*:Bb]attery:.*|.*:temperature.*|.*:humidity.*|.*:dewpoint.*|.*:pressure.*|Melder.*:.*|RM_.*:.*|sunDummy.*:.*|out_Regen.*:.*|.*_SenPwr.*|gds.*)
Hi, das heisst es ist weiterhin ein globales Objekt aber man kann durch den Regex auch die FHEM-Objekte benennen, auf die es wirkt?
Hilf mir doch noch mal eben:
Angenommen ich möchte
Temp1: temperature, humidity
Heizung: forward, return, power
Water: litersperminute
wegschreiben - wie sähe der Regex dazu aus?
So?
(temp1:temperature|temp1:humidity|heizung:forward|heizung:return|heizung:power|water:litersperminute) ?
Sieht gut aus, probiers doch einfach aus :)
regexp ist nun wirklich nichts fhem-spezifisches.
Servus betateilchen,
sieht gut aus! Dein Modul funktioniert prima :-D
Danke!
Ich habe nachher noch ein paar Stunden Bahnfahrt nach München vor mir, da werde ich mich mit dem Thema nochmal befassen. Vor allem eine Fehlerbehandlung, wenn jemand versucht, zwei rsyslog devices zu definieren.
Prima! Bin gespannt! Danke
In der nächsten Version sind folgende Punkte enthalten:
- Fehlermeldung beim Versuch, ein zweites rsyslog device zu definiere
- Attribut rsl_timestamp ermöglicht das Loggen der fhem-eigenen timestamps (nützlich wenn mseclog in fhem definiert ist)
- commandref doku enthalten (abrufbar über device specific help in der Detailansicht)
Das Modul steht in ./contrib bereit und kann per SVN ausgecheckt werden. Es muss vorläufig noch manuell nach ./FHEM kopiert werden.
@herrmannj von Splunk als SIEM kann ich abraten. sind jetzt auf logrhythm und top zufrieden :)
Wen es interessiert:
Um das lokale Loggen in /var/log/syslog auf dem FHEM Rechner abzudrehen (bei Verwendung von rsyslog) muss lediglich in der /etc/rsyslog.conf
aus *.*;auth,authpriv.none -/var/log/syslog ein *.*;local0,auth,authpriv.none -/var/log/syslog gemacht werden. (sofern man wie ich local0 für FHEM nutzt). Danach noch rsyslog durchstarten und schon ist Ruhe im Karton.
Darüberhinaus sollte man sich noch (generell) sinnvolle Schwellwerte für das Logging in FHEM überlegen. Beispielsweise hat sich für meine Lacrosse Temperatursensoren ein "event-on-change-reading: temperature,humidity" und ein "event-min-interval: 300", "resolution: 10" als praktikabel erwiesen.
Zitat von: daubsi am 20 März 2016, 08:05:26
A propos Zielhost: Bietet das Perl Syslog Modul denn die Möglichkeit direkt an einem Remoteserver zu loggen?
Theoretisch scheint das zu funktionieren, aber es wird in allen Beschreibungen zu Sys::Syslog dringend davon abgeraten.
Hi, na ja, nachdem das mit dem Forwarden via rsyslog.conf so prima funktioniert, ist es ja kein Problem...
Hallo zusammen,
ich weiß nicht ob es jemandem noch hilft, aber ich habe jetzt aktuell auch einen Splunk Server aufgesetzt und auch das mit dem rsyslog ausgetestet, allerdings wollte mein raspberry mit fhem dann nicht mehr so wirklich wie ich, aufgrund der schier unendlichen anzahl an logs.
daraufhin habe ich mich auf die Suche nach einen Splunk Forwarder für den Pi gemacht, und tatsächlich das funktioniert einwandfrei, derzeit überwache ich mit dem forwarder nur /var/log/messages und wandle es gleich hier in einen eigenen "source-type" um.
Das könnte man jetzt so ziemlich für jede TextDatei machen, also auch mit den Fhem eigenen File-Logs, man hat dann also die möglichkeit eine kombination aus splunk und fhem-log zu verwenden, und die "field-extraction" auch für mehrere fhem events durchführen, da zumindest bei mir teilweise in einem event mehrere Readings übergeben werden.
Den Forwarder habe ich nach folgendem Blog Beitrag durchgeführt:
https://stichintime.wordpress.com/2015/03/23/raspberry-pi-as-a-splunk-universal-forwarder-to-store-and-foward-logs/
Und wie man "Source-Types" in splunk definiert findet ihr hier:
http://docs.splunk.com/Documentation/Splunk/6.4.3/Data/Setsourcetype
Als Anhang noch ein Screenshot eines SPlunk Dashboards mit Benzin Preisen der letzten 7 Tage.
Grüße
Sebastian