Uso de Citrix ADM para solucionar problemas de redes nativas de Citrix Cloud™

Descripción general

En este documento, revisamos cómo puede usar Citrix ADM para entregar y supervisar aplicaciones de microservicios de Kubernetes. También profundizamos en el uso de la CLI, los gráficos de servicios y el rastreo para permitir que los equipos de plataforma y SRE solucionen problemas.

Descripción general del rendimiento y la latencia de las aplicaciones

Cifrado TLS

TLS es un protocolo de cifrado diseñado para proteger las comunicaciones por Internet. Un protocolo de enlace TLS es el proceso que inicia una sesión de comunicación que utiliza cifrado TLS. Durante un protocolo de enlace TLS, las dos partes que se comunican intercambian mensajes para reconocerse, verificarse, establecer los algoritmos de cifrado que utilizan y acordar las claves de sesión. Los protocolos de enlace TLS son una parte fundamental del funcionamiento de HTTPS.

Protocolos de enlace TLS frente a SSL

SSL, o Secure Sockets Layer, fue el protocolo de cifrado original desarrollado para HTTP. TLS, Transport Layer Security, reemplazó a SSL hace algún tiempo. Los protocolos de enlace SSL ahora se denominan protocolos de enlace TLS, aunque el nombre “SSL” todavía se usa ampliamente.

¿Cuándo se produce un protocolo de enlace TLS?

Un protocolo de enlace TLS tiene lugar cada vez que un usuario navega a un sitio web a través de HTTPS y el navegador comienza a consultar el servidor de origen del sitio web. Un protocolo de enlace TLS también ocurre cada vez que cualquier otra comunicación utiliza HTTPS, incluidas las llamadas a la API y las consultas de DNS sobre HTTPS.

Los protocolos de enlace TLS se producen después de que se haya abierto una conexión TCP a través de un protocolo de enlace TCP.

¿Qué sucede durante un protocolo de enlace TLS?

• Durante un protocolo de enlace TLS, el cliente y el servidor realizan lo siguiente:
  • Especifican qué versión de TLS (TLS 1.0, 1.2, 1.3, etc.) utilizan.
  • Deciden qué conjuntos de cifrado (consulte la siguiente sección) utilizan.
  • Autenticar la identidad del servidor mediante la clave pública del servidor y la firma digital de la autoridad de certificación SSL.
  • Generar claves de sesión para usar cifrado simétrico una vez completado el protocolo de enlace.

¿Cuáles son los pasos de un protocolo de enlace TLS?

• Los protocolos de enlace TLS son una serie de datagramas, o mensajes, intercambiados por un cliente y un servidor. Un protocolo de enlace TLS implica varios pasos, ya que el cliente y el servidor intercambian la información necesaria para completar el protocolo de enlace y hacer posible una conversación posterior.

Los pasos exactos dentro de un protocolo de enlace TLS varían según el tipo de algoritmo de intercambio de claves utilizado y los conjuntos de cifrado admitidos por ambas partes. El algoritmo de intercambio de claves RSA es el más utilizado. Funciona de la siguiente manera:

1. El mensaje de ‘saludo del cliente’: El cliente inicia el protocolo de enlace enviando un mensaje de “saludo” al servidor. El mensaje incluye la versión de TLS que admite el cliente, los conjuntos de cifrado admitidos y una cadena de bytes aleatorios conocida como “aleatorio del cliente”.
2. El mensaje de ‘saludo del servidor’: En respuesta al mensaje de saludo del cliente, el servidor envía un mensaje que contiene el certificado SSL del servidor, el conjunto de cifrado elegido por el servidor y el “aleatorio del servidor”, otra cadena aleatoria de bytes generada por el servidor.
3. Autenticación: El cliente verifica el certificado SSL del servidor con la autoridad de certificación que lo emitió. Esto confirma que el servidor es quien dice ser y que el cliente está interactuando con el propietario real del dominio.
4. El secreto pre-maestro: El cliente envía una cadena más de bytes aleatorios, el “secreto pre-maestro”. El secreto pre-maestro se cifra con la clave pública y solo puede ser descifrado con la clave privada por el servidor. (El cliente obtiene la clave pública del certificado SSL del servidor).
5. Clave privada utilizada: El servidor descifra el secreto pre-maestro.
6. Claves de sesión creadas: Tanto el cliente como el servidor generan claves de sesión a partir del aleatorio del cliente, el aleatorio del servidor y el secreto pre-maestro. Deberían llegar a los mismos resultados.
7. El cliente está listo: El cliente envía un mensaje de “finalizado” que está cifrado con una clave de sesión.
8. El servidor está listo: El servidor envía un mensaje de “finalizado” cifrado con una clave de sesión.
9. Cifrado simétrico seguro logrado: El protocolo de enlace se ha completado y la comunicación continúa utilizando las claves de sesión.

