Solución de problemas de la correlación de dispositivos

uimpga-ga
2
Advertencia
Las diferentes versiones de CA UIM utilizan esquemas de base de datos diferentes para la base de datos de UIM. Este documento presupone que se está utilizando CA UIM 8.5.1 o posterior. Si se está utilizando una versión diferente de CA UIM, es posible que los siguientes elementos no sean válidos tal y como se describe en el entorno de CA UIM:
  • Nombres de tablas y columnas de la base de datos de UIM.
  • Ejemplos de consultas SQL a la base de datos de UIM.
Nota: CA Technologies se reserva el derecho a realizar cambios de esquema en las versiones posteriores de CA UIM que pueden hacer que el contenido de este documento no sea válido.
Descripción general
device_correlation_troubleshooting
Al consultar los dispositivos en CA UIM, es posible que aparezca una de las dos siguientes situaciones:
  • Dispositivos duplicados: Un dispositivo aparece más de una vez en el inventario.
  • Dispositivos combinados: Dispositivos diferentes aparecen como un único dispositivo.
Ambos problemas están causados por la correlación de dispositivos incorrecta. La correlación de dispositivos es el proceso de asociar las propiedades del dispositivo obtenidas de una sonda con el dispositivo correcto en la base de datos de UIM. El primer problema es el resultado de falta de correlación, que es un error al asociar un dispositivo entrante con un dispositivo existente. Da lugar a una instancia duplicada del dispositivo que se está creando. El segundo problema es una correlación excesiva, que se produce cuando se asocian diferentes dispositivos de forma incorrecta como si fueran el mismo dispositivo. Como resultado, la información de los diferentes dispositivos se combina en un solo dispositivo.
Revise la documentación sobre la configuración de la correlación de dispositivos para obtener información sobre cómo funciona la correlación, así como información sobre cómo configurarla. A partir de la versión 8.51, la correlación de dispositivos es altamente configurable. Se puede solucionar la mayoría de los casos de correlación personalizando la configuración de la sonda discovery_server. La documentación de UIM incluye varios escenarios de correlación y cómo solucionarlos.
Por qué se producen problemas de correlación
La precisión de la correlación de dispositivos depende de la información de los dispositivos proporcionada por las sondas. Idealmente, todas las sondas deben proporcionar el nombre, la dirección IP y la dirección MAC de todos los dispositivos con el fin de facilitar una sólida coincidencia de correlación. La realidad es que la cantidad de información por dispositivo varía según la sonda. La mayoría de las sondas proporcionan un nombre o una dirección IP. Solo un número relativamente pequeño de sondas proporciona una dirección MAC.
Se puede producir un dispositivo duplicado si no hay información coincidente entre las perspectivas del dispositivo de diferentes sondas. Por ejemplo, si una sonda solo incluye un nombre para un dispositivo y otra sonda solo incluye una dirección IP para el dispositivo, los dispositivos no se correlacionarán a menos que una tercera sonda incluya tanto el nombre como la dirección IP del dispositivo, vinculando las tres perspectivas.
Siempre que sea posible, proporcione un nombre y la dirección IP de un dispositivo al configurar una sonda para evitar dicha duplicación potencial.
Otro origen de los problemas de correlación es que no coincidan los valores de origen. Por ejemplo, si un dispositivo se está monitorizando desde un concentrador con el origen HubA y el mismo dispositivo se está monitorizando desde otro concentrador distinto con el origen HubB, no se correlacionarán si los dispositivos solo tienen una dirección IP o un nombre de host simple (que no es un FQDN). Debido a que es posible que una dirección IP o un nombre de host simple no sean únicos en un entorno, el origen se utiliza como un calificador de la correlación. El mero hecho de aceptar el nombre del concentrador como el origen predeterminado puede conducir a que se produzca la falta de coincidencia de la correlación que se describe aquí.
Asigne los orígenes estratégicamente para facilitar la correlación.
Orígenes y orígenes enriquecidos
Las sondas publican un origen con cada dispositivo. El origen publicado normalmente coincide con el origen del robot donde se está ejecutando la sonda. El origen del robot tiene como valor predeterminado el origen del concentrador, pero se puede anular en el robot. El origen del concentrador tiene como valor predeterminado el nombre del concentrador, pero se puede anular en el concentrador. El origen publicado a veces se llama "origen del bus".
Los orígenes enriquecidos son los orígenes anulados ubicados en la tabla S_QOS_DATA. La sonda qos_processor se utiliza para anular el origen en la tabla S_QOS_DATA utilizando scripts personalizados. Sin embargo, en algunas implementaciones, la tabla S_QOS_DATA se puede modificar directamente sin utilizar la sonda qos_processor. De forma predeterminada, el origen de la calidad del servicio es el mismo que el origen del robot.
El servidor de detección detecta los cambios en el origen enriquecido en la tabla S_QOS_DATA y los aplica a los dispositivos afectados. Un origen enriquecido es el valor del origen de la tabla S_QOS_DATA donde el modificador es != 'nimsoft' y el origen es != nim_origin. Las columnas modificador, origen y nim_origin deben tener valores no nulos para que el servidor de detección seleccione el origen enriquecido.
Para las reglas de correlación que se califican por origen, se necesita un origen coincidente (ya sea de la propiedad Origin o de la propiedad EnrichedOrigin) para que dos dispositivos se correlacionen.
Asigne los orígenes del concentrador o del robot estratégicamente para facilitar la correlación, o configure orígenes enriquecidos para ayudar a los dispositivos a vincularse.
El origen predeterminado del nombre del concentrador a menudo resulta problemático. Sería menos problemático si cada concentrador y robot tuviera de forma predeterminada el mismo origen (por ejemplo, el nombre del dominio UIM) y si solo se anulara el origen debido a un propósito específico. De esta manera se puede gestionar un entorno de un único cliente sin nombres ni direcciones IP solapados.
Si existen direcciones IP o nombres solapados en las ubicaciones, asigne un origen diferente para cada ubicación. Asigne el mismo origen a cada concentrador y robot de esa ubicación.
Utilice la misma estrategia para varios clientes.
Asigne un origen diferente a cada cliente.
Se debe asignar a cada concentrador y robot de ese cliente el mismo origen, a menos que haya necesidad de subdividir aún más el cliente. Por ejemplo, si el cliente tiene varias ubicaciones con direcciones IP o nombres solapados, asigne orígenes diferentes a cada ubicación del cliente. Un patrón de nomenclatura jerárquica para los orígenes también puede ayudar. Por ejemplo, "CustomerA_IL_Chicago" especifica tanto el cliente como la ubicación.
Consulte la documentación existente sobre la configuración de la sonda qos_processor para obtener más información sobre la creación de orígenes enriquecidos para los dispositivos monitorizados.
Además de asignar de forma estratégica los orígenes del concentrador o robot y de configurar los orígenes enriquecidos, el servidor de detección es compatible con una función para "tratar como valores iguales" que se puede utilizar para definir conjuntos de orígenes que se deben tratar como iguales en la correlación. Consulte la documentación sobre la configuración de la correlación de dispositivos de CA UIM para obtener más detalles al respecto.
Herramientas para la solución de problemas
El servidor de detección de la versión 8.51 y de versiones posteriores incluye las siguientes herramientas que le ayudarán con la solución de problemas y con la solución de los casos de correlación:
  • Tabla de la base de datos CM_DEVICE_CORRELATION_HISTORY para ver un historial de los resultados de la correlación.
  • Comandos y devoluciones de llamada del servidor de detección:
    • query_devices_by_cs_ids
    • dry_run_correlate_devices_by_cs_ids
    • reimport_devices_by_cs_ids
