Solución de problemas de estados de agente gris en System Center Operations Manager

En este artículo se describe cómo solucionar problemas en los que un agente, un servidor de administración o una puerta de enlace no están disponibles o están atenuados en System Center Operations Manager (OpsMgr).

Versión original del producto: Microsoft System Center 2012 Operations Manager
Número de KB original: 2288515

Un agente, un servidor de administración o una puerta de enlace pueden tener uno de los siguientes estados, como se indica en el color del nombre y el icono del agente en el panel Supervisión .

Causas de un estado gris

Un agente, un servidor de administración o una puerta de enlace pueden dejar de estar disponibles por cualquiera de los siguientes motivos:

• Error de latido
• Configuración no válida
• Error de flujos de trabajo del sistema
• Problemas de rendimiento de bases de datos o almacenamiento de datos de Operations Manager
• Problemas de rendimiento del servidor de administración o del servidor de puerta de enlace
• Problemas de red o autenticación
• El servicio de mantenimiento no se está ejecutando

Ámbito de problema

Antes de empezar a solucionar el problema atenuado del agente, primero debe comprender la topología de Operations Manager y, a continuación, definir el ámbito del problema. Las siguientes preguntas pueden ayudarle a definir el ámbito del problema:

• ¿Cuántos agentes se ven afectados?
• ¿Están experimentando los agentes el problema en el mismo segmento de red?
• ¿Los agentes notifican al mismo servidor de administración?
• ¿Con qué frecuencia entran y permanecen los agentes en un estado gris?
• ¿Cómo se recupera normalmente de esta situación (por ejemplo, reiniciar el servicio de mantenimiento del agente, borrar la memoria caché y confiar en la recuperación automática)?
• ¿Se generan las alertas de error de latido para estos agentes?
• ¿Se produce este problema durante una hora específica del día?
• ¿Este problema persiste si conmuta por error estos agentes a otro servidor de administración o puerta de enlace?
• ¿Cuándo comenzó este problema?
• ¿Se han realizado cambios en los agentes, los servidores de administración o la puerta de enlace o el grupo de administración?
• ¿Son los agentes afectados sistemas en clúster de Windows?
• ¿Se excluye la carpeta Estado del servicio de mantenimiento del examen antivirus?

Estrategia de solución de problemas

La estrategia de solución de problemas se determinará por qué componente está inactivo, dónde se encuentra ese componente dentro de la topología y qué tan extendido es el problema. Tenga en cuenta las condiciones siguientes:

• Si los agentes que informan a un servidor de administración o puerta de enlace determinados no están disponibles, la solución de problemas debe comenzar en el nivel de puerta de enlace o servidor de administración.
• Si las puertas de enlace que informan a un servidor de administración determinado no están disponibles, la solución de problemas debe comenzar en el nivel de servidor de administración.
• Para sistemas sin agente, para dispositivos de red y para servidores Unix y Linux, la solución de problemas debe comenzar en el agente, el servidor de administración o la puerta de enlace que supervisa estos objetos.
• Normalmente, la solución de problemas se inicia en el nivel inmediatamente superior al componente no disponible.

Escenario 1

Solo algunos agentes se ven afectados por el problema. Estos agentes notifican a diferentes servidores de administración. Los agentes siguen sin estar disponibles de forma periódica. Aunque puede borrar la memoria caché del agente para ayudar a resolver el problema temporalmente, el problema se repite después de unos días.

Resolución del escenario 1

Para resolver el problema en este escenario, siga estos pasos:

1. Aplique la revisión adecuada a los sistemas operativos afectados.
2. Excluya la memoria caché del agente del examen antivirus. Para obtener más información, consulte Recomendaciones para exclusiones de antivirus relacionadas con Operations Manager.
3. Detenga el servicio de mantenimiento.
4. Borre la memoria caché del agente.
5. Inicie el servicio de mantenimiento.

Escenario 2

