En los capítulos anteriores, aprendió a hacer que sus aplicaciones estuvieran altamente disponibles y a enrutar clientes de todo el mundo a instancias distribuidas globalmente de su aplicación. Un objetivo era minimizar la cantidad de interacción con la infraestructura de su aplicación y permitir que la plataforma Azure administrara automáticamente el estado y el rendimiento. A veces, todavía necesita subirse las mangas y revisar los diagnósticos o métricas de rendimiento. En este capítulo, aprenderá a revisar los diagnósticos de arranque para una VM, supervisar las métricas de rendimiento y solucionar problemas de conectividad con Network Watcher.

Diagnóstico de arranque de VM
Con Web Apps, usted implementa el código y deja que la plataforma Azure se encargue del resto. En el capítulo 3, analizamos los fundamentos de cómo solucionar y diagnosticar el problema de las implementaciones de aplicaciones web. Aprendió a ver los eventos de aplicación en tiempo real para supervisar el rendimiento. Cuando trabaja con VM en la nube, suele ser difícil solucionar un problema cuando no se puede ver físicamente la pantalla del equipo de la manera en que ve los diagnósticos de aplicaciones web.
Uno de los problemas más comunes con las VM es la falta de conectividad. Si no puede aplicar SSH o RDP a una VM, ¿cómo puede solucionar el problema? Una de las primeras cosas que debe comprobar es si la VM se está ejecutando correctamente. Para ayudarlo a hacer esto, Azure ofrece diagnósticos de arranque de VM que incluye registros de arranque y una captura de pantalla de la consola.

Acceso interactivo de la consola de arranque
Para situaciones específicas de solución de problemas, también puede acceder a una consola serie para VM en vivo en Azure. Esta consola serie permite los arranques de sesión interactivos y la solución de problemas de arranque. Puede volver a configurar su VM para corregir situaciones de arranque fallidos o configuraciones erróneas de servicios y aplicaciones que impiden que su VM se inicie correctamente.
Este capítulo no abarca situaciones específicas para el uso de la consola serie, pero es un gran recurso que le permite prácticamente sentarse frente a la pantalla de una VM mientras se inicia. También necesita habilitar los diagnósticos de arranque, así que estos ejercicios son un prerrequisitos para la consola serie.

Pruébelo ahora
Complete los siguientes pasos para crear una VM y habilitar el diagnóstico de arranque:
1 En Azure Portal, seleccione Crear un recurso en la esquina superior izquierda.
2 Busque y seleccione una imagen de máquina virtual de Windows Server 2019 Datacenter.
3 Cree un grupo de recursos, como azuremolchapter12 y, luego, seleccione la región de Azure correspondiente más cercana a usted.
4 Seleccione un tamaño de VM, como DS1_v2.
5 Escriba un nombre de usuario para la VM, como azuremol, y una contraseña. La contraseña debe tener un mínimo de 12 caracteres y contener 3 de los siguientes: un carácter en minúscula, un carácter en mayúscula, un número y un carácter especial.
6 Acepte cualquier opción de redundancia o reglas de puerto de entrada.
7 Acepte los valores predeterminados para los discos y las redes; no hay nada que necesite cambiar. Esa configuración tiene que ser familiar para usted por ahora.
Una sección que se puede haber saltado anteriormente es la sección Administración. Como se muestra en la figura 12.1, la opción de diagnóstico de arranque está activada de forma predeterminada y se crea una cuenta de almacenamiento.
8 Por ahora, deje desactivada la opción de diagnóstico del sistema operativo invitado.
9 Revise la configuración de la máquina virtual y seleccione Crear.
La VM demora unos minutos en crearse y configurarse, así que continuemos explorando los diagnósticos de arranque.
Si no tiene habilitado el diagnóstico de arranque pero se produce un problema, es probable que no pueda iniciar la VM para habilitar correctamente los diagnósticos. Es como el caso del huevo y la gallina, ¿verdad? Como resultado, los diagnósticos de arranque se habilitan automáticamente para las VM creadas en Azure Portal. Para Azure PowerShell, la CLI de Azure y los SDK específicos de cada lenguaje, es necesario habilitar el diagnóstico de arranque. Le recomiendo encarecidamente que habilite los diagnósticos de arranque en las VM al crearlos. Acostúmbrese a utilizar las plantillas de Azure Resource Manager (capítulo 6) o sus propios scripts de CLI de Azure o PowerShell que permiten el diagnóstico de arranque durante la implementación.