CM_DEVICE_CORRELATION_HISTORY
Se puede consultar la tabla CM_DEVICE_CORRELATION_HISTORY para obtener los resultados de la correlación de un dispositivo. Consulte la documentación sobre la configuración de la correlación de dispositivos para obtener detalles sobre esta tabla. Tenga en cuenta lo siguiente:
  • El servidor de detección suprime automáticamente las entradas con más de 14 días.
  • Se puede configurar a través del parámetro de configuración device_correlation_history_delete_older_than_time.
  • También se ejecuta manualmente con la devolución de llamada "delete_device_correlation_history_older_than".
Debido a que el servidor de detección suprime automáticamente las entradas antiguas, es posible que los dispositivos que no se han procesado recientemente no tengan ninguna entrada en CM_DEVICE_CORRELATION_HISTORY.
query_devices_by_cs_ids
Este comando de la utilidad de la sonda del servidor de detección proporciona los detalles necesarios para solucionar los problemas de los casos de correlación de dispositivos. Tenga en cuenta lo siguiente:
  • El comando acepta una lista separada por comas de uno o más valores cs_id de CM_COMPUTER_SYSTEM.
  • Los resultados de las consultas de las tablas siguientes para los valores cs_id especificados se guardan en archivos CSV:
    • CM_COMPUTER_SYSTEM
    • CM_COMPUTER_SYSTEM_ATTR
    • CM_DEVICE, CM_DEVICE_ATTRIBUTE
    • CM_DEVICE_CORRELATION_HISTORY
  • Se guardan los archivos CSV en query_devices_by_cs_ids_<códigofecha>.zip en el directorio discovery_server.
