Exportar (0) Imprimir
Expandir todo

Prácticas recomendadas de solución de problemas para desarrollar aplicaciones de Azure

Actualizado: noviembre de 2014

Autor: William Bellamy, Ingeniero de escalación principal de Microsoft

Colaboradores:

  • Bryan Lamos, Jefe de programa sénior de Microsoft, Calidad de productos

  • Kevin Williamson, Ingeniero de escalación sénior de Microsoft, Soporte para desarrolladores de Azure

  • Pranay Doshi, Jefe de programa sénior de Microsoft, Servicios de producción de Azure

  • Tom Christian, Ingeniero de escalación sénior de Microsoft, Soporte para desarrolladores de Azure

Publicado: enero de 2012

La principal prioridad de Microsoft es ayudar a los clientes de Azure a mantener sus aplicaciones en funcionamiento. Los Contratos de nivel de servicio de Azure definen una disponibilidad del 99,95 % de conectividad externa cuando implementa dos instancias de rol o más. Sin embargo, la conectividad externa asegura que pueda conectarse con su aplicación desde fuera de los centros de datos de Microsoft, que no es lo mismo que “el sitio esté activo”. La mayoría de los servicios de Azure tienen varias dependencias: SQL Azure, almacenamiento en memoria caché, red de entrega de contenido, recursos internos (a través de Azure Connect), etc. Un error en cualquiera de estas dependencias puede provocar que su servicio de Azure no funcione según lo esperado.

En este documento, se abordan las distintas dificultades para la solución de problemas y los enfoques recomendados para el diseño y el desarrollo de aplicaciones más compatibles para la plataforma Azure. Cuando (y no “si”) se presenta un problema, el tiempo es fundamental. La correcta planificación puede permitirle encontrar y corregir problemas sin tener que ponerse en contacto con Microsoft para obtener asistencia. El enfoque que se sostiene en este documento también acelerará la solución de los problemas que exigen la asistencia de Microsoft.

Este documento tiene como fin servir de recurso para los técnicos de software: diseñadores de software, arquitectos, profesionales de TI, integradores de sistemas, desarrolladores y evaluadores que diseñan, compilan e implementan soluciones de Azure.

Suponemos que cuenta con una comprensión básica del ciclo de vida del desarrollo de aplicaciones de Azure, incluida la terminología y los distintos componentes del entorno de desarrollo y tiempo de ejecución de Azure.

También suponemos que se seguirán las directrices básicas de Azure, como el uso de la versión más reciente del SDK de Azure y la comprobación de los cambios de código antes de implementarlos en la producción.

Este documento se organiza en dos secciones:

  • Información general de los recursos de diagnóstico de Azure:

    • Recursos de Azure

    • Recursos de terceros

  • Procedimientos recomendados para un diseño, desarrollo e implementación compatibles:

    • Antes de implementar su aplicación.

    • Diseño y supervisión rápidos de errores.

    • Qué hacer cuando se genera un problema.

Ningún desarrollador espera que su aplicación caiga una vez que entra en la fase de producción. Hacemos lo posible por probar el código durante el desarrollo para que sea lo suficientemente robusta para ejecutarse sin errores a medida que nos encargamos de un nuevo proyecto. Desafortunadamente, el código se corrompe. En un entorno distribuido, los errores leves pueden volverse catastróficos debido a las complejidades inherentes a la separación de los componentes de la aplicación. Es por ello que debe diseñarse una estrategia de registro y seguimiento de la aplicación desde un comienzo. Lo ideal es que esta estrategia incluya disposiciones para ajustarse de forma dinámica sin necesidad de volver a compilar o implementar el tipo y la cantidad de registros en el nivel de componentes. Tener una cantidad de registros no garantiza soluciones rápidas. Más no es sinónimo de mejor, ya que una gran cantidad de datos exige mucho tiempo para descifrarlos y posiblemente ralentice el rendimiento de su aplicación. Un registro ajustable controla tanto el tamaño como el coste de almacenamiento de los datos de registro.

Las aplicaciones distribuidas como las que se ejecutan en la plataforma Azure tienen varios componentes que interactúan entre sí cuando el usuario interactúa con la aplicación. Al registrar el flujo de código de forma coherente y constante, teniendo especial cuidado de las llamadas a los servicios externos, cualquiera debería poder seguir virtualmente el flujo de ejecución de su aplicación. Esto puede resultar invalorable uno o dos años después, cuando se genere un problema durante la producción. Lo ideal es que el nivel de registro se pueda ajustar desde el archivo ServiceConfiguration.cscfg para poder cambiarlo sin necesidad de una nueva implementación.

Es conveniente usar una compilación de depuración durante el desarrollo con el objetivo de obtener el máximo de información de los errores. En general, los desarrolladores agregan instrucciones de depuración y, en ocasiones, algún tipo de registro de errores. La única salvedad es que las instrucciones de depuración se eliminan en la compilación de producción, lo que significa que no tendrá suerte cuando haya un problema. La mayoría de los clientes no querrá volver a implementar con una compilación de depuración para resolver un problema de producción. Mike Kelly destaca cuatro tipos de salidas de diagnóstico que los desarrolladores deben configurar:

  • Salida de depuración: solo en compilaciones de depuración que incluyen aserciones

  • Seguimiento: hace un seguimiento del flujo de control durante la ejecución

  • Registro de eventos: eventos más importantes

  • Registro de errores: situación excepcional o peligrosa

Probablemente, muchos de los mensajes de depuración deberían contarse como instrucciones de seguimiento para aprovechar los distintos niveles de seguimiento. Los Diagnósticos de Azure también le permiten configurar diagnósticos y deshabilitar las transferencias para poder controlar cuándo se escribe información en el almacenamiento persistente.

En las secciones siguientes se describen algunos de los recursos de solución de problemas que los desarrolladores tienen disponibles para compilar aplicaciones en Azure.

Antes de adentrarnos en Azure, comencemos viendo el paradigma actual de solución de problemas para las aplicaciones de Windows Server. Normalmente, los desarrolladores examinan los registros cuando se genera un problema de producción. Los registros de eventos y los registros IIS se activan de forma predeterminada y resisten los reinicios (siempre que no haya un error de disco).

El mismo proceso funcionará en una aplicación de Azure si el Escritorio remoto está habilitado; los desarrolladores pueden conectarse a cada instancia para recopilar datos de diagnóstico. La recopilación se puede lograr mediante la copia de los registros en el almacenamiento o la configuración del RDP para poder copiarlos en el equipo local. Este proceso lleva tiempo y provocará un error si se restablece la imagen inicial de la instancia, lo que genera que se inicie una versión limpia del rol web o de trabajo. Evidentemente, esta versión limpia está desprovista de todos los registros anteriores. Se puede producir el restablecimiento de la imagen inicial si hay una actualización del sistema operativo del host o de la máquina virtual huésped. El restablecimiento de la imagen inicial es una parte normal de la arquitectura de Azure.

El SDK 1.0 de Azure original incluía la funcionalidad para recopilar diagnósticos y guardarlos en el almacenamiento de Azure, conocido en su conjunto como Diagnósticos de Azure (WAD). Este software, basado en el marco de Seguimiento de eventos para Windows (ETW), satisface dos requisitos de diseño introducidos por la arquitectura de escala horizontal de Azure:

  1. Guardar los datos de diagnóstico que se perderían durante un restablecimiento de la imagen inicial de la instancia.

  2. Proporcionar un repositorio central para el diagnóstico de varias instancias.

El espacio de nombres Microsoft.WindowsAzure.Diagnostic amplía el espacio de nombres System.Diagnostics para que pueda usar el marco de ETW dentro de una aplicación de Azure.

Diagrama de flujo de diagnóstico de Windows Azure

Después de incluir los Diagnósticos de Azure en el rol (ServiceConfiguration.cscfg y ServiceDefinition.csdef), WAD recopila datos de diagnóstico de todas las instancias de ese rol en particular. Los datos de diagnóstico se pueden usar para la depuración y solución de problemas, medición del rendimiento, supervisión del uso de recursos, análisis del tráfico y planeación de la capacidad, y auditoría. Las transferencias a la cuenta de almacenamiento de Azure para su persistencia se pueden programar o realizar a petición.

Los Diagnósticos de Azure cambian el paradigma del servidor en cuatro aspectos importantes:

  1. Los diagnósticos deben habilitarse en el momento de creación de la aplicación.

  2. Se necesitan herramientas/pasos específicos para visualizar los resultados de diagnóstico.

  3. Los bloqueos provocarán la pérdida de datos de diagnóstico a menos que estos se escriban en un almacenamiento duradero (almacenamiento de Azure en lugar de cada instancia).

  4. El almacenamiento de diagnóstico genera un gasto mensual si se encuentra en el almacenamiento de Azure.

El coste es de especial importancia, ya que una de las ventajas clave de la plataforma Azure es la reducción de costes. La única forma de eliminar el costo de usar WAD actualmente es dejar los datos en la máquina virtual. Esto puede funcionar en una pequeña implementación, pero no resulta práctico cuando hay varias instancias. Estos son algunos ejemplos de cómo minimizar el impacto financiero:

  1. Asegúrese de que la cuenta de almacenamiento esté en el mismo centro de datos que su aplicación. Si por algún motivo no se encuentran en el mismo centro de datos, elija con cuidado el intervalo de transferencias programadas. Los períodos de transferencia más cortos aumentarán la pertinencia de los datos, pero puede que esto no compense el ancho de banda adicional y la sobrecarga de procesamiento.

  2. Copie los datos de diagnóstico y bórrelos periódicamente del almacenamiento de Azure. Los datos de diagnóstico pasarán por el almacenamiento de Azure, pero no residirán allí innecesariamente. Existe una variedad de herramientas para ello: Módulo de supervisión de System Center para Azure, Azure Diagnostics Manager de Cerebrata y cmdlets de PowerShell de Azure.

  3. Escoja únicamente los datos de diagnóstico que necesitará para supervisar y solucionar los problemas de su aplicación. Capturar demasiados datos puede dificultar la solución de problemas, además de aumentar el gasto significativamente.

  4. Controle la recopilación y la extensión de los datos de diagnóstico mediante la implementación de un conmutador a petición en su aplicación.

  5. Utilice el nivel de registro (detallado, información, advertencia, error) para que toda la información esté disponible, luego utilice la configuración de WAD después de la implementación para recoger datos de manera selectiva.

El almacenamiento de Azure es la base para cualquier aplicación compatible. Lo ideal es que todas las aplicaciones tengan esta funcionalidad configurada y activa.

El análisis de almacenamiento de Azure realiza el registro y proporciona datos de métricas para una cuenta de almacenamiento. Puede usar estos datos para hacer un seguimiento de las solicitudes de almacenamiento, analizar tendencias de uso y diagnosticar problemas con la cuenta de almacenamiento.

La clave para escribir código de SQL Azure compatible es examinar los códigos de retorno y asegurarse de tener un código de reintento bien estructurado para manejar los errores.

Este Módulo de supervisión (en inglés) le permite usar Microsoft System Center Operations Manager para supervisar la disponibilidad y el rendimiento de las aplicaciones de Azure:

  • Detecta aplicaciones de Azure.

  • Proporciona el estado de cada instancia de rol.

  • Recopila y supervisa la información de rendimiento.

  • Recopila y supervisa los eventos de Windows.

  • Recopila y supervisa los mensajes de seguimiento de .NET Framework desde cada instancia de rol.

  • Limpia los datos de rendimiento, eventos y seguimiento de .NET Framework de la cuenta de almacenamiento de Azure.

  • Cambia el número de instancias de rol.

Microsoft System Center Operations Manager 2007 es la mejor forma de supervisar el estado de su aplicación de Azure.

Actualmente, Azure no ofrece una solución completa para que los clientes supervisen y administren su servicio hospedado. Para obtener información de conexión en red, speedtest.net ofrece una herramienta que mide los tiempos de respuesta, el ancho de banda y la calidad general de conexión. La latencia entre los distintos centros de datos de Microsoft se puede ver con Azure Statistics de Matthew Rosoff. Hay varias herramientas muy útiles cuando se trabaja con Azure. La lista siguiente no implica una aprobación ni recomendación de ninguna herramienta de terceros en particular.

Cmdlets de PowerShell de Azure:

La mejor manera de administrar los diagnósticos de forma remota es usar los cmdlets de PowerShell de Azure. Los cmdlets se basan en las API Administración y Diagnósticos de Azure, y el código fuente completo está disponible en el proyecto CodePlex para lograr una mejor comprensión de las API subyacentes. La versión 2.0 le permite configurar, descargar y limpiar todos los aspectos de Diagnósticos de Azure. El blog de Michael Washam ofrece algunos buenos scripts de ejemplo.

Supervisión de la red: AlertBot, Gomez, Keynote, Pingdom

Gomez Application Performance Management de Compuware, Keynote, Pingdom y AlertBot son soluciones para supervisar su aplicación de Azure desde el exterior. Le permiten supervisar la disponibilidad de su aplicación y optimizar el rendimiento. Algunos servicios, como Pingdom, permiten la notificación por correo electrónico, SMS o un notificador de escritorio cuando se detecta un error. Este tipo de supervisión exige simular lo que hace un usuario final a fin de lograr una supervisión correcta, ya que en ocasiones un rol web mostrará la página de inicio sin ser completamente funcional.

Azure Check

AzureCheck de Apica es una herramienta que supervisa su aplicación web de Azure «desde fuera». A fin de usar esta herramienta, debe descargar el código y agregarlo a su implementación como tarea de arranque. La ventaja de esta herramienta es que no le exige que almacene sus registros en su cuenta de almacenamiento, lo que reduce el gasto de supervisión.

Azure Diagnostics Manager

Azure Diagnostic Manager de Cerebrata es un cliente basado en Windows para administrar Diagnósticos de Azure. Muestra o descarga los registros que recopila WAD. También puede administrar su configuración de WAD, y un panel le permite supervisar el rendimiento en directo.

Exploradores de almacenamiento de Azure

Existe una variedad de formas de explorar el almacenamiento de Azure. El equipo de almacenamiento de Azure creó una lista de exploradores de almacenamiento. Cualquiera de estos le permitirá ver los archivos de WAD y los archivos de análisis de almacenamiento de Azure. Explorer for Azure Blob Storage de Cloudberry Lab ofrece una interfaz de usuario para habilitar el análisis de almacenamiento directamente en la aplicación al hacer clic en Storage Settings.

IntelliTrace

Microsoft Visual Studio 2010 Ultimate contiene IntelliTrace, que se puede habilitar con el fin de depurar aplicaciones antes de implementarlas en producción. IntelliTrace admite aplicaciones ASP.NET y WCF. IntelliTrace no se admite cuando se habilita en un servicio de producción, pero se puede usar para obtener excepciones para una aplicación después de la implementación en Azure. En el blog de Jim Nakashima se describe cómo usar IntelliTrace para depurar los Servicios en la nube de Azure.

AVIcode

Microsoft adquirió AVIcode y ahora es parte de Microsoft System Center. AVIcode ofrece capacidades de supervisión del rendimiento de aplicaciones .NET con un paquete integral de capacidades de supervisión de aplicaciones.

Fiddler

Fiddler es un proxy de depuración web que registra todo el tráfico HTTP(S) entre su equipo e Internet. Fiddler le permite inspeccionar el tráfico, establecer puntos de interrupción y “juguetear” con los datos de entrada o salida. Fiddler es especialmente útil para solucionar problemas de almacenamiento de Azure.

Para usar Fiddler con el entramado de desarrollo local, use ipv4.fiddler en lugar de 127.0.0.1:

  1. Inicie Fiddler.

  2. Inicie su servicio en el entramado de desarrollo.

  3. Vaya a http://ipv4.fiddler:/. Fiddler debería hacer un seguimiento de la solicitud.

Para usar Fiddler con el almacenamiento de desarrollo local, debe modificar el archivo de configuración del servicio para que apunte a Fiddler:

  1. Abra el archivo ServiceConfiguration.cscfg y cambie la cadena de conexión a:

    Value=“UseDevelopmentStorage=true;DevelopmentStorageProxyUri=http://ipv4.fiddler”

  2. Inicie Fiddler.

  3. Inicie su servicio. Fiddler debería hacer un seguimiento de las solicitudes de almacenamiento.

Generación de perfiles de rendimiento

Puede generar perfiles de su aplicación de Azure cuando se ejecute en Azure para determinar cualquier problema de rendimiento. Al publicar su aplicación de Azure en Visual Studio, puede decidir generar perfiles de la aplicación y seleccionar la configuración de generación de perfiles que requiera.

Azure VM Assistant

La herramienta VM Assistant es un proyecto de CodePlex que le ahorra tiempo para diagnosticar problemas al recopilar todos los datos pertinentes en un lugar cuando agrega Escritorio remoto a una instancia. El botón VM Health le da el estado actual de la instancia.

En lo referente a las soluciones basadas en la nube, es importante que los diseñadores y desarrolladores de software se preparen para los problemas en el momento del diseño, más de lo que sería necesario con el software tradicional empaquetado que se implementa en los servidores de un centro de datos corporativo. En esta sección se destacan algunos escenarios específicos que los desarrolladores son responsables de mitigar en la nube y se describe cómo prepararse para que esos problemas se puedan resolver rápidamente cuando se presentan.

La diferencia fundamental con la implementación tradicional basada en servidores es que ya no puede acceder al hardware del servidor. El SDK 1.3 de Azure agregó la capacidad de usar los Servicios de Escritorio remoto para acceder a los roles de Azure. Usar el SDK más reciente asegurará la mejor experiencia. Habilitar el escritorio remoto es una primera medida obligatoria en la creación de un servicio de Azure compatible. Esta medida solo se puede llevar a cabo antes de la implementación.

Uno de los pasos necesarios para habilitar el Escritorio remoto es elegir un nombre de usuario, una contraseña y una fecha de expiración de la cuenta. Estos tres elementos se pueden cambiar en el Portal de administración de Azure. Esto resulta útil si olvida la contraseña que configuró hace meses, cuando implementó el servicio por primera vez.

Al hacer en el botón Configurar en el portal para cambiar alguno de estos tres parámetros, normalmente verá esta secuencia: Actualizando…, En espera de host…, El rol se actualizó correctamente. En espera de host…, Listo. Esto corresponde a que el rol recibe y luego se encarga del evento de cambio. Los clientes pueden suscribirse a eventos RoleEnvironment y luego, cuando se recibe el evento RoleEnvironment.Changing: aceptar los cambios y seguir en ejecución (predeterminado), o bien desconectar la instancia, aplicar los cambios y volver a conectarse (e.Cancel = true).

Si el código recicla el rol ante eventos de cambio, se reciclarán todas las instancias en todos los roles en ese servicio hospedado. Los servicios con varias instancias por rol no sufrirán una pérdida de tiempo debido a la arquitectura de dominio de actualización, pero el rendimiento puede reducirse al reciclar cada dominio. Lo que es más importante, si se encuentra en medio de un problema que solo se reproduce una vez al mes, perderá la oportunidad de capturar el estado de la instancia. Por lo tanto, recomendamos que tenga habilitada una conexión de Escritorio remoto con credenciales conocidas y seguras que no hayan expirado.

A continuación, debe probar que la conexión funcione. Esto se hace fácilmente al hacer clic en el botón Conectar en el portal. En la mayoría de los casos, debería conservar una copia del archivo RDP para poder cambiar la sección Recursos locales para incluir sus discos locales. Esto le permitirá copiar fácilmente los archivos a un lado y otro de su instancia. Para ello, haga clic en la pestaña Recursos locales y luego en el botón Más. La configuración de conexión en la pestaña General le permitirá guardar la configuración en un archivo .RDP.

Cuadros de diálogo de conexión a Escritorio remoto de Windows Azure

Cómo solucionar problemas en la máquina virtual

Una vez que se ha conectado a una instancia, ¿qué va a buscar? Si quiere solucionar los problemas de un rol que no se inicia, vea este artículo de MSDN. Kevin Williamson tiene una excelente publicación de blog que ofrece información general sobre dónde encontrar archivos de registro y qué proceso depurar.

También puede instalar VM Assistant para mirar los archivos de registro y obtener información útil sobre su instancia. Además, puede instalar herramientas, como Network Monitor o Fiddler, para ver qué sucede en la red. Una de las pruebas más sencillas es ejecutar Internet Explorer en la instancia y conectarse al sitio web, ya que le mostrará los detalles de la excepción.

Depuración de un núcleo web hospedado

Si ejecuta un rol de núcleo web hospedado, solo tendrá disponible una ventana de comando en la máquina virtual, por lo que debería abrir una nueva ventana de Cmd ejecutando Start desde el símbolo del sistema o, de lo contrario, obtendrá la experiencia completa de Windows Server. Aquí encontrará una lista de algunos comandos básicos:

  • Start: abre una nueva ventana de Cmd

  • explorer: abre el Explorador de Windows

  • eventvwr: abre el visor de registro de eventos

  • taskmgr: abre el Administrador de tareas

  • start iexplore: ejecuta Internet Explorer

  • services.msc:: abre Service Manager

  • control: abre el Panel de control

  • certmgr.msc: abre el complemento del administrador de certificados

  • regedit: abre el Editor del Registro

  • shutdown /r /t 0: reinicia la instancia de la máquina virtual

  • Iniciar el Administrador de tareas: es útil si pierde el símbolo del sistema y debe iniciar uno nuevo (desde Administrador de tareas, vaya a Archivo > Ejecutar > Cmd)

El Escritorio remoto es la base de un servicio de Azure compatible, pero tiene sus limitaciones cuando aumenta el número de roles y de instancias. Por ejemplo, ¿cómo sabe a qué instancia debe conectarse cuando hay 100 o más? Con este método de solución de problemas, en realidad puede aumentar el tiempo necesario para que el sitio vuelva a estar activo si no sabe dónde buscar ni qué buscar.

Los puntos clave son los siguientes:

  • Habilitar el escritorio remoto en cada rol durante la implementación.

  • Establecer una contraseña conocida segura y asegurarse de que las credenciales no expiren.

  • Probar el acceso para asegurarse de que funcione, antes de que se produzcan problemas.

  • Guardar un archivo RDP para la conexión.

Hay cuatro tareas principales para usar Diagnósticos de Azure:

  1. Configuración de WAD

  2. Configuración de recopilación de datos

  3. Instrumentación del código

  4. Visualización de los datos

Configuración de WAD

La arquitectura de Diagnósticos de Azure está construida de modo que primero se recopilen los datos de la instancia y luego se conserven los datos en el almacenamiento de Azure. Por lo tanto, primero debe ir al Portal de administración de Azure para crear una cuenta de almacenamiento, por ejemplo, mylogs. Una práctica recomendada consiste en ubicar la cuenta de almacenamiento en la misma ubicación geográfica que la aplicación de Azure para evitar pagar costes externos de ancho banda y reducir la latencia.

Una de las grandes características de desarrollo de la versión 1.4 de Azure Tools para Visual Studio (agosto de 2011) y las versiones posteriores es la posibilidad de tener archivos de configuración (ServiceConfiguration.cscfg) diferentes para el equipo local y para la nube. Tal como señala Nick Harris en su blog, esta característica tiene grandes usos. Es útil tener varias configuraciones de servicio para los diagnósticos, ya que facilita el uso del emulador de almacenamiento para realizar pruebas locales de forma gratuita y tener un archivo de configuración diferente para producción. Una de las principales causas para que las aplicaciones no se inicien cuando se publican en Azure es olvidar cambiar una cadena de conexión que contiene UseDevelopmentStorage=true por false.

Visual Studio facilita habilitar los diagnósticos durante las pruebas; para ello, haga clic en el botón Usar el emulador de almacenamiento de Azure:

Cuadros de diálogo de conexión con una cuenta de almacenamiento de Windows Azure

Después de haber probado la aplicación y estar listo para publicarla, deberá configurar una cuenta de almacenamiento para la nube (ServiceConfiguration.Cloud.cscfg). En el blog de David Makogon se encuentran tres razones para tener una cuenta de almacenamiento específicamente para diagnósticos, que sea independiente de su almacenamiento de datos de la aplicación:

  1. Tener una clave de acceso independiente para diagnósticos le permite acceder a los registros sin riesgos para los datos de la aplicación.

  2. No se incurre en gastos por tener varias cuentas de almacenamiento, ya que se basa en el tamaño de los datos.

  3. Tener una cuenta independiente puede mejorar el rendimiento.

A continuación, establezca la cadena de conexión:

<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="DefaultEndpointsProtocol=https;AccountName=<name>;AccountKey=<key>" />