Todos los protocolos de enlace TLS utilizan cifrado asimétrico (la clave pública y privada), pero no todos utilizan la clave privada en el proceso de generación de claves de sesión. Por ejemplo, un protocolo de enlace efímero Diffie-Hellman procede de la siguiente manera:

1. Saludo del cliente: El cliente envía un mensaje de saludo del cliente con la versión del protocolo, el aleatorio del cliente y una lista de conjuntos de cifrado.
2. Saludo del servidor: El servidor responde con su certificado SSL, su conjunto de cifrado seleccionado y el aleatorio del servidor. A diferencia del protocolo de enlace RSA descrito en la sección anterior, en este mensaje el servidor también incluye lo siguiente (paso 3).
3. Firma digital del servidor: El servidor utiliza su clave privada para cifrar el aleatorio del cliente, el aleatorio del servidor y su parámetro DH*. Estos datos cifrados funcionan como la firma digital del servidor, estableciendo que el servidor tiene la clave privada que coincide con la clave pública del certificado SSL.
4. Firma digital confirmada: El cliente descifra la firma digital del servidor con la clave pública, verificando que el servidor controla la clave privada y es quien dice ser. Parámetro DH del cliente: El cliente envía su parámetro DH al servidor.
5. El cliente y el servidor calculan el secreto pre-maestro: En lugar de que el cliente genere el secreto pre-maestro y lo envíe al servidor, como en un protocolo de enlace RSA, el cliente y el servidor utilizan los parámetros DH que intercambiaron para calcular un secreto pre-maestro coincidente por separado.
6. Claves de sesión creadas: Ahora, el cliente y el servidor calculan las claves de sesión a partir del secreto pre-maestro, el aleatorio del cliente y el aleatorio del servidor, al igual que en un protocolo de enlace RSA.
   • El cliente está listo: Igual que un protocolo de enlace RSA
   • El servidor está listo
   • Cifrado simétrico seguro logrado

   *Parámetro DH: DH significa Diffie-Hellman. El algoritmo Diffie-Hellman utiliza cálculos exponenciales para llegar al mismo secreto pre-maestro. El servidor y el cliente proporcionan cada uno un parámetro para el cálculo, y cuando se combinan, dan como resultado un cálculo diferente en cada lado, con resultados iguales.

Para obtener más información sobre el contraste entre los protocolos de enlace efímeros Diffie-Hellman y otros tipos de protocolos de enlace, y cómo logran la confidencialidad directa, consulte esta Documentación del protocolo TLS.

¿Qué es un conjunto de cifrado?

• Un conjunto de cifrado es un conjunto de algoritmos de cifrado que se utilizan para establecer una conexión de comunicaciones segura. (Un algoritmo de cifrado es un conjunto de operaciones matemáticas realizadas sobre datos para que estos parezcan aleatorios.) Existen varios conjuntos de cifrado de uso generalizado, y una parte esencial del protocolo de enlace TLS es acordar qué conjunto de cifrado se utiliza para ese protocolo de enlace.

Para empezar, consulte Referencia: Documentación del protocolo TLS.

Panel SSL de Citrix Application Delivery Management

Citrix Application Delivery Management (ADM) ahora simplifica todos los aspectos de la gestión de certificados. A través de una única consola, puede establecer políticas automatizadas para garantizar el emisor correcto, la solidez de la clave y los algoritmos adecuados, al tiempo que mantiene un control estricto sobre los certificados que no se utilizan o que están próximos a caducar. Para empezar a utilizar el panel SSL de Citrix ADM y sus funcionalidades, debe comprender qué es un certificado SSL y cómo puede utilizar Citrix ADM para rastrear sus certificados SSL.

A Secure Socket Layer (SSL) certificate, which is a part of any SSL transaction, is a digital data form (X509) that identifies a company (domain) or an individual. The certificate has a public key component that is visible to any client that wants to initiate a secure transaction with the server. The corresponding private key, which resides securely on the Citrix Application Delivery Controller™ (ADC) appliance, is used to complete asymmetric key (or public key) encryption and decryption.

Puede obtener un certificado y una clave SSL de cualquiera de las siguientes maneras:

• De una autoridad de certificación (CA) autorizada
• Generando un nuevo certificado SSL y clave en el dispositivo Citrix ADC

Citrix ADM proporciona una vista centralizada de los certificados SSL instalados en todas las instancias de Citrix ADC administradas. En el panel SSL, puede ver gráficos que le ayudan a rastrear emisores de certificados, fortalezas de clave, algoritmos de firma, certificados caducados o no utilizados, etc. También puede ver la distribución de los protocolos SSL que se ejecutan en sus servidores virtuales y las claves que están habilitadas en ellos.

También puede configurar notificaciones para que le informen cuando los certificados estén a punto de caducar e incluir información sobre qué instancias de Citrix ADC utilizan esos certificados.

