Usar Citrix ADM para solucionar problemas de redes nativas de Citrix Cloud

Información general

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

Descripción general de latencia y rendimiento de aplicaciones

Cifrado TLS

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

TLS frente a apretones de manos 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 apretones de manos SSL ahora se denominan apretones de manos TLS, aunque el nombre “SSL” sigue siendo de uso generalizado.

¿Cuándo se produce un desafío mutuo TLS?

Se produce un desafío mutuo TLS cada vez que un usuario navega a un sitio web a través de HTTPS y el explorador comienza a consultar primero el servidor de origen del sitio web. Un desafío mutuo TLS también ocurre cuando cualquier otra comunicación utiliza HTTPS, incluidas las llamadas a la API y las consultas DNS a través de HTTPS.

Los apretones de manos TLS se producen después de que se ha abierto una conexión TCP mediante un protocolo de enlace TCP.

¿Qué ocurre durante un desafío mutuo de TLS?

• Durante un protocolo de enlace de TLS, el cliente y el servidor juntos hacen lo siguiente:
  • Especifique qué versión de TLS (TLS 1.0, 1.2, 1.3, etc.) usan.
  • Decida qué conjuntos de cifrado (consulte la siguiente sección) que utilizan.
  • Autenticar la identidad del servidor a través de la clave pública del servidor y la firma digital de la entidad de certificación SSL.
  • Genere claves de sesión para usar cifrado simétrico después de que se complete el desafío mutuo.

¿Cuáles son los pasos de un desafío mutuo TLS?

• Los apretones de manos TLS son una serie de datagramas o mensajes intercambiados por un cliente y un servidor. Un desafío mutuo TLS implica varios pasos, ya que el cliente y el servidor intercambian la información necesaria para completar el desafío mutuo 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 se usa con mayor frecuencia. Va de la siguiente manera:

1. El mensaje de “saludo del cliente”: el cliente inicia el desafío mutuo enviando un mensaje de “hola” al servidor. El mensaje incluye qué versión de TLS admite el cliente, las suites de cifrado admitidas y una cadena de bytes aleatorios conocida como “cliente aleatorio”.
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 “servidor aleatorio”, otra cadena aleatoria de bytes que genera el servidor.
3. Autenticación: El cliente verifica el certificado SSL del servidor con la entidad de certificación que lo emitió. Esto confirma que el servidor es quien dice ser y que el cliente interactúa con el propietario real del dominio.
4. El secreto premaestro: El cliente envía una cadena aleatoria más de bytes, el “secreto premaestro”. El secreto premaestro se cifra con la clave pública y el servidor solo puede descifrarlo con la clave privada. (El cliente obtiene la clave pública del certificado SSL del servidor).
5. Clave privada utilizada: el servidor descifra el secreto premaestro.
6. Claves de sesión creadas: tanto el cliente como el servidor generan claves de sesión a partir del cliente aleatorio, el servidor aleatorio y el secreto premaestro. Deben llegar a los mismos resultados.
7. El cliente está listo: el cliente envía un mensaje “finalizado” que se cifra con una clave de sesión.
8. El servidor está listo: el servidor envía un mensaje “finalizado” cifrado con una clave de sesión.
9. Cifrado simétrico seguro: se completa el desafío mutuo y la comunicación continúa utilizando las claves de sesión.

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

1. Saludo del cliente: el cliente envía un mensaje de saludo al cliente con la versión del protocolo, el cliente aleatorio y una lista de conjuntos de cifrado.
2. Saludos del servidor: el servidor responde con su certificado SSL, su conjunto de cifrado seleccionado y el servidor de forma aleatoria. 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 cliente de forma aleatoria, el servidor de forma aleatoria y su parámetro DH*. Estos datos cifrados funcionan como la firma digital del servidor, lo que establece 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 premaestro: en lugar de que el cliente genere el secreto premaestro 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 premaestro 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 premaestro, 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 desafío mutuo de RSA
   • El servidor está listo
   • Encriptación simétrica segura

   *Parámetro DH: DH significa Diffie-Hellman. El algoritmo Diffie-Hellman utiliza cálculos exponenciales para llegar al mismo secreto de premaster. El servidor y el cliente proporcionan 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 apretones de manos efímeros de Diffie-Hellman y otros tipos de apretones de manos, y cómo logran el secreto hacia adelante, consulte esta documentación del protocolo TLS.

