Solución de problemas de las aplicaciones
AppFabric proporciona capacidades para administrar los servicios de .NET Framework versión 4 WCF y WF hospedados por IIS. Estas capacidades incluyen mecanismos de confiabilidad para hospedar servicios de flujo de trabajo durable, configuración de la aplicación simplificada y herramientas para realizar un seguimiento del estado de los servicios de .NET Framework 4 WCF y WF. En esta sección se describe cómo usar las herramientas de seguimiento para solucionar problemas de los servicios.
Use el panel para empezar a solucionar los problemas de los servicios de WCF y WF. Haga clic en el icono Panel del grupo AppFabric en el Administrador de IIS para mostrar la página Panel. Esta página compuesta ofrece una vista resumida del estado de las aplicaciones implementadas en un ámbito determinado en IIS y proporciona vínculos para explorar en profundidad información más específica sobre la solución de problemas. Si las métricas que el panel y sus páginas relacionadas muestran no proporcionan la profundidad de información que necesita para resolver el problema, puede usar las herramientas de AppFabric para habilitar el seguimiento de System.Diagnostics con el fin de solucionar los problemas de una aplicación de WCF o WF.
Solución de problemas mediante el uso del panel
Para aplicaciones distribuidas, aislar un problema no es tan sencillo como consultar un contador o usar sólo una herramienta en el aislamiento. En cambio, la solución de problemas en un entorno de servicio distribuido implica con frecuencia la correlación de datos de diferentes herramientas o contadores para crear una imagen realista de la verdadera causa de un problema. El panel contiene tres widgets, Instancias de WF persistentes, Historial de llamadas WCF e Historial de instancias de WF, que puede usar para correlacionar información y solucionar los problemas de las aplicaciones. Los dos últimos son métricas históricas, lo que significa que la información que aparece se ve afectada por el selector de tiempo Período de tiempo de la parte superior del panel (Último minuto, Últimas 24 horas, etcétera).
Cuando abre o consulta inicialmente uno de los tres widgets, verá una vista resumida de alto nivel del estado de las métricas. Puede ver rápidamente si existe un problema en este nivel. Por ejemplo, el widget Instancias de WF persistentes muestra inicialmente el estado de las instancias de flujo de trabajo durable dinámicas que guardaron su estado en el almacén de persistencia. Ofrece un estado resumido del número de instancias persistentes que se encuentran en los estados Activo, Inactivo y Suspendido. Esto puede informarle rápidamente si hay un problema en el nivel de flujo de trabajo persistente. Puede hacer clic en vínculos de la página resumida para obtener más información sobre ese contador de resumen específico.
Uso de métricas de instancias de WF persistentes
El widget Instancias de WF persistentes muestra el estado de las instancias de flujo de trabajo dinámicas que guardaron su estado en el almacén de persistencia. Muestra el número de instancias persistentes que están en los estados Activo, Inactivo y Suspendido. Cada encabezado, y el propio recuento de resumen, es un vínculo a la página Instancias de WF persistentes que contiene los datos sin procesar.
Para comprender mejor el problema al solucionar problemas de instancias suspendidas, haga clic en el vínculo Instancias suspendidas del panel. La página Instancias de WF persistentes muestra todas las instancias suspendidas. Al seleccionar una de ellas, se llena el panel Detalles de la parte inferior de la pantalla con información resumida sobre la instancia suspendida. La pestaña Errores muestra el motivo por el que se suspendió la instancia. Si necesita más información, puede hacer clic con el botón secundario del mouse y seleccionar la opción Ver eventos supervisados. Esta acción le lleva a la página Eventos supervisados, que muestra todos los eventos supervisados para la instancia de flujo de trabajo suspendida. De forma predeterminada, los eventos se clasifican en orden descendente, con los más recientes arriba.
Uso de las métricas del historial de llamadas WCF
El widget Historial de llamadas WCF muestra el número de llamadas WCF que se recibieron y registraron en el almacén de seguimiento. El encabezado muestra un recuento de resumen de las llamadas finalizadas, las excepciones encontradas o el número de veces que se alcanzó un límite. La primera columna muestra los cinco servicios principales con el mayor número de llamadas completadas. La segunda columna muestra un desglose de los errores de WCF agrupados por tipo de error. La tercera columna muestra los cinco servicios principales con el mayor número de excepciones de servicio. Cada métrica se vincula a la página Eventos supervisados, en la que puede ver los datos sin procesar resumidos en el panel.
Por ejemplo, para obtener más información sobre una llamada errónea, haga clic en el contador de resumen Llamadas erróneas y vaya a la página Eventos supervisados. Esta página se llena con las llamadas de WCF erróneas para el ámbito seleccionado en la jerarquía de IIS. La selección de uno de estos eventos llena el panel Detalles de la parte inferior de la pantalla. La pestaña Errores contiene información de excepción sobre el error. Si necesita más contexto sobre la llamada errónea, puede hacer clic con el botón secundario del mouse en el evento y seleccionar la opción Ver todos los eventos asociados. Esto actualiza la página Eventos supervisados y la llena con todos los eventos relacionados con el primero.
Nota
Para usar la opción Ver todos los eventos asociados, el nivel de seguimiento para la aplicación se debe establecer en Seguimiento de extremo a extremo o superior. Este nivel indica la infraestructura de seguimiento para recopilar eventos de transferencia que asocian un identificador de actividad de extremo a extremo (E2EActivityId) con otro.
Uso de las métricas del historial de instancias de WF
El widget Historial de instancias de WF muestra el número de instancias de flujo de trabajo que se activaron, las erróneas y las finalizadas. La primera columna muestra los cinco servicios principales con el mayor número de activaciones. La segunda columna muestra los cinco servicios principales con el mayor número de instancias erróneas. La tercera columna muestra cuántas instancias erróneas se recuperaron. Por ejemplo, si una instancia de flujo de trabajo encontró un error que causó su suspensión, pero luego se reanudó y finalizó correctamente, verá un recuento de uno en las columnas Erróneas y Recuperadas.
La solución de problemas con la información del widget Historial de instancias de WF es similar a la del widget Instancias de WF persistentes. Haga clic en uno de los encabezados para ir a la página Instancias de WF supervisadas donde puede ver información resumida sobre la instancia de flujo de trabajo. Sin embargo, puesto que el widget Historial de instancias de WF muestra instancias de flujo de trabajo que ya pueden haber finalizado, no verá las acciones de control de instancias que ve en la página Instancias de WF persistentes. En la página Instancias de WF supervisadas puede hacer clic con el botón secundario del mouse en una instancia y consultar los eventos supervisados para ver los datos de seguimiento de nivel inferior para la instancia.
Solución de problemas mediante el seguimiento de System.Diagnostics
AppFabric refuerza las mejoras en el seguimiento de WCF y WF en .NET Framework 4 que emiten eventos al subsistema de Seguimiento de eventos para Windows (ETW). ETW proporciona una infraestructura de seguimiento de eventos rápida. Sin embargo, en algunos escenarios, deberá ver toda la información de diagnóstico disponible. En AppFabric puede habilitar el seguimiento de System.Diagnostics en el nivel de aplicación o de sitio. Esta información de seguimiento se escribe en archivos del disco y se puede consultar con la herramienta Visor de seguimiento de servicios.
Advertencia |
---|
El seguimiento de System.Diagnostics disminuye el rendimiento de las aplicaciones y genera archivos de seguimiento de gran tamaño. Debe habilitar el seguimiento de System.Diagnostics únicamente para solucionar problemas de la aplicación. |
Solución de problemas de una aplicación de ASP.NET distribuida
Puede usar el Id. de actividad (como se mencionó en la sección anterior, Uso de las métricas del historial de llamadas WCF) para buscar el Id. de una instancia duradera y ayudar a solucionar problemas de una aplicación ASP.NET que se comunique entre varios equipos de servidor AppFabric con servicios WCF. Para conseguir este objetivo, el nivel de seguimiento debe estar establecido al menos como Seguimiento de extremo a extremo para configurar el seguimiento de la actividad. Veamos un ejemplo de cómo puede producirse esto.
Mientras realiza un seguimiento de la aplicación web mediante las herramientas de seguimiento ASP e IIS, el administrador observa un aumento en los errores de tiempo de espera para la aplicación ASP.NET mientras se comunica con un servicio. Después de comprobar los errores, el administrador obtiene el Id. de actividad que estaba activo en el momento en que se produjo el error. Mediante el Panel de AppFabric, el administrador crea y ejecuta una consulta del mismo Id. de actividad. Se devuelve un evento (un evento de recepción en la instancia Y del servicio X). El administrador ve el flujo del mensaje asociado con dicho evento y observa un evento “Se ha superado el límite de número máximo de llamadas concurrentes”. Observando las páginas de resumen del servicio, el administrador observa que los “Resultados de limitaciones de WCF” están establecidos en 20. También ve que las llamadas durante el período de las últimas 24 horas presentan un pico en los últimos 30 minutos. Mira otros días y observa lo mismo a la misma hora todos los días. Concluye que la carga aumenta a dichas horas cada día y que es necesario aumentar el valor del límite del número máximo de llamadas concurrentes a 25. Estudiando esto atentamente, el administrador observa que la incidencia de eventos de límite disminuye drásticamente al igual que lo hacen los errores de tiempo de espera para la aplicación ASP.NET al llamar a los servicios WCF.
Tareas de servicio Windows del Agente SQL Server
El servicio Windows de Agente SQL Server supervisa las operaciones de SQL Server, automatiza determinadas tareas administrativas, genera alertas cuando son necesarias, además de programar y ejecutar tareas. Un trabajo de SQL Server es una serie de operaciones especificadas que el Agente SQL Server realiza secuencialmente y que abarcan una variedad de tareas relacionadas con la base de datos. Cuando AppFabric se configura para usar SQL Server, usa el Agente SQL Server para importar eventos al almacén de datos de seguimiento y purgar periódicamente los datos anteriores del almacén.
Si el Agente SQL Server no se ejecuta, las tareas programadas de AppFabric no se pueden ejecutar en la instalación de SQL Server. A continuación se proporcionan algunos pasos para garantizar que estas tareas se ejecutan según lo programado mediante el servicio Windows del Agente SQL Server:
Compruebe el estado del servicio Windows de Agente SQL Server para asegurarse de que esté en ejecución. Haga clic en Herramientas administrativas, seleccione Servicios y, a continuación, Agente SQL Server (MSSQLSVR). Asegúrese de que su Estado muestre actualmente Iniciado. Si no es así, inicie el servicio.
Se crean cuatro tareas de SQL Server cuando se inicializa el almacén:
Microsoft_ApplicationServer_Monitoring_AutoPurge_<nombre de la base de datos de seguimiento>
Microsoft_ApplicationServer_Monitoring_ImportWfEvents_<nombre de la base de datos de seguimiento>
Microsoft_ApplicationServer_Monitoring_ImportWcfEvents_<nombre de la base de datos de seguimiento>
Microsoft_ApplicationServer_Monitoring_ImportTransferEvents_<nombre de la base de datos de seguimiento>
Si el servicio Windows de Agente SQL Server está iniciado y las tareas de AppFabric no se ejecutan, compruebe los errores que se encontraron la última vez que se ejecutó la tarea.
Si las instancias de tarea finalizaron correctamente pero no hay ningún evento en las tablas de eventos, consulte la tabla ASFailedStagingTable del almacén de datos de seguimiento. Esta tabla contiene determinadas columnas, como ErrorNumber y ErrorMessage, que pueden ayudarle a averiguar el motivo del error. Si no se produjo ningún error, esta tabla estará en blanco.
La identidad (el propietario) de Windows bajo la que se ejecuta una tarea de Agente SQL Server de AppFabric no debe ser la del usuario que inició la sesión. En cambio, debe ejecutarse bajo la identidad de la cuenta de seguridad de Windows AS_MonitoringDbJobsAdmin preconfigurada. Esta cuenta debe ser, preferiblemente, una cuenta de dominio. La cuenta recibe los permisos adecuados en el almacén de seguimiento al ejecutar el cmdlet Initialize-ASMonitoringDatabase después de la instalación.
A continuación se indica cómo el Agente SQL Server procesa los diferentes propietarios de una tarea de servidor de AppFabric enviada:
Si el propietario de una tarea de Agente SQL Server es una cuenta de dominio, SQL Server se pone en contacto con el controlador del dominio para comprobar que la cuenta es válida. En caso afirmativo, se ejecuta bajo la cuenta de dominio. De lo contrario, intenta ejecutarse bajo una cuenta local.
Si el propietario de una tarea de Agente SQL Server es una cuenta sysdmin local, el Agente SQL Server aceptará correctamente la identidad “RunAs” en el paso de tarea y emitirá el comando "Ejecutar usuario como AS_MonitoringDbJobsAdmin". Esto significa que la tarea se ejecuta bajo la identidad de la cuenta AS_MonitoringDbJobsAdmin.
Nota
Para ver la identidad “RunAs” de una tarea en SQL Server Management Studio, haga clic con el botón secundario del mouse en la tarea, seleccione Propiedades y, a continuación, haga clic en la pestaña Opciones avanzadas. Este valor se debe establecer en la cuenta AS_MonitoringDbJobsAdmin.
Si el propietario de una tarea de Agente SQL Server es una cuenta local pero no es sysadmin, se pasará por alto la identidad “RunAs” proporcionada en el paso de la tarea. En este caso, el servicio de Agente SQL Server ejecuta la tarea como propietario local.
En el escenario de dominio desconectado (un equipo portátil, por ejemplo), si la identidad de una tarea de seguimiento de SQL Server es un usuario del dominio, el Agente SQL Server intenta validar la cuenta. Para ello, se pone en contacto con el controlador de dominio. Si el equipo que ejecuta la tarea de Agente SQL Server está desconectado del dominio, se generará un error. Para mitigar este error, existen dos opciones:
La primera y más simple de las dos es configurar la tarea (es decir, ejecutar el cmdlet Initialize-ASMonitoringDatabase) con una cuenta de usuario local.
La segunda opción es que un propietario configure una tarea con una cuenta de dominio; más adelante el usuario puede actualizar el propietario de la tarea en una cuenta de usuario local mediante el procedimiento almacenado sp_update_job de SQL Server.
Una práctica recomendable es configurar el servicio Windows de Agente SQL Server para que se ejecute bajo una cuenta de inicio de sesión local. Esto permite al servicio ejecutarse en un equipo con AppFabric aunque su conexión de red haya finalizado. Si el servicio se ejecuta bajo una cuenta de dominio y no se puede obtener acceso a dicho dominio, el servicio Windows de Agente SQL Server no puede obtener las credenciales. Esto significa que los eventos de seguimiento no se pueden mover correctamente a sus tablas de destino finales. El resultado es que ningún dato nuevo aparecerá en el panel.
Tareas de SQL Server Express
Aunque los pasos del diagnóstico del motivo del error de una tarea son muy similares a los de SQL Server, deberá consultar la tabla ASJobsTable para SQL Server Express. Esta tabla es específica de una instalación de SQL Server Express y no está presente en una instalación de SQL Server. En ella puede ver los valores de las columnas LastRunOn y LastRunSuccess en la fila de una tarea específica para determinar si una tarea se ejecutó correctamente o con errores.
SQL Server Express no usa el servicio de Windows de Agente SQL Server. En cambio, aprovecha SQL Service Broker. Esta característica dispone de una capacidad con un valor de tiempo de espera establecido en el intervalo en el que la tarea Microsoft_ApplicationServer_Monitoring_AutoPurge_<nombre de la base de datos de seguimiento> está configurada para ejecutarse. Cuando se agota este intervalo de tiempo de espera, se envía un mensaje a la cola de tareas de SQL Server. Este mensaje activa el procedimiento almacenado que se ejecuta como parte de la tarea Microsoft_ApplicationServer_Monitoring_AutoPurge_<nombre de la base de datos de seguimiento>. A su vez, esto ejecuta la funcionalidad de purga automática en un almacén de SQL Server Express.
A continuación se proporcionan algunas consultas de T-SQL que puede ejecutar como ayuda en el seguimiento del progreso de la funcionalidad de purga automática del almacén:
Muestra las tareas programadas actualmente:
SELECT * FROM ASJobsTable
Consulta la columna dialog_timer (hora UTC) para ver cuándo está programada la siguiente ejecución de la tarea:
SELECT * FROM sys.conversation_endpoints
Muestra el número de procedimientos de activación en ejecución:
SELECT * FROM sys.dm_broker_activated_tasks
Descubre cuántos mensajes siguen en la cola. Cuando no hay tareas en ejecución, devolverá 0:
SELECT * FROM ASScheduledJobQueue
Vea también
Otros recursos
Dashboard Page
Persisted WF Instances Page
Tracked WF Instances Page
Tracked Events Page
2012-03-05