Es necesario crear una cuenta de almacenamiento para los registros de arranque y las capturas de pantalla de la consola, pero el costo de almacenar estos datos es probablemente inferior a USD 0,01 al mes, a menos que tenga una máquina virtual muy ocupada que genere muchos datos. La primera vez que se produzca un problema con la VM y necesite acceder a los diagnósticos de arranque, ese centavo al mes valdrá la pena. Esta cuenta de almacenamiento también se puede utilizar para contener métricas y registros adicionales de rendimiento en el nivel de la VM, que examinaremos en la proxima sección. De nuevo, los costos de almacenamiento tienen que ser mínimos. Incluso a medida que crezca su entorno de VM, vale la pena el pequeño costo adicional para poder solucionar rápidamente un problema cuando las cosas salen mal.

Pruébelo ahora
Para ver el diagnóstico de arranque para su VM, complete los siguientes pasos:
1 En Azure Portal, seleccione Máquinas virtuales en el menú de la izquierda.
2 Elija la VM que creó en el ejercicio anterior.
3 En la sección Soporte técnico y solución de problemas del menú de la VM, seleccione Diagnóstico de arranque. Aparecerá el diagnóstico de arranque y el estado de la VM, como se muestra en la figura 12.2. El informe de estado indica cualquier problema de arranque con la VM y le permite diagnosticar la causa raíz del problema.

Métricas y alertas de rendimiento
Uno de los primeros pasos para solucionar un problema es la revisión del rendimiento. ¿Cuánta memoria hay disponible, cuánta CPU se consume y cuánta actividad de disco hay?
A medida que compile y pruebe sus aplicaciones en Azure, le recomendamos registrar las líneas base de rendimiento en varios puntos. Estas líneas base le dan una idea de cómo debe funcionar su aplicación bajo diferentes cantidades de carga. ¿Por qué es tan importante? En tres meses, ¿cómo se puede determinar si hay problemas de rendimiento sin algunos datos para compararlos con el rendimiento actual?
Cuando aprendió a escalar automáticamente las aplicaciones en el capítulo 9, utilizó métricas básicas de rendimiento, como el uso de la CPU, para decirle a la plataforma Azure cuándo aumentar o disminuir el número de instancias de la aplicación. Estas métricas básicas solo le dan una pequeña idea de cómo funciona la VM. Para obtener métricas más detalladas, tiene que observar el rendimiento de la máquina virtual y, para ello, debe instalar la extensión de diagnósticos de Azure.

Visualización de métricas de rendimiento con la extensión de diagnóstico de VM
Para agregar funcionalidad a las VM, Azure tiene docenas de extensiones que puede instalar sin problemas. Estas extensiones instalan un pequeño agente o tiempo de ejecución de las aplicaciones en la VM que suele reportar la información a la plataforma Azure o a soluciones de terceros. Las extensiones de VM pueden configurar e instalar componentes automáticamente o ejecutar scripts en las VM.
La extensión de diagnóstico de VM es una común que se utiliza para transmitir métricas de rendimiento desde el interior de la VM a una cuenta de almacenamiento. Estas métricas de rendimiento pueden ser analizadas en Azure Portal, o descargadas y usadas en una solución de supervisión existente. Puede utilizar la extensión de diagnóstico para obtener una comprensión más profunda del rendimiento de la CPU y el consumo de memoria dentro de la VM, que normalmente puede proporcionar un panorama más detallado y preciso que el host.