¿Qué es un conjunto de cifrado?

• Un conjunto de cifrado es un conjunto de algoritmos de cifrado para su uso en el establecimiento de una conexión de comunicaciones segura. (Un algoritmo de cifrado es un conjunto de operaciones matemáticas que se realizan en los datos para hacer que los datos parezcan aleatorios). Hay varios conjuntos de cifrado de uso generalizado, y una parte esencial del desafío mutuo TLS es acordar qué conjunto de cifrado se usa para ese desafío mutuo.

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

Panel SSL de Citrix Application Delivery Management

Citrix Application Delivery Management (ADM) ahora optimiza todos los aspectos de la administración de certificados por usted. A través de una sola consola, puede establecer directivas automatizadas para garantizar el emisor correcto, la fortaleza de la clave y los algoritmos correctos, al tiempo que mantiene una estrecha ficha sobre los certificados que no se utilizan o que caducan pronto. Para empezar a usar el panel SSL de Citrix ADM y sus funcionalidades, debe comprender qué es un certificado SSL y cómo puede usar Citrix ADM para rastrear sus certificados SSL.

Un certificado Secure Socket Layer (SSL), que forma parte de cualquier transacción SSL, es un formulario de datos digitales (X509) que identifica a una empresa (dominio) o a un individuo. El certificado tiene un componente de clave pública visible para cualquier cliente que quiera iniciar una transacción segura con el servidor. La clave privada correspondiente, que reside de forma segura en el dispositivo Citrix Application Delivery Controller (ADC), se utiliza para completar el cifrado y descifrado de clave asimétrica (o clave pública).

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

• De una entidad emisora de certificados (CA) autorizada
• Al generar un nuevo certificado SSL y una 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 de control SSL, puede ver gráficos que le ayudan a realizar un seguimiento de emisores de certificados, fortalezas 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 informarle cuando los certificados están a punto de caducar e incluir información sobre las instancias Citrix ADC que utilizan dichos 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 vincula al mismo certificado de CA tienen el mismo origen y el mismo emisor. Después de vincular los certificados a un certificado de CA, puede desvincularlos.

Para empezar, consulte la siguiente documentación del panel de 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 llama “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 para que una respuesta se envíe de vuelta al origen. La otra medición se denomina “tiempo hasta el primer byte” (o TTFB), que registra el tiempo que tarda 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 usa más comúnmente para medir la latencia porque se puede ejecutar desde un solo punto de la red y no requiere que el software de recopilación de datos se instale en el punto de destino (como lo hace TTFB).

Al supervisar el uso y el rendimiento del ancho de banda de la aplicación en tiempo real, el servicio ADM facilita la identificación de problemas y el tratamiento preventivo de posibles problemas antes de que se manifiesten y afecten a los usuarios de su red. Esta solución basada en flujo hace un seguimiento del uso por interfaz, aplicación y conversación, lo que le brinda información detallada sobre la actividad en su red.

Uso de Splunk Tools

El rendimiento de la infraestructura y las aplicaciones es interdependiente. Para ver el panorama completo, SignalFx proporciona una correlación perfecta entre la infraestructura de la nube y los microservicios que se ejecutan en la parte superior de la misma. Si su aplicación funciona mal debido a una pérdida de memoria, a un contenedor vecino ruidoso o a cualquier otro problema relacionado con la infraestructura, SignalFx se lo informa. Para completar el panorama, el acceso en contexto a los registros y eventos de Splunk permite una solución de problemas más profunda y un análisis de la causa raíz.

Para obtener más información sobre la APM de microservicios SignalFx y la solución de problemas con Splunk, consulte Splunk para obtener información sobre DevOps.

Soporte MongoDB

MongoDB almacena los datos en documentos flexibles similares a JSON. Los campos de significado pueden variar de un documento a otro y la estructura de los datos se puede cambiar con el tiempo.

El modelo de documento se asigna a los objetos del código de la 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 eficaces de acceder a sus datos y analizarlos.

MongoDB es una base de datos distribuida en su núcleo, por lo que la alta disponibilidad, el escalado horizontal y la distribución geográfica están integradas 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:

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

Con estas capacidades, puede crear una plataforma de datos operativos 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 entrada 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 estándar de Kubernetes Ingress asumen que todo el tráfico se basa en HTTP y no atiende a 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 o LDAP, no se pueden exponer mediante Kubernetes Ingress estándar.

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

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

