Preguntas más frecuentes sobre la solución Network Performance Monitor.

A continuación se muestran los requisitos de plataforma para diversas funcionalidades de NPM:

• Las funcionalidades Monitor de rendimiento y Monitor de conectividad de servicio de NPM admiten tanto Windows Server como escritorios/sistemas operativos cliente Windows. Las versiones admitidas del sistema operativo Windows Server son 2008 SP1 y posteriores. Las versiones admitidas de cliente o escritorios de Windows son Windows 10, Windows 8.1, Windows 8 y Windows 7.
• La funcionalidad Supervisión de ExpressRoute de NPM solo admite el sistema operativo Windows Server (2008 SP1 o posterior).

La funcionalidad de supervisión de redes con nodos basados en Linux se encuentra disponible con carácter general. Acceda al agente aquí.

Para ejecutar la solución NPM en máquinas virtuales de nodo para supervisar redes, los nodos deben tener al menos 500 MB de memoria y un núcleo. No es necesario usar nodos independientes para ejecutar NPM. La solución pueda ejecutarse en nodos en los que haya otras cargas de trabajo en ejecución. La solución tiene la capacidad de detener el proceso de supervisión si usa más del 5 % de CPU.

Tanto la funcionalidad Monitor de rendimiento como Monitor de conectividad de servicio admite nodos conectados como agentes directos y conectados a través de Operations Manager.

En la funcionalidad Supervisión de ExpressRoute, los nodos de Azure solo deben conectarse como agentes directos. Los nodos de Azure, que se conectan a través de Operations Manager, no se admiten. En los nodos locales, se admiten los nodos conectados como agentes directos y a través de Operations Manager para supervisar un circuito ExpressRoute.

Si va a supervisar su red mediante nodos basados en Windows Server, se recomienda usar TCP como protocolo de supervisión, ya que ofrece mayor precisión.

Se recomienda ICMP para los nodos basados en el sistema operativo de cliente o escritorios de Windows. Esta plataforma no admite que se envíen datos TCP a través de sockets sin procesar, que NPM usa para detectar la topología de red.

Puede obtener más detalles sobre las ventajas relativas de cada protocolo aquí.

Para que el nodo admita la supervisión con el protocolo TCP:

• Asegúrese de que la plataforma de nodos sea Windows Server (2008 SP1 o posterior).
• Ejecute el script EnableRules.ps1 de PowerShell en el nodo. Vea las instrucciones para obtener más detalles.

Para cambiar el puerto TCP que NPM utiliza para la supervisión, ejecute el script EnableRules.ps1. Debe especificar el número de puerto que va a utilizar como parámetro. Por ejemplo, para habilitar TCP en el puerto 8060, ejecute EnableRules.ps1 8060. Asegúrese de utilizar el mismo puerto TCP en todos los nodos que se usan para la supervisión.

El script configura solo el firewall de Windows localmente. Si tiene reglas de firewall de red o de grupo de seguridad de red (NSG), asegúrese de que permiten el tráfico destinado al puerto TCP que NPM utiliza.

Debe usar a al menos un agente para cada subred que quiera supervisar.

NPM limita el número de direcciones IP a direcciones 5000 por área de trabajo. Si un nodo tiene direcciones IPv4 e IPv6, esto contará como dos direcciones IP para ese nodo. Por lo tanto, el límite de 5000 direcciones IP podría decidir el límite superior en el número de agentes. Puede eliminar los agentes inactivos en la pestaña Nodos en NPM >> Configurar. NPM también mantiene el historial de todas las direcciones IP que se han asignado a la máquina virtual que hospeda el agente. Cada una se cuenta como una dirección IP independiente que contribuye a ese límite de 5000 direcciones IP. Para liberar direcciones IP para el área de trabajo, puede usar la página Nodos para eliminar las direcciones IP que no están en uso.

Los agentes de origen envían solicitudes SYN de TCP (si se elige TCP como protocolo de supervisión) o solicitudes de eco ICMP (si se elige ICMP como protocolo de supervisión) a la dirección IP de destino a intervalos regulares para asegurarse de que se cubren todas las rutas de acceso en la combinación de direcciones IP de origen y de destino. Para calcular la pérdida y latencia de cada ruta de acceso, se mide el porcentaje de paquetes recibidos y el tiempo de ida y vuelta de los paquetes. Estos datos se agregan a lo largo del intervalo de sondeo y de todas las rutas de acceso para obtener los valores agregados de pérdida y latencia para la combinación de direcciones IP del intervalo de sondeo determinado.