Automatización y extensiones de VM
En el capítulo 18, hablamos de Azure Automation, que le permite realizar tareas de forma automatizada y programada en la VM. Una característica poderosa de Azure Automation es actuar como un servidor de extracción de Desired State Configuration (DSC) de PowerShell. PowerShell DSC define un estado determinado de cómo debe configurarse un sistema, qué paquetes deben instalarse, archivos y permisos, etc. Usted crea definiciones para la configuración deseada y se aplican a las VM o servidores físicos. A continuación, puede informar y aplicar el cumplimiento de esas directivas. La extensión de Azure PowerShell DSC se utiliza para aplicar configuraciones DSC, como por ejemplo, desde un servidor de extracción de Azure Automation.
Otras extensiones que pueden aplicar configuraciones y ejecutar scripts en VM incluyen Azure Custom Script Extension. Con la extensión de la secuencia de comandos personalizada, puede definir un conjunto simple de comandos o dirigir a uno o más scripts externos, como los alojados en Azure Storage o GitHub. Estos scripts pueden ejecutar tareas complejas de instalación y configuración, y garantizar que todas las VM implementadas estén configuradas de manera uniforme.
La extensión de Azure PowerShell DSC y la extensión de la secuencia de comandos personalizada se utilizan comúnmente con conjuntos de escalado de máquinas virtuales. Se aplica una de estas extensiones al conjunto de escalado y, a continuación, cuando se crean instancias de VM dentro del conjunto de escalado, se configuran automáticamente para ejecutar la aplicación. El objetivo de estas extensiones es minimizar la configuración manual requerida de las VM, que es un proceso propenso a errores y que requiere interacción humana.
Otras formas de automatizar las configuraciones de VM incluyen Puppet y Chef, ambos con extensiones de la VM Azure disponibles. Si ya tiene una herramienta de administración de configuración en uso, consulte con su proveedor el enfoque compatible para utilizar en Azure. Es muy probable que haya una extensión de VM disponible para hacer su vida más fácil.

Pruébelo ahora
Complete los siguientes pasos para habilitar la extensión de diagnóstico de VM:
1 En Azure Portal, seleccione Máquinas virtuales en el menú de la izquierda.
2 Elija la VM que creó en el ejercicio anterior.
3 En la sección Monitor del menú de VM, seleccione Configuración de diagnóstico.
4 Seleccione el botón para activar la supervisión en el nivel de invitado.
La supervisión de nivel de invitado tarda un par de minutos en activarse. Esto es lo que hace Azure:
– Instala la extensión de diagnóstico de VM
– Configura la extensión para transmitir métricas de nivel de invitado para las siguientes áreas:
–Disco lógico
–Memoria
–Interfaz de red
–Procesos
–Procesador
–Sistema
–Habilita la aplicación, la seguridad y los registros del sistema para que se transmitan a Azure Storage
Cuando instale la extensión de diagnóstico, puede limitar los datos que se recopilan seleccionando solo ciertos contadores de rendimiento a reportar. Por ejemplo, es posible que desee recopilar solo el uso de memoria o habilitar la recopilación de métricas de Microsoft SQL Server. De forma predeterminada, las métricas se recopilan cada 60 segundos. Puede ajustar esta velocidad de muestreo como desee para sus aplicaciones e infraestructura.
La extensión de diagnóstico de VM también puede transmitir archivos de registro de su máquina virtual, lo que le permite centralizar los registros de la aplicación, la seguridad y el sistema para el análisis o las alertas, como se muestra en la figura. De forma predeterminada, se registran los sistemas y los registros de aplicaciones que generan alertas críticas, errores o advertencias, junto con eventos de seguridad para las auditorías con errores. Puede cambiar los niveles de registro para registrar, así como también habilitar la recopilación de registros de IIS, los registros de aplicaciones y los eventos de Seguimiento de eventos para Windows (ETW). Como parte de la planificación e implementación de aplicaciones, determine qué registros desea recopilar.
Aquí no hay nada único de las VM Windows. Puede utilizar la extensión de diagnóstico en las VM Linux de la misma manera, a fin de obtener métricas de rendimiento y transmitir varios registros.
Por lo general, si su VM encuentra un problema, la única manera de analizar lo que sucedió es revisando los volcados de memoria. Los canales de soporte suelen solicitar estos volcados si desea llegar a la causa raíz de un problema. Al igual que con los diagnósticos de arranque, no hay manera de habilitar retroactivamente los volcados de memoria para ver por qué algo falló, así que determine si necesita supervisar ciertos procesos y sea proactivo con la configuración de los volcados de memoria. Por ejemplo, puede supervisar el proceso de IIS y registrar un volcado de memoria en Azure Storage si el proceso falla.
Aquí hay un par de otras áreas que puede configurar para las métricas de invitado:
¡ Los receptores le permiten configurar la extensión de diagnóstico de VM para enviar ciertos eventos a Azure Application Insights. Con Application Insights, puede obtener visibilidad directa sobre cómo funciona el código.
– El agente le permite especificar una cuota de almacenamiento para todas sus métricas (El valor predeterminado es 5 GB). También puede habilitar la recolección de registros para el propio agente o desinstalar el agente.