Los valores AccountName y AccountKey se encuentran en el Portal de administración, en la sección de la cuenta de almacenamiento. AccountName es la primera porción de la dirección URL de los extremos de tabla y almacenamiento de blobs (la parte antes de “.table.core.windows.net”). AccountKey es la clave de acceso principal en base 64 para la cuenta de almacenamiento.

De forma predeterminada, solo están habilitados los registros de Azure, pero no se conservan, por lo que luego deberá decidir cuántos datos quiere recopilar y cuándo se deben transferir los registros. Estas no son decisiones triviales, dado que influyen en el rendimiento de su aplicación y determinan cuánto se le cobrará por el almacenamiento cada mes.

En primer lugar, debe decidir cuál será el total de almacenamiento que se necesitará para los datos recopilados por Diagnósticos de Azure. Este valor está dado por el tamaño del disco de su instancia/tamaño de máquina virtual y por la propiedad OverallQuotaInMB de la clase DiagnosticMonitorConfiguration. Por ejemplo, si ha configurado un modelo de servicio para usar un tamaño de máquina virtual ExtraSmall, la cantidad máxima de almacenamiento local disponible son 20 GB. De forma predeterminada, OverallQuotaInMB se establece en 4 GB; es decir, solo tendría un total de 16 GB de almacenamiento local, lo que no sería suficiente para sus archivos de aplicación y temporales. OverallQuotaInMB establece el tamaño de un búfer de ajuste automático reescribible. Por otro lado, si su sitio web tiene mucho tráfico y ha configurado muchos contadores de rendimiento, puede que se sobrescriban los datos de diagnóstico, en particular si no los transfiere a un almacenamiento persistente periódicamente.

Una vez que se haya establecido el tamaño de la máquina virtual, es posible que quiera ir más allá de los 4 GB. Para esto, puede agregar al archivo ServiceDefinition.csdef un elemento <LocalStorage> para DiagnosticStore con el atributo sizeInMB establecido en el nuevo tamaño y cambiar el valor OverallQuotaInMB en consecuencia:

<LocalResources>
      <LocalStorage name="DiagnosticStore" sizeInMB="8192" cleanOnRoleRecycle="false" />
    </LocalResources>

Si establece el valor del atributo cleanOnRoleRecycle en false, se asegura de que el almacenamiento local “DiagnosticStore” no se elimine cuando se recicle el rol. Consulte Apéndice D: ServiceDefinition.csdef para ver el código completo de ServiceDefinition.csdef. Este ajuste no garantiza que se conservarán los datos si se mueve la instancia (problemas de hardware, etc.). Recuerde que la configuración de diagnóstico es específica a un rol, por lo que debe agregar un DiagnosticStore para cada uno de sus roles por separado.

Es sumamente importante calcular el tamaño total de los datos de diagnóstico que ha configurado, ya que Diagnósticos de Azure dará un error si la suma es mayor que OverallQuotaInMB. La única forma de ver este error es adjuntar un depurador o agregar un try catch al método OnStart. Esto es lo que aparece en el registro de eventos de la aplicación si el código catch escribe un evento:

Registro de eventos de Windows Azure

Entonces, ¿cómo calcula la “suma de las subcuotas solicitadas”? Cada tipo de colección de elementos (registros de eventos, contadores de rendimiento, etc.) tiene un búfer de datos asociado que, de forma predeterminada, es cero. La propiedad BufferQuotaInMB se puede dejar en su valor predeterminado de cero, lo que significa menos de OverallQuotainMB, o se puede definir un valor explícito. OverallQuotaInMB debe ser menor que la suma de todas las propiedades BufferQuotaInMB.

Cuando se alcanza la cuota, se eliminan los datos más antiguos a medida que se agregan datos nuevos. Esta directiva de eliminación también se aplica si ha configurado un intervalo de transferencia para el búfer. Una vez realizada la transferencia, los datos permanecen en el almacenamiento local y se eliminan según la directiva anterior.


// Set an overall quota of 8GB.
config.OverallQuotaInMB = 8192;

// Set the sub-quotas and make sure it is less than the OverallQuotaInMB set above
config.Logs.BufferQuotaInMB = 1024;
config.Directories.BufferQuotaInMB = 0; // Use the rest of the storage here
 config.WindowsEventLog.BufferQuotaInMB = 1024;
config.PerformanceCounters.BufferQuotaInMB = 1024;
config.DiagnosticInfrastructureLogs.BufferQuotaInMB = 1024;

Las subcuotas de los directorios se establecen en cero de modo que usen el resto de la cuota de almacenamiento disponible. Si indica un valor específico, debe ser mayor o igual que las otras cuotas, ya que debe ser lo suficientemente grande para contener los registros IIS (rol web) y los volcados de memoria. De forma predeterminada, Directory.QuotaInMB se establece en 1024 MB; es decir, si un volcado de memoria es mayor que un gigabyte, se producirá un error durante la escritura del volcado. Los minivolcados son una forma de reducir el tamaño de los volcados.

Los archivos de volcado completo contienen una memoria de proceso (bytes virtuales) en el momento del bloqueo. Dado que la ejecución es en una versión de Windows de 64 bits, el límite superior de memoria será la memoria física de la máquina. Puede encontrar este valor si mira la columna de memoria de esta tabla de instancia/tamaño de máquina virtual. Por ejemplo, un volcado de memoria completo de una instancia ExtraLarge podría ascender a 14 GB. Evidentemente, este es el peor escenario donde el proceso utiliza toda la memoria disponible pero, ¿no es entonces cuando en verdad quiere capturar el archivo de volcado?

Ahora que sabe cuántos datos de diagnóstico va a recopilar, debe decidir una estrategia para la persistencia de esos datos.

Una opción sería no comenzar a recopilar datos hasta determinar que se ha producido un problema. Esta opción tiene dos defectos:

  1. ¿Cómo sabrá que se ha producido un problema? Si bien se puede esperar que los clientes informen de los problemas graves, ¿qué sucede con los problemas más insidiosos, como una pérdida de memoria?

  2. ¿Cuál es la línea base antes del inicio del problema? ¿La aplicación se ejecuta con un uso del 80 % de CPU en todo momento o este es un síntoma del problema?

Por raro que parezca, esta opción es la más usada, ya que no requiere ningún costo, planificación ni acción. También es, sin duda, la peor opción.

La opción dos es configurar todos los contadores necesarios, pero no conservar los datos en el almacenamiento de Windows Azure. Cuando hay un problema, los datos se pueden examinar o se puede iniciar una transferencia manualmente. Esta parece ser una solución ideal, ya que no genera costos en tanto no haya problemas. Desafortunadamente, los mismos problemas de la opción uno se aplican a la opción dos y aumenta el tiempo de recuperación.

La opción tres consiste en establecer las distintas propiedades ScheduledTransferPeriod con un valor suficientemente pequeño como para garantizar que los datos de diagnóstico no se sobrescriban en la instancia, pero suficientemente grande para que no afecte al rendimiento de la aplicación. El menor período de transferencia que puede especificar es 1 minuto, con suerte cualquier valor inferior se redondeará a 1, por lo que la persistencia no se desactivará. Por lo tanto, asegúrese de que los datos de diagnóstico se transfieran antes de que realmente los necesite.

Un problema común en muchos de los ejemplos de código es que ScheduledTransferPeriod se establece en 1 minuto, lo que afecta adversamente el rendimiento de su aplicación durante la producción. La razón por la que los ejemplos usan el valor mínimo es que pueda comprobar si funciona correctamente. La mayoría de los desarrolladores no quieren esperar 30 minutos para comprobar que se transfirieron los registros. Hay dos caminos para enfrentar esta situación: modificar sistemáticamente la configuración de WAD después de la implementación usando una de las Otras herramientas útiles, o agregar código además de una configuración al archivo ServiceConfiguration.cscfg para aprovechar la característica de varios archivos de configuración del servicio que se menciona anteriormente en esta sección. La configuración se crea de la siguiente forma en ServiceConfiguration.Local.cscfg:

<ConfigurationSettings>
      <Setting name="ScheduledTransferPeriod" value="1" />

Mientras que en ServiceConfiguration.Cloud.cscfg, se ve así:

<ConfigurationSettings>
      <Setting name="ScheduledTransferPeriod" value="30" />

El código en el método OnStart y el evento RoleEnvironmentChanging se verían así:

// Get ScheduledTransferPeriod setting from ServiceConfiguration.cscfg and then set it 
var myScheduledTransferPeriod = RoleEnvironment.GetConfigurationSettingValue("ScheduledTransferPeriod");
TimeSpan myTimeSpan = TimeSpan.FromMinutes(Convert.ToDouble(myScheduledTransferPeriod));
config.Logs.ScheduledTransferPeriod = myTimeSpan;
config.Directories.ScheduledTransferPeriod = myTimeSpan;
config.WindowsEventLog.ScheduledTransferPeriod = myTimeSpan;
config.PerformanceCounters.ScheduledTransferPeriod = myTimeSpan;
config.DiagnosticInfrastructureLogs.ScheduledTransferPeriod = myTimeSpan;

La otra variable que afectará a la cantidad de datos recopilados es el nivel de registro. Una de las fuentes de datos más importante que se debe recopilar son los registros de eventos de la aplicación. Los registros de eventos de la aplicación y, en ocasiones, los registros de eventos del sistema pueden ser útiles. Los registros de eventos de seguridad pueden no estar disponibles a través de WAD. El tamaño de estos archivos se puede mitigar si se usan los valores de filtro siguientes para especificar el nivel de entradas de los registros:

  • Crítico

  • Error

  • Advertencia

  • Información

  • Detallado

El nivel de registro es acumulativo, por lo que si el filtro se define en Advertencia, también se transferirán Error y Crítico. Puede usar el método anterior para configurar niveles de LogLevelFilter específicos para las configuraciones local y de la nube. ServiceConfiguration.Local.cscfg se vería así:

<Setting name="LogLevelFilter" value="Information" />

ServiceConfiguration.Cloud.cscfg se vería así:

      <Setting name="LogLevelFilter" value="Error" />

El código en el método OnStart y el evento RoleEnvironmentChanging se verían así:

// Get LogLevelFilter setting from ServiceConfiguration.cscfg and then set it
var LogLevelFilter = RoleEnvironment.GetConfigurationSettingValue("LogLevelFilter");
var myLogLevel = LogLevel.Undefined;
switch (LogLevelFilter)
{
    case ("Information"):
        myLogLevel = LogLevel.Information;
        break;
    case ("Verbose"):
        myLogLevel = LogLevel.Verbose;
        break;
    case ("Warning"):
        myLogLevel = LogLevel.Warning;
        break;
    case ("Critical"):
        myLogLevel = LogLevel.Critical;
        break;
    case ("Error"):
        myLogLevel = LogLevel.Error;
        break;
    default:
        break;
} 

// Filter what will be sent to persistent storage.
config.Logs.ScheduledTransferLogLevelFilter = myLogLevel;
config.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter = myLogLevel;
config.WindowsEventLog.ScheduledTransferLogLevelFilter = myLogLevel;

El código sugerido puede ajustarse a sus necesidades o no. Para aquellos que no quieren agregar ningún código y prefieren tener la última configuración conocida en lugar de lo definido en el código, hay otra solución.

Uso de un archivo de configuración

El SDK 1.3 de Azure agregó la capacidad de poner la configuración en un archivo XML en lugar de escribir código. David Hardin sostiene que esta es la forma más eficaz de configurar los diagnósticos para todos los tipos de roles de Azure. Este método tiene muchas ventajas en comparación con el de escribir código:

  1. WAD se inicia antes de ejecutar el método OnStart con objeto de detectar los errores de las tareas de inicio.

  2. Cualquier cambio realizado en la configuración en tiempo de ejecución se conservará después de reiniciar.

  3. El agente de diagnóstico se inicia automáticamente con una configuración establecida sin la necesidad de código adicional que pueda provocar una excepción que haga que su rol no se inicie.

  4. Este es el único método para obtener diagnósticos de un rol de máquina virtual beta.

  5. Los cambios en la configuración no requieren que se vuelva a generar el código.

Se puede encontrar un diagnostics.wadcfg de muestra en el Apéndice F: diagnostics.wadcfg. El archivo de configuración llamado diagnostics.wadcfg se debe colocar en la ubicación siguiente y se debe asegurar de establecer la opción Copiar en el directorio de salida en Copiar siempre:

  • Para los roles de trabajo, el archivo de configuración se encuentra en el directorio raíz del rol.

  • Para los roles web, el archivo de configuración se encuentra en el directorio bin del directorio raíz del rol.

  • Para los roles de máquina virtual beta, el archivo de configuración debe ubicarse en la carpeta %ProgramFiles%\Azure Integration Components\<NúmeroVersión>\Diagnostics en la imagen del servidor que va a cargar en el Portal de administración de Azure. <NúmeroVersión> es la versión del SDK de Azure que está usando. En esta carpeta se encuentra un archivo predeterminado que puede modificar o sobrescribir con uno propio.