Solo algunos agentes se ven afectados por el problema. Estos agentes notifican a diferentes servidores de administración. Los agentes permanecen inactivos constantemente. Aunque puede borrar la caché del agente, esto no resuelve el problema.

Resolución del escenario 2

Para resolver el problema en este escenario, siga estos pasos:

1. Determine si el servicio de mantenimiento está activado y se está ejecutando actualmente en el servidor de administración o la puerta de enlace. Si el servicio de mantenimiento ha dejado de responder, genere un volcado de ADPlus en un modo de bloqueo del servicio para ayudar a determinar la causa del problema. Para obtener más información, consulte Uso de ADPlus.vbs para solucionar problemas de "bloqueos" y "bloqueos".

2. Examine el registro de eventos de Operations Manager en el agente para buscar cualquiera de los siguientes eventos:

   Identificador de evento: 1102
   Origen del evento: HealthService
   Descripción del evento:
   La regla o supervisión "%4" que se ejecuta por ejemplo "%3" con id:"%2" no se puede inicializar y no se cargará. Grupo de administración "%1"

   Identificador de evento: 1103
   Origen del evento: HealthService
   Descripción del evento:
   Resumen: %2 reglas/monitores con errores y se descargaron, %3 de ellas alcanzaron el límite de errores que impide la recarga automática. Grupo de administración "%1". Se trata de un evento de solo resumen, consulte otros eventos con descripciones de reglas o monitores descargados.

   Identificador de evento: 1104
   Origen del evento: HealthService
   Descripción del evento:
   No se puede resolver el perfil de RunAs en el flujo de trabajo "%4", que se ejecuta por ejemplo "%3" con id:"%2". El flujo de trabajo no se cargará. Grupo de administración "%1"

   Identificador de evento: 1105
   Origen del evento: HealthService
   Descripción del evento:
   Error de coincidencia de tipos para el perfil de RunAs en el flujo de trabajo "%4", que se ejecuta por ejemplo "%3" con id:"%2". El flujo de trabajo no se cargará. Grupo de administración "%1"

   Identificador de evento: 1106
   Origen del evento: HealthService
   Descripción del evento:
   No se puede acceder al perfil runAs de texto sin formato en el flujo de trabajo "%4", que se ejecuta por ejemplo "%3" con id:"%2". El flujo de trabajo no se cargará. Grupo de administración "%1"

   Identificador de evento: 1107
   Origen del evento: HealthService
   Descripción del evento:
   No se ha definido la cuenta del perfil de ejecución en el flujo de trabajo "%4", que se ejecuta por ejemplo "%3" con id:"%2". El flujo de trabajo no se cargará. Asocie una cuenta con el perfil. Grupo de administración "%1"

   Identificador de evento: 1108
   Origen del evento: HealthService
   Descripción del evento:
   No se puede resolver una cuenta especificada en el perfil de ejecución "%7". En concreto, la cuenta se usa en la invalidación de referencia segura "%6". %n%n Esta condición puede haberse producido porque la cuenta no está configurada para distribuirse a este equipo. Para resolver este problema, debe abrir el perfil de ejecución especificado a continuación, buscar la entrada Cuenta como especifica su SSID y elegir distribuir la cuenta a este equipo si procede, o bien cambiar la configuración en el perfil para que el objeto de destino no use la cuenta especificada. %n%nGrupo de administración: %1 %nEjecutar como perfil: %7 %nSecureReferenceOverride nombre: %6 %nSecureReferenceOverride ID: %4 %nNombre de objeto: %3 %n Id. de objeto: %2 %nAccount SSID: %5

   Identificador de evento: 4000
   Origen del evento: HealthService
   Descripción del evento:
   Un host de supervisión no responde o se ha bloqueado. El código de estado del error de host era %1.

   Identificador de evento: 21016
   Origen de eventos: Conector de OpsMgr
   Descripción del evento:
   OpsMgr no pudo configurar un canal de comunicaciones en %1 y no hay hosts de conmutación por error. La comunicación se reanudará cuando %1 esté disponible y se permita la comunicación desde este equipo.

   Identificador de evento: 21006
   Origen de eventos: Conector de OpsMgr
   Descripción del evento:
   El conector de OpsMgr no se pudo conectar a %1:%2. El código de error es %3(%4). Compruebe que hay conectividad de red, que el servidor se está ejecutando y que ha registrado su puerto de escucha y que no hay firewalls que bloqueen el tráfico al destino.

   Identificador de evento: 20070
   Origen de eventos: Conector de OpsMgr
   Descripción del evento:
   El conector de OpsMgr se conectó a %1, pero la conexión se cerró inmediatamente después de que se produjera la autenticación. La causa más probable de este error es que el agente no está autorizado para comunicarse con el servidor o que el servidor no ha recibido la configuración. Compruebe el registro de eventos en el servidor para ver si hay 20000 eventos, lo que indica que los agentes que no están aprobados están intentando conectarse.

   Identificador de evento: 20051
   Origen de eventos: Conector de OpsMgr
   Descripción del evento:
   No se pudo cargar el certificado especificado porque el certificado no es válido actualmente. Compruebe que la hora del sistema es correcta y vuelva a emitir el certificado si es necesario%n Hora de inicio válida del certificado: %1%n Hora de finalización válida del certificado: %2

   Origen del evento: ESE
   Categoría de eventos: Administrador de transacciones
   Identificador de evento: 623
   Descripción: HealthService (<PID>) El almacén de versiones de instance><("<name>") ha alcanzado su tamaño máximo de <valor> Mb. Es probable que una transacción de larga duración impida la limpieza del almacén de versiones y haga que se compile en tamaño. Novedades se rechazará hasta que la transacción de larga duración se haya confirmado o revertido por completo. Posible transacción de larga duración:
   SessionId: <value>
   Contexto de sesión: <valor>
   ThreadId de contexto de sesión: <valor>.
   Limpieza: <valor>