• ingress.citrix.com/insecure-service-type: La anotación habilita 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, se configura el puerto 80.

Para obtener más información, consulte Cómo equilibrar la carga del tráfico de ingreso 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. La ECV (validación de contenido extendida) supervisa la ayuda para verificar si la aplicación devuelve el contenido esperado o no.

Además, el rendimiento de la aplicación se puede mejorar mediante el uso de métodos de persistencia, como IP de origen. Puede usar estas funciones de Citrix ADC a través de anotaciones inteligentes en Kubernetes. A continuación se muestra un ejemplo de ello:

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)

Citrix ADM Service ofrece las siguientes ventajas:

• Á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, la actualización y el uso de las funciones proporcionadas. La frecuencia de las actualizaciones, combinada con la función de actualización automatizada, mejora rápidamente la implementación de Citrix ADC.
• Tiempo de obtención de valor más rápido: Logro de objetivos empresariales más rápido. A diferencia de la implementación local tradicional, puede usar su servicio Citrix ADM con unos pocos clics. No solo ahorra tiempo de instalación y configuración, sino que también evita perder tiempo y recursos en posibles errores.
• Administración de varios sitios: Un solo panel de vidrio para instancias en centros de datos de varios sitios. Con Citrix ADM Service, puede administrar y supervisar los ADC de Citrix que se encuentran en varios tipos de implementaciones. Tiene una administración integral para los ADC de Citrix implementados en las instalaciones y en la nube.
• Eficiencia operativa: Forma optimizada y automatizada de lograr una mayor productividad operativa. Con Citrix ADM Service, sus costes operativos se reducen al ahorrar tiempo, dinero y recursos en el mantenimiento y actualización de las implementaciones de hardware tradicionales.

Service Graph para aplicaciones de Kubernetes

Con el gráfico de servicio para la función de aplicación nativa de la nube en Citrix ADM, puede:

• Garantice el performance general de las aplicaciones end-to-end
• Identifique los cuellos de botella creados por la interdependencia de los diferentes componentes de sus aplicaciones
• Reúna 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 de 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 realizar las acciones necesarias para solucionar problemas 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, consulta Configurar el gráfico de servicios.

Gráfico de servicios para aplicaciones web de 3 niveles

Con la función de gráfico de servicio desde el panel de aplicación, puede ver:

• Detalles sobre cómo se configura la aplicación (con el servidor virtual de conmutación de contenido y el servidor virtual de equilibrio de carga)
  • Para las 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 la que 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 asociadas (solo para aplicaciones GSLB)
• Detalles de métricas para clientes, servicios y servidores virtuales
• Si los errores son del cliente o del servicio
• El estado del servicio, como Crítico, Revisión y Bueno. Citrix ADM muestra el estado del servicio según el tiempo de respuesta del servicio y el recuento de errores.
  • Crítico (rojo): Indica cuando el tiempo medio de respuesta del servicio es > 200 ms Y cuenta de errores > 0
  • Revisión (naranja): Indica cuando el tiempo promedio de respuesta del servicio > 200 ms O cuenta de errores > 0
  • Buena (verde): Indica que no hay errores y 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 según 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 número de errores > 0
  • Revisión (naranja): Indica cuando la latencia media de la red del cliente > 200 ms O cuenta de errores > 0
  • Buena (verde): Indica que no hay errores y 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 es < 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:

• En el gráfico de servicio solo se muestran los servidores virtuales de equilibrio de carga, conmutación de contenido y GSLB.
• Si ningún servidor virtual está enlazado a una aplicación personalizada, los detalles no se ven en el gráfico de servicio de la aplicación.
• Puede ver métricas para clientes y servicios en el gráfico de servicios solo si se producen transacciones activas entre servidores virtuales y aplicaciones 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 servicio en función de 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 servicio.

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

Para empezar, consulte la documentación de Service Graph.

Solución de problemas para Citrix ADC Teams

Analicemos algunos de los atributos más comunes para solucionar problemas en 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.

Citrix ADC tiene una interfaz de línea de comandos (CLI) que muestra los comandos en tiempo real y es útil para determinar las configuraciones en tiempo de ejecución, la estática y la configuración de directivas. Esto se facilita mediante el comando “SHOW”.

SHOW: realizar operaciones 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 de SSL

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

