Weiter zum Inhalt
  • Home
  • Aktuell
  • Tags
  • 0 Ungelesen 0
  • Kategorien
  • Unreplied
  • Beliebt
  • GitHub
  • Docu
  • Hilfe
Skins
  • Hell
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dunkel
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Standard: (Kein Skin)
  • Kein Skin
Einklappen
ioBroker Logo

Community Forum

donate donate
  1. ioBroker Community Home
  2. Deutsch
  3. Skripten / Logik
  4. JavaScript
  5. ioBroker Prozess- & Gesundheitsmonitor + Grafana + HTML

NEWS

  • Neuer ioBroker-Blog online: Monatsrückblick März/April 2026
    BluefoxB
    Bluefox
    8
    1
    750

  • Verwendung von KI bitte immer deutlich kennzeichnen
    HomoranH
    Homoran
    10
    1
    573

  • Monatsrückblick Januar/Februar 2026 ist online!
    BluefoxB
    Bluefox
    18
    1
    1.1k

ioBroker Prozess- & Gesundheitsmonitor + Grafana + HTML

Geplant Angeheftet Gesperrt Verschoben JavaScript
javascriptmonitoring
78 Beiträge 8 Kommentatoren 2.1k Aufrufe 13 Beobachtet
  • Älteste zuerst
  • Neuste zuerst
  • Meiste Stimmen
Antworten
  • In einem neuen Thema antworten