3. Si encuentra los siguientes eventos específicos, siga estas instrucciones:

   • Eventos 1102 y 1103: estos eventos indican que algunos de los flujos de trabajo no se pudieron cargar. Si estos son los flujos de trabajo principales del sistema, estos eventos podrían provocar el problema. En este caso, céntrese en resolver estos eventos.

   • Eventos 1104, 1105, 1106, 1107 y 1108: estos eventos pueden hacer que se produzcan los eventos 1102 y 1103. Normalmente, esto se produciría debido a cuentas de ejecución mal configuradas. Por ejemplo, las cuentas de ejecución están configuradas para usarse con la clase incorrecta o no están configuradas para distribuirse al agente.

   • Evento 4000: este evento indica que el proceso de Monitoringhost.exe se bloqueó. Si este problema se debe a una falta de coincidencia de DLL o a la falta de claves del Registro, es posible que pueda resolver el problema reinstalando el agente. Si el problema persiste, intente resolverlo mediante los métodos siguientes:

     • Ejecute una captura de Process Monitor hasta el punto en que el proceso se bloquee. Para obtener más información, consulte Monitor de procesos v3.53.
     • Generar un volcado de ADPlus en modo de bloqueo. Para obtener más información, consulte Uso de ADPlus.vbs para solucionar problemas de "bloqueos" y "bloqueos".

   • Identificador de evento 21006: este evento indica que existen problemas de comunicación entre el agente y el servidor de administración. Si el agente usa un certificado para la autenticación mutua, compruebe que el certificado no ha expirado y que el agente usa el certificado correcto. Si se usa Kerberos, compruebe que el agente puede comunicarse con Active Directory. Si la autenticación funciona correctamente, esto puede significar que los paquetes del agente no llegan al servidor de administración o la puerta de enlace. Intente establecer un telnet para el puerto 5723 del agente al servidor de administración. Además, ejecute un seguimiento de red simultáneo entre el agente y el servidor de administración mientras reproduce los errores de comunicación. Esto puede ayudarle a determinar si los paquetes llegan al servidor de administración y si algún dispositivo entre los dos componentes está intentando optimizar el tráfico o está quitando algunos paquetes. Para obtener más información, consulte Recopilación de datos mediante el Monitor de red.

   • Identificador de evento 623: este evento suele producirse en un entorno de Operations Manager grande en el que un servidor de administración o un equipo agente administra muchos flujos de trabajo. Para obtener más información, consulte Uno o varios servidores de administración y sus dispositivos administrados están atenuados en la consola de Operations Manager.