Citrix ADC tiene un comando para enumerar las estadísticas de todos los objetos en función de un intervalo de contador de siete (7) segundos. Esto se facilita mediante el comando “STAT”.

Telemetría L3-L7 altamente granular de Citrix ADC

• Nivel del sistema: uso de CPU y memoria del ADC.
• Protocolo HTTP: #Requests /Responses, división GET/POST, errores HTTP para N-S y E-W (solo para service mesh lite, sidecar pronto).
• SSL: #Sessions y #Handshakes para tráfico N-S y E-W solo para service mesh lite.
• Protocolo IP: #Packets recibidos/enviados, #Bytes recibidos/enviados, paquetes #Truncated y búsqueda de direcciones #IP.
• Citrix ADC AAA: Sesiones #Active
• Interfaz: paquetes de multidifusión #Total, bytes transferidos #Total y paquetes #Jumbo recibidos/enviados.
• Servidor virtual de equilibrio de carga y servidor virtual de conmutación de contenido: #Packets, #Hits y #Bytes recibidos/enviados.

STAT: realice operaciones CLI de ADC:

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

Citrix ADC tiene una estructura de archivo de registros que permite buscar estadísticas y contadores al solucionar errores específicos mediante el comando “NSCONMSG”.

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

    Cd/var/nslog

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

Nstcpdump

Se puede utilizar nstcpdump para la solució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 ADC. La salida del volcado se puede ver directamente en la pantalla de la CLI.

CTRL + C: Presione 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 especificada.

! [Ejemplo nstcpdump] (/en-us/advanced-concepts/media/nstcpdump.png)

NSTRACE: Archivo de seguimiento de paquetes

NSTRACE es una herramienta de depuración de paquetes de bajo nivel para solucionar problemas de redes. Le permite almacenar archivos de captura que puede analizar más a fondo con las herramientas del analizador. Dos herramientas comunes son Network Analyzer y Wireshark.

!La salida de nstrace

Una vez que se crea el archivo de captura NSTRACE 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 proceso para la 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 los equipos de SRE

Flujos de tráfico de Kubernetes

Norte/sur:

• El tráfico norte/sur es el tráfico que fluye desde el usuario al clúster, a través de la entrada.

Este/oeste:

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

Cómo equilibra la carga de Citrix ADC CPX el flujo de tráfico de este a 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 los servicios, los puntos finales y las reglas de entrada.

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

En esta ilustración se muestra cómo la carga de ADC CPX equilibra el flujo de tráfico de este a 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 front-end y un servicio 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 en 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 front-end, la carga de recursos de entrada equilibra la solicitud entre las instancias del servicio 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. La carga de la instancia CPX de ADC equilibra las solicitudes entre los servicios de back-end del clúster, lo que proporciona un flujo de tráfico de este a oeste.

Gráfico de servicio ADM para aplicaciones

La función de gráfico de servicio de Citrix ADM permite supervisar todos los servicios de 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 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 servicio también muestra todas las aplicaciones de microservicios que pertenecen a los clústeres de Kubernetes. Sitúe el puntero del mouse sobre un servicio para ver los detalles de las métricas.

Podrá ver lo siguiente:

• El nombre del servicio
• El protocolo utilizado por el servicio como SSL, HTTP, TCP, SSL sobre HTTP
• Hits: El número total de hits recibidos por el servicio
• Tiempo de respuesta del servicio: El tiempo medio de respuesta tomado del servicio. (Tiempo de respuesta = cliente RTT + petición último byte: Solicitud primer byte)
• Errores: El total de errores como 4xx, 5xx, etc.
• Volumen de datos: Volumen total de datos procesados por el servicio
• Espacio de nombres: El espacio de nombres del servicio
• Nombre del clúster: Nombre del clúster en el que está alojado el servicio
• Errores del servidor SSL: El total de errores SSL del servicio

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

Exportador de estadísticas de Citrix ADC

Se trata de un servidor sencillo que extrae las estadísticas de Citrix ADC y las exporta a través de HTTP a Prometheus. Luego, Prometheus se puede agregar como origen de datos a Grafana para ver las estadísticas de Citrix ADC de forma gráfica.

Para supervisar las estadísticas y los contadores de las instancias de Citrix ADC, citrix-adc-metric-exporter se puede ejecutar como 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 y 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. A continuación, se puede apuntar a Grafana 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.