Pruébelo ahora
Complete los siguientes pasos para ver las métricas en el nivel de invitado:
1 En Azure Portal, seleccione Máquinas virtuales en el menú de la izquierda.
2 Elija la VM que creó en el ejercicio anterior.
3 En la sección Monitor del menú de VM, seleccione Métricas.
Ahora hay muchas más métricas disponibles, en comparación con las métricas básicas basadas en el host del capítulo 9. Explore algunas de las métricas del host y del invitado de la máquina virtual disponibles, y piense en algunas aplicaciones para las que podría querer monitorear métricas específicas.

Creación de alertas para condiciones de rendimiento
Con su VM configurada para exponer métricas de rendimiento en el nivel de invitado, ¿cómo sabe cuándo hay un problema? No quiere sentarse y mirar los gráficos de rendimiento en tiempo real y esperar hasta que ocurra un problema. Pero si quiere hacerlo, bienvenido. Pero hay una manera mucho mejor: las alertas de métricas.
Las alertas de métricas le permiten seleccionar un recurso, una métrica y un umbral
y, a continuación, definir a quién y cómo desea notificar cuando se cumple ese umbral. Las alertas no funcionan exclusivamente en las VM. Puede definir alertas en direcciones IP públicas que detectan paquetes de denegación de servicio distribuido (DDoS) entrantes, por ejemplo, y advertirle cuando se cumple un determinado umbral que pueda constituir un ataque.
Cuando se generan alertas, puede elegir enviar una notificación por correo electrónico a dueños, colaboradores y lectores. Estos usuarios y direcciones de correo electrónico se obtienen con base en las directivas RBAC aplicadas. En organizaciones más grandes, las alertas podrían enviar notificaciones por correo electrónico a un grupo grande de personas, ¡así que úselas con cuidado! Otra opción es especificar direcciones de correo electrónico, como las de los dueños de aplicaciones o ingenieros de infraestructura específicos, o una lista de distribución o un grupo dirigido a las partes directamente involucradas.
Existe un par de otras opciones útiles para las acciones que se deben tomar cuando se activa una alerta:
– Ejecutar un runbook. En el capítulo 18, examinaremos Azure Automation. El servicio de automatización le permite crear y utilizar runbooks que ejecutan scripts. Estos scripts pueden realizar una acción correctiva básica en la VM, por ejemplo, para reiniciar un proceso o reiniciar la VM. También podrían ejecutar los cmdlets de Azure PowerShell para habilitar las funciones de Azure Network Watcher, como los paquetes de captura, que exploraremos en el resto de este capítulo.
– Ejecutar una aplicación lógica. Azure Logic Apps le permite generar flujos de trabajo que ejecuten código sin servidor. Puede escribir información en un sistema de tickets de soporte o iniciar una llamada telefónica automatizada a un ingeniero de turno. En el capítulo 21, exploraremos el maravilloso mundo de la informática sin servidor con Azure Logic Apps y Azure Functions.
En el laboratorio de fin del capítulo, configurará algunas alertas para su VM. Sin embargo, Azure puede hacer más que ayudar a solucionar problemas y supervisar sus VM. Analicemos otra causa común cuando hay problemas: la red.

