Documentación de productos
ADC
14.1 - Current Release 13.1 13.0 12.1
Ver PDF

Utilice NetScaler Console para solucionar problemas de redes nativas en la nube de NetScaler

April 15, 2024
Contribución de: 
C

Información general

Este documento proporciona información sobre cómo puede usar NetScaler Console para entregar y supervisar las aplicaciones de microservicios de Kubernetes. También se sumerge en el uso de la CLI, los gráficos de servicio y el seguimiento para permitir que los equipos de la plataforma y de SRE solucionen los problemas.

Descripción general de rendimiento y latencia 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.

Apretones de manos TLS vs SSL

SSL (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 NetScaler Application Delivery Management

NetScaler Application Delivery Management (ADM) ahora optimiza todos los aspectos de la administración de certificados para 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 NetScaler Console y sus funcionalidades, debe entender qué es un certificado SSL y cómo puede usar NetScaler Console 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 autoridad de certificación autorizada (CA)
  • Al generar un nuevo certificado SSL y una clave en el dispositivo NetScaler

NetScaler Console proporciona una vista centralizada de los certificados SSL instalados en todas las instancias de NetScaler administradas. En el panel de control de SSL, puede ver gráficos que le ayudan a rastrear los emisores de certificados, los puntos fuertes clave, los algoritmos de firma, los 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 NetScaler que utilizan dichos certificados.

Puede vincular los certificados de una instancia de NetScaler a un certificado de CA. Sin embargo, asegúrese de que los certificados que enlace al mismo certificado de CA tengan el mismo origen y el mismo emisor. Después de vincular los certificados a un certificado de CA, puede desvincularlos.

Panel de control SSL

Para empezar, consulte la 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 herramientas de Splunk

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.

Splunk

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.

Compatibilidad con 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 quiere.
  • 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 NetScaler para obtener más información.

La segunda opción es anotar el objeto de entrada. El Ingress Controller NetScaler le permite equilibrar la carga del tráfico de ingreso 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 NetScaler.
  • 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 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 NetScaler. 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 la IP de origen. Puede usar estas funciones de NetScaler 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 de administración de entrega de aplicaciones (ADM) de NetScaler

El servicio de consola NetScaler ofrece las siguientes ventajas:

  • Ágil: Fácil de operar, actualizar y consumir. El modelo de servicio de NetScaler Console Service está disponible en la nube, lo que facilita el funcionamiento, 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 NetScaler.
  • 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 el servicio de consola de NetScaler 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 el servicio de consola de NetScaler, puede administrar y supervisar los NetScaler que se encuentran en varios tipos de implementaciones. Dispone de una gestión integral para los NetScalers implementados en las instalaciones y en la nube.
  • Eficiencia operativa: Forma optimizada y automatizada de lograr una mayor productividad operativa. Con el servicio de consola NetScaler, 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 servicio para aplicaciones Kubernetes

Con el gráfico de servicio para la función de aplicación nativa de la nube de NetScaler Console, 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
  • Supervise los servicios dentro del clúster de Kubernetes
  • Supervisa qué servicio tiene problemas
  • Compruebe los factores que contribuyen a los problemas de rendimiento
  • Ver la visibilidad detallada de las transacciones HTTP del servicio
  • Analizar las métricas HTTP, TCP y SSL

Al visualizar estas métricas en NetScaler Console, puede analizar la causa raíz de los problemas y tomar las medidas de solución de problemas necesarias con mayor rapidez. 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 servicio 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 de cliente y las métricas NetScaler 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, Revisadoy Bueno. NetScaler Console muestra el estado del servicio según el tiempo de respuesta del servicio y el recuento de errores.
    • Crítico (rojo): Indica cuándo el tiempo promedio de respuesta del servicio es superior a 200 ms Y el recuento de errores es > 0
    • Revisión (naranja): Indica si el tiempo promedio de respuesta del servicio es > 200 ms O el recuento de errores es > 0
    • Bueno (verde): Indica que no hay errores y que el tiempo medio de respuesta del servicio es inferior a 200 ms
  • El estado del cliente, como Crítico, Revisadoy Bueno. NetScaler Console muestra el estado del cliente según la latencia de la red del cliente y el recuento de errores.
    • Crítico (rojo): indica si la latencia promedio de la red del cliente es > 200 ms Y el recuento de errores es > 0
    • Revisión (naranja): Indica si la latencia promedio de la red del cliente es > 200 ms O el recuento de errores es > 0
    • Bueno (verde): Indica que no hay ningún error y que la latencia media de la red del cliente es < 200 ms.
  • El estado del servidor virtual, como Crítico, Revisadoy Correcto. NetScaler Console muestra el estado del servidor virtual en función de la puntuación de la aplicación.
    • Crítico (rojo): Indica si la puntuación de la aplicación es inferior < 40
    • Reseña (naranja): Indica si 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.

Diagrama de flujo de servicios

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

Solución de problemas para los equipos NetScaler

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

NetScaler 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-->

Mostrar estadísticas de SSL

NetScaler 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 NetScaler

  • 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.
  • NetScaler 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-->

Iniciar SSL

NetScaler 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-->

Flujo de comandos

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`

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`

La salida de seguimiento de paquetes

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 del 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 información de depuración de autenticación

aaad.debug

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 el artículo de asistencia 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 el documento de asistencia 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 la carga de NetScaler CPX equilibra 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.

Al implementar una instancia CPX de NetScaler 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.

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

Equilibrio de carga 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 CPX de NetScaler se implementan en los nodos 1 y 2, las instancias CPX de NetScaler 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 fondo del clúster, dirige las solicitudes a la instancia CPX de NetScaler de su nodo. La carga de esa instancia CPX de NetScaler equilibra las solicitudes entre los servicios de fondo 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 servicios de NetScaler Console 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:

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. Sin embargo, el puntero del mouse en 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
  • Visitas: Número total de visitas recibidas por el servicio
  • Tiempo de respuesta del servicio: El tiempo de respuesta promedio tomado del servicio. (Tiempo de respuesta = RTT del cliente + último byte de la solicitud — primer byte de la solicitud)
  • Errores: El total de errores, como 4xx, 5xx, etc.
  • 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: Nombre del clúster en el que está alojado el servicio
  • Errores del servidor SSL: El total de errores SSL del servicio

Aplicación lenta

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

Exportador de estadísticas de NetScaler

Se trata de un servidor sencillo que extrae las estadísticas de NetScaler 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 NetScaler de forma gráfica.

Para supervisar las estadísticas y los contadores de las instancias de NetScaler, citrix-adc-metric-exporter se puede ejecutar como contenedor o script. El exportador recopila estadísticas de NetScaler, 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 NetScaler 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 NetScaler.

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 NetScaler extrae el exportador de forma predeterminada y cómo modificarlas.

Para obtener más información sobre Exporter for NetScaler, 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:

  • 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 para el seguimiento distribuido de ADM

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:

Encabezados de

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

Análisis de NetScaler Observability Exporter (COE)

NetScaler Observability Exporter es un contenedor que recopila métricas y transacciones de NetScaler y las transforma a formatos adecuados (como JSON o AVRO) para los puntos de conexión compatibles. Puede exportar los datos recopilados por el exportador de observabilidad de NetScaler al punto final deseado. Al analizar los datos exportados al endpoint, puede obtener información valiosa a nivel de microservicios para las aplicaciones proxies de NetScalers.

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

COE con Elasticsearch como punto final de la transacción

COE

Cuando se especifica Elasticsearch como el punto de enlace de la transacción, NetScaler Observability Exporter convierte los datos a formato JSON. En el servidor de Elasticsearch, NetScaler 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, el exportador de observabilidad de NetScaler carga los datos en formato JSON en los índices de búsqueda de Elastic 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.

COE JSON

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.

NetScaler Observability Exporter implementa el seguimiento distribuido para NetScaler y actualmente admite Zipkin como rastreador distribuido.

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

Para empezar, consulta el Exportador de observabilidad de GitHub.

COE ADC

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, consulte Zipkin.

Rastros de zipkin

Amazon span

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

Servicio Zipkin de muestra

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:

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.)

Panel de Kibana

http de Kibana

Utilice NetScaler Console para solucionar problemas de redes nativas en la nube de NetScaler
April 15, 2024
Contribución de: 
C
April 15, 2024
Contribución de: 
C

En este artículo

Comentarios sobre el sitio | Your privacy choices footer linkSus opciones de privacidad | Condiciones legales y de privacidad | Preferencias de cookies | Parámetros de consentimiento | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.