El formato de este archivo se describe en el siguientedocumento de MSDN. El archivo .wadcfg se omite si ya hay una configuración XML en el contenedor de almacenamiento de blobs wad-control-container. También puede asegurarse de que todo en el archivo esté correcto, de lo contrario, no se recopilarán diagnósticos.

Ahora está listo para decidir qué información quiere recopilar.

Configuración de recopilación de datos

Si no quiere usar un archivo de configuración, el mejor lugar para comenzar el diagnóstico es en el método OnStart dentro de un bloque try/catch. El bloque asegurará que, si hay un problema, lo maneje debidamente, lo que evitará que su rol se quede bloqueado reciclando. El peligro de colocar código en el método OnStart es que si no se encarga de todas las excepciones, el rol entrará en un bucle de reciclado que es difícil de depurar. En este método, la instancia de rol se establece en Ocupado y no está disponible en el equilibrador de carga de Azure. Si el método OnStart devuelve false o si hay una excepción, la instancia de rol se detiene de inmediato. Si el método devuelve true, Azure inicia el rol mediante una llamada al método Run.

Al encapsular el código OnStart en un bloque try/catch, puede evitar que el rol se ejecute en ciclos (el estado en el Portal de administración nunca pasa a Listo) cuando hay una excepción. El código catch puede contener una llamada al método Trace.WriteLine (ejemplo de MSDN) o se puede registrar un error del registro de eventos (blog de depuración de ASP.NET). Al registrar un evento en el registro de eventos es más fácil ver por qué no se inicia un rol. Según lo propuesto por Tom Christian, un leve giro a este código es registrar la excepción en el registro de eventos de la aplicación de este modo:

catch (Exception e)  
    {
            string sSource;
            string sEvent;
            sSource = "WaAppAgent";
            sEvent = "WorkerRole OnStart Event: " + e.Message;
            EventLog.WriteEntry(sSource, sEvent, EventLogEntryType.Error, 0);
    }

El código completo está en el Apéndice B: Ejemplo de código de rol web. El método más eficaz para configurar los diagnósticos es usar tanto un archivo de configuración como un código que le permita cambiar de forma dinámica la configuración desde el Portal de administración.

Ahora que Diagnósticos de Azure está configurado, puede comenzar a recopilar datos. Hay cinco tipos de datos que se pueden recopilar:

  • Volcados de memoria

  • Registro de eventos de Windows

  • Contadores de rendimiento

  • Registros IIS

  • Registros FREB

La tabla siguiente ofrece un resumen de qué datos se recopilan localmente de forma predeterminada y qué datos se deben configurar de manera explícita:

 

Origen de datos Configuración predeterminada Descripción

DiagnosticInfrastructureLogs

Habilitado, se almacena localmente, no hay definida una transferencia al almacenamiento persistente. Se transfiere a la tabla de almacenamiento WADDiagnosticInfrastructureLogsTable

Registros específicos a la infraestructura de diagnóstico misma. En general, no son muy útiles.

Registros

Habilitado, se almacena localmente, no hay definida una transferencia al almacenamiento persistente. Se transfiere a la tabla de almacenamiento WADLogsTable

Registro System.Diagnostics.Trace que se coloca en el código de la aplicación.

Directorios

Los blobs wad-iis-failedreqlogfiles, wad-iis-logfiles y wad-crash-dumps se crean automáticamente de forma predeterminada, cada uno con su propiedad DirectoryQuotaInMB establecida en 1024 MB. También puede configurar directorios adicionales.

Los datos de registro se transferirán según el intervalo de transferencia ScheduledTransferPeriod.

PerformanceCounters

Deshabilitado. Cuando se agregan, el nombre de la tabla de almacenamiento es WADPerformanceCountersTable.

Los contadores de rendimiento deben especificarse explícitamente.

WindowsEventLog

Deshabilitado. Cuando se agregan, el nombre de la tabla de almacenamiento es WADWindowsEventLogsTable.

No se especifican DataSources para los registros de eventos de Windows.

CrashDumps

Los minivolcados de memoria se recopilan localmente. Se pueden habilitar los volcados completos. wad-crash-dumps es el nombre creado en el almacenamiento de blobs.

Llame al método EnableCollection(true) para obtener volcados de memoria completos.

Datos de seguimiento de solicitudes con error de IIS 7.0

Deshabilitado. Cuando se agregan, el nombre del almacenamiento de blobs es wad-iis-failedreqlogfiles.

Debe estar habilitado en Web.config.

  • Volcados de memoria

    Diagnósticos de Azure no recopila volcados de memoria automáticamente. La sintaxis es confusa porque para recopilar minivolcados debe agregar este código:

    // Enable crash mini dump collection.
                    CrashDumps.EnableCollection(false);
    
    El código para recopilar volcados completos se ve así:

                    // Enable full crash dump collection.
                    CrashDumps.EnableCollection(true);
    
    Recuerde cuando hablamos sobre la configuración de Directory.QuotaInMB que, si tiene volcados completos, deberá asignar almacenamiento local y almacenamiento general suficientes para guardar un volcado completo.

  • Registros de eventos

    Los registros de eventos son la forma más útil de buscar errores en la aplicación. Así es como puede agregar eventos de la aplicación y del sistema:

    // Add in configuration settings for Windows Event logs           config.WindowsEventLog.DataSources.Add("Application!*");
    config.WindowsEventLog.DataSources.Add("System!*");
    
    Se recopilarán únicamente los eventos generados después de que se inicie Diagnósticos de Azure, lo que hace que los registros de eventos sean inútiles para diagnosticar problemas de arranque, a menos que use el método recomendado para iniciar y configurar los diagnósticos.

    También puede filtrar ciertos eventos únicamente. En el blog de Steve Marx se explica cómo crear una consulta XPath para obtener solo la información que será útil. Por ejemplo, usar la consulta XPath siguiente con el método Add solo recopilaría mensajes WaAppAgent:

    ("Application!*[System[Provider[@Name='WaAppAgent']]]")
    
  • Contadores de rendimiento

    Los contadores de rendimiento deben agregarse de manera explícita. La dificultad de configurar estos contadores es que si uno está mal, provocará el error de todos los contadores de ese rol. En la ventana de salida del emulador de procesos, verá el siguiente error:

    [MonAgentHost] Error:  PdhExpandWildCardPath(\Process(_Total)) failed
    
    Los roles web y de trabajo puede usar varios lenguajes. Para todos los tipos de roles, los siguientes son los contadores de rendimiento básicos recomendados. El nombre del proceso en el ejemplo siguiente (WaWorkerHost) deberá cambiarse a WaIISHost para un rol web. El código específico para un rol de trabajo que no ejecute código .NET se puede encontrar en el Apéndice C: Ejemplo de código de rol de trabajo:

    • @"\Process(WaWorkerHost)\% Processor Time "

    • @"\Process(WaWorkerHost)\Private Bytes "

    • @"\Process(WaWorkerHost)\Thread Count"

    • @"\Processor(_Total)\% Processor Time"

    • @"\Memory\Available Bytes"

    Para un rol web o un rol de trabajo que ejecute código en lenguaje .NET, existen contadores adicionales que deberán supervisarse. Nuevamente, el nombre del proceso en el ejemplo siguiente (w3wp) deberá cambiarse por WaWorkerHost si se trata de un rol de trabajo y por WaIISHost si usa un rol web en modo IIS completo. Los contadores recomendados para un rol web que ejecute código en lenguaje .NET se pueden encontrar en el Apéndice B: Ejemplo de código de rol web:

    • @"\Process(w3wp)\% Processor Time "

    • @"\Process(w3wp)\Private Bytes "

    • @"\Process(w3wp)\Thread Count "

    • @"\Processor(_Total)\% Processor Time"

    • @"\Memory\Available Bytes"

    • @"\ASP.NET\Applications Running"

    • @"\.NET CLR Interop(_Global_)\# of marshalling"

    • @"\.NET CLR Jit(_Global_)\% Time in Jit"

    • @"\.NET CLR Loading(_Global_)\% Time Loading"

    • @"\.NET CLR LocksAndThreads(_Global_)\Contention Rate / sec"

    • @"\.NET CLR Memory(_Global_)\# Bytes in all Heaps"

    • @"\.NET CLR Networking(_Global_)\Connections Established"

    • @"\.NET CLR Remoting(_Global_)\Remote Calls/sec"

    La cadena WaIISHost deberá cambiarse por w3wp si no se usa el método IIS completo. Como se mencionó anteriormente, ScheduledTransferPeriod determinará cuándo y si los contadores se conservan en el almacenamiento.

  • Registros IIS

    Los roles web de Azure se ejecutan en IIS con el registro habilitado de forma predeterminada, y se escriben en formato W3C codificado en UTF-8 en la carpeta de recursos de su aplicación, por ejemplo, C:\Resources\directory\c5c31518818e46569fa68f0809b5a6aa.fm_WebRole.DiagnosticStore\LogFiles\Web) con la Conversión de archivos de registro establecida en Cada hora. Hay un archivo de registro por sitio. Si entra remotamente en una de sus instancias y abre el Administrador de Internet Information Services, podrá ver la configuración:

    Cuadro de diálogo de registro de Windows Azure

    Las opciones de registro predeterminadas se pueden modificar para ajustarse a sus requisitos particulares. El truco es que los cambios deberán incorporarse a una tarea de arranque para que, en el reinicio de cada instancia, no se pierda la configuración. Por ejemplo, para registrar errores únicamente, usaría Appcmd.exe, que es parte de IIS7 en una tarea de arranque que contendría el comando siguiente:

    appcmd set config /section:httpLogging /dontLog:False /selectiveLogging:LogError
    
  • Error del seguimiento de solicitudes

    Si tiene un rol web, sin duda querrá recopilar los registros de seguimiento de solicitudes con error (antiguamente conocido como almacenamiento en búfer de solicitudes con error o FREB). Para ello, se deben agregar las líneas siguientes a la sección <system.webServer> en el archivo web.config:

    <tracing>
          <traceFailedRequests>
            <add path="*">
              <traceAreas>
                <add provider="ASP" verbosity="Verbose" />
                <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
                <add provider="WWW Server" areas="Authentication, Security, Filter, StaticFile, CGI, Compression, Cache, RequestNotifications,Module" verbosity="Verbose" />
              </traceAreas>
              <failureDefinitions timeTaken="00:00:20" statusCodes="400-599" />
            </add>
          </traceFailedRequests>
        </tracing>
    
    Esto provoca un error en el registro de errores de las solicitudes que lleven más de 15 segundos o con códigos de estado entre 400 y 599 (el elemento failureDefinitions). Una vez creado el registro FREB, se conservará automáticamente en el almacenamiento.

  • Otros directorios

    Puede que también quiera recopilar otros archivos que se escriben en la instancia, en particular, los archivos de agente invitado. Estos archivos pueden darle información sobre lo que sucede entre el agente invitado y el controlador de tejido de Azure. Para ello, deberá configurar un directorio que Diagnósticos de Azure copiará:

              // Add a custom directory transfer
              DirectoryConfiguration directoryConfiguration = new DirectoryConfiguration();
              directoryConfiguration.Container = "wad-custom-logs";
              directoryConfiguration.DirectoryQuotaInMB = 0;
              directoryConfiguration.Path = @"c:\logs\WaAppAgent.log";
              config.Directories.DataSources.Add(directoryConfiguration);
    
    Aquí se aplica la misma salvedad sobre lo que puede suceder si hay un error de configuración. Para probar en el emulador de proceso, deberá crear esta carpeta y asegurarse de que no haya varios roles que ejecuten este código o, de lo contrario, se producirá una infracción de uso compartido. Este error no se producirá en la configuración de la nube, ya que cada instancia es independiente.

Solución de problemas de WAD

