Passer au contenu 
Je te montre la configuration prête à la production pour Hébergement PHP Error Handling: des defaults php.ini aux stratégies de logging en passant par les gestionnaires personnalisés pour des réponses propres. C'est ainsi que je considère erreurs de production Le système d'exploitation de l'entreprise a été conçu de manière à ce qu'il soit possible d'accéder à l'interface utilisateur, de sécuriser les informations sensibles et d'augmenter la stabilité de la sécurité lors de l'exploitation en direct.
Points centraux
- php.ini se déconnectent : DEV montre tout, PROD enregistre discrètement.
- Niveau d'erreur filtrer finement : Se concentrer sur les véritables erreurs de production.
- Gestionnaire personnalisé utiliser les ressources : Intercepter les erreurs, réagir proprement.
- Enregistrement structurer les informations : Contexte, Rotation, Alertes.
- Environnements séparer clairement les deux : les drapeaux DEBUG et les valeurs par défaut sécurisées.
Configuration d'erreur PHP prête pour la production expliquée en bref
Dans le développement, je fais apparaître tous les messages car Qualité du code de manière précoce. Sur les serveurs en direct, j'éteins strictement l'affichage, mais je consigne tout pour pouvoir Diagnostic à tout moment. Ainsi, les interfaces utilisateur restent propres, tandis que les logs disent la vérité. Les erreurs de texte visibles menacent la confidentialité et peuvent interrompre des chaînes de fonctions ; j'empêche cela en les séparant clairement. Ce modèle améliore la stabilité de la sécurité et permet de planifier les temps de réaction.
php.ini : paramètres par défaut sécurisés pour le trafic en direct
Pour les environnements de développement, j'active display_errors et mets error_reporting En production, je désactive systématiquement les publicités tout en conservant un reporting et une journalisation complets. Ce mélange protège les utilisateurs et me permet de garder un œil sur le comportement du système. Je définis les valeurs de manière centralisée dans php.ini et je versionne les snippets ini complémentaires. Cela me permet d'obtenir des déploiements reproductibles et de réduire les surprises lors de l'exploitation en direct.
Le tableau suivant montre la comparaison des réglages DEV et PROD typiques pour plus de Transparence et claires Lignes directrices:
| Réglage | Développement | Production | Remarque |
|---|---|---|---|
| display_errors | On | Off | Éviter strictement l'affichage en direct |
| display_startup_errors | On | Off | Rendre les erreurs de démarrage visibles uniquement dans DEV |
| error_reporting | E_ALL ou -1 | E_ALL (filtre facultatif) | -1 couvre tous les niveaux, y compris les niveaux futurs |
| log_errors | On | On | Les logs sont une source obligatoire pour l'analyse |
| error_log | Fichier/chemin | Fichier/chemin | Sécuriser le chemin avec des rotations et des droits |
Dans PROD, je définis donc “Afficher désactivé, signaler activé” et j'active via error_log tout écrire dans des fichiers. En outre, je renforce les droits sur les fichiers, car les fichiers journaux contiennent souvent des contextes sensibles. Ceux qui utilisent des hôtes virtuels ou des conteneurs séparent proprement les chemins par application. Cela simplifie les corrélations ultérieures et accélère l'analyse des causes. Ainsi, l'interface reste conviviale, tandis que j'obtiens des traces complètes en arrière-plan.
Ajuster finement le niveau de reporting des erreurs sans afflux de logs
Par défaut, j'utilise dans PROD E_ALL et filtre éventuellement les bruits parasites comme les notes s'ils n'apportent pas de valeur. Un modèle fréquemment utilisé est E_ALL & ~E_NOTICE & ~E_WARNING & ~E_DEPRECATED. Cela permet d'éviter le bruit, tout en continuant à se concentrer sur les véritables erreurs de production. Avant d'apporter des modifications, je vérifie les effets sur le débit et la latence, car beaucoup de logging coûte en IO. Si vous voulez comprendre les effets par niveau, vous trouverez des explications sur les points suivants Niveau d'erreur et performance.
J'applique le principe “fixer d'abord proprement, filtrer ensuite”, car le refoulement ne fait que déplacer les problèmes. Pour les phases de migration, je fais enregistrer DEPRECATED de manière visible afin de détecter rapidement les futures ruptures. En outre, je marque séparément les classes d'erreurs critiques afin que les alarmes soient déclenchées de manière fiable. Ainsi, les chemins d'analyse profitent et je gagne du temps dans la résolution des pannes. Le résultat est moins de bruit et plus de données exploitables. Signaux.
Manipulateurs personnalisés : intercepter proprement les exceptions, les erreurs et les arrêts
J'installe mes propres gestionnaires avec set_error_handler(), set_exception_handler() et register_shutdown_function(). J'intercepte ainsi les erreurs classiques, les exceptions non capturées et les erreurs fatales. Pour les utilisateurs, je fournis une page 500 neutre, le contexte complet est consigné dans le journal. Cela protège les détails sensibles et maintient la stabilité du serveur à un niveau élevé. En même temps, je garde la main sur le format, les champs et les canaux de sortie.
<?php
class ErrorHandler {
public static function register() {
set_error_handler([__CLASS__, 'handleError']);
set_exception_handler([__CLASS__, 'handleException']);
register_shutdown_function([__CLASS__, 'handleShutdown']);
}
public static function handleError($errno, $errstr, $errfile, $errline) {
error_log("ERROR: [$errno] $errstr in $errfile on line $errline");
if ($errno === E_ERROR) {
http_response_code(500);
echo "Ein interner Fehler ist aufgetreten. Bitte versuchen Sie es später erneut.";
}
return true;
}
public static function handleException($exception) {
error_log("EXCEPTION: " . $exception->getMessage());
http_response_code(500);
echo "Ein interner Fehler ist aufgetreten.";
}
public static function handleShutdown() {
$error = error_get_last();
if ($error !== null) {
error_log("FATAL: " . $error['message']);
http_response_code(500);
}
}
}
ErrorHandler::register();Au quotidien, j'ajoute des champs tels que Request-ID, User-ID et Session-Hash pour Corrélation pour faciliter les choses. Pour les API, je fournis une structure d'erreur générique dans PROD, par exemple JSON avec le code et l'ID du ticket. Ainsi, le support peut intervenir immédiatement, tandis que les informations internes restent cachées. En outre, j'encapsule les E/S autour des enregistreurs pour éviter qu'un système de fichiers défectueux ne déclenche d'autres erreurs. Cette prévention en cascade contribue directement à la réduction du MTTR.
Logging structuré : contexte, rotation, alertes
Une bonne journalisation commence par Contexte: horodatage, type, fichier, ligne et référence de la requête. Vient ensuite la discipline : politique de rotation, droits et conservation. Je sépare les logs d'application et les logs de serveur web afin de garder une vue d'ensemble rapide. Je déclenche les classes critiques comme E_ERROR dans les canaux d'alerte, par exemple Mail ou Chat. Selon blog.nevercodealone.de, un journal d'erreurs clair réduit le temps de débogage jusqu'à 70 % - un levier puissant pour les opérations.
<?php
set_error_handler(function ($errno, $errstr, $errfile, $errline) {
if (!(error_reporting() & $errno)) return false;
$type = match($errno) {
E_ERROR => 'ERROR',
E_WARNING => 'WARNING',
E_NOTICE => 'NOTICE',
default => 'UNKNOWN'
};
$message = sprintf(
"[%s] %s: %s in %s on line %d | req=%s user=%s",
date('Y-m-d H:i:s'), $type, $errstr, $errfile, $errline,
$_SERVER['HTTP_X_REQUEST_ID'] ?? '-', $_SESSION['uid'] ?? '-'
);
error_log($message, 3, '/var/log/app/custom_error.log');
if ($errno === E_ERROR) {
// Alert versenden
}
return true;
});Je vérifie la taille des logs quotidiennement ou de manière automatisée pour Mémoire de préserver les données. La rotation avec des règles basées sur la taille ou le temps évite les disques pleins. En outre, j'écris en option au format JSON pour que les analyseurs puissent extraire les métriques. Pour l'évaluation, une entrée structurée est utile ; le guide sur les Analyser les logs des pistes de réflexion utiles. Cela me permet de repérer plus rapidement les dérives et de minimiser les vols à l'aveuglette.
Vivre de manière cohérente la séparation entre DEV, STAGE et PROD
Je garde chaque environnement avec sa propre Drapeau DEBUG et des overrides ini dédiés. Les valeurs de configuration atterrissent dans des variables Env, pas dans le code. Le serveur web affiche des en-têtes de cache dans PROD, tandis que DEV est généreusement désactivé. Pour STAGE, je reflète les paramètres PROD, mais j'active des métriques supplémentaires. Cette discipline évite les surprises et augmente la prédictibilité des déploiements.
Les noms des fichiers journaux varient en fonction de l'environnement, ce qui me permet erreurs types ne se mélangent pas. CI/CD définit les indicateurs avant le déploiement, de sorte qu'aucune erreur humaine ne s'y glisse. J'ajoute des contrôles de santé pour les points finaux essentiels, afin que les interruptions soient détectées rapidement. Les indicateurs de fonctionnalités aident à protéger temporairement les chemins risqués. De cette manière, les mises en service restent prévisibles et les risques de retour en arrière sont réduits.
Débogage de l'exécution : Quand je dois vérifier rapidement
Parfois, j'ai besoin pendant un moment Aperçu sur une instance de test, par exemple juste après un hotfix. Ensuite, j'active temporairement ini_set(‚display_errors‘, 1) et error_reporting(E_ALL) - mais jamais en production réelle. Je consigne chaque modification, je la supprime ensuite et je n'en communique rien. Un petit tour de contrôle avec des requêtes ciblées est généralement suffisant. Ensuite, je retourne immédiatement aux logs silencieux et aux fausses pages neutres.
Pour des analyses reproductibles, j'encapsule des indicateurs de débogage derrière des toggles de fonctions que je dans le temps limiter les risques. J'évite ainsi des situations permanentes et je réduis les risques. Si je dois creuser plus profondément, je mise sur Xdebug dans un environnement DEV isolé. Mesurer plutôt que deviner reste le leitmotiv. C'est la seule façon de détecter les goulots d'étranglement réels et non les placebos.
Configurer WordPress et les frameworks en toute sécurité
Sur WordPress, je place dans PROD WP_DEBUG à false et redirige les erreurs vers les logs. Dans DEV, j'utilise WP_DEBUG_LOG et WP_DEBUG_DISPLAY de manière ciblée pour le développement de fonctionnalités. Je désactive les éditeurs de plug-ins dans PROD afin qu'aucune modification de code ne se produise en direct. Le contrôle cron via des tâches cron système réduit les aberrations et lisse Pics de charge. Pour les détails, le guide compact sur le Mode de débogage de WordPress.
Des frameworks comme Symfony ou Laravel fournissent des indicateurs ENV et des pages d'erreur dédiés, que je conséquent utilise. J'utilise des enregistreurs centralisés comme Monolog avec une structure de canaux. Pour les réponses HTTP dans PROD, j'édite des textes d'erreur génériques et je fais référence à des corrélations en interne. Ainsi, les interfaces restent neutres, mais les logs sont riches. Cette combinaison contribue sensiblement à la stabilité du serveur.
Les aspects de sécurité : Ce qui ne doit jamais atterrir dans le journal
Je filtre systématiquement Secrets: mots de passe, jetons, fragments de cartes de crédit et données personnelles. Le masquage a lieu le plus tôt possible, par exemple au niveau du service avant le logger. Pour les messages d'erreur, je vérifie si les contenus contiennent des chemins d'accès aux fichiers, des SQL ou des IP internes. Tout ce qui augmente la surface d'attaque est masqué ou anonymisé. Ainsi, les logs restent utiles sans compromettre la protection des données ou la sécurité.
Je définis les droits de fichiers de manière restrictive et les processus n'écrivent que dans les fichiers partagés. Sentiers. En outre, j'active la rotation des logs avec compression, afin que les anciennes données ne soient pas exposées. En cas d'incident, je tiens un runbook à disposition : Où trouver quelles traces, quelles équipes avertir en premier. Cette préparation permet d'économiser de précieuses minutes dans les situations d'urgence. Au final, c'est le temps de récupération qui compte.
Surveillance et alarme sans ratés d'allumage
Je définis des valeurs seuils qui contextuel sont des alertes : Les alertes isolées ne déclenchent pas d'alarme, les pics soudains si. Les fenêtres de temps, les limites de taux et la déduplication empêchent la fatigue des pagers. Je signale immédiatement les classes critiques comme E_ERROR, E_PARSE et les dépassements de temps récurrents. Pour les dérives récurrentes, je prévois des tickets plutôt que des mesures ad hoc. Ainsi, l'équipe reste capable d'agir et les vrais problèmes ne passent pas inaperçus.
La visualisation m'aide à identifier des schémas reconnaîtreCycles journaliers, pics de déploiement, vagues de bots. Les corrélations entre les dates de release et les taux d'erreur révèlent les causes. J'enregistre les runbooks directement dans les textes d'alarme afin que On-Call puisse agir immédiatement. Je surveille également les dépendances telles que les bases de données et les files d'attente. Un flux d'erreurs sans contexte fournit rarement des solutions.
Liste de contrôle du déploiement : Déployer en limitant les erreurs
Avant chaque déploiement, je vérifie Configuration, les logs, les droits et la mémoire libre. Ensuite, j'effectue un smoke test avec les points de terminaison les plus importants. Les indicateurs de fonctionnalités et les versions Canary réduisent les risques lors de changements importants. Je consigne les temps de déploiement afin de faciliter les corrélations par la suite. En outre, je planifie des retours en arrière au cas où un hotfix tournerait mal.
Pour les mises à jour importantes, je déplace brièvement la charge d'écriture et j'exécute des Readiness-sont plus sévères. Il s'agit notamment de vérifier la possibilité d'écrire dans le journal et les connexions à la base de données. En outre, je contrôle si 500 pages apparaissent correctement et sans internalités. Ces points apparemment mineurs évitent les grandes surprises. Les déploiements sont ainsi moins bruyants et plus compréhensibles.
FPM et serveur web : sécurisation spécifique à SAPI
En plus de php.ini, je sécurise Piscines FPM de manière dure. Dans l'ensemble du pool, je définis display_errors sur Off par php_admin_flag et impose ainsi des valeurs par défaut productives même en cas d'erreurs dans les overrides d'application. Avec slowlog et request_terminate_timeout, j'identifie et je limite les blocages avant qu'ils ne bloquent les travailleurs. En outre, je consigne les sorties des travailleurs afin d'enregistrer les rares cas de bord.
[www]
php_admin_flag[display_errors] = Off
php_admin_value[error_reporting] = E_ALL
php_admin_value[log_errors] = On
php_admin_value[limite_mémoire] = 256M
catch_workers_output = yes
request_terminate_timeout = 30s
slowlog = /var/log/php-fpm/www-slow.log
request_slowlog_timeout = 5sAu niveau du serveur web (nginx/Apache), j'active fastcgi_intercept_errors ou ProxyErrorOverride. Ainsi, le serveur web peut livrer des pages statiques 50x si PHP tombe en panne. Je cache pas de 5xx, mais je traite les erreurs 4xx avec des TTL courts. Un en-tête X-Request-ID est généré par le serveur web et transmis à PHP pour que je corrige chaque chemin.
# nginx
error_page 500 502 503 504 /50x.html ;
location = /50x.html { root /usr/share/nginx/html ; internal ; }
fastcgi_intercept_errors on ;
add_header X-Request-Id $request_id always ;
# Apache (extrait)
ErrorDocument 500 /50x.html
ProxyErrorOverride OnDans PROD, je désactive également html_errors et expose_php. Cela évite les erreurs de texte au format HTML et les fuites sur les versions de PHP. Avec ignore_repeated_errors et log_errors_max_len je contrôle les tempêtes de logs sans avaler les vrais signaux. J'exploite Opcache de manière strictement proche de la production, mais je veille à ce que les messages d'erreur ne soient pas masqués par une revalidation agressive.
Réponse uniforme aux erreurs pour les API et les frontaux
Je standardise le schéma de réponse : Voir les utilisateurs générique Les textes, les systèmes reçoivent des codes structurés. Les erreurs 4xx signalent les problèmes des clients (validation, authentification), les erreurs 5xx représentent les problèmes des serveurs. Une représentation cohérente des exceptions sur les statuts HTTP évite les malentendus et facilite la surveillance.
[
'code' => $code,
'message' => $publicMessage,
'request_id' => $_SERVER['HTTP_X_REQUEST_ID'] ? ? '-',
'timestamp' => date('c'),
] + $meta
] ;
header('Type de contenu : application/json') ;
echo json_encode($payload) ;
}
try {
// ...
} catch (ValidationException $e) {
respondError(422, 'VALIDATION_FAILED', 'Entrée incomplète ou invalide') ;
} catch (NotFoundException $e) {
respondError(404, 'NOT_FOUND', 'Ressource introuvable') ;
} catch (Throwable $e) {
error_log('UNHANDLED : '.$e->getMessage()) ;
respondError(500, 'INTERNAL_ERROR', 'Une erreur interne est survenue') ;
}Pour les UI, je tiens à disposition une page 500 propre, qui ne montre pas d'informations internes. Si je localise des textes erronés, je le fais exclusivement pour public Messages - les détails internes restent dans les logs. Cela améliore la qualité de l'assistance et réduit les demandes de renseignements.
Collecte centralisée des logs, échantillonnage et conteneurs
Dans les configurations modernes, je transmets les logs de manière centralisée à Syslog ou Journald. Dans les conteneurs, j'écris de préférence vers stdout/stderr et laisse la rotation et l'envoi à la plateforme. J'évite les logs basés sur des fichiers dans des conteneurs, à moins qu'un sidecar ne les tourne de manière fiable. J'utilise l'échantillonnage de manière contrôlée : En cas d'alertes massives et similaires, j'enregistre des échantillons représentatifs et je continue à conserver les données. chaque classe critique.
J'enrichis les lignes de log pour inclure le hash de déploiement, l'hôte, l'ID du pod/conteneur et l'environnement. En cas de défaillance de l'envoi central, j'effectue un buffering limité localement et, si nécessaire, je reviens à un logging minimal afin de ne pas bloquer la requête. Les problèmes de réseau ne doivent pas Erreurs en cascade déclencher dans le chemin critique - la stabilité prime sur l'exhaustivité.
Traiter de manière robuste les CLI, les tâches Cron et les processus Worker
Les scripts CLI suivent leurs propres règles : Ils ont besoin Codes de sortie, Ils écrivent selon STDERR et ne doivent jamais échouer en silence. Je sépare leurs logs des requêtes web et je veille à des stratégies de backoff/retrait en cas d'erreurs transitoires. Pour les tâches longues, je fixe délibérément des limites de mémoire et j'enregistre les scores intermédiaires afin de pouvoir détecter les accrocs ou les fuites.
<?php
if (PHP_SAPI === 'cli') {
set_error_handler(function($errno, $errstr, $errfile, $errline) {
$msg = sprintf("CLI [%s] %s in %s:%d\n", $errno, $errstr, $errfile, $errline);
fwrite(STDERR, $msg);
return true;
});
register_shutdown_function(function() {
$e = error_get_last();
if ($e) fwrite(STDERR, "CLI FATAL: {$e['message']}\n");
});
}
try {
// Job-Logik
exit(0);
} catch (Throwable $e) {
fwrite(STDERR, "CLI EXCEPTION: ".$e->getMessage()."\n");
// 2 = temporär, 1 = dauerhaft, 3 = Konfig-Fehler (Beispiel)
exit(2);
}J'encapsule les tâches cron avec des lockfiles ou des locks distribués afin d'éviter que des démarrages parallèles ne provoquent des pics de charge et des salves d'erreurs. Je planifie les fenêtres de reprise de manière à ce qu'elles n'entrent pas en collision avec le trafic de pointe. Ici aussi riche en contexte Les logs battent n'importe quelle trace de pile tronquée.
Approfondir la protection des données, la conservation et le masquage
Au-delà du simple fait de “ne pas se connecter”, j'implémente Règles de masquageJe remplace les jetons et les mots de passe par des caractères génériques, je conserve les IP sous forme abrégée et je pseudonymisais les identifiants personnels (hash avec salt). Je définis des règles claires pour chaque environnement. Rétention-et supprimer automatiquement les anciens stocks. Les chemins d'exportation (par ex. les bundles de support) sont en outre cryptés et accessibles en fonction des rôles.
Je vérifie les exceptions pour les contenus sensibles (SQL avec valeurs claires, noms d'hôtes internes). J'apprends aux équipes à utiliser les neutre formuler des textes erronés. La protection des données commence dans le code - l'enregistreur n'est que le dernier recours, pas le premier filtre.
Versions, dépréciations et fenêtres de migration
Pour les mises à jour PHP, je décris une fenêtre de migration : dans STAGE, j'évalue E_DEPRECATED dans PROD, je les enregistre de manière visible, mais sans alarme. Je distingue les dépréciations provenant de ma base de code et celles provenant de paquets tiers et je planifie les corrections de manière itérative. Un cas de test dédié permet de s'assurer que les dépréciations pas polluent l'IU et finissent exclusivement dans des logs.
Je considère en outre qu'une Matrice de compatibilité pour les extensions. Si des composants divergent temporairement, je réduis le volume du journal de manière ciblée, sans désamorcer les classes critiques. L'objectif est toujours le même : fixer proprement et non pas cacher.
SLO, budgets d'erreur et contrôle fin des alarmes
Je ne me contente pas de mesurer des chiffres absolus d'erreurs, mais je définis Taux d'erreur-SLOs par point final. Je déduis du budget d'erreur la fréquence de déploiement et le mode de surveillance : si le budget est serré, j'augmente la prudence, j'active l'échantillonnage de manière plus stricte et je donne la priorité au travail de qualité. Je déduplique les alarmes en fonction du temps et je les regroupe par cause (même trace de pile, même point de terminaison) afin que On-Call reste capable d'agir.
Pages d'erreur du serveur web, pannes du FPM et pièges de la mise en cache
Si le FPM est à genoux ou fournit 502/504, la statique Page 50x comme repli fiable. Cette page ne contient pas d'informations de construction ni de liens internes, mais des indications claires pour les utilisateurs et les contacts de support. Je veille à ce que les CDN et les reverse proxies ne mettent pas en cache les 5xx et respectent les en-têtes Retry-After. Pour les fenêtres de maintenance, j'envoie 503 avec Retry-After, pas 500, et je garde des pages de maintenance en dehors de PHP.
Pour les requêtes avec acceptation de JSON, je propose en option à 5xx une réponse d'erreur JSON minimale provenant du serveur web, afin que les clients ne se retrouvent pas dans le vide. En même temps, j'évite que le serveur web ne révèle des chemins ou des modules internes - la sécurité prime sur le confort, même avec le fallback.
Résumé pratique
Je sépare systématiquement DEV et PROD, je désactive les annonces dans Live et j'enregistre les données dans le journal. entièrement. Les gestionnaires personnalisés me permettent de contrôler la réaction et le contexte. Un niveau d'erreur clair, des filtres judicieux et une rotation propre réduisent le bruit. Les filtres de sécurité protègent les secrets, tandis que les alarmes ne se déclenchent qu'en cas de problème réel. Ainsi, l'interface reste calme, les logs sont clairs et la stabilité du serveur augmente sensiblement.
Celui qui suit ce set-up s'éloigne du extinction d'incendie vers un fonctionnement prédictif. Les déploiements sont calculables, les pannes plus courtes et les analyses répétables. C'est précisément pour cela qu'il vaut la peine d'investir dans une configuration propre. J'applique ces principes dans chaque projet et je dors plus tranquille. La production n'a pas besoin de magie, mais de règles claires et d'une mise en œuvre disciplinée.