Puede vincular los certificados de una instancia de Citrix ADC a un certificado de CA. Sin embargo, asegúrese de que los certificados que vincule al mismo certificado de CA tengan la misma fuente y el mismo emisor. Una vez que haya vinculado los certificados a un certificado de CA, puede desvincularlos.

Para empezar, consulte la siguiente Documentación del panel SSL.

Integraciones de terceros

La latencia de la aplicación se mide en milisegundos y puede indicar una de dos cosas, según la métrica utilizada. La forma más común de medir la latencia se denomina “tiempo de ida y vuelta” (o RTT). El RTT calcula el tiempo que tarda un paquete de datos en viajar de un punto a otro de la red y en que se envíe una respuesta de vuelta al origen. La otra medida se denomina “tiempo hasta el primer byte” (o TTFB), que registra el tiempo que transcurre desde el momento en que un paquete sale de un punto de la red hasta el momento en que llega a su destino. El RTT se utiliza más comúnmente para medir la latencia porque se puede ejecutar desde un único punto de la red y no requiere que se instale software de recopilación de datos en el punto de destino (como sí lo requiere el TTFB).

Al monitorizar el uso del ancho de banda y el rendimiento de su aplicación en tiempo real, el servicio ADM facilita la identificación de problemas y la resolución preventiva de posibles problemas antes de que se manifiesten y afecten a los usuarios de su red. Esta solución basada en flujos rastrea el uso por interfaz, aplicación y conversación, proporcionándole información detallada sobre la actividad en su red.

Uso de herramientas de Splunk

El rendimiento de la infraestructura y de las aplicaciones son interdependientes. Para ver el panorama completo, SignalFx proporciona una correlación perfecta entre la infraestructura de la nube y los microservicios que se ejecutan sobre ella. Si su aplicación falla debido a una fuga de memoria, un contenedor de vecino ruidoso o cualquier otro problema relacionado con la infraestructura, SignalFx se lo hace saber. Para completar el panorama, el acceso en contexto a los registros y eventos de Splunk permite una resolución de problemas más profunda y un análisis de la causa raíz.

Para obtener más información sobre SignalFx Microservices APM y la resolución de problemas con Splunk, consulte la información de Splunk for DevOps.

Soporte de MongoDB

MongoDB almacena datos en documentos flexibles, similares a JSON. Esto significa que los campos pueden variar de un documento a otro y la estructura de datos puede cambiar con el tiempo.

El modelo de documentos se asigna a los objetos en el código de su aplicación, lo que facilita el trabajo con los datos.

Las consultas bajo demanda, la indexación y la agregación en tiempo real proporcionan formas potentes de acceder y analizar sus datos.

MongoDB es una base de datos distribuida en su esencia, por lo que la alta disponibilidad, el escalado horizontal y la distribución geográfica están integrados y son fáciles de usar.

MongoDB está diseñado para satisfacer las demandas de las aplicaciones modernas con una base tecnológica que le permite a través de:

• El modelo de datos de documentos – que le presenta la mejor manera de trabajar con los datos.
• Un diseño de sistemas distribuidos – que le permite colocar los datos de forma inteligente donde los desee.
• Una experiencia unificada que le da la libertad de ejecutar en cualquier lugar – lo que le permite preparar su trabajo para el futuro y eliminar la dependencia de un proveedor.

Con estas capacidades, puede construir una Plataforma de Datos Operacionales Inteligente, respaldada por MongoDB. Para obtener más información, consulte la Documentación de MongoDB.

Cómo equilibrar la carga del tráfico de Ingress a una aplicación basada en TCP o UDP

En un entorno de Kubernetes, un Ingress es un objeto que permite el acceso a los servicios de Kubernetes desde fuera del clúster de Kubernetes. Los recursos de Ingress estándar de Kubernetes asumen que todo el tráfico se basa en HTTP y no admiten protocolos no basados en HTTP como TCP, TCP-SSL y UDP. Por lo tanto, las aplicaciones críticas basadas en protocolos L7 como DNS, FTP, LDAP, no pueden exponerse utilizando el Ingress estándar de Kubernetes.

La solución estándar de Kubernetes es crear un servicio de tipo LoadBalancer. Consulte Tipo de servicio LoadBalancer en Citrix ADC para obtener más información.

La segunda opción es anotar el objeto ingress. El controlador de entrada de Citrix le permite equilibrar la carga del tráfico de entrada basado en TCP o UDP. Proporciona las siguientes anotaciones que puede utilizar en la definición de su recurso de entrada de Kubernetes para equilibrar la carga del tráfico de entrada basado en TCP o UDP:

• ingress.citrix.com/insecure-service-type: La anotación permite el equilibrio de carga L4 con TCP, UDP o ANY como protocolo para Citrix ADC.
• ingress.citrix.com/insecure-port: La anotación configura el puerto TCP. La anotación es útil cuando se requiere acceso a microservicios en un puerto no estándar. De forma predeterminada, el puerto 80 está configurado.