Ahora que ha configurado todo, es momento de probarlo tanto en el emulador de proceso como implementado en Azure. ¿Qué ocurre cuando sus diagnósticos no aparecen? En la lista siguiente se enumeran los puntos que hay que comprobar:

  1. Compruebe los blobs en el contenedor de blobs wad-control-container en la cuenta de almacenamiento de diagnósticos. Busque el blob llamado <deploymentID>/<RoleName>/<RoleInstance> (es decir, 3981bcff0eb743ddb9b7574a8821e955/WebRole1/WebRole1_IN_0).

    1. Abra el archivo XML y asegúrese de que esté configurado del modo que espera. Si ve <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes> en un origen de datos dado, significa que los diagnósticos no están configurados para transferir ningún dato.

    2. Si tiene varias instancias y algunas de ellas transfieren diagnósticos pero otras no, compare los archivos XML para asegurarse de que todas estén configuradas correctamente.

    3. Si configura los diagnósticos después de la implementación y los diagnósticos se detienen de forma aleatoria, esto probablemente se deba a que el rol se recicló o a que la instancia se reinició. Cuando una instancia se reinicia, se pierde la configuración personalizada después de la implementación y se usan los diagnósticos configurados en el código. Una de las principales ventajas de usar el archivo .wadcfg es que esta configuración no se sobrescribe cuando se recicla el rol.

  2. Compruebe los registros en la tabla WADDiagnosticInfrastructureLogsTable de la cuenta de almacenamiento de diagnósticos. Querrá filtrar según DeploymentId (es decir, DeploymentId eq 'bd9e149f76e8413aba8865c77326e449'). Busque excepciones o mensajes de error que puedan indicar por qué no se están transfiriendo diagnósticos.

  3. Si la información de Diagnostics.Trace no se está recopilando, asegúrese de que DiagnosticMonitorTraceListener esté configurado en web.config o app.config. En los proyectos en la nube está configurado de forma predeterminada, pero en ocasiones se puede modificar, lo que puede provocar que los diagnósticos no recopilen las instrucciones de seguimiento.

  4. Un problema común es no consultar el almacenamiento de diagnósticos de forma correcta, lo que no devuelve ningún resultado y hace suponer que no se están capturando diagnósticos. Consulte las tablas de diagnósticos, filtrando por DeploymentID, y compruebe si los diagnósticos se están transfiriendo correctamente o no. Algunos de los errores comunes en las consultas son: no filtrar por DeploymentID y no seguir los tokens de continuación.

  5. Después de la implementación, si su instancia no se inicia, asegúrese de que la cuenta de almacenamiento configurada en el archivo ServiceConfiguration.cscfg no esté definida en «UseDevelopmentStorage=true». Si usa una versión posterior a agosto de 2011 de Azure Tools para Visual Studio 2011, recibirá una advertencia. De lo contrario, deberá aplicar el RDP a su instancia y comprobar el archivo de configuración de roles ubicado en la carpeta C:\Config.

  6. Otra cosa que debe comprobarse al conectarse a una instancia es que DiagnosticsAgent.exe y MonAgentHost.exe se estén ejecutando. Suponiendo que es así, puede instalar y adjuntar WinDBG para ver si se lanzan excepciones.

  7. También puede comprobar que los diagnósticos se estén escribiendo localmente.

    • Para el entorno de desarrollo, los archivos .tsf se escribirán en:

      C:\Usuarios\<nombredeusuario>\AppData\Local\dftmp\Resources\<deploymentID>\directory\DiagnosticStore\Monitor\Tables

    • En una instancia en ejecución los archivos se escribirán en:

      C:\Resources\<deploymentID>.<role>\directory\DiagnosticStore\Monitor\Tables

    Actualmente, para leer estos archivos necesita crear una incidencia y enviarla a Microsoft.

  8. Si tiene varias instancias y solo unas pocas no transfieren diagnósticos correctamente, intente restablecer la imagen inicial del rol desde el Portal de administración. Este procedimiento debe usarse como último recurso, ya que perderemos la capacidad de determinar la causa del problema.

Instrumentación del código

Puede que los datos de diagnóstico más importante sean los mensajes de seguimiento que como desarrollador agrega a su propio código. Los datos del sistema pueden mostrar excepciones o mensajes de error de registro. Puede hacer un seguimiento hasta llamadas específicas a sistemas dependientes. La práctica recomendada sería agregar un mensaje de seguimiento al llamar a un sistema dependiente que puede producir un error; por ejemplo, un servicio de autenticación de terceros.

El marco ETW asocia un TraceEventType con cada evento:

 

TraceEventType Nivel Valor Significado

Crítico

1

0x0001

Error fatal o bloqueo de la aplicación

Error

2

0x0002

Error recuperable

Advertencia

3

0x0004

Problema no crítico: puede ser un indicador de problemas más graves en el futuro

Información

4

0x0008

Mensaje de información

Detallado

5

0x0010

Seguimiento de depuración (como información detallada del flujo de ejecución, parámetros, etc.)

Start

0x0100

Inicio de una operación lógica

Stop

0x0200

Parada de una operación lógica

Después de tener un plan para instrumentar el código, basta con agregar el espacio de nombres System.Diagnostics y agregar después mensajes de seguimiento, que en C# serían similares al siguiente:

Trace.WriteLine("LoggingWorkerRole entry point called", "Information");

Dado que Azure comenzó a ejecutarse en la versión completa de IIS (SDK 1.3), el código de la aplicación web se ejecuta en un dominio y proceso de aplicación diferente de RoleEntryPoint. Es decir, los mensajes de seguimiento no aparecerán en el emulador de proceso a menos que agregue un agente de escucha de seguimiento adicional a Web.Config en Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener:

<add type="Microsoft.ServiceHosting.Tools.DevelopmentFabric.Runtime.DevelopmentFabricTraceListener, Microsoft.ServiceHosting.Tools.DevelopmentFabric.Runtime, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="DevFabricListener">
    <filter type=""/>
</add>

Para aplicaciones más complejas, tener una metodología para EventId le permitirá filtrar los registros de manera más eficiente, lo que generará una resolución de problemas más rápida. Si usa WriteLine de C#, EventId siempre será 0. A fin de especificar un EventId, debe usar el método TraceEvent, donde traceType se puede encontrar en la tabla anterior:

Trace.TraceEvent(traceType, eventId, message);

Los mensajes de seguimiento se conservan en la tabla WADLogsTable. Azure asocia automáticamente la siguiente información a cada evento registrado: una marca de tiempo, un contador (que proporciona un control de tiempo más detallado de hasta 100 nanosegundos) e información sobre la implementación, el rol y la instancia de rol. Esto permite restringir los registros a instancias específicas. El mensaje se almacena en formato XML de la forma siguiente:


<Properties>
 <EventTickCount>634402131502204503</EventTickCount>
 <DeploymentId>deployment(28)</DeploymentId>
 <Role>WebRole1</Role>
 <RoleInstance>deployment(28).Sample.WebRole1.0</RoleInstance>
 <Level>3</Level>
 <EventId>20</EventId>
 <Pid>10796</Pid>
 <Tid>7172</Tid>
 <Message>trace message; TraceSource 'Data' event</Message> 
</Properties>

El nivel corresponde a TraceEventType. En la tabla anterior, puede ver que el nivel 3 corresponde a una Advertencia. Si no se especifica TraceEventType o si usa Trace.WriteLine, el nivel se establecerá en 5 (Detallado).

En la mayoría de los casos, el registro estándar debería ser suficiente. Para tipos más detallados de registro, puede crear un agente de escucha de seguimiento personalizado:

Azure Table Query es un proyecto de CodePlex de roles web que le permiten consultar WADLogsTable con una consulta LINQ.

Visualización de sus datos

La razón para recopilar diagnósticos es tenerlos disponibles de inmediato cuando haya un problema. Es decir, que debe comprobar que todo funcione antes de que haya un problema, del mismo modo que debe comprobar que una copia de seguridad de datos funciona correctamente. Para ello, deberá ver los datos de diagnóstico durante la prueba de su aplicación y luego periódicamente para asegurarse de que siga funcionando. También significa crear una línea base para saber cuándo se produce un rendimiento fuera de lo normal.

Todos los datos de Diagnóstico de Azure se almacenan en la cuenta de almacenamiento que especifica cuando se inicia WAD. Puede utilizar el Explorador de servidores de Visual Studio o uno de los muchos storage explorers para visualizar estos datos.

El blob wad-control-container contiene el registro de la infraestructura de diagnóstico misma. Aquí es donde puede ver si los datos se están transfiriendo desde una instancia dada. La identidad del blob tendrá una forma similar a la siguiente:

0aef2b51ad1d49ef915dd41d3ca01f24/WorkerRole1/WorkerRole1_IN_0

Esta identidad se separa en tres partes:

  1. El número largo es el identificador de implementación: 0aef2b51ad1d49ef915dd41d3ca01f24

  2. Nombre de rol: WorkerRole1

  3. Nombre de la instancia: WorkerRole1_IN_0

Cuando hay varias instancias, aumentará el sufijo basado en cero, por ejemplo, WorkerRole1_IN_1 será la segunda instancia.

A continuación encontrará una tabla que muestra dónde se escribe cada uno de los registros:

 

Tipo de registro Formato de almacenamiento de Azure Notas

Registros de Azure generados a partir de su código

Tabla

Debe agregarse el agente de escucha de seguimiento al archivo web.config o app.config. Los archivos se almacenan en WADLogsTable.

Registros de IIS 7.0

Blob

Solo roles web. Se almacena en un contenedor de blobs en la ruta wad-iis-logfiles\<id. de >\<nombre de rol web>\<instancia de rol>\W3SVC1.

Registros de infraestructura de Diagnósticos de Windows

Tabla

Información acerca del servicio de diagnósticos mismo. Se almacena en la tabla WADDiagnosticInfrastructureLogs.

Registros de solicitudes con error

Blob

Solo roles web. Se habilita con las opciones de seguimiento del sistema. Configuración de WebServer en web.config. Se almacena en un contenedor de blobs en la ruta wad-iis-failedreqlogfiles\<id. de implementación>\<nombre de rol web>\<instancia de rol>\W3SVC1.

Registros de eventos de Windows

Tabla

Se habilita modificando DiagnosticMonitor Configuration.WindowsEventLog al establecer la configuración inicial. Se almacena en la tabla WADWindowsEventLogs.

Contadores de rendimiento

Tabla

Se habilita modificando DiagnosticMonitor Configuration. PerformanceCounters. Se almacena en la tabla WADPerformanceCounters. El rol de trabajo del código de muestra configura un contador de rendimiento.

Volcados de memoria

Blob

Se habilita al llamar a CrashDumps.EnableCollection. Se almacena en un contenedor de blobs en la ruta wad-crash-dumps. Puesto que ASP.NET controla la mayoría de las excepciones, normalmente solo es útil para un rol de trabajo.

Registros de errores personalizados

Blob

Para obtener un ejemplo útil sobre cómo usarlo, vea el blog de Neil Mackenzie.

Cuando los datos de los volcados de memoria se transfieren al almacenamiento persistente, se almacenan en el contenedor de blobs wad-crash-dumps. Los registros IIS se transfieren al contenedor de blobs wad-iis-logfiles. Las solicitudes con error se almacenan en el contenedor de blobs wad-iis-failedreqlogfiles.

Los registros de eventos se transfieren a la tabla WADWindowsEventLogs en el almacenamiento persistente. Los contadores de rendimiento se transfieren a la tabla WADPerformanceCounters a intervalos especificados. WADDiagnosticInfrastructureLogs contiene registros sobre la infraestructura de diagnóstico. Los agentes de escucha de seguimiento se encuentra en la tabla WADLogsTable.

Otra herramienta para ver datos de diagnóstico es usar LINQPad con el ejemplo AzureLogsWithLINQPad de Jason Haley.

Administración de diagnósticos

Conservar todos estos archivos de registro en el almacenamiento de Azure costará tiempo y dinero. La solución ideal es poner en práctica un seguimiento “a su debido tiempo” cuando deba resolver un problema en particular. Cuando cambie dinámicamente la configuración de diagnóstico, debe recordar devolverla a la configuración original o cambiar la configuración original si hay algo que deba estar presente siempre. Este paso consciente es especialmente importante si no usa un archivo .wadcfg ya que, en los casos donde se reinicia la instancia, la nueva configuración se sustituirá por las opciones de diagnóstico configuradas en su código.

Los cmdlets de PowerShell de Azure pueden administrar muchos aspectos de sus servicios de Azure en ejecución, incluidos los diagnósticos. Los ejecuta desde el equipo local, y usan las API de Administración y Diagnósticos de Azure para conectarse por Internet a su servicio para enviar información y ajustar parámetros.