Azure Network Watcher
Las métricas de rendimiento y los diagnósticos de arranque de VM son excelentes maneras de supervisar sus aplicaciones de IaaS Azure. Los registros de aplicaciones de Web Apps y App Insights reconocen el rendimiento de sus aplicaciones PaaS. El tráfico de red suele ser menos glamoroso, pero es más probable que sea la causa de sus problemas (o de sus clientes) de conectividad de las aplicaciones.
En el capítulo 5, bromeamos con que el equipo de red siempre es el culpable de los problemas que el equipo de operaciones no puede explicar. Aquí es donde podemos tratar de volver a hacernos amigos o al menos obtener alguna prueba sólida de que la culpable es la red. Azure Network Watcher es una de esas funciones que ayuda a unir equipos en un amistoso abrazo grupal. Con Network Watcher, puede supervisar y solucionar problemas usando características tales como:
– Captura de paquetes de red
– Validación del flujo de IP para NSG
– Generación de topología de red
Lo genial acerca de estas funciones es que ponen diferentes equipos en el asiento del conductor para solucionar problemas. Si crea algunas VM y luego no puede conectarse a ellas, puede comprobar que haya conectividad de red. Para los desarrolladores, si la aplicación no puede conectarse a un nivel de la base de datos back-end, puede examinar las reglas de NSG para ver si hay algún problema. Y los ingenieros de red pueden capturar paquetes para examinar la transmisión de comunicación completa entre los hosts para un análisis más profundo.

Solución de problemas de red adicionales
Network Watcher trabaja en conjunto con los registros de diagnóstico y las métricas analizadas anteriormente. Los recursos de red como los equilibradores de carga y los Application Gateways también pueden generar registros de diagnóstico. Estos registros funcionan de la misma manera que los registros de aplicaciones y sistemas desde una VM o una aplicación web. Los registros se cotejan en Azure Portal para que usted determine si hay errores en la configuración o en las comunicaciones entre hosts y aplicaciones.
DNS y Traffic Manager también tienen un área de Solución de problemas en Azure Portal. El portal lo guía a través de algunos errores comunes que puede encontrar, ofrece consejos de configuración y proporciona vínculos a documentación adicional. Si todo lo demás falla, puede abrir una solicitud de asistencia para el Soporte técnico de Azure.
Aunque a menudo puede ser más fácil compilar implementaciones de aplicaciones de gran tamaño con las plantillas de Azure Resource Manager o con los scripts de CLI de Azure o PowerShell, Azure Portal cuenta con muchas herramientas y funciones excelentes que puede usar cuando está teniendo problemas. Especialmente con las configuraciones de red complicadas y las directivas de seguridad, unos pocos segundos de su tiempo para revisar los resultados de las herramientas de Network Watcher pueden ayudar a identificar un problema y resolverlo rápidamente. Todas estas herramientas ayudan a mejorar el estado general y la experiencia de las aplicaciones para sus clientes.

Verificación de flujos de IP
Este es un problema común: los clientes no pueden conectarse a su aplicación. La aplicación funciona bien cuando se conecta desde la oficina, pero los clientes no pueden acceder a la aplicación a través de Internet público. ¿Por qué?

VPNs y ExpressRoute
Azure Virtual Private Networks (VPN) proporciona comunicaciones seguras entre las oficinas locales y los centros de datos de Azure. Azure ExpressRoute proporciona conexiones privadas de alta velocidad y exclusiva desde oficinas locales hasta los centros de datos Azure y suele utilizarse en grandes organizaciones.
Ambas conexiones son un poco más complicadas de configurar que lo que podemos cubrir en un solo descanso de almuerzo y, por lo general, se configuran una sola vez. El equipo de red suele ser el responsable de configurarlas, y es posible que usted ni siquiera sepa que accede a Azure a través de una conexión privada.

