Hoppa till innehåll 
Jag ska visa dig den produktionsfärdiga konfigurationen för Hosting för PHP-felhanteringfrån php.ini-standardvärden och loggningsstrategier till anpassade hanterare för rena svar. Det här är hur jag håller produktionsfel från användargränssnittet, skydda känslig information och öka serverns stabilitet i skarp drift.
Centrala punkter
- php.ini Koppla bort: DEV visar allt, PROD loggar diskret.
- Felnivå fint filter: Fokus på äkta produktionsfel.
- Anpassad hanterare utnyttja: Fånga upp fel, reagera på rätt sätt.
- Loggning struktur: Sammanhang, rotation, varningar.
- Omgivningar tydligt åtskilda: DEBUG-flaggor och säkra standardvärden.
Produktionsfärdig PHP-felkonfiguration förklaras kortfattat
Jag låter alla meddelanden visas i utvecklingen eftersom jag Kodkvalitet säkra tidigt. På live-servrar stänger jag strikt av skärmen, men loggar allt så att jag kan Diagnos möjligt när som helst. Detta håller användargränssnitten rena, samtidigt som loggarna talar sanning. Synliga feltexter äventyrar sekretessen och kan avbryta funktionskedjor, vilket jag förhindrar med tydlig separation. Detta mönster ökar serverstabiliteten och gör svarstiderna förutsägbara.
php.ini: säkra standardvärden för live-trafik
För utvecklingsmiljöer aktiverar jag display_errors och ställa in fel_rapportering I produktionen stänger jag konsekvent av annonser men behåller omfattande rapportering och loggning. Blandningen skyddar användarna och håller min insikt i systemets beteende intakt. Jag definierar värdena centralt i php.ini och version additional ini snippets. Det ger mig reproducerbara driftsättningar och minimerar överraskningar i skarpt läge.
Följande tabell visar en jämförelse av typiska DEV- och PROD-inställningar för mer Öppenhet och tydlig Riktlinjer:
| Inställning | Utveckling | Produktion | Ledtråd |
|---|---|---|---|
| display_errors | På | Av | Undvik strikt visning i live-läge |
| display_startup_errors | På | Av | Gör startfelet synligt endast i DEV |
| fel_rapportering | E_ALL eller -1 | E_ALL (valfritt filter) | -1 täcker alla nivåer inklusive framtida nivåer |
| log_fel | På | På | Loggar är en obligatorisk källa för analys |
| fel_logg | Fil/sökväg | Fil/sökväg | Säker väg med rotation och rättigheter |
Så jag ställde in “display off, report on” i PROD och har fel_logg skriva allt till filer. Jag sätter också hårda filbehörigheter eftersom loggfiler ofta innehåller känsliga kontexter. Om du använder virtuella värdar eller containrar, separera sökvägar rent för varje applikation. Detta förenklar efterföljande korrelationer och påskyndar analyser av grundorsaker. Detta håller gränssnittet vänligt, samtidigt som jag får fullständiga spår i bakgrunden.
Finjustera felrapporteringsnivån utan att loggen översvämmas
Som standard använder jag i PROD E_ALL och eventuellt filtrera bakgrundsljud som meddelanden om de inte är av något värde. Ett ofta använt mönster är E_ALL & ~E_NOTICE & ~E_WARNING & ~E_DEPRECATED. Detta förhindrar brus, men fortsätter att fokusera på verkliga produktionsfel. Innan jag gör ändringar kontrollerar jag effekterna på genomströmning och latens eftersom en hel del loggning kostar IO. Om du vill förstå effekterna per nivå kan du hitta bakgrundsinformation på Felnivå och prestanda.
Jag följer principen “först fixa rent, sedan filtrera”, eftersom undertryckande bara skjuter upp problem. I migreringsfaser loggar jag DEPRECATED på ett synligt sätt för att tidigt upptäcka framtida avbrott. Jag markerar också kritiska felklasser separat så att larmen utlöses på ett tillförlitligt sätt. Detta underlättar analysarbetet och sparar tid vid felsökning. Resultatet är mindre brus och mer användbara data. Signaler.
Anpassad hanterare: fånga upp undantag, fel och avstängningar på ett snyggt sätt
Jag installerar mina egna hanterare med set_error_handler(), set_exception_handler() och registrera_avstängning_funktion(). Det är så jag fångar upp klassiska fel, undantag som inte fångats upp och fatala fel. Jag förser användarna med en neutral 500-sida och hela sammanhanget hamnar i loggen. På så sätt skyddas känsliga uppgifter och serverstabiliteten hålls hög. Samtidigt behåller jag kontrollen över format, fält och utdatakanaler.
<?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();I vardagen lägger jag till fält som request ID, user ID och session hash för att Korrelation för att göra det enklare. För API:er tillhandahåller jag en generisk felstruktur i PROD, t.ex. JSON med kod och ärende-ID. Detta gör att support kan starta omedelbart, medan intern information förblir dold. Jag kapslar också in IO runt loggrar så att ett defekt filsystem inte utlöser ytterligare fel. Detta undvikande av kaskadfel bidrar direkt till en lägre MTTR.
Strukturerad loggning: sammanhang, rotation, varningar
Bra loggning börjar med Sammanhang: tidsstämpel, typ, fil, rad och referens till begäran. Detta följs av disciplinen: rotationspolicy, behörigheter och lagring. Jag separerar apploggar och webbserverloggar för att få en snabb överblick. Jag utlöser kritiska klasser som E_ERROR i larmkanaler, t.ex. e-post eller chatt. Enligt blog.nevercodealone.de minskar en tydlig fellogg felsökningstiden med upp till 70 % - en kraftfull hävstång för verksamheten.
<?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;
});Jag kontrollerar loggstorleken dagligen eller automatiskt för att Minne för att skydda skivorna. Rotation med storleks- eller tidsbaserade regler förhindrar fulla skivor. Dessutom skriver jag valfritt i JSON-format så att parsers kan extrahera mätvärden. En strukturerad start hjälper till med utvärderingen; guiden till Analysera loggar användbara tankeställare. På så sätt kan jag snabbare känna igen avvikande värden och minimera risken för att flyga i blindo.
Konsekvent uppdelning av DEV, STAGE och PROD
Jag håller varje miljö med sin egen DEBUG-flagga och dedikerade ini åsidosättningar. Konfigurationsvärden hamnar i Env-variabler, inte i koden. Webbservern visar cache-rubriker i PROD, medan DEV är generöst avaktiverad. För STAGE speglar jag PROD-inställningarna men aktiverar ytterligare mätvärden. Den här disciplinen förhindrar överraskningar och ökar förutsägbarheten i driftsättningarna.
Namnen på loggfilerna skiljer sig åt beroende på miljö, så att jag kan Felbilder blanda inte. CI/CD sätter flaggorna före utrullningen så att inga mänskliga fel slinker in. Jag lägger till hälsokontroller för viktiga slutpunkter så att driftstopp uppmärksammas tidigt. Feature flags hjälper till att tillfälligt skydda riskfyllda vägar. På så sätt håller jag releaser förutsägbara och minskar riskerna för rollback.
Felsökning under körtid: När jag behöver göra en snabb kontroll
Ibland behöver jag en kort Insikt på en testinstans, till exempel omedelbart efter en hotfix. Sedan ställer jag tillfälligt in ini_set(‚display_errors‘, 1) och error_reporting(E_ALL) - men aldrig på riktig produktion. Jag loggar varje ändring, raderar den efteråt och gör inga commit. En kort testrunda med riktade förfrågningar är vanligtvis tillräckligt. Efter det återgår jag omedelbart till tysta loggar och neutrala felsidor.
För reproducerbara analyser kapslar jag in felsökningsflaggor bakom funktionsknappar som jag i tid begränsa. På så sätt förhindrar jag permanenta tillstånd och minskar risken. Om jag behöver gräva djupare förlitar jag mig på Xdebug i en isolerad DEV-miljö. Att mäta i stället för att gissa är fortfarande den vägledande principen. Det är det enda sättet för mig att upptäcka verkliga flaskhalsar och inte placebo.
Säker konfiguration av WordPress och ramverk
Med WordPress satte jag in PROD WP_DEBUG till false och omdirigera fel till loggar. I DEV använder jag WP_DEBUG_LOG och WP_DEBUG_DISPLAY specifikt för funktionsutveckling. Jag avaktiverar plugin-redaktörer i PROD så att inga kodändringar sker live. Cron-kontroll via systemets cronjobs minskar avvikelser och jämnar ut Belastningstoppar. För detaljer, den kompakta guiden till WordPress felsökningsläge.
Ramverk som Symfony eller Laravel tillhandahåller dedikerade ENV-flaggor och felsidor, vilket jag konsekvent använda. Jag använder centraliserade loggrar som Monolog med en kanalstruktur. För HTTP-svar i PROD skriver jag ut generiska feltexter och hänvisar internt till korrelationer. På så sätt förblir gränssnitten neutrala, men loggarna produktiva. Denna kombination ger ett märkbart bidrag till serverstabiliteten.
Säkerhetsaspekter: Vad får aldrig hamna i loggen
Jag filtrerar konsekvent HemligheterLösenord, tokens, kreditkortsfragment och personuppgifter. Maskeringen sker så tidigt som möjligt, till exempel på servicenivå före loggern. För felmeddelanden kontrollerar jag om innehållet innehåller filsökvägar, SQL eller interna IP-adresser. Jag skyddar eller anonymiserar allt som ökar attackytan. På så sätt förblir loggarna användbara utan att dataskydd eller säkerhet äventyras.
Jag sätter filbehörigheter restriktivt, och processer skriver bara till delade filer. Stigar. Jag aktiverar också loggrotation med komprimering så att gamla data inte ligger och skräpar. Jag håller en runbook redo för incidenter: Var hittar jag vilka spår, vilka team meddelar jag först. Den här förberedelsen sparar dyrbara minuter i hektiska situationer. I slutändan är det tiden fram till återställning som räknas.
Övervakning och alarmering utan felavfyrningar
Jag definierar tröskelvärden som kontextkänslig är: Enskilda varningar utlöser inget larm, men plötsliga toppar gör det. Tidsfönster, hastighetsgränser och deduplicering förhindrar att personsökaren tröttnar. Jag rapporterar kritiska klasser som E_ERROR, E_PARSE och återkommande timeouts omedelbart. För återkommande avvikelser planerar jag ärenden i stället för ad hoc-åtgärder. På så sätt förblir teamet handlingskraftigt och verkliga problem går inte obemärkta förbi.
Visualisering hjälper mig att känna igen mönster Känna igenDagliga cykler, toppar i distributionen, botvågor. Korrelationer mellan releasetider och felfrekvenser avslöjar orsaker. Jag lagrar runbooks direkt i larmtexter så att jourhavande kan agera omedelbart. Jag övervakar också beroenden som databaser och köer. En felström utan sammanhang ger sällan lösningar.
Checklista för driftsättning: Utrullning med få fel
Före varje utrullning kontrollerar jag Konfiguration, loggar, behörigheter och ledigt minne. Sedan genomför jag ett "smoke test" med de viktigaste slutpunkterna. Feature flags och canary releases minskar riskerna i händelse av större förändringar. Jag loggar driftsättningstider för att underlätta korrelationer senare. Jag planerar också bakvägar om en hotfix skulle gå fel.
För större uppdateringar flyttar jag skrivbördan under en kort tid och utför Beredskap-proberna är strängare. Detta inkluderar en kontroll av loggskrivbarhet och databasanslutningar. Jag kontrollerar också om 500 sidor visas korrekt och utan intern information. Dessa till synes små punkter förhindrar stora överraskningar. Detta gör utrullningarna tystare och mer begripliga.
FPM och webbserver: SAPI-specifikt skydd
Förutom php.ini sparar jag FPM-pooler hårt. För hela poolen ställer jag in display_errors till Off via php_admin_flag och upprätthåller därmed produktiva standardvärden även med felaktiga programöverskrivningar. Jag använder slowlog och request_terminate_timeout för att identifiera och begränsa hängningar innan de blockerar arbetare. Jag loggar också arbetarnas utgångar för att registrera sällsynta kantfall.
[www]
php_admin_flag[display_errors] = Av
php_admin_value[felrapportering] = E_ALL
php_admin_value[log_errors] = På
php_admin_value[minnesbegränsning] = 256M
catch_workers_output = ja
begäran_avsluta_timeout = 30s
slowlog = /var/log/php-fpm/www-slow.log
begäran_slowlog_timeout = 5sPå webbservernivå (nginx/Apache) aktiverar jag fastcgi_intercept_fel eller ProxyErrorOverride. Detta gör att webbservern kan leverera 50x statiska sidor om PHP misslyckas. Jag cachar ingen 5xx-svar, men jag hanterar 4xx-fel med korta TTL. En X-Request-ID-header genereras av webbservern och skickas vidare till PHP så att jag kan korrigera varje sökväg.
# nginx
error_page 500 502 503 504 /50x.html;
location = /50x.html { root /usr/share/nginx/html; internal; }
fastcgi_intercept_errors på;
add_header X-Request-Id $request_id alltid;
# Apache (utdrag)
FelDokument 500 /50x.html
ProxyErrorOverride PåI PROD inaktiverar jag också html_fel och exponera_php. Detta förhindrar HTML-formaterade felaktiga texter och läckor via PHP-versioner. Med ignorera_upprepade_fel och log_fel_max_len Jag håller loggstormar i schack utan att svälja verkliga signaler. Jag kör Opcache strikt nära produktionen, men ser till att felmeddelanden inte döljs av aggressiv revalidering.
Standardiserade felsvar för API:er och frontend
Jag standardiserar svarsschemat: Användarna ser generisk Texter, system tar emot strukturerade koder. 4xx-fel signalerar klientproblem (validering, auth), 5xx-fel står för serverproblem. Konsekvent mappning av undantag till HTTP-status förebygger missförstånd och underlättar övervakning.
[
'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 (Valideringsundantag $e) {
respondError(422, 'VALIDATION_FAILED', 'Inmatningen är ofullständig eller ogiltig');
} catch (NotFoundException $e) {
respondError(404, 'NOT_FOUND', 'Resursen hittades inte');
} catch (Throwable $e) {
error_log('UNHANDLED: '.$e->getMessage());
respondError(500, 'INTERNAL_ERROR', 'Ett internt fel har inträffat');
}För användargränssnitt har jag en ren 500-sida som inte visar någon intern information. Om jag lokaliserar felaktig text gör jag det endast för Allmänheten Meddelanden - interna detaljer finns kvar i loggar. Detta ökar kvaliteten på supporten och minskar antalet frågor.
Central insamling av loggar, provtagning och behållare
I moderna installationer vidarebefordrar jag loggar centralt till Syslog eller Journald. I containrar föredrar jag att skriva till stdout/stderr och överlåter rotation och leverans till plattformen. Jag undviker filbaserade loggar i containrar om inte en sidovagn roterar dem på ett tillförlitligt sätt. Jag använder mig av stickprov på ett kontrollerat sätt: När det gäller massor av liknande varningar registrerar jag representativa slumpmässiga urval och fortsätter att spara dem. varje kritisk klass i sin helhet.
Jag berikar loggraderna med deployment-hash, värd, pod/container-ID och miljö. Om den centrala avsändningen misslyckas buffrar jag lokalt och faller tillbaka till minimal loggning om det behövs för att inte blockera begäran. Nätverksproblem får inte vara Felkaskader på den kritiska vägen - stabilitet går före fullständighet.
Robust hantering av CLI, cron-jobb och arbetsprocesser
CLI-skript följer sina egna regler: Du behöver Utgångskoder, skriva till STDERR och får aldrig misslyckas i tysthet. Jag separerar deras loggar från webbförfrågningar och tillhandahåller backoff/retry-strategier för övergående fel. För långa jobb sätter jag medvetet minnesgränser och loggar mellanliggande statusar så att jag kan känna igen häng eller läckage.
<?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);
}Jag kapslar in cron-jobb med låsfiler eller distribuerade lås så att parallella starter inte leder till belastningstoppar och felsalvor. Jag planerar retry-fönster så att de inte krockar med trafiktoppar. Detsamma gäller här: rik på sammanhang Loggar slår alla stubbstackspårningar.
Fördjupning av dataskydd, lagring och maskering
Utöver att bara “inte logga” implementerar jag Regler för maskeringJag ersätter tokens och lösenord med platshållare, jag lagrar förkortade IP-adresser och jag pseudonymiserar personliga ID (hash med salt). För varje miljö definierar jag tydliga Kvarhållande-tider och radera gamla lager automatiskt. Exportvägar (t.ex. supportpaket) är också krypterade och kan nås på en rollbaserad basis.
Jag kontrollerar undantag för känsligt innehåll (SQL med tydliga värden, interna värdnamn). Jag utbildar team i att känna igen hjälpsamma, men neutral att formulera feltexter. Dataskyddet börjar i koden - loggern är bara den sista instansen, inte det första filtret.
Versioner, avskrivningar och migreringsfönster
För PHP-uppgraderingar beskriver jag ett migreringsfönster: I STAGE utvärderar jag E_DEPRECATED Jag loggar dem synligt i PROD, men utan att varna. Jag skiljer mellan avskrivningar från min kodbas och från tredjepartspaket och planerar fixar iterativt. Ett dedikerat testfall säkerställer att avskrivningar inte förorenar användargränssnittet och hamnar uteslutande i loggar.
Jag har också en Kompatibilitetsmatris redo för förlängningar. Om komponenterna tillfälligt avviker från varandra stryper jag loggvolymen på ett målinriktat sätt utan att för den skull avaktivera kritiska klasser. Målet är alltid att åtgärda saker på ett rent sätt, inte att dölja dem.
SLO:er, felbudgetar och finstyrning av larm
Jag mäter inte bara absoluta saknade tal, utan definierar också Felprocent SLO per slutpunkt. Jag härleder utplaceringsfrekvensen och bevakningsläget från felbudgeten: om budgeten är snäv ökar jag försiktigheten, aktiverar provtagningen mer strikt och prioriterar kvalitetsarbete. Jag avduplicerar larm baserat på tid och grupperar dem efter orsak (samma stackspårning, samma slutpunkt) så att On-Call kan fortsätta att agera.
Webserverns felsidor, FPM-fel och cachningsfällor
Om FPM går ner eller levererar 502/504, kommer statisk 50x-sidan som en pålitlig reserv. Den här sidan innehåller varken bygginformation eller interna länkar, utan tydliga instruktioner för användare och supportkontakter. Jag ser till att CDN:er och omvända proxyer inte cachar 5xx och respekterar Retry-After-rubriker. För underhållsfönster skickar jag 503 med Retry-After, inte 500, och håller underhållssidor utanför PHP.
För förfrågningar med JSON-acceptans erbjuder jag valfritt ett minimalt JSON-felsvar från webbservern för 5xx så att klienter inte stöter på ingenting. Samtidigt undviker jag att webbservern avslöjar interna sökvägar eller moduler - säkerhet går också före bekvämlighet när det gäller fallback.
Praktisk sammanfattning
Jag skiljer konsekvent på DEV och PROD, stänger av annonser i Live och log komplett. Anpassade handlers ger mig kontroll över reaktion och sammanhang. En tydlig felnivå, förnuftiga filter och ren rotation minskar bruset. Säkerhetsfilter skyddar hemligheter, medan larm bara utlöses vid verkliga problem. På så sätt blir gränssnittet tyst, loggarna talar klarspråk och serverstabiliteten ökar märkbart.
Om du följer detta upplägg kommer du bort från brandbekämpning mot prediktiv drift. Driftsättningar blir beräkningsbara, störningar kortare och analyser upprepningsbara. Det är just därför som det lönar sig att investera i en ren konfiguration. Jag tillämpar dessa principer i varje projekt och sover bättre. Produktion behöver inte magi, den behöver tydliga regler och disciplinerad implementering.
