monitor 1.9.0 - aber richtig :)

[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