En estas secciones se proporcionan detalles sobre la configuración del exportador para que trabaje en un entorno como se indica en la ilustración. También se explica una nota sobre qué entidades/métricas de Citrix ADC extrae el exportador de forma predeterminada y cómo modificarlas.

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

Seguimiento distribuido del servicio ADM

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

• Analice el rendimiento general del servicio.
• Visualice el flujo de comunicación entre el servicio seleccionado y sus servicios interdependientes.
• Identificar qué servicio indica errores y solucionar el servicio erróneo
• Permite ver los detalles de las transacciones entre el servicio seleccionado y cada servicio interdependiente.

Requisitos previos de ADM Distributed Tracing

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

• Asegúrese de que una aplicación mantenga los siguientes encabezados de seguimiento, mientras envía cualquier tráfico este-oeste:

• Actualice el archivo YAML CPX con NS_DISTRIBUTED_TRACING y el valor 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 ADC 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 proxy de Citrix ADC.

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

COE con Elasticsearch como punto final de la transacción

Cuando se especifica Elasticsearch como el punto de enlace de la transacción, Citrix Observability Exporter convierte los datos a 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). A continuación, Citrix Observability Exporter carga los datos en formato JSON en índices de búsqueda elástica para cada ADC. Todas las transacciones regulares se colocan en el índice http_event y cualquier anomalía se coloca en el índice http_error.

Función de rastreo distribuido con Zipkin

En una arquitectura de microservicios, una solicitud de un solo usuario final puede abarcar varios microservicios, lo que dificulta el seguimiento de una transacción y la corrección de los orígenes de los errores. En tales casos, las formas tradicionales de supervisión del rendimiento no pueden identificar con precisión dónde ocurren las fallas y cuál es la razón detrás de un rendimiento deficiente. Necesita una forma de capturar puntos de datos específicos para cada microservicio que gestiona una solicitud y analizarlos para obtener información valiosa.

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 varios microservicios.

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

Citrix Observability Exporter implementa el seguimiento distribuido para Citrix ADC y actualmente admite Zipkin como trazador distribuido.

Actualmente, puede supervisar el rendimiento a nivel de aplicación mediante Citrix ADC. Con Citrix Observability Exporter con Citrix ADC, puede obtener datos de seguimiento para microservicios de cada aplicación proxy por su Citrix ADC CPX, MPX o VPX.

Para empezar, consulta el Exportador de observabilidad de GitHub.

Zipkin para 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 sistema de rastreo distribuido en producción. Google explica esto en su artículo: “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 a la hora de solucionar problemas, especialmente cuando un sistema es complejo y está distribuido.

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

Para empezar, consulta el siguiente Zipkin.

Ejemplo de intervalo de Zipkin que muestra la latencia de la aplicación para la solicitud de carga

Kibana para ver datos

Kibana es una interfaz de usuario abierta que le permite visualizar sus datos de Elasticsearch y navegar por Elastic Stack. Puede hacer lo que quiera, desde hacer un seguimiento de la carga de las consultas hasta comprender la forma en que las solicitudes fluyen

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

• Una plataforma de análisis y visualización de código abierto. Use Kibana para explorar sus datos de Elasticsearch y, a continuación, crear visualizaciones y paneles atractivos.
• Una interfaz de usuario para administrar Elastic Stack. Administre su configuración de seguridad, asigne funciones 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 análisis de registros hasta descubrimiento de documentos y SIEM, Kibana es el portal para acceder a estas y otras capacidades.

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

En la página principal, Kibana proporciona estas opciones para agregar datos:

• Importe datos mediante el visualizador de datos de archivo.
• Configura un flujo de datos a Elasticsearch con nuestros tutoriales integrados. Si no existe un tutorial para sus datos, vaya a 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 lleve a Kibana a probarlo sin cargar los datos usted mismo.
• Indexe sus datos en Elasticsearch con las API REST o lasbibliotecas cliente.

Kibana usa un patrón de índice para indicarle qué índices de Elasticsearch explorar. Si carga un archivo, ejecuta un tutorial incorporado o agrega datos de muestra, obtiene un patrón de índice de forma gratuita y es bueno comenzar a explorar. Si carga sus propios datos, puede crear un patrón de índice en Stack Management.

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 los orígenes de los registros.

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

• Intervalo de tiempo
• Vista tabular
• Los recuentos de resultados se basan en la aplicación.
  • Hora IP, agente, Machine.OS, código de respuesta (200), URL
  • Filtrar por valores

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

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