dry_run_correlate_devices_by_cs_ids
Se puede utilizar este comando de la utilidad de la sonda del servidor de detección para probar los cambios realizados en la configuración de la correlación de dispositivos, así como para solucionar los problemas de los casos de correlación de dispositivos. Tenga en cuenta lo siguiente:
  • El comando acepta una lista separada por comas de uno o más valores cs_id de CM_COMPUTER_SYSTEM.
  • El comando también acepta un nombre de archivo CFG con una configuración de la correlación personalizada. Si no se ha especificado un archivo CFG, el comando utiliza la configuración actual del servidor de detección.
  • El servidor de detección establecerá una correlación entre los dispositivos asociados con los valores cs_id especificados. Solo se correlacionarán los dispositivos y no se conservarán los resultados con el fin de hacer que la operación de correlación no sea destructiva.
  • El equivalente de lo que se guarda en CM_DEVICE_CORRELATION_HISTORY se guarda en un archivo llamado correlation_results.csv.
  • Para que se puedan comparar los resultados actuales de la correlación con los resultados anteriores, el último resultado de la correlación de CM_DEVICE_CORRELATION_HISTORY para el mismo conjunto de dispositivos se guarda en el archivo previous_correlation_results.csv con la hora en la que se ha procesado.
  • Para que se pueda realizar un análisis más detallado, los resultados de la consulta de CM_COMPUTER_SYSTEM, CM_COMPUTER_SYSTEM_ATTR, CM_DEVICE y CM_DEVICE_ATTRIBUTE para los valores cs_id especificados se guardan en archivos CSV.
  • Todos los archivos anteriores, además del archivo discovery_server.cfg y del archivo CFG opcional, se guardan en dry_run_correlate_devices_by_cs_ids_<códigofecha>.zip en el directorio discovery_server.
Tenga en cuenta que el valor cs_id estará en blanco en el archivo correlation_results.csv. Debido a que el comando "dry_run_correlate_devices_by_cs_ids" no modifica la base de datos para guardar los resultados de la correlación, el valor de cs_id es indeterminado. Todo lo que se puede determinar en la ejecución de prueba es el dispositivo de destino si se encuentra una coincidencia, así como el match_type (nombre de la regla) y las claves/valores coincidentes que han impulsado la correlación.
reimport_devices_by_cs_ids
Este comando de la utilidad de la sonda del servidor de detección puede utilizarse junto con la devolución de llamada "dry_run_correlate_devices_by_cs_ids". Cuando se haya comprobado que los cambios de configuración producen los resultados deseados, se podrán implementar en discovery_server.cfg y, a continuación, se podrá utilizar el comando "reimport_devices_by_cs_ids" para volver a correlacionar los dispositivos utilizando la nueva configuración. Tenga en cuenta lo siguiente:
  • El comando acepta una lista separada por comas de uno o más valores cs_id de CM_COMPUTER_SYSTEM.
  • El comando vuelve a importar los dispositivos con los datos actuales en la base de datos. La reimportación de dispositivos pasa por el proceso de importación completo: correlación, reconciliación y persistencia.
  • La devolución de llamada no vuelve a importar los dispositivos de forma inmediata. Publica los dispositivos en la cola interna del servidor de detección para su procesamiento.
