Guía del usuario del software API de transmisión Juniper NETWORKS

Software API de transmisión Juniper NETWORKS

Información del producto

Presupuesto

• Nombre del producto: Garantía activa Paragon
• Versión: 4.1
• Fecha de publicación: 2023-03-15

Introducción:
Esta guía proporciona instrucciones sobre cómo extraer datos de Paragon Active Assurance utilizando la API de transmisión del producto. El cliente de transmisión y la API están incluidos en la instalación de Paragon Active Assurance, pero se requiere cierta configuración antes de usar la API. El proceso de configuración se trata en la sección "Configuración de la API de transmisión".

Configuración de la API de transmisión:
Los siguientes pasos describen el proceso para configurar la API de transmisión:

Encimaview
Kafka es una plataforma de transmisión de eventos diseñada para la captura y almacenamiento de datos en tiempo real de diversas fuentes. Permite la gestión de flujos de eventos de forma distribuida, escalable, tolerante a fallos y segura. Esta guía se centra en la configuración de Kafka para utilizar la función Streaming API en Paragon Active Assurance Control Center.

Terminología
La Streaming API permite a los clientes externos recuperar información de métricas de Kafka. Las métricas recopiladas por los agentes de prueba durante una tarea de prueba o monitoreo se envían al servicio Stream. Después del procesamiento, el servicio Stream publica estas métricas en Kafka junto con metadatos adicionales.

Habilitación de la API de transmisión
Para habilitar la API de transmisión, siga estos pasos:

1. Ejecute los siguientes comandos en el servidor del Centro de control usando sudo:

KAFKA_METRICS_ENABLED = True los servicios sudo ncc habilitan las métricas de timescaledb los servicios sudo ncc inician las métricas timescaledb los servicios sudo ncc se reinician

Verificación de que la API de transmisión funciona en el Centro de control:
Para verificar que está recibiendo métricas sobre los temas correctos de Kafka:

1. Instale la utilidad kafkacat con los siguientes comandos:
   sudo apt-get actualización
   sudo apt-get instalar kafkacat

2. Reemplace "micuenta" con el nombre corto de su cuenta en el
   Centro de control URL:
   exportar METRICS_TOPIC=paa.public.accounts.myaccount.metrics
   exportar METADATA_TOPIC=paa.public.accounts.myaccount.metadata

3. Ejecute el siguiente comando para view métrica:
   kafkacat -b ${KAFKA_FQDN}:9092 -t ${METRICS_TOPIC} -C -e
   Nota: El comando anterior mostrará las métricas.
4. A view metadatos, ejecute el siguiente comando:
   kafkacat -b ${KAFKA_FQDN}:9092 -t ${METADATA_TOPIC} -C -e

Nota: El comando anterior mostrará metadatos, pero no se actualizará con tanta frecuencia.

ex clienteampLos
Para cliente examparchivos y más información, consulte la página 14 del manual del usuario.

Preguntas frecuentes (FAQ)

• P: ¿Qué es Paragon Active Assurance?
  R: Paragon Active Assurance es un producto que proporciona capacidades de monitoreo y prueba.
• P: ¿Qué es la API de transmisión?
  R: La Streaming API es una función de Paragon Active Assurance que permite a los clientes externos recuperar información de métricas de Kafka.
• P: ¿Cómo habilito la API de transmisión?
  R: Para habilitar la API de transmisión, siga los pasos descritos en la sección "Habilitación de la API de transmisión" del manual del usuario.
• P: ¿Cómo puedo verificar que la API de Streaming esté funcionando?
  R: Consulte la sección "Verificación de que la API de transmisión funciona en el Centro de control" para obtener instrucciones sobre cómo verificar la funcionalidad de la API de transmisión.

Introducción

Esta guía describe cómo extraer datos de Paragon Active Assurance a través de la API de transmisión del producto.
La API y el cliente de transmisión se incluyen en la instalación de Paragon Active Assurance. Sin embargo, se necesita un poco de configuración antes de poder utilizar la API. Esto se trata en el capítulo “Configuración de la API de transmisión” en la página 1.

Encimaview
Este capítulo describe cómo configurar Streaming API para permitir la suscripción a mensajes de métricas a través de Kafka.
pr
A continuación recorreremos:

• Cómo habilitar la API de transmisión
• Cómo configurar Kafka para escuchar clientes externos
• Cómo configurar Kafka para usar ACL y configurar el cifrado SSL para dichos clientes

