Die Konsole verzögert. D.h. Sie zeigt Threads länger an, als diese Laufen, damit man übersehen kann was passiert. Ansonsten würde man sehr oft nichts sehen, weil es soschnell geht. Prometheus zeigt es also eigentlich genauer an, kann aber aufgrund des 5s Intervalls mal Peaks verpassen.
Steckt evtl. ein Thread fest bei dir?
paresy
Ah ok, das ist natürlich eine Erklärung. 
Demnach langweilt sich meine Kiste ja völlig. Da müssen also noch viel mehr Skripte her. 
Nein, eigentlich hängt zurzeit nichts bei mir. Meinst du wegen des 1 Threads der permanent angezeigt wird? Das hätte ich jetzt auf das Prometheus-Modul selbst zurückgeführt, welches ja in dem Moment, wo es Daten liefert, läuft und somit als ein Thread zählt oder nicht?
Stimmt. Das ergibt total sinn, dass er sich selbst mitzählt 
paresy
Ich erfasse jetzt bei mir testweise zusätzlich auch die CPU-Last.
Bis jetzt kann ich dadurch keine negativen Auswirkungen erkennen. Auch die Ausführung des Skripts geht sehr schnell.
Ach, wenn man erst mal angefangen hat mit den Metriken rumzuspielen, ist das echt ne feine Sache. 
wie muss ich mir eigentlich vorstellen das Grafana/Prometheus alle Daten punktgenau erfasst.
Was ich damit sagen möchte ist, das im Endeffekt die Daten gepollt werden.
Wie funktioniert das dann Prometheus nichts entgehen kann, weil wenn Scripte teilweise unter 100ms fertig abgearbeitet sind wie kann man durch ein Datenpollen diese Abarbeitung mitbekommen.
Anders vorsichtig gefragt, wird alles in einer Art und weise Eventbasierend erfasst und zum abrufen zur Verfügung gestellt ?
Gruß
Das funktioniert nur teilweise. Einige Daten (z.B. Anzahl der insgesamt ausgeführten Threads seit Dienst-Start) werden in IPS aggregiert und diese aggregierten Werte werden dann auch an Prometheus weitergegeben.
Andere Werte (z.B. momentan ausgeführte Threads, Speicherbelegung etc.) sind Momentaufnahmen und da werden auch nur die Daten zum Zeitpunkt des Pollings durch Prometheus erfasst. Wenn es zwischen zwei Abfragen Unterschiede gibt, sind diese nicht erkennbar.
Und bei den in IPS aggregierten Daten erfolgt nach dem Neustart des Dienstes auch ein Reset.
Das Monitoring ist unterm Strich gut, hat aber gewisse Unschärfen. Insbesondere mit den gleichzeitig ausgeführten Skripten bin ich nicht so ganz glücklich, da der reale Wert deutlich höher sein muss als der im Monitoring angezeigte.
Gruß
Slummi
Hallo,
das habe ich mir glatt gedacht das Prometheus nicht die Eierlegende Wollmilchsau ist um schwerwiegende Probleme ermitteln zu können, außer die Probleme sind weitaus über einer Sekunde präsent.
Wie gesagt wenn es hier um Abarbeitungszeiten geht die unter einer Sekunde liegen ist es absolut nicht dafür zu gebrauchen.
Grafana ist nur ein schönes anderes Darstellungstool für Graphen aufzubauen, mehr nicht.
Gruß
Das ist so leider nicht korrekt. Sicherlich sind die PHP Threads Metriken eine Momentaufnahme, aber fast alle anderen Metriken sind Counter bzw. absolute Werte, die über die Laufzeit sehr gute Aussagen treffen können.
Ich verstehe, dass dein sehr spezielles Problem in den Graphen nicht sichtbar ist, aber diese Aussage pauschalisiert ein komplexes Analysetool und ist einfach falsch.
paresy
Mhh, ich hätte jetzt gesagt, dass bei IPS 6.0 folgende Graphen auf Momentaufnahmen basieren:
Oder liege ich da falsch?
Ich bin auch der Meinung, dass man darüber wirklich gute Aussagen bzgl. des Systems treffen kann. Gefällt mir wirklich gut!
Nur mit den Threads hadere ich noch ein wenig. Da würde ich ja gerne mal wissen, wie viel wirklich maximal parallel läuft, auch wenn das meist nur im Millisekundenbereich liegen wird.
Ich habe jetzt mal über mehrere Tage die Werte der Threads in Use betrachtet und sehe da genau vier verschiedene Werte, wobei der überwiegende Teil den Wert 1 hat, ein paar wenige Werte sind 2 und 3 und der Rest ist 4.
Rein vom Bauchgefühl her bin ich da etwas skeptisch, ob das stimmt. Denn es gibt so viele Skripte, die durch Variablenänderungen getriggert werden, die jederzeit passieren können und nicht vorhersagbar sind. Da hätte ich eigentlich eine etwas andere „Zufallsverteilung“ erwartet. Aber es kann natürlich sein, dass das auf die Ausführungszeit im ms-Bereich zurückzuführen ist und man sich diesbezüglich einfach verschätzt.
Gruß
Slummi
Korrekt. Die Logged „schleppen“ quasi alte Verbindungen noch 15 Minuten lang mit. Dadurch kann man ganz gut erkennen, ob ständig neue Verbindungen dazu kommen oder Verbindungen öfters mal abbrechen.
Korrekt. Wobei dies an der Metrik per se liegt. Da wüsste ich nicht, wie man das besser abbilden könnten. Ein Task-Manager zeigt ja auch nur eine Momentaufnahme. (Für alles was wir dort loggen wollen reicht diese Momentaufnahme auch aus. Diese sind im Normalfall nur für Leaks notwendig und die treten meistens über längere Zeit auf)
Die wird von Linux intern berechnet und zeigt einen Average über 1, 5, 15 Minuten an. Somit sehr aussagekräftig. Unter Windows gibt es sowas leider nicht.
Korrekt → Wobei hier wichtig ist, einen sich aufbauenden Wert zu erkennen. Sollte es Delays geben, werden die über längere Zeit auf jeden Fall auftauchen. Zusätzlich gibt es ja den Slow-Counter, der hochgeht, wenn Nachrichten über dem Limit waren, wodurch auch dadurch Verzögerungen erkannt werden können, wenn die momentane Abfrage „Pech“ hat.
Hier haben wir zur 6.1 viele neue Metriken, welche die Ausführungszeit je Instanz summieren und die Top-Blockierer zeigen. Damit kann man jetzt auf Instanz-Ebene wissen, wer im System ggf. blockiert.
Zur 6.2 wird die Message-Queue außerdem von mehreren Threads verarbeitet, sodass dieses Problem wesentlich weniger relevant wird.
Falsch 
Hier sind es Counter Werte, sodass du definitiv nie etwas verlierst sondern exakte Werte bekommst.
Dort hatte ich schon überlegt, ob man eine Art Delay bis zur Ausführung tracken könnte. (Wei bei der MessageQueue) Diese sollte nur ein paar Millisekunden betragen. Definitiv eine Momentaufnahme, aber trotzdem bei längerem Logging ein guter Indikator.
Wenn deine Auslastung nicht gerade in den Graphen am Limit fährt, bin ich mir recht sicher, dass du genug Luft hast. Sofern es echte Probleme gibt würde die interne ThreadQueue überlaufen (weil zu langsam abgearbeitet wird) und du bekommst fiese Fehlermeldungen im Log.
Generell kannst du in den Metriken nach „gauge“ suchen für Momentaufnahmen und „counter“ sind summierte Daten, die von Grafana auf einen Zeitraum geplottet werden.
paresy
Hi
gut lassen wir das mal so stehen. Aber, ein Daten abpollen bleibt abpollen, wenn nicht hätte ich schon sehr gerne technisch gewusst wie das funktioniert.
Gruß
So, nachdem ich heute sowieso etwas am System war, hab ich das Dashboard mal eingerichtet und bekomme nun schöne bunte Graphen.
Danke schön dafür
Mit der Darstellung der Message Types bin ich auch noch nicht so ganz zufrieden.
Im Modul ist das als Counter implementiert und in Grafana wird es als Rate auf Minutenbasis dargestellt. Einzelne Fehler und Warnungen gehen dabei allerdings in der Darstellung unter - im Gegensatz zum Status- und Message-Widget der Konsole.
Liefert UC_GetKernelStatistics() die Werte immer für die letzten 60 Sekunden seit Aufruf der Funktion?
Vielleicht kann ich das in Grafana noch etwas optimieren.
Gruß
Slummi
Das kann eigentlich nicht sein, wenn ich es mir genauer ansehe. Dafür ist der Wert zu hoch und wird scheinbar auch nicht zurückgesetzt. Mir scheint eher, dass das die Meldungen seit Systemstart sind, so wie sie auch im Status-Widget ausgegeben werden.
Ich hätte in Grafana aber gerne so eine Darstellung, wie im Meldungs-Widget, wo ich erkennen kann, wie viele Nachrichten es von welchem Typ in einem bestimmten Intervall (letzte 15 Sekunden) gab. Kann ich das mit den vorhandenen Prometheus-Daten irgendwie realisieren?
Gruß
Slummi
Wenn ich die vom Modul genutzten Spezialschalter aktiviert habe, „spammen“ die mir zum Teil mein Status-Widget zu (z.B. DataFlowWatch), was ich nicht ganz so toll finde, weil dann andere benutzerdefinierte Nachrichten untergehen.
Kann ich das über einen RegEx-Filter lösen oder stehen die Daten dann dem Prometheus-Modul nicht mehr zur Verfügung?
Gruß
Slummi
Du kannst die Schwellwerte in ms selber einstellen. Dafür gibt es auch Spezialschalter 
paresy
Ich muss mich erst mal mit den neuen Spezialschaltern der 6.1 vertraut machen. Dokumentiert ist da scheinbar noch nichts. Mir ist noch nicht so 100% klar, was ich da sehe, wie ich es interpretiere und vor allem was sinnvolle Schwellwerte sind.
Ich denke, dass beim DataFlowWatch immer die Dauer des Datenflusses zwischen einer Instanz und ihrer Elterninstanz angezeigt wird, oder? Bei Instanzen ohne Parent wird dann vermutlich auch nichts gemessen. Der Default liegt wohl bei 250 ms. Der scheint bei mir aber zu niedrig zu sein, weil ich sehr viele Meldungen >250 ms kriege. Keine Ahnung, was da normal ist. Irgendwas werdet ihr euch sicher bei den 250 ms gedacht haben. 
Oder ist mein System dann zu lahm?!
Slummi
Ja - Die sind recht spät dazu gekommen. Das holen wir zeitnah nach.
Je nachdem. Wenn du z.B. einen WWW Reader hast, und von extern Daten abfragst, kann es gut sein, dass 250ms voll ok sind. Interne Abfrage oder zwischen den Instanzen sind 250ms nicht ganz so dolle. Da du Grafana nutzt, sind die Schwellwerte fürs Log für dich eigentlich fast egal. Vielleicht sollte ich ne Option einbauen, dass man die Spezialschalter MessageQueueWatchLimit/DataFlowWatchTxLimit/DataFlowWatchRxLimit auf 0 setzen kann und somit gar keine Meldungen ins Log kommen, da du dies ja wesentlich hochwertiger über Grafana auswerten kannst.
paresy
Ja, ich glaube das wäre ganz gut. Dann kann man Grafana nutzen, ohne dass man vor lauter Statusmeldungen nichts mehr sieht. Und den Schwellwert solange „tunen“, bis keine Meldungen mehr kommen, macht ja auch keinen Sinn. Dann kann man den Switch auch gleich aus lassen.
@paresy kannst du mir hier helfen?
Prometheus zeigt diesen Fehler an:
strconv.ParseFloat: parsing "Objekt": invalid syntax
Grüße,
Kai