Tabla de contenidos
- 44.1. Resumen
- 44.2. Writers
- 44.2.1. Escritura en Streams
- 44.2.2. Escritura en bases de datos
- 44.2.3. Escritura en Firebug
- 44.2.4. Escritura por correo electrónico
- 44.2.5. Escritura en el log del sistema
- 44.2.6. Escritura en el Zend Server Monitor
- 44.2.7. Anular el Writer (stub)
- 44.2.8. Pruebas con el Mock
- 44.2.9. Composición de Writers
- 44.3. Formatters
- 44.4. Filters
- 44.5. Uso de la Factory para crear un Log
- 44.5.1. Opciones de Writer
- 44.5.1.1. Opciones de Zend_Log_Writer_Db
- 44.5.1.2. Opciones de Zend_Log_Writer_Firebug
- 44.5.1.3. Opciones de Zend_Log_Writer_Mail
- 44.5.1.4. Opciones de Zend_Log_Writer_Mock
- 44.5.1.5. Opciones de Zend_Log_Writer_Null
- 44.5.1.6. Opciones de Zend_Log_Writer_Stream
- 44.5.1.7. Opciones de Zend_Log_Writer_Syslog
- 44.5.1.8. Opciones de Zend_Log_Writer_ZendMonitor
- 44.5.2. Opciones de Filter
- 44.5.3. Creación de Writers y Filters configurables
Zend_Log es un componente para el registro de propósito general.
Soporta múltiples backends de log, formatea los mensajes enviados al log,
y filtra los mensajes para que no se registren. Estas funciones se dividen
en los siguientes objetos:
Un Log (instancia de
Zend_Log) es el objeto que su aplicación usa con más frecuencia. Puede tener tantos objetos Log como desee; no interactúan entre sí. Un objeto Log debe contener al menos un Writer, y opcionalmente puede contener uno o más Filters.Un Writer (hereda de
Zend_Log_Writer_Abstract) es responsable de guardar los datos en el almacenamiento.Un Filter (implementa
Zend_Log_Filter_Interface) bloquea que los datos de log se guarden. Un filtro puede aplicarse a un Writer individual, o a un Log, donde se aplica antes que todos los Writers. En cualquier caso, los filtros pueden encadenarse.Un Formatter (implementa
Zend_Log_Formatter_Interface) puede formatear los datos del log antes de que sean escritos por un Writer. Cada Writer tiene exactamente un Formatter.
Para empezar a registrar, instancie un Writer y luego páselo a una instancia de Log:
$logger = new Zend_Log();
$writer = new Zend_Log_Writer_Stream('php://output');
$logger->addWriter($writer);
Es importante señalar que el Log debe
tener al menos un Writer. Puede añadir cualquier número de Writers usando el
método addWriter() del Log.
Alternativamente, puede pasar un Writer directamente al constructor del Log como un atajo:
$writer = new Zend_Log_Writer_Stream('php://output');
$logger = new Zend_Log($writer);
El Log ya está listo para usarse.
Para registrar un mensaje, llame al método log() de una instancia de Log
y páselo el mensaje con una prioridad correspondiente:
$logger->log('Informational message', Zend_Log::INFO);
El primer parámetro del método log() es un
message de tipo string y el segundo parámetro es una
priority de tipo entero. La prioridad debe ser una de las prioridades reconocidas por
la instancia de Log. Esto se explica en la siguiente sección.
También está disponible un atajo. En lugar de llamar al método
log(), puede llamar a un método con el mismo nombre que la prioridad:
$logger->log('Informational message', Zend_Log::INFO);
$logger->info('Informational message');
$logger->log('Emergency message', Zend_Log::EMERG);
$logger->emerg('Emergency message');
Si el objeto Log ya no es necesario, asigne NULL a la
variable que lo contiene para destruirlo. Esto llamará automáticamente al
método de instancia shutdown() de cada Writer adjunto antes de
que el objeto Log sea destruido:
$logger = null;
Destruir el log explícitamente de esta manera es opcional y se realiza automáticamente al finalizar PHP.
La clase Zend_Log define las siguientes prioridades:
EMERG = 0; // Emergency: system is unusable ALERT = 1; // Alert: action must be taken immediately CRIT = 2; // Critical: critical conditions ERR = 3; // Error: error conditions WARN = 4; // Warning: warning conditions NOTICE = 5; // Notice: normal but significant condition INFO = 6; // Informational: informational messages DEBUG = 7; // Debug: debug messages
Estas prioridades siempre están disponibles, y un método de conveniencia con el mismo nombre está disponible para cada una de ellas.
Las prioridades no son arbitrarias. Provienen del protocolo BSD syslog,
que se describe en RFC-3164.
Los nombres y los números de prioridad correspondientes también son
compatibles con otro sistema de registro de PHP,
PEAR Log,
lo que quizás promueve la interoperabilidad entre este y Zend_Log.
Los números de prioridad descienden en orden de importancia. EMERG (0)
es la prioridad más importante. DEBUG (7) es la prioridad menos
importante de las prioridades integradas. Puede definir prioridades
de menor importancia que DEBUG. Al
seleccionar la prioridad para su mensaje de log, tenga en cuenta esta jerarquía
de prioridades y elija apropiadamente.
Las prioridades definidas por el usuario pueden añadirse en tiempo de ejecución usando el
método addPriority() del Log:
$logger->addPriority('FOO', 8);
El fragmento anterior crea una nueva prioridad, FOO, cuyo
valor es '8'. La nueva prioridad está entonces disponible para registrar:
$logger->log('Foo message', 8);
$logger->foo('Foo Message');
Las nuevas prioridades no pueden sobrescribir las existentes.
Cuando llama al método log() o a uno de sus atajos, se
crea un evento de log. Esto es simplemente un array asociativo con datos
que describen el evento y que se pasa a los writers. Las siguientes claves
se crean siempre en este array: timestamp,
message, priority, y
priorityName.
La creación del array event es completamente transparente. Sin embargo, se requiere conocimiento del array event para añadir un elemento que no exista en el conjunto predeterminado anterior.
Para añadir un nuevo elemento a cada evento futuro, llame al
método setEventItem() proporcionando una clave y un valor:
$logger->setEventItem('pid', getmypid());
El ejemplo anterior establece un nuevo elemento llamado pid y lo
rellena con el PID del proceso actual. Una vez que se ha establecido un nuevo
elemento, está disponible automáticamente para todos los writers junto con todos los
demás datos del evento durante el registro. Un elemento puede sobrescribirse en cualquier
momento llamando de nuevo al método setEventItem().
Establecer un nuevo elemento de evento con setEventItem() hace que el
nuevo elemento se envíe a todos los writers del logger. Sin embargo, esto no
garantiza que los writers realmente registren el elemento. Esto es
porque los writers no sabrán qué hacer con él a menos que un objeto
formatter sea informado del nuevo elemento. Consulte la sección sobre Formatters
para obtener más información.
Zend_Log también se puede usar para registrar errores de PHP.
Llamar a registerErrorHandler() añadirá
Zend_Log antes del manejador de errores actual, y también pasará el
error consigo.
Los eventos de Zend_Log provenientes de errores de PHP tienen los campos adicionales que coinciden con
handler ( int $errno , string $errstr [, string $errfile [, int
$errline [, array $errcontext ]]] ) de set_error_handler
Tabla 44.1. Campos adicionales para los eventos de Zend_Log provenientes de errores de PHP
| Nombre | Parámetro del manejador de errores | Descripción |
|---|---|---|
| message | errstr | Contiene el mensaje de error, como una cadena. |
| errno | errno | Contiene el nivel del error generado, como un entero. |
| file | errfile | Contiene el nombre de archivo en el que se generó el error, como una cadena. |
| line | errline | Contiene el número de línea en el que se generó el error, como un entero. |
| context | errcontext | (opcional) Un array que apunta a la tabla de símbolos activa en el punto en que se produjo el error. En otras palabras, errcontext contendrá un array de cada variable que existía en el ámbito en el que se activó el error. El manejador de errores del usuario no debe modificar el contexto del error. |