Para obtener más información, consulte Cómo equilibrar la carga del tráfico de entrada a una aplicación basada en TCP o UDP

Supervise y mejore el rendimiento de sus aplicaciones basadas en TCP o UDP

Los desarrolladores de aplicaciones pueden supervisar de cerca el estado de las aplicaciones basadas en TCP o UDP a través de monitores enriquecidos (como TCP-ECV, UDP-ECV) en Citrix ADC. Los monitores ECV (validación de contenido extendida) ayudan a verificar si la aplicación devuelve el contenido esperado o no.

Además, el rendimiento de la aplicación se puede mejorar utilizando métodos de persistencia como la IP de origen. Puede utilizar estas funciones de Citrix ADC a través de anotaciones inteligentes en Kubernetes. El siguiente es un ejemplo:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
    name: mongodb
    annotations:
        ingress.citrix.com/insecure-port: “80”
        ingress.citrix.com/frontend-ip: “192.168.1.1”
        ingress.citrix.com/csvserver: ‘{“l2conn”:”on”}’
        ingress.citrix.com/lbvserver: ‘{“mongodb-svc”:{“lbmethod”:”SRCIPDESTIPHASH”}}’
        ingress.citrix.com/monitor: ‘{“mongodbsvc”:{“type”:”tcp-ecv”}}’
Spec:
    rules:
    - host: mongodb.beverages.com
      http:
        paths:
        - path: /
          backend:
            serviceName: mongodb-svc
            servicePort: 80
<!--NeedCopy-->

Servicio Citrix Application Delivery Management (ADM)

El servicio Citrix ADM ofrece los siguientes beneficios:

• Ágil – Fácil de operar, actualizar y consumir. El modelo de servicio de Citrix ADM Service está disponible en la nube, lo que facilita la operación, actualización y uso de las funciones proporcionadas. La frecuencia de las actualizaciones, combinada con la función de actualización automatizada, mejora rápidamente su implementación de Citrix ADC.
• Tiempo de comercialización más rápido – Logro más rápido de los objetivos comerciales. A diferencia de la implementación tradicional local, puede utilizar su servicio Citrix ADM con unos pocos clics. No solo ahorra tiempo de instalación y configuración, sino que también evita desperdiciar tiempo y recursos en posibles errores.
• Administración multisitio – Un único panel de control para instancias en centros de datos multisitio. Con el servicio Citrix ADM, puede administrar y supervisar los Citrix ADC que se encuentran en varios tipos de implementaciones. Dispone de una administración centralizada para los Citrix ADC implementados localmente y en la nube.
• Eficiencia operativa – Forma optimizada y automatizada de lograr una mayor productividad operativa. Con el servicio Citrix ADM, sus costos operativos se reducen al ahorrar tiempo, dinero y recursos en el mantenimiento y la actualización de las implementaciones de hardware tradicionales.

Gráfico de servicios para aplicaciones de Kubernetes

Mediante el uso de la función de gráfico de servicios para aplicaciones nativas de la nube en Citrix ADM, puede:

• Asegurar el rendimiento general de la aplicación de extremo a extremo
• Identificar los cuellos de botella creados por la interdependencia de los diferentes componentes de sus aplicaciones
• Obtener información sobre las dependencias de los diferentes componentes de sus aplicaciones
• Supervisar los servicios dentro del clúster de Kubernetes
• Supervisar qué servicio tiene problemas
• Comprobar los factores que contribuyen a los problemas de rendimiento
• Ver visibilidad detallada de las transacciones HTTP del servicio
• Analizar las métricas HTTP, TCP y SSL

Al visualizar estas métricas en Citrix ADM, puede analizar la causa raíz de los problemas y tomar las medidas de solución de problemas necesarias más rápidamente. El gráfico de servicios muestra sus aplicaciones en varios servicios de componentes. Estos servicios que se ejecutan dentro del clúster de Kubernetes pueden comunicarse con varios componentes dentro y fuera de la aplicación.

Para empezar, consulte Configuración del gráfico de servicios.

Gráfico de servicios para aplicaciones web de 3 niveles

Mediante la función de gráfico de servicios del panel de aplicaciones, puede ver:

• Detalles sobre cómo está configurada la aplicación (con servidor virtual de conmutación de contenido y servidor virtual de equilibrio de carga)
  • Para aplicaciones GSLB, puede ver el centro de datos, la instancia de ADC, los servidores virtuales CS y LB
