Saltar para o conteúdo 
Vou mostrar-lhe a configuração pronta para produção para Hospedagem com tratamento de erros PHPdesde as predefinições do php.ini e estratégias de registo até aos manipuladores personalizados para respostas limpas. É assim que eu mantenho erros de produção da interface do utilizador, proteger informações sensíveis e aumentar a estabilidade do servidor em funcionamento.
Pontos centrais
- php.ini desligar: DEV mostra tudo, PROD regista discretamente.
- Nível de erro filtro fino: Concentrar-se nos defeitos de produção genuínos.
- Manipulador personalizado utilizar: Intercetar erros, reagir de forma limpa.
- Registo estrutura: Contexto, rotação, alertas.
- Arredores claramente separados: sinalizadores DEBUG e predefinições seguras.
Breve explicação da configuração de erros do PHP pronta para produção
Deixo que todas as mensagens apareçam no desenvolvimento porque Qualidade do código seguro desde cedo. Nos servidores em direto, desligo rigorosamente o ecrã, mas registo tudo para poder Diagnóstico possível em qualquer altura. Isto mantém as interfaces de utilizador limpas, enquanto os registos dizem a verdade. Os textos de erro visíveis põem em causa a confidencialidade e podem interromper cadeias de funções; evito-o com uma separação clara. Este padrão aumenta a estabilidade do servidor e mantém os tempos de resposta previsíveis.
php.ini: predefinições seguras para tráfego em direto
Para ambientes de desenvolvimento, ativo exibir_erros e definir relatório de erros Na produção, desligo constantemente os anúncios, mas mantenho relatórios e registos abrangentes. Esta combinação protege os utilizadores e mantém intacta a minha visão do comportamento do sistema. Defino os valores de forma centralizada no php.ini e nos snippets adicionais da versão ini. Isto dá-me implementações reproduzíveis e minimiza as surpresas no funcionamento em tempo real.
A tabela a seguir mostra uma comparação das configurações DEV e PROD típicas para mais Transparência e claro Diretrizes:
| Definição | Desenvolvimento | Produção | Nota |
|---|---|---|---|
| exibir_erros | On | Desligado | Evitar rigorosamente a visualização em modo direto |
| display_startup_errors | On | Desligado | Tornar o erro de arranque visível apenas no DEV |
| relatório de erros | E_ALL ou -1 | E_ALL (filtro facultativo) | -1 abrange todos os níveis, incluindo os futuros níveis |
| erros_de_log | On | On | Os registos são uma fonte obrigatória para análise |
| registo de erros | Ficheiro/Path | Ficheiro/Path | Caminho seguro com rotação e direitos |
Por isso, defino “display off, report on” no PROD e tenho registo de erros escrever tudo em ficheiros. Também defino permissões de ficheiro rígidas porque os ficheiros de registo contêm frequentemente contextos sensíveis. Se utilizar anfitriões virtuais ou contentores, separe os caminhos de forma limpa para cada aplicação. Isso simplifica as correlações subsequentes e acelera as análises de causa raiz. Isto mantém a interface do utilizador amigável, enquanto eu obtenho traços completos em segundo plano.
Ajuste fino do nível de comunicação de erros sem inundação de registos
Por defeito, utilizo em PROD E_ALL e, opcionalmente, filtrar ruídos de fundo, como avisos, se não tiverem valor. Um padrão frequentemente utilizado é E_ALL & ~E_NOTICE & ~E_WARNING & ~E_DEPRECATED. Isto evita o ruído, mas continua a concentrar-se nos verdadeiros erros de produção. Antes de fazer alterações, verifico os efeitos no débito e na latência, porque muito registo custa IO. Se quiser entender os efeitos por nível, você pode encontrar informações básicas em Nível de erro e desempenho.
Defendo o princípio de “primeiro corrigir corretamente, depois filtrar”, uma vez que a supressão apenas adia os problemas. Para as fases de migração, registo DEPRECATED de forma visível para reconhecer antecipadamente futuras quebras. Também marco separadamente as classes de erros críticos para que os alarmes disparem de forma fiável. Isto beneficia os caminhos de análise e poupa-me tempo na resolução de problemas. O resultado é menos ruído e mais dados utilizáveis. Sinais.
Manipulador personalizado: intercepta de forma limpa excepções, erros e encerramentos
Eu instalo os meus próprios manipuladores com set_error_handler(), set_exception_handler() e register_shutdown_function(). É assim que apanho os erros clássicos, as excepções não capturadas e os erros fatais. Forneço aos utilizadores uma página 500 neutra, e o contexto completo acaba no registo. Isto protege os detalhes sensíveis e mantém a estabilidade do servidor elevada. Ao mesmo tempo, mantenho o controlo sobre o formato, os campos e os canais de saída.
<?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();No dia a dia, adiciono campos como o ID do pedido, o ID do utilizador e o hash da sessão para Correlação para o tornar mais fácil. Para APIs, forneço uma estrutura de erro genérica no PROD, como JSON com código e ID do ticket. Isso permite que o suporte comece imediatamente, enquanto as informações internas permanecem ocultas. Também encapsulo o IO em torno dos registadores para que um sistema de ficheiros defeituoso não provoque mais erros. Esta prevenção em cascata contribui diretamente para um MTTR mais baixo.
Registo estruturado: contexto, rotação, alertas
Um bom registo começa com Contexto: registo de data e hora, tipo, ficheiro, linha e referência do pedido. Segue-se a disciplina: política de rotação, permissões e retenção. Separo os registos de aplicações e os registos do servidor Web para manter uma visão geral rápida. Acciono classes críticas, como E_ERROR, em canais de alarme, como o correio eletrónico ou o chat. De acordo com o blog.nevercodealone.de, um registo de erros claro reduz o tempo de depuração até 70 % - uma poderosa alavanca para as operações.
<?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;
});Verifico o tamanho do registo diariamente ou automaticamente para Memória para proteger os discos. A rotação com regras baseadas no tamanho ou no tempo impede que os discos fiquem cheios. Além disso, escrevo opcionalmente em formato JSON para que os analisadores possam extrair métricas. Um início estruturado ajuda na avaliação; o guia para Analisar os registos úteis para a reflexão. Isto permite-me reconhecer mais rapidamente os valores anómalos e minimizar o risco de ficar às cegas.
Separação consistente de DEV, STAGE e PROD
Mantenho cada ambiente com a sua própria Bandeira DEBUG e substituições de ini dedicadas. Os valores de configuração acabam em variáveis Env, não no código. O servidor web mostra cabeçalhos de cache em PROD, enquanto DEV é generosamente desativado. Para o STAGE, eu espelho as configurações do PROD, mas habilito métricas adicionais. Esta disciplina evita surpresas e aumenta a previsibilidade das implementações.
Os nomes dos ficheiros de registo diferem consoante o ambiente, para que eu possa Imagens de erros não se misturam. A CI/CD define as bandeiras antes do lançamento para que não haja erros humanos. Acrescento verificações de saúde para os principais pontos finais, para que os tempos de inatividade sejam notados desde o início. Os sinalizadores de funcionalidades ajudam a proteger temporariamente os caminhos de risco. Desta forma, mantenho os lançamentos previsíveis e reduzo os riscos de reversão.
Depuração em tempo de execução: Quando preciso de verificar rapidamente
Por vezes, preciso de uma pequena Visão numa instância de teste, por exemplo, imediatamente após um hotfix. Depois defino temporariamente ini_set(‚display_errors‘, 1) e error_reporting(E_ALL) - mas nunca em produção real. Registo todas as alterações, elimino-as depois e não as submeto a commit. Uma pequena ronda de testes com pedidos específicos é normalmente suficiente. Depois disso, volto imediatamente aos registos silenciosos e às páginas de erro neutras.
Para análises reprodutíveis, encapsulo os sinalizadores de depuração por detrás de alternâncias de funcionalidades que no tempo limite. Desta forma, evito estados permanentes e reduzo o risco. Se precisar de ir mais fundo, confio no Xdebug num ambiente DEV isolado. Medir em vez de adivinhar continua a ser o princípio orientador. É a única forma de reconhecer os verdadeiros estrangulamentos e não os placebos.
Configurar o WordPress e as estruturas de forma segura
Com o WordPress, defino em PROD WP_DEBUG para falso e redirecionar os erros para os registos. No DEV, utilizo WP_DEBUG_LOG e WP_DEBUG_DISPLAY especificamente para o desenvolvimento de funcionalidades. Desactivo os editores de plugins em PROD para que não haja alterações de código em tempo real. O controlo do Cron através dos cronjobs do sistema reduz os outliers e suaviza Picos de carga. Para mais pormenores, o guia compacto do Modo de depuração do WordPress.
Estruturas como o Symfony ou o Laravel fornecem sinalizadores ENV dedicados e páginas de erro, que eu coerente utilização. Utilizo registadores centralizados, como o Monolog, com uma estrutura de canais. Para as respostas HTTP no PROD, emito textos de erro genéricos e remeto internamente para correlações. Desta forma, as interfaces permanecem neutras, mas os registos permanecem produtivos. Esta combinação contribui de forma notável para a estabilidade do servidor.
Aspectos de segurança: O que nunca deve ir parar ao registo
Filtro de forma consistente SegredosPalavras-passe, tokens, fragmentos de cartões de crédito e dados pessoais. O mascaramento é efectuado o mais cedo possível, por exemplo, ao nível do serviço, antes do registo. No caso das mensagens de erro, verifico se o conteúdo contém caminhos de ficheiros, SQLs ou IPs internos. Protejo ou anonimo tudo o que aumenta a superfície de ataque. Desta forma, os registos continuam a ser úteis sem pôr em causa a proteção ou a segurança dos dados.
Defino as permissões dos ficheiros de forma restritiva e os processos só escrevem em ficheiros partilhados. Caminhos. Também ativo a rotação de registos com compressão para que os dados antigos não fiquem à solta. Mantenho um plano de ação pronto para os incidentes: Onde encontro que vestígios, que equipas devo notificar primeiro. Esta preparação poupa minutos preciosos em situações agitadas. No final, o que conta é o tempo até à recuperação.
Monitorização e alarme sem falhas de ignição
Defino valores-limite que sensível ao contexto são: Os avisos individuais não accionam um alarme, mas os picos súbitos sim. Janelas de tempo, limites de taxa e deduplicação evitam a fadiga do pager. Comunico imediatamente classes críticas como E_ERROR, E_PARSE e timeouts recorrentes. No caso de anomalias recorrentes, planeio bilhetes em vez de medidas ad hoc. Desta forma, a equipa continua a ser capaz de agir e os problemas reais não passam despercebidos.
A visualização ajuda-me a reconhecer padrões ReconhecerCiclos diários, picos de implantação, ondas de bots. As correlações entre os tempos de lançamento e as taxas de erro revelam as causas. Guardo os runbooks diretamente nos textos de alarme para que o pessoal de serviço possa agir imediatamente. Também monitorizo as dependências, como bases de dados e filas de espera. Um fluxo de erros sem contexto raramente fornece soluções.
Lista de controlo da implementação: Implementação com poucos erros
Antes de cada lançamento, verifico Configuração, registos, permissões e memória livre. Em seguida, realizo um teste de fumaça com os pontos de extremidade mais importantes. Os sinalizadores de funcionalidades e as versões canário reduzem os riscos no caso de grandes alterações. Registo os tempos de implementação para facilitar as correlações posteriores. Também planeio caminhos alternativos para o caso de uma correção de emergência correr mal.
Para actualizações maiores, transfiro a carga de escrita durante um curto período de tempo e faço Prontidão-As sondas são mais rigorosas. Isto inclui uma verificação da capacidade de escrita do registo e das ligações à base de dados. Também verifico se 500 páginas aparecem corretamente e sem informação interna. Estes pontos, aparentemente pequenos, evitam grandes surpresas. Isto torna os lançamentos mais silenciosos e mais compreensíveis.
FPM e servidor Web: proteção específica SAPI
Para além do php.ini, guardo o ficheiro Piscinas FPM difícil. Em todo o grupo, eu defino display_errors como Off via php_admin_flag e, assim, aplico padrões produtivos mesmo com substituições de aplicativos defeituosos. Eu uso slowlog e request_terminate_timeout para identificar e limitar travamentos antes que eles bloqueiem os workers. Eu também registo as saídas dos workers para registrar casos raros.
[www]
php_admin_flag[mostrar_erros] = Desligado
php_admin_value[relatório_de_erros] = E_ALL
php_admin_value[log_errors] = Ligado
php_admin_value[memory_limit] = 256M
catch_workers_output = sim
request_terminate_timeout = 30s
slowlog = /var/log/php-fpm/www-slow.log
request_slowlog_timeout = 5sAo nível do servidor Web (nginx/Apache), ativo fastcgi_intercept_errors ou ProxyErrorOverride. Isso permite que o servidor web forneça 50x páginas estáticas se o PHP falhar. Eu faço cache nenhum Respostas 5xx, mas eu trato os erros 4xx com TTLs curtos. Um cabeçalho X-Request-ID é gerado pelo servidor web e passado para o PHP para que eu possa corrigir cada caminho.
# 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 (excerto)
ErrorDocument 500 /50x.html
ProxyErrorOverride OnNo PROD também desactivei erros_de_horário e expor_php. Isto evita textos incorrectos formatados em HTML e fugas através de versões PHP. Com ignorar_erros_repetidos e log_errors_max_len Mantenho as tempestades de registos sob controlo sem engolir sinais reais. Executo a Opcache estritamente perto da produção, mas certifico-me de que as mensagens de erro não são ocultadas por uma revalidação agressiva.
Respostas de erro normalizadas para APIs e front-ends
Normalizo o esquema de resposta: os utilizadores vêem genérico Os textos e os sistemas recebem códigos estruturados. Os erros 4xx assinalam problemas do cliente (validação, autenticação), os erros 5xx representam problemas do servidor. Um mapeamento coerente das excepções ao estado HTTP evita mal-entendidos e facilita o controlo.
[
'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', 'Entrada incompleta ou inválida');
} catch (NotFoundException $e) {
respondError(404, 'NOT_FOUND', 'Recurso não encontrado');
} catch (Throwable $e) {
error_log('UNHANDLED: '.$e->getMessage());
respondError(500, 'INTERNAL_ERROR', 'Ocorreu um erro interno');
}Para as interfaces de utilizador, mantenho uma página 500 limpa que não apresenta qualquer informação interna. Se localizar texto incorreto, faço-o apenas para Público Mensagens - os detalhes internos permanecem nos registos. Isto aumenta a qualidade do apoio e reduz as consultas.
Recolha central de registos, amostragem e contentores
Em configurações modernas, eu encaminho os logs centralmente para o Syslog ou Journald. Em containers, eu prefiro escrever para stdout/stderr e deixar a rotação e o envio para a plataforma. Evito registos baseados em ficheiros em contentores, a menos que um sidecar os faça rodar de forma fiável. Utilizo a amostragem de forma controlada: No caso de grandes quantidades de avisos semelhantes, registo amostras aleatórias representativas e continuo a guardá-las. cada classe crítica na sua totalidade.
Enriqueço as linhas de registo com hash de implementação, anfitrião, ID de pod/contentor e ambiente. Se o envio central falhar, coloco o buffer localmente e recuo para o registo mínimo, se necessário, para não bloquear o pedido. Os problemas de rede não devem ser Cascatas de erros no caminho crítico - a estabilidade tem precedência sobre a exaustividade.
Manuseamento robusto de CLI, tarefas cron e processos de trabalho
Os scripts CLI seguem as suas próprias regras: É necessário Códigos de saída, escrevem para STDERR e nunca devem falhar silenciosamente. Separo os seus registos dos pedidos Web e prevejo estratégias de retrocesso/repetição para erros transitórios. Para trabalhos longos, estabeleço deliberadamente limites de memória e registo os estados intermédios para poder reconhecer interrupções ou fugas.
<?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);
}Encapsulo as tarefas cron com ficheiros de bloqueio ou bloqueios distribuídos para que os arranques paralelos não conduzam a picos de carga e a salvas de erros. Planeio janelas de repetição para que não colidam com picos de tráfego. O mesmo se aplica aqui: rico em contexto Os registos superam qualquer rastreio de pilha de stub.
Aprofundar a proteção, o armazenamento e o mascaramento de dados
Para além de apenas “não registar”, implemento Regras de máscaraSubstituo os tokens e as palavras-passe por marcadores de posição, guardo IPs encurtados e pseudonimizo as IDs pessoais (hash com sal). Para cada ambiente, defino claramente Retenção-e eliminar automaticamente as existências antigas. Os caminhos de exportação (por exemplo, pacotes de suporte) também são encriptados e podem ser acedidos com base em funções.
Verifico se as excepções têm conteúdo sensível (SQL com valores claros, nomes de anfitriões internos). Instruo as equipas a reconhecerem as excepções úteis, mas neutro para formular textos de erro. A proteção dos dados começa no código - o registador é apenas a última instância, não o primeiro filtro.
Versões, depreciações e janelas de migração
Para actualizações de PHP, descrevo uma janela de migração: Em STAGE I, avalio E_DEPRECATED Registo-as visivelmente no PROD, mas sem alertar. Diferencio as depreciações da minha base de código e dos pacotes de terceiros e planeio as correcções de forma iterativa. Um caso de teste dedicado garante que as depreciações não poluem a IU e acabam exclusivamente em registos.
Também sou titular de um Matriz de compatibilidade pronto para extensões. Se os componentes divergirem temporariamente, reduzo o volume de registos de uma forma direcionada, sem desativar as classes críticas. O objetivo é sempre corrigir as coisas de forma limpa, não escondê-las.
SLOs, orçamentos de erros e controlo fino de alarmes
Não só meço os números absolutos em falta, como também defino Taxa de erro SLOs por ponto final. Derivo a frequência de implementação e o modo de vigilância do orçamento de erros: se o orçamento for apertado, aumento a cautela, ativo a amostragem de forma mais rigorosa e dou prioridade ao trabalho de qualidade. Desduplico os alarmes com base no tempo e agrupo-os de acordo com a causa (mesmo stack trace, mesmo endpoint) para que o On-Call continue a ser capaz de atuar.
Páginas de erro do servidor Web, falhas do FPM e armadilhas de cache
Se o FPM descer ou entregar 502/504, o estático 50x como uma alternativa fiável. Esta página não contém informações de compilação nem ligações internas, mas sim instruções claras para os utilizadores e contactos de apoio. Certifico-me de que os CDNs e os proxies inversos não armazenam em cache 5xx e respeitam os cabeçalhos Retry-After. Para janelas de manutenção, envio 503 com Retry-After, não 500, e mantenho as páginas de manutenção fora do PHP.
Para pedidos com aceitação de JSON, ofereço opcionalmente uma resposta de erro JSON mínima do servidor Web para 5xx, para que os clientes não se deparem com nada. Ao mesmo tempo, evito que o servidor Web revele caminhos ou módulos internos - a segurança também tem precedência sobre a conveniência quando se trata de fallback.
Resumo prático
Separo sistematicamente o DEV e o PROD, desligo os anúncios no Live e registo completo. Os manipuladores personalizados permitem-me controlar a reação e o contexto. Um nível de erro claro, filtros sensatos e uma rotação limpa reduzem o ruído. Os filtros de segurança protegem os segredos, enquanto os alarmes só disparam em caso de problemas reais. Isto mantém a interface silenciosa, os registos falam uma linguagem simples e a estabilidade do servidor aumenta visivelmente.
Se seguir este esquema, afasta-se da extinção de incêndios em direção a uma operação preditiva. As implementações tornam-se calculáveis, as interrupções mais curtas e as análises repetíveis. É precisamente por isso que vale a pena investir numa configuração limpa. Implemento estes princípios em todos os projectos e durmo mais descansado. A produção não precisa de magia, precisa de regras claras e de uma implementação disciplinada.