¿Qué es Kafka?
Kafka es una plataforma de transmisión de eventos que permite la captura en tiempo real de datos enviados desde varias fuentes de eventos (sensores, bases de datos, dispositivos móviles) en forma de flujos de eventos, así como el almacenamiento duradero de estos flujos de eventos para su posterior recuperación y manipulación.
Con Kafka es posible administrar la transmisión de eventos de extremo a extremo de manera distribuida, altamente escalable, elástica, tolerante a fallas y segura.

NOTA: Kafka se puede configurar de muchas maneras diferentes y fue diseñado para sistemas redundantes y escalables. Este documento se centra únicamente en cómo configurarlo para utilizar la función Streaming API que se encuentra en Paragon Active Assurance Control Center. Para configuraciones más avanzadas, consultamos la documentación oficial de Kafka: kafka.apache.org/26/documentation.html.

Terminología

• Kafka: plataforma de transmisión de eventos.
• Tema Kafka: Colección de eventos.
• Suscriptor/consumidor de Kafka: componente responsable de la recuperación de eventos almacenados en un tema de Kafka.
• Broker de Kafka: servidor de capa de almacenamiento de un clúster de Kafka.
• SSL/TLS: SSL es un protocolo seguro desarrollado para enviar información de forma segura a través de Internet. TLS es el sucesor de SSL, introducido en 1999.
• SASL: marco que proporciona mecanismos para la autenticación de usuarios, la verificación de la integridad de los datos y el cifrado.
• Suscriptor de Streaming API: Componente responsable de la recuperación de eventos almacenados en temas definidos en Paragon Active Assurance y destinados al acceso externo.
• Autoridad de certificación: una entidad de confianza que emite y revoca certificados de clave pública.
• Certificado raíz de la autoridad de certificación: certificado de clave pública que identifica a una autoridad de certificación.

Cómo funciona la API de transmisión
Como se mencionó anteriormente, la API de transmisión permite a los clientes externos recuperar información sobre las métricas de Kafka.

Todas las métricas recopiladas por los agentes de prueba durante una tarea de prueba o monitoreo se envían al servicio Stream. Después de una fase de procesamiento, el servicio Stream publica esas métricas en Kafka junto con metadatos adicionales.

Temas de Kafka
Kafka tiene el concepto de temas en los que se publican todos los datos. En Paragon Active Assurance hay muchos temas de Kafka disponibles; sin embargo, solo un subconjunto de estos está destinado al acceso externo.
Cada cuenta de Paragon Active Assurance en Control Center tiene dos temas dedicados. A continuación, CUENTA es el nombre abreviado de la cuenta:

• paa.cuentas.públicas.{CUENTA}.métricas
  • Todos los mensajes de métricas para la cuenta dada se publican en este tema
  • Grandes cantidades de datos
  • Alta frecuencia de actualización
• paa.cuentas.públicas.{CUENTA}.metadatos
  • Contiene metadatos relacionados con los datos de métricas, por ej.amparchivar la prueba, el monitor o el agente de prueba asociado con las métricas
  • Pequeñas cantidades de datos
  • Baja frecuencia de actualización

Habilitación de la API de transmisión

NOTA: Estas instrucciones deben ejecutarse en el servidor del Centro de control mediante sudo.

Dado que la API de transmisión agrega algunos gastos generales al Centro de control, no está habilitada de manera predeterminada. Para habilitar la API, primero debemos habilitar la publicación de métricas en Kafka en la configuración principal file:

• /etc/netrounds/netrounds.conf

KAFKA_METRICS_ENABLED = Verdadero

ADVERTENCIA: Habilitar esta función podría afectar el rendimiento del Centro de control. Asegúrese de haber dimensionado su instancia en consecuencia.

A continuación, para habilitar el reenvío de estas métricas a los temas de Kafka correctos:

• /etc/netrounds/metrics.yaml

transmisión-api: verdadero

Para habilitar e iniciar los servicios de Streaming API, ejecute:

• Los servicios sudo ncc habilitan métricas timescaledb
• Los servicios sudo ncc inician las métricas de timescaledb

Finalmente, reinicie los servicios:

• reinicio de servicios sudo ncc

Verificación de que la API de transmisión funciona en Control Center

NOTA: Estas instrucciones deben ejecutarse en el servidor del Centro de control.

Ahora puede verificar que está recibiendo métricas sobre los temas de Kafka correctos. Para hacerlo, instale la utilidad kafkacat:

• sudo apt-get actualización
• sudo apt-get instalar kafkacat

Si tiene una prueba o un monitor ejecutándose en Control Center, debería poder usar kafkacat para recibir métricas y metadatos sobre estos temas.
Reemplace myaccount con el nombre corto de su cuenta (esto es lo que ve en su Centro de control URL):

• exportar METRICS_TOPIC=paa.public.accounts.myaccount.metrics
• exportar METADATA_TOPIC=paa.public.accounts.myaccount.metadata

Ahora debería ver las métricas ejecutando este comando:

• kafkacat -b ${KAFKA_FQDN}:9092 -t ${METRICS_TOPIC} -C -e

A view metadatos, ejecute el siguiente comando (tenga en cuenta que esto no se actualizará con tanta frecuencia):

• kafkacat -b ${KAFKA_FQDN}:9092 -t ${METADATA_TOPIC} -C -e

NOTA:
kafkacat”Cliente examples ”en la página 14

Esto verifica que tenemos una API de transmisión en funcionamiento desde Control Center. Sin embargo, lo más probable es que esté interesado en acceder a los datos desde un cliente externo. La siguiente sección describe cómo abrir Kafka para acceso externo.

Apertura de Kafka para hosts externos

NOTA: Estas instrucciones deben ejecutarse en el servidor del Centro de control.

De forma predeterminada, Kafka que se ejecuta en el Centro de control está configurado para escuchar solo en el host local para uso interno. Es posible abrir Kafka para clientes externos modificando la configuración de Kafka.

Conexión a Kafka: advertencias

PRECAUCIÓN: Lea esto detenidamente, ya que es fácil tener problemas de conexión con Kafka si no ha entendido estos conceptos.

En la configuración del Centro de control que se describe en este documento, solo hay un agente de Kafka.
Sin embargo, tenga en cuenta que un agente de Kafka está diseñado para ejecutarse como parte de un clúster de Kafka que puede constar de muchos agentes de Kafka.
Al conectarse a un agente de Kafka, el cliente de Kafka establece una conexión inicial. A través de esta conexión, el corredor de Kafka a su vez devolverá una lista de "oyentes anunciados", que es una lista de uno o más corredores de Kafka.
Al recibir esta lista, el cliente de Kafka se desconectará y luego se volverá a conectar a uno de estos oyentes anunciados. Los oyentes anunciados deben contener nombres de host o direcciones IP a las que pueda acceder el cliente de Kafka, o el cliente no podrá conectarse.
Si se utiliza el cifrado SSL, que implica un certificado SSL que está vinculado a un nombre de host en particular, es aún más importante que el cliente de Kafka reciba la dirección correcta para conectarse, ya que, de lo contrario, la conexión puede ser rechazada.
Lea más sobre los oyentes de Kafka aquí: www.confluent.io/blog/kafka-listeners-explained

Cifrado SSL/TLS
Para asegurarnos de que solo los clientes de confianza puedan acceder a Kafka y a la API de Streaming, debemos configurar lo siguiente:

• Autenticación: Los clientes deben proporcionar nombre de usuario y contraseña a través de una conexión segura SSL/TLS entre el cliente y Kafka.
• Autorización: Los clientes autenticados pueden realizar tareas reguladas por ACL.

Aquí hay un resumenview:

*) Autenticación de nombre de usuario/contraseña realizada en un canal cifrado SSL

Para comprender completamente cómo funciona el cifrado SSL/TLS para Kafka, consulte la documentación oficial: docs.confluent.io/platform/current/kafka/encryption.html

Certificado SSL/TLS superadoview

NOTA: En esta subsección utilizaremos la siguiente terminología:

Certificado: un certificado SSL firmado por una autoridad certificadora (CA). Cada corredor de Kafka tiene uno.
Almacén de claves: El almacén de claves file que almacena el certificado. El almacén de claves file contiene la clave privada del certificado; por lo tanto, debe mantenerse de forma segura.
almacén de confianza: A file que contiene los certificados de CA de confianza.

Para configurar la autenticación entre un cliente externo y Kafka que se ejecuta en Control Center, ambos lados deben tener un almacén de claves definido con un certificado relacionado firmado por una autoridad de certificación (CA) junto con el certificado raíz de CA.
Además de esto, el cliente también debe tener un almacén de confianza con el certificado raíz de CA.
El certificado raíz de CA es común para el agente de Kafka y el cliente de Kafka.