• Transacciones de extremo a extremo desde el cliente hasta el servicio
• La ubicación desde donde el cliente accede a la aplicación
• El nombre del centro de datos donde se procesan las solicitudes del cliente y las métricas de Citrix ADC del centro de datos asociado (solo para aplicaciones GSLB)
• Detalles de las métricas para el cliente, el servicio y los servidores virtuales
• Si los errores provienen del cliente o del servicio
• El estado del servicio, como Crítico, Revisión y Bueno. Citrix ADM muestra el estado del servicio en función del tiempo de respuesta del servicio y el recuento de errores.
  • Crítico (rojo) - Indica cuando el tiempo medio de respuesta del servicio > 200 ms Y el recuento de errores > 0
  • Revisión (naranja) - Indica cuando el tiempo medio de respuesta del servicio > 200 ms O el recuento de errores > 0
  • Bueno (verde) - Indica que no hay errores y el tiempo medio de respuesta del servicio < 200 ms
• El estado del cliente, como Crítico, Revisión y Bueno. Citrix ADM muestra el estado del cliente en función de la latencia de la red del cliente y el recuento de errores.
  • Crítico (rojo)- Indica cuando la latencia media de la red del cliente > 200 ms Y el recuento de errores > 0
  • Revisión (naranja) - Indica cuando la latencia media de la red del cliente > 200 ms O el recuento de errores > 0
  • Bueno (verde) - Indica que no hay errores y la latencia media de la red del cliente < 200 ms
• El estado del servidor virtual, como Crítico, Revisión y Bueno. Citrix ADM muestra el estado del servidor virtual en función de la puntuación de la aplicación.
  • Crítico (rojo) - Indica cuando la puntuación de la aplicación < 40
  • Revisión (naranja) - Indica cuando la puntuación de la aplicación está entre 40 y 75
  • Bueno (verde) - Indica cuando la puntuación de la aplicación es > 75

Puntos a tener en cuenta:

• Solo los servidores virtuales de equilibrio de carga, conmutación de contenido y GSLB se muestran en el gráfico de servicios.
• Si ningún servidor virtual está vinculado a una aplicación personalizada, los detalles no son visibles en el gráfico de servicios para esa aplicación.
• Solo puede ver métricas para clientes y servicios en el gráfico de servicios si se producen transacciones activas entre los servidores virtuales y la aplicación web.
• Si no hay transacciones activas disponibles entre los servidores virtuales y la aplicación web, solo puede ver los detalles en el gráfico de servicios basándose en los datos de configuración, como el equilibrio de carga, la conmutación de contenido, los servidores virtuales GSLB y los servicios.
• Las actualizaciones en la configuración de la aplicación pueden tardar 10 minutos en reflejarse en el gráfico de servicios.

Para obtener más información, consulte Gráfico de servicios para aplicaciones.

Para empezar, consulte Documentación del gráfico de servicios.

Solución de problemas para equipos de Citrix ADC

Analicemos algunos de los atributos más comunes para la solución de problemas de la plataforma Citrix ADC y cómo estas técnicas de solución de problemas se aplican a las implementaciones de Nivel 1 para topologías de microservicios.

El Citrix ADC tiene una interfaz de línea de comandos (CLI) que muestra comandos en tiempo real y es útil para determinar configuraciones en tiempo de ejecución, estadísticas y configuración de políticas. Esto se facilita a través del comando “SHOW”.

SHOW - realizar operaciones de CLI de ADC:

>Show running config (-summary -fullValues)

 Ability to search (grep command)
>“sh running config | -i grep vserver”

Check the version.
>Show license
  “sh license"
<!--NeedCopy-->

Mostrar estadísticas SSL

>Sh ssl
        System
        Frontend
        Backend
        Encryption
<!--NeedCopy-->

Mostrar estadísticas SSL(/es-es/advanced-concepts/media/show-ssl-statistics.png)

El Citrix ADC tiene un comando para enumerar estadísticas de todos los objetos basándose en un intervalo de contador de siete (7) segundos. Esto se facilita a través del comando “STAT”.

Telemetría L3-L7 altamente granular por Citrix ADC

• Nivel de sistema: Utilización de CPU y memoria de ADC.
• Protocolo HTTP: #Solicitudes/Respuestas, división GET/POST, errores HTTP para N-S y E-W (solo para service mesh lite, sidecar pronto).
• SSL: #Sesiones y #Handshakes para tráfico N-S y E-W solo para service mesh lite.
• Protocolo IP: #Paquetes recibidos/enviados, #Bytes recibidos/enviados, #Paquetes truncados y #Búsqueda de dirección IP.
• Citrix ADC AAA: #Sesiones activas
• Interfaz: #Total de paquetes de multidifusión, #Total de bytes transferidos y #Paquetes Jumbo recibidos/enviados.
• Servidor virtual de equilibrio de carga y servidor virtual de conmutación de contenido: #Paquetes, #Aciertos y #Bytes recibidos/enviados.

STAT - realizar operaciones CLI de ADC:

>Statistics
“stat ssl”
<!--NeedCopy-->

Iniciar SSL(/es-es/advanced-concepts/media/start-ssl.png)

