Guía del usuario de la API de transmisión de Juniper

Simplicidad de ingeniería
Guía 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 están incluidos en la instalación de Paragon Active Assurance.
Sin embargo, se necesita un poco de configuración antes de poder usar 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.
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 se diseñó para escalabilidad y sistemas redundantes. Este documento se enfoca solo en cómo configurarlo para hacer uso de la función Streaming API que se encuentra en Paragon Active Assurance Control Center. Para configuraciones más avanzadas, consulte 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 usando 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 las métricas timescaledb los servicios sudo ncc inician las métricas 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 actualizar 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.cuentas.públicas.micuenta.metadatos
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 localhost 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 un nombre de usuario y una 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 de certificación (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 configurar para el administrador y el usuario del cliente, respectivamente.
  Tenga en cuenta que puede agregar más usuarios, como se indica en el ej.ampel.
  Edite o agregue (con acceso sudo) las siguientes propiedades en /etc/kafka/server.properties, insertando las variables anteriores como se muestra:

ADVERTENCIA: No elimine TEXTOPLANO://localhost:9092 ; esto interrumpirá la funcionalidad del Centro de control ya que los servicios internos no podrán comunicarse.
…# Las direcciones en las que escucha el bróker de 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 de SASL sasl.enabled.mechanisms=PLAIN
listener.name.sasl_ssl.plain.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginMo dule requerido \ username=”admin” \ password=” ”\usuario_admin=” ”\usuario_cliente=” ”; # NOTA Se pueden agregar más usuarios con user_ =
# Autorización, active las ACL authorizer.class.name=kafka.security.authorizer.AclAuthorizer super.users=User: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 Control Center pueda seguir accediendo a Kafka. Si esto no se hace, las cosas se romperán.
######### Entradas de ACL para usuarios anónimos
/usr/lib/kafka/bin/kafka-acls.sh \
–authorizer kafka.security.authorizer.AclAuthorizer \ –authorizer-properties zookeeper.connect=localhost:2181 \ –add –allow-principal Usuario:ANONYMOUS –allow-host 127.0.0.1 –cluster
/usr/lib/kafka/bin/kafka-acls.sh \
–authorizer kafka.security.authorizer.AclAuthorizer \ –authorizer-properties zookeeper.connect=localhost:2181 \ –add –allow-principal User:ANONYMOUS –allow-host 127.0.0.1 –topic '*'
/usr/lib/kafka/bin/kafka-acls.sh \
–authorizer kafka.security.authorizer.AclAuthorizer \ –authorizer-properties zookeeper.connect=localhost:2181 \ –add –allow-principal User: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.*.
NOTA: Para obtener un control más detallado, consulte la documentación oficial de Kafka.
######### Entradas de ACL para usuarios externos
/usr/lib/kafka/bin/kafka-acls.sh \
–autorizador kafka.security.authorizer.AclAuthorizer \–authorizer-properties zookeeper.connect=localhost:2181 \
–añadir –permitir usuario principal:* –operación leer –operación describir \–grupo 'NCC'
/usr/lib/kafka/bin/kafka-acls.sh \
–autorizador kafka.security.authorizer.AclAuthorizer \
–autorizador-propiedades zookeeper.connect=localhost:2181 \
–añadir –permitir-usuario principal:* –operación leer –operación describir \
–tema paa.publico. –resource-pattern-type prefijado
Una vez hecho esto, debe reiniciar los servicios:
reinicio de servicios sudo ncc
Para verificar que un cliente pueda establecer una conexión segura, ejecute el siguiente comando en una computadora cliente externa (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 se esté ejecutando en Control Center.
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
Centro de control: a saber, 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} donde
  • {PATH_TO_CA_CERT} es la ubicación del certificado raíz de CA utilizado por el agente de 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={RUTA_A_CA_CERT} \
-X sasl.mecanismos=PLAIN \
-X sasl.username={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; option go_package = “.;paa_streamingapi”; métricas de mensajes { google.protobuf.Timestamp más oportunoamp = 1; mapa valores = 2; int32 medición_id = 3; } /** * Un valor de métrica puede ser un número entero o un flotante. */
mensaje MetricValue { uno de tipo { int64 int_val = 1; flotador float_val = 2; } }
Esquema de metadatos Protobuf
sintaxis = “proto3”; paquete paa.streamingapi; option go_package = “.;paa_streamingapi”; metadatos del mensaje { int32 id_medida = 1; cadena nombre_medida = 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=3.3.1
cd ./paa-control-center_${CC_VERSION} ls paa-streaming-api-client-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-client-examples 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 Control Center.
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étrica de un campo de id de flujo que hace referencia al mensaje de metadatos correspondiente.
Para ejecutar el ex avanzadoamples, ejecute: ./build.sh run-advanced –kafka-brokers localhost:9092 –account NOMBRE_CORTO_CUENTA donde NOMBRE_CORTO_CUENTA 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 run-advanced \ –kafka-brokers localhost:9092 \ –account ACCOUNT_SHORTNAME \ –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 del Centro de control de Paragon Active Assurance, cambie a paa-streaming-api-clintexampcarpeta 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.protocolo=SASL_SSL
  ssl.ca.ubicación=ca-cert
  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 run-basic –kafka-brokers ${KAFKA_FQDN}:9093 \ –account ACCOUNT_SHORTNAME
  –config-file client.properties 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 run-advanced –kafka-brokers ${KAFKA_FQDN}:9093 \ –account 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=~/my-ca mkdir ${CA_PATH} cp ca-cert ${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):
# Cree un directorio para almacenar la exportación de CA CA_PATH=~/my-ca mkdir ${CA_PATH}
# Genere el certificado de 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:
keytool -keystore kafka.client.truststore.jks \ -alias CARoot \ -importcert -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 de Kafka para conectarse al Centro de control. sudo mkdir -p /var/ssl/privado
sudo chown -R $USUARIO: /var/ssl/private cd /var/ssl/private export FQDN=
keytool -keystore kafka.server.keystore.jks \ -alias server \ -validity 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:
keytool -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 de Certificación (CA) si está utilizando una real. Luego devolverán el certificado firmado. Nos referiremos a esto como cert-server-signed a continuación. Firmar el certificado SSL utilizando un certificado de CA de creación propia
NOTA: Nuevamente, no se recomienda usar 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/private openssl x509 -req \ -CA ${CA_PATH}/ca-cert \ -CAkey ${CA_PATH}/ca-key \ -in cert-server-request \ -out cert-server-signed \ -days 999 -CAcreateserial \ -passin pass:{contraseña-ca}
Importación del certificado firmado al almacén de claves
Importe el certificado raíz ca-cert al almacén de claves:
keytool -keystore kafka.server.keystore.jks \ -alias ca-cert \ -import \ -file ${CA_PATH}/certificado ca
Importe el certificado firmado denominado cert-server-signed:
keytool -keystore kafka.server.keystore.jks \ -servidor alias \ -importación \ -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

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 abreviado del Control
Cuenta Centro (indicado al crear la cuenta):
const (exportadorNombre = “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 que demuestra cómo las métricas y sus metadatos se transmiten por separado y simplemente imprime los mensajes recibidos en la consola. Puede 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 utilizar sudo para ejecutar comandos de Docker como los anteriores. Opcionalmente, puede seguir los pasos posteriores a la instalación de Linux para poder ejecutar los comandos de Docker sin sudo.
Para obtener 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 © 2022 Juniper Networks, Inc. Todos los derechos reservados.