Calidad de la evaluación

La característica de calidad de la evaluación es una mejora en la hoja de requisitos previos anterior.

Característica de calidad de la evaluación a petición

Las conclusiones de la evaluación son tan buenas como los datos recopilados para afirmar esas conclusiones. El descubrimiento y la recopilación de datos incorrectos degradan el valor de los resultados de la evaluación y pueden contribuir a la percepción de una calidad deficiente. A veces estos problemas también pasan desapercibidos sin una capacidad para exponerlos y proporcionar instrucciones que se puedan procesar para resolverlos. Esta mejora importante en el módulo área de enfoque de los requisitos previos existentes en el panel de evaluación de Azure Log Analytics se desarrolló pensando en dos objetivos:

• Problemas de calidad de la evaluación de Surface para permitirle tener la oportunidad de remediar y volver a ejecutar la evaluación para garantizar una buena calidad de evaluación.
• Minimiza la necesidad de elevar los vales de soporte técnico para solucionar problemas de calidad de envío de datos mediante la oferta de contenido de corrección específico y accionable.

Específicamente, las capacidades llevadas al mercado que mejoran el módulo de área de enfoque de requisitos previos existentes son:

1. Categorización de los Estados de error potenciales en las fases de ejecución de la evaluación inicial que incluyen la recopilación de requisitos previos y detección.

2. Índice de calidad de la evaluación y visualmente una tasa de éxito de% para la recopilación de datos de evaluación.

3. Un gráfico de anillos actualizado para representar visualmente las categorías y el índice de calidad de la evaluación.

¿Qué representa el “índice de calidad de la evaluación”?

AssessmentQualityIndex = Flujos de trabajo de requisitos previos superados/Flujos de trabajo de requisitos previos totales

Cuando se ejecute la evaluación, ejecutaremos varios recopiladores y, a continuación, ejecutaremos analizadores en los resultados. Si se produce un error en algún recopilador (porque WMI Remoting ha fallado en un destino), no tendremos nada para ejecutar un análisis. Esto dará como resultado un resultado incompleto de la evaluación que reduce la calidad que le entregamos.

Los requisitos previos se crearon inicialmente para solucionar este problema. Antes de ejecutar recopiladores, ejecutamos los recopiladores en “modo de requisitos previos” para probar si se cumplen determinados requisitos previos (comprobaremos que WMI Remoting está activado en el destino). Si se produce un error en alguno de los requisitos previos, se exponen estos errores en el portal de Azure con el módulo “requisitos previos”; sin embargo, la implementación inicial de los requisitos previos no mostraba al usuario final una visión general correcta de la calidad de la evaluación.

Considere el siguiente escenario: Está ejecutando los destinos ADAssessment y 100 se identifican durante la detección. Ejecutamos un recopilador en el modo de requisitos previos para confirmar que WMI Remoting está activado, pero se produce un error en todos los objetivos porque no se ha activado WMI Remoting en su entorno. Antes de Calidad de la evaluación, vería un único error de requisitos previos en Azure relacionado con “La comunicación remota de WMI no está habilitada”. Sin embargo, en realidad habría 100 flujos de trabajo de requisitos previos erróneos y la evaluación apenas tendría nada que analizar, lo que daría lugar a un resultado deficiente. Esto no era necesariamente obvio, ya que solo se podía ver un error de requisito previo único en Azure.

Ahora, con la característica de calidad de la evaluación, proporcionamos un índice de calidad de la evaluación, que es simplemente el porcentaje de flujos de trabajo de requisitos previos superados/requisitos previos. De este modo, en el ejemplo anterior, vería un índice de calidad de evaluación del 0 % o 1 %, lo que hace evidente que la calidad de la evaluación global era muy mala debido a errores de requisitos previos.

Nota:

En la vida real, ADAssessment probablemente ejecuta una variedad más amplia de flujos de trabajo de requisitos previos, no solo WMI Remoting, por lo que lo más probable es que vea un índice de calidad de evaluación más alto.

¿Cuál es la diferencia entre el error de detección, los errores de requisitos previos importantes y otros errores de requisitos previos?

La evaluación pasa por varias fases cuando se ejecuta. En primer lugar, ejecutamos el descubrimiento para encontrar los distintos nodos que se evaluarán. A continuación, ejecutamos varios recopiladores en el modo de requisito previo. Por último, ejecutaremos los recopiladores como de costumbre y, después, el análisis.

Los requisitos previos se refieren principalmente a las dos primeras fases: Los descubrimientos y recopiladores se ejecutan en el modo de requisito previo.

El archivo de resultados de los requisitos previos ahora especificará la fase en la que se ha producido un error de requisitos previos y lo mostraremos en Azure.

¿Por qué a veces la clave importante errores de requisitos previos solo aparece en el gráfico de anillos o la leyenda?

Cuando los autores de IP crean sus evaluaciones, pueden marcar los flujos de trabajo como importantes. Esto significa que el flujo de trabajo es fundamental para la calidad de la evaluación. Si la evaluación no tiene definidos flujos de trabajo importantes, no mostraremos los errores de requisitos previos que son importantes en el gráfico de anillos o la leyenda en Azure.

