Monitoreo y logging de aplicaciones PHP: cómo no perderte un bug

Si tu aplicación está en silencio, es una mala señal

¿Alguna vez te has enterado de un bug en producción por un usuario furioso? Si es así, sabes lo doloroso que es. Si no, has tenido suerte (por ahora).

PHP es el lenguaje que impulsa el 78% de los sitios web del mundo. Pero tiene una peculiaridad: es demasiado "silencioso". Por defecto, PHP simplemente se traga el error, muestra una página en blanco o, peor aún, sigue funcionando con datos incorrectos. Sin un sistema de monitoreo y logging, estás operando a ciegas.

En este artículo, veremos cómo transformar tu aplicación PHP de una "caja negra" a un sistema transparente, donde cada error, cada consulta lenta y cada acción sospechosa queden registrados. ¡Allá vamos!

¿Por qué "echo $error" no es logging?

Muchos desarrolladores novatos escriben:

try {\n    // algún código\n} catch (Exception $e) {\n    echo $e->getMessage();\n}\n

Eso no es logging. Es un grito en el vacío. Mostrar el error en el navegador no se guarda, no se estructura y no te da ningún análisis. El logging real te permite:

\n
• Ver el error 5 minutos después de que ocurra
\n
• Saber en qué servidor y entorno sucedió
\n
• Filtrar entre miles de registros para encontrar el que buscas
\n
• Recibir una notificación en Telegram/Slack si algo se rompe
\n

Pasemos a las herramientas que hacen esto posible.

Monolog: el estándar de facto para PHP

Si programas en PHP y no usas Monolog, probablemente estés reinventando la rueda. Esta librería se ha convertido en el estándar para logging en PHP (Laravel y Symfony la usan internamente).

Instalación y ejemplo básico

composer require monolog/monolog\n

<?php\nuse Monolog\\Logger;\nuse Monolog\\Handler\\StreamHandler;\n\n// Creamos un canal de logs\n$log = new Logger('mi_app');\n// Escribimos en el archivo /var/log/mi_app.log\n$log->pushHandler(new StreamHandler('/var/log/mi_app.log', Logger::WARNING));\n\n// Lo usamos\n$log->warning('Esto es una advertencia');\n$log->error('Error crítico: base de datos no disponible');\n

Ya es mejor. Pero Monolog puede mucho más. Puedes enviar logs a diferentes destinos al mismo tiempo:

\n
• A un archivo — para depuración local
\n
• A Elasticsearch — para búsquedas avanzadas
\n
• A Telegram/Slack — para alertas urgentes
\n
• A Syslog — para administración del sistema
\n

Ejemplo avanzado con múltiples manejadores

<?php\nuse Monolog\\Logger;\nuse Monolog\\Handler\\StreamHandler;\nuse Monolog\\Handler\\TelegramBotHandler;\nuse Monolog\\Handler\\ElasticsearchHandler;\nuse Monolog\\Formatter\\LineFormatter;\n\n$log = new Logger('produccion');\n\n// Todos los errores se guardan en un archivo\n$fileHandler = new StreamHandler('/var/log/app.log', Logger::DEBUG);\n$log->pushHandler($fileHandler);\n\n// Los errores críticos van directo a Telegram\n$telegramHandler = new TelegramBotHandler(\n    'TU_TOKEN_DEL_BOT', \n    'TU_ID_DE_CHAT', \n    Logger::CRITICAL\n);\n$telegramHandler->setFormatter(new LineFormatter(\n    "[%datetime%] %channel%.%level_name%: %message% %context%\\n"\n));\n$log->pushHandler($telegramHandler);\n\n// Logueamos\n$log->critical('La base de datos falló', ['servidor' => gethostname()]);\n

Ahora, si la base de datos cae en la madrugada, te enterarás por una notificación en tu teléfono. No a la mañana siguiente por un cliente.

Sentry: monitoreo de errores con contexto

Monolog escribe logs excelentes, pero cuando hay muchos errores, leer archivos se vuelve un infierno. Aquí entra Sentry, un sistema de recolección de errores con interfaz web.

Sentry recopila automáticamente:

\n
• El stack trace (rastreo de llamadas)
\n
• Los datos de la solicitud (URL, cabeceras, cuerpo)
\n
• Información del usuario (si se la proporcionas)
\n
• El estado de las variables