Creación de los certificados necesarios
Esto se cubre en el “Apéndice” en la página 17.

Configuración de Kafka Broker SSL/TLS en Control Center

NOTA: Estas instrucciones deben ejecutarse en el servidor del Centro de control.

NOTA: Antes de continuar, debe crear el almacén de claves que contiene el certificado SSL siguiendo las instrucciones del “Apéndice” en la página 17. Las rutas que se mencionan a continuación provienen de estas instrucciones.
El almacén de claves SSL es un file almacenado en disco con el file extensión .jks.

Una vez que haya creado los certificados necesarios para el agente de Kafka y el cliente de Kafka disponibles, puede continuar configurando el agente de Kafka que se ejecuta en Control Center. Necesitas saber lo siguiente:

• : El nombre de host público del Centro de control; esto debe ser resoluble y accesible para los clientes de Kafka.
• : La contraseña del almacén de claves proporcionada al crear el certificado SSL.
• y : Estas son las contraseñas que desea establecer para el usuario administrador y cliente respectivamente. Tenga en cuenta que puede agregar más usuarios, como se indica en el exampel.

Edite o agregue (con acceso sudo) las siguientes propiedades en /etc/kafka/server.properties, insertando las variables anteriores como se muestra:

ADVERTENCIA: No elimine PLAINTEXT://localhost:9092; esto interrumpirá la funcionalidad del Centro de control ya que los servicios internos no podrán comunicarse.

• …
• # Las direcciones que escucha el broker Kafka.
• oyentes=PLAINTEXT://localhost:9092,SASL_SSL://0.0.0.0:9093
• # Estos son los hosts que se anuncian a cualquier cliente que se conecte.
• anunciado.listeners=PLAINTEXT://localhost:9092,SASL_SSL:// :9093…
• ####### CONFIGURACIÓN PERSONALIZADA
• # CONFIGURACIÓN SSL
• ssl.endpoint.identificación.algoritmo=
  ssl.keystore.ubicación=/var/ssl/private/kafka.server.keystore.jks
• ssl.almacén de claves.contraseña=
• ssl.clave.contraseña=
• ssl.client.auth=ninguno
• ssl.protocolo=TLSv1.2
• # configuración SASL
• sasl.enabled.mechanisms=PLAIN
• nombre de usuario = "admin" \
• contraseña =” ”\
• usuario_admin =” ”\
• usuario_cliente =” ”;
• # NOTA Se pueden agregar más usuarios con user_ =
• # Autorización, activar ACL
• Authorizer.class.name=kafka.security.authorizer.AclAuthorizer super.users=Usuario:admin

Configuración de listas de control de acceso (ACL)

Activar ACL en localhost

ADVERTENCIA: Primero debemos configurar las ACL para localhost, de modo que el Centro de control aún pueda acceder a Kafka. Si no se hace esto, las cosas se estropearán.

• –autorizador kafka.security.authorizer.AclAuthorizer \
• –autorizador-propiedades zookeeper.connect=localhost:2181 \
• –añadir –allow-principal Usuario:ANONYMOUS –allow-host 127.0.0.1 –cluster
• /usr/lib/kafka/bin/kafka-acls.sh \
• –autorizador kafka.security.authorizer.AclAuthorizer \
• –autorizador-propiedades zookeeper.connect=localhost:2181 \
• –add –allow-principal Usuario:ANONYMOUS –allow-host 127.0.0.1 –topic '*'
• /usr/lib/kafka/bin/kafka-acls.sh \
• –autorizador kafka.security.authorizer.AclAuthorizer \
• –autorizador-propiedades zookeeper.connect=localhost:2181 \
• –add –allow-principal Usuario:ANONYMOUS –allow-host 127.0.0.1 –group '*'

Luego, debemos habilitar las ACL para el acceso externo de solo lectura, de modo que los usuarios externos puedan leer los temas paa.public.*.

### Entradas de ACL para usuarios anónimos /usr/lib/kafka/bin/kafka-acls.sh \

NOTA: Para un control más detallado, consulte la documentación oficial de Kafka.

• –autorizador kafka.security.authorizer.AclAuthorizer \
• –autorizador-propiedades zookeeper.connect=localhost:2181 \
• –add –allow-principal Usuario:* –operación lectura –operación describe \ –grupo 'NCC'
• /usr/lib/kafka/bin/kafka-acls.sh \
• –autorizador kafka.security.authorizer.AclAuthorizer \
• –autorizador-propiedades zookeeper.connect=localhost:2181 \
• –add –allow-principal Usuario:* –operación lectura –operación describe \ –tema paa.public. –tipo de patrón de recurso con prefijo