Windows PowerShell se instala con Windows 7 y es la evolución de los cmdlets de Administración de servicios instalados con la herramienta de administración de Azure (MMC). Aquí encontrará una lista de algunos de los cmdlets más útiles:

  • Get-DiagnosticConfiguration: obtiene la configuración de búfer para un nombre de búfer especificado (Logs, Directories, PerformanceCounters, WindowsEventLogs o DiagnosticInfrastructureLogs).

  • Para cambiar la configuración de un rol, use el cmdlet Set-DiagnosticConfiguration.

  • Start-OnDemandTransfer: inicia una transferencia a petición del búfer de datos especificado. Mueve los datos al almacenamiento de Azure (ya sea una tabla o un almacenamiento de blobs).

El blog de David Aiken tiene un script para limpiar algunos archivos de registro (archivos de registro de IIS y los archivos XML de wad-control-container). Se debe llamar al cmdlet Clear-Container para cada contenedor. También deberá asegurarse de que las transferencias programadas no se superpongan con la eliminación. Además, deberá idear una estrategia para los registros almacenados en tablas (contadores de rendimiento, registros de eventos, etc.). Algunos usuarios descargan todo del almacenamiento de Azure y lo colocan en una base de datos SQL Server para que ya no se les cobre el almacenamiento y para poder hacer consultas más complejas en los datos.

Al comprender los recursos de diagnóstico de Azure, los desarrolladores pueden crear aplicaciones más compatibles gracias a las prácticas recomendadas de diseño que se describen a continuación.

El estado de una aplicación debe medirse en función de una línea base. El hecho de que aparezca la página de inicio no significa necesariamente que el estado de su aplicación sea correcto. También es necesario comprender el estado y el rendimiento de su lógica comercial para crear una línea base de estado completa.

El paso siguiente consiste en entender cómo se acumula el estado. El primer pilar de un estado correcto es pagar la factura de Azure dentro del plazo. No pagar una suscripción tendrá consecuencias negativas progresivas que llevarán, en última instancia, a que se elimine su aplicación.

Para cada suscripción, un servicio hospedado de Azure tiene cuatro niveles que pueden afectar al estado de su aplicación.

Niveles de estado de mantenimiento de Windows Azure

Por ejemplo, una instancia podría generar un error debido a un error de hardware o podría reiniciarse debido a una actualización de software. Esto no provocará un error en el rol a menos que tenga solo una instancia configurada. De igual modo, cada servicio hospedado se ubica en una región en particular (por ejemplo, EE. UU. Central Sur). Esta información fundamental determinará si su aplicación se verá afectada por un evento que interrumpa el servicio (también conocido como caída). Los errores en los niveles inferiores pueden provocar errores en el nivel de servicio hospedado si en el diseño de la aplicación no se ha incorporado redundancia.

La mayoría de las aplicaciones de Azure exigen arquitecturas más complejas que el diagrama anterior. Su aplicación probablemente se parezca más a esta:

Ejemplo de arquitectura de Windows Azure

La naturaleza distribuida introduce varios posibles puntos de error. Documentar estas rutas críticas hace que la solución de problemas sea más eficaz. Por ejemplo, en el diagrama anterior, ¿cómo podría probar si el error se produjo en el control de acceso?

Para comprender qué salió mal en una aplicación, debe supervisar y registrar el estado de la aplicación. En general, querrá registrar cuatro categorías de información sobre su aplicación:

  • Programática: excepciones, valores de variables clave y cualquier información necesaria para depurar la aplicación.

  • Proceso comercial: auditoría necesaria para seguridad, control de cambios, cumplimiento.

  • Estabilidad del sistema: rendimiento, escalabilidad, rendimiento, latencias.

  • Validación de supuestos comerciales: ¿la aplicación se usa según su diseño?

El elemento más básico del carácter humano es paralizarse cuando se presenta una crisis. El estudio y la práctica le permitirán superar ese instinto. Es por ello que existen los simulacros, y algunas aerolíneas están impartiendo cursos de seguridad ante siniestros. La mayoría de las grandes empresas dedican una gran parte de su presupuesto a planes de recuperación ante desastres. Para las prácticas recomendadas, puede leer Implementación de TI de recuperación ante desastres en el centro de datos de Microsoft.

Simplemente quisiéramos destacar algunas técnicas que acelerarán la solución de problemas en caso de que se presente uno. Saber que su aplicación se ha creado de forma que facilitará la solución de problemas puede reducir la tensión cuando efectivamente haya un problema, a la vez que reduce el tiempo necesario para que el sitio esté operativo. El análisis de coste/beneficio determinará la tolerancia a errores que se integrará en su sistema. Por ejemplo, ¿vale la pena el coste adicional de una copia de seguridad en caliente hecha por el Administrador de tráfico para reducir el tiempo de interrupción?

El Administrador de tráfico de Azure le permite administrar y distribuir el tráfico entrante a sus servicios hospedados de Azure, tanto si se han implementado en el mismo centro de datos como en centros diferentes en todo el mundo. Permite configurar un servicio de conmutación por error para que, en caso de que el servicio principal se caiga, el tráfico se envíe al siguiente servicio disponible de una lista. El software de terceros, como Akamai o Limelight, también ofrece soluciones de equilibrio de carga.

A continuación encontrará un plan de cinco pasos para acelerar la resolución.

El primer paso del plan es tener conocimiento de los problemas apenas se generan. Cuanto más rápido sepa que hay un problema, más rápido podrá implementar un plan ante desastres. Por eso la supervisión es fundamental.

El segundo paso es descubrir el origen del problema: la plataforma Azure o su aplicación. El primer lugar donde mirar es el Panel de servicio de Azure. Este sitio requiere que sepa todos los servicios que usa su aplicación y en qué centro de datos se ha implementado el servicio. La degradación de un servicio basta para afectar a su aplicación.

Una forma de supervisar los eventos de servicio de la plataforma Azure es suscribirse a todas las fuentes RSS en función de su aplicación. Por ejemplo, si su aplicación se hospeda en el centro de datos de EE. UU. Central Norte, se suscribiría a esta fuente RSS.

El almacenamiento de Azure usa dominios de error (bastidor, conmutador de red, alimentación) para limitar el impacto de los errores de hardware. Un falso concepto común sobre el almacenamiento de Azure es que las réplicas de sus datos fuera de una única ubicación (por ejemplo, EE. UU. Central Sur) conmutarán por error automáticamente a una réplica. Si el almacenamiento tiene un problema en una ubicación dada, el acceso a sus datos se verá afectado. Este blog del equipo de almacenamiento ofrece todos los detalles sobre la nueva característica de replicación geográfica.

El tercer paso es localizar el problema. Este tal vez sea el paso más difícil en una aplicación compleja que use varios servicios de Azure. Crear un servicio sin estado ayudará a aislar las distintas partes de su aplicación. Si todos los servicios dependientes se ejecutan con normalidad, debe determinar el estado de sus servicios de proceso. Esto se puede hacer desde el Portal de administración; abra la sección Servicios hospedados, Cuentas de almacenamiento & CDN y elija su implementación. En la ventana de propiedades, verá algo similar a lo siguiente:

Propiedades de implementación de Windows Azure

En este caso, puedo ver que durante los últimos ocho días la implementación se ha ejecutado con normalidad según lo calculado por la diferencia del intervalo de tiempo entre Última operación, Hora de finalización y Última actualización. Si, por otro lado, ve que su implementación se ha anulado o reiniciado recientemente, esto puede ayudarle a señalarle dónde empezar a buscar. Si parece ser un servicio que afecta a todas sus implementaciones en un centro de datos dado, póngase en contacto con Microsoft de inmediato: (866) 676-6546.

El cuarto paso es llevar a cabo los pasos habituales de solución de problemas, como la comprobación de los archivos de registro, los registros de eventos, adjuntar un depurador o usar herramientas, como Procmon o Network Monitor, para ver si encuentra alguna señal del problema. El primer lugar donde buscar en la implementación de un servicio hospedado de Azure es el registro de eventos de la aplicación. Asegúrese de que su aplicación no lance ninguna excepción. Esto parecería ser innecesario, ya que actualmente todo el soporte es gratuito. La verdad es que a menudo podrá encontrar y corregir problemas con mayor rapidez que un ingeniero de soporte de Microsoft preparado que no tiene conocimiento del ámbito total de su aplicación. Si la premisa es “dejar el sitio operativo”, mirar primero es la mejor alternativa.

El quinto paso es ponerse en contacto con los servicios de soporte técnico de Microsoft. Para acelerar la solución de su problema, deberá indicar el identificador federado (Windows Live ID) asociado con el propietario de la cuenta de su suscripción. Esta es la dirección de correo utilizada para iniciar sesión en Microsoft Online Services - Portal del cliente para administrar sus suscripciones. También debería entregar el resultado de su análisis del origen del problema y los errores detectados en los distintos archivos de registro. Puede que el ingeniero de soporte de Microsoft le pida que lo agregue como coadministrador de su suscripción para poder ver el Portal de administración exactamente como lo ve usted.

El rendimiento es como la belleza: depende del ojo con que se mire. ¿Cuál es el umbral en que el rendimiento deja de ser aceptable? ¿Cuándo se agota el tiempo de espera de una página? Incluso si cuantifica el tiempo de carga máximo, eso no garantiza que se carguen las páginas para todos sus clientes. La ruta DNS y la confiabilidad de la red son dos factores clave para determinar los tiempos de carga de las páginas. Por ejemplo, teníamos un cliente en Memphis, Tennessee, cuyo ISP enviaba el tráfico de San Antonio, Texas, por Chicago antes. Microsoft Online Services ofrece una herramienta de prueba de rendimiento que mide los tiempos de respuesta, el ancho de banda y la calidad general de conexión. Si quiere ver la latencia entre los distintos centros de datos de Microsoft, puede usar Azure Statistics de Matthew Rosoff.

Una discusión detallada del rendimiento queda fuera del ámbito de este artículo. Para conocer las prácticas recomendadas de desarrollo en Azure, vea el artículo de TechNet Guía sobre el rendimiento y la flexibilidad de SQL Azure. La solución de problemas de rendimiento comienza por tener una línea base. Es por esto que es fundamental recopilar datos de rendimiento durante un período prolongado. Una vez que tenga la línea base, puede ver las tendencias y las anomalías.

La plataforma Azure ofrece Contratos de nivel de servicio (SLA) que definen los niveles de disponibilidad y conectividad de los distintos servicios. ¿Cuáles son sus SLA? Mi ISP una vez me dijo que no debería usar mi conexión para negocios porque mi paquete no tenía un SLA. La confiabilidad es un poco como el rendimiento, en cuanto a que depende enormemente de la conexión de red subyacente del cliente y depende del ojo de quien mire. Los vínculos anteriores pueden ayudarle a comprender el rendimiento de su conexión de red.

Un error común es suponer que los SLA de la plataforma Azure garantizarán los mismos SLA para su aplicación. En primer lugar, hay quienes no leen la segunda oración, que dice:

En el caso de los procesos, garantizamos que, cuando implemente dos o más instancias de rol en diferentes dominios de error y actualización, los roles orientados a Internet tendrán conectividad externa al menos durante el 99,95 % del tiempo.

A esta oración le falta un calificador adicional de dos palabras: “dos o más instancias de rol por rol”. En otras palabras, tener un rol web y un rol de trabajo, cada uno con una instancia, implica que su aplicación no estará disponible cada vez que haya actualizaciones del SO host o haya algún tipo de recuperación del sistema. El proceso de Azure usa dominios de error para asegurar que se cumpla el SLA.

Otro concepto erróneo es que si elige una versión de SO en particular, no habrá interrupciones debido a las actualizaciones del SO. Si bien esto se cumple para el SO invitado que se ejecuta en su instancia, no es así para el SO host que se ejecuta en el equipo físico que se ejecuta en el centro de datos.

A fin de maximizar la confiabilidad, debe supervisar su sitio de manera interna con los datos de Diagnóstico de Windows Azure y externamente con AzureCheck de Apica, Gomez de Compuware o Pingdom. También debe asegurarse de tener las revisiones de seguridad más recientes y un plan para la comprobación de los cambios en el código.

Al crear una aplicación con Visual Studio, el comportamiento predeterminado es configurar la versión del SO invitado como sigue en el archivo ServiceConfiguration.cscfg:

osFamily="1" osVersion="*"

