Logging básico

[Kiquenet]

Hola a todos,

estamos desarrollando aplicación de consola y servicio WCF con .NET 4.5.

La idea es utilizar alguna librería de logging muy simple pero eficaz y potente.

Hay muchas librerías y componentes. 

Common.LoggingCSharp Dot Net Loggerlog4netLogger.NETLogThisNLogPerformance Analysis of Logs PAL ToolTraceTool
Ent.Library 6.0
Y más componentes
https://code.google.com/p/elmah/

https://essentialdiagnostics.codeplex.com/

También hay información interesante:

http://stackoverflow.com/questions/576185/logging-best-practices

http://stackoverflow.com/questions/118047/log4net-vs-enterprise-library-which-is-better-faster

Muchos recomiendan Ent.Lib y Log4net.  También creo recordar que algún proyecto de github hacía una abstracción para utilizar EntLib, log4net, el que se desease, pero no lo encontré.

Cualquier comentario al respecto sobre este tema sería muy interesante. Gracias de antemano.

[Vicenç Garcia]

Y utilizar lo que viene de fábrica?

https://msevents.microsoft.com/CUI/EventDetail.aspx?culture=es-AR&EventID=1032504840&CountryCode=AR

2013/5/22 Kiquenet <kiqu...@gmail.com>

--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a altnet-hispan...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/altnet-hispano?hl=es.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

--

Vicenç García

http://vgaltes.com

http://geeks.ms/blogs/devnettips
http://www.linkedin.com/in/vgaltes
http://www.twitter.com/vgaltes

[Daniel Valcarce]

Buenas.

Echale un ojo a este proyecto: http://netcommon.sourceforge.net/index.html

Quizá es lo que estás buscando para la abstracción de la librería.

Un saludo.

2013/5/22 Kiquenet <kiqu...@gmail.com>

--

Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a altnet-hispan...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/altnet-hispano?hl=es.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

--
Daniel Valcarce Miranda

http://davamix.wordpress.com

[Kiquenet]

Gracias. Vincenç. No he visto el webcast (pone algo de Reactive Extensions), pero permite Diagnostics de una manera flexible escribir trazas a fichero? Saludos.

PD: lástima SecondNug no continué, parece que muchas grabaciones de eventos se perdieron.

[Vicenç Garcia]

Si, la imagen pone reactive extensions, pero si te bajas el webcast es el de Rodrigo sobre System.Diagnostics.

2013/5/22 Kiquenet <kiqu...@gmail.com>

Gracias. Vincenç. No he visto el webcast (pone algo de Reactive Extensions), pero permite Diagnostics de una manera flexible escribir trazas a fichero? Saludos.

PD: lástima SecondNug no continué, parece que muchas grabaciones de eventos se perdieron.

--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a altnet-hispan...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/altnet-hispano?hl=es.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

[Kiquenet]

Gracias a ambos.

Vincenç utilizas System.Diagnostics para trazar a fichero en tus proyectos?

Daniel, también utilizas NetCommon en los proyectos que realizas.

¿Podéis comentar vuestras experiencias?

[Vicenç Garcia]

Si, nosotros lo utilizamos y nos va bien.

2013/5/22 Kiquenet <kiqu...@gmail.com>

--

Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a altnet-hispan...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/altnet-hispano?hl=es.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

[Daniel Valcarce]

Conocía el proyecto de NetCommons pero nunca lo he llegado a utilizar, soy más de Log4Net, personalmente siempre a cubierto mis necesidades, fácil de implementar y configurar.

2013/5/22 Kiquenet <kiqu...@gmail.com>

--

Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a altnet-hispan...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/altnet-hispano?hl=es.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

--

[Joaquín Sosa]

Hola Kike,

 

echa un vistazo a  http://geeks.ms/blogs/jconesa/archive/2013/04/21/todos-los-eventos-de-second-nug.aspx

 

Javier se lo ha currado y ha ido subiendo todos los eventos que hicimos.

 

Saludos

Joaquín Sosa

[Mauro Decima]

Simple, eficaz y potente + logging = log4net

Convertí tus archivos a pdf gratis en http://www.guardarcomopdf.com

[Daniel Cazzulino]

Usa Tracer, y elegi que implementacion usar despues: http://blogs.clariusconsulting.net/kzu/tracer-the-unified-dead-simple-api-for-all-logging-frameworks-in-existence/

