ich möchte hier, auch wenn ein wenig off-topic, aus aktuellem Anlass noch mal Bezug nehmen auf mein vorletztes Posting (Do 27 Sep, 2007 17:57) und das nachfolgende von Stefan (Fr 28 Sep, 2007 10:48 ). Wir hatten uns seinerzeit zusammengetan und haben versucht die Probleme mit PRTG in eine lesbare Form zu bringen und sie dem Support von Paessler zukommen zu lassen in der Hoffnung, dass sich was ändert:
Daraufhin kam folgende Antwort:Stefan/Jirka hat geschrieben:----------------------------------------------------------------
SUPPORT TICKET #2007-283-30341:
----------------------------------------------------------------
Product: PRTG
Version: 6.1.1.855
Windows: Windows XP 32bit
----------------------------------------------------------------
Topic: Fehler/Bugs im PRTG
----------------------------------------------------------------
Description:
Sehr geehrte Damen und Herren,
nachfolgend einige Fehler/Bugs, die mir in PRTG aufgefallen sind. Installiert ist PRTG Traffic Grapher V6.1.1.855 in deutsch. Geräte die damit ausgewertet werden sind von LANCOM, hier geht es um Standard-Traffic-Sensoren.
1) Das Problem tritt bei mir bei Firmwareupdates an LANCOM-Routern auf, dann nämlich führt das in PRTG mitunter zu einer Anzeige von 800.000 kbit/Sekunde. In der Folge ist dann der bisherige Verlauf der Zeitreihe "gestaucht" und selbst Peaks sind nicht mehr auszumachen. Leider gibt es scheinbar keine Möglichkeit, die von PRTG ausgelesenen Werte direkt einzusehen oder gar noch zu editieren. Um zu untersuchen, ob das ganze am LANCOM oder dem PRTG liegt, habe ich mit Wireshark/Ethereal mal mitgeschnitten und gestern passierte auch genau das beim Firmwareupdate. Da nach einem Firmware-Update der LANCOM neu bootet liefern die Variablen ifInOctets und ifOutOctets sehr kleine Werte, da seit dem Bootvorgang ja bisher kaum Traffic angefallen ist. Damit PRTG jetzt nicht denkt, dass der 32-Bit-Zähler übergelaufen ist, d. h. der Wert von 4294967295 Bytes überschritten wurde und dann wieder von vorne angefangen wird zu zählen, erfolgt noch eine Abfrage der Betriebszeit, indem die Variable sysUpTime abgefragt wird. Aus der Betriebszeit lässt sich dann schließen, ob es einen Zählerüberlauf oder ein Nullsetzen der Variablen gegeben hat. Diese Abfrage der sysUpTime erfolgt vor jedem Abfragen eines Wertes, also sowohl bei ifInOctets als auch bei ifOutOctets. Nur leider scheint PRTG diese Werte nicht so auszuwerten wie es angebracht wäre... Es war zu erkennen, dass die Abfrage nach der sysUpTime erfolgte, zu der Zeit bootete der LANCOM jedoch gerade. Von daher blieb die Antwort aus. Danach (5 Sek. später, Betriebszeit LANCOM 3,8 Sekunden) erfolgte die Abfrage nach ifInOctets, die mit dem Wert 40 beantwortet wurde. Da dem PRTG nun die Antwort auf sysUpTime fehlte geht er fälschlicherweise davon aus, dass kein Bootvorgang stattfand und folglich ein Zählerüberlauf angenommen wird, so dass sich der verbrauchte Traffic zu 4294967295 - letzte Abfrage + aktuelle Abfrage ergibt. Das kann natürlich utopische Werte ergeben. Meiner Ansicht nach liegt hier ein klarer Fehler in PRTG vor. Wenn die sysUpTime-Anfrage unbeantwortet bleibt muss entweder die nachfolgende (in dem Fall ifInOctets-)Anfrage verworfen werden, oder aber die sysUpTime-Anfrage muss wiederholt werden (z. B. nach 5 Sekunden). Alternativ könnte man ja auch die unmittelbar nachfolgende sysUpTime-Anfrage auswerten (die vor der ifOutOctets-Anfrage kommt). Auf alle Fälle darf PRTG nicht aus einer unbeantworteten sysUpTime-Anfrage schließen, dass es einen Zählerüberlauf gab. PRTG hätte wissen müssen, dass sysUpTime-Anfragen bei diesem Sensor immer beantwortet wurden und dass er ohne die Angabe der sysUpTime den ifInOctets-Wert nicht auswerten dürfte. Um das ganze abzuschließen noch eine theoretische Betrachtung. Ich weiß es nicht genau, aber ein LANCOM bootet in ca. 6 Sek. Daraus schlussfolgernd dürften die Antworten von sysUpTime und ifInOctets nicht mehr als 6 Sek. auseinanderliegen um eine korrekte Auswertung zu ermöglichen. Denn sysUpTime vorm booten und ifInOctets nach dem booten würde auch wieder einen Fehler ergeben. In dem Fall müßte sysUpTime neu angefordert werden. Und noch einen Versuch habe ich gestartet, ich habe unter Optionen -> System -> Tweaks -> Erneute SNMP-Anfrage angehakt, in der Hoffnung, dass eine unbeantwortete sysUpTime-Anfrage dann nachgefordert wird und das Problem nicht auftritt. Leider passiert dies nicht, sondern es wird nur die ifInOctets-Anfrage wiederholt, was die Wahrscheinlichkeit des Auftretens des Fehlers noch erhöht, wie sich heute zeigte, denn wenn beide Anfragen noch in die Bootzeit fallen, wird die letzte ifInOctets-Anfrage wiederholt, was dann zu dem Fehler führt - ansonsten wäre halt eine Lücke, was aber eher weniger stört.
2) Nun gibt es die Möglichkeit bei den Eigenschaften des Sensors übergroße Werte von der Auswertung auszuschließen, auch wenn ich davon nicht so viel halte, weil man dadurch nicht die Ursache sondern die Symtome beseitigt. Bearbeitet man einen Sensor findet sich unter Sensoreinstellungen -> Erweitert -> Werte das Feld "Höchstwerte filtern". Dass die Angabe bei einem Traffic-Sensor hier in Bytes/Sekunde zu erfolgen hat ist schon mal schwer auszumachen, aber egal. Problem Nummer 1, theoretisch müßte man hier für eingehend und ausgehend unterschiedliche Werte angeben können. Problem Nummer 2, die Implementation dieser Funktion ist fehlerhaft, sie funktioniert immer nur für die letzten 24 bis 48 Stunden (weiß nicht genau). Beispiel: Ich hatte einen herausragenden Peak in meiner Monatskurve. Dann klickte ich die Wertefilterung ab, dann waren drei (unnormale) Peaks zu sehen. Daraufhin Wertefilterung wieder angehakt und von den drei Peaks verschwand leider keiner mehr! Man kriegt also nicht die Peaks weg! Es half auch nichts, den Cache zu löschen (den Inhalt des Ordners Cache).
3) Die deutsche Version gibt es noch nicht lange, dementsprechend finden sich hier und da immer wieder Stellen, wo Wörter abgeschnitten sind, weil sie von der Länge her dort so nicht hinpassen. Einfach mal die Dialogfelder durchschauen. Aus diesem Grund eignet sich von den drei zur Auswahl stehenden Webinterface-Designs auch nur eins. Bei der Angabe der letzten Werte in der Grafik heißt es ebenfalls noch "last" statt z. B. "letzter Wert". Ich will hier nicht auf alles detailliert eingehen, da dies nur Formprobleme sind und dies nicht das Hauptanliegen dieser E-Mail ist.
Vielen Dank für Ihre Hilfe.
Mit freundlichen Grüßen,
Stefan Bunzel und Jirka Reimer
Die Antwort hat uns natürlich nicht wirklich zufrieden gestellt. Aber abwarten und Tee trinken.Paessler Support Team hat geschrieben:Hallo Herr Bunzel,
erst mal vielen dank für diese wirklich konstruktive Kritik!
Die von ihnen angesprochenen Bugs sind uns bekannt. Die Sache mit dem Überlauf nach Neustart des Geräts ist nicht ideal gelöst, es gibt aber unter Extras -> Optionen -> System -> Tweaks -> Erweitert die Möglichkeit "Überlauf ignorieren" einzuschalten. Dann werden aber natürlich auch echte Überläufe ignoriert.
Das Problem der Webdarstellung im deutschen ist auch bekannt, hierzu gibt es einen Blog Eintrag.
http://www.paessler.com/blog/2007/01/31 ... interface/
Natürlich sollten wir als deutsche Firma auf die Richtigkeit der Darstellung in der deutschen Version mehr Acht geben, aber da die meisten unserer Kunden die englische Version verwenden haben wir fast all nur die englische Version auf dem eigenen Rechner Laufen.
Ob die Bugs noch in dieser Version von PRTG behoben werden kann ich nicht versprechen. Wir arbeiten derzeit mit Hochdruck an einer neuen Version von PRTG die für Ende Q1 2008 geplant ist. Diese wird grundlegend anders sein als die bisherige Version, und beansprucht deshalb besonders viel Entwicklungsarbeit.
Nochmals vielen dank für ihre Ausführungen und ihre Mühe, das ist sehr viel besser als eine einfache "DAS GEHT NICHT".
mfg
...
Nun ist die Version 6.2.0.907/908 erschienen, Changelog:
Die Version habe ich mir nun vorhin angeschaut. Und es hat sich extrem viel geändert! Dem changelog sieht man das gar nicht an...Paessler hat geschrieben:Some small orthographic corrections
New: "equal" and "different" options for threshold notifications
New: Enhanced SNMP Performance - The SNMP engine was heavily optimized. It can now query more SNMP values in less time and with less network load. Especially for installations with some hundred sensors or more (and for installations with small intervals, e.g. below 10 seconds) this new version will show less CPU load and less network load while showing better performance.
New: Created three new HTML template files (sensordata1.htm, sensordata2.htm, sensordata3.htm). These templates can be edited by the user e.g. to enable external applications to access the status of a sensor or the current value of a sensor using a HTTP request.
Quelle: http://www.de.paessler.com/prtg/history
Das Hauptproblem was wir ansprachen wurde sauber gelöst, genau so, wie wir es wollten! Für die Auswertung nur eines Traffic-Sensors auf einem LANCOM wurden bisher sage und schreibe 8 Pakete mit 720 Byte durch die Gegend geschickt (jeweils Anfrage und Antwortpaket für sysUpTime, ifInOctets, sysUpTime, ifOutOctets). Der zeitliche Abstand zwischen den Paketen ließ die oben genau ausgeführten Probleme entstehen. Nun wird das ganze mit 2 Paketen erledigt (eine Anfrage für die Werte sysUpTime, ifInOctets und ifOutOctets und die Antwort darauf) und dabei nur noch 248 Byte an Traffic verbraucht.
Fazit: Nur noch ca. ein Drittel der Netzwerklast*, Probleme beseitigt! PRTG ist nun wesentlich ausgereifter!
Ich frage mich nur, was die Jungs die Jahre vorher gemacht haben...
Viele Grüße,
Jirka
* oder noch weniger, wenn auf einem Gerät mehrere Sensoren überwacht werden