Una vez hecho esto, debe reiniciar los servicios:

### Entradas de ACL para usuarios externos /usr/lib/kafka/bin/kafka-acls.sh \

• reinicio de servicios sudo ncc

Para verificar que un cliente puede establecer una conexión segura, ejecute el siguiente comando en un dispositivo externo
computadora cliente (no en el servidor del Centro de control). A continuación, PUBLIC_HOSTNAME es el nombre de host del Centro de control:

• openssl s_client -debug -connect ${PUBLIC_HOSTNAME}:9093 -tls1_2 | grep "Se admite la renegociación segura"

En la salida del comando, debería ver el certificado del servidor, así como lo siguiente:

• Se admite la renegociación segura

Para asegurarse de que los servicios internos tengan acceso al servidor de Kafka, consulte el siguiente registrofiles:

• /var/log/kafka/servidor.log
• /var/log/kafka/kafka-autorizador.log

Validación de la conectividad del cliente externo

gato kafka

NOTA: Estas instrucciones deben ejecutarse en una computadora cliente (no en el servidor del Centro de control).
NOTA: Para mostrar información de métricas, asegúrese de que al menos un monitor esté ejecutándose en el Centro de control.

Para verificar y validar la conectividad como cliente externo, es posible utilizar la utilidad kafkacat que se instaló en la sección “Verificación de que la API de transmisión funciona en Control Center” en la página 4.
Realice los siguientes pasos:

NOTA: A continuación CLIENT_USER es el usuario previamente especificado en el file /etc/kafka/server.properties en el Centro de control: es decir, user_client y la contraseña establecida allí.
El certificado raíz de CA utilizado para firmar el certificado SSL del lado del servidor debe estar presente en el cliente.

Crear un file client.properties con el siguiente contenido:

• seguridad.protocolo=SASL_SSL
• ssl.ca.ubicación={PATH_TO_CA_CERT}
• sasl.mechanisms=PLAIN
• sasl.username={CLIENTE_USUARIO}
• sasl.contraseña={CLIENTE_CONTRASEÑA}

dónde

• {PATH_TO_CA_CERT} es la ubicación del certificado raíz de CA utilizado por el agente Kafka
• {CLIENT_USER} y {CLIENT_PASSWORD} son las credenciales de usuario del cliente.

Ejecute el siguiente comando para ver el mensaje consumido por kafkacat:

• exportar KAFKA_FQDN=
• export METRICS_TOPIC=paa.public.accounts. .métrica
• kafkacat -b ${KAFKA_FQDN}:9093 -F cliente.propiedades -t ${METRICS_TOPIC} -C -e

donde {METRICS_TOPIC} es el nombre del tema de Kafka con el prefijo "paa.public".

NOTA: Las versiones anteriores de kafkacat no proporcionan la opción -F para leer la configuración del cliente desde un file. Si está utilizando una versión de este tipo, debe proporcionar la misma configuración desde la línea de comando como se muestra a continuación.

kafkacat -b ${KAFKA_FQDN}:9093\

• X seguridad.protocolo=SASL_SSL \
• X ssl.ca.ubicación={PATH_TO_CA_CERT} \
• X sasl.mechanisms=PLAIN \
• X sasl.nombredeusuario={CLIENTE_USUARIO} \
• X sasl.contraseña={CLIENTE_CONTRASEÑA} \
• t ${METRICS_TOPIC} -C -e

Para depurar la conectividad, puede usar la opción -d:

Depurar las comunicaciones de los consumidores
kafkacat -d consumidor -b ${KAFKA_FQDN}:9093 -F cliente.propiedades -t ${METRICS_TOPIC} -C -e
# Depurar comunicaciones de intermediarios
kafkacat -d intermediario -b ${KAFKA_FQDN}:9093 -F cliente.propiedades -t ${METRICS_TOPIC} -C -e

Asegúrese de consultar la documentación de la biblioteca cliente de Kafka en uso, ya que las propiedades pueden diferir de las de client.properties.

Formato de mensaje
Los mensajes utilizados para los temas de métricas y metadatos se serializan en formato de búfer de protocolo (protobuf) (ver desarrolladores.google.com/protocol-buffers). Los esquemas para estos mensajes se adhieren al siguiente formato:

Esquema de métricas Protobuf

