Mangelhafter Umgang mit error_logs ist aber nicht die Schuld des error_logs, sondern der Administratoren und/oder der Entwickler.

Logs müssen gelesen und ausgewertet werden. Punkt.

Und Fehler und Warnungen müssen nachvollziehbar bleiben. Auch Fehler/Warnungen der Vergangenheit.

Passende Stichworte wären Logrotation, Kompression, Logauswertung und Monitoring. Es gibt da kostenlose und auch -pflichtige Produkte. Man muss sie nur einsetzen.

Ich vermute aber, dass die Mitarbeiter dafür keine Zeit und Mittel zur Verfügung haben. Dann darf man sich aber auch nicht wundern, wenn das nicht sauber läuft. Oder die Werkzeuge des Unternehmens können diese Aufgabe nicht erfüllen, weil die Entscheidung für diese Werkzeuge beim Golfen oder so getroffen wurde :-(

Fehler und Warnungen haben in einer produktiven Anwendung NICHTS im Browser-Fenster verloren. Da darf ein "Allgemein-Plätzchen 'Ein Fehler ist aufgetreten....'" erscheinen, aber keinerlei Details. Die sind dem error_log zu entnehmen.

Bei der Entwicklung kann man mit use CGI::Carp qw( fatalsToBrowser  warningsToBrowser ); Fehler und/oder Warnungen zum Browser umleiten. Das Modul bietet auch noch reichlich Möglichkeiten, das Verhalten anzupasssen oder Ausnahmen zu definieren; siehe CGI::Carp
Beim produktiven Einsatz muss das abgeschaltet sein und die Meldungen gehören nur ins Error_Log.

edit: admins/entwickler in der Einleitung angepasst
Last edited: 2016-02-04 18:06:14 +0100 (CET)