Todas las pruebas de su aplicación funcionan bien. Puede acceder a la aplicación a través de un navegador web, realizar pedidos y recibir notificaciones por correo electrónico. Pero cuando sus clientes intentan hacer un pedido, la aplicación no se carga.
¿Cómo puede ayudar Network Watcher? Verificando los flujos IP. Network Watcher simula el flujo de tráfico a su destino e informa si el tráfico puede llegar a su VM.
Pruébelo ahora
Complete los siguientes pasos para habilitar Network Watcher y verificar flujos IP:
1 En Azure Portal, elija Todos los recursos en la parte superior del menú de navegación a la izquierda.
2 Filtre y seleccione Network Watcher en la lista de servicios disponibles. Habilite Network Watcher en las regiones que desea supervisar. Cuando habilita Network Watcher en una región, Azure utiliza controles de acceso basados en roles para los diversos recursos y tráfico de red.
3 Amplíe la lista de regiones para su cuenta. Es posible que algunas regiones ya estén habilitadas. Si la región en la que se implementó su máquina virtual no está habilitada, seleccione la región y, a continuación, habilite Network Watcher.
4 Cuando Network Watcher esté activado en una región (tarda uno o dos minutos), seleccione Comprobación del flujo de IP en Herramientas de diagnóstico de red en el lado izquierdo de la ventana de Network Watcher.
5 Seleccione el grupo de recursos, como azuremolchapter12 y la VM, como molvm. De forma predeterminada, el protocolo se establece en TCP y la dirección es entrante. También se rellena la dirección IP local de la NIC virtual.
6 Para Puerto local, ingrese puerto 80. Si aceptó los valores predeterminados al crear la VM en el ejercicio anterior, no abrió el puerto 80, así que esta es una buena prueba de lo que sucede cuando se deniega el tráfico.
7 En Dirección IP remota, ingrese 8.8.8.8. Esta dirección puede parecer familiar: es un servidor DNS abierto proporcionado por Google. No está haciendo nada con este servidor; solo tiene que dar a Network Watcher una dirección IP externa para simular el flujo de tráfico. También puede ir a https://whatsmyip.com e ingresar su dirección IP pública real.
8 Establezca el puerto remoto en el puerto 80 y, a continuación, seleccione Comprobar.
El resultado de la comprobación del flujo de IP debe ser Acceso denegado. Prácticamente, Network Watcher le dice qué regla provocó que el flujo de tráfico fallara: la regla DenyAllInBound. Como ya lo sabe, hay una regla de seguridad de red que bloquea el tráfico, pero ¿dónde se aplica esta regla? ¿En la subred, la NIC virtual o el grupo de seguridad de aplicaciones? Otra función de Network Watcher puede decírselo.

Visualización de reglas efectivas de NSG
Las reglas NSG se pueden aplicar a una única NIC virtual, en el nivel de subred o a un grupo de VM en un grupo de seguridad de aplicaciones. Las reglas se combinan, lo que permite especificar un conjunto de reglas comunes en toda una subred y luego obtener

más detalles para los grupos de seguridad de aplicaciones (como «Permitir el puerto TCP 80 en todos los servidores web») o de una VM individual.
A continuación se muestran algunos ejemplos comunes de cómo se pueden aplicar las reglas de NSG:
¡ Nivel de subred: permite que el puerto TCP 5986 administre de forma remota y segura la subred de administración 10.1.10.20/24.
¡ Nivel de grupo de seguridad de aplicaciones: permite el puerto TCP 80 para tráfico HTTP a aplicaciones web y aplica el grupo de seguridad de aplicaciones a todas las VM de aplicaciones web.
¡ Nivel de NIC virtual: permite el puerto TCP 3389 el acceso a escritorio remoto desde la subred de administración 10.1.10.20/24.
Estas reglas son básicas y permiten explícitamente cierto tráfico. Si no hay reglas allow que permitan coincidir con un paquete de red, se aplican las reglas DenyAll predeterminadas para detener el tráfico.
Durante la prueba de la aplicación analizada en el ejemplo, es posible que haya configurado esa regla HTTP solo para permitir el tráfico de una de las subredes locales. Ahora, los clientes no pueden conectarse a través de Internet público.

