Guía de API de transmisión
Publicado
2023-07-07
LANZAR
4.2

Introdución

Esta guía describe como extraer datos de Paragon Active Assurance mediante a API de streaming do produto.
A API e o cliente de transmisión están incluídos na instalación de Paragon Active Assurance.
Non obstante, é necesario un pouco de configuración antes de poder usar a API. Isto é tratado no capítulo "Configuración da API de transmisión en tempo real" na páxina 1.

Configuración da API de streaming

Acabadoview
Este capítulo describe como configurar a API de streaming para permitir a subscrición a mensaxes de métricas a través de Kafka.
pr
A continuación pasaremos por:

• Como activar a API de streaming
• Como configurar Kafka para escoitar clientes externos
• Como configurar Kafka para usar ACL e configurar o cifrado SSL para ditos clientes

Kafka é unha plataforma de transmisión de eventos que permite a captura en tempo real de datos enviados desde varias fontes de eventos (sensores, bases de datos, dispositivos móbiles) en forma de fluxos de eventos, así como o almacenamento duradeiro destes fluxos de eventos para a súa posterior recuperación e manipulación.
Con Kafka é posible xestionar a transmisión de eventos de extremo a extremo de forma distribuída, altamente escalable, elástica, tolerante a fallos e segura.
NOTA: Kafka pódese configurar de moitas formas diferentes e foi deseñado para sistemas de escalabilidade e redundantes. Este documento céntrase só en como configuralo para facer uso da función API de streaming que se atopa no Centro de control de Paragon Active Assurance. Para configuracións máis avanzadas remitimos á documentación oficial de Kafka: kafka.apache.org/26/documentation.html.

Terminoloxía

• Kafka: plataforma de transmisión de eventos.
• Tema de Kafka: Colección de eventos.
• Abonado/consumidor de Kafka: compoñente responsable da recuperación dos eventos almacenados nun tema de Kafka.
• Kafka broker: servidor de capa de almacenamento dun clúster de Kafka.
• SSL/TLS: SSL é un protocolo seguro desenvolvido para enviar información de forma segura a través de Internet. TLS é o sucesor de SSL, introducido en 1999.
• SASL: marco que proporciona mecanismos para a autenticación do usuario, a comprobación da integridade dos datos e o cifrado.
• Abonado da API de streaming: Compoñente responsable da recuperación dos eventos almacenados en temas definidos en Paragon Active Assurance e destinados a acceso externo.
• Autoridade de certificación: unha entidade de confianza que emite e revoga certificados de clave pública.
• Certificado raíz da autoridade de certificación: certificado de clave pública que identifica a unha autoridade de certificación.

Como funciona a API de streaming
Como se mencionou anteriormente, a API de transmisión permite que os clientes externos recuperen información sobre as métricas de Kafka.
Todas as métricas recollidas polos axentes de proba durante unha tarefa de proba ou seguimento envíanse ao servizo Stream.
Despois dunha fase de procesamento, o servizo Stream publica esas métricas en Kafka xunto con metadatos adicionais.Temas Kafka
Kafka ten o concepto de temas aos que se publican todos os datos. En Paragon Active Assurance hai moitos temas de Kafka dispoñibles; non obstante, só un subconxunto destes están destinados ao acceso externo.
Cada conta de Paragon Active Assurance en Control Center ten dous temas dedicados. Abaixo, ACCOUNT é o nome abreviado da conta:

• paa.public.accounts.{ACCOUNT}.metrics
• Todas as mensaxes de métricas para a conta indicada publícanse neste tema
• Grandes cantidades de datos
• Alta frecuencia de actualización
• paa.public.accounts.{ACCOUNT}.metadatos
• Contén metadatos relacionados cos datos das métricas, por exemploample a proba, monitor ou axente de proba asociado ás métricas
• Pequenas cantidades de datos
• Baixa frecuencia de actualización

Activando a API de streaming
NOTA: Estas instrucións deben executarse no servidor do Centro de control mediante sudo.
Dado que a API de transmisión engade algo de sobrecarga ao Centro de control, non está activada por defecto. Para activar a API, primeiro debemos activar a publicación de métricas en Kafka na configuración principal file:

• /etc/netrounds/netrounds.conf

KAFKA_METRICS_ENABLED = Verdadeiro
AVISO: A activación desta función pode afectar o rendemento do Centro de control. Asegúrese de dimensionar a súa instancia en consecuencia.
A continuación, para activar o reenvío destas métricas aos temas de Kafka correctos:

• /etc/netrounds/metrics.yaml

streaming-api: verdadeiro
Para activar e iniciar os servizos da API de streaming, executa:
Os servizos sudo ncc activan as métricas de escala temporal
Os servizos de sudo ncc comezan métricas con escala de tempo
Finalmente, reinicia os servizos:
Reiniciar os servizos sudo ncc
Comprobando que a API de streaming funciona no Centro de control
NOTA: Estas instrucións deben executarse no servidor do Centro de control.
Agora podes verificar que estás a recibir métricas sobre os temas de Kafka correctos. Para facelo, instale a utilidade kafkacat:
actualización de sudo apt-get
sudo apt-get install kafkacat
Se tes unha proba ou un monitor en execución no Centro de control, deberías poder usar kafkacat para recibir métricas e metadatos sobre estes temas.
Substitúe myaccount polo nome curto da túa conta (isto é o que ves no teu Centro de control URL):
exportar METRICS_TOPIC=paa.public.accounts.myaccount.metrics
exportar METADATA_TOPIC=paa.public.accounts.myaccount.metadata
Agora deberías ver as métricas executando este comando:
kafkacat -b ${KAFKA_FQDN}:9092 -t ${METRICS_TOPIC} -C -e
Para view metadatos, execute o seguinte comando (ten en conta que non se actualizará con tanta frecuencia):
kafkacat -b ${KAFKA_FQDN}:9092 -t ${METADATA_TOPIC} -C -e
NOTA:
kafkacat”Cliente Examples" na páxina 14
Isto verifica que temos unha API de streaming que funciona dende o Centro de control. Non obstante, o máis probable é que estea interesado en acceder aos datos desde un cliente externo. A seguinte sección describe como abrir Kafka para o acceso externo.
Abrir Kafka para hosts externos
NOTA: Estas instrucións deben executarse no servidor do Centro de control.
Por defecto, Kafka que se executa no Centro de control está configurado para escoitar só no host local para uso interno.
É posible abrir Kafka para clientes externos modificando a configuración de Kafka.
Conexión con Kafka: advertencias
PRECAUCIÓN: Lea isto atentamente, xa que é fácil atopar problemas de conexión con Kafka se non entendeu estes conceptos.
Na configuración do Centro de control descrita neste documento, só hai un único corredor de Kafka.
Non obstante, teña en conta que un corredor de Kafka está destinado a funcionar como parte dun clúster de Kafka que pode constar de moitos corredores de Kafka.
Cando se conecta a un corredor de Kafka, o cliente de Kafka establece unha conexión inicial. Durante esta conexión, o corredor de Kafka devolverá á súa vez unha lista de "oíntes anunciados", que é unha lista dun ou máis corredores de Kafka.
Ao recibir esta lista, o cliente de Kafka desconectarase e, a continuación, volverá conectarse a un destes oíntes anunciados. Os oíntes anunciados deben conter nomes de host ou enderezos IP accesibles para o cliente de Kafka, ou o cliente non poderá conectarse.
Se se utiliza o cifrado SSL, que implica un certificado SSL que está ligado a un nome de host en particular, é aínda máis importante que o cliente de Kafka reciba o enderezo correcto para conectarse, xa que, en caso contrario, a conexión pode ser rexeitada.
Lea máis sobre os oíntes de Kafka aquí: www.confluent.io/blog/kafka-listeners-explained
Cifrado SSL/TLSE
Para asegurarnos de que só os clientes de confianza teñen permiso para acceder a Kafka e á API de streaming, debemos configurar o seguinte:

• Autenticación: os clientes deben proporcionar nome de usuario e contrasinal a través dunha conexión segura SSL/TLS entre o cliente e Kafka.
• Autorización: os clientes autenticados poden realizar tarefas reguladas polas ACL.

Aquí hai un remateview:
*) Autenticación de nome de usuario/contrasinal realizada nunha canle cifrada con SSL