¿Por qué a veces solo se muestran “errores de detección”, pero no las otras categorías de Azure?

Si durante la detección se produce un error en la prueba MVE (entorno mínimo viable), significa que no se cumplieron ciertos prerequisitos fundamentales (no se encontraron servidores SQL en SQLAssessment). En ese caso, los recopiladores ni siquiera se ejecutan en el modo de requisitos previos. Cuando esto sucede, solo se muestran los errores de detección en Azure.

¿Por qué veo un módulo de calidad de la evaluación en blanco?

No todas las máquinas de recopilación de datos/tareas programadas que envían datos a este área de trabajo de Log Analytics han vuelto a ejecutar la evaluación con los nuevos bits de calidad de la evaluación. Se resolverá automáticamente una vez que:

1. Todas las máquinas de recopilación de datos y las tareas programadas en esos equipos hayan vuelto a ejecutar la evaluación con nuevos bits, O
2. El periodo de retención de datos (el valor predeterminado es 30 días) hace que los datos antiguos se detengan, dejando únicamente los datos "buenos" que se generaron después de que se publicara la característica de calidad de la evaluación.

La característica de calidad de la evaluación necesitaba agregar una nueva columna CustomData a los archivos de resultados de la evaluación y la nueva experiencia de usuario analiza esta nueva columna CustomData para generar las estáticas que se muestran en la nueva hoja de calidad de evaluación.

Esto complicaba la compatibilidad con versiones anteriores. La nueva experiencia de usuario solo funciona si ha ejecutado la evaluación con los nuevos cambios del cliente ODA que rellenarán la columna CustomData. Así que tenemos código en la experiencia del usuario que identificará si el área de trabajo de log Analytics tiene registros con CustomData rellenado, lo que significa que la evaluación se ha ejecutado con los nuevos bits. Si no es así, volveremos al antiguo módulo de requisitos previos. Si EXISTE CustomData, entonces mostraremos la nueva hoja de calidad de evaluación.

Sin embargo, es posible que varias máquinas de recopilación de datos (o incluso varias tareas programadas en la misma máquina de recopilación de datos) envíen datos a un único área de trabajo de Análisis de registros y este Blade sea un agregado de los resultados de requisitos previos para todas las máquinas de recopilación de datos conectadas al área de trabajo. Entonces, ¿qué sucede si algunas máquinas han enviado datos con la nueva columna CustomData, pero otras no lo han hecho? ¿Mostraremos la antigua experiencia de usuario o la nueva experiencia de usuario?

Aquí es cuando verás la hoja en blanco en la captura de pantalla. No existía una solución excepcional aquí, por lo que verás este estado intermedio dañado hasta que todos los equipos de recopilación de datos hayan enviado datos con los nuevos bits.

Hay algunos casos desafortunados que podrían resultar en una experiencia complicada para los clientes:

1. Sabemos que, para algunas evaluaciones, es común tener varias tareas programadas configuradas en la misma máquina de recopilación de datos (por ejemplo, Windows Client Assessment) y esas tareas programadas se configuran para que se ejecuten en diferentes días. Supongamos que tiene dos tareas, una el lunes y otra el miércoles. Una vez que la tarea se ejecute el lunes, verá la hoja en blanco hasta que la segunda tarea se ejecute el miércoles, momento en el que el cliente debería comenzar a ver la nueva hoja de calidad de evaluación.

2. ¿Qué sucede si tres máquinas de recopilación de datos tienen la ejecución de SQL Assessment y apuntan al mismo área de trabajo de Análisis de registros, pero una de estas máquinas se ha retirado hace 2 semanas? Las otras dos máquinas ejecutan la evaluación con nuestros nuevos bits, pero como el tercer equipo se ha retirado, no puede ejecutar la evaluación con nuestros nuevos bits. En este escenario, el cliente vería la hoja en blanco.

3. Hemos observado este problema en algunas de nuestras áreas de trabajo de prueba que tienen muchas personas ejecutando evaluaciones y que envían datos al mismo área de trabajo de Análisis de registros. En este caso, es muy difícil (probablemente imposible) localizarlos todos y obtenerlos para volver a ejecutar la evaluación con los nuevos bits.

Sin embargo, el problema se resolverá automáticamente cuando una de estas dos cosas suceda:

1. Todas las máquinas de recopilación de datos y las tareas programadas en esos equipos hayan vuelto a ejecutar la evaluación con nuevos bits.

2. El periodo de retención de datos (el valor predeterminado es 30 días) hace que los datos antiguos se detengan, dejando únicamente los datos "buenos" que se generaron después de que se publicara la característica de calidad de la evaluación.

Por este motivo, decidimos que se trata de una cantidad aceptable de turbulencia que debe resistir.

En el peor de los casos, los clientes siempre pueden crear una nueva área de trabajo de Análisis de registros o usar la API de depurador de datos y luego volver a ejecutar la evaluación que dará como resultado un módulo de calidad de evaluación limpia.