En las funcionalidades Monitor de rendimiento y Supervisión de ExpressRoute, el origen envía paquetes cada cinco segundos y registra las mediciones de red. Estos datos se agregan durante un intervalo de sondeo de tres minutos para calcular los valores promedio y máximo de pérdida y latencia. En la funcionalidad Monitor de conectividad de servicio, la frecuencia de envío de los paquetes para la medición de red viene determinada por la frecuencia especificada por el usuario para la prueba específica durante la configuración de la prueba.

El número de paquetes enviados por el agente de origen al destino en un sondeo es adaptable y se decide con nuestro algoritmo propietario, que puede ser diferente para las distintas topologías de red. Cuanto mayor sea el número de rutas de acceso de red en la combinación de direcciones IP de origen y destino, mayor será el número de paquetes que se envían. El sistema garantiza que se cubren todas las rutas de acceso en la combinación de direcciones IP de origen y de destino.

NPM usa un algoritmo propietario que se basa en Traceroute para detectar todas las rutas de acceso y los saltos entre el origen y destino.

Aunque NPM puede detectar todas las posibles rutas entre el agente de origen y el destino, no ofrece visibilidad de la ruta que tomaron los paquetes enviados por las cargas de trabajo específicas. La solución puede ayudarle a identificar las rutas de acceso y los saltos de red subyacentes, que agregan más latencia de la que se espera.

Pueden existir distintas rutas de acceso de red entre las direcciones IP de origen y destino, y cada ruta de acceso puede tener un valor distinto de pérdida y latencia. NPM marca esas rutas de acceso como incorrectas (como indica el color rojo) para las que los valores de pérdida o latencia son mayores que el correspondiente umbral establecido en la configuración de supervisión.

Si un salto aparece en rojo, indica que forma parte de al menos una ruta de acceso incorrecta. NPM solo marca las rutas de acceso como incorrectas, no segrega el estado de mantenimiento de cada ruta de acceso. Para identificar los saltos problemáticos, puede ver la latencia de salto a salto y separar los que agregan más latencia de la que se espera.

NPM usa un mecanismo probabilístico para asignar las probabilidades de error a cada ruta de acceso de red, segmento de red, y a los saltos de red que los componen en función del número de rutas de acceso incorrectas de las que forman parte. A medida que los segmentos de red y los saltos engrosan el número de rutas de acceso incorrectas, aumenta la probabilidad de error asociada a ellos. Este algoritmo funciona mejor cuando se tienen muchos nodos con el agente de NPM conectados entre sí, ya que esto aumenta los puntos de datos para calcular las probabilidades de error.

Consulta del monitor de rendimiento

NetworkMonitoring
 | where (SubType == "SubNetwork" or SubType == "NetworkPath") 
 | where (LossHealthState == "Unhealthy" or LatencyHealthState == "Unhealthy") and RuleName == "<<your rule name>>"

Consulta del monitor de conectividad de servicio

NetworkMonitoring
 | where (SubType == "EndpointHealth" or SubType == "EndpointPath")
 | where (LossHealthState == "Unhealthy" or LatencyHealthState == "Unhealthy" or ServiceResponseHealthState == "Unhealthy" or LatencyHealthState == "Unhealthy") and TestName == "<<your test name>>"

Consultas del monitor de ExpressRoute: Consulta de circuitos

NetworkMonitoring
 | where (SubType == "ERCircuitTotalUtilization") and (UtilizationHealthState == "Unhealthy") and CircuitResourceId == "<<your circuit resource ID>>"

Emparejamiento privado

NetworkMonitoring
 | where (SubType == "ExpressRoutePeering" or SubType == "ERVNetConnectionUtilization" or SubType == "ExpressRoutePath")   
 | where (LossHealthState == "Unhealthy" or LatencyHealthState == "Unhealthy" or UtilizationHealthState == "Unhealthy") and CircuitName == "<<your circuit name>>" and VirtualNetwork == "<<vnet name>>"

Emparejamiento de Microsoft

NetworkMonitoring
 | where (SubType == "ExpressRoutePeering" or SubType == "ERMSPeeringUtilization" or SubType == "ExpressRoutePath")
 | where (LossHealthState == "Unhealthy" or LatencyHealthState == "Unhealthy" or UtilizationHealthState == "Unhealthy") and CircuitName == ""<<your circuit name>>" and PeeringType == "MicrosoftPeering"