Escenario 3

Todos los agentes que informan a un servidor de administración o puerta de enlace determinados no están disponibles.

Resolución del escenario 3

Para resolver el problema en este escenario, siga estos pasos:

1. Intente determinar qué tipo de cargas de trabajo está supervisando el servidor de administración o la puerta de enlace. Estas cargas de trabajo pueden incluir dispositivos de red, agentes multiplataforma, transacciones sintéticas, agentes de Windows y equipos sin agente.

2. Determine si el servicio de mantenimiento se ejecuta en el servidor de administración o la puerta de enlace.

3. Determine si el servidor de administración se ejecuta en modo de mantenimiento. Si es necesario, quite el servidor del modo de mantenimiento.

4. Examine el registro de eventos de Operations Manager en el agente para ver cualquiera de los eventos que aparecen en el escenario 2. Si hay un identificador de evento 21006, siga las mismas directrices que se mencionan en Resolución para el escenario 2. Además, en este caso, este evento indica que el servidor de administración o la puerta de enlace no se pueden comunicar con su servidor primario. Para una puerta de enlace, el servidor primario puede ser cualquier servidor de administración. (Consulte el paso 3 de la resolución para el escenario 2).

5. Examine el registro de eventos de Operations Manager para ver los siguientes eventos. Estos eventos suelen indicar que existen problemas de rendimiento en el servidor de administración o microsoft SQL Server que hospeda la OperationsManager base de datos o OperationsManagerDW :

   Identificador de evento: 2115
   Origen del evento: HealthService
   Descripción del evento:
   Un origen de datos de enlace en el grupo de administración %1 ha publicado elementos en el flujo de trabajo, pero no ha recibido una respuesta en %5 segundos. Esto indica un problema funcional o de rendimiento con el flujo de trabajo.%n Id. de flujo de trabajo: %2%n Instancia: %3%n Id. de instancia: %4%n

   Identificador de evento: 5300
   Origen del evento: HealthService
   Descripción del evento:
   El servicio de mantenimiento local no está en buen estado. El flujo de cambio de estado de entidad está detenido con confirmación pendiente. %n%nGrupo de administración: %2 %n Id. de grupo de administración: %1

   Identificador de evento: 4506
   Origen del evento: HealthService
   Descripción del evento: Operations Manager
   Los datos se quitaron debido a que hay demasiados datos pendientes en la regla "%2" que se ejecuta por ejemplo "%3" con id:"%4" en el grupo de administración "%1".

   Identificador de evento: 31551
   Origen de eventos: módulos del servicio de mantenimiento
   Descripción del evento:
   No se pudieron almacenar datos en el Data Warehouse. Se volverá a intentar la operación.%rException '%5': %6 %n%nOne o más flujos de trabajo se vieron afectados por esto. %n%nNombre del flujo de trabajo: %2 %nNombre de la instancia: %3 %nInstancia de la instancia: %4 %nGrupo de administración: %1

   Identificador de evento: 31552
   Origen de eventos: módulos del servicio de mantenimiento
   Descripción del evento:
   No se pudieron almacenar datos en el Data Warehouse.%rException "%5": %6 %n%nOne o más flujos de trabajo se vieron afectados por esto. %n%nNombre del flujo de trabajo: %2 %nNombre de la instancia: %3 %nInstancia de la instancia: %4 %nGrupo de administración: %1

   Identificador de evento: 31553
   Origen de eventos: módulos del servicio de mantenimiento
   Descripción del evento:
   Los datos se escribieron en el área de ensayo de Data Warehouse, pero se produjo un error de procesamiento en una de las operaciones posteriores.%rException "%5": %6 %n%nOne o más flujos de trabajo se vieron afectados por esto. %n%nNombre del flujo de trabajo: %2 %nNombre de la instancia: %3 %nInstancia de la instancia: %4 %nGrupo de administración: %1

   Identificador de evento: 31557
   Origen de eventos: módulos del servicio de mantenimiento
   Descripción del evento:
   No se pudo obtener información de estado del proceso de sincronización de Data Warehouse base de datos. Se volverá a intentar la operación.%rException '%5': %6 %n%nOne o más flujos de trabajo se vieron afectados por esto. %n%nNombre del flujo de trabajo: %2 %nNombre de la instancia: %3 %nInstancia de la instancia: %4 %nGrupo de administración: %1