Para comprender completamente como funciona o cifrado SSL/TLS para Kafka, consulte a documentación oficial: docs.confluent.io/platform/current/kafka/encryption.html
Certificado SSL/TLS superiorview
NOTA: Nesta subsección empregaremos a seguinte terminoloxía:
Certificado: un certificado SSL asinado por unha autoridade de certificación (CA). Cada corredor de Kafka ten un.
Almacén de claves: o almacén de claves file que almacena o certificado. O almacén de chaves file contén a clave privada do certificado; polo tanto, hai que gardala de forma segura.
Fideicomiso: A file que contén os certificados de CA de confianza.
Para configurar a autenticación entre un cliente externo e Kafka que se executa no Centro de control, ambas as partes deben ter un almacén de claves definido cun certificado relacionado asinado por unha autoridade de certificación (CA) xunto co certificado raíz da CA.
Ademais disto, o cliente tamén debe ter un almacén de confianza co certificado raíz da CA.
O certificado raíz da CA é común ao corredor de Kafka e ao cliente de Kafka.
Creación dos certificados necesarios
Isto está descrito no "Apéndice" na páxina 17.
Configuración SSL/TLS de Kafka Broker no Centro de control
NOTA: Estas instrucións deben executarse no servidor do Centro de control.
NOTA: Antes de continuar, debes crear o almacén de claves que contén o certificado SSL seguindo as instrucións do "Apéndice" na páxina 17. As rutas que se mencionan a continuación proceden destas instrucións.
O almacén de claves SSL é un file almacenado no disco co file extensión .jks.
Unha vez que teñas dispoñibles os certificados necesarios creados tanto para o corredor de Kafka como para o cliente de Kafka, podes continuar configurando o corredor de Kafka que se executa no Centro de control. Debes saber o seguinte:

• : O nome de host público do Centro de control; isto debe ser resolto e accesible polos clientes de Kafka.
• : o contrasinal do almacén de claves proporcionado ao crear o certificado SSL.
• e : Estes son os contrasinais que quere establecer para o usuario administrador e cliente respectivamente. Teña en conta que pode engadir máis usuarios, como se indica no example.

Edite ou engada (con acceso sudo) as seguintes propiedades en /etc/kafka/server.properties, inserindo as variables anteriores como se mostra:
AVISO: Non elimine PLAINTEXT://localhost:9092; isto romperá a funcionalidade do Centro de control xa que os servizos internos non poderán comunicarse.

…
# Os enderezos que escoita o corredor de Kafka.
listeners=PLAINTEXT://localhost:9092,SASL_SSL://0.0.0.0:9093
# Estes son os hosts anunciados a calquera cliente que se conecte.
advertised.listeners=PLAINTEXT://localhost:9092,SASL_SSL:// : 9093
…
####### CONFIGURACIÓN PERSONALIZADA
# CONFIGURACIÓN SSL
ssl.endpoint.identification.algorithm=
ssl.keystore.location=/var/ssl/private/kafka.server.keystore.jks
ssl.keystore.password=
ssl.key.contrasinal=
ssl.client.auth=ningunha
ssl.protocol=TLSv1.2
# Configuración SASL
sasl.enabled.mechanisms=PLAIN
listener.name.sasl_ssl.plain.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginMo
dule necesario \
nome de usuario="admin" \
contrasinal=” ” \
user_admin=" ” \
usuario_cliente=" ”;
# NOTA Pódense engadir máis usuarios con user_ =
# Autorización, activa as ACL
authorizer.class.name=kafka.security.authorizer.AclAuthorizer
super.users=Usuario:admin

Configurar listas de control de acceso (ACL)
Activando as ACL en localhost
AVISO: Primeiro debemos configurar ACL para localhost, para que o propio Centro de control poida acceder a Kafka. Se isto non se fai, as cousas 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:ANÓNIMO –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 Usuario:ANÓNIMO –allow-host 127.0.0.1 –tema '*'
/usr/lib/kafka/bin/kafka-acls.sh \
–authorizer kafka.security.authorizer.AclAuthorizer \
–authorizer-properties zookeeper.connect=localhost:2181 \
–add –allow-principal Usuario:ANÓNIMO –allow-host 127.0.0.1 –grupo '*'