Esto es útil porque recibirá actualizaciones automáticas, que es una de las ventajas clave de PaaS. Pero no es lo óptimo porque no estará usando el SO más reciente. A fin de usar la versión de SO más reciente (Windows Server 2008 R2), la configuración debe verse así:

osFamily="2" osVersion="*"

Desafortunadamente, muchos clientes deciden quedarse con una versión en particular del SO en un intento de tener mayor tiempo activo al evitar las actualizaciones del SO invitado. Esta estrategia solo es razonable para los clientes empresariales que prueban sistemáticamente cada actualización en un entorno de ensayo y luego programan un intercambio de VIP de la aplicación crítica para su misión, que se ejecuta en producción. Para todos aquellos que no prueban cada actualización del SO invitado, no configurar las actualizaciones automáticas es sinónimo de poner en peligro su aplicación de Azure.

¿Cuál es el plan para cuando deba actualizar el servicio, en especial en una emergencia? Este paso, con frecuencia dejado en el olvido, puede marcar la diferencia entre la caída del sitio y tener que afrontar un problema menor en el entorno de ensayo. Si bien se pone mucho tiempo y esfuerzo en la planificación inicial y la publicación de una aplicación de Azure, muchas veces se supone que las actualizaciones no exigen pruebas exhaustivas, dado que el listón para corregir un cambio es más bajo que en un producto empaquetado. Las regresiones se pueden corregir con rapidez. Desafortunadamente, también pueden crear un error catastrófico.

Cada cambio en una aplicación en producción debe probarse antes de la implementación final en producción. El tiempo adicional bien valdrá la pena ante las posibles consecuencias de un error. Para obtener más información, debería leer Información general sobre la actualización de un servicio de Azure.

Gracias por tomarse su tiempo para leer los temas que se analizan en este documento. Nos encantaría conocer su opinión sobre lo que le ha funcionado a usted. El coste por la interrupción de un servicio debe ponderarse con el coste de recopilar los datos de diagnóstico. Este cálculo debe hacerse antes de pasar a producción. El trabajo necesario para desarrollar aplicaciones confiables para Azure no es nuevo, revolucionario ni implica un reto desde el punto de vista técnico; simplemente exige que los diseñadores y desarrolladores tengan en cuenta los posibles problemas que pueden presentarse en sus aplicaciones y apliquen las prácticas que se describen en este documento.

  • Christian, Tom, “Help with Azure role stuck in Initializing/Busy/Stopped state”, Blog, 25 de febrero de 2011.

  • Cross, Andy, “Tracing to Azure Compute Emulator SDK V1.3”, Blog, 22 de enero de 2011.

  • Haley, Jason, “How To: Query Azure Log Tables with LINQPad”, Blog, 28 de enero de 2010 15:09.

  • Hardin, David, “Configuring WAD via the diagnostics.wadcfg Config File”, Blog, 29 de marzo de 2011.

  • Kelly, Mike, “Tome el control de registro y seguimiento en Azure”, MSDN Magazine, junio de 2010.

  • Mackenzie, Neil, “Custom Diagnostics in Azure”, Blog, 8 de diciembre de 2009.

  • Makogon, David, “Azure Tip of the Day: Separate Diagnostic Storage Account”, Blog, 15 de agosto de 2010.

  • Marx, Steve, “Capturing Filtered Windows Events with Azure Diagnostics”, Blog, 21 de abril de 2010.

  • Mladenov, Toddy, “Collecting Event Logs in Azure”, Blog, 2 de mayo de 2010.

  • Myers, Walter, “Setting Up Performance Counters In Your Azure Web and Worker Roles”, Blog, 31 de enero de 2011.

  • Nakashima, Jim, “Using IntelliTrace to debug Azure Cloud Services”, Blog, 7 de junio de 2010.

  • O’Neil, Jim, “500 and Other Errors in Azure Deployments Blog”, Blog, 11 de abril de 2011 4:47 AM.

  • Stiefel, Michael, “Why Did My Azure Application Crash? Using the Azure Diagnostics API to Find Code Problems”, Blog, 8 de septiembre de 2011.

  • Washam, Michael, “Managing Log Files with Azure PowerShell Cmdlets 2.0”, Blog, 20 de septiembre de 2011.

  • Williamson, Kevin, “Azure Role Architecture”, Blog, 5 de mayo de 2011.

  • Portal de administración de Azure http://manage.windowsazure.com.

  • Curso de aprendizaje de la plataforma Azure: Exercise 3 - Monitoring Applications in Azure.

  • Portal de Azure http://www.microsoft.com/windowsazure/

 

Tejido

Clústeres lógicos de los equipos, que proporcionan un entorno de ejecución de roles dentro de una máquina virtual.

FREB

Seguimiento de solicitudes con error (antiguamente conocido como almacenamiento en búfer de solicitudes con error).

Portal de administración

El Portal de administración de Azure es un portal para administrar, implementar y supervisar los servicios de Azure. Conéctese al Portal de administración en http://manage.windowsazure.com.

REST

REpresentational State Transfer (Transferencia de estado representacional); un diseño de software que usa una arquitectura cliente servidor sin estado en la que los servicios web se ven como recursos y se pueden identificar por sus direcciones URL.

Contrato de nivel de servicio

Contratos de nivel de servicio

Máquina virtual

Emulación mediante software de un equipo que se ejecuta en una partición aislada de un equipo real.

WAD

Diagnósticos de Azure

Rol web

Un rol web es un rol que se personaliza para la programación de aplicaciones web tal como las admiten IIS 7 y ASP.NET.

Rol de trabajo

Un rol de trabajo es un rol que resulta útil para el desarrollo generalizado y puede realizar un procesamiento en segundo plano de un rol web.

Este apéndice se centra en el código necesario para configurar Diagnósticos de Azure. Se llama al método RoleEntryPoint.OnStart para darle la oportunidad de personalizar el arranque de su instancia de rol. Puede proporcionar su propia implementación de OnStart para ejecutar el código necesario para configurar WAD para su rol.

public override bool OnStart()
{
    string sSource = "WaAppAgent";
    string sEvent = null;

    try
    {
        DiagnosticMonitorConfiguration config = DiagnosticMonitor.GetDefaultInitialConfiguration();

        // Set an overall quota of 8GB.
        config.OverallQuotaInMB = 8192;

        // Set the sub-quotas and make sure it is less than the OverallQuotaInMB set above
        config.Logs.BufferQuotaInMB = 1024;
        config.Directories.BufferQuotaInMB = 0; // Use the rest of the storage here
        config.WindowsEventLog.BufferQuotaInMB = 1024;
        config.PerformanceCounters.BufferQuotaInMB = 1024;
        config.DiagnosticInfrastructureLogs.BufferQuotaInMB = 1024;

        // Get ScheduledTransferPeriod setting from ServiceConfiguration.cscfg and then set it 
        var myScheduledTransferPeriod = RoleEnvironment.GetConfigurationSettingValue("ScheduledTransferPeriod");
        TimeSpan myTimeSpan = TimeSpan.FromMinutes(Convert.ToDouble(myScheduledTransferPeriod));
        config.Logs.ScheduledTransferPeriod = myTimeSpan;
        config.Directories.ScheduledTransferPeriod = myTimeSpan;
        config.WindowsEventLog.ScheduledTransferPeriod = myTimeSpan;
        config.PerformanceCounters.ScheduledTransferPeriod = myTimeSpan;
        config.DiagnosticInfrastructureLogs.ScheduledTransferPeriod = myTimeSpan;

        // Get LogLevelFilter setting from ServiceConfiguration.cscfg and then set it
        var LogLevelFilter = RoleEnvironment.GetConfigurationSettingValue("LogLevelFilter");
        var myLogLevel = LogLevel.Undefined;
        switch (LogLevelFilter)
        {
            case ("Information"):
                myLogLevel = LogLevel.Information;
                break;
            case ("Verbose"):
                myLogLevel = LogLevel.Verbose;
                break;
            case ("Warning"):
                myLogLevel = LogLevel.Warning;
                break;
            case ("Critical"):
                myLogLevel = LogLevel.Critical;
                break;
            case ("Error"):
                myLogLevel = LogLevel.Error;
                break;
            default:
                break;
        } 

        // Filter what will be sent to persistent storage.
        config.Logs.ScheduledTransferLogLevelFilter = myLogLevel;
        config.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter = myLogLevel;
        config.WindowsEventLog.ScheduledTransferLogLevelFilter = myLogLevel;

        // Add in configuration settings for Windows Event logs
        config.WindowsEventLog.DataSources.Add("Application!*");
        config.WindowsEventLog.DataSources.Add("System!*");

        // Add a custom directory transfer
        DirectoryConfiguration directoryConfiguration = new DirectoryConfiguration();
        directoryConfiguration.Container = "wad-custom-logs";
        directoryConfiguration.DirectoryQuotaInMB = 0;
        directoryConfiguration.Path = @"c:\logs";
        config.Directories.DataSources.Add(directoryConfiguration);
 

        // Enable full crash dump collection.
        CrashDumps.EnableCollection(true);

        // Use 30 seconds for the perf counter sample rate.
        TimeSpan perfSampleRate = TimeSpan.FromSeconds(30D);

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Memory\Available Bytes",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Processor(_Total)\% Processor Time",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(w3wp)\% Processor Time",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(w3wp)\Private Bytes",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(w3wp)\Thread Count",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR Interop(_Global_)\# of marshalling",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
             CounterSpecifier = @"\.NET CLR Jit(_Global_)\% Time in Jit",
             SampleRate = perfSampleRate
         });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR Loading(_Global_)\% Time Loading",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR LocksAndThreads(_Global_)\Contention Rate / sec",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR Memory(_Global_)\# Bytes in all Heaps",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR Networking(_Global_)\Connections Established",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR Remoting(_Global_)\Remote Calls/sec",
            SampleRate = perfSampleRate
        });

        // Apply the updated configuration to the diagnostic monitor.
        // The first parameter is for the connection string configuration setting.
        DiagnosticMonitor.Start("Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString", config);

        sEvent = "Management OnStart called diagnostics";
        EventLog.WriteEntry(sSource, sEvent, EventLogEntryType. Information, 0);
    }
    catch (Exception e)
    {
        sEvent = "Management OnStart Event: " + e.Message;
        EventLog.WriteEntry(sSource, sEvent, EventLogEntryType.Error, 0);
    }

    return base.OnStart();
}

Este apéndice se centra en el código necesario para configurar Diagnósticos de Azure en un rol de trabajo.

