Ga naar de inhoud 
Ik laat je de productieklare configuratie zien voor PHP Foutafhandeling Hostingvan php.ini standaardinstellingen en loggingstrategieën naar aangepaste handlers voor schone reacties. Dit is hoe ik productiefouten van de gebruikersinterface, beveilig gevoelige informatie en verhoog de stabiliteit van de server tijdens live gebruik.
Centrale punten
- php.ini ontkoppelen: DEV toont alles, PROD logt discreet.
- Foutniveau fijn filter: Focus op echte productiefouten.
- Aangepaste handler gebruiken: Onderschep fouten, reageer netjes.
- Loggen structuur: Context, rotatie, waarschuwingen.
- Omgeving duidelijk gescheiden: DEBUG-vlaggen en veilige standaardinstellingen.
Productieklare PHP foutconfiguratie kort uitgelegd
Ik laat alle berichten in de ontwikkeling verschijnen omdat ik Code kwaliteit vroeg beveiligen. Op live servers schakel ik het beeldscherm strikt uit, maar log ik alles zodat ik Diagnose op elk moment mogelijk. Dit houdt gebruikersinterfaces schoon, terwijl logs de waarheid vertellen. Zichtbare foutteksten brengen de vertrouwelijkheid in gevaar en kunnen functieketens onderbreken; dit voorkom ik met een duidelijke scheiding. Dit patroon verhoogt de stabiliteit van de server en houdt de responstijden voorspelbaar.
php.ini: standaardinstellingen beveiligen voor live verkeer
Voor ontwikkelomgevingen activeer ik display_errors en stel in fout_rapportage In productie schakel ik advertenties consequent uit, maar behoud ik uitgebreide rapportage en logging. Deze mix beschermt gebruikers en houdt mijn inzicht in systeemgedrag intact. Ik definieer de waarden centraal in php.ini en versie aanvullende ini snippets. Dit geeft me reproduceerbare implementaties en minimaliseert verrassingen tijdens live gebruik.
De volgende tabel toont een vergelijking van typische DEV- en PROD-instellingen voor meer Transparantie en duidelijk Richtlijnen:
| Instelling | Ontwikkeling | Productie | Tip |
|---|---|---|---|
| display_errors | Op | Uit | Weergave in live-modus strikt vermijden |
| weergave_opstart_fouten | Op | Uit | Startfout alleen zichtbaar maken in DEV |
| fout_rapportage | E_ALL of -1 | E_ALL (optioneel filter) | -1 dekt alle niveaus, inclusief toekomstige niveaus |
| log_fouten | Op | Op | Logboeken zijn een verplichte bron voor analyse |
| foutlogboek | Bestand/Pad | Bestand/Pad | Beveiligd pad met rotatie en rechten |
Dus ik stel “display uit, rapport aan” in PROD in en heb foutlogboek schrijf alles naar bestanden. Ik stel ook harde bestandsrechten in omdat logbestanden vaak gevoelige contexten bevatten. Als je virtuele hosts of containers gebruikt, scheid paden dan netjes voor elke applicatie. Dit vereenvoudigt latere correlaties en versnelt hoofdoorzaakanalyses. Dit houdt de interface vriendelijk, terwijl ik volledige traces op de achtergrond krijg.
Foutrapportageniveau fijn afstellen zonder logovervloed
Standaard gebruik ik in PROD E_ALL en filteren optioneel achtergrondgeluiden zoals mededelingen als ze geen waarde hebben. Een veelgebruikt patroon is E_ALL & ~E_NOTICE & ~E_WARNING & ~E_DEPRECATED. Dit voorkomt ruis, maar blijft zich richten op echte productiefouten. Voordat ik wijzigingen aanbreng, controleer ik de effecten op doorvoer en latency omdat veel loggen IO kost. Als je de effecten per niveau wilt begrijpen, kun je achtergrondinformatie vinden op Foutenniveau en prestaties.
Ik hanteer het principe “eerst netjes repareren, dan pas filteren”, omdat onderdrukken problemen alleen maar uitstelt. Voor migratiefasen log ik zichtbaar DEPRECATED om toekomstige fouten in een vroeg stadium te herkennen. Ik markeer ook kritieke foutklassen apart zodat alarmen betrouwbaar afgaan. Dit komt de analysepaden ten goede en bespaart me tijd bij het oplossen van problemen. Het resultaat is minder ruis en meer bruikbare gegevens. Signalen.
Aangepaste handler: netjes uitzonderingen, fouten en uitschakelingen onderscheppen
Ik installeer mijn eigen handlers met set_error_handler(), set_uitzondering_handler() en register_shutdown_functie(). Zo vang ik klassieke fouten, niet-gevangen uitzonderingen en fatale fouten op. Ik voorzie gebruikers van een neutrale 500-pagina en de volledige context komt in het log terecht. Dit beschermt gevoelige details en houdt de stabiliteit van de server hoog. Tegelijkertijd behoud ik de controle over het formaat, de velden en de uitvoerkanalen.
<?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();In het dagelijks leven voeg ik velden toe zoals verzoek-ID, gebruikers-ID en sessie-hash om Correlatie om het gemakkelijker te maken. Voor API's voorzie ik een generieke foutstructuur in PROD, zoals JSON met code en ticket-ID. Hierdoor kan ondersteuning direct starten, terwijl interne informatie verborgen blijft. Ik kapsel ook IO in rond loggers zodat een defect bestandssysteem geen verdere fouten veroorzaakt. Deze cascadevermijding draagt direct bij aan een lagere MTTR.
Gestructureerd loggen: context, rotatie, waarschuwingen
Goed loggen begint met ContextTijdstempel, type, bestand, regel en verzoekreferentie. Dit wordt gevolgd door de discipline: rotatiebeleid, machtigingen en retentie. Ik scheid app logs en webserver logs om een snel overzicht te houden. Ik trigger kritische klassen zoals E_ERROR in alarmkanalen, zoals mail of chat. Volgens blog.nevercodealone.de vermindert een duidelijk foutenlog de debug-tijd met wel 70 % - een krachtige hefboom voor operaties.
<?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;
});Ik controleer de loggrootte dagelijks of automatisch om Geheugen om de schijven te beschermen. Rotatie met grootte- of tijdgebaseerde regels voorkomt volle schijven. Daarnaast schrijf ik optioneel in JSON-formaat zodat parsers metriek kunnen extraheren. Een gestructureerde start helpt bij de evaluatie; de gids voor Logboeken analyseren nuttige stof tot nadenken. Dit stelt me in staat om sneller uitschieters te herkennen en zo min mogelijk blind te varen.
Consistente scheiding van DEV, STAGE en PROD
Ik houd elke omgeving met zijn eigen DEBUG vlag en specifieke ini overschrijvingen. Configuratiewaarden komen terecht in Env-variabelen, niet in de code. De webserver toont cache headers in PROD, terwijl DEV genereus gedeactiveerd is. Voor STAGE spiegel ik de PROD instellingen, maar schakel ik extra metrieken in. Deze discipline voorkomt verrassingen en verhoogt de voorspelbaarheid van implementaties.
Logbestandsnamen verschillen afhankelijk van de omgeving, zodat ik Foutbeelden niet mengen. CI/CD zet de vlaggen vóór de uitrol zodat er geen menselijke fouten insluipen. Ik voeg gezondheidscontroles toe voor belangrijke eindpunten zodat downtime in een vroeg stadium wordt opgemerkt. Feature vlaggen helpen om riskante paden tijdelijk af te schermen. Op deze manier houd ik releases voorspelbaar en verlaag ik de risico's van rollbacks.
Debuggen tijdens runtime: Wanneer ik snel moet controleren
Soms heb ik een korte Inzicht op een testinstantie, bijvoorbeeld direct na een hotfix. Dan stel ik tijdelijk ini_set(‚display_errors‘, 1) en error_reporting(E_ALL) in - maar nooit op echte productie. Ik log elke verandering, verwijder het daarna en commit er niets van. Een korte testronde met gerichte requests is meestal voldoende. Daarna ga ik onmiddellijk terug naar stille logs en neutrale foutpagina's.
Voor reproduceerbare analyses sluit ik debug-flags in achter functieknoppen die ik tijdelijk beperken. Op deze manier voorkom ik permanente toestanden en verminder ik het risico. Als ik dieper moet graven, vertrouw ik op Xdebug in een geïsoleerde DEV-omgeving. Meten in plaats van gissen blijft de leidraad. Alleen zo kan ik echte knelpunten herkennen en geen placebo's.
WordPress en frameworks veilig configureren
Met WordPress stel ik in PROD WP_DEBUG op false en fouten omleiden naar logs. In DEV gebruik ik WP_DEBUG_LOG en WP_DEBUG_DISPLAY specifiek voor functieontwikkeling. In PROD deactiveer ik plugin editors zodat er geen codewijzigingen live plaatsvinden. Cron controle via systeem cronjobs vermindert uitschieters en egaliseert Pieken in belasting. De compacte gids voor de WordPress foutopsporingsmodus.
Frameworks zoals Symfony of Laravel bieden speciale ENV-flags en foutpagina's, die ik consequent gebruiken. Ik gebruik gecentraliseerde loggers zoals Monolog met een kanaalstructuur. Voor HTTP-reacties in PROD voer ik generieke foutteksten uit en verwijs ik intern naar correlaties. Op deze manier blijven interfaces neutraal, maar logs productief. Deze combinatie levert een merkbare bijdrage aan de stabiliteit van de server.
Beveiligingsaspecten: Wat mag nooit in het logboek terechtkomen
Ik filter consequent GeheimenWachtwoorden, tokens, creditcardfragmenten en persoonlijke gegevens. Het maskeren gebeurt zo vroeg mogelijk, bijvoorbeeld op serviceniveau vóór de logger. Bij foutmeldingen controleer ik of de inhoud bestandspaden, SQL's of interne IP's bevat. Alles wat het aanvalsoppervlak vergroot, scherm ik af of anonimiseer ik. Op deze manier blijven logs bruikbaar zonder de gegevensbescherming of beveiliging in gevaar te brengen.
Ik heb de bestandsrechten beperkt ingesteld en processen schrijven alleen naar gedeelde bestanden. Paden. Ik activeer ook logrotatie met compressie zodat oude gegevens niet openlijk rondslingeren. Ik houd een runbook klaar voor incidenten: Waar vind ik welke sporen, welke teams licht ik als eerste in. Deze voorbereiding bespaart kostbare minuten in hectische situaties. Uiteindelijk is het de tijd tot herstel die telt.
Bewaking en alarmering zonder verkeerde aansturing
Ik definieer drempelwaarden die contextgevoelig zijn: Afzonderlijke waarschuwingen veroorzaken geen alarm, maar plotselinge pieken wel. Tijdvensters, snelheidslimieten en ontdubbeling voorkomen pager-moeheid. Ik rapporteer kritieke klassen zoals E_ERROR, E_PARSE en terugkerende timeouts onmiddellijk. Voor terugkerende uitschieters plan ik tickets in plaats van ad-hocmaatregelen. Zo blijft het team slagvaardig en blijven echte problemen niet onopgemerkt.
Visualisatie helpt me om patronen te herkennen herkennenDagelijkse cycli, inzetpieken, botgolven. Correlaties tussen releasetijden en foutpercentages onthullen oorzaken. Ik sla runbooks direct op in alarmteksten, zodat on-call onmiddellijk kan handelen. Ik monitor ook afhankelijkheden zoals databases en wachtrijen. Een foutenstroom zonder context biedt zelden oplossingen.
Checklist voor implementatie: Uitrollen met weinig fouten
Voor elke uitrol controleer ik Configuratie, logs, permissies en vrij geheugen. Daarna voer ik een rooktest uit met de belangrijkste eindpunten. Feature flags en canary releases verminderen de risico's bij grote veranderingen. Ik log implementatietijden om latere correlaties te vergemakkelijken. Ik plan ook backpaden voor het geval een hotfix fout gaat.
Voor grotere updates verschuif ik de schrijfbelasting voor korte tijd en voer ik Gereedheid-probes zijn strenger. Dit omvat een controle op schrijfbaarheid in logboeken en databaseverbindingen. Ik controleer ook of 500 pagina's correct en zonder interne informatie worden weergegeven. Deze ogenschijnlijk kleine punten voorkomen grote verrassingen. Dit maakt rollouts rustiger en begrijpelijker.
FPM en webserver: SAPI-specifieke bescherming
Naast php.ini sla ik de FPM zwembaden hard. Over de hele groep stel ik display_errors in op Off via php_admin_flag en zo dwing ik productieve standaardinstellingen af, zelfs met foutieve applicatie-overrides. Ik gebruik slowlog en request_terminate_timeout om hangs te identificeren en te beperken voordat ze werkers blokkeren. Ik log ook uitvoer van werkers om zeldzame randgevallen te registreren.
[www]
php_admin_flag[display_errors] = Uit
php_admin_waarde[error_reporting] = E_ALL
php_admin_waarde[log_errors] = Aan
php_admin_waarde[memory_limit] = 256M
catch_workers_output = ja
verzoek_terminate_timeout = 30s
slowlog = /var/log/php-fpm/www-slow.log
request_slowlog_timeout = 5sOp webserverniveau (nginx/Apache) activeer ik fastcgi_intercept_errors of ProxyErrorOverride. Hierdoor kan de webserver 50x statische pagina's leveren als PHP faalt. Ik cache geen 5xx antwoorden, maar ik behandel 4xx fouten met korte TTL's. Een X-Request-ID header wordt gegenereerd door de webserver en doorgegeven aan PHP zodat ik elk pad kan corrigeren.
# nginx
error_page 500 502 503 504 /50x.html;
location = /50x.html { root /usr/share/nginx/html; internal; }
fastcgi_intercept_errors aan;
add_header X-Request-Id $request_id altijd;
# Apache (uittreksel)
Foutendocument 500 /50x.html
ProxyErrorOverride AanIn PROD deactiveer ik ook html-fouten en blootleggen_php. Dit voorkomt onjuiste HTML-teksten en lekken via PHP-versies. Met negeer_herhaalde_fouten en log_fouten_max_len Ik houd de logboekstormen in toom zonder echte signalen in te slikken. Ik draai Opcache strikt dicht bij productie, maar zorg ervoor dat foutmeldingen niet verborgen worden door agressieve revalidatie.
Gestandaardiseerde foutreacties voor API's en front-ends
Ik standaardiseer het reactieschema: Gebruikers zien generiek Teksten, systemen ontvangen gestructureerde codes. 4xx fouten duiden op problemen met de client (validatie, auth), 5xx fouten staan voor problemen met de server. Consistente toewijzing van uitzonderingen aan HTTP-status voorkomt misverstanden en vergemakkelijkt controle.
[
'code' => $code,
'message' => $publicMessage,
'request_id' => $_SERVER['HTTP_X_REQUEST_ID'] ?? '-',
'timestamp' => date('c'),
] + $meta
];
header('Content-Type: application/json');
echo json_encode($payload);
}
try {
// ...
} catch (ValidationException $e) {
respondError(422, 'VALIDATION_FAILED', 'Invoer onvolledig of ongeldig');
} vangst (NotFoundException $e) {
respondError(404, 'NOT_FOUND', 'Bron niet gevonden');
} catch (Throwable $e) {
error_log('ONGESCHIKT: '.$e->getMessage());
respondError(500, 'INTERNAL_ERROR', 'Er is een interne fout opgetreden');
}Voor UI's houd ik een schone 500-pagina bij die geen interne informatie toont. Als ik onjuiste tekst lokaliseer, doe ik dit alleen voor Openbaar Berichten - interne details blijven in logboeken staan. Dit verhoogt de kwaliteit van de ondersteuning en vermindert het aantal vragen.
Centrale logboekverzameling, bemonstering en containers
In moderne opstellingen stuur ik logs centraal door naar Syslog of Journald. In containers schrijf ik liever naar stdout/stderr en laat rotatie en verzending over aan het platform. Ik vermijd bestandsgebaseerde logs in containers tenzij een zijspan ze betrouwbaar roteert. Ik gebruik steekproeven op een gecontroleerde manier: In het geval van massa's gelijkaardige waarschuwingen, neem ik representatieve willekeurige steekproeven en blijf ze opslaan. elke kritische klasse in zijn geheel.
Ik verrijk logregels met deployment hash, host, pod/container ID en omgeving. Als de centrale dispatch mislukt, buffer ik lokaal en val terug op minimale logging indien nodig om het verzoek niet te blokkeren. Netwerkproblemen mogen niet Foutcascades in het kritieke pad - stabiliteit gaat boven volledigheid.
CLI, cronjobs en werkprocessen robuust afhandelen
CLI scripts volgen hun eigen regels: Je moet Exit-codes, schrijven naar STDERR en mogen nooit stilletjes falen. Ik scheid hun logs van webverzoeken en voorzie backoff/retry strategieën voor voorbijgaande fouten. Voor lange taken stel ik bewust geheugenlimieten in en log ik tussentijdse statussen zodat ik hangs of lekken kan herkennen.
<?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);
}Ik sluit cron jobs in met lock bestanden of gedistribueerde locks zodat parallelle starts niet leiden tot belastingspieken en foutsalvo's. Ik plan retry vensters zodat ze niet botsen met piekverkeer. Hetzelfde geldt hier: rijk aan context Logs verslaan elke stub stack trace.
Gegevensbescherming, opslag en maskering verdiepen
Naast gewoon “niet loggen”, implementeer ik Regels voor maskerenIk vervang tokens en wachtwoorden door placeholders, ik sla verkorte IP's op en ik pseudonimiseer persoonlijke ID's (hash met salt). Voor elke omgeving definieer ik duidelijk Behoud-tijden en oude voorraden automatisch verwijderen. Exportpaden (bijv. ondersteuningsbundels) worden ook versleuteld en zijn toegankelijk op rolgebaseerde basis.
Ik controleer uitzonderingen op gevoelige inhoud (SQL met duidelijke waarden, interne hostnamen). Ik leer teams om behulpzame, maar neutraal om foutteksten te formuleren. Gegevensbescherming begint in de code - de logger is slechts de laatste instantie, niet de eerste filter.
Versies, afschrijvingen en migratievensters
Voor PHP-upgrades beschrijf ik een migratievenster: In STAGE evalueer ik E_DEPRECATED Ik log ze zichtbaar in PROD, maar zonder waarschuwing. Ik maak onderscheid tussen deprecaties uit mijn codebase en uit pakketten van derden en plan fixes iteratief. Een speciale testcase zorgt ervoor dat deprecaties niet vervuilen de UI en eindigen uitsluitend in logs.
Ik heb ook een Compatibiliteitsmatrix klaar voor uitbreidingen. Als componenten tijdelijk divergeren, smoor ik het logvolume op een gerichte manier af zonder kritieke klassen onschadelijk te maken. Het doel is altijd om dingen netjes op te lossen, niet om ze te verbergen.
SLO's, foutbudgetten en alarmfijnregeling
Ik meet niet alleen absolute ontbrekende aantallen, maar definieer ook Foutenpercentage SLO's per eindpunt. Ik leid de inzetfrequentie en de bewakingsmodus af van het foutbudget: als het budget krap is, verhoog ik de voorzichtigheid, activeer ik sampling strenger en geef ik prioriteit aan kwaliteitswerk. Ik ontdubbel alarmen op basis van tijd en cluster ze op basis van oorzaak (zelfde stack trace, zelfde endpoint) zodat On-Call in staat blijft om op te treden.
Foutpagina's van de webserver, FPM-fouten en caching-traps
Als de FPM daalt of 502/504 levert, wordt de statisch 50x pagina als een betrouwbare terugval. Deze pagina bevat geen build-informatie of interne links, maar duidelijke instructies voor gebruikers en supportcontacten. Ik zorg ervoor dat CDN's en reverse proxies geen 5xx cachen en Retry-After headers respecteren. Voor onderhoudsvensters stuur ik 503 met Retry-After, geen 500, en houd ik onderhoudspagina's buiten PHP.
Voor verzoeken met JSON acceptatie bied ik optioneel een minimale JSON foutreactie van de webserver voor 5xx zodat clients niet tegen niets aanlopen. Tegelijkertijd vermijd ik dat de webserver interne paden of modules onthult - veiligheid gaat ook boven gemak als het gaat om fallback.
Praktische samenvatting
Ik scheid DEV en PROD consequent, schakel advertenties uit in Live en log volledig. Aangepaste handlers geven me controle over reactie en context. Een duidelijk foutenniveau, zinvolle filters en schone rotatie verminderen ruis. Beveiligingsfilters beschermen geheimen, terwijl alarmen alleen afgaan bij echte problemen. Dit houdt de interface rustig, de logs spreken duidelijke taal en de stabiliteit van de server neemt merkbaar toe.
Als je deze opzet volgt, ga je weg van de brandblussen naar een voorspellende werking. Implementaties worden berekenbaar, verstoringen korter en analyses herhaalbaar. Dit is precies waarom investeren in een schone configuratie de moeite waard is. Ik implementeer deze principes in elk project en slaap een stuk beter. Productie heeft geen magie nodig, maar duidelijke regels en een gedisciplineerde implementatie.