• sintaxis = “proto3”;
• importar “google/protobuf/timestamp.proto”;
• paquete paa.streamingapi;
• opción go_package = “.;paa_streamingapi”;
• Métricas del mensaje {
• google.protobuf.Timestamp más oportunoamp = 1;
• mapa valores = 2;
• int32 stream_id = 3;
• }
• /**
• * Un valor métrico puede ser un número entero o flotante.
• */
• mensaje ValorMetrico {
• uno de tipo {
• int64 valor_int = 1;
• flotador valor_flotante = 2;
• }
• }

Esquema de metadatos Protobuf

• sintaxis = “proto3”;
• paquete paa.streamingapi;
• opción go_package = “.;paa_streamingapi”;
• mensaje Metadatos {
• int32 stream_id = 1;
• cadena nombre_secuencia = 2;
• mapa tags = 13;
• }

ex clienteampLos

NOTA: Estos comandos están destinados a ejecutarse en un cliente externo, por ej.ampdeje su computadora portátil o similar, y no en el Centro de control.
NOTA: Para que se muestre la información de métricas, asegúrese de que al menos un monitor se esté ejecutando en Control Center.

El tarball del Centro de control incluye el archivo paa-streaming-api-client-examples.tar.gz (cliente-examples), que contiene un exampLe script de Python que muestra cómo usar la API de Streaming.

Instalación y configuración de Client ExampLos
Encuentras cliente-examparchivos en la carpeta del Centro de control de Paragon Active Assurance:

• exportar CC_VERSION=4.1.0
• cd ./paa-control-center_${CC_VERSION}
• ls paa-streaming-api-cliente-examples*

Para instalar cliente-examparchivos en su computadora cliente externa, proceda de la siguiente manera:

• # Crear directorio para extraer el contenido del cliente examples tarball
• mkdir paa-streaming-api-cliente-exampLos
• # Extrae el contenido del cliente examples tarball
• tar xzf paa-streaming-api-cliente-examples.tar.gz -C paa-streaming-api-cliente-exampLos
• # Ir al directorio recién creado
• cd paa-streaming-api-cliente-exampLos

cliente-examples requiere Docker para ejecutarse. Las descargas y las instrucciones de instalación de Docker se pueden encontrar en https://docs.docker.com/engine/install.

Usando Cliente ExampLos
El cliente-examples tools pueden ejecutarse en modo básico o avanzado para compilar examples de diversa complejidad. En ambos casos, también es posible ejecutar el examparchivos con una configuración file que contiene propiedades adicionales para una mayor personalización del lado del cliente.

Modo básico
En el modo básico, las métricas y sus metadatos se transmiten por separado. Para ello, el cliente escucha cada tema de Kafka disponible para acceso externo y simplemente imprime los mensajes recibidos en la consola.
Para iniciar la ejecución de la base examparchivos, ejecute:

• build.sh run-basic –kafka-brokers localhost:9092 –cuenta ACCOUNT_SHORTNAME

donde ACCOUNT_SHORTNAME es el nombre abreviado de la cuenta de la que desea obtener las métricas.
Para terminar la ejecución de la example, presione Ctrl + C. (Puede haber un ligero retraso antes de que la ejecución se detenga porque el cliente espera un evento de tiempo de espera).

Modo avanzado

NOTA: Las métricas se muestran solo para los monitores HTTP que se ejecutan en el Centro de control.

La ejecución en modo avanzado muestra la correlación entre métricas y mensajes de metadatos. Esto es
posible gracias a la presencia en cada mensaje de métricas de un campo de identificación de flujo que hace referencia al mensaje de metadatos correspondiente.
Para ejecutar el ex avanzadoamparchivos, ejecute:

• build.sh ejecutar-avanzado –kafka-brokers localhost:9092 –cuenta ACCOUNT_SHORTNAME

donde ACCOUNT_SHORTNAME es el nombre abreviado de la cuenta de la que desea obtener las métricas.
Para terminar la ejecución de la example, presione Ctrl + C. (Puede haber un ligero retraso antes de que la ejecución se detenga porque el cliente espera un evento de tiempo de espera).

Ajustes adicionales
Es posible ejecutar el examparchivos con configuración adicional del cliente usando el –config-file opción seguida de file nombre que contiene propiedades en la forma clave=valor.

• build.sh ejecutar-avanzado \
• –kafka-brokers localhost:9092 \
• –cuenta CUENTA_NOMBRE CORTO \
• –config-file client_config.properties