A continuación, necesitamos activar as ACL para o acceso externo de só lectura, para que os usuarios externos poidan ler os temas paa.public.*.
NOTA: Para un control máis fino, consulte a documentación oficial de Kafka.

######### Entradas de ACL para usuarios externos
/usr/lib/kafka/bin/kafka-acls.sh \
–authorizer kafka.security.authorizer.AclAuthorizer \
–authorizer-properties zookeeper.connect=localhost:2181 \
–add –allow-principal Usuario:* –operation read –operation describe \
-grupo 'NCC'
/usr/lib/kafka/bin/kafka-acls.sh \
–authorizer kafka.security.authorizer.AclAuthorizer \
–authorizer-properties zookeeper.connect=localhost:2181 \
–add –allow-principal Usuario:* –operation read –operation describe \
–tema paa.público. –prefixo de tipo de patrón de recurso

Unha vez feito isto, cómpre reiniciar os servizos:
Reiniciar os servizos sudo ncc
Para verificar que un cliente pode establecer unha conexión segura, execute o seguinte comando nun equipo cliente externo (non no servidor do Centro de control). Abaixo, PUBLIC_HOSTNAME é o nome de host do Centro de control:
openssl s_client -debug -connect ${PUBLIC_HOSTNAME}:9093 -tls1_2 | grep "Renegociación segura é compatible"
Na saída do comando deberías ver o certificado do servidor así como o seguinte:
É compatible a renegociación segura
Para asegurarse de que se concedeu acceso aos servizos internos ao servidor de Kafka, consulte o seguinte rexistrofiles:

• /var/log/kafka/server.log
• /var/log/kafka/kafka-authorizer.log

Validando a conectividade do cliente externo
kafkacat
NOTA: Estas instrucións deben executarse nun ordenador cliente (non no servidor do Centro de control).
NOTA: Para mostrar información de métricas, asegúrese de que polo menos un monitor estea en execución no Centro de control.
Para verificar e validar a conectividade como cliente externo, é posible utilizar a utilidade kafkacat que se instalou na sección "Comprobación de que a API de streaming funciona no Centro de control" na páxina 4.
Realice os seguintes pasos:
NOTA: Abaixo, CLIENT_USER é o usuario especificado anteriormente no file /etc/kafka/server.properties no Centro de control: é dicir, usuario_cliente e o contrasinal definido alí.
O certificado raíz da CA usado para asinar o certificado SSL do servidor debe estar presente no cliente.

• Crear un file client.properties co seguinte contido:

security.protocol=SASL_SSL
ssl.ca.location={PATH_TO_CA_CERT}
sasl.mechanisms=PLAIN
sasl.username={CLIENT_USER}
sasl.password={CLIENT_PASSWORD}
onde

• {PATH_TO_CA_CERT} é a localización do certificado raíz da CA que utiliza o corredor de Kafka
• {CLIENT_USER} e {CLIENT_PASSWORD} son as credenciais de usuario do cliente.
• Executa o seguinte comando para ver a mensaxe consumida por kafkacat:

exportar KAFKA_FQDN=
exportar METRICS_TOPIC=paa.public.accounts. .métricas
kafkacat -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -e
onde {METRICS_TOPIC} é o nome do tema de Kafka co prefixo “paa.public.”.

NOTA: As versións anteriores de kafkacat non proporcionan a opción -F para ler a configuración do cliente desde a file. Se está a usar esa versión, debe proporcionar a mesma configuración desde a liña de comandos que se mostra a continuación.

kafkacat -b ${KAFKA_FQDN}:9093 \
-X security.protocol=SASL_SSL \
-X ssl.ca.location={PATH_TO_CA_CERT} \
-X sasl.mechanisms=PLAIN \
-X sasl.username={CLIENT_USER} \
-X sasl.password={CLIENT_PASSWORD} \
-t ${METRICS_TOPIC} -C -e
Para depurar a conectividade, pode usar a opción -d:

Depurar as comunicacións do consumidor
kafkacat -d consumidor -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -e
# Depurar as comunicacións do corredor
kafkacat -d corredor -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -e