Consulta común

NetworkMonitoring
 | where (SubType == "ExpressRoutePeering" or SubType == "ERVNetConnectionUtilization" or SubType == "ERMSPeeringUtilization" or SubType == "ExpressRoutePath")
 | where (LossHealthState == "Unhealthy" or LatencyHealthState == "Unhealthy" or UtilizationHealthState == "Unhealthy")

NPM solo identifica el nombre de host y de IP de los saltos de red subyacentes (conmutadores, enrutadores, servidores, etc.) entre las direcciones IP de origen y destino. También identifica la latencia entre estos saltos identificados. No supervisa individualmente estos saltos subyacentes.

Sí. Consulte el artículo Monitor Azure, AWS, and on-premises networks using NPM (Supervisar Azure, AWS y redes locales con NPM) para obtener más detalles.

El uso de ancho de banda corresponde al total de ancho de banda entrante y saliente. Se expresa en bits por segundo.

Se pueden capturar los valores entrantes y salientes del ancho de banda principal y secundario.

Para obtener información de nivel de emparejamiento de Microsoft, utilice la consulta que se menciona a continuación en la búsqueda de registros.

NetworkMonitoring
 | where SubType == "ERMSPeeringUtilization"
 | project CircuitName,PeeringName,BitsInPerSecond,BitsOutPerSecond 

Para obtener información de nivel de emparejamiento privada, utilice la consulta que se menciona a continuación en la búsqueda de registros.

NetworkMonitoring
 | where SubType == "ERVNetConnectionUtilization"
 | project CircuitName,PeeringName,BitsInPerSecond,BitsOutPerSecond

Para obtener información de nivel de circuito, utilice la consulta que se menciona a continuación en la búsqueda de registros.

NetworkMonitoring
 | where SubType == "ERCircuitTotalUtilization"
 | project CircuitName, BitsInPerSecond, BitsOutPerSecond

NPM puede supervisar la conectividad entre redes en cualquier parte del mundo, desde un área de trabajo que se hospede en una de las regiones admitidas.

NPM puede supervisar la conectividad con servicios en cualquier parte del mundo, desde un área de trabajo que se hospede en una de las regiones admitidas.

NPM puede supervisar los circuitos ExpressRoute ubicados en cualquier región de Azure. Para incorporarse a NPM, requerirá un área de trabajo de Log Analytics que debe hospedarse en una de Las regiones admitidas

NPM usa una versión modificada del comando traceroute para detectar la topología desde el agente de origen al destino. Un salto no identificado indica que el salto de red no respondió a la solicitud de traceroute del agente de origen. Si tres saltos de red consecutivos no responden al comando traceroute del agente, la solución marca los saltos que no responden como no identificados y no intenta detectar más saltos.

Es posible que un salto no responda a un comando traceroute en uno o varios de los escenarios siguientes:

• Los enrutadores se han configurado para no revelar su identidad.
• Los dispositivos de red no permiten el tráfico ICMP_TTL_EXCEEDED.
• Un firewall bloquea la respuesta ICMP_TTL_EXCEEDED del dispositivo de red.

Cuando cualquiera de los puntos de conexión se encuentra en Azure, traceroute muestra saltos no identificados, ya que la infraestructura de Azure no revela la identidad a traceroute.

NPM genera una alerta si la latencia de extremo a extremo entre el origen y el destino cruza el umbral en cualquiera de las rutas de acceso entre ellos. Algunas redes tienen varias rutas de acceso que conectan el mismo origen y destino. NPM genera una alerta si el estado de alguna de las rutas de acceso es incorrecto. La pérdida y latencia que se muestran en los gráficos es el valor medio de todas las rutas de acceso, por lo que puede que no muestre el valor exacto de una única ruta de acceso. Para saber dónde se ha superado el umbral, busque la columna "SubType" en la alerta. Si el problema se debe a una ruta de acceso, el valor de SubType será NetworkPath (para las pruebas del Monitor de rendimiento), EndpointPath (para las pruebas del Monitor de conectividad de servicio) y ExpressRoutePath (para las pruebas del Monitor de ExpressRotue).

Consulta de ejemplo para buscar la ruta de acceso incorrecta:

NetworkMonitoring
 | where ( SubType == "ExpressRoutePath")
 | where (LossHealthState == "Unhealthy" or LatencyHealthState == "Unhealthy" or UtilizationHealthState == "Unhealthy") and CircuitResourceID =="<your ER circuit ID>" and ConnectionResourceId == "<your ER connection resource id>"
 | project SubType, LossHealthState, LatencyHealthState, MedianLatency