NOTA: Todo fileLos correos electrónicos a los que se hace referencia en el comando anterior deben estar ubicados en el directorio actual y deben ser referidos usando solo rutas relativas. Esto se aplica tanto a la –config-file argumento y a todas las entradas en la configuración file que describen file Ubicaciones.

Validación de la autenticación de cliente externo
Para validar la autenticación del cliente desde fuera del Centro de control mediante client-examparchivos, realice los siguientes pasos:

Desde la carpeta Paragon Active Assurance Control Center, cambie a paa-streaming-api-client-exampcarpeta de archivos:

cd paa-streaming-api-cliente-exampLos

• Copie el certificado raíz de CA ca-cert en el directorio actual.
• Crear un cliente.propiedades file con el siguiente contenido:

seguridad.protocol=SASL_SSL ssl.ca.location=certificado ca
sasl.mechanism=PLAIN
sasl.username={CLIENTE_USUARIO}
sasl.contraseña={CLIENTE_CONTRASEÑA}

donde {CLIENT_USER} y {CLIENT_PASSWORD} son las credenciales de usuario del cliente.

Ejecutar básico exampellos:

• exportar KAFKA_FQDN=
• build.sh ejecutar-básico –kafka-brokers ${KAFKA_FQDN}:9093 \
• –cuenta ACCOUNT_SHORTNAME
• –config-file cliente.propiedades

donde ACCOUNT_SHORTNAME es el nombre abreviado de la cuenta de la que desea obtener las métricas.

Ejecutar avanzado exampellos:

• exportar KAFKA_FQDN=
• build.sh ejecutar-avanzado –kafka-brokers ${KAFKA_FQDN}:9093 \
• –cuenta ACCOUNT_SHORTNAME
• –config-file cliente.propiedades

Apéndice

En este apéndice describimos cómo crear:

• un almacén de claves file para almacenar el certificado SSL del agente Kafka
• un almacén de confianza file para almacenar el certificado raíz de la autoridad de certificación (CA) que se usa para firmar el certificado del agente de Kafka.

Creación de un certificado de agente de Kafka
Creación de un certificado mediante una autoridad de certificación real (recomendado)
Se recomienda que obtenga un certificado SSL real de una CA de confianza.
Una vez que se haya decidido por una CA, copie su certificado raíz de CA ca-cert file a su propio camino como se muestra a continuación:

• exportar CA_PATH=~/mi-ca
• mkdir${CA_PATH}
• cp certificado ca ${CA_PATH}

Cree su propia autoridad de certificación

NOTA: Normalmente debería tener su certificado firmado por una Autoridad de Certificación real; ver la subsección anterior. Lo que sigue es solo un exampel.

Aquí creamos nuestro propio certificado raíz de la Autoridad de certificación (CA) file válido por 999 días (no recomendado en producción):

• # Crear un directorio para almacenar la CA
• exportar CA_PATH=~/mi-ca
• mkdir${CA_PATH}
• # Generar el certificado CA
• openssl req -new -x509 -keyout ${CA_PATH}/ca-key -out ${CA_PATH}/ca-cert -days 999

Creación del almacén de confianza del cliente
Ahora puedes crear un almacén de confianza file que contiene el ca-cert generado anteriormente. Este file será necesario para el cliente de Kafka que accederá a la API de Streaming:

• herramienta de claves -keystore kafka.client.truststore.jks \
  • alias CARoot\
  • certificado de importación -file ${CA_PATH}/certificado ca

Ahora que el certificado de CA está en el almacén de confianza, el cliente confiará en cualquier certificado firmado con él.
Deberías copiar el file kafka.client.truststore.jks a una ubicación conocida en su computadora cliente y apúntelo en la configuración.

Creación del almacén de claves para el bróker de Kafka
Para generar el certificado SSL del agente Kafka y luego el almacén de claves kafka.server.keystore.jks, proceda de la siguiente manera:

Generando el Certificado SSL
A continuación, 999 es el número de días de validez del almacén de claves y FQDN es el nombre de dominio completo del cliente (nombre de host público del nodo).

NOTA: Es importante que el FQDN coincida con el nombre de host exacto que utilizará el cliente Kafka para conectarse al Centro de control.

• sudo mkdir -p /var/ssl/privado
• sudo chown -R $USUARIO: /var/ssl/privado
• cd /var/ssl/privado
• exportar FQDN= herramienta de claves -keystore kafka.server.keystore.jks \
• – servidor alias \
• – validez 999 \
• – genkey -keyalg RSA -ext SAN=dns:${FQDN}