6. El identificador de evento 3155X también se puede registrar debido a configuraciones incorrectas de cuenta de ejecución o a que faltan permisos para las cuentas de ejecución.

Escenarios 4

Todos los agentes que informan a un servidor de administración específico alternan intermitentemente entre estados correctos y grises. O bien, todos los agentes del entorno alternan intermitentemente entre estados correctos y grises.

Resolución del escenario 4

Para resolver el problema, determine primero la causa del problema. Entre las causas comunes de la falta de disponibilidad del servidor temporal se incluyen las siguientes:

• El servidor primario de los agentes está temporalmente sin conexión.
• Los agentes inundan el servidor de administración con datos operativos, como alertas, estados, detecciones, etc. Esto puede provocar un mayor uso de los recursos del sistema en la base de datos de Operations Manager y en los servidores de Operations Manager.
• Las interrupciones de red provocaron un error de comunicación temporal entre el servidor primario y los agentes.
• Se han producido cambios en el módulo de administración (MP). En la consola de Operations Manager, estos cambios requieren una configuración de Operations Manager y una redistribución de MP a los agentes. Si el cambio afecta a una base de agentes mayor, esto puede provocar un mayor uso del uso de recursos del sistema en la base de datos de Operations Manager y en los servidores de Operations Manager.

La clave para solucionar problemas en estos escenarios es comprender la duración de la falta de disponibilidad del servidor y la hora del día durante la que se produjo. Esto le ayudará a restringir rápidamente el ámbito del problema.

Solución de problemas de rendimiento del servidor de administración y la puerta de enlace

Servidor de administración

Durante una ráfaga de actualización de configuración (causada por la importación y detección de MP), los cuellos de botella típicos son, en primer lugar, la CPU y, en segundo lugar, la E/S del disco de instalación de Operations Manager. El servidor de administración es responsable de reenviar los archivos de configuración a los agentes de destino.

Para la recopilación de datos operativos, los cuellos de botella suelen deberse a la CPU. La E/S del disco también puede tener la capacidad máxima, pero no es tan probable. El servidor de administración es responsable de descomprimir y descifrar los datos operativos entrantes e insertarlos en la base de datos operativa. También envía confirmaciones (ACL) a los agentes o puertas de enlace después de recibir datos operativos y usa la cola de disco para almacenar temporalmente estas ACL salientes.

Puerta de enlace

La puerta de enlace está enlazada a la CPU y enlazada a E/S. Cuando la puerta de enlace retransmite una gran cantidad de datos, las operaciones de CPU y E/S pueden mostrar un uso elevado. La mayor parte del uso de CPU se debe a la descompresión, compresión, cifrado y descifrado de los datos entrantes, y también a la transferencia de esos datos. Todos los datos recibidos por la puerta de enlace y de los agentes se almacenan en una cola persistente en el disco, para que el servicio de mantenimiento de la puerta de enlace lea y reenvíe al servidor de administración. Esto puede provocar un uso intensivo del disco. Este uso puede ser significativo cuando la puerta de enlace se desconecta temporalmente y, a continuación, debe controlar los datos de agente acumulados que los agentes generaron e intentaron enviar cuando la puerta de enlace todavía estaba sin conexión.

