Monitoreo y registro de aplicaciones PHP: cómo no pasar por alto un error

Su aplicación PHP no habla, le gritan

Imagínese que es el capitán de una nave espacial. Su tarea es llegar a Marte. Pero la nave no tiene instrumentos, ni sensores, ni siquiera un botón de "alarma de emergencia". Simplemente vuela, esperando lo mejor. Así más o menos se siente un desarrollador que lanza una aplicación PHP a producción sin monitoreo ni registro.

Los usuarios ven "500 Internal Server Error", y usted solo ve una pantalla vacía de logs. ¿Le suena familiar? Si no es así, o es un genio o simplemente aún no se ha enfrentado a la caída de un servidor en producción a las 3 de la madrugada.

En este artículo, analizaremos cómo convertir su aplicación PHP de una "caja negra" en un sistema transparente que le cuente por sí mismo dónde y por qué falló. Le mostraré código real, mejores prácticas y herramientas que se utilizan en producción en proyectos grandes. ¡Allá vamos!

Por qué el registro en PHP no es solo un "echo"

Muchos principiantes piensan que el registro es:

echo "Aquí hay un error: " . $error;

Spoiler: esto no funciona en producción. El usuario verá esa "belleza" en la pantalla. Y si el error es fatal, usted no se enterará de nada.

El registro real es la recopilación estructurada de datos que se pueden analizar, buscar y a los que se puede reaccionar en tiempo real. PHP proporciona funciones básicas (error_log(), syslog()), pero en el mundo moderno esto no es suficiente.

¿Qué debe tener un buen log?

\n
• Nivel de gravedad — DEBUG, INFO, WARNING, ERROR, CRITICAL
\n
• Marca de tiempo — hora exacta del evento (preferiblemente en UTC)
\n
• Contexto — ID de usuario, IP, URL, datos de la solicitud
\n
• Stack de llamadas — trace del error
\n
• Identificador único de solicitud — para vincular todos los logs de una misma acción
\n

Monolog — el estándar de registro en PHP

Si escribe en PHP y no usa Monolog — está perdiendo el tiempo. Es el estándar de facto para el registro, compatible con Symfony, Laravel y la mayoría de los frameworks modernos.

¿Por qué Monolog es genial?

\n
• "Handlers" flexibles — se puede escribir en archivo, BD, Telegram, Slack, email
\n
• Formateadores — JSON, HTML, Syslog
\n
• Procesadores — añaden contexto automáticamente
\n

Instalación y ejemplo básico

composer require monolog/monolog

Ahora escribamos un logger simple:

<?php\nrequire 'vendor/autoload.php';\n\nuse Monolog\\Logger;\nuse Monolog\\Handler\\StreamHandler;\nuse Monolog\\Handler\\TelegramBotHandler;\nuse Monolog\\Level;\n\n// Creamos el logger con nombre de canal\n$log = new Logger('my_app');\n\n// Escribimos en archivo\n$log->pushHandler(\n    new StreamHandler(__DIR__ . '/logs/app.log', Level::Debug)\n);\n\n// Errores críticos — a Telegram\n$log->pushHandler(\n    new TelegramBotHandler(\n        'YOUR_BOT_TOKEN',\n        'YOUR_CHAT_ID',\n        Level::Critical\n    )\n);\n\n// Usamos\n$log->info('Usuario inició sesión', ['user_id' => 123]);\n$log->error('Base de datos no disponible', ['db_host' => 'localhost']);

Tenga en cuenta: usamos diferentes handlers para diferentes niveles. En el archivo se escribe todo (depuración), y a Telegram solo lo crítico. Esto permite no saturar con notificaciones, pero no pasar por alto un problema real.

Monitoreo de PHP: cómo ver lo que está oculto

El registro es la recopilación pasiva de datos. El monitoreo es la observación y notificación activa. Si un usuario le informa de un error — ya llegó tarde. Un buen monitoreo le alertará antes de que el problema afecte a los usuarios.

Sentry — imprescindible para el desarrollador PHP

Sentry es un sistema de seguimiento de errores en tiempo real. Captura excepciones, recopila contexto, stack de llamadas e incluso datos de sesión.