NPM supervisa la topología, la latencia y la pérdida de un extremo a otro en intervalos diferentes. La pérdida y la latencia se miden una vez cada cinco segundos y se agregan cada tres minutos (para el Monitor de rendimiento y la Supervisión de ExpressRoute), mientras que la topología se calcula mediante el comando traceroute una vez cada diez minutos. Por ejemplo, entre las 03:44 y las 04:04, la topología podría actualizarse tres veces (a las 03:44, 03:54 y 04:04), pero la pérdida y la latencia se actualizan unas siete veces (a las 03:44, 03:47, 03:50, 03:53, 03:56, 03:59 y 04:02). La topología que se genera a las 03:54 se representará para la pérdida y la latencia calculadas a las 03:56, 03:59 y 04:02. Supongamos que recibe una alerta que indica que el circuito ER se encontraba en un estado incorrecto a las 03:59. Inicia sesión en NPM e intenta establecer la hora de la topología a las 03:59. NPM representará la topología que se generó a las 03:54. Para entender la última topología conocida de la red, compare los campos TimeProcessed (hora a la que se calcularon la pérdida y la latencia) y TracerouteCompletedTime (hora a la que se calculó la topología).

E2EMedianLatency es la latencia actualizada cada tres minutos después de agregar los resultados de las pruebas de ping basadas en TCP, mientras que AvgHopLatencyList se actualiza cada diez minutos en función del comando traceroute. Para entender la hora exacta a la que se calculó E2EMedianLatency, use el campo TimeProcessed. Para entender la hora exacta a la que el comando traceroute completó y actualizó AvgHopLatencyList, use el campo TracerouteCompletedTime.

HopLatencyValues son el origen de un punto de conexión. Por ejemplo: saltos: A,B,C; AvgHopLatency: 10,15,20. Esto significa que el origen de la latencia A es 10, el origen de la latencia B es 15 y el origen de la latencia C es 20. La interfaz de usuario calculará que la latencia del salto A-B es 5 en la topología.

Esto puede ocurrir si el firewall del host o el firewall intermedio (firewall de red o Azure NSG) bloquea la comunicación entre el agente de origen y el destino a través del puerto que NPM utiliza para la supervisión (de manera predeterminada el puerto es el 8084, a menos que el cliente lo haya cambiado).

• Para comprobar que el firewall del host no bloquea la comunicación en el puerto requerido, vea el estado de mantenimiento de los nodos de origen y destino desde la siguiente vista: Network Performance Monitor -> Configuración -> Nodos. Si son incorrectos, vea las instrucciones y realice acciones correctivas. Si los nodos son correctos, siga en el paso b a continuación.
• Para comprobar que un firewall de red intermedio o NSG de Azure no bloquean la comunicación en el puerto necesario, emplee la utilidad de terceros PsPing con las instrucciones siguientes:
  • La utilidad psping está disponible para su descarga aquí.
  • Ejecute el siguiente comando en el nodo de origen.
    • psping -n 15 <IPAddress del nodo de destino>:portNumber De manera predeterminada, NPM utiliza el puerto 8084. En caso de que lo haya cambiado explícitamente mediante el script EnableRules.ps1, escriba el número de puerto personalizado que utiliza). Se trata de un ping de la máquina de Azure al entorno local.
• Compruebe si los pings son correctos. Si no es así, indica que un firewall de red intermedio o un grupo de seguridad de red de Azure bloquean el tráfico en este puerto.
• Ahora, ejecute el comando desde la dirección IP del nodo de destino a la del nodo de origen.

Como las rutas de acceso de red entre A y B pueden ser diferentes de las rutas de acceso de red entre B y A, se pueden observar diferentes valores de pérdida y latencia.

NPM ahora detecta los circuitos ExpressRoute y las conexiones de emparejamiento en todas las suscripciones a la que el usuario tiene acceso. Elija todas las suscripciones donde los recursos de Express Route están vinculados y habilite la supervisión de cada recurso detectado. NPM busca objetos de conexión durante la detección de un emparejamiento privado, por tanto, compruebe si hay una red virtual asociada con el emparejamiento. NPM no detecta los circuitos y el emparejamiento que se encuentran en otro inquilino del área de trabajo de Log Analytics.

