zu dürftige Logging-Informationen beim Kunden, was tun?
Was macht ihr eigentlich wenn die Logging-Informationen, die ihr ausgebt, zu dürftig sind, um auf die Schnelle beim Kunden Fehler korrekt zu diagnostizieren?
Greift ihr über Remot-Desktop oder Remote-Debugging zu?
Habt ihr eigene Monitoring-Tools? oder Log-Auswerter?
Meine Idee wäre jetzt, dass es teilweise angebracht sein könnte, über einen Enhancer "mehr" Logging-Code in die exe reinzuschießen. Zumindest um erste genauere Diagnosen zu erhalten.
Oder habt ihr einen Dialog in der Exe der bei Fehlern E-Mails an die Kunden verschicken kann, so á la Quality-Feedback-Agent wie z.B. bei Mozilla?
Benutzt ihr kommerzielle Debugging-Tools?
Ich möchte einfach mal wissen, was es da noch so gibt und wie ihr an die Probleme rangeht.
Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.
hi,
passt jetzt wahrscheinlich nicht direkt zu deinem problem, da du die exe nicht neu kompilieren willst. jedenfalls hab ich neulich einen sehr interessanten artikel in der aktuellen dotnetPro gelesen, in der ein automatisches logging per AOP (spring.Net) erstellt wurde. durch den aspektorientierten ansatz müssen quasi keine änderungen am vorhandenen code gemacht werden, es wird nur ein neuer "aspekt" eingefügt.
gruß
@feadur: doch, passt. Mit Enhancer und reinschießen meine ich eben genau das, quasi den Code zu injizieren über ein Post-Compile.
Ausserdem gibt's noch die Möglichkeit, zumindest um bestimmte LoggingStates an und auszuswitchen:
Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.
Hallo dr4g0n76,
naja, was man machen kann und was sich verbietet, hängt ein bisschen von der Situation ab. Wenn du einen Enhancer benutzt, dann änderst du ja das Programm mit unvorhersehbaren Auswirkungen vor allem in den Bereichen Performance und RaceConditions. Das muss man sicher vorher testen. Dann ist es aber nicht anderes, als wenn man manuell eine neue Version mit verbessertem Logging erstellt.
Wenn du in Produktion debuggen willst, dann gelten ähnliche Überlegungen wie bei den Enhancern, weil auch Debugger das Ablaufverhalten und teilweise auch die Semantik von Programmen verändern.
Natürlich können E-Mail-Benachrichtigungen nützlich sein, aber bei deiner Frage geht es ja um die Menge der vorhandenen Information und nicht darum, wie du an die Information kommst.
Bei einem Fehler (komplettes Aufhängen der Anwendung), den wir über Wochen nicht finden und vor allem nicht reproduzieren konnten, hat ein persönlicher Besuch in der Fachabteilung uns innerhalb von Minuten die Reproduzierbarkeit gebracht. Der Sachbearbeiter klickte (zu 486er-Zeiten) manchmal in das Fenster, während es sich noch aufbaute. Wir hatten bei unseren Tests immer brav gewartet, bis das Fenster vollständig aufgebaut war.
herbivore
Grundsätzlich zur Laufzeit konfigurierbares Logging mit zumindest den Stufen Unerwartete Fehler, Warnung, Info. Wobei er dann in der Stufe Info natürlich echte ASCII-Wüsten produzieren sollte.
Dazu kommen automatische Benachrichtigungen per Mail incl. aller relevanter Informationen wie z.B. Stacktraces.
Und, wie schon herbivore schrieb, ganz wichtig die Auge-Optik-Methodik im direkten Kontakt mit Kunden. Viele "unerklärliche Fehler" lassen sich so mit minimalem Aufwand beheben. Mir fällt da spontan als Beispiel der Win-Service ein, der übers LAN auf ein Verzeichnis zugreifen musste. Der Admin hatte dazu ein Share eingerichtet und den Service entsprechend konfiguriert. Leiderdessen hatte der Admin nicht berücksichtigt, das der Service unter dem Network-Service-Konto lief und es ein klitzkleines Berechtigungsproblem gab ...
Mit Logging per AOP wäre ich persönlich auch vorsichtig, warum sollte ausgerechnet der entsprechende Weaver die weltweit einzige fehlerfreie Software sein ? Dazu kommen die schon angesprochenen Seiteneffekte, die per Test ausgeschlossen werden müssten.
Das alles hilft Dir jetzt vermutlich auch nicht viel weiter, aber mir war halt gerade nach Meinungsäußerung zumute 😉.
2 + 2 = 5 for large values of 2
Original von dr4g0n76
Oder habt ihr einen Dialog in der Exe der bei Fehlern E-Mails an die Kunden verschicken kann, so á la Quality-Feedback-Agent wie z.B. bei Mozilla?
Ja, ich verwende Log4Net gerne mit E-Mail Benachrichigung. Aber das adressiert ja ein anderes Thema: Kunden sind meist ziemlich beeindruckt, wenn man ihnen sagt, dass die Anwendung einen Fehler gemeldet hätte und sie haben ihn u.U. noch nichtmal bemerkt. Kunden stehen drauf, wenn man selbst aktiv wird. Gibt ihnen das Gefühl umsorgt zu werden. Anders als bei Feedback-Programmen mache ich das ohne Dialog, ist aber natürlich mit dem Kunden vereinbart.
Dann sorge ich dafür, dass es immer zwei Logs gibt. Eines für den Kunden und ein geschwätziges für mich. Erfahrungsgemäß guckt aber kein Schwein in ein Kunden-Log....
Wenn du einen Enhancer benutzt, dann änderst du ja das Programm mit unvorhersehbaren Auswirkungen vor allem in den Bereichen Performance und RaceConditions. Das muss man sicher vorher testen.
Klar, das es das Verhalten verändert ist sicherlich unbestreitbar.
Dann ist es aber nicht anderes, als wenn man manuell eine neue Version mit verbessertem Logging erstellt.
Sehe ich nicht ganz so, vom Zeitaufwand her ist es sicher besser eine automatisierte Version zu haben, vom Effekt her kann es sicherlich dasselbe sein, als diese Sachen von Hand einzufügen.
Wenn du in Produktion debuggen willst, dann gelten ähnliche Überlegungen wie bei den Enhancern, weil auch Debugger das Ablaufverhalten und teilweise auch die Semantik von Programmen verändern.
Ist quasi fast die gleiche Aussage wie oben (Performance und RaceConditions).
Und sicherlich auch richtig, da stimm ich mit Dir überein.
Bei einem Fehler (komplettes Aufhängen der Anwendung), den wir über Wochen nicht finden und vor allem nicht reproduzieren konnten, hat ein persönlicher Besuch in der Fachabteilung uns innerhalb von Minuten die Reproduzierbarkeit gebracht.
Auch das versuchen wir natürlich auch, und auch bei uns stellen wir sehr oft fest, dass ein kurzes Kundengespräch z.B. andere Bedienungsabläufe zu Tage fördert, mit denen wir einfach nicht gerechnet haben oder die einen Bug in der Software auslösen und aufdecken.
Nur gibt es eben auch Situationen, die IMHO die von mir angegebene Vorgehensweise nötig machen, da weder reger Kundenkontakt noch Remote-Verbindung in diesem Falle möglich sind und der Fehler vielleicht vor Ort nicht nachvollzogen werden kann.
Deshalb denke ich ist es zumindest einen Versuch wert.
Und in diese Richtung habe ich auch schon - bisher erfolgreich - getestet.
Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.