Para solucionar el problema en esta situación, recopile la siguiente información para cada servidor de administración o puerta de enlace afectados:

• Número exacto de versión, edición y compilación de Windows

• Número de procesadores

• Cantidad de RAM

• Unidad que contiene la carpeta Estado del servicio de mantenimiento

• Si el software antivirus está configurado para excluir el almacén del servicio de mantenimiento

  Nota:

  Para obtener más información, consulte Recomendaciones para exclusiones de antivirus relacionadas con Operations Manager.

• Nivel RAID (0, 1, 50+1 o 1+0) para la unidad que usa el estado del servicio de mantenimiento

• Número de discos usados para RAID

• Si la memoria caché de escritura respaldada por batería está habilitada en el controlador de matriz

Solución de problemas de rendimiento SQL Server

Base de datos operativa (OperationsManager)

Para la OperationsManager base de datos, el cuello de botella más probable es la matriz de disco. Si la matriz de discos no tiene la capacidad máxima de E/S, el siguiente cuello de botella más probable es la CPU. La base de datos experimentará ralentizaciones ocasionales y tormentas de datos operativos (alta incidencia de eventos, alertas y datos de rendimiento o cambios de estado que persisten durante un tiempo relativamente largo). Una ráfaga corta normalmente no causa ningún retraso significativo durante un período de tiempo prolongado.

Durante la inserción de datos operativos, los discos de base de datos se usan principalmente para las escrituras. El uso de CPU se debe a SQL Server renovación. Esto puede ocurrir cuando tiene consultas grandes y complejas, inserción de datos intensiva y limpieza de tablas grandes (que, de forma predeterminada, se produce a medianoche). Normalmente, el aseo de incluso grandes eventos y tablas de datos de rendimiento no consume recursos excesivos de CPU o disco. Sin embargo, la limpieza de las tablas de cambios de estado y alertas puede consumir mucha CPU para las tablas grandes.

La base de datos también está enlazada a la CPU cuando controla las ráfagas de redistribución de configuración, que son causadas por importaciones de MP o por un cambio de espacio de instancia grande. En estos casos, el servicio Config consulta la base de datos para obtener una nueva configuración de agente. Por lo general, esto hace que se produzcan picos de CPU en la base de datos antes de que el servicio envíe las actualizaciones de configuración a los agentes.

Almacenamiento de datos (OperationsManagerDW)

Para la OperationsManagerDW base de datos, el cuello de botella más probable es la matriz de disco. Esto suele ocurrir debido a grandes inserciones de datos operativos. En estos casos, los discos están ocupados principalmente realizando escrituras. Normalmente, los discos realizan pocas lecturas, excepto para controlar las vistas de informes generadas manualmente porque ejecutan consultas en el almacenamiento de datos.

El uso de CPU se debe a SQL Server renovación. Los picos de CPU pueden producirse durante una actividad de creación de particiones pesada (cuando las tablas se convierten en grandes y, a continuación, se crean particiones), la generación de informes complejos y grandes cantidades de alertas en la base de datos, con las que el almacenamiento de datos debe sincronizarse constantemente.

Solución de problemas generales

Para solucionar el problema en esta situación, recopile la siguiente información para cada servidor de administración o puerta de enlace afectados:

• Número exacto de versión, edición y compilación de Windows

• Número de procesadores

• Cantidad de RAM

• Cantidad de memoria asignada a SQL Server

