¿Cómo debo manejar las fallas del registrador?

En varias de las aplicaciones de nuestra empresa, utilizamos un registrador personalizado. Es bastante robusto, aunque podemos reemplazarlo con algo como NLog en el futuro. Una de las tareas del registrador es registrar cualquier excepción encontrada en la aplicación.

Una preocupación que siempre tuve es que el manejo de excepciones dentro del registrador permite una falla silenciosa. Es decir, si el registro no está escrito para una excepción dada (debido a un error en el registrador), ¿cómo debo manejarlo y (de alguna manera) registrar la excepción en el registrador ?

Digamos que la función WriteLog produce una excepción. ¿Debería intentar llamar a la función varias veces o hasta que no se produzca la excepción? ¿Debería tratar de escribir la excepción lanzada con el registrador (lo que probablemente resultaría en excepciones hasta el final ...)? He tenido la suerte de no encontrarme con esta situación, excepto cuando implementamos el registrador personalizado por primera vez. Por otro lado, no tengo forma de saber en este momento si el registrador no ha podido registrar las excepciones de la aplicación (debido a sus propias excepciones).

He intentado buscar en línea y en algunos sitios de SE, pero hasta ahora ha sido infructuoso ya que todas las publicaciones tratan errores en un registrador (pero no posibles excepciones y cómo registrarlos) o con excepciones fuera del registrador.

Cuando encuentre excepciones dentro del registrador, no debe usar el registrador para registrar sus propias excepciones. La razón de eso es que:

• Puede estar atrapado en un bucle infinito. Imagine que dentro de su registrador, tiene una rama condicional que no se probó (y genera una excepción). Imagine que una vez que se cumple la condición, cualquier otra excepción reportada es manejada por la misma rama. Esto significa que desde el momento en que se ejecuta la rama, estás en un bucle infinito.

• Puede estar atrapado en un bucle temporal, generando miles de excepciones por segundo. Imagine que está informando excepciones a un servidor remoto. Un problema con el servidor provoca otra excepción, que provoca otra, y así sucesivamente, hasta que la conexión se restablezca.

Lo que debe hacer en cambio es recurrir a una forma más segura de registrar las excepciones. Por ejemplo, si su registrador envía las excepciones a un servidor remoto, envíe las excepciones dentro del registrador a syslog. Si su registrador registra excepciones en Eventos de Windows y esta acción falla, almacene la excepción de falla en un archivo de texto simple.

Una vez que tenga eso, la siguiente pregunta es cómo sabe que ocurrieron esas excepciones: si tiene docenas de aplicaciones que se ejecutan en miles de servidores, no puede SSH cada una de ellas regularmente para verificar si estaban registrando algo localmente .

Una forma es tener un trabajo cron que verifique esos "registros excepcionales" y los empuje a la ubicación donde se almacenan otras excepciones (eventualmente usando su registrador, ¡pero tenga cuidado con los bucles infinitos o temporales!).

Si el registro es crítico para su aplicación, se debe detener la aplicación si falla el registro.

Si no es crítico, estar algo a la defensiva podría tener un componente secundario para manejar fallas de registro que registra / alerta a una fuente secundaria. Pero incluso eso no es infalible y tendrá que considerar qué sucede si el registrador secundario falla mientras está monitoreando al registrador primario.

Una buena estrategia es iniciar sesión en un archivo local y, si eso falla, tal vez registrar esa falla en el registro de eventos, generar una alerta por correo electrónico, guardar en una base de datos, etc. Con los marcos de registro disponibles, esto debería ser infalible a menos que la máquina funcione sin espacio en disco o alguna otra condición rara.

Idealmente, es mejor que falle en silencio ya que eso hará que la aplicación sea menos compleja.

Más importante aún, para manejar las fallas de registro, uno debe monitorear los registros de un tercero. Con el tiempo, debería poder discernir cuántos eventos está registrando una aplicación saludable. Si comienza a registrar eventos bajos o sin eventos, entonces, a través de la supervisión, puede ver que ocurre el problema y potencialmente alertar a través de ese mecanismo de terceros.