El Citrix ADC tiene una estructura de archivo de registro que permite la búsqueda de estadísticas y contadores al solucionar errores específicos a través del comando “NSCONMSG”.

NSCONMSG - archivo de registro principal (formato de datos ns)

    Cd/var/nslog

    “Mac Moves”
    nsconmsg -d current -g nic_err
<!--NeedCopy-->

Flujo de comandos(/es-es/advanced-concepts/media/command-flow.png)

Nstcpdump

Puede usar nstcpdump para la resolución de problemas de bajo nivel. nstcpdump recopila información menos detallada que nstrace. Abra la CLI de ADC y escriba shell. Puede usar filtros con nstcpdump pero no puede usar filtros específicos para los recursos de ADC. La salida del volcado se puede ver directamente en la pantalla de la CLI.

CTRL + C – Pulse estas teclas simultáneamente para detener un nstcpdump.

nstcpdump.sh dst host x.x.x.x – Muestra el tráfico enviado al host de destino.

nstcpdump.sh -n src host x.x.x.x – Muestra el tráfico del host especificado y no convierte las direcciones IP en nombres (-n).

nstcpdump.sh host x.x.x.x – Muestra el tráfico hacia y desde la IP del host especificado.

NSTRACE - archivo de seguimiento de paquetes

NSTRACE es una herramienta de depuración de paquetes de bajo nivel para la resolución de problemas de red. Permite almacenar archivos de captura que puede analizar posteriormente utilizando las herramientas de análisis. Dos herramientas comunes son Network Analyzer y Wireshark.

Una vez que el archivo de captura de NSTRACE se crea en /var/nstrace en el ADC, puede importar el archivo de captura en Wireshark para la captura de paquetes y el análisis de red.

SYSCTL - Información detallada de ADC: Descripción, Modelo, Plataforma, CPU, etc

    sysctl -a grep hw.physmem

    hw.physmem: 862306304
    netscaler.hw_physmem_mb: 822
<!--NeedCopy-->

aaad.debug - Abrir canal para información de depuración de autenticación

Para obtener más información sobre cómo solucionar problemas de autenticación a través de ADC o ADC Gateway con el módulo aaad.debug, consulte este Artículo de soporte de aaad.debug.

También existe la posibilidad de obtener estadísticas de rendimiento y registros de eventos directamente para el ADC. Para obtener más información al respecto, consulte este Documento de soporte de ADC.

Solución de problemas para equipos de SRE y plataformas

Flujos de tráfico de Kubernetes

Norte/Sur:

• El tráfico norte/sur es el tráfico que fluye desde el usuario hacia el clúster, a través del ingreso.

Este/Oeste:

• El tráfico este/oeste es el tráfico que fluye alrededor del clúster de Kubernetes: de servicio a servicio o de servicio a almacén de datos.

Cómo Citrix ADC CPX equilibra la carga del flujo de tráfico este-oeste en un entorno de Kubernetes

Después de implementar el clúster de Kubernetes, debe integrar el clúster con ADM proporcionando los detalles del entorno de Kubernetes en ADM. ADM supervisa los cambios en los recursos de Kubernetes, como servicios, puntos finales y reglas de Ingress.

Cuando implementa una instancia de ADC CPX en el clúster de Kubernetes, esta se registra automáticamente con ADM. Como parte del proceso de registro, ADM aprende la dirección IP de la instancia CPX y el puerto en el que puede acceder a la instancia para configurarla mediante las API REST de NITRO.

La siguiente figura muestra cómo ADC CPX equilibra la carga del flujo de tráfico este-oeste en un clúster de Kubernetes.

En este ejemplo,

El Nodo 1 y el Nodo 2 de los clústeres de Kubernetes contienen instancias de un servicio de front-end y un servicio de back-end. Cuando las instancias de ADC CPX se implementan en el Nodo 1 y el Nodo 2, las instancias de ADC CPX se registran automáticamente con ADM. Debe integrar manualmente el clúster de Kubernetes con ADM configurando los detalles del clúster de Kubernetes en ADM.

Cuando un cliente solicita el servicio de front-end, el recurso de entrada equilibra la carga de la solicitud entre las instancias del servicio de front-end en los dos nodos. Cuando una instancia del servicio de front-end necesita información de los servicios de back-end en el clúster, dirige las solicitudes a la instancia de ADC CPX en su nodo. Esa instancia de ADC CPX equilibra la carga de las solicitudes entre los servicios de back-end en el clúster, proporcionando un flujo de tráfico este-oeste.

Gráfico de servicios de ADM para aplicaciones

La función de gráfico de servicios en Citrix ADM le permite supervisar todos los servicios en una representación gráfica. Esta función también proporciona un análisis detallado y métricas útiles. Puede ver gráficos de servicios para:

• Aplicaciones configuradas en todas las instancias de Citrix ADC
• Aplicaciones de Kubernetes
• Aplicaciones web de 3 niveles