Anmelden zum Antworten
Dieses Thema wurde gelöscht. Nur Nutzer mit entsprechenden Rechten können es sehen.
  • crunchipC crunchip

    ioBroker Prozess-Monitor — Langzeit-Gesundheitsmonitoring

    Ich stelle hier mein Script für ein erweitertes Prozess- und Gesundheitsmonitoring von ioBroker vor, inklusive passendem Grafana-Dashboard für InfluxDB v1. (InfluxQL )
    InfluxDB v2 ist grundsätzlich vorgesehen, aktuell aber noch nicht als separates Dashboard-Paket enthalten.
    Habe das Grafana json (flux) im Beitrag unten ergänzt, jedoch ungetestet

    Das Script nutzt Standard-States wie system.adapter.* und system.host.* und benötigt keinen zusätzlichen eigenen Adapter.
    Für Log-Tracking und die Erkennung degradierter Adapter wird onLog des JavaScript-Adapters benötigt.

    Enthalten sind unter anderem:

    • CPU-/RAM-Monitoring aller laufenden Adapter
    • Restart-Tracking für Flaky-Adapter und Cron-Restarts
    • Memory-Leak- und Deadlock-Erkennung
    • Log-Error-/Warn-Tracking und Degraded-Adapter-Bewertung
    • Host-, Disk- und Health-Score-Monitoring
    • Optionale Telegram-Alarme und REST-Auswertung
    • Übersicht über deaktivierte Adapter

    Getestet auf Raspberry Pi, VM, LXC, Docker und Unraid; produktiv läuft es aktuell auf Docker/Unraid.
    Ziel ist die Früherkennung schleichender Probleme in produktiven ioBroker-Systemen.

    Wichtig:
    Nach dem Import des Dashboards bitte zuerst DSINFLUXDB, DSINFINITY und iobrokerurl prüfen bzw. auswählen.
    Erst danach liefern alle Panels und REST-basierten Tabellen zuverlässig Daten.

    Im Beitrag:

    1. Script
    2. Grafana-Dashboard InfluxDB v1 ( InfluxQL )
    3. Grafana-Dashboard InfluxDB v2 (flux)
    4. Die für InfluxDB benötigten Datenpunkte; weitere Tabellen und Zusatzdaten kommen per Infinity direkt über die REST-API
      92378b3e-1ebf-4697-9f4d-79b7d4a03095-image.png
    5. Variablen anlegen siehe https://forum.iobroker.net/post/1330170
    6. Für dein Dashboard und die Ressourcen ist entscheidend, wie du die Datenpunkt‑spezifischen Influx‑Einstellungen je Typ setzt – nicht global alles gleich.

    Grundprinzip je Datenpunkttyp

    • Langsam ändernde Zustände (Booleans, Modus, Error‑Flags, Health‑Scores, Event‑Pulse):
    • Nur Änderungen aufzeichnen: an
    • Entprellzeit: 300–1000 ms
    • Blockzeit: 0
    • „Trotzdem gleiche Werte aufzeichnen“: 600–3600 s (je nach gewünschter History‑Auflösung)
    • Minimale Differenz: 0 (bei Booleans/Zahlen mit kleinem Bereich)
    • Ergebnis: sehr wenige Punkte, aber alle Zustandswechsel sauber im Grafana‑Dashboard.

    Kontinuierliche Messwerte mit Trend (CPU‑Last, RAM‑MB, Host‑Disk‑FreeMB, Health‑Score):

    • Nur Änderungen aufzeichnen: an
    • Entprellzeit: 500 ms wie im Screenshot ist ok
    • „Trotzdem gleiche Werte“: auf deinen Script‑Zyklus bzw. Host‑Intervalle ausrichten, z. B. 180–300 s, damit Influx wenigstens alle paar Minuten einen Punkt bekommt, selbst wenn sich nichts ändert.
    • Minimale Differenz: z. B. 1 % bei CPU‑Werten, 5–10 MB bei RAM, 1 Punkt beim Health‑Score.
    • Ignoriere 0/Nullwerte: an, falls der DP beim Start kurz 0/NULL ist und das im Dashboard nicht stören soll.

    Pulse‑Werte für Events (RestartEventPulse, FlakyEventPulse, Deadlock‑Alarm‑Pulse etc.):

    • Nur Änderungen: an
    • Trotzdem gleiche Werte: 0 s (nicht nötig, der Pulse ist ein kurzer Wechsel 0→1→0)
    • Entprellzeit: klein (100–200 ms), damit jeder Pulse als eigener Punkt landet.
    • 0/Null ignorieren: aus, sonst siehst du nur die 1, aber keinen „Rückfall“ im Graphen.
    Bereich Datenpunkte
    Grundprinzip / langsam ändernde Zustände SystemHealthScore, DisabledAdaptersCount, ConnectionIssuesCount, DeadlockAdapters, DisconnectedCount, FlakyAdaptersCount, CronRestartCount, MemoryLeakCount, LogErrorCount, LogErrors1hTotal, LogWarns1hTotal, CriticalAdaptersCount, WarningAdaptersCount, CPUAlarmCounter, RAMAlarmCounter, RestartCount24h
    Kontinuierliche Messwerte ioBrokerCPUGesamt, ioBrokerRAMGesamt, HostCPULoad, HostCPUOther, HostRAMFreeMB, HostRAMAvailMB, HostRAMUsedMB, HostRAMTotalMB, HostRAMUsedPercent, HostLoadAvg, HostUptimeDays, HostEventLoopLag, DiskFreeMB, DiskUsedPct
    Puls-Werte RestartEventPulse, FlakyEventPulse

    Feedback, Tests in anderen Umgebungen und Verbesserungsvorschläge willkommen! 🚀

    🔥 NEU: Prozess-Monitor

    // CHANGELOG v4.6.7 (04.05.2026)
    // ============================================================
    // ✅ E-Mail-Benachrichtigung (email-Adapter): parallel zu Telegram/Pushover,
    // gleicher Cooldown, gleiche Alarmtyp-Schalter (EMAIL*ALERT)

    Changelog_old


    CHANGELOG v4.6.6 (20.04.2026) RAM-Prozent mit Docker-tauglicher Bezugsgröße (Cgroup / manuell).


    ✅ RAMPERCENTBASIS / RAMPERCENTMANUALMB: gemeinsamer Nenner für alle RAM-%-Werte (ioBroker-Gesamt + Host „frei“) → Prozent im Container bezieht sich auf Cgroup-Limit oder festen Wert, nicht blind auf Host-totalmem
    ✅ readCgroupMemoryLimitBytes(): liest memory.max (v2) bzw. memory.limit_in_bytes (v1) → passendes Limit unter Linux/Docker, wenn gesetzt
    ✅ Modi cgroup_or_host / host / cgroup / manual: steuerbar, wann Cgroup, Hardware oder manuelle MB greifen → klare Experten- vs. Standard-Logik
    ✅ formatRAMAlertMessage(): wenn Prozent aktiv, aber keine Bezugsgröße ermittelbar → Text nennt MB-Fallback und Hinweis zu RAMPERCENT* → Telegram passt zur echten Alarmlogik

    CHANGELOG v4.6.5 (20.04.2026) RAM-Schwellen wahlweise in Prozent oder MB (Einsteiger / Experte).


    ✅ IOBROKERRAMTHRESHOLDMODE percent | mb: ioBroker-Gesamt-RAM → entweder RAMWARNINGPCT / RAMCRITICALPCT oder RAMWARNING / RAMCRITICAL (MB)
    ✅ HOSTRAMTHRESHOLDMODE percent | mb: freier Host-RAM → entweder HOSTRAMFREEPCT oder HOSTRAMFREEMB → beide Bereiche unabhängig umschaltbar
    ✅ resolveIoBrokerRamAlarmLevels() + Dashboard-Kachel: Farbe/Limit-Text folgen dem Modus → konsistent zu checkAlarm und HTML-DashboardHTML
    ✅ Host-RAM-Alarm & Host-Kachel: Prozent nutzt dieselbe Bezugsgröße wie ioBroker-% (ab v4.6.6 inkl. Cgroup/Manual) → einheitliche Semantik
    Hinweis: Script neu starten. Grafana ändert sich nicht von selbst (keine Dashboard-Datei im Skript); nur Schwellzeitpunkte können sich bei Umstellung auf Prozent verschieben — fest eingetragene MB-Linien in Panels ggf. anpassen. Wer nur klassisch MB will: IOBROKERRAMTHRESHOLDMODE: 'mb' und HOSTRAMTHRESHOLDMODE: 'mb' setzen.

    CHANGELOG v4.6.4 (17.04.2026) HTML-Dashboard für VIS / Jarvis / iQontrol (ohne Grafana).


    ✅ Optionales Dashboard: DASHBOARDHTMLENABLED (Standard: true) → State …Prozesse.DashboardHTML mit role: 'html'
    ✅ Eigener Rhythmus: DASHBOARDHTMLINTERVAL in Minuten (Standard: 10, 0 = kein Schedule) → weniger Last als beim Haupt-Monitoring
    ✅ Kein History-Müll: Beim Anlegen des States sind InfluxDB / history / sql für genau diesen State per custom deaktiviert → nur dieser eine State, Rest unverändert
    ✅ Dirty-Check: HTML wird nur geschrieben, wenn sich der Inhalt geändert hat → weniger DB-Schreibvorgänge
    ✅ Sparklines: RAM-Verlauf aus memoryHistoryCache mit Downsampling (max. 20 Punkte) → kompakt für Raspberry & Co.
    Hinweis: In VIS z. B. Widget „String (unescaped)“ auf DashboardHTML legen. Bei abweichenden Adapter-Instanzen (influxdb.2 etc.) custom im Script anpassen.

    CHANGELOG v4.6.3 (17.04.2026) Performance, Bugfixes, Stabilität.


    ✅ formatCPUAlertMessage() ergänzt → war nicht definiert, sonst ReferenceError beim CPU-Kritisch-Alarm
    ✅ Stats-Zyklus-Cache: getProcessStats() pro Adapter nur noch einmal pro Zyklus statt mehrfach → deutlich weniger getState()-Aufrufe
    ✅ $()-Selector: aliveSelector einmal pro updateMonitoring() und an getDisabledAdapters() übergeben
    ✅ Log-History: Obergrenze pro Adapter und Severity (errors / warns) → Schutz vor RAM-Wachstum bei Dauerfehlern
    ✅ Memory-History: harte Obergrenze der gespeicherten Punkte pro Adapter
    ✅ Schedule-Fix: cleanupAllLogErrors von */60 * * * auf 5 Felder */60 * * * * → Cleanup lief vorher nicht
    ✅ purgeOrphanAdapterPersistentData() nur noch stündlich statt bei jedem Monitoring-Zyklus
    ✅ Pulse-States: setStateDelayed(…, clearRunning=true) statt setTimeout für Restart-/Flaky-Pulse → weniger Überschneidungen
    Hinweis: Script neu starten. Bei bereits existierendem DashboardHTML ohne custom ggf. History in der Admin-UI prüfen (siehe v4.6.4).

    CHANGELOG v4.6.2 (14.04.2026) Pushover als zweiter Benachrichtigungskanal neben Telegram.


    ✅ Pushover-Unterstützung: Neuer Konfig-Block mit PUSHOVERENABLE, PUSHOVERINSTANCE, PUSHOVERDEVICE, PUSHOVERTITLE und PUSHOVERPRIORITY (-2 bis 1) → komplett optional, per Default deaktiviert
    ✅ Granulare Schalter: Jeder Alarmtyp hat einen eigenen Pushover-Schalter (PUSHOVERALERT) → analog zu den bestehenden TELEGRAMALERT-Flags
    ✅ Gemeinsamer Cooldown: sendAlert() löst Telegram und Pushover gleichzeitig aus → ein Timer pro Alarmtyp verhindert Alarmflut auf beiden Kanälen
    ✅ Keine Änderung für bestehende Nutzer: Telegram-Konfiguration bleibt unverändert

    Hinweis: PUSHOVERENABLE: true setzen, PUSHOVERINSTANCE anpassen, Script neu starten. ioBroker Pushover-Adapter muss installiert und konfiguriert sein.

    CHANGELOG v4.6.1 (13.04.2026) Minütliche Controller-Warnungen nach Adapter-Deinstallation behoben.


    ✅ existsObject() vor getObject(): Fehlende system.adapter.*-Objekte werden übersprungen → keine minütlichen „Object … does not exist“-Warnungen mehr
    ✅ History-Bereinigung: Uptime-, Log- und Memory-Einträge deinstallierter Instanzen werden beim Monitoring-Lauf automatisch entfernt

    Hinweis: Aktueller ioBroker.javascript-Adapter mit existsObject() empfohlen. Script neu starten.

    CHANGELOG v4.6.0 (20.03.2026) Konfigurationsbereich vollständig neu strukturiert.


    ✅ Neue Konfig-Struktur: Benutzerwerte, Schwellwerte und Expertenwerte klar getrennt
    ✅ Benutzer-Checkliste ergänzt: Schneller erkennbar, welche Werte angepasst werden sollen
    ✅ Einheitliche Kommentare und Abschnittsüberschriften → forumtauglicher, übersichtlicher, leichter wartbar
    ✅ Kein funktionaler Eingriff: Bestehende States, Prüfungen und Features bleiben vollständig erhalten
    ✅ Neu: Deaktivierte Adapter: DisabledAdaptersCount und DisabledAdapters werden erfasst und als State geschrieben

    Script
    iobroker-prozessmonitor_v4.6.7

    Das Dashboard (InfluxQL )
    dashboard-4.6.0-Final

    NEU 30.03.2026
    Das Dashboard (Flux)
    dashboard-4.6.0_flux

    6f1fa838-d2ed-4bcc-979c-106f6c6d64b3-image.png
    a993a827-5211-429f-8da5-439af66494c5-image.png
    21551d26-8e42-4686-be68-3fd5b1bdba9d-image.png
    b146f87b-c57e-4ca7-b972-5c8df09c06c3-image.jpeg

    Offene Tuning-Punkte

    • Flaky: aktuell 3 Restarts in 24h — sinnvoller Grenzwert, wenn geplante Cron-Restarts toleriert werden?
    • Errors: aktuell 3/h Warnung und 20/h kritisch — passen diese Werte in anderen Umgebungen?
    • Worst/Best Performer: Gewichtung des Health Scores noch offen für Feintuning.
    • Degraded Adapter: aktuell kritische Error-Rate ab 10/h plus CPU > 12 und/oder Event Loop Lag > 100 ms — praxistauglich?
    • Event Loop Lag: aktuell 500 ms kritisch als allgemeiner Schwellwert — vermutlich hardwareabhängig?
    • Memory Leak: aktuell ab (R^2 > 0.65) und Wachstum > 15 MB/h — Erfahrungswerte willkommen.
    • Deadlock: aktuell alive=true und connected=false — eventuell noch erweiterbar.
    sigi234S Online
    sigi234S Online
    sigi234
    Forum Testing Most Active
    schrieb am zuletzt editiert von sigi234
    #59

    @crunchip

    Hallo,

    kannst du bitte noch eine E-Mail Benarichtigung einbauen?

    Wo kann ich den Hintergrund für das HTML Widget einstellen? (transparent)
    Wegen Anpassung für AURA.

    Erledigt, passt sich im Frontend eh an. 😀

    LG
    Sigi

    Bitte benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
    Immer Daten sichern!

    crunchipC 1 Antwort Letzte Antwort
    0
    • sigi234S sigi234

      @crunchip

      Hallo,

      kannst du bitte noch eine E-Mail Benarichtigung einbauen?

      Wo kann ich den Hintergrund für das HTML Widget einstellen? (transparent)
      Wegen Anpassung für AURA.

      Erledigt, passt sich im Frontend eh an. 😀

      LG
      Sigi

      crunchipC Abwesend
      crunchipC Abwesend
      crunchip
      Forum Testing Most Active Developer
      schrieb am zuletzt editiert von crunchip
      #60

      @sigi234 sagte:

      eine E-Mail Benarichtigung einbauen

      Lässt sich sicherlich machen, wenn ich heut abend dazu komme

      @sigi234 ist drin, siehe ersten Beitrag

      umgestiegen von Proxmox auf Unraid

      sigi234S 1 Antwort Letzte Antwort
      1
      • R Offline
        R Offline
        rallef
        schrieb am zuletzt editiert von
        #61

        top5cpu.jpg

        1 Antwort Letzte Antwort
        0
        • R Offline
          R Offline
          rallef
          schrieb am zuletzt editiert von
          #62

          wenn ich in der api den befehl absetze funktioniert es. Nochmal welchen port muss ich nehmen? 8081 vom admin iobroker oder 8093 von der rest api. Was soll ich neustarten Grafana? Grafana läuft in einem anderen container als iobroker.
          bei jedem neuen Aufruf von dem dashboard muss ich jedesmall die influxdb iobroker und den iobroker_url eintippen. die ist doch gespeichert

          crunchipC 1 Antwort Letzte Antwort
          0
          • R rallef

            wenn ich in der api den befehl absetze funktioniert es. Nochmal welchen port muss ich nehmen? 8081 vom admin iobroker oder 8093 von der rest api. Was soll ich neustarten Grafana? Grafana läuft in einem anderen container als iobroker.
            bei jedem neuen Aufruf von dem dashboard muss ich jedesmall die influxdb iobroker und den iobroker_url eintippen. die ist doch gespeichert

            crunchipC Abwesend
            crunchipC Abwesend
            crunchip
            Forum Testing Most Active Developer
            schrieb am zuletzt editiert von crunchip
            #63

            @rallef na so wie in der Anleitung und wie ich auch nochmals geschrieben habe, 8083 und so lang dein Port falsch ist, kann es nicht funktionieren

            @rallef sagte:

            muss ich jedesmall die influxdb iobroker und den iobroker_url eintippen

            Mann kann das auch in den Variablen festlegen und die obere Anzeige im dashboard entfernen. Das ist nur drin für andere für den ersten Start als Hilfestellung
            @rallef
            dort schreibst du deinen Datenbanknamen rein und bei show on dashboard stellst du auf nothing
            3f0f23ca-5b5c-4e31-a130-7efa4038e5b5-image.jpeg

            umgestiegen von Proxmox auf Unraid

            1 Antwort Letzte Antwort
            0
            • R Offline
              R Offline
              rallef
              schrieb am zuletzt editiert von
              #64

              ok funktioniert jetzt super. Allerdings geht mein Synology NAS jetzt in die Knie. Mein iobroker belegt mehr als 44% RAM und es werden jede menge Warnings und errors in die influxdb geschrieben. schaukelt sich also hoch. da muss ich noch was optimieren

              crunchipC 1 Antwort Letzte Antwort
              0
              • R Offline
                R Offline
                rallef
                schrieb am zuletzt editiert von
                #65

                top ram.jpg

                1 Antwort Letzte Antwort
                0
                • R rallef

                  ok funktioniert jetzt super. Allerdings geht mein Synology NAS jetzt in die Knie. Mein iobroker belegt mehr als 44% RAM und es werden jede menge Warnings und errors in die influxdb geschrieben. schaukelt sich also hoch. da muss ich noch was optimieren

                  crunchipC Abwesend
                  crunchipC Abwesend
                  crunchip
                  Forum Testing Most Active Developer
                  schrieb am zuletzt editiert von
                  #66

                  @rallef sagte:

                  ede menge Warnings und errors in die influxdb geschrieben

                  die da wären?

                  @rallef sagte:

                  muss ich noch was optimieren

                  sollte eigentlich von haus aus so passen, mit den vorgegebenen Werten

                  umgestiegen von Proxmox auf Unraid

                  1 Antwort Letzte Antwort
                  0
                  • crunchipC crunchip

                    @sigi234 sagte:

                    eine E-Mail Benarichtigung einbauen

                    Lässt sich sicherlich machen, wenn ich heut abend dazu komme

                    @sigi234 ist drin, siehe ersten Beitrag

                    sigi234S Online
                    sigi234S Online
                    sigi234
                    Forum Testing Most Active
                    schrieb am zuletzt editiert von
                    #67

                    @crunchip sagte:

                    @sigi234 ist drin, siehe ersten Beitrag

                    DANKE! 👍

                    Bitte benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
                    Immer Daten sichern!

                    1 Antwort Letzte Antwort
                    0
                    • R Offline
                      R Offline
                      rallef
                      schrieb am zuletzt editiert von
                      #68

                      habe jetzt 350 warnings /h in der influxdb.0 und ich sehe das die instanz neugestartet wird. Mein Host Ram ist auch zeitweise kritisch nur 13% und mein iobroker Ram belegt mehr als 54% zeitweise
                      hab eine synology Nas DS918+ mit 12 GB ram

                      crunchipC 1 Antwort Letzte Antwort
                      0
                      • R Offline
                        R Offline
                        rallef
                        schrieb am zuletzt editiert von
                        #69

                        werde die mal auf 16GB aufrüsten

                        1 Antwort Letzte Antwort
                        0
                        • R rallef

                          habe jetzt 350 warnings /h in der influxdb.0 und ich sehe das die instanz neugestartet wird. Mein Host Ram ist auch zeitweise kritisch nur 13% und mein iobroker Ram belegt mehr als 54% zeitweise
                          hab eine synology Nas DS918+ mit 12 GB ram

                          crunchipC Abwesend
                          crunchipC Abwesend
                          crunchip
                          Forum Testing Most Active Developer
                          schrieb am zuletzt editiert von
                          #70

                          @rallef das der RAM oder die CPU mal schwankt ist normal, meine Frage lag eher darin:
                          Hattest du diese Probleme schon vorher oder wolltest du mir mitteilen, erst seit Scriptinstallation

                          umgestiegen von Proxmox auf Unraid

                          1 Antwort Letzte Antwort
                          0
                          • R Offline
                            R Offline
                            rallef
                            schrieb am zuletzt editiert von
                            #71

                            kann ich nicht sagen, aber es werden ja viele Änderungen in die influxdb geschrieben seitdem ich das Skript gestartetd habe

                            1 Antwort Letzte Antwort
                            0
                            • R Offline
                              R Offline
                              rallef
                              schrieb am zuletzt editiert von
                              #72

                              hab halt viele Warnungen die in der influxdb geschrieben werden
                              ich werde die mal posten

                              1 Antwort Letzte Antwort
                              0
                              • crunchipC crunchip

                                ioBroker Prozess-Monitor — Langzeit-Gesundheitsmonitoring

                                Ich stelle hier mein Script für ein erweitertes Prozess- und Gesundheitsmonitoring von ioBroker vor, inklusive passendem Grafana-Dashboard für InfluxDB v1. (InfluxQL )
                                InfluxDB v2 ist grundsätzlich vorgesehen, aktuell aber noch nicht als separates Dashboard-Paket enthalten.
                                Habe das Grafana json (flux) im Beitrag unten ergänzt, jedoch ungetestet

                                Das Script nutzt Standard-States wie system.adapter.* und system.host.* und benötigt keinen zusätzlichen eigenen Adapter.
                                Für Log-Tracking und die Erkennung degradierter Adapter wird onLog des JavaScript-Adapters benötigt.

                                Enthalten sind unter anderem:

                                • CPU-/RAM-Monitoring aller laufenden Adapter
                                • Restart-Tracking für Flaky-Adapter und Cron-Restarts
                                • Memory-Leak- und Deadlock-Erkennung
                                • Log-Error-/Warn-Tracking und Degraded-Adapter-Bewertung
                                • Host-, Disk- und Health-Score-Monitoring
                                • Optionale Telegram-Alarme und REST-Auswertung
                                • Übersicht über deaktivierte Adapter

                                Getestet auf Raspberry Pi, VM, LXC, Docker und Unraid; produktiv läuft es aktuell auf Docker/Unraid.
                                Ziel ist die Früherkennung schleichender Probleme in produktiven ioBroker-Systemen.

                                Wichtig:
                                Nach dem Import des Dashboards bitte zuerst DSINFLUXDB, DSINFINITY und iobrokerurl prüfen bzw. auswählen.
                                Erst danach liefern alle Panels und REST-basierten Tabellen zuverlässig Daten.

                                Im Beitrag:

                                1. Script
                                2. Grafana-Dashboard InfluxDB v1 ( InfluxQL )
                                3. Grafana-Dashboard InfluxDB v2 (flux)
                                4. Die für InfluxDB benötigten Datenpunkte; weitere Tabellen und Zusatzdaten kommen per Infinity direkt über die REST-API
                                  92378b3e-1ebf-4697-9f4d-79b7d4a03095-image.png
                                5. Variablen anlegen siehe https://forum.iobroker.net/post/1330170
                                6. Für dein Dashboard und die Ressourcen ist entscheidend, wie du die Datenpunkt‑spezifischen Influx‑Einstellungen je Typ setzt – nicht global alles gleich.

                                Grundprinzip je Datenpunkttyp

                                • Langsam ändernde Zustände (Booleans, Modus, Error‑Flags, Health‑Scores, Event‑Pulse):
                                • Nur Änderungen aufzeichnen: an
                                • Entprellzeit: 300–1000 ms
                                • Blockzeit: 0
                                • „Trotzdem gleiche Werte aufzeichnen“: 600–3600 s (je nach gewünschter History‑Auflösung)
                                • Minimale Differenz: 0 (bei Booleans/Zahlen mit kleinem Bereich)
                                • Ergebnis: sehr wenige Punkte, aber alle Zustandswechsel sauber im Grafana‑Dashboard.

                                Kontinuierliche Messwerte mit Trend (CPU‑Last, RAM‑MB, Host‑Disk‑FreeMB, Health‑Score):

                                • Nur Änderungen aufzeichnen: an
                                • Entprellzeit: 500 ms wie im Screenshot ist ok
                                • „Trotzdem gleiche Werte“: auf deinen Script‑Zyklus bzw. Host‑Intervalle ausrichten, z. B. 180–300 s, damit Influx wenigstens alle paar Minuten einen Punkt bekommt, selbst wenn sich nichts ändert.
                                • Minimale Differenz: z. B. 1 % bei CPU‑Werten, 5–10 MB bei RAM, 1 Punkt beim Health‑Score.
                                • Ignoriere 0/Nullwerte: an, falls der DP beim Start kurz 0/NULL ist und das im Dashboard nicht stören soll.

                                Pulse‑Werte für Events (RestartEventPulse, FlakyEventPulse, Deadlock‑Alarm‑Pulse etc.):

                                • Nur Änderungen: an
                                • Trotzdem gleiche Werte: 0 s (nicht nötig, der Pulse ist ein kurzer Wechsel 0→1→0)
                                • Entprellzeit: klein (100–200 ms), damit jeder Pulse als eigener Punkt landet.
                                • 0/Null ignorieren: aus, sonst siehst du nur die 1, aber keinen „Rückfall“ im Graphen.
                                Bereich Datenpunkte
                                Grundprinzip / langsam ändernde Zustände SystemHealthScore, DisabledAdaptersCount, ConnectionIssuesCount, DeadlockAdapters, DisconnectedCount, FlakyAdaptersCount, CronRestartCount, MemoryLeakCount, LogErrorCount, LogErrors1hTotal, LogWarns1hTotal, CriticalAdaptersCount, WarningAdaptersCount, CPUAlarmCounter, RAMAlarmCounter, RestartCount24h
                                Kontinuierliche Messwerte ioBrokerCPUGesamt, ioBrokerRAMGesamt, HostCPULoad, HostCPUOther, HostRAMFreeMB, HostRAMAvailMB, HostRAMUsedMB, HostRAMTotalMB, HostRAMUsedPercent, HostLoadAvg, HostUptimeDays, HostEventLoopLag, DiskFreeMB, DiskUsedPct
                                Puls-Werte RestartEventPulse, FlakyEventPulse

                                Feedback, Tests in anderen Umgebungen und Verbesserungsvorschläge willkommen! 🚀

                                🔥 NEU: Prozess-Monitor

                                // CHANGELOG v4.6.7 (04.05.2026)
                                // ============================================================
                                // ✅ E-Mail-Benachrichtigung (email-Adapter): parallel zu Telegram/Pushover,
                                // gleicher Cooldown, gleiche Alarmtyp-Schalter (EMAIL*ALERT)

                                Changelog_old


                                CHANGELOG v4.6.6 (20.04.2026) RAM-Prozent mit Docker-tauglicher Bezugsgröße (Cgroup / manuell).


                                ✅ RAMPERCENTBASIS / RAMPERCENTMANUALMB: gemeinsamer Nenner für alle RAM-%-Werte (ioBroker-Gesamt + Host „frei“) → Prozent im Container bezieht sich auf Cgroup-Limit oder festen Wert, nicht blind auf Host-totalmem
                                ✅ readCgroupMemoryLimitBytes(): liest memory.max (v2) bzw. memory.limit_in_bytes (v1) → passendes Limit unter Linux/Docker, wenn gesetzt
                                ✅ Modi cgroup_or_host / host / cgroup / manual: steuerbar, wann Cgroup, Hardware oder manuelle MB greifen → klare Experten- vs. Standard-Logik
                                ✅ formatRAMAlertMessage(): wenn Prozent aktiv, aber keine Bezugsgröße ermittelbar → Text nennt MB-Fallback und Hinweis zu RAMPERCENT* → Telegram passt zur echten Alarmlogik

                                CHANGELOG v4.6.5 (20.04.2026) RAM-Schwellen wahlweise in Prozent oder MB (Einsteiger / Experte).


                                ✅ IOBROKERRAMTHRESHOLDMODE percent | mb: ioBroker-Gesamt-RAM → entweder RAMWARNINGPCT / RAMCRITICALPCT oder RAMWARNING / RAMCRITICAL (MB)
                                ✅ HOSTRAMTHRESHOLDMODE percent | mb: freier Host-RAM → entweder HOSTRAMFREEPCT oder HOSTRAMFREEMB → beide Bereiche unabhängig umschaltbar
                                ✅ resolveIoBrokerRamAlarmLevels() + Dashboard-Kachel: Farbe/Limit-Text folgen dem Modus → konsistent zu checkAlarm und HTML-DashboardHTML
                                ✅ Host-RAM-Alarm & Host-Kachel: Prozent nutzt dieselbe Bezugsgröße wie ioBroker-% (ab v4.6.6 inkl. Cgroup/Manual) → einheitliche Semantik
                                Hinweis: Script neu starten. Grafana ändert sich nicht von selbst (keine Dashboard-Datei im Skript); nur Schwellzeitpunkte können sich bei Umstellung auf Prozent verschieben — fest eingetragene MB-Linien in Panels ggf. anpassen. Wer nur klassisch MB will: IOBROKERRAMTHRESHOLDMODE: 'mb' und HOSTRAMTHRESHOLDMODE: 'mb' setzen.

                                CHANGELOG v4.6.4 (17.04.2026) HTML-Dashboard für VIS / Jarvis / iQontrol (ohne Grafana).


                                ✅ Optionales Dashboard: DASHBOARDHTMLENABLED (Standard: true) → State …Prozesse.DashboardHTML mit role: 'html'
                                ✅ Eigener Rhythmus: DASHBOARDHTMLINTERVAL in Minuten (Standard: 10, 0 = kein Schedule) → weniger Last als beim Haupt-Monitoring
                                ✅ Kein History-Müll: Beim Anlegen des States sind InfluxDB / history / sql für genau diesen State per custom deaktiviert → nur dieser eine State, Rest unverändert
                                ✅ Dirty-Check: HTML wird nur geschrieben, wenn sich der Inhalt geändert hat → weniger DB-Schreibvorgänge
                                ✅ Sparklines: RAM-Verlauf aus memoryHistoryCache mit Downsampling (max. 20 Punkte) → kompakt für Raspberry & Co.
                                Hinweis: In VIS z. B. Widget „String (unescaped)“ auf DashboardHTML legen. Bei abweichenden Adapter-Instanzen (influxdb.2 etc.) custom im Script anpassen.

                                CHANGELOG v4.6.3 (17.04.2026) Performance, Bugfixes, Stabilität.


                                ✅ formatCPUAlertMessage() ergänzt → war nicht definiert, sonst ReferenceError beim CPU-Kritisch-Alarm
                                ✅ Stats-Zyklus-Cache: getProcessStats() pro Adapter nur noch einmal pro Zyklus statt mehrfach → deutlich weniger getState()-Aufrufe
                                ✅ $()-Selector: aliveSelector einmal pro updateMonitoring() und an getDisabledAdapters() übergeben
                                ✅ Log-History: Obergrenze pro Adapter und Severity (errors / warns) → Schutz vor RAM-Wachstum bei Dauerfehlern
                                ✅ Memory-History: harte Obergrenze der gespeicherten Punkte pro Adapter
                                ✅ Schedule-Fix: cleanupAllLogErrors von */60 * * * auf 5 Felder */60 * * * * → Cleanup lief vorher nicht
                                ✅ purgeOrphanAdapterPersistentData() nur noch stündlich statt bei jedem Monitoring-Zyklus
                                ✅ Pulse-States: setStateDelayed(…, clearRunning=true) statt setTimeout für Restart-/Flaky-Pulse → weniger Überschneidungen
                                Hinweis: Script neu starten. Bei bereits existierendem DashboardHTML ohne custom ggf. History in der Admin-UI prüfen (siehe v4.6.4).

                                CHANGELOG v4.6.2 (14.04.2026) Pushover als zweiter Benachrichtigungskanal neben Telegram.


                                ✅ Pushover-Unterstützung: Neuer Konfig-Block mit PUSHOVERENABLE, PUSHOVERINSTANCE, PUSHOVERDEVICE, PUSHOVERTITLE und PUSHOVERPRIORITY (-2 bis 1) → komplett optional, per Default deaktiviert
                                ✅ Granulare Schalter: Jeder Alarmtyp hat einen eigenen Pushover-Schalter (PUSHOVERALERT) → analog zu den bestehenden TELEGRAMALERT-Flags
                                ✅ Gemeinsamer Cooldown: sendAlert() löst Telegram und Pushover gleichzeitig aus → ein Timer pro Alarmtyp verhindert Alarmflut auf beiden Kanälen
                                ✅ Keine Änderung für bestehende Nutzer: Telegram-Konfiguration bleibt unverändert

                                Hinweis: PUSHOVERENABLE: true setzen, PUSHOVERINSTANCE anpassen, Script neu starten. ioBroker Pushover-Adapter muss installiert und konfiguriert sein.

                                CHANGELOG v4.6.1 (13.04.2026) Minütliche Controller-Warnungen nach Adapter-Deinstallation behoben.


                                ✅ existsObject() vor getObject(): Fehlende system.adapter.*-Objekte werden übersprungen → keine minütlichen „Object … does not exist“-Warnungen mehr
                                ✅ History-Bereinigung: Uptime-, Log- und Memory-Einträge deinstallierter Instanzen werden beim Monitoring-Lauf automatisch entfernt

                                Hinweis: Aktueller ioBroker.javascript-Adapter mit existsObject() empfohlen. Script neu starten.

                                CHANGELOG v4.6.0 (20.03.2026) Konfigurationsbereich vollständig neu strukturiert.


                                ✅ Neue Konfig-Struktur: Benutzerwerte, Schwellwerte und Expertenwerte klar getrennt
                                ✅ Benutzer-Checkliste ergänzt: Schneller erkennbar, welche Werte angepasst werden sollen
                                ✅ Einheitliche Kommentare und Abschnittsüberschriften → forumtauglicher, übersichtlicher, leichter wartbar
                                ✅ Kein funktionaler Eingriff: Bestehende States, Prüfungen und Features bleiben vollständig erhalten
                                ✅ Neu: Deaktivierte Adapter: DisabledAdaptersCount und DisabledAdapters werden erfasst und als State geschrieben

                                Script
                                iobroker-prozessmonitor_v4.6.7

                                Das Dashboard (InfluxQL )
                                dashboard-4.6.0-Final

                                NEU 30.03.2026
                                Das Dashboard (Flux)
                                dashboard-4.6.0_flux

                                6f1fa838-d2ed-4bcc-979c-106f6c6d64b3-image.png
                                a993a827-5211-429f-8da5-439af66494c5-image.png
                                21551d26-8e42-4686-be68-3fd5b1bdba9d-image.png
                                b146f87b-c57e-4ca7-b972-5c8df09c06c3-image.jpeg

                                Offene Tuning-Punkte

                                • Flaky: aktuell 3 Restarts in 24h — sinnvoller Grenzwert, wenn geplante Cron-Restarts toleriert werden?
                                • Errors: aktuell 3/h Warnung und 20/h kritisch — passen diese Werte in anderen Umgebungen?
                                • Worst/Best Performer: Gewichtung des Health Scores noch offen für Feintuning.
                                • Degraded Adapter: aktuell kritische Error-Rate ab 10/h plus CPU > 12 und/oder Event Loop Lag > 100 ms — praxistauglich?
                                • Event Loop Lag: aktuell 500 ms kritisch als allgemeiner Schwellwert — vermutlich hardwareabhängig?
                                • Memory Leak: aktuell ab (R^2 > 0.65) und Wachstum > 15 MB/h — Erfahrungswerte willkommen.
                                • Deadlock: aktuell alive=true und connected=false — eventuell noch erweiterbar.
                                crunchipC Abwesend
                                crunchipC Abwesend
                                crunchip
                                Forum Testing Most Active Developer
                                schrieb am zuletzt editiert von crunchip
                                #73

                                crunchip sagte:

                                Grundprinzip je Datenpunkttyp

                                Langsam ändernde Zustände (Booleans, Modus, Error‑Flags, Health‑Scores, Event‑Pulse):
                                Nur Änderungen aufzeichnen: an
                                Entprellzeit: 300–1000 ms
                                Blockzeit: 0
                                „Trotzdem gleiche Werte aufzeichnen“: 600–3600 s (je nach gewünschter History‑Auflösung)
                                Minimale Differenz: 0 (bei Booleans/Zahlen mit kleinem Bereich)
                                Ergebnis: sehr wenige Punkte, aber alle Zustandswechsel sauber im Grafana‑Dashboard.
                                Kontinuierliche Messwerte mit Trend (CPU‑Last, RAM‑MB, Host‑Disk‑FreeMB, Health‑Score):

                                Nur Änderungen aufzeichnen: an
                                Entprellzeit: 500 ms wie im Screenshot ist ok
                                „Trotzdem gleiche Werte“: auf deinen Script‑Zyklus bzw. Host‑Intervalle ausrichten, z. B. 180–300 s, damit Influx wenigstens alle paar Minuten einen Punkt bekommt, selbst wenn sich nichts ändert.
                                Minimale Differenz: z. B. 1 % bei CPU‑Werten, 5–10 MB bei RAM, 1 Punkt beim Health‑Score.
                                Ignoriere 0/Nullwerte: an, falls der DP beim Start kurz 0/NULL ist und das im Dashboard nicht stören soll.
                                Pulse‑Werte für Events (RestartEventPulse, FlakyEventPulse, Deadlock‑Alarm‑Pulse etc.):

                                Nur Änderungen: an
                                Trotzdem gleiche Werte: 0 s (nicht nötig, der Pulse ist ein kurzer Wechsel 0→1→0)
                                Entprellzeit: klein (100–200 ms), damit jeder Pulse als eigener Punkt landet.
                                0/Null ignorieren: aus, sonst siehst du nur die 1, aber keinen „Rückfall“ im Graphen.

                                @rallef hast du aber schon beachtet? und auch Punkt4 im ersten Beitrag?

                                umgestiegen von Proxmox auf Unraid

                                1 Antwort Letzte Antwort
                                0
                                • R Offline
                                  R Offline
                                  rallef
                                  schrieb am zuletzt editiert von
                                  #74

                                  muss ich nachschauen

                                  dp.jpg

                                  1 Antwort Letzte Antwort
                                  0
                                  • R Offline
                                    R Offline
                                    rallef
                                    schrieb am zuletzt editiert von
                                    #75

                                    muss ich das für alle datenpunkte unter prozesse ändern ?

                                    1 Antwort Letzte Antwort
                                    0
                                    • R Offline
                                      R Offline
                                      rallef
                                      schrieb am zuletzt editiert von
                                      #76

                                      ok aber was ist was
                                      Langsam ändernde Zustände (Booleans, Modus, Error‑Flags, Health‑Scores, Event‑Pulse): welche dp's sind das?

                                      crunchipC 1 Antwort Letzte Antwort
                                      0
                                      • R Offline
                                        R Offline
                                        rallef
                                        schrieb am zuletzt editiert von
                                        #77

                                        super vielen dank das habe ich noch nie berücksichtigt bei den anderen Datenpunkten meiner anderen Anwendungen. Vielleicht habe ich das problem schon vorher gehabt. aber das die Influxdb Instanz mehrmals täglich sich restartet ist neu. Werde alle Datenpunkte unter Prozesse heute abend mir anschauen und ggfls ändern. Hoffe das reicht dann damit Influxdb nicht mehr sich restartet

                                        1 Antwort Letzte Antwort
                                        0
                                        • R rallef

                                          ok aber was ist was
                                          Langsam ändernde Zustände (Booleans, Modus, Error‑Flags, Health‑Scores, Event‑Pulse): welche dp's sind das?

                                          crunchipC Abwesend
                                          crunchipC Abwesend
                                          crunchip
                                          Forum Testing Most Active Developer
                                          schrieb zuletzt editiert von
                                          #78

                                          @rallef sagte:

                                          ok aber was ist was

                                          ich habs oben im ersten Beitrag ergänzt

                                          umgestiegen von Proxmox auf Unraid

                                          1 Antwort Letzte Antwort
                                          0

                                          Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.

                                          Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.

                                          Mit deinem Input könnte dieser Beitrag noch besser werden 💗

                                          Registrieren Anmelden
                                          Antworten
                                          • In einem neuen Thema antworten
                                          Anmelden zum Antworten
                                          • Älteste zuerst
                                          • Neuste zuerst
                                          • Meiste Stimmen


                                          Support us

                                          ioBroker
                                          Community Adapters
                                          Donate

                                          606

                                          Online

                                          32.8k

                                          Benutzer

                                          82.9k

                                          Themen

                                          1.3m

                                          Beiträge
                                          Community
                                          Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen | Einwilligungseinstellungen
                                          ioBroker Community 2014-2025
                                          logo
                                          • Anmelden

                                          • Du hast noch kein Konto? Registrieren

                                          • Anmelden oder registrieren, um zu suchen
                                          • Erster Beitrag
                                            Letzter Beitrag
                                          0
                                          • Home
                                          • Aktuell
                                          • Tags
                                          • Ungelesen 0
                                          • Kategorien
                                          • Unreplied
                                          • Beliebt
                                          • GitHub
                                          • Docu
                                          • Hilfe