Pruébelo ahora
Complete los siguientes pasos para determinar dónde se aplica una regla de NSG:
1 En Network Watcher, seleccione Reglas de seguridad eficaces a la izquierda.
2 Seleccione el grupo de recursos, como azuremolchapter12 y su VM, como molvm. Las reglas efectivas tardan unos segundos en aparecer.

Las reglas predeterminadas de la VM creada anteriormente no son interesantes, pero puede desplazarse a través de la subred, la interfaz de red y las reglas predeterminadas para tener una idea de cómo se combinan las reglas efectivas y cómo puede identificar dónde se aplican las reglas si necesita realizar cambios.

Captura de paquetes de red
Supongamos que ha actualizado las reglas de seguridad de red para permitir el acceso a su aplicación para clientes de Internet público, pero un cliente informa que está experimentando un comportamiento extraño. A veces, la aplicación web no se carga
o muestra imágenes incompletas. Pareciera que se agota el tiempo de espera de la conexión.
Los problemas intermitentes son a menudo los más difíciles de solucionar, especialmente si tiene acceso limitado o nulo al equipo que sufre el problema. Un enfoque de solución de problemas común es capturar los paquetes de red y revisarlos para detectar signos de cualquier problema, como errores de transmisión de red, paquetes malformados o problemas de protocolo y comunicación.
Con las capturas de paquetes de red, obtiene la transmisión de datos sin procesar entre dos o más hosts. Hay un arte para analizar las capturas de red y no es para los débiles de corazón. Herramientas especiales de terceros como Wireshark de Riverbed, Fiddler de Telerik y Message Analyzer de Microsoft proporcionan una forma gráfica para que vea y filtre los paquetes de red, típicamente agrupándolos mediante comunicaciones o protocolos relacionados. En la figura se muestra un ejemplo de captura de paquetes de red.
Para habilitar Network Watcher para capturar paquetes desde y hacia las VM, primero Instale la extensión VM de Network Watcher. Como vio en la sección 12.3.2, las extensiones de VM proporcionan una manera para que la plataforma Azure llegue al interior de una VM para realizar varias tareas de administración. En el caso de la extensión de Network Watcher, examina el tráfico de red desde y hacia la VM.