Para empezar, consulte los detalles en el gráfico de servicios.

Ver contadores de aplicaciones de microservicios

El gráfico de servicios también muestra todas las aplicaciones de microservicios que pertenecen a los clústeres de Kubernetes. Pase el puntero del ratón sobre un servicio para ver los detalles de las métricas.

Puede ver:

• El nombre del servicio
• El protocolo utilizado por el servicio, como SSL, HTTP, TCP, SSL sobre HTTP
• Hits – El número total de aciertos recibidos por el servicio
• Tiempo de respuesta del servicio – El tiempo de respuesta promedio del servicio. (Tiempo de respuesta = RTT del cliente + último byte de la solicitud – primer byte de la solicitud)
• Errores – Los errores totales, como 4xx, 5xx, y así sucesivamente
• Volumen de datos – El volumen total de datos procesados por el servicio
• Espacio de nombres – El espacio de nombres del servicio
• Nombre del clúster – El nombre del clúster donde se aloja el servicio
• Errores del servidor SSL – El total de errores SSL del servicio

Estos contadores específicos y registros de transacciones se pueden extraer a través del Citrix Observability Exporter (COE) utilizando una variedad de puntos finales compatibles. Para obtener más información sobre COE, consulte las siguientes secciones.

Exportador de estadísticas de Citrix ADC

Este es un servidor simple que recopila estadísticas de Citrix ADC y las exporta a través de HTTP a Prometheus. Prometheus se puede agregar luego como una fuente de datos a Grafana para ver las estadísticas de Citrix ADC gráficamente.

Para supervisar las estadísticas y los contadores de las instancias de Citrix ADC, citrix-adc-metric-exporter se puede ejecutar como un contenedor o script. El exportador recopila estadísticas de Citrix ADC, como el total de visitas a un servidor virtual, la tasa de solicitudes HTTP, la tasa de cifrado-descifrado SSL, etc., de las instancias de Citrix ADC y las retiene hasta que el servidor Prometheus extrae las estadísticas y las almacena con una marca de tiempo. Luego, Grafana puede apuntar al servidor Prometheus para obtener las estadísticas, trazarlas, establecer alarmas, crear mapas de calor, generar tablas, etc., según sea necesario para analizar las estadísticas de Citrix ADC.

Los detalles sobre cómo configurar el exportador para que funcione en un entorno como el que se muestra en la figura se proporcionan en las siguientes secciones. También se explica una nota sobre qué entidades/métricas de Citrix ADC recopila el exportador por defecto y cómo modificarlas.

Para obtener más información sobre el exportador para Citrix ADC, consulte el GitHub de Metrics Exporter.

Rastreo distribuido del servicio ADM

En el gráfico de servicio, puede utilizar la vista de rastreo distribuido para:

• Analizar el rendimiento general del servicio.
• Visualizar el flujo de comunicación entre el servicio seleccionado y sus servicios interdependientes.
• Identifique qué servicio indica errores y solucione el servicio erróneo.
• Vea los detalles de la transacción entre el servicio seleccionado y cada servicio interdependiente.

Requisitos previos del rastreo distribuido de ADM

Para ver la información de rastreo del servicio, debe:

• Asegúrese de que una aplicación mantenga los siguientes encabezados de rastreo al enviar cualquier tráfico este-oeste:

• Actualice el archivo YAML de CPX con NS_DISTRIBUTED_TRACING y el valor como YES. Para empezar, consulte Rastreo distribuido.

Análisis de Citrix Observability Exporter (COE)

Citrix Observability Exporter es un contenedor que recopila métricas y transacciones de Citrix ADCs y las transforma a formatos adecuados (como JSON, AVRO) para los puntos finales compatibles. Puede exportar los datos recopilados por Citrix Observability Exporter al punto final deseado. Al analizar los datos exportados al punto final, puede obtener información valiosa a nivel de microservicios para las aplicaciones a las que Citrix ADCs sirve de proxy.

Para obtener más información sobre COE, consulte el GitHub de COE.

COE con Elasticsearch como punto final de transacción

Cuando se especifica Elasticsearch como punto final de transacción, Citrix Observability Exporter convierte los datos al formato JSON. En el servidor de Elasticsearch, Citrix Observability Exporter crea índices de Elasticsearch para cada ADC cada hora. Estos índices se basan en los datos, la hora, el UUID del ADC y el tipo de datos HTTP (http_event o http_error). Luego, Citrix Observability Exporter carga los datos en formato JSON bajo los índices de búsqueda de Elastic para cada ADC. Todas las transacciones regulares se colocan en el índice http_event y las anomalías se colocan en el índice http_error.

Compatibilidad con el rastreo distribuido con Zipkin