public override bool OnStart()
{
    // Set the maximum number of concurrent connections 
    ServicePointManager.DefaultConnectionLimit = 12;
    string sSource = "WaAppAgent";
    string sEvent = "WorkerRole OnStart Event: ";

    try
    {
        // For information on handling configuration changes
        // see the MSDN topic at http://go.microsoft.com/fwlink/?LinkId=166357.

        DiagnosticMonitorConfiguration config = DiagnosticMonitor.GetDefaultInitialConfiguration();

        // Set an overall quota of 8GB.
        config.OverallQuotaInMB = 8192;
        // Set the sub-quotas and make sure it is less than the OverallQuotaInMB set above
        config.Logs.BufferQuotaInMB = 1024;
        config.Directories.BufferQuotaInMB = 0; // Use the rest of the storage here
        config.WindowsEventLog.BufferQuotaInMB = 1024;
        config.PerformanceCounters.BufferQuotaInMB = 1024;
        config.DiagnosticInfrastructureLogs.BufferQuotaInMB = 1024;

        // Get ScheduledTransferPeriod setting from ServiceConfiguration.cscfg and then set it 
        var myScheduledTransferPeriod = RoleEnvironment.GetConfigurationSettingValue("ScheduledTransferPeriod");
        TimeSpan myTimeSpan = TimeSpan.FromMinutes(Convert.ToDouble(myScheduledTransferPeriod));
        config.Logs.ScheduledTransferPeriod = myTimeSpan;
        config.Directories.ScheduledTransferPeriod = myTimeSpan;
        config.WindowsEventLog.ScheduledTransferPeriod = myTimeSpan;
        config.PerformanceCounters.ScheduledTransferPeriod = myTimeSpan;
        config.DiagnosticInfrastructureLogs.ScheduledTransferPeriod = myTimeSpan;

        // Get LogLevelFilter setting from ServiceConfiguration.cscfg and then set it
        var LogLevelFilter = RoleEnvironment.GetConfigurationSettingValue("LogLevelFilter");
        var myLogLevel = LogLevel.Undefined;
        switch (LogLevelFilter)
        {
            case ("Information"):
                myLogLevel = LogLevel.Information;
                break;
            case ("Verbose"):
                myLogLevel = LogLevel.Verbose;
                break;
            case ("Warning"):
                myLogLevel = LogLevel.Warning;
                break;
            case ("Critical"):
                myLogLevel = LogLevel.Critical;
                break;
            case ("Error"):
                myLogLevel = LogLevel.Error;
                break;
            default:
                break;
        }

        // Filter what will be sent to persistent storage.
        config.Logs.ScheduledTransferLogLevelFilter = myLogLevel;
        config.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter = myLogLevel;
        config.WindowsEventLog.ScheduledTransferLogLevelFilter = myLogLevel;

        // Add in configuration settings for Windows Event logs
        config.WindowsEventLog.DataSources.Add("Application!*");
        config.WindowsEventLog.DataSources.Add("System!*");

        // Add a custom directory transfer
        DirectoryConfiguration directoryConfiguration = new DirectoryConfiguration();
        directoryConfiguration.Container = "wad-custom-logs";
        directoryConfiguration.DirectoryQuotaInMB = 0;
        directoryConfiguration.Path = @"c:\logs";
        config.Directories.DataSources.Add(directoryConfiguration);

        // Enable full crash dump collection.
        CrashDumps.EnableCollection(true);

        // Use 30 seconds for the perf counter sample rate.
        TimeSpan perfSampleRate = TimeSpan.FromSeconds(30D);

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Memory\Available Bytes",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Processor(_Total)\% Processor Time",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(WaWorkerHost)\% Processor Time",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(WaWorkerHost)\Private Bytes",
            SampleRate = perfSampleRate
        }); 
                
        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(WaWorkerHost)\Thread Count",
            SampleRate = perfSampleRate
        });

        // Apply the updated configuration to the diagnostic monitor.
        // The first parameter is for the connection string configuration setting.
        DiagnosticMonitor.Start("Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString", config);

    }
    catch (Exception e)  
        {
                sEvent += e.Message;
                EventLog.WriteEntry(sSource, sEvent, EventLogEntryType.Error, 0);
        } 
            
    return base.OnStart();   
}

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="Windows_Azure_Full_Diagnostics" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="WebRole1">
    <Sites>
      <Site name="Web">
        <Bindings>
          <Binding name="Endpoint1" endpointName="Endpoint1" />
        </Bindings>
      </Site>
    </Sites>
    <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="http" port="8080" />
    </Endpoints>
    <Imports>
      <Import moduleName="Diagnostics" />
      <Import moduleName="RemoteAccess" />
      <Import moduleName="RemoteForwarder" />
    </Imports>
    <ConfigurationSettings>
      <Setting name="ScheduledTransferPeriod" />
      <Setting name="LogLevelFilter" />
    </ConfigurationSettings>
    <LocalResources>
      <LocalStorage name="DiagnosticStore" cleanOnRoleRecycle="false" sizeInMB="8192" />
    </LocalResources>
  </WebRole>
  <WorkerRole name="WorkerRole1" vmsize="Small">
    <Imports>
      <Import moduleName="Diagnostics" />
      <Import moduleName="RemoteAccess" />
    </Imports>
    <LocalResources>
      <LocalStorage name="DiagnosticStore" sizeInMB="8192" cleanOnRoleRecycle="false" />
    </LocalResources>
    <ConfigurationSettings>
      <Setting name="ScheduledTransferPeriod" />
      <Setting name="LogLevelFilter" />
    </ConfigurationSettings>
  </WorkerRole>
</ServiceDefinition>

noteNota
Este archivo de configuración es para su uso local, con el emulador de proceso.

<?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration serviceName="Windows_Azure_Full_Diagnostics" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" osFamily="2" osVersion="*">
  <Role name="WebRole1">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="ScheduledTransferPeriod" value="1" />
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
      <Setting name="LogLevelFilter" value="Verbose" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.Enabled" value="true" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountUsername" value="me" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountEncryptedPassword" value="MIIBnQYJKoZIhvcNAQcDoIIBjjCCAYoCAQAxggFOMIIBSgIBADAyMB4xHDAaBgNVBAMME1dpbmRvd3MgQXp1cmUgVG9vbHMCEDra5x6UQkuIRHdUChkiglEwDQYJKoZIhvcNAQEBBQAEggEAp8ADE0ov0pKTFo6V1AI94NmsUr8YcQ/dl4M63zbBQkrjSvqqzgofMcMwxYVO8gTwmr3eXawTNp2fbPdN68ZynNgRwEHBm67QP3y6lcAFvx8Amxvp8GZ6qxpAYGE8LhpqBNzoel55mot6IZg0I3qfXtl6SHyfLcyGuPv3nDEzhuYGuPSFR+UF82G2ZK0omLzSuI3KQcbFyTxaUYDIu/fSNOkHVOWwgpNND3SIvg+nSHfS38w+nskAA7bo7oN06LnC+3lLNRrpoKsPBaqogqfyhTkivc3+AJoQ6UAHIyyAJU6kfp4iP7gMl0ZU1mLVeqX5oDwmywf9FGRf7vSn2uEfiTAzBgkqhkiG9w0BBwEwFAYIKoZIhvcNAwcECAw305eQdOSogBA6i8i7rTruZOxAadm1g545" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountExpiration" value="2011-12-31T23:59:59.0000000-05:00" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteForwarder.Enabled" value="true" />
    </ConfigurationSettings>
    <Certificates>
      <Certificate name="Microsoft.WindowsAzure.Plugins.RemoteAccess.PasswordEncryption" thumbprint="D91092F38C839BE56787A0528591E49510FCC711" thumbprintAlgorithm="sha1" />
    </Certificates>
  </Role>
  <Role name="WorkerRole1">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
      <Setting name="ScheduledTransferPeriod" value="1" />
      <Setting name="LogLevelFilter" value="Verbose" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.Enabled" value="true" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountUsername" value="me" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountEncryptedPassword" value="MIIBnQYJKoZIhvcNAQcDoIIBjjCCAYoCAQAxggFOMIIBSgIBADAyMB4xHDAaBgNVBAMME1dpbmRvd3MgQXp1cmUgVG9vbHMCEDra5x6UQkuIRHdUChkiglEwDQYJKoZIhvcNAQEBBQAEggEAp8ADE0ov0pKTFo6V1AI94NmsUr8YcQ/dl4M63zbBQkrjSvqqzgofMcMwxYVO8gTwmr3eXawTNp2fbPdN68ZynNgRwEHBm67QP3y6lcAFvx8Amxvp8GZ6qxpAYGE8LhpqBNzoel55mot6IZg0I3qfXtl6SHyfLcyGuPv3nDEzhuYGuPSFR+UF82G2ZK0omLzSuI3KQcbFyTxaUYDIu/fSNOkHVOWwgpNND3SIvg+nSHfS38w+nskAA7bo7oN06LnC+3lLNRrpoKsPBaqogqfyhTkivc3+AJoQ6UAHIyyAJU6kfp4iP7gMl0ZU1mLVeqX5oDwmywf9FGRf7vSn2uEfiTAzBgkqhkiG9w0BBwEwFAYIKoZIhvcNAwcECAw305eQdOSogBA6i8i7rTruZOxAadm1g545" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountExpiration" value="2011-12-31T23:59:59.0000000-05:00" />
    </ConfigurationSettings>
    <Certificates>
      <Certificate name="Microsoft.WindowsAzure.Plugins.RemoteAccess.PasswordEncryption" thumbprint="D91092F38C839BE56787A0528591E49510FCC711" thumbprintAlgorithm="sha1" />
    </Certificates>
  </Role>
</ServiceConfiguration>

Este es un ejemplo de archivo diagnostics.wadcfg para un rol web.

<?xml version="1.0" encoding="utf-8" ?>
<DiagnosticMonitorConfiguration xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration"
      configurationChangePollInterval="PT1M"
      overallQuotaInMB="4096">
  <DiagnosticInfrastructureLogs bufferQuotaInMB="0"
     scheduledTransferLogLevelFilter="Verbose"
     scheduledTransferPeriod="PT1M" />
  <Logs bufferQuotaInMB="0"
     scheduledTransferLogLevelFilter="Verbose"
     scheduledTransferPeriod="PT1M" />
  <Directories bufferQuotaInMB="0"
     scheduledTransferPeriod="PT1M">

    <!-- These three elements specify the special directories 
           that are set up for the log types -->
    <CrashDumps container="wad-crash-dumps" directoryQuotaInMB="0" />
    <FailedRequestLogs container="wad-frq" directoryQuotaInMB="0" />
    <IISLogs container="wad-iis" directoryQuotaInMB="0" />
  </Directories>

  <PerformanceCounters bufferQuotaInMB="0" scheduledTransferPeriod="PT1M">
    <!-- The counter specifier is in the same format as the imperative 
           diagnostics configuration API -->
    <PerformanceCounterConfiguration counterSpecifier="\Memory\Available Bytes" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\Processor(_Total)\% Processor Time" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\Process(w3wp)\% Processor Time" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\Process(w3wp)\Private Bytes" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\Process(w3wp)\Thread Count" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Interop(_Global_)\# of marshalling" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Loading(_Global_)\% Time Loading" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR LocksAndThreads(_Global_)\Contention Rate / sec" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Memory(_Global_)\# Bytes in all Heaps" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Networking(_Global_)\Connections Established" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Remoting(_Global_)\Remote Calls/sec" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Jit(_Global_)\% Time in Jit" sampleRate="PT30S" />
  </PerformanceCounters>
  <WindowsEventLog bufferQuotaInMB="0"
     scheduledTransferLogLevelFilter="Verbose"
     scheduledTransferPeriod="PT1M">
    <!-- The event log name is in the same format as the imperative 
           diagnostics configuration API -->
    <DataSource name="Application!*" />
    <DataSource name="System!*" />
  </WindowsEventLog>
</DiagnosticMonitorConfiguration>

Esta es la configuración predeterminada escrita en el blob wad-control-container.

<?xml version="1.0"?>
<ConfigRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <DataSources>
    <OverallQuotaInMB>4080</OverallQuotaInMB>
    <Logs>
      <BufferQuotaInMB>0</BufferQuotaInMB>
      <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes>
      <ScheduledTransferLogLevelFilter>Undefined</ScheduledTransferLogLevelFilter>
    </Logs>
    <DiagnosticInfrastructureLogs>
      <BufferQuotaInMB>0</BufferQuotaInMB>
      <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes>
      <ScheduledTransferLogLevelFilter>Undefined</ScheduledTransferLogLevelFilter>
    </DiagnosticInfrastructureLogs>
    <PerformanceCounters>
      <BufferQuotaInMB>0</BufferQuotaInMB>
      <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes>
      <Subscriptions />
    </PerformanceCounters>
    <WindowsEventLog>
      <BufferQuotaInMB>0</BufferQuotaInMB>
      <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes>
      <Subscriptions />
      <ScheduledTransferLogLevelFilter>Undefined</ScheduledTransferLogLevelFilter>
    </WindowsEventLog>
    <Directories>
      <BufferQuotaInMB>0</BufferQuotaInMB>
      <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes>
      <Subscriptions>
        <DirectoryConfiguration>
          <Path>C:\Users\me\AppData\Local\dftmp\Resources\c95f5289-7d10-4bff-b105-198904c9ad93\directory\DiagnosticStore\FailedReqLogFiles</Path>
          <Container>wad-iis-failedreqlogfiles</Container>
          <DirectoryQuotaInMB>1024</DirectoryQuotaInMB>
        </DirectoryConfiguration>
        <DirectoryConfiguration>
          <Path>C:\Users\me\AppData\Local\dftmp\Resources\c95f5289-7d10-4bff-b105-198904c9ad93\directory\DiagnosticStore\LogFiles</Path>
          <Container>wad-iis-logfiles</Container>
          <DirectoryQuotaInMB>1024</DirectoryQuotaInMB>
        </DirectoryConfiguration>
        <DirectoryConfiguration>
          <Path>C:\Users\me\AppData\Local\dftmp\Resources\c95f5289-7d10-4bff-b105-198904c9ad93\directory\DiagnosticStore\CrashDumps</Path>
          <Container>wad-crash-dumps</Container>
          <DirectoryQuotaInMB>1024</DirectoryQuotaInMB>
        </DirectoryConfiguration>
      </Subscriptions>
    </Directories>
  </DataSources>
  <IsDefault>true</IsDefault>
</ConfigRequest>

Mostrar:
© 2014 Microsoft