Pruébelo ahora
Siga los pasos descritos a continuación para instalar los paquetes de red de captura
y extensión de VM de Network Watcher:
1 En Azure Portal, seleccione Máquinas virtuales en el menú de la izquierda
y, a continuación, seleccione la VM, como molvm.
2 En la categoría Configuración a la izquierda en la ventana de VM, seleccione Extensiones.
3 Seleccione Agregar una extensión.
4 En la lista de extensiones disponibles, seleccione Agente de Network Watcher para Windows y luego seleccione Crear.
5 Para confirmar la instalación de la extensión, seleccione Aceptar. La instalación del agente de Network Watcher puede tardar algunos minutos en instalarse en su VM.
6 Para volver al menú de Network Watcher en Azure Portal, seleccione Todos los servicios en la parte superior del menú de navegación de Servicios a la izquierda del portal y, a continuación, seleccione Network Watcher.
7 En la sección Herramientas de diagnóstico de red a la izquierda en la ventana de Network Watcher, seleccione Captura de paquetes y, a continuación, seleccione Agregar una nueva captura.
8 Seleccione el grupo de recursos, como azuremolchapter12, y la VM, como molvm; luego escriba un nombre para su captura de paquetes, como molcapture.
De forma predeterminada, las capturas de paquetes se almacenan en Azure Storage. También puede elegir guardar en archivo y especificar un directorio local en la VM de origen. La extensión del agente de Network Watcher luego escribe el archivo de captura de paquetes en el disco en la VM.
9 Si no está ya seleccionado, elija el nombre de la cuenta de almacenamiento que comienza con el nombre del grupo de recursos, como azuremolchapter12diag493. Esta cuenta de almacenamiento creada y utilizada por la extensión de diagnóstico de VM que habilitó anteriormente.
10 Puede especificar un tamaño máximo para cada paquete (el valor predeterminado es 0 para todo el paquete), el tamaño máximo del archivo para la sesión de captura de paquetes (el valor predeterminado es 1 GB) y el límite de tiempo para la captura de paquetes (el valor predeterminado es 5 horas). Para capturar solo el tráfico de fuentes o puertos específicos, también puede agregar un filtro para reducir el alcance de las capturas de paquetes.
11 Defina un límite de tiempo de 60 segundos.
12 Para iniciar la captura de paquetes, seleccione Aceptar.
El inicio de la captura tarda uno o dos minutos. Cuando la captura está en curso, los datos se transmiten a la cuenta de Azure Storage o al archivo local de la VM. La lista de capturas se muestra en la página del portal de Network Watcher. Si transmite los registros a Azure Storage, puede hacer que la captura vaya directamente a la cuenta de almacenamiento y descargar el archivo de captura .cap. A continuación, puede abrir la captura de paquetes en un programa de análisis, como se analizó en la sección 12.3.3. De hecho, la captura de red de ejemplo mostrada en la figura anteriormente en este capítulo era de una captura de paquetes de Azure Network Watcher.

Laboratorio: Creación de alertas de rendimiento
Espero que el diagnóstico, las métricas de VM y las funciones de Network Watcher abordadas en este capítulo le hayan dado una idea de lo que hay disponible en Azure para ayudarle a solucionar problemas con las aplicaciones. Algunas cosas, como los diagnósticos de arranque y la extensión de diagnóstico de VM, tienen más sentido cuando las habilita y configura a medida que implementa las VM.
En este laboratorio, configurará algunas alertas de métricas para ver qué notificaciones puede recibir y cómo se verán las alertas cuando las reciba:
1 En Azure Portal, busque la VM que creó en los ejercicios anteriores.
2 En la sección Monitor de la VM, seleccione Alertas.
3 Elija crear una regla de alerta y, a continuación, agregue una condición para cuando el porcentaje de la CPU sea superior a un promedio del 10 % en los últimos 5 minutos. Un gráfico le mostrará cuáles son las métricas más recientes, así que ajuste el umbral si el 10 % no activó una alerta.
4 Agregue un grupo de acciones y asígnele un nombre y un nombre corto. Para este laboratorio, establece ambos nombres como azuremol. Los grupos de acciones le permiten definir conjuntos de pasos reutilizables para realizar cuando se genera una alerta, como enviar un correo electrónico a un conjunto de usuarios o ejecutar un script de PowerShell automatizado o una Azure Logic App.
5 Explore los tipos de acción disponibles y, a continuación, seleccione correo electrónico/SMS/Push/de voz.
6 Elija cómo quiere que se le notifique, por ejemplo, por correo electrónico
o mensaje de texto. Es posible que se apliquen algunos cargos del operador por las notificaciones de SMS o de voz.
7 Una vez creado el grupo de acciones, asigne un nombre a la alerta y luego especifique una seguridad. Esta gravedad es útil cuando tiene muchas alertas definidas para ayudarle a clasificar y priorizar lo que debe resolver primero.
8 Cuando esté listo, cree la regla. La regla tarda entre 10 y 15 minutos en activarse y generar las notificaciones definidas.
Este ejemplo es básico, así que piense en las alertas y notificaciones existentes que tiene para las aplicaciones y servicios y en cómo podría utilizar esta función cuando ejecute cargas de trabajo en Azure.

Y aqui finalizamos la entrada de hoy, gracias.