Troubleshooting PHP Issues

Transkript

1 Troubleshooting PHP Issues Jan Burkl System Engineer

2 Code Qualität und der Einfluss auf Entwicklungszeit und -kosten Quelle: Boehm und Papaccio Studie Fehlerhafter Code verbraucht typischerweise zwischen 40% und 50% der gesamten Projektkosten Jede für Fehlersuche und Fehlerbehebung aufgebrachte Stunde in der Entwicklung reduziert die Maintenance Zeit um 3 bis 10 Stunden Leider werden nicht alle Bugs während der Entwicklungs- oder Q/A-Phase entdeckt

3 Was werden wir heute besprechen? Typen von PHP Problemen Error Logging Probleme reproduzieren Code Tracing Demo

4 Allgemeine PHP Issues E_ERROR (Fatal Errors) E_WARNING (Problematisch, aber keine Fatal Errors) E_NOTICE (nicht kritisch, können auf ein Fehler hinweisen) E_PARSE (nicht zur Laufzeit, durch den Parser generiert) E_STRICT (Vorschläge) E_RECOVERABLE_ERROR (Catchable Fatal Error, seit PHP 5.2) E_DEPRECATED (seit PHP 5.3) E_USER_* (User generierte Events, durch trigger_error())

5 Andere Problemtypen Logische Fehler Z.B. inkorrekte Berechnungen, fehlerhafte SQL Querys, etc. Schlechte Performance Z.B. teure Datenbankzugriffe, Speicherverbrauch, etc. Security Issues Z.B. Code Angreifbarkeit, PHP Settings Diese Probleme äußern sich nicht in PHP Fehlern

6 PHP Errors Best Practices Während Entwicklungs- und Testphase sollten alle Fehler angezeigt werden: error_reporting = E_ALL display_errors = on Im Produktionsumfeld nur die wichtigsten Fehler aktivieren: error_reporting = E_ALL & ~E_NOTICE display_errors = off Zur Laufzeit können error_reporting() und ini_set( display_errors, value) benutzt werden

7 Beispiel Dieses Beispiel erzeugt eine Notice, zwei Warnungen und einen Fatal Error: <?php error_reporting(e_all); ini_set('display_errors', 1); $num = 5 / $div; require 'utility.inc'; Notice: Undefined variable: div in test.php on line 4 Warning: Division by zero in test.php on line 4 Warning: require(utility.inc) [function.require]: failed to open stream: No such file or directory in test.php on line 5 Fatal error: require() [function.require]: Failed opening required 'utility.inc' (include_path='.:...') in test.php on line 5

8 Custom Errors Events Ein aus PHP heraus generiertes Event wird an den Default Output gesendet Die Events können in ein Log File geschrieben werden error_log Direktive in php.ini Der Error Handler kann mit Hilfe der Funktion set_error_handler() angepasst werden Z.B. eine an den Admin bei einem Error schicken Fatal Errors können nicht mit set_error_handler() behandelt werden Zur Erinnerung: Fatal Errors (E_ERROR) stoppen die Ausführung eines PHP Skripts!

9 Zend Studio: Probleme während der Entwicklung und des Testens lokalisieren Parse Errors (E_PARSE) entdecken ohne den Code auszuführen Aufspüren von logischen Fehlern, die Fatal Errors bedingen könnten Lokales oder Remote Debugging (mit Zend Server) Code Profile Performance Probleme finden Code Coverage benutzen

10 No need to die() Zend_Log, Firebug, FirePHP protected function _initlog() { $writer = new Zend_Log_Writer_Firebug(); $logger = new Zend_Log($writer); } Zend_Registry::set('logger', $logger); // Controller action $logger = Zend_Registry::get('logger'); $logger->info('event: '. $eventid); $logger->info($event); $logger->warn("event starts after 3pm"); $logger->err($exception);

11 No need to die() Zend_Log, Firebug, FirePHP protected function _initlog() { $writer = new Zend_Log_Writer_Firebug(); $logger = new Zend_Log($writer); } Zend_Registry::set('logger', $logger); // Controller action $logger = Zend_Registry::get('logger'); $logger->info('event: '. $eventid); $logger->info($event); $logger->warn("event starts after 3pm"); $logger->err($exception);