Asegúrese de consultar a documentación da biblioteca cliente de Kafka en uso, xa que as propiedades poden diferir das de client.properties.
Formato da mensaxe
As mensaxes utilizadas para os temas de métricas e metadatos serialízanse no formato de búferes de protocolo (protobuf) (consulte developers.google.com/protocol-buffers). Os esquemas destas mensaxes adhírense ao seguinte formato:

Metrics Protobuf Schema

sintaxe = "proto3";
importar "google/protobuf/timestamp.proto”;
paquete paa.streamingapi;
opción go_package = ".;paa_streamingapi";
Métricas da mensaxe {
google.protobuf.Timestamp veces máisamp = 1;
mapa valores = 2;
int32 stream_id = 3;
}
/**
* Un valor métrico pode ser un número enteiro ou un flotante.
*/
mensaxe MetricValue {
un de tipo {
int64 int_val = 1;
flotante float_val = 2;
}
}

Metadatos Protobuf Schema

sintaxe = "proto3";
paquete paa.streamingapi;
opción go_package = ".;paa_streamingapi";
metadatos da mensaxe {
int32 stream_id = 1;
cadea nome_stream = 2;
mapa tags = 13;
}

Cliente Examples

NOTA: Estes comandos están destinados a executarse nun cliente externo, por exemploample o seu portátil ou similar, e non no Centro de control.
NOTA: Para que se mostre a información das métricas, asegúrese de que polo menos un monitor estea en execución no Centro de control.
O tarball do Centro de control inclúe o arquivo paa-streaming-api-client-examples.tar.gz (cliente-examples), que contén un example script de Python que mostra como usar a API de streaming.
Instalación e configuración do cliente Examples
Atoparás cliente-exampficheiros no cartafol do Centro de control de Paragon Active Assurance:

exportar CC_VERSION=4.2.0
cd ./paa-control-center_${CC_VERSION}
ls paa-streaming-api-client-examples*
Para instalar cliente-exampficheiros no seu ordenador cliente externo, proceda do seguinte xeito:
# Crear directorio para extraer o contido do cliente, por exemploamples tarball
mkdir paa-streaming-api-client-examples
# Extraer o contido do cliente examples tarball
tar xzf paa-streaming-api-client-examples.tar.gz -C paa-streaming-api-client-examples
# Vaia ao directorio recén creado
cd paa-streaming-api-client-examples
cliente-examples require que Docker se execute. As descargas e as instrucións de instalación de Docker pódense atopar en https://docs.docker.com/engine/install.

Usando Cliente Examples
O cliente-exampas ferramentas poden executarse en modo básico ou avanzado para construír exampos de diversa complexidade. En ambos os casos, tamén é posible executar o exampficheiros cunha configuración file contén propiedades adicionais para unha maior personalización do lado do cliente.
Modo básico
No modo básico, as métricas e os seus metadatos transmítense por separado. Para iso, o cliente escoita cada tema de Kafka dispoñible para o acceso externo e simplemente imprime as mensaxes recibidas na consola.
Para comezar a execución do examples, executa:
./build.sh run-basic –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME
onde ACCOUNT_SHORTNAME é o nome curto da conta da que queres obter as métricas.
Para finalizar a execución do example, preme Ctrl + C. (Pode haber un lixeiro atraso antes de que se deteña a execución porque o cliente espera un evento de tempo de espera.)
Modo avanzado
NOTA: As métricas móstranse só para monitores HTTP que se executan no Centro de control.
A execución en modo avanzado mostra a correlación entre as métricas e as mensaxes de metadatos. Isto é posible grazas á presenza en cada mensaxe de métricas dun campo de ID de fluxo que fai referencia á mensaxe de metadatos correspondente.
Para executar o examples, executa:
./build.sh run-advanced –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME
onde ACCOUNT_SHORTNAME é o nome curto da conta da que queres obter as métricas.
Para finalizar a execución do example, preme Ctrl + C. (Pode haber un lixeiro atraso antes de que se deteña a execución porque o cliente espera un evento de tempo de espera.)
Configuración adicional
É posible executar o exampficheiros con configuración adicional do cliente mediante o –config-file opción seguida de a file nome que contén propiedades na forma clave=valor.
./build.sh run-advanced \
–kafka-brokers localhost:9092 \
–conta ACCOUNT_SHORTNAME \
-config-file client_config.properties