Puede que haya un escenario donde exista una conexión correcta entre los nodos locales y de Azure, pero el tráfico no pase a través del circuito ExpressRoute configurado para que NPM lo supervise.

Esto puede suceder si:

• El circuito ER está inactivo.
• Los filtros de ruta se configuran de tal manera que dan prioridad a otras rutas (por ejemplo, una conexión VPN u otro circuito ExpressRoute) a través del circuito ExpressRoute previsto.
• Los nodos locales y de Azure elegidos para supervisar el circuito ExpressRoute en la configuración de supervisión no tienen conectividad entre sí a través del circuito ExpressRoute previsto. Asegúrese de que ha elegido nodos correctos que tengan conectividad entre sí a través del circuito ExpressRoute que va a supervisar.

El monitor de ExpressRoute compara los valores de rendimiento de red (pérdida, latencia y uso de ancho de banda) notificados por los agentes o servicios con los umbrales establecidos durante la configuración. En el caso de un circuito, si el uso de ancho de banda indicado es mayor que el umbral establecido en la configuración, el circuito se marca como incorrecto. En el caso de los emparejamientos, si la pérdida, la latencia o el uso de ancho de banda notificado es mayor que el umbral establecido en la configuración, el emparejamiento se marca como incorrecto. NPM no usa métricas ni ningún otro tipo de datos para decidir el estado de mantenimiento.

Para el monitor de ExpressRoute, el uso de ancho de banda es el promedio de ancho de banda de entrada y salida de los últimos 20 minutos que se expresa en bits por segundo. En el caso de las métricas de ExpressRoute, los bits de entrada y salida se miden por puntos de datos por minuto. De manera interna, se usa el mismo conjunto de datos, pero la agregación varía entre las métricas de NPM y ER. Para obtener una supervisión detallada por minuto y alertas rápidas, se recomienda establecer las alertas directamente en las métricas de ER

Esto puede suceder si los nodos de Azure se conectan a través de Operations Manager. La funcionalidad Supervisión de ExpressRoute solo admite los nodos de Azure que se conectan como agentes directos.

Aunque NPM se puede usar tanto en Azure Portal como en el portal de OMS, la detección de circuitos de la funcionalidad Supervisión de ExpressRoute solo funciona a través de Azure Portal. Una vez que los circuitos se detectan en Azure Portal, se puede usar la funcionalidad en cualquiera de los dos portales.

Esto puede suceder si se cumple una o más de las siguientes condiciones:

• El servicio está inactivo.
• El nodo que se usa para comprobar la conectividad de red con el servicio está inactivo.
• El destino que se escribió en la configuración de prueba no es correcto.
• El nodo no tiene conectividad de red ninguna.

Esto puede suceder si se cumple una o más de las siguientes condiciones:

• Si el nodo que se usa para comprobar la conectividad de red con el servicio es un equipo cliente Windows, independientemente de si el servicio de destino bloquea las solicitudes ICMP o un firewall de red bloquea las solicitudes ICMP que se originan del nodo.
• La casilla Realizar mediciones de red está en blanco en la configuración de prueba.

Esto puede suceder si el servicio de destino no es una aplicación web pero la prueba está configurada como prueba web. Edite la configuración de prueba y elija red como tipo de prueba en lugar de web.

El proceso de NPM está configurado para detenerse en caso de que utilice más del 5 % de los recursos de CPU del host. Con esto se garantiza que se pueden seguir usando los nodos para las cargas de trabajo habituales sin afectar al rendimiento.

NPM solo crea una regla local de Firewall de Windows en los nodos en los que se ejecuta el script EnableRules.ps1 de PowerShell para permitir que los agentes establezcan conexiones TCP entre sí en el puerto especificado. La solución no modifica las reglas de firewall de red o de grupo de seguridad de red (NSG).

Puede ver el estado de mantenimiento de los nodos que se usan para la supervisión en la siguiente vista: Network Performance Monitor -> Configuración -> Nodos. Si un nodo es incorrecto, puede ver los detalles del error y realizar la acción sugerida.

NPM redondea los números de latencia en la interfaz de usuario y en milisegundos. Los mismos datos se almacenan con una granularidad superior (a veces hasta cuatro posiciones decimales).

No. Cada nodo NPM requiere un área de trabajo de Log Analytics dedicada.

El agente OMS para Linux también requiere el uso de GLIBC 2.14 o posterior.

Pasos siguientes

• Puede obtener más información sobre Network Performance Monitor en Solución Network Performance Monitor en Azure.