• Si SQL Server es de 32 bits y está habilitado para AWE

  Puede encontrar la mayor parte de esta información en SQL Server Management Studio o en SQL Server Enterprise Manager. Para ello, abra la ventana Propiedades del servidor y, a continuación, seleccione las pestañas General y Memoria . La pestaña General incluye la versión de SQL Server, la versión de Windows, la plataforma, la cantidad de RAM y el número de procesadores. La pestaña Memoria incluye la memoria que se asigna a SQL Server. En Microsoft SQL Server 2008, la pestaña Memoria también incluye la opción AWE.

  Si el sistema operativo es de 32 bits y la RAM es de 4 GB o superior, compruebe si los /pae conmutadores o /3gb existen en el Boot.ini. archivo. Estas opciones se podrían configurar incorrectamente si el servidor se instaló originalmente con 4 GB o menos de RAM y si la RAM se actualizó más adelante.

  En el caso de los servidores de 32 bits que tienen 4 GB de RAM, el /3gb cambio en Boot.ini aumenta la cantidad de memoria que SQL Server puede abordar (de 2 GB a 3 GB). En el caso de los servidores de 32 bits que tienen más de 4 GB de RAM, el /3gb conmutador de Boot.ini podría limitar realmente la cantidad de memoria que SQL Server puede abordar. Para estos sistemas, agregue el /pae conmutador a Boot.ini y, a continuación, habilite AWE en SQL Server.

  En un sistema multiprocesador, compruebe la configuración Grado máximo de paralelismo (MAXDOP). En SQL Server 2008, esta opción se encuentra en la pestaña Avanzadas del cuadro de diálogo Propiedades del servidor.

  El valor predeterminado es 0, lo que significa que se usarán todos los procesadores disponibles. Una configuración de 0 es correcta para los servidores que tienen ocho o menos procesadores. En el caso de los servidores que tienen más de ocho procesadores, el tiempo que se tarda SQL Server en coordinar el uso de todos los procesadores puede ser contraproducente. Por lo tanto, para los servidores que tienen más de ocho procesadores, por lo general debe establecer grado máximo de paralelismo en un valor de 8. Para ello, ejecute el siguiente comando en el Analizador de consultas sql:

  sp_configure 'show advanced options', 1
  GO
  RECONFIGURE WITH OVERRIDE
  GO
  sp_configure 'max degree of parallelism', 8
  GO
  RECONFIGURE WITH OVERRIDE
  GO
  

• Letras de unidad que contienen archivos de almacenamiento de datos, base de datos de Operations Manager y Tempdb

• Si el software antivirus está configurado para excluir archivos de registro y datos SQL (examinar SQL Server archivos de base de datos con software antivirus puede degradar el rendimiento).

• Cantidad de espacio libre en las unidades que contienen archivos de almacenamiento de datos, base de datos de Operations Manager y Tempdb

• Tipo de almacenamiento (SAN o local)

• Nivel RAID (0, 1, 5, 0+1 o 1+0) para las unidades que usa SQL Server

• Si se usa el almacenamiento SAN: número de ejes en cada LUN que usa SQL Server

• Si se usa o se ha usado el módulo de administración de Exchange 2007 convertido: número de filas de la tabla en la LocalizedText base de datos de Operations Manager y en la EventPublisher tabla de la base de datos de almacenamiento de datos

  Para determinar los importes de fila, ejecute los siguientes comandos:

  USE OperationsManager SELECT COUNT(*) FROM LocalizedText
  USE OperationsManagerDW SELECT COUNT(*) FROM EventPublisher
  

Contadores para identificar la presión de memoria

Contadores para identificar la presión del disco

Capture estos contadores de disco físico para todas las unidades que contienen datos SQL o archivos de registro:

• % de tiempo de inactividad: cuánto tiempo de inactividad de disco se está notificando. Cualquier cosa por debajo del 50 por ciento podría indicar un cuello de botella de disco.

