Registro en aplicaciones PHP: mejores prácticas y herramientas

Introducción: Por qué el logging es la base de una aplicación PHP confiable

El logging (log) es el proceso de registrar eventos que ocurren en una aplicación en un diario especial (archivo de log). Para un desarrollador PHP, un logging adecuado no es solo un "plus en el karma", sino una necesidad. Sin él, la depuración de errores en producción se convierte en una adivinanza, y el monitoreo del rendimiento se vuelve imposible. Un logging mal configurado puede provocar la fuga de datos sensibles o, por el contrario, la pérdida de información críticamente importante.

En este artículo, analizaremos las mejores prácticas de logging en PHP: desde la elección de la biblioteca y los niveles de logging hasta la estructuración de mensajes y la seguridad. Aprenderá cómo convertir echo y var_dump dispersos en un sistema de monitoreo profesional.

1. Elección de la biblioteca: PSR-3 y Monolog

En la comunidad PHP moderna, el estándar de facto es la interfaz Psr\\Log\\LoggerInterface (PSR-3). Define 8 métodos para diferentes niveles de logging: emergency, alert, critical, error, warning, notice, info, debug.

La implementación más popular de PSR-3 es la biblioteca Monolog. Es flexible, potente y compatible con prácticamente todos los frameworks modernos (Laravel, Symfony, Yii2).

Instalación de Monolog a través de Composer

composer require monolog/monolog

Ejemplo básico de uso

<?phprequire 'vendor/autoload.php';

use Monolog\\Logger;use Monolog\\Handler\\StreamHandler;

// Creamos un logger con nombre de canal (ejemplo: 'my_app')$log = new Logger('my_app');// Agregamos un handler: escribimos en un archivo, nivel - INFO y superior$log->pushHandler(new StreamHandler(__DIR__ . '/app.log', Logger::INFO));

// Registramos mensajes$log->info('Usuario inició sesión', ['user_id' => 123]);$log->warning('Contraseña incorrecta', ['attempts' => 3]);$log->error('Error de conexión a la BD', ['exception' => $e->getMessage()]);?>

Tenga en cuenta: el segundo argumento es el contexto (context). En él se pueden pasar datos adicionales: ID de usuario, IP, stack trace, etc. Nunca concatene datos en la cadena del mensaje — use el contexto.

2. Niveles de logging y filtrado

Usar los niveles correctos es la base de un log legible. La regla general: cuanto mayor es el nivel, menos mensajes. Aquí hay una breve chuleta:

• DEBUG (100) — información de depuración para desarrollo. En producción suele estar desactivado.
• INFO (200) — eventos importantes: usuario se registró, pedido creado.
• NOTICE (250) — eventos normales pero significativos.
• WARNING (300) — situación anómala, pero la aplicación continúa funcionando (ejemplo: intento de inicio de sesión fallido).
• ERROR (400) — error que requiere intervención (no se pudo guardar el archivo).
• CRITICAL (500) — error crítico (base de datos no disponible).
• ALERT (550) — se requiere acción inmediata.
• EMERGENCY (600) — el sistema no funciona.

Filtrado en diferentes entornos

En producción no es necesario escribir mensajes DEBUG — crean carga adicional en el disco y dificultan la búsqueda de registros importantes. Use diferentes handlers para diferentes entornos:

<?phpuse Monolog\\Logger;use Monolog\\Handler\\StreamHandler;use Monolog\\Handler\\FingersCrossedHandler;

$log = new Logger('app');

if (getenv('APP_ENV') === 'production') {    // En producción escribimos solo WARNING y superior    $log->pushHandler(new StreamHandler('/var/log/app/error.log', Logger::WARNING));    // FingersCrossedHandler: almacena en búfer todo, pero escribe solo en caso de error    $log->pushHandler(new FingersCrossedHandler(        new StreamHandler('/var/log/app/critical.log', Logger::CRITICAL)    ));} else {    // En desarrollo escribimos todo    $log->pushHandler(new StreamHandler(__DIR__ . '/dev.log', Logger::DEBUG));}?>