12 PHP Error Logs für Troubleshooting Error Logs sind hilfreich während der Entwicklung, des Testens und in der Produktion Trotzdem gibt es einige Begrenzungen Keine Hilfe bei Performance Problemen Keine Hilfe bei logischen Fehlern Notwendigkeit der Problemreproduktion schwierig in der Produktion! Bietet nur eine beschränkte Sicht auf die Probleme es fehlt der Kontext

13 Application Level Monitoring in Zend Server Zend Server Monitor überwacht die Applikation nach: PHP Fehlern (einschließlich Warnings, Notices, Uncaught Exceptions, ) Fehlgeschlagene Funktionsaufrufe (user-defined oder intern) Fehlgeschlagene DB Querys Langsame Funktionsaufrufe (user-defined oder intern) Slow Request Execution Hoher Speicherverbrauch Von Zend Server Komponenten entdeckte Fehler

14 Zend Server - Events

15 Ursachenanalyse Wiederkehrende Events werden aggregiert und auf einer Zeitleiste angeordnet Wann wiederholt sich ein Problem? Jeder Event Report beinhaltet Kontext Informationen, die beim Debuggen unterstützen URL, File, Line, Error Message, Repeat Count, etc. Request Information (GET, POST, COOKIE, etc.) Server Information Session Information Backtrace (wenn relevant)

16 Integration in Zend Studio Zend Server integriert Zend Studio und bietet die Möglichkeit, ein Event nochmals durchzuführen In einer Debug Session In einer Profile Session Durch einen Klick in der GUI oder, durch Exportieren der Event Daten, danach Import in die IDE Replay auf alternativem Test Server In vielen Fällen eliminiert es die Zeit zur Reproduktion

17 Zend Framework Monitoring mit Zend Server Alle Monitoring Funktionen von Zend Server arbeiten natürlich auch für Zend Framework Applikationen Zend_Log_Writer_ZendMonitor()

18 Zend Framework Monitoring mit Zend Server All automatic monitoring capabilities of Zend Server also work for Zend Framework projects just like any other PHP application Zend_Log_Writer_ZendMonitor() can save

19 Release von PHP Code in die Produktion PHP Code sollte fehlerfrei (zumindest ohne E_WARNING und E_ERROR), wenn es releast wird Warum treten trotzdem Fehler in der Produktion auf? Unterschiede in der Produktionsumgebung Andere Last in der Produktion Echte User nutzen die Applikation anders als Entwickler und Tester antizipiert haben Infrastrukturkomponenten oder Back-End Systeme schlagen fehl oder ändern sich Murphy's law - "Anything that can go wrong will go wrong.

20 Code Tracing Data Capture Reproduktion ist nicht immer möglich Abhängigkeit von spezifischem SESSION-Status. Abhängigkeit von spezifischem Datenbank-Status. Wiederholung des Requests ist riskant oder unmöglich. Code Tracing ist in der Lage den gesamten Execution Flow zu erfassen. Execution Tree inklusive Funktionsaufrufen und inkludierten Files. Funktions-Argumente und Return-Parameter. Output und HTTP-Header-Generierung. Lokation von Fehlern, Exceptions und Zend Monitor Events. Für jeden Knoten wird Ausführungszeit und Speicherverbrauch gemessen.

21 Code Tracing

22 Code Tracing Code Trace-Daten werden generiert durch manuelle Requests Monitoring-Events Durch API Code Tracing erfasst folgende Informationen: Execution Tree inklusive Funktionsaufrufen und inkludierten Files. Funktions-Argumente und Return-Parameter. Output und HTTP-Header-Generierung. Lokation von Fehlern, Exceptions und Zend Monitor Events. Für jeden Knoten wird Ausführungszeit und Speicherverbrauch gemessen.

23 Zend Server Code Tracing: Verringert die Zeit der Ursachenanalyse Speichert den Live-Anwendungsablauf bei Problemauftritt Aktivierung durch Zend-Server Monitoringregeln oder manuell Funktioniert im Produktions- oder im Testumfeld - eliminiert die Notwendigkeit Probleme zu reproduzieren Problemlösungszeit ohne Code Tracing Ursachen-Analyse Problemreproduktion Debug Lösung Problemlösungszeit mit Code Tracing Ursachen-Analyse Code Trace-Analyse Lösung

24 Demo!

25 Dankeschön!