NOTA: Todos fileOs referenciados no comando anterior deben estar situados no directorio actual e referidos só usando camiños relativos. Isto aplícase tanto a –config-file argumento e a todas as entradas da configuración file que describen file localizacións.
Validación da autenticación de cliente externo
Para validar a autenticación do cliente desde fóra do Centro de control mediante client-examples, realice os seguintes pasos:

• Desde o cartafol do Centro de control de Paragon Active Assurance, cambie ao paa-streaming-api-clientexampcartafol les:
  cd paa-streaming-api-client-examples
• Copie o certificado raíz da CA ca-cert no directorio actual.
• Crear un cliente.propiedades file co seguinte contido:
  security.protocol=SASL_SSL
  ssl.ca.location=ca-cert
  sasl.mechanism=PLAIN
  sasl.username={CLIENT_USER}
  sasl.password={CLIENT_PASSWORD}
  onde {CLIENT_USER} e {CLIENT_PASSWORD} son as credenciais de usuario do cliente.
• Executar básico examples:
  exportar KAFKA_FQDN=
  ./build.sh run-basic –kafka-brokers ${KAFKA_FQDN}:9093 \
  –conta ACCOUNT_SHORTNAME
  -config-file cliente.propiedades
  onde ACCOUNT_SHORTNAME é o nome curto da conta da que queres obter as métricas.
• Executar avanzado examples:
  exportar KAFKA_FQDN=
  ./build.sh run-advanced –kafka-brokers ${KAFKA_FQDN}:9093 \
  –conta ACCOUNT_SHORTNAME
  -config-file cliente.propiedades

Apéndice
Neste apéndice describimos como crear:

• un almacén de claves file para almacenar o certificado SSL do corredor Kafka
• unha tenda de confianza file para almacenar o certificado raíz da Autoridade de Certificación (CA) usado para asinar o certificado do corredor de Kafka.

Creando un certificado de Kafka Broker
Crear un certificado usando unha autoridade de certificación real (recomendado)
Recoméndase obter un certificado SSL real dunha CA de confianza.
Unha vez que teña decidido unha CA, copie o seu certificado raíz de CA ca-cert file ao teu propio camiño como se mostra a continuación:
exportar CA_PATH=~/my-ca
mkdir ${CA_PATH}
cp ca-cert ${CA_PATH}
Crea a túa propia autoridade de certificación
NOTA: Normalmente deberías ter o teu certificado asinado por unha autoridade de certificación real; ver a subsección anterior. O que segue é só un example.
Aquí creamos o noso propio certificado raíz de Autoridade de Certificación (CA). file válido durante 999 días (non recomendado en produción):
# Crea un directorio para almacenar a CA
exportar CA_PATH=~/my-ca
mkdir ${CA_PATH}
# Xera o certificado CA
openssl req -new -x509 -keyout ${CA_PATH}/ca-key -out ${CA_PATH}/ca-cert -days 999

Creando o almacén de confianza do cliente
Agora podes crear unha tenda de confianza file que contén o ca-cert xerado anteriormente. Isto file será necesario polo cliente de Kafka que accederá á API de transmisión:

keytool -keystore kafka.client.truststore.jks \
-alias CARoot \
-importcert -file ${CA_PATH}/ca-cert

Agora que o certificado da CA está no almacén de confianza, o cliente confiará en calquera certificado asinado con el.
Debería copiar o file kafka.client.truststore.jks a unha localización coñecida no seu ordenador cliente e apunte a ela na configuración.
Creando o almacén de claves para Kafka Broker
Para xerar o certificado SSL do intermediario de Kafka e despois o almacén de claves kafka.server.keystore.jks, proceda do seguinte xeito:
Xeración do certificado SSL
Abaixo, 999 é o número de días de validez do almacén de claves e FQDN é o nome de dominio totalmente cualificado do cliente (nome de host público do nodo).
NOTA: É importante que o FQDN coincida co nome de host exacto que usará o cliente Kafka para conectarse ao Centro de control.
sudo mkdir -p /var/ssl/private
sudo chown -R $USER: /var/ssl/private
cd /var/ssl/private
exportar FQDN=
keytool -keystore kafka.server.keystore.jks \
-servidor alias\
-validez 999 \
-genkey -keyalg RSA -ext SAN=dns:${FQDN}
Crea unha solicitude de sinatura de certificado e gárdaa no ficheiro file nomeada solicitude-cert-server-request:
keytool -keystore kafka.server.keystore.jks \
-servidor alias\
-certreq \
-file solicitude-cert-server-request

