Créditos de la fotografía: Scott Webb en Pexels
Si has leído el documento que tengo de monitorización y observabilidad, entenderás lo importante que es guardar unas buenas trazas de tu aplicación, si no lo has leído, te recomiendo que lo revises (ir al documento).
Da igual si estas en la nube o estas en tu infraestructura local, debes medirlo todo, guardar trazas de todo y analizarlo todo. Esta obsesión por la monitorización y observabilidad de una aplicación, es una prioridad que debes tener desde el minuto 0 de tu aplicación.
Los desarrollos de .Net desde un template estandar ya te proponen un logger propio, pero este logger puede que se te quede corto y necesites más funcionalidades que guardar las trazas. Si no necesitas más, aplica KISS. No merece la pena ir a Serilog o Log4Net. En cambio, si necesitas enviar esa información a un Event Grid, guardar el fichero y establecer la información en Azure Application Insight, sí que te merece la pena tener una librería similar.
Antes de continuar, se que te estarás preguntando cuál de los 2 es mejor, yo parto de una premisa, Log4Net es un port del de Java y Serilog es nativo de .Net, no quiere decir este aspecto que uno sea mejor que otro, por ejemplo Log4Net tiene muchas herramientas dedicadas y por ejemplo cualquier sistema basado en Apache lleva un Log4J o Apache Logging Service. pero me decanto más por Serilog por ser más sencillo de configurar por que el fichero es más estructurado.
En cualquier caso ambos dan versátil que el que viene por defecto en un proyecto de .NET, ambos están muy vivos y si resulta que usas SPARK.NET (ir a un curso), esta claro que tiras hacia un lado concreto. Veamos una tabla:
| Pros | Contras | |
| Serilog |
|
|
| Log4Net |
|
|
| Build-In |
|
|
Pasos
1. Crear en Visual Studio 2019, una Azure Function, llamada azfSeriLog de tipo HTTP Trigger.
2. Añadir al proyecto las librería de SeriLog:
3. Añadir la clase y Startup.cs
Pasos a paso:
-
- Hemos definido el tipo de salida a consola con un template.
- Hemos definido que salga a un fichero y genera la información diaria.
- Le indicamos que nos muestre las trazas en Application Insight.
- Que enriquezca el contenido con contexto, nombre de la máquina, proceso e hilo, existen más opciones asociadas a los Nugets correspondientes.
Que dejo pendiente, añadir el nuget de configuración de fichero y así lo podrás obtener todo de u appsetting.json y personalziarlos para cada entorno.
4. Ponemos algo de codigo que lance un error o que funcione correctamente para ver la salida.
5. Ejecutamos
6. Observamos la salida por consola:
7. Ahora desplegamos nuestra función en Azure y creamos un Application Insight del cual cogeremos la Key para posteriormente observar la telemetría que genera con Serilog
Conclusión
Has podido ve que con 4 linea de codigo es muy sencillo establecer un log que nos permita sacar la información en diferentes sitios, incluso si quieres ir a DataLog, existe un plugin; o guardar el fichero de errores en un blob diariamente.
Siempre y cuando debas continuar con el estandar de la organización en la que trabajes no voy a recomendarte usar la opción build-in, pero si puedes elegir, build-in es una buena opción ya que es el que lleva inherente .NET y la información que ofrece en la mayoría de los casos es suficiente para localizar una incidencia si lo usas en consonancia con Azure Application Insight.
Si no usas esa pieza de Azure, no puedo recomendarlo, se queda muy corto y te diría que uses o bien Serilog o Log4Net si por ejemplo la información la viertes en un InfluxDB con Grapana.
Tampoco recomiedo mucho Build-in para ficheros, no es la mejor opción te toca hacer un poco de trajo por tu parte, aunque lo que aporta es suficiente, a veces es escaso.
