monitor 1.9.0 - aber richtig :)

[MiThoTyN]

Die Sache mit dem Log finde ich auch nicht gut. Dann haste plötzlich auch auf Seiten des monitors eine Art Datenhaltung. Das soll ja eben vom monitor getrennt sein und dann von einer Datenbank übernommen werden. Im Endeffekt würd ich also auch sagen, dass der monitor-daemon sturr das weitergibt, was er auswertet. Basta. Um eine History-Funktion muss sich dann ein Client kümmern. z.B. eben die angesprochene mySQL Datenbank, die ja durchaus als Proxy zwischen dem monitor und den weiteren Clients sitzen kann.

Gruß Joachim

[nepomuck]

History werde ich ermutlich nur über ein SQL Backend machen. Log-File parsen ist nichts, was ich für so richtig toll halte. Zumal man die auch noch rotieren muss ...

Das würde zwangsweise eine MySQL-Datenbank im Backend erfordern. Das würde mir nicht gefallen, da ich dadurch Probleme mit der Live-CD bekomme.

Bislang kann "Bosix" monatelang von CD gebootet arbeiten, wenn es die LOGs sequentiell auf einen simplen USB-Stick schreiben kann. Die permanenten Änderungen an SQL-Tabellen würden das Union-Dateisystem von Knoppix schnell zum überlaufen bringen, so dass die Live-CD wahrscheinlich innerhalb von wenigen Tagen abstürzt.

Ich dränge immer noch auf ein Backend OHNE MySQL.

Das mit dem Logfile-parsen kann doch nicht so komplex sein, oder?

Andreas

[MiThoTyN]

Nene .. Da haben wir uns schon richtig verstanden. Das eigentliche Backend hat keine MySQL Anbindung. Diese würde ebenfalls per TCP angedockt. Der monitor als Backend übernimmt einzig und alleine die Dekodierung der Funksignale.

Das mit der Logdatei hat meiner Meinung nach zu viele Nachteile. Zum einen ist es echt komplex zu Handhaben. Dateioperationen können immer mal schief gehen. Du musst ständig auf die Datei zugreifen und erzeugst so haufenweise Festplattenzugriffe. Diese kann dann auch nicht in den Standbymodus gehen. Ohne Logdatei läuft der monitor rein im Arbeitsspeicher. Auch musst du die Logdatei rotieren und immer hinten ein Eintrag rauswerfen und vorne einen neuen anfügen. Dazu muss ständig die ganze Datei geladen werden, über nicht wenige Befehle rotiert und wieder gespeichert werden. Rein aus Performance- und Dauerlaufsicht ist ein Dateizugriff in der Form nicht wünschenswert.

Auch sind die Vorteile der Logdatei nicht überzeugend. Sicher ist es für ein Frontend ne feine Sache, wenn es auch Meldungen bekommt, die in der Vergangenheit liegen. z.B. wenn sich das Frontend neu verbinden muss, dann gehen die Meldungen in der Zwischenzeit nicht verloren. Aber was passiert, wenn der monitor selbst mal ne Zeit ausfällt? Dann hast du in den Logdateien noch alte Daten drinne stehen, auf die dann brandneue Daten folgen. Diese werden dann an ein Frontend weitergegeben. Das hat dann plötzlich uralte Daten drinne. Man kann also auch nicht garantieren, dass die Daten aus der Logdatei nicht schon unsinnig sind. Es sei denn man bohrt das entsprechend auf und verwaltet das nach Uhrzeit und alles. Aber das ist ein riesen Aufwand, diesen Datenbestand sinnvoll aktuell zu halten. Und DAS wiederum ist nicht Aufgabe des monitor als solches. Wie gesagt bin ich durchaus für so eine komplexe History. Nur eben als Teil der Datenbank, wo sämtliche Daten eh gespeichert sind.

Gruß Joachim

[nepomuck]

OK, History entfällt im Backend -> Aufgabe des Frondends.
Das gilt dann auch für den Fahrzeug Status via FMS?