Agora deberías enviar o file cert-server-request á súa autoridade de certificación (CA) se está a usar un real. Despois devolverán o certificado asinado. Referirémonos a isto como asinado polo servidor de certificados a continuación.
Asinando o certificado SSL usando un certificado de CA de creación propia
NOTA: De novo, non se recomenda usar a túa propia CA nun sistema de produción.
Asina o certificado usando a CA mediante o file cert-server-request, que produce o certificado asinado cert-server-signed. Ver abaixo; ca-password é o contrasinal definido ao crear o certificado 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 \
-días 999 -CAcreateserial \
-passin pass:{ca-contrasinal}

Importando o certificado asinado no Keystore
Importe o certificado raíz ca-cert no almacén de claves:
keytool -keystore kafka.server.keystore.jks \
-alias ca-cert \
-importar \
-file ${CA_PATH}/ca-cert
Importe o certificado asinado denominado cert-server-signed:
keytool -keystore kafka.server.keystore.jks \
-servidor alias\
-importar \
-file asinado-cert-server
O file kafka.server.keystore.jks debe ser copiado nunha localización coñecida no servidor do Centro de control, e logo referido en /etc/kafka/server.properties.

Usando a API de streaming

Xeral
A API de streaming obtén tanto datos de proba como de monitor. Non é posible sinalar unha destas categorías.
A API de streaming non obtén datos das probas baseadas en guións (as representadas por un rectángulo en lugar dunha peza de rompecabezas na GUI do Centro de control), como as probas de activación do servizo Ethernet e as probas de transparencia.

Nomes dos temas de Kafka
Os nomes dos temas de Kafka para a API de transmisión son os seguintes, onde %s é o nome curto da conta do Centro de control (indicado ao crear a conta):

const (
exporterName = "kafka"
metadataTopicTpl = “paa.public.accounts.%s.metadata”
metricsTopicTpl = “paa.public.accounts.%s.metrics”
)

Exampficheiros de Uso da API de streaming
O exampOs ficheiros que seguen atópanse no tarball paa-streaming-api-client-examples.tar.gz contida no tarball do Centro de control.
En primeiro lugar, hai un ex básicoample que demostra como as métricas e os seus metadatos se transmiten por separado e simplemente imprimen as mensaxes recibidas na consola. Pode executalo do seguinte xeito:
sudo ./build.sh run-basic –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME
Tamén hai un ex máis avanzadoample onde as métricas e as mensaxes de metadatos están correlacionadas. Use este comando para executalo:
sudo ./build.sh run-advanced –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME
Debe usar sudo para executar comandos de Docker como os anteriores. Opcionalmente, pode seguir os pasos posteriores á instalación de Linux para poder executar os comandos de Docker sen sudo. Para obter máis información, vai a docs.docker.com/engine/install/linux-postinstall.

Juniper Networks, o logotipo de Juniper Networks, Juniper e Junos son marcas rexistradas de Juniper Networks, Inc. nos Estados Unidos e noutros países. Todas as outras marcas comerciais, marcas de servizo, marcas rexistradas ou marcas de servizo rexistradas son propiedade dos seus respectivos propietarios. Juniper Networks non asume ningunha responsabilidade por calquera imprecisión neste documento. Juniper Networks resérvase o dereito de cambiar, modificar, transferir ou revisar esta publicación sen previo aviso. Copyright © 2023 Juniper Networks, Inc. Todos os dereitos reservados.

Documentos/Recursos

API de transmisión de Juniper NETWORKS Active Assurance [pdfGuía do usuario Streaming API Active Assurance, API Active Assurance, Active Assurance, Assurance

Referencias

• Manual de usuario