En una arquitectura de microservicios, una única solicitud de usuario final puede abarcar varios microservicios, lo que dificulta el seguimiento de una transacción y la corrección de las fuentes de errores. En tales casos, las formas tradicionales de supervisión del rendimiento no pueden identificar con precisión dónde se producen los fallos y cuál es la razón del bajo rendimiento. Necesita una forma de capturar puntos de datos específicos de cada microservicio que maneja una solicitud y analizarlos para obtener información significativa.

El rastreo distribuido aborda este desafío al proporcionar una forma de rastrear una transacción de extremo a extremo y comprender cómo se maneja en múltiples microservicios.

OpenTracing es una especificación y un conjunto estándar de API para diseñar e implementar el rastreo distribuido. Los rastreadores distribuidos le permiten visualizar el flujo de datos entre sus microservicios y ayudan a identificar los cuellos de botella en su arquitectura de microservicios.

Citrix Observability Exporter implementa el rastreo distribuido para Citrix ADC y actualmente es compatible con Zipkin como rastreador distribuido.

Actualmente, puede supervisar el rendimiento a nivel de aplicación mediante Citrix ADC. Al usar Citrix Observability Exporter con Citrix ADC, puede obtener datos de rastreo para los microservicios de cada aplicación a la que su Citrix ADC CPX, MPX o VPX sirve de proxy.

Para empezar, consulte el GitHub Observability Exporter.

Zipkin para la depuración de aplicaciones

Zipkin es un sistema de rastreo distribuido de código abierto basado en el documento de Dapper de Google. Dapper es el sistema de Google para su rastreo distribuido en producción. Google lo explica en su documento: «Creamos Dapper para proporcionar a los desarrolladores de Google más información sobre el comportamiento de los sistemas distribuidos complejos». Observar el sistema desde diferentes ángulos es fundamental al solucionar problemas, especialmente cuando un sistema es complejo y distribuido.

Los siguientes datos de rastreo de Zipkin identifican un total de 5 tramos y 5 servicios relacionados con la aplicación de ejemplo Watches. Los datos de rastreo muestran los datos específicos de los tramos en los 5 microservicios.

Para empezar, consulte el siguiente Zipkin.

Tramo de Zipkin de ejemplo que muestra la latencia de la aplicación para la solicitud de carga inicial de la página:

Kibana para la visualización de datos

Kibana es una interfaz de usuario abierta que le permite visualizar sus datos de Elasticsearch y navegar por Elastic Stack. Haga cualquier cosa, desde el seguimiento de la carga de consultas hasta la comprensión de cómo fluyen las solicitudes a través de sus aplicaciones.

Tanto si es analista como administrador, Kibana hace que sus datos sean procesables al proporcionar las tres funciones clave siguientes:

• Una plataforma de análisis y visualización de código abierto. Utilice Kibana para explorar sus datos de Elasticsearch y, a continuación, cree hermosas visualizaciones y paneles.
• Una interfaz de usuario para administrar Elastic Stack. Administre su configuración de seguridad, asigne roles de usuario, tome instantáneas, acumule sus datos y mucho más, todo desde la comodidad de una interfaz de usuario de Kibana.
• Un centro centralizado para las soluciones de Elastic. Desde el análisis de registros hasta el descubrimiento de documentos y SIEM, Kibana es el portal para acceder a estas y otras capacidades.

Kibana está diseñado para usar Elasticsearch como fuente de datos. Piense en Elasticsearch como el motor que almacena y procesa los datos, con Kibana encima.

Desde la página de inicio, Kibana ofrece estas opciones para agregar datos:

• Importe datos utilizando el visualizador de datos de archivo.
• Configure un flujo de datos a Elasticsearch utilizando nuestros tutoriales integrados. Si no existe un tutorial para sus datos, vaya a la Descripción general de Beats para obtener información sobre otros remitentes de datos de la familia Beats.
• Agregue un conjunto de datos de muestra y pruebe Kibana sin cargar datos usted mismo.
• Indexe sus datos en Elasticsearch con API REST o Bibliotecas de cliente.

Kibana utiliza un patrón de índice para indicarle qué índices de Elasticsearch explorar. Si carga un archivo, ejecuta un tutorial integrado o agrega datos de muestra, obtiene un patrón de índice de forma gratuita y puede comenzar a explorar. Si carga sus propios datos, puede crear un patrón de índice en Administración de pila.

Paso 1: Configurar el patrón de índice para Logstash

Paso 2: Seleccione el índice y genere tráfico para rellenar.

Paso 3: generar la aplicación a partir de los datos no estructurados de las fuentes de registro.

Paso 4: Kibana formatea la entrada de Logstash para crear informes y paneles.

• Rango de tiempo
• Vista tabular
• Recuentos de aciertos basados en la aplicación.
  • Hora IP, Agente, Machine.OS, Código de respuesta (200), URL
  • Filtrar por valores

Paso 5: Visualizar los datos en un informe de agregaciones.

• Agregación de resultados en un informe de gráficos (circular, de barras, etc.)