services - .Net Web Service Logging
startup auth cs web api (1)
Use wcf si es posible e implemente el registro de mensajes, consulte http://msdn.microsoft.com/en-us/library/ms730064.aspx.
<system.diagnostics>
<sources>
<source name="System.ServiceModel.MessageLogging">
<listeners>
<add name="messages"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData="c:/logs/messages.svclog" />
</listeners>
</source>
</sources>
</system.diagnostics>
<system.serviceModel>
<diagnostics>
<messageLogging
logEntireMessage="true"
logMalformedMessages="false"
logMessagesAtServiceLevel="true"
logMessagesAtTransportLevel="false"
maxMessagesToLog="3000"
maxSizeOfMessageToLog="2000"/>
</diagnostics>
</system.serviceModel>
Mi situación ideal para iniciar sesión en nuestro servicio web sería registrar todas las llamadas a los métodos (autenticación y acceso a los datos) con los parámetros que se les pasaron, así como los errores que puedan haber ocurrido, y vincularlos con un único ID que asocie ellos con la misma llamada. Además, idealmente me gustaría poder controlar si se registran todos los parámetros o si solo se registra la llamada al método. Me gustaría poder controlar si se registran todos los inicios de sesión o solo los que fallaron. Una vez más, toda la información recuperada en una única solicitud se vinculará a través de una identificación (guía o de otro tipo).
Esta es mi situación de registro ideal. Si alguien sabe cómo implementar todo esto y estaría dispuesto a mudarse al área de Manchester, NH ...;)
Pero en serio, ¿alguien sabe cómo me gustaría vincular una solicitud de servicio web recibida a un error o una llamada a un método? Mis intentos iniciales implican meterse en una extensión de jabón, tratando de agregar un encabezado (soap o html) y lo que no debe pasar un valor arbitrario de la extensión en el servicio en sí. Todos mis intentos no han tenido éxito.
Nuestra situación de registro actual tiene el registro de autenticación en una tabla, el método / llamadas comerciales a otra tabla, y el registro de excepciones a otra tabla, sin interconexión entre ellas. Las marcas de tiempo son útiles, a veces, pero no son lo suficientemente confiables para una depuración efectiva. Actualmente estamos en .Net 2.0 con el potencial de estar usando 3.5 antes de fin de año, por lo que sería más útil si las respuestas se mantuvieran en la funcionalidad 2.0.
¿Alguien tiene alguna idea?