Cree una solicitud de firma de certificado y guárdela en el file llamado cert-server-request:

• herramienta de claves -keystore kafka.server.keystore.jks \
  • – servidor alias \
  • – certreq \
  • – file solicitud de servidor de certificación

Ahora debe enviar el file cert-server-request a su autoridad certificadora (CA) si está utilizando una real. Luego le devolverán el certificado firmado. A continuación nos referiremos a esto como certificado firmado por el servidor.

Firmar el certificado SSL utilizando un certificado CA de creación propia

NOTA: Nuevamente, no se recomienda utilizar su propia CA en un sistema de producción.

Firmar el certificado utilizando la CA mediante el file cert-server-request, que genera el certificado firmado cert-server-signed. Vea abajo; ca-password es la contraseña establecida al crear el certificado de CA.

• cd /var/ssl/privado openssl x509 -req \
  • – CA ${CA_PATH}/ca-cert\
  • – CAkey ${CA_PATH}/ca-key \
  • – en solicitud-servidor-certificado \
  • – fuera firmado por el servidor de certificados \
  • – días 999 -CAcreateserial\
  • – contraseña:{ca-contraseña}

Importación del certificado firmado al almacén de claves

Importe el certificado raíz ca-cert al almacén de claves:

• herramienta de claves -keystore kafka.server.keystore.jks \
  • – alias ca-cert \
  • - importar \
  • – file ${CA_PATH}/certificado ca

Importe el certificado firmado denominado cert-server-signed:

• herramienta de claves -keystore kafka.server.keystore.jks \
  • – servidor alias \
  • - importar \
  • – file certificado-servidor-firmado

El file kafka.server.keystore.jks debe copiarse en una ubicación conocida en el servidor del Centro de control y luego consultarse en /etc/kafka/server.properties.

Uso de la API de transmisión

EN ESTA SECCIÓN

• Generalidades | 20
• Nombres de temas de Kafka | 21
• Examparchivos de uso de la API de streaming | 21

General
La API de transmisión obtiene datos de prueba y de monitoreo. No es posible destacar una de estas categorías.
La API de transmisión no obtiene datos de las pruebas basadas en secuencias de comandos (aquellas representadas por un rectángulo en lugar de una pieza de rompecabezas en la GUI del Centro de control), como las pruebas de activación del servicio Ethernet y las pruebas de transparencia.

Nombres de temas de Kafka
Los nombres de los temas de Kafka para la API de transmisión son los siguientes, donde %s es el nombre corto de la cuenta del Centro de control (indicado al crear la cuenta):

• constante (
• NombreExportador = “kafka”
• metadataTopicTpl = “paa.public.accounts.%s.metadata” metricsTopicTpl = “paa.public.accounts.%s.metrics” )

ExampArchivos de Uso de la API de Streaming
El exampLos archivos que siguen se encuentran en el tarball paa-streaming-api-client-examples.tar.gz contenido en el tarball del Centro de control.
Primero, hay un ex básicoample demuestra cómo las métricas y sus metadatos se transmiten por separado y simplemente imprimen los mensajes recibidos en la consola. Puedes ejecutarlo de la siguiente manera:

• sudo ./build.sh run-basic –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME

También hay un ex más avanzado.amparchivo donde se correlacionan las métricas y los mensajes de metadatos. Utilice este comando para ejecutarlo:

• sudo ./build.sh run-advanced –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME

Debe usar sudo para ejecutar comandos de Docker como los anteriores. Opcionalmente, puede seguir los pasos posteriores a la instalación de Linux para poder ejecutar comandos de Docker sin sudo. Para más detalles, vaya a docs.docker.com/engine/install/linux-postinstall.

Juniper Networks, el logotipo de Juniper Networks, Juniper y Junos son marcas comerciales registradas de Juniper Networks, Inc. en los Estados Unidos y otros países. Todas las demás marcas comerciales, marcas de servicio, marcas registradas o marcas de servicio registradas son propiedad de sus respectivos dueños. Juniper Networks no asume ninguna responsabilidad por las imprecisiones que pueda contener este documento. Juniper Networks se reserva el derecho de cambiar, modificar, transferir o revisar de otro modo esta publicación sin previo aviso. Copyright © 2023 Juniper Networks, Inc. Todos los derechos reservados.