Andreas

[jhr-online]

OK, History entfällt im Backend -> Aufgabe des Frondends.
Das gilt dann auch für den Fahrzeug Status via FMS?

Andreas

Ich denke ja; der jeweils aktuelle Status sollte auch aus der DB erfragt werden.

jhr

[Buebchen]

Ne Ne Ne ... Warum nicht ein externer DB-Server ? Auch die logfiles muss er irgendwo hinschreiben. Da würde CD-Boot auch nicht gehen, bzw. es wäre fast das gleiche.

Mein Vorschlag: Es gibt eine Option für den Backend-DB Server. Entweder ist er aktiv oder nicht. Danach kann man immer noch klären welche Daten die Clients dann vom monitord anfordern können oder nicht. Ggf. können die Clients auch einfach selbst auf dem DB Server zugreifen. Das kann dann jeder Entwickler selbst entscheiden.

Eine Zwischenstufe (TCP Client speichert in DB) wäre denkbar. Aber es ist m.E. nicht sinnvoll, daß die Clients selbst die Daten speichern müssen. Was macht man, wenn man eben erst den Client startet ? Man hätte keine aktuellen Statusinformationen zu den Fahrzeugen. Aber alle in die "6" oder "2" zu stellen ist auch nicht richtig.
Gerade bei der Nutzung in einer nachbesetzten Führungsstelle ist das eine wichtige Information ("Welche Fahrzeuge sind ausgerückt - und wann ?").

[nepomuck]

Es gibt eine Option für den Backend-DB Server. Entweder ist er aktiv oder nicht.

Folgende Idee, um das Problem zu lösen.

Der eigentliche Backend hat selbst keine DB und schreibt seine Daten per Default in ein klassisches LOG. das kann man auch abschalten.

Es gibt ein SQL-Modul, welches sich regulär per TCP beim Frontend anmeldet und die Auswertungen per ODBC in irgend eine eine SQL-Db schreibt.
Das SQL modul kann auf dem Backend Server oder irgend einer Maschine im LAN arbeiten. Ebenso kann die Db sein wo sie will.

Eine History-Query muss ein Client an das SQL-Modul stellen.
Da sich das SQL-Modul beim Backend anmeldet, kann ein Client-Task bem backend danach fragen und bekommt als Antwort die IP-Adresse des SQL-Moduls.

123 SQL
234 NOPE

oder

123 SQL
234 192.168.23.65:1234

Vorteil: Die DB ist kein zwingender Bestandteil des backends. Falls die DB ausfällt oder der entfernte sql-server nicht antwortet, funtioniert das Backend regulär weiter.

nachteil: Ein Client der Live-Daten und alte daten auswerten will, muss sich mit zwei TCP-Sitzungen mit dem backend und dem SQL modul verbinden. ausserdem müssen wir ein zweites protokoll zur kommunikation zwischen frontend und sql modul entwickeln.

das hat im gegenzug den vorteil, dass ein task der db-auswertungen mit viel sql-traffic ausführt nicht den backend kanal belastet.

Andreas

[Buebchen]

Das geht schon eher so in die Richtung, die ich mir vorstellen könnte.

Das TCP->SQL Modul wäre zwar nicht mein Lieblingsding aber durchaus ok. Dadurch könnte man vor allen Dingen noch ein anderes Problem erschlagen, daß mir in der Praxis schon begegnet ist:

Was macht man, wenn man im Gerätehaus auf einigen Kanälen schlechten Empfang hat ? Richtig: Von einem besseren Standort die ausgewertete Daten holen. Man könnte also in einer Datenbank durch zwei oder mehr solcher Agenten Daten mehrerer monitord sammeln.

Müßte man noch klären, wie die Benutzerdaten verwaltet werden. Ich hatte bisher einfach gegen MySQL Anmeldung geprüft. Konnte man er sich mit den Daten am mysql anmelden (nur als Prüfung), war man auch am "monitord" angemeldet. Der Client konnte sich dann auch am MySQL anmelden (bekam er ähnlich wie nepomuck schon schrieb dann mitgeteilt, wo dieser MySQL zu finden ist).