Ejemplo de solución de problemas
Supongamos que hay dos dispositivos en el inventario de UIM con el nombre "foobar" que parecen ser duplicados.
Consulte CM_COMPUTER_SYSTEM para determinar los valores cs_id para los dispositivos "foobar":
select * from CM_COMPUTER_SYSTEM where name='foobar'
Se determina que los valores cs_id sean 314851 y 314852.
Ahora, abra probe_utility en el servidor de detección, seleccione el comando "query_devices_by_cs_ids", establezca los valores cs_id en "314851,314852" y ejecute el comando. Para ver los resultados, recupere el archivo query_devices_by_cs_ids_<códigofecha>.zip del directorio discovery_server del sistema donde está instalado el servidor de detección.
Al mirar en el archivo cm_device_correlation_history.csv, verá que los dispositivos "foobar" no encuentran una coincidencia (target_dev_id está vacío y match_type es 'ninguno'):
source_dev_id
target_dev_id
cs_id
time_processed
motivo
match_type
D268FAC8073818534EF7B6463F201267A
314851
2/2/17 15:16
0
ninguno
DB26684F675CD005DEBC4E387593590D2
314851
2/2/17 15:16
0
ninguno
Al mirar en el archivo cm_device_attribute.csv, se verá lo siguiente:
dev_id
cs_id
dev_ip
dev_name
probe_name
dev_attr_key
dev_attr_value
D268FAC8073818534EF7B6463F201267A
314851
foobar
probe1
CorrrelationNames
foobar
D268FAC8073818534EF7B6463F201267A
314851
foobar
probe1
Origen
HubA
DB26684F675CD005DEBC4E387593590D2
314852
foobar
probe2
CorrrelationNames
foobar
DB26684F675CD005DEBC4E387593590D2
314852
foobar
probe2
Origen
HubB
Los dispositivos no incluyen una dirección IP. La única propiedad de correlación común entre los dos dispositivos es el nombre "foobar". Los dispositivos no se correlacionan debido a que sus orígenes no coinciden.
Buscando posibles soluciones en la documentación sobre la configuración de la correlación de dispositivos, se decide utilizar la función <treat_as_equal_values> para especificar que los orígenes HubA y HubB se deben tratar como iguales en la correlación.
Copie discovery_server.cfg en discovery_server_test.cfg y agregue una sección llamada <treat_as_equal_values> en <Origins> en discovery_server_test.cfg.
Ahora, ejecute el comando del servidor de detección "dry_run_correlate_devices_by_cs_ids". Establezca los valores cs_id en "314851,314852" y optional_cfg_file en "discovery_server_test.cfg". Obtenga el archivo dry_run_correlate_devices_by_cs_ids_<datecode>.zip del directorio discovery_server para comprobar los resultados.
Al mirar en el archivo correlation_results.csv, verá que ahora se correlacionan los dispositivos:
source_dev_id
target_dev_id
cs_id
time_processed
motivo
match_type
D268FAC8073818534EF7B6463F201267A
DB26684F675CD005DEBC4E387593590D2
2/2/17 15:37
0
name_origin
DB26684F675CD005DEBC4E387593590D2
D268FAC8073818534EF7B6463F201267A
2/2/17 15:37
0
name_origin
Una vez comprobado el cambio de configuración, copie discovery_server_test.cfg en discovery_server.cfg y reinicie el servidor de detección.
Para volver a correlacionar los dispositivos "foobar" con la nueva configuración, se puede utilizar el comando "reimport_devices_by_cs_ids" del servidor de detección y se pueden establecer los valores cs_id en "314851,314852".