Soporta practicamente todos los que nombras. O sea, hay una separacion entre:

- Traces en la logica de negocio (no necesita saber que implementacion vas a usar)

- App start/bootstrap: que elige la implementacion.

el codigo esta en github.com/clariuslabs/tracer, y lo instalas via nuget https://nuget.org/packages/tracer y despues la implementacion es tracer.log4net, o tracer.entlib, o tracer.systemdiagnostics (que tambien anda bien para muchos escenarios "normales").

/kzu

--
Daniel Cazzulino

2013/5/22 Kiquenet <kiqu...@gmail.com>

--

[Leonardo Micheloni]

Hablando de eso, según su experiencia, cuál sería le mejor forma de implementar logging por toda la app? digo para que no quede todo el código de logging disperso, pienso en algo de AOP pero a menos que tengas todos tus objetos provistos por un IoC y puedas "proxiar" con algo que tenga logging adentro tenés que usar algo en tiempo de compilación como AspectSharp o algo así. Cuál sería el mejor enfoque?

Gracias!

2013/5/22 Daniel Cazzulino <dan...@cazzulino.com>

--

Leonardo Micheloni

@leomicheloni

[José F. Romaniello]

por mucho que me guste AOP, si metes logs en todos lados de esa forma podes terminar con un log que no se entiende nada y muy dificil de seguir. A veces me gusta algo más personalizado con la información que realmente me va a servir, sobre todo en las partes críticas de una aplicación

[Daniel Cazzulino]

El mejor enfoque, como dijo Jose, es logear concienzudamente lo que sabes que te va a servir cuando lo leas en un log. "Semantic logging" kinda ;)

/kzu

--
Daniel Cazzulino

2013/5/22 Leonardo Micheloni <leonardogabr...@gmail.com>

[José F. Romaniello]

El 22 de mayo de 2013 10:49, Daniel Cazzulino <dan...@cazzulino.com> escribió:

Semantic logging

exactamente eso quería decir

[Leonardo Micheloni]

Gracias, eso lo tengo claro, escapa un poco a lo que se necesita ahora que es "logear mucho" :(

2013/5/22 Daniel Cazzulino <dan...@cazzulino.com>

--

Leonardo Micheloni

@leomicheloni

[Walter Poch]

Yo ni lo pienso, log4net.

AOP para logging, termina siendo un estilo de tracing de la App, muchos datos pero poca información. Lo he usado para apps, viejas con cero logging, donde tener muchos datos era mejor a no tener nada.

Ahora prefiero poco log, pero con mucha info.

Saludos,

El 22 de mayo de 2013 10:49, Daniel Cazzulino <dan...@cazzulino.com> escribió:

--

Saludos,

Walter G. Poch
--------------------------------------------
Cell: +54 (9 341) 6836871
walte...@gmail.com

[juan ladetto]

Leo... me permito disentir de 2 grandes como José y kzu. 

Cuando creo aplicaciones (en mi caso gralmente web) es necesario saber como va funcionando todo ya que en tiempo de desarrollo no se puede saber como se comportará en producción con n usuarios concurrentes y más cuando n tiende a millones o cuando las estructuras de datos migran de cientos de miles a millones.

Entonces si uno tiene los mecanismos de logging bien definidos entonces puede encender y tomar la traza como para que te des una idea (en .net estoy usando postsharp en mi caso):

[MethodExecutionTimeLimit(200)]

me indica en un log si un request/llamada a un método demoró más de 200 milisegundos (mi umbral para determinar que una página necesita ser optimizada).

Desde la app prendo/no este flag.

Algo similar para las llamadas a los accesos a datos pero por otro camino (me loguea el tiempo que demoró un query y el query ejecutado), entonces puedo activar/desactivar cuando a mi me interesa y saber si un cambio que hicimos en la db impactó negativamente en la performance de los queries que se ejecutan.

Entonces con ir activando los distintos flags de logging durante un tiempo puedo tener claro como está la salud de la aplicación.

Espero que se entienda.

Abrazos

Juan

2013/5/22 Leonardo Micheloni <leonardogabr...@gmail.com>

[Walter Poch]

Juan, creo que lo que estás haciendo es semántico también. 

Yo tengo armados uns aspects muy parecidos a los tuyos, pero no tengo los flags y me gustaría agregarlo. Los logs del aspect "MethodExecutionTimeLimit" (suponiendo es log4net) lo envías a todos a un mismo logger, y luego desde el .config los prendes o apagas?, el prendido/apagado es por web.config, o por código?.

Me interesa tu propuesta, podrías contarme un poco más de cómo lo haces?.

Gracias!

[juan ladetto]

Walter:

Los flags ahora los configuramos vía config... y tenemos armado un helper que te loguea según le indiques. La idea es evolucionarlo y no tener que reiniciar todo cada vez que modifiquemos web.config. Ya tenemos un esquema similar que levanta cada n minutos una configuración particular por si hay cambios y la idea es meterlo ahí a esto too.

El logger es algo así (cada tipo de logger tiene implementado su propio esquema)...

public static class Logger
{
    public static void Error(string message, string module)
    {
        WriteError(message,  module);
    }

    public static void Error(Exception ex, string module)
    {
        WriteError(ex.Message, module);
    }

    public static void Warning(string message, string module)
    {
        WriteWarning(message, module);
    }

    public static void Info(string message, string module)
    {
        WriteInfo(message, module);
    }

Saludos

....

2013/5/30 Walter Poch <walte...@gmail.com>

[Leonardo Micheloni]

Groso Juan como siempre, gracias, muy interesante! el próximo kata de arquitectura que nos toque le metemos logging y todo.

salut

2013/5/30 juan ladetto <jlad...@gmail.com>

--

Leonardo Micheloni

@leomicheloni

[Walter Poch]

Ahh ok, gracias Juan!! pensé estaba más orientado a log4net.

Abrazo,

[Julian Dominguez]

Hola,

Si tu aplicación es .NET 4.5 te recomiendo que mires la clase System.Diagnostics.Tracing.EventSource, que te permite generar eventos que después decidís como querés persistirlos, pero preservando todo el contexto que necesites sobre el evento.

En Enterprise Library 6 lanzamos una nueva library (Semantic Logging Application Block o SLAB, no confundir con el viejo Logging block) que permite consumir los eventos producidos por tu aplicación y persistirlos en archivos de texto, SQL o Windows Azure tables...

Sin embargo no es necesario que uses EntLib, pero te recomiendo que mires esa nueva clase EventSource, ya que personalmente creo que es una manera mucho más sencilla de lograr que tus logs sean semánticos. Con log4net o el viejo EntLib podés lograrlo, pero hay muchos menos enforcements, y es muy fácil salir a producción con Logs que no te sirven para nada o son muy difíciles de leer a la hora de hacer troubleshooting y mucho menos que una tool te ayude a parsearlos...

 

Hay mucha más información en el siguiente pdf: https://entlib.codeplex.com/downloads/get/668950

También hay un overview acá (un poquito outdated, pero sin embargo transmite las ideas fundamentales): http://blogs.msdn.com/b/agile/archive/2013/02/07/embracing-semantic-logging.aspx

 

2013/5/30 Walter Poch <walte...@gmail.com>

[Kiquenet]

Muchas gracias a todos por los comentarios. Es un tema muy amplio sin duda y con muchas alternativas.

La aplicación es .NET 4.5. Es un servicio Wcf y también una aplicación de consola.

Algún ejemplo básico de System.Diagnostics.Tracing.EventSource que persista a fichero (y que sea un "rolling" file) ?

A mi me gusta la idea del "logger wrapper" (http://stackoverflow.com/questions/5646820/logger-wrapper-best-practice)

public interface ILogger
{
 void LogInformation(string msg);
 void LogError(string error);
}

Creo que lo que comentaban en el hilo de Tracer (http://blogs.clariusconsulting.net/kzu/tracer-the-unified-dead-simple-api-for-all-logging-frameworks-in-existence/), puede ir por ese camino, no?

Aquí hablan de NLog vs log4net. Hace mucho no se actualiza log4net comentan.

http://stackoverflow.com/questions/710863/log4net-vs-nlog?rq=1

También puede ser interesante ELMAH. Alguna experiencia tienen al respecto?

http://stackoverflow.com/questions/895901/exception-logging-for-wcf-services-using-elmah?rq=1

[Julian Dominguez]

Si querés utilizar algo como un logging wrapper, entonces la clase EventSource no es tu mejor opción, ya que by design te fuerza a crear una clase tipada para tu aplicación con un método diferente para cada log entry.

A simple vista parece más overhead, pero hay una razón por la que ese approach (en MI opinión) es superior y una vez que se entiende, el overhead definitivamente no es superior. Lo intenté explicar todo acá (en inglés) por si les interesa: http://channel9.msdn.com/Events/Build/2013/3-336

Si lo mirás, me interesa tu opinión.

Saludos!

Julian

2013/6/24 Kiquenet <kiqu...@gmail.com>

--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a altnet-hispan...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.

Visita este grupo en http://groups.google.com/group/altnet-hispano.

[Kiquenet]

Hola a todos,

En cuanto al tema del logging, encontré unas buenas prácticas al respecto, pero sin implementaciones ni ejemplos concretos

http://programmers.stackexchange.com/questions/168059/best-practices-for-logging-user-actions-in-production

En este momento, tengo un escenario de clases "Processor" que ejecutan acciones (de despliegue en servidores) y se necesita trazabilidad (logging) de todo el proceso para temas de depuración, control de errores, etc.

Aquí hay un ejemplo mucho más complejo, pero así ven la idea.

https://filesynchronizer1.codeplex.com/SourceControl/latest#FileSynchronizer/FileSynchronizer/SyncProcessor.cs

Contemplo varias opciones como  Action<string> , Event e incluso event Action<string>

Se encuentran varias clases implicadas, en el que se van "encadenando" los eventos "GenerationProgress", de unas a otras.

Finalmente, el cliente que llama a estas clases puede ser 

         una aplicación Windows Forms, que mostraría las trazas en un RichTextBox,

         o una aplicación de Consola que mostraría las trazas por la salida estandar, o incluso a un fichero en FileSystem,

         o un servicio Windows que utiliza Msmq, que mostraría las trazas por la salida estandar, e incluso dentro de un objecto con System.Messaging.Message

 Action<string>

 public partial class AgentExecutor

    {

        static Action<string> logTracer = null;

        private static void Log(string msg)

        {

            Trace.WriteLine(msg);

            if (logTracer == null) return;

            logTracer(msg);

        }

        public static bool DeployUsingCommandExecutor(Action<string> tracer, string command, string empaquetadoXml, string projectName, string projectGuid)

        {

            logTracer = tracer;

            Log("Desplegando comando" + command);

            // omitido ....

event EventHandler<GenerationProgressEventArgs>

 public partial class AgentProxy

    {

        protected int progressValue = 0;

        public int ProgressValue

        {

            get { return progressValue; }

        }

        public event EventHandler<GenerationProgressEventArgs> GenerationProgress;

        protected virtual void RaiseGenerationProgress(double progress, string stageName, ReportStageType stageType)

        {

            EventHandler<GenerationProgressEventArgs> handler = GenerationProgress;

            if (handler != null)

            {

                handler(this, new GenerationProgressEventArgs(progress, stageName, stageType));

            }

        }

        public event EventHandler<ReportCanceledEventArgs> ReportCanceled;

        protected virtual void RaiseReportCanceled(bool hasFailed, Exception exception)

        {

            EventHandler<ReportCanceledEventArgs> handler = ReportCanceled;

            if (handler != null)

            {

                handler(this, new ReportCanceledEventArgs(hasFailed, exception));

            }

        }

Ejemplo EventHandler<ReportCanceledEventArgs>, encadenando eventos

  private DatosResultadoDespliegue ExecuteDeployment(IDeployPowerShellExecutor executor)

        {

            executor.Initialize(DatosDeEjecucion).

                SetProgressValue(progress);

            executor.GenerationProgress += (sender, args) => RaiseGenerationProgress(args.Progress, args.StageName, args.StageType); // ReportProgress(string.Format("\r\n{0:0}% finished, Current step: {1}", args.Progress * 100, args.StageName));

            executor.ReportCanceled += (sender, args) => RaiseReportCanceled(args.HasFailed, args.Exception); // Trace.WriteLine("CANCELED " + args.Exception.Message);

            executor.DoDeploy();

            ResultadoDeDespliegue = executor.DeploymentResult;

            return new DatosResultadoDespliegue()

            {

                ResultadoDespliegue = executor.DeploymentResult,

                ResultadosScript = DatosDeEjecucion.ResultadosScript,

            };

        }

En este escenario, deseaba aplicar buenas prácticas y una forma adecuada de tener logging, de una manera lo más simple posible,  si pueden darme alguna recomendación al respecto.

Muchas gracias y saludos.

Referencias: http://stackoverflow.com/questions/10257259/returning-an-event-from-a-function

[cibrax]

Mi pequena contribucion. Una ventaja fundamental de EventSource contra cualquier otro metodo convencional de tracing es que usa ETW, por lo que podes dejar el trace prendido siempre y no va a pasar nada. Es tracing a nivel kernel y lo que usan la mayoria de los componentes del OS en Windows. Cuando realmente queres capturar informacion para saber que esta pasando, empezas a capturar el trace de ETW. No tenes que cambiar el archivo de configuracion o reiniciar nada, simplemente ejecutas un comando por consola para empezar a capturar. 

Pablo.

[Carlos Admirador]

Hola gente!

Qué tal estas aproximaciones en este tema, estado del arte en 2016 - 2017 ?

Veo que hablan mucho de Serilog, combiando con Seq para hacer queries a los logs !!!
Alguna comenta Loggy, además  ELK , Splunk, VS Application Insights,...

Me suena a chino, buscaré algo por github, Real World application, que lo utilicen.

log4net, EntLib, ELMAH quedaron atrás?

For web apps flat files are enough (easy to analyze) - we are using Splunk to gather them.
For mobile/desktop apps (where both logging and capturing user UI usage are important) I prefer to use some 3rd party logging services like Visual Studio Application Insights or HockeyApp

Serilog. Serilog serilog serilog. All day serilog. Combined with Seq for viewing the errors it's an awesome little logger for not just regular logging but also tracking down unhandled exceptions. For ASP.NET they have a nice library called SerilogWeb.Classic that will get you the post data included along with quite a bit of other metrics that you can define.

Second Serilog. I also like NLog for small projects. Elmah is nice, but you don't want to take a dependency on Elmah on non-web projects such as the DAL and BL/core. I'd use a sink to log to Glimpse for dev time debugging and write to a rolling file or database table or into Elastic Search for production purposes. The log format/s should be consistently 'tagged' (e.g. log type, timestamp, source, message, metadata) for easy processing via the ELK stack or some other tool.

For what we do the UI is just the tip of the iceberg. Serilog has enrichers to gather all the data ELMAH gives us and enough sinks to get the data in the right spot in the same way ELMAH does. Throw in Seq as the log aggregator (or splunk, exceptionless, elmah.io or any number of other sinks) and you have a nice way of consuming it. The real improvement is we can use the same logging from all our backend services, libraries, etc that aren't tied to ASP.NET.

Combined with structured logging makes for a very powerful library that's very easy to consume.

edit: very short version of structured logging - instead of logging text it logs the message format and the variables that build it. e.g. log("The account {accountId} failed to bill", account.Id) would log exactly that format and the variable. Then you can use something like Seq to query maybe all the log statements related to a specific account id if you suspect you are having problems with it. Or we include the username and referring url in our logs. So I can quickly get a list of all the requests made from a specific html page to our api filtered by the username.

Thirded.

Serilog + Logg.ly has revolutionized our operations.

We log everything, and then we can write real time queries like "message X for this event hasn't occured in 30 seconds, somethings probably messed up, send a message to our operations alerts HipChat room pronto!"

Then we get a nice link in our HipChat room that links us to the exact error in navigable JSON format. It's so easy. I know exactly what my systems are doing at any given time.

We are actually using https://github.com/samirahmed/serlog.logglybulksink

Looks a bit sketch, but it works perfectly. If you're pumping LOTS of events in from any one machine or process, it's definitely the way to go. I put 20GB through it in the past few hours.

StackExchange.Exceptional?

I'm using NLog. I wrote a HTTPModule that catches the ambient request exception and on startup binds the appdomain UnhandledException event to a log statement. The HTTPModule extracts the request's principal, URL, HTTP verb, remote address, browser from headers, stack and generates an error ID. The error ID is shown to the client on the error page. The error ID is the last 8 characters of a random guid.

This is then forwarded to an rsyslogd server and into splunk. You don't have to do that though. Event log or file is fine too.

It's very helpful when a user says "I got error ed54db51" and you can trace the exact request that blew.

Saludos Gente!