• Longitud media de cola de disco: este valor no debe superar el doble del número de ejes de un LUN. Por ejemplo, si un LUN tiene 25 ejes, se acepta un valor de 50. Sin embargo, si un LUN tiene 10 ejes, un valor de 25 es demasiado alto. Puede usar las fórmulas siguientes en función del nivel RAID y el número de discos en la configuración de RAID:

  • RAID 0: todos los discos están trabajando en un conjunto RAID 0

  • Longitud <media de la cola de disco= # (Discos en la matriz) *2

  • RAID 1: la mitad de los discos están trabajando; por lo tanto, solo la mitad de ellos se puede contar para la cola de disco

  • Longitud <media de la cola de disco= # (Discos en la matriz/2) *2

  • RAID 10: la mitad de los discos están "haciendo trabajo"; por lo tanto, solo la mitad de ellos se puede contar para la cola de disco

  • Longitud <media de la cola de disco= # (Discos en la matriz/2) *2

  • RAID 5: Todos los discos están trabajando en un conjunto RAID 5

  • Longitud <media de la cola de disco= # Discos de la matriz *2

  • Promedio de segundos de disco/transferencia: el número de segundos que se tarda en completar una E/S de disco

  • Promedio de segundos de disco/lectura: el tiempo medio, en segundos, para leer datos del disco

  • Promedio de segundos de disco/escritura: el tiempo medio, en segundos, para escribir datos en el disco

    Los tres últimos contadores de esta lista deben tener de forma coherente valores de aproximadamente .020 (20 ms) o inferiores y nunca deben superar .050 (50 ms). Los siguientes son los umbrales que se documentan en la guía de solución de problemas de rendimiento de SQL Server:

    • Menos de 10 ms: muy bueno
    • Entre 10 y 20 ms: ok
    • Entre 20 y 50 ms: lento, necesita atención
    • Mayor que 50 ms: cuello de botella grave de E/S

  • Bytes de disco por segundo: número de bytes que se transfieren al disco por segundo o desde él

  • Transferencias de disco/s: el número de operaciones de entrada y salida por segundo (IOPS)

  Cuando % de tiempo de inactividad es bajo (10 por ciento o menos), esto significa que el disco se utiliza por completo. En este caso, los dos últimos contadores de esta lista (Bytes de disco/s y Transferencias de disco/s) proporcionan una buena indicación del rendimiento máximo de la unidad en bytes y en IOPS, respectivamente. El rendimiento de una unidad SAN es muy variable, dependiendo del número de ejes, la velocidad de las unidades y la velocidad del canal. La mejor opción es consultar con el proveedor de SAN para averiguar cuántos bytes e IOPS debe admitir la unidad. Si % de tiempo de inactividad es bajo y los valores de estos dos contadores no cumplen el rendimiento esperado de la unidad, póngase en contacto con el proveedor de SAN para solucionar problemas.

SQL Server guía de solución de problemas de rendimiento proporciona información más detallada sobre la solución de problemas SQL Server rendimiento.

Contadores de rendimiento de Operations Manager

En las secciones siguientes se describen los contadores de rendimiento que puede usar para supervisar y solucionar problemas de rendimiento de Operations Manager.

Rol de servidor de puerta de enlace

Contadores de rendimiento generales

Estos contadores indican el rendimiento general de la puerta de enlace:

Operations Manager procesa contadores de rendimiento genéricos

Estos contadores indican el rendimiento general de los procesos de Operations Manager en la puerta de enlace:

Contadores de rendimiento específicos de Operations Manager

Estos contadores son contadores específicos de Operations Manager que indican el rendimiento de aspectos específicos de Operations Manager en la puerta de enlace:

Rol de servidor de administración

Contadores de rendimiento generales

Estos contadores indican el rendimiento general del servidor de administración:

Operations Manager procesa contadores de rendimiento genéricos

Estos contadores indican el rendimiento general de los procesos de Operations Manager en el servidor de administración:

Contadores de rendimiento específicos de Operations Manager

Estos contadores son contadores específicos de Operations Manager que indican el rendimiento de aspectos específicos de Operations Manager en el servidor de administración: