Remote Logging / z.B. Syslog Support

hmm, das ist ein Windows-System. Ich lese in der php-DOku gerade, das es die facility locale0 … local7 unter Windows nicht zur Verfügung steht.Das bedeutet es gibt dann nur die Facility ‚user‘, die DU verwenden kannst.

Mach mal ein Update …

demel

So jetzt erst zum weitertesten gekommen.
Message senden kommt schonmal an.
Aber bei Nachricht checken bekomme ich folgende Fehlermeldung:

28.02.2019, 17:13:08 | TimerPool | Syslog (CheckMessages): <br />
<b>Warning</b>: Der Bereich der Nachricht ist größer als der Nachrichtenpuffer in <b>C:\Program Files (x86)\IP-SYMCON\modules\IPSymconSyslog\IPSymconSyslog\module.php</b> on line <b>188</b><br />
<br />
<b>Warning</b>: Invalid argument supplied for foreach() in <b>C:\Program Files (x86)\IP-SYMCON\modules\IPSymconSyslog\IPSymconSyslog\module.php</b> on line <b>192</b><br />

Gesendet von iPad mit Tapatalk

in der Zeile 188 des Modules mache ich den Abruf

$r = IPS_GetSnapshotChanges($TimeStamp);

D.h. es kommen mehr Daten zurück, als IPS verarbeiten kann.

Ich bin mir nichtsicher, ob das der richtige Spezialschalter ist, aber ich würde den vermuten: MessageRingBufferSize. eventuell kannst Du das was dran drehen?

Welches Update-Intervall hast Du eingestellt?

Bei mir läuft das mit einem 10s-Intervall. (auf eine Raspberry mit Standard-IPS-Einstellung: 8kb).

Gruß
demel

Hallo
Hab das mal nur mit dem Befehl IPS_GetSnapshotChanges
Getestet. Was genau sagt der Parameter $Timestamp ?
Ist doch kein UnixTimestamp ?
Bei mir :
IPS_GetSnapshotChanges(0) bringt eine Stringlaenge von ca 150 Byte.
IPS_GetSnapshotChanges(1) bringt schon diesen Fehler.

Dein Script hat als Timestamp schon einen Wert von 8459.

Alle 10 Sekunden probiert wie bei dir mit 8192 und diesen auch mal verdoppelt.

Gesendet von iPad mit Tapatalk

nein, kein Unix-Timestamp. Das schein ein laufender Zähler zu sein, Es wird jeweils der letzte ‚TimeStamp‘ aus dem Ergebnis vom IPS_GetSnapshotChanges() genommen.
Man fängt immer mit 0 an und bekommt eine Array mit Lämge 1 und nimmt den TimeStamp heraus und macht mit dem weiter. d.h. immer den TimeStamp aus dem letzten Array-Element.

Alle 10 Sekunden probiert wie bei dir mit 8192 und diesen auch mal verdoppelt.

sorry, aber den Satz habe ich nicht verstanden.

gruß
demel

Updatezeit 10 Sekunden
Buffergroesse 8192 Byte (8kb)

Gesendet von iPad mit Tapatalk

d.h. also, es klappt so gerade? Ich würde das Intervall mal kürzer setzen. Um so weniger Daten sind das pro Abruf

demel

Nein , Mit einer Sekunde und 16Kb kommt schon der Fehler.
Muss das heute abend mehr testen wenn ich zu Hause bin.
Alles war bisher von unterwegs.

Gesendet von iPad mit Tapatalk

Das Problem muss woanders liegen. ich habe das Moudl auf IPS 5 angepasst (fehlende define’s) und auf meinem ProdSys zum laufen gebrach (Ubuntu). Die Datenmenge ist deutlich über 8kb.
Mein Verdacht ist ein anderr: hast Du ggfs. Variablen, die geößer al 8kb sind (zB eine HTML-Box?)
ich habe mal was eingebaut, was Text der Nachricht auf 1kb kürzt. Ist ja eh die Frage, was der Syslog mit so grossen Messages anfangen würde.

Mach mal ein Update und schalte gleich auch den Modul-Debug ein, das müssten Infos über die Längen geben

demel

Du hast da 2 Fehler im Script @ und return , Besser so

        $r = @IPS_GetSnapshotChanges($TimeStamp);
        if ($r == '') {
            $this->SetStatus(IS_BUFFEROVERRUN);
            return;

Hab ein Bufferoverrun.
Ich denke das Problem liegt wo anders.
Hab mit echo IPS_GetSnapshotChanges(0); mal den aktuelen Timstamp mir geholt und den in
dein Script kurz eingetragen. Danach hab ich fuer einige Zeit keinen Fehler. ( Updatezeit 2 Sekunden )
Aber so nach ein paar updates wird die Variable $Timestamp nicht mehr aktualisiert und laeuft
sozusagen dann aus dem „Fenster“. Der Abstand $Timestamp zu aktuelem Timestamp wird so gross,
dass es zu einem BUFFEROVERRUN kommt.

Hab jetzt mal mal die Variable $Timestamp „manipuliert“ indem ich folgendes ins Script eingefuegt habe.

				$r = IPS_GetSnapshotChanges(0);
        $obj = json_decode($r, true);
				$TimeStamp = $obj[0]['TimeStamp'];
        $TimeStamp = $TimeStamp - 1000;

length of data zwischen 80000 und 600000

da miit ‚return‘ ist natürlich ein Tippfejler, ist korrigiert.
Aber der @ dient doch dazu, die PHP-Fehlermeldung zu unterdrücken - statt dessen setze ich den neuen Status BUFFEROVERRUN.

Hab ein Bufferoverrun.
Ich denke das Problem liegt wo anders.
Hab mit echo IPS_GetSnapshotChanges(0); mal den aktuelen Timstamp mir geholt und den in
dein Script kurz eingetragen.

das macht er beim Start ja automatisch, den TimeStamp speichert es dann ja zwischen über ein SetBuffer.

Danach hab ich fuer einige Zeit keinen Fehler. ( Updatezeit 2 Sekunden )
Aber so nach ein paar updates wird die Variable $Timestamp nicht mehr aktualisiert und laeuft
sozusagen dann aus dem „Fenster“. Der Abstand $Timestamp zu aktuelem Timestamp wird so gross,
dass es zu einem BUFFEROVERRUN kommt.

Hmm, ist mir spontan erstmal ein Rätsel…

War bis jetzt der Meinung man macht das vor die Funktion und nicht ganz vorne.
Gibt es da einen Unterschied:confused:

damit ist doch aber die Sequenz der Messages nicht mehr in Ordnung? Wenn Du in dem IPS_GetSnapshitChanges() weniger als 1000 Nachrichten hast kommen immer wieder die gleichen (würde ich sagen(. Irgendwann hat IPS die Messages nicht mehr in seinem internen puffer und dann kommt nix mehr.

Bei mir ist die Größe der Snapshots zwar auch mehr als 8kb, aber auch nicht mehr vielleicht 15-20kb.
Da in den Messages ja auch Variablen-Änderungen auftauchen - so wie im normaln IPS-Log - ist mein verdacht weiterhin in diese Richtung.
Wie viele Nachrichten hast du denn pro Intervall? (gebe ich im debug aus „size of array“ und ich gebe bei jeder einzelnen Nachricht die Größe aus.

Gruss
demel

ich verstehe das so, das quasi ab dem @ die Meldungen unterdrückt werden. Wäre also hier equivalent (weil die Zuweisung an sich ja kein Problem machen kann). Aber de @ vor der Funktion ist sicherlich „korrekter“.

Naja ich bekomme da immer eine Fehlermeldung

28.02.2019 23:09:16 | TimerPool | Syslog (CheckMessages): <br />
<b>Warning</b>:  count(): Parameter must be an array or an object that implements Countable in <b>C:\Program Files (x86)\IP-SYMCON\modules\IPSymconSyslog\IPSymconSyslog\module.php</b> on line <b>209</b><br />
<br />
<b>Warning</b>:  Invalid argument supplied for foreach() in <b>C:\Program Files (x86)\IP-SYMCON\modules\IPSymconSyslog\IPSymconSyslog\module.php</b> on line <b>212</b><br />

DebugFenster:

start cycle with TimeStamp=682241
length of data=12065411
size of array=0

Hallo,

das ist eine Folge davon, das die Daten von IPS_GetSnapshotChanges() nicht json-dekodiert werden können (warum auch immer und darf nicht sein). ich geben nun den json.-error aus.

Ich habe auch noch einige Punkte nachgearbeitet, so kann man zB auf Inhalte Filter (in Sender und Text) sowie das ein oder andere überarbeitet.
Sind aber keine Fehlerkorrekturen, die bei deinem Problem helfen können. Ich finde die Größen, die du dort ausgegeben bekommst, abstrus - da das ja alles Nachrichten sind, die (auch) im normalen IPS-Logfile landen, hätten die angegebenen 1.2MB innerhalb weniger Minuten ein gigantisches Logfile zur Folge.

Gruß
demel

Schon daran gedacht das auch MediaObjekte (Bilder und IPSView Files können mehrere MB haben) dort mit durchrauschen?
Die landen natürlich nicht im Log, aber bei Änderungen auch im Snapshot.
Michael

Wobei die Daten nicht in den Snapshot Changes drin sind. Es kommt nur eine Meldung, dass es neue Daten gibt :slight_smile:

Die Aussage, dass alles im Logfile landet ist übrigens nicht korrekt. :slight_smile:

paresy

So mit der neuen Version bekomme ich alle paar Sekunden folgende Fehlermeldung:

01.03.2019, 15:42:10 | CheckMessages | unable to decode json-data, error=5, data=[{„TimeStamp“:7506545,„SenderID“:12971,„Message“:10206,„Data“:[„CheckMessages“,„c3RhcnQgY3ljbGUgd2l0aCBUaW1lU3RhbXA9NzUwNjQ4Mg==“,0,1551451244]},{„TimeStamp“:7506546,„SenderID“:12971,„Message“:10206,„Data“:[„CheckMessages“,„bGVuZ3RoIG9mIGRhdGE9MTQ3MjU5“,0,1551451244]},{„TimeStamp“:7506547,„SenderID“:12971,„Message“:10206,„Data“:[„CheckMessages“,„bWVzc2FnZS1jb3VudD02Mg==“,0,1551451244]},{„TimeStamp“:7506548,„SenderID“:12971,„Message“:10206,„Data“:[„CheckMessages“,„U2VuZGVySUQ9MCwgTWVzc2FnZT0xMDIwMSwgc2VuZGVyPVNldHRpbmdzLCB0ZXR4LWxlbj0yNSwgdGV4dD1TY2hyZWliZSBFaW5zdGVsbHVuZ2VuLi4uLCB0c3RhbXA9MDEuMDMuMjAxOSAxNTo0MDo0Mg==“,0,1551451244]},{„TimeStamp“:7506549,„SenderID“:12971,„Message“:10206,„Data“:[„Message“,„c2VydmVyPTE5Mi4xNjguMS41LCBwb3J0PTUxNCwgbWVzc2FnZT0iPDE0PjEgMjAxOS0wMy0wMVQxNTo0MDo0NCswMTowMCBCYXJlYm9uZSBpcHN5bWNvbiAtIDE1NTE0NTEyNDQwMDAwMDAgLSBTY2hyZWliZSBFaW5zdGVsbHVuZ2VuLi4uIg==“,0,1551451244]},{„TimeStamp“:7506550,„SenderID“:0,„Message“:11202,„Data“:[1,3,8,1551451244]},{„TimeStamp“:7506551,„SenderID“:…

Gesendet von iPad mit Tapatalk