Hier wäre dann auch direkt das Problem des externen Zugriffs: Hat der MySQL Server eine LAN IP aus Sicht des monitord nützt diese IP einem von aussen (ohne VPN) zugreifenden Client nichts. Man müßte in letzter Instanz auch über ein "masquerading" nachdenken (Fern-Fern-Fernziel).

Ach so:

Vorteil: Die DB ist kein zwingender Bestandteil des backends. Falls die DB ausfällt oder der entfernte sql-server nicht antwortet, funtioniert das Backend regulär weiter.

nachteil: Ein Client der Live-Daten und alte daten auswerten will, muss sich mit zwei TCP-Sitzungen mit dem backend und dem SQL modul verbinden. ausserdem müssen wir ein zweites protokoll zur kommunikation zwischen frontend und sql modul entwickeln.

Nachteil aus meiner Sicht wäre auch, wenn der monitord zwar läuft ich aber im Fall der Fälle keine Auswertungen der Daten machen kann, da der SQL-Agent sich weggehängt hätte.

Ich schaue weniger in die Auswerter aus Neugierde. Eher im Auswertungen zu fahren (Bsp: Ausrückzeiten, Eintreffzeiten) oder Doku zu schreiben.

Als Protokoll zum Backend würde ich vorläufig mysql-Tools nehmen und direkt auf den Server zugreifen. Alles andere ist ggf. schon wirklich komplex. Gerade wenn auch noch Performance dahinter sein soll. Benutzername und PW dafür sind noch zu klären (dynamisch oder static ...)

[nepomuck]

Müßte man noch klären, wie die Benutzerdaten verwaltet werden.

Wie wäre es mit "gar nicht". Warum direkt gegen MySQL schreiben? Warum nicht ODBC, dann kann das SQL-Modul gegen jede SQL-Datenbank schreiben und die Login-Verwaltung ist Sache des ODBC-Treibers.

diese IP einem von aussen (ohne VPN) zugreifenden Client nichts.

Da sträuben sich mir die Nackenhaare! SQL via Internet ohne VPN. Warum sollte das jeman tun wollen? Jedes Linux und jedes Windows beherrscht zumindest PPTP.
Ich meine, wenn du ohnehin mit SQL-Server arbeitest, hängst du sowieso ein PHP/WEB-Frontend davor und kommst von außen daran -- warum also SQL direkt?

Als Protokoll zum Backend würde ich vorläufig mysql-Tools nehmen

was zwangsweise einen installierten MySQL-Client im Backend erfordert.

Gerade wenn auch noch Performance dahinter sein soll.

Wenn Funk-Nachrichten mit maximal 1200 Baud eingehen, ist die Performance glaube ich das geringste Problem.

Andreas

[Buebchen]

Wie wäre es mit "gar nicht". Warum direkt gegen MySQL schreiben? Warum nicht ODBC, dann kann das SQL-Modul gegen jede SQL-Datenbank schreiben und die Login-Verwaltung ist Sache des ODBC-Treibers.

Und woher weiss der SQL Agent, daß die Anmeldung, die da Daten holen will gültig sind ? Wenn ich nen monitor-client habe, der eine History zum Rettungsmittel zeigen soll, dann ist der

* am monitord angemeldet
* am sql angemeldet

... aber mit welchen Benutzernamen und viel wichtiger: wo werden diese zentral gepflegt ? Oder muss man dann immer die Benutzer zweimal anlegen ?

Da sträuben sich mir die Nackenhaare! SQL via Internet ohne VPN. Warum sollte das jeman tun wollen? Jedes Linux und jedes Windows beherrscht zumindest PPTP.
Ich meine, wenn du ohnehin mit SQL-Server arbeitest, hängst du sowieso ein PHP/WEB-Frontend davor und kommst von außen daran -- warum also SQL direkt?

Also mein altes Handy kann mal kein VPN :-)

was zwangsweise einen installierten MySQL-Client im Backend erfordert.

und ? Warum auch nicht ? Wer ihn nicht will kann ihn ja abschalten

Wenn Funk-Nachrichten mit maximal 1200 Baud eingehen, ist die Performance glaube ich das geringste Problem.

Andreas

Wenn ich aus 2 Mio Datensätze die FMS Protokolle eines Standorts für die letzten 24 Stunden filtere und mir anzeigen lassen sind 1200 Baud nicht viel :-)

Wir sollten auf jeden Fall drei Fälle unterscheiden.

1. Ein "Textbasierter Client" wie bisher
Er fragt weder einer Historie ab, noch sonst was. Braucht auch keine DB

2. Ein grafischer Client - Vielleicht eine Mischung aus Crusader und FMS32
Der könnte z.B. schon Daten aus der History-DB abfragen können

3. Ein erweiterter Client, der neben der reinen "Ansicht" der Funkdaten weitere Aufgaben übernimmt (Einsatztagebuch, Meldungsverwaltung, Patientenerfassung,...) und diese mit den Daten der History-DB verknüpft.

Nun ja. Erstmal nicht sooo wichtig. Ich werde definitiv eine Datenbankanbindung schreiben. Wer sie nutzt, kann das tun. Wer sie nicht will schaltet sie eben ab. Wichtiger ist das TCP Protokoll. Sonst gibts auch vorläufig keine Clients.

[nepomuck]

Und woher weiss der SQL Agent, daß die Anmeldung, die da Daten holen will gültig sind ?

SQL-Agent meldet sich am Backend an -- User meldet sich bei Backend an -- User fragt Backend nach SQL -- Backend übermittelt dem User die IP des SQL-Agenten UND sendet dem SQL-Agenten die IP des Users zu und bestätigt damit, dass er ran darf.

Also mein altes Handy kann mal kein VPN :-)

Einen MySQL-Client wird's dann ja auch nicht haben.

und ? Warum auch nicht ? Wer ihn nicht will kann ihn ja abschalten

Ohne MySQL-Client plus Headers und Libs läuft dann wieder kein Make durch. Oder es kommt ein neues Distributionsupdate mit einem neuen MySQL-Client raus der evtl. nicht zum Code passt und dann hängt wieder alles.
Je weniger Dependencies das Backend hat, umso besser.
Und ich würde Bosix 0.2 liebend gerne von einem USB-Stick anstelle einer CD booten und dafür würde ich die Linux-Distribution gerne so klein wie es irgend geht machen.

MySQL-Client = 5.6 MB. Libs and Headers = 7.3 MB Shared Libs = 1.6 MB
macht 14.5 MB
MyODBC = 2.5 MB

Wenn ich aus 2 Mio Datensätze die FMS Protokolle eines Standorts für die letzten 24 Stunden filtere und mir anzeigen lassen

OK. Aber für das Data-Mining kannst du ja eine Applikation schreiben, die direkt auf MySQL zugreift. Für das Backend würde ODBC genügen.

1. Ein "Textbasierter Client" wie bisher

der nur eine TCP-Verbindung zum Backend herstellt

2. Ein grafischer Client

der per TCP mit dem Backend und dem SQL-Agenten in Verbindung steht

3. Ein erweiterter Client

Der per TCP mit dem Backend und per MySQL-CLient mit der Datenbank in Verbindung steht.

Andreas

[Buebchen]

Einen MySQL-Client wird's dann ja auch nicht haben.

Aber ein SDK für Java. Und das kann Datenbankzugriffe. Aber eben kein VPN.

Ohne MySQL-Client plus Headers und Libs läuft dann wieder kein Make durch. Oder es kommt ein neues Distributionsupdate mit einem neuen MySQL-Client raus der evtl. nicht zum Code passt und dann hängt wieder alles.
Je weniger Dependencies das Backend hat, umso besser.
Und ich würde Bosix 0.2 liebend gerne von einem USB-Stick anstelle einer CD booten und dafür würde ich die Linux-Distribution gerne so klein wie es irgend geht machen.

MySQL-Client = 5.6 MB. Libs and Headers = 7.3 MB Shared Libs = 1.6 MB
macht 14.5 MB
MyODBC = 2.5 MB

Die Grössen sind aber doch nicht nur die benötigten libraries. Das betrifft doch nur die build Umgebung. Die dll und shared-lib für mysql haben um die 1MB. ODBC weiss ich nicht.

Soll an dieser Stelle auch erstmal egal sein. Ich werde das in eine virtuelle Funktion packen. Das DB Backend wäre dann mal generell austauschbar. Vielleicht auch eine Klasse, die die Daten repräsentiert.

der nur eine TCP-Verbindung zum Backend herstellt

der per TCP mit dem Backend und dem SQL-Agenten in Verbindung steht

Der per TCP mit dem Backend und per MySQL-CLient mit der Datenbank in Verbindung steht.

Andreas

Das hätte mein Full-ACK.

Die Geschichte mit SQL-Agent fragt monitord nach Useranmeldung etc ist vom Gedanken her gut. Bin mir nur noch nicht so sicher, ob das dann im technischen Detail auch ohne Probleme klappt.

Werde mir mal die aktuellen ODBC Varianten bei Gelegenheit mal anschauen. Vielleicht tritt da ja noch ein Sinneswandel bei mir ein.

[nepomuck]

Die Grössen sind aber doch nicht nur die benötigten libraries. Das betrifft doch nur die build Umgebung. Die dll und shared-lib für mysql haben um die 1MB. ODBC weiss ich nicht.

Ok. Dannn sollte es gehen. Ich muss für den Remaster-Prozess alles installieren, den Make fahren und kann danach die Bulid-Umgebung und Headers wieder entfernen. Ich brauche dann nur eine Liste der shared libs, die bleiben müssen.

Andreas

[jhr-online]

Wenn ich noch mal was technisches reinwerfen darf:
Wie wäre es damit, wenn ich sich einer derjenigen, die auch wirklich verstehen, was hier geplant ist, mal dranmachen würde, das ganze etwas systematisch im Wiki aufzuarbeiten. Der Thread wird langsam unübersichtlich - die ersten beklagen sich :)
Da ich am Code nicht viel mitarbeiten kann, bin ich gerne bereit, mich weiter in dieses organisatorisch reinzuhängen, aber den ersten Schritt muss wirklich jemand machen, der das alles versteht... Die Vorschläge auseinanderhalten und das, was zusammen gehört, auch zusammen zu formulieren; Backend- von Frontend-Vorschlägen trennen etc.

Hat jemand Lust? Hier geht's los:
http://monitor.08k.de/index.php/Devel bzw. eigentlich erst
hier: http://monitor.08k.de/index.php/Devel/2.0

jhr

Nachtrag: Ich muss ja nicht alles selber machen und auf meinem PC horten... :) Tragt euch ein: http://monitor.08k.de/index.php/Devel/Team

[Norad]

Moin, ich mische mich hier auch mal ein :)
Mir scheint, dass die Komplexität hier gerade explodiert ;)

Ich würde mir das so vorstellen:
monitor-backend: nimmt Daten von der Soundkarte und stellt diese Dekodiert über TCP zur Verfügung. Kein Logging, keine Datenbank.

Frontends: z.B. Daten in eine Datenbank schreiben, Daten in ein Log schrieben usw.
Ein GUI- (oder Textkonsolen-) Frontend würde aktuelle Ereignisse direkt vom Monitor-Backend bekommen und könnte die Historie entweder direkt aus der Datenbank des DB-Frontends abrufen oder evtl. mit dem DB-Frontend kommunizieren. Für den Direktzugriff auf die DB müssen GUI- und DB-Frontend sich bloß auf eine Datenbankstruktur einigen, für die andere Variante müsste man ein Protokoll entwerfen ...