Guide de l'utilisateur de l'API Juniper Streaming

Ce guide décrit comment extraire des données de Paragon Active Assurance via l'API de diffusion en continu du produit.
L'API ainsi que le client de streaming sont inclus dans l'installation de Paragon Active Assurance.
Cependant, un peu de configuration est nécessaire avant de pouvoir utiliser l'API. Ceci est traité dans le chapitre "Configuration de l'API de streaming" à la page 1.

Surview

Ce chapitre décrit comment configurer l'API Streaming pour permettre l'abonnement aux messages de métriques via Kafka.
Ci-dessous, nous allons passer par:

Comment activer l'API de diffusion en continu
Comment configurer Kafka pour écouter les clients externes
Comment configurer Kafka pour utiliser les ACL et configurer le cryptage SSL pour lesdits clients

Qu'est-ce que Kafka ?

Kafka est une plate-forme de streaming d'événements qui permet la capture en temps réel des données envoyées à partir de diverses sources d'événements (capteurs, bases de données, appareils mobiles) sous la forme de flux d'événements, ainsi que le stockage durable de ces flux d'événements pour une récupération et une manipulation ultérieures.
Avec Kafka, il est possible de gérer le streaming d'événements de bout en bout de manière distribuée, hautement évolutive, élastique, tolérante aux pannes et sécurisée.
NOTE: Kafka peut être configuré de différentes manières et a été conçu pour l'évolutivité et les systèmes redondants. Ce document se concentre uniquement sur la façon de le configurer pour utiliser la fonctionnalité API de streaming trouvée dans Paragon Active Assurance Control Center. Pour des configurations plus avancées, nous nous référons à la documentation officielle de Kafka : kafka.apache.org/26/documentation.html.

Terminologie

Kafka : plate-forme de diffusion d'événements.
Sujet Kafka : Collection d'événements.
Abonné/consommateur Kafka : composant responsable de la récupération des événements stockés dans un sujet Kafka.
Broker Kafka : serveur de la couche de stockage d'un cluster Kafka.
SSL/TLS : SSL est un protocole sécurisé développé pour envoyer des informations en toute sécurité sur Internet. TLS est le successeur de SSL, introduit en 1999.
SASL : Framework qui fournit des mécanismes pour l'authentification des utilisateurs, la vérification de l'intégrité des données et le chiffrement.
Abonné à l'API de streaming : composant responsable de la récupération des événements stockés dans les sujets définis dans Paragon Active Assurance et destinés à un accès externe.
Autorité de certification : entité de confiance qui émet et révoque les certificats de clé publique.
Certificat racine de l'autorité de certification : certificat de clé publique qui identifie une autorité de certification.

Fonctionnement de l'API de diffusion en continu

Comme mentionné précédemment, l'API Streaming permet aux clients externes de récupérer des informations sur les métriques de Kafka.
Toutes les métriques collectées par les agents de test lors d'une tâche de test ou de surveillance sont envoyées au service Stream.
Après une phase de traitement, le service Stream publie ces métriques sur Kafka avec des métadonnées supplémentaires.

Sujets Kafka

Kafka a le concept de sujets sur lesquels toutes les données sont publiées. Dans Paragon Active Assurance, de nombreux sujets Kafka sont disponibles ; cependant, seul un sous-ensemble d'entre eux est destiné à un accès externe.
Chaque compte Paragon Active Assurance dans Control Center comporte deux rubriques dédiées. Ci-dessous, ACCOUNT est le nom abrégé du compte :

paa.public.accounts.{ACCOUNT}.metrics
Tous les messages de métriques pour le compte donné sont publiés dans ce sujet
De grandes quantités de données
Fréquence de mise à jour élevée
paa.public.accounts.{ACCOUNT}.metadata
Contient des métadonnées liées aux données de métriques, par exempleample test, le moniteur ou l'agent de test associé aux métriques
Petites quantités de données
Fréquence de mise à jour faible

Activation de l'API de diffusion en continu

NOTE: Ces instructions doivent être exécutées sur le serveur Control Center à l'aide de sudo.
Étant donné que l'API de diffusion en continu ajoute une surcharge au centre de contrôle, elle n'est pas activée par défaut. Pour activer l'API, il faut d'abord activer la publication des métriques vers Kafka dans la configuration principale file:

/etc/netrounds/netrounds.conf
KAFKA_METRICS_ENABLED = Vrai
AVERTISSEMENT: L'activation de cette fonctionnalité peut avoir un impact sur les performances du Control Center. Assurez-vous d'avoir dimensionné votre instance en conséquence.
Ensuite, pour activer le transfert de ces métriques vers les bons sujets Kafka :
/etc/netrounds/metrics.yaml
streaming-api : vrai

Pour activer et démarrer les services de l'API Streaming, exécutez :
Les services sudo ncc activent les métriques timescaledb Les services sudo ncc démarrent les métriques timescaledb
Enfin, redémarrez les services :
redémarrage des services sudo ncc

Vérifier que l'API de diffusion en continu fonctionne dans le centre de contrôle

NOTE: Ces instructions doivent être exécutées sur le serveur Control Center.
Vous pouvez maintenant vérifier que vous recevez des métriques sur les bons sujets Kafka. Pour ce faire, installez l'utilitaire kafkacat :
sudo apt-get mise à jour sudo apt-get install kafkacat
Si vous avez un test ou un moniteur en cours d'exécution dans Control Center, vous devriez pouvoir utiliser kafkacat pour recevoir des métriques et des métadonnées sur ces sujets.
Remplacez myaccount par le nom court de votre compte (c'est ce que vous voyez dans votre Control Center URL):
exporter METRICS_TOPIC=paa.public.accounts.myaccount.metrics
exporter METADATA_TOPIC=paa.public.accounts.myaccount.metadata
Vous devriez maintenant voir les métriques en exécutant cette commande :
kafkacat -b ${KAFKA_FQDN}:9092 -t ${METRICS_TOPIC} -C -e
À view metadata, exécutez la commande suivante (notez que cela ne sera pas mis à jour aussi fréquemment) :
kafkacat -b ${KAFKA_FQDN}:9092 -t ${METADATA_TOPIC} -C -e
NOTE:
kafkacat"Client Exampfichiers” à la page 14
Cela vérifie que nous avons une API de streaming fonctionnelle depuis Control Center. Cependant, vous êtes probablement plutôt intéressé par l'accès aux données d'un client externe. La section suivante décrit comment ouvrir Kafka pour un accès externe.

Ouverture de Kafka pour les hôtes externes

NOTE: Ces instructions doivent être exécutées sur le serveur Control Center.
Par défaut, Kafka s'exécutant sur le Control Center est configuré pour n'écouter que sur localhost pour un usage interne.
Il est possible d'ouvrir Kafka pour des clients externes en modifiant les paramètres de Kafka.
Se connecter à Kafka : mises en garde
PRUDENCE: Veuillez lire ceci attentivement, car il est facile de rencontrer des problèmes de connexion avec Kafka si vous n'avez pas compris ces concepts.
Dans la configuration du centre de contrôle décrite dans ce document, il n'y a qu'un seul courtier Kafka.
Cependant, notez qu'un courtier Kafka est censé fonctionner dans le cadre d'un cluster Kafka qui peut être composé de nombreux courtiers Kafka.
Lors de la connexion à un courtier Kafka, une connexion initiale est établie par le client Kafka. Sur cette connexion, le courtier Kafka renverra à son tour une liste « d'auditeurs annoncés », qui est une liste d'un ou plusieurs courtiers Kafka.
A la réception de cette liste, le client Kafka se déconnectera, puis se reconnectera à l'un de ces listeners annoncés. Les écouteurs annoncés doivent contenir des noms d'hôte ou des adresses IP accessibles au client Kafka, sinon le client ne parviendra pas à se connecter.
Si le cryptage SSL est utilisé, impliquant un certificat SSL lié à un nom d'hôte particulier, il est encore plus important que le client Kafka reçoive l'adresse correcte à laquelle se connecter, sinon la connexion peut être rejetée.
En savoir plus sur les auditeurs de Kafka ici : www.confluent.io/blog/kafka-listeners-explained
Cryptage SSL/TLS
Pour nous assurer que seuls les clients de confiance sont autorisés à accéder à Kafka et à l'API Streaming, nous devons configurer les éléments suivants :

Authentification : les clients doivent fournir un nom d'utilisateur et un mot de passe via une connexion sécurisée SSL/TLS entre le client et Kafka.
Autorisation : les clients authentifiés peuvent effectuer des tâches réglementées par les ACL.
Voici un overview:

*) Authentification par nom d'utilisateur/mot de passe effectuée sur un canal crypté SSL
Pour bien comprendre le fonctionnement du chiffrement SSL/TLS pour Kafka, veuillez vous référer à la documentation officielle : docs.confluent.io/platform/current/kafka/encryption.html
Certificat SSL/TLS surview
NOTE: Dans cette sous-section, nous utiliserons la terminologie suivante :
Certificat : certificat SSL signé par une autorité de certification (CA). Chaque courtier Kafka en a un.
Magasin de clés : Le magasin de clés file qui stocke le certificat. Le magasin de clés file contient la clé privée du certificat ; par conséquent, il doit être conservé en toute sécurité.
Truststore : A file contenant les certificats CA de confiance.
Pour configurer l'authentification entre un client externe et Kafka s'exécutant dans Control Center, les deux parties doivent disposer d'un magasin de clés défini avec un certificat associé signé par une autorité de certification (AC) avec le certificat racine de l'AC.
En plus de cela, le client doit également disposer d'un truststore avec le certificat racine de l'autorité de certification.
Le certificat racine de l'autorité de certification est commun au courtier Kafka et au client Kafka.
Création des certificats requis
Ceci est couvert dans l'« Annexe » à la page 17.
Configuration SSL/TLS du courtier Kafka dans le centre de contrôle
NOTE: Ces instructions doivent être exécutées sur le serveur Control Center.
NOTE: Avant de continuer, vous devez créer le keystore qui contient le certificat SSL en suivant les instructions de la section « Annexe » à la page 17. Les chemins mentionnés ci-dessous sont issus de ces instructions.
Le magasin de clés SSL est un file stocké sur disque avec le file extension .jks.
Une fois que vous disposez des certificats requis créés pour le courtier Kafka et le client Kafka, vous pouvez continuer en configurant le courtier Kafka exécuté dans Control Center. Vous devez connaître les éléments suivants :

: Le nom d'hôte public de Control Center ; cela doit pouvoir être résolu et accessible par les clients Kafka.
: Le mot de passe du magasin de clés fourni lors de la création du certificat SSL.
et : Il s'agit des mots de passe que vous souhaitez définir respectivement pour l'administrateur et l'utilisateur client.
Notez que vous pouvez ajouter plus d'utilisateurs, comme indiqué dans l'example.
Modifiez ou ajoutez (avec un accès sudo) les propriétés ci-dessous dans /etc/kafka/server.properties, en insérant les variables ci-dessus comme indiqué :

AVERTISSEMENT: Ne supprimez pas PLAINTEXT://localhost:9092 ; cela interrompra la fonctionnalité du centre de contrôle car les services internes ne pourront pas communiquer.
…# Les adresses sur lesquelles le courtier Kafka écoute.
auditeurs=PLAINTEXT://localhost:9092,SASL_SSL://0.0.0.0:9093
# Ce sont les hôtes annoncés à tout client se connectant.
advertising.listeners=PLAINTEXT://localhost:9092,SASL_SSL:// :9093…
####### CONFIG PERSONNALISÉE
# CONFIGURATION SSL
ssl.endpoint.identification.algorithm=
ssl.keystore.location=/var/ssl/private/kafka.server.keystore.jks
ssl.keystore.password=
ssl.key.password=
ssl.client.auth=aucun
ssl.protocol=TLSv1.2
# Configuration SASL sasl.enabled.mechanisms=PLAIN
listener.name.sasl_ssl.plain.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginMo dule requis \ username= »admin » \ password= » ”\user_admin=” ”\client_utilisateur=” ”; # REMARQUE plus d'utilisateurs peuvent être ajoutés avec user_ =
# Autorisation, activez les ACL allower.class.name=kafka.security.authorizer.AclAuthorizer super.users=User:admin
Configuration des listes de contrôle d'accès (ACL)
Activer les ACL sur localhost
AVERTISSEMENT: Nous devons d'abord configurer les ACL pour localhost, afin que Control Center lui-même puisse toujours accéder à Kafka. Si cela n'est pas fait, les choses vont se casser.
######### Entrées ACL pour les utilisateurs anonymes
/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 –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 '*'
Nous devons ensuite activer les ACL pour l'accès externe en lecture seule, afin que les utilisateurs externes soient autorisés à lire les sujets paa.public.*.
NOTE: Pour un contrôle plus précis, veuillez vous référer à la documentation officielle de Kafka.
######### Entrées ACL pour les utilisateurs externes
/usr/lib/kafka/bin/kafka-acls.sh \
–authorizer kafka.security.authorizer.AclAuthorizer \–authorizer-properties zookeeper.connect=localhost:2181 \
–add –allow-principal Utilisateur :* –opération lire –opération décrire \–groupe 'NCC'
/usr/lib/kafka/bin/kafka-acls.sh \
–autoriseur kafka.security.authorizer.AclAuthorizer \
–authorizer-properties zookeeper.connect=localhost:2181 \
–add –allow-principal Utilisateur :* –opération lire –opération décrire \
–sujet paa.public. –resource-pattern-type préfixé
Une fois cela fait, vous devez redémarrer les services :
redémarrage des services sudo ncc
Pour vérifier qu'un client peut établir une connexion sécurisée, exécutez la commande suivante sur un ordinateur client externe (pas sur le serveur Control Center). Ci-dessous, PUBLIC_HOSTNAME est le nom d'hôte du centre de contrôle :
openssl s_client -debug -connect ${PUBLIC_HOSTNAME}:9093 -tls1_2 | grep « La renégociation sécurisée est prise en charge »
Dans la sortie de la commande, vous devriez voir le certificat du serveur ainsi que les éléments suivants :
Prise en charge du SI de renégociation sécurisée
Pour vous assurer que les services internes ont été autorisés à accéder au serveur Kafka, veuillez vérifier le journal suivantfiles:

Validation de la connectivité du client externe

chat kafka
NOTE: Ces instructions doivent être exécutées sur un ordinateur client (pas sur le serveur Control Center).
NOTE: Pour afficher les informations sur les métriques, assurez-vous qu'au moins un moniteur est en cours d'exécution dans Control Center.
Pour vérifier et valider la connectivité en tant que client externe, il est possible d'utiliser l'utilitaire kafkacat qui a été installé dans la section "Vérifier que l'API de streaming fonctionne dans Control Center" à la page 4.
Procédez comme suit :
NOTE: Ci-dessous, CLIENT_USER est l'utilisateur précédemment spécifié dans le file /etc/kafka/server.properties dans
Centre de contrôle : à savoir, user_client et le mot de passe qui y est défini.
Le certificat racine CA utilisé pour signer le certificat SSL côté serveur doit être présent sur le client.

Créer un file client.properties avec le contenu suivant :
security.protocol=SASL_SSL
ssl.ca.location={PATH_TO_CA_CERT}
sasl.mechanisms=PLAIN
sasl.username={CLIENT_USER}
sasl.password={CLIENT_PASSWORD} où
• {PATH_TO_CA_CERT} est l'emplacement du certificat racine de l'autorité de certification utilisé par le courtier Kafka
• {CLIENT_USER} et {CLIENT_PASSWORD} sont les informations d'identification de l'utilisateur pour le client.
• Exécutez la commande suivante pour voir le message consommé par kafkacat :
exporter KAFKA_FQDN=
exporter METRICS_TOPIC=paa.public.accounts. .métrique
kafkacat -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -e
où {METRICS_TOPIC} est le nom du sujet Kafka avec le préfixe "paa.public.".

NOTE: Les anciennes versions de kafkacat ne fournissent pas l'option -F pour lire les paramètres du client à partir d'un file. Si vous utilisez une telle version, vous devez fournir les mêmes paramètres à partir de la ligne de commande, comme indiqué ci-dessous.
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
Pour déboguer la connectivité, vous pouvez utiliser l'option -d :
Déboguer les communications grand public
kafkacat -d consommateur -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -e
# Déboguer les communications du courtier
kafkacat -d courtier -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -e
Assurez-vous de vous référer à la documentation de la bibliothèque cliente Kafka utilisée, car les propriétés peuvent différer de celles de client.properties.

Format du message

Les messages utilisés pour les rubriques de métriques et de métadonnées sont sérialisés au format Protocol buffers (protobuf) (voir développeurs.google.com/protocol-buffers). Les schémas de ces messages respectent le format suivant :
Schéma Protobuf des métriques
syntaxe = "proto3" ; importer "google/protobuf/timestamp.proto"; package paa.streamingapi ; option go_package = ".;paa_streamingapi" ; message Métriques { google.protobuf.Timestamp foisamp = 1 ; carte valeurs = 2 ; int32 mesure_id = 3 ; } /** * Une valeur de métrique peut être un entier ou un flottant. */
message MetricValue { oneof type { int64 int_val = 1; float float_val = 2 ; } }
Schéma Protobuf des métadonnées
syntaxe = "proto3" ; package paa.streamingapi ; option go_package = ".;paa_streamingapi" ; message Métadonnées { int32 measure_id = 1 ; chaîne nom_mesure = 2 ; carte tags = 13 ; }

Ex clientamples

NOTE: Ces commandes sont destinées à s'exécuter sur un client externe, par examplevez votre ordinateur portable ou similaire, et non dans Control Center.
NOTE: Pour afficher les informations de mesure, assurez-vous qu'au moins un moniteur est en cours d'exécution dans Control Center.
L'archive tar du Control Center inclut l'archive paa-streaming-api-client-examples.tar.gz (ex-clientamples), qui contient un example script Python montrant comment utiliser l'API Streaming.
Installation et configuration de Client Examples
Vous trouvez client-exampfichiers dans le dossier Paragon Active Assurance Control Center :
exporter CC_VERSION=3.3.1
cd ./paa-control-center_${CC_VERSION} ls paa-streaming-api-client-examples*
Pour installer client-exampsur votre ordinateur client externe, procédez comme suit :
# Créer un répertoire pour extraire le contenu du client examples tarball mkdir paa-streaming-api-client-examples
# Extraire le contenu du client examples tarball tar xzf paa-streaming-api-client-examples.tar.gz -C paa-streaming-api-client-examples
# Allez dans le répertoire nouvellement créé cd paa-streaming-api-client-examples client-examples fichiers nécessitent Docker pour s'exécuter. Les téléchargements et les instructions d'installation de Docker sont disponibles sur https://docs.docker.com/engine/install.
Utilisation du client Examples
L'ex-clientamples outils peuvent s'exécuter en mode de base ou avancé pour créer des exampfichiers de complexité variable. Dans les deux cas, il est également possible d'exécuter l'exampfichiers avec une configuration file contenant des propriétés supplémentaires pour une personnalisation plus poussée du côté client.
Mode de base En mode de base, les métriques et leurs métadonnées sont diffusées séparément. À cette fin, le client écoute chaque sujet Kafka disponible pour un accès externe et imprime simplement les messages reçus sur la console.
Pour démarrer l'exécution de l'ex de baseampfichiers, exécutez : ./build.sh run-basic –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME
où ACCOUNT_SHORTNAME est le nom abrégé du compte dont vous souhaitez obtenir les statistiques.
Pour mettre fin à l'exécution de l'example, appuyez sur Ctrl + C. (Il peut y avoir un léger délai avant que l'exécution ne s'arrête car le client attend un événement de temporisation.)
Mode avancé
NOTE: Les métriques sont affichées uniquement pour les moniteurs HTTP exécutés dans Control Center.
L'exécution en mode avancé montre la corrélation entre les métriques et les messages de métadonnées. Ceci est possible grâce à la présence dans chaque message de métrique d'un champ stream id qui fait référence au message de métadonnées correspondant.
Pour exécuter l'ex avancéamples, exécutez : ./build.sh run-advanced –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME où ACCOUNT_SHORTNAME est le nom abrégé du compte dont vous souhaitez obtenir les métriques.
Pour mettre fin à l'exécution de l'example, appuyez sur Ctrl + C. (Il peut y avoir un léger délai avant que l'exécution ne s'arrête car le client attend un événement de temporisation.)
Paramètres supplémentaires
Il est possible d'exécuter l'exampfichiers avec une configuration supplémentaire du client à l'aide de –config-file option suivie d'un file nom contenant les propriétés sous la forme clé=valeur.
./build.sh run-advanced \ –kafka-brokers localhost:9092 \ –account ACCOUNT_SHORTNAME \ –config-file client_config.propriétés
NOTE: Tous fileLes s référencés dans la commande ci-dessus doivent être situés dans le répertoire actuel et référencés uniquement à l'aide de chemins relatifs. Ceci s'applique à la fois au –config-file argument et à toutes les entrées de la configuration file qui décrivent file emplacements.
Validation de l'authentification du client externe
Pour valider l'authentification client depuis l'extérieur du centre de contrôle à l'aide de client-exampfichiers, effectuez les étapes suivantes :

Dans le dossier Paragon Active Assurance Control Center, basculez vers paa-streaming-api-clientexampdossier les :
cd paa-streaming-api-client-examples
Copiez le certificat racine de l'autorité de certification ca-cert dans le répertoire en cours.
Créer un client.propriétés file avec le contenu suivant :
security.protocol=SASL_SSL
ssl.ca.location=ca-certificat
sasl.mechanism=PLAIN
sasl.username={CLIENT_USER}
sasl.password={CLIENT_PASSWORD}
où {CLIENT_USER} et {CLIENT_PASSWORD} sont les informations d'identification de l'utilisateur pour le client.
Exécutez l'ex de baseamples:
exporter KAFKA_FQDN= ./build.sh run-basic –kafka-brokers ${KAFKA_FQDN}:9093 \ –account ACCOUNT_SHORTNAME
–config-file client.properties où ACCOUNT_SHORTNAME est le nom abrégé du compte dont vous souhaitez obtenir les métriques.
Exécuter l'ex avancéamples:
exporter KAFKA_FQDN= ./build.sh run-advanced –kafka-brokers ${KAFKA_FQDN}:9093 \ –account ACCOUNT_SHORTNAME–config-file client.propriétés

Appendice

Dans cette annexe, nous décrivons comment créer :

un magasin de clés file pour stocker le certificat SSL du courtier Kafka
un truststore file pour stocker le certificat racine de l'autorité de certification (CA) utilisé pour signer le certificat du courtier Kafka.

Création d'un certificat Kafka Broker
Création d'un certificat à l'aide d'une véritable autorité de certification (recommandé)
Il est recommandé d'obtenir un véritable certificat SSL auprès d'une autorité de certification de confiance.
Une fois que vous avez choisi une autorité de certification, copiez son certificat racine d'autorité de certification ca-cert file à votre propre chemin comme indiqué ci-dessous :
export CA_PATH=~/my-ca mkdir ${CA_PATH} cp ca-cert ${CA_PATH}
Créez votre propre autorité de certification
NOTE: Normalement, vous devriez faire signer votre certificat par une véritable autorité de certification ; voir la sous-section précédente. Ce qui suit n'est qu'un example.
Ici, nous créons notre propre certificat racine d'autorité de certification (CA) file valable 999 jours (non recommandé en production):
# Créer un répertoire pour stocker l'exportation CA CA_PATH=~/my-ca mkdir ${CA_PATH}
# Générer le certificat CA openssl req -new -x509 -keyout ${CA_PATH}/ca-key -out ${CA_PATH}/ca-cert -days 999
Création du magasin de confiance du client
Vous pouvez maintenant créer un truststore file qui contient le ca-cert généré ci-dessus. Ce file seront nécessaires au client Kafka qui accédera à l'API Streaming :
keytool -keystore kafka.client.truststore.jks \ -alias CARoot \ -importcert -file ${CA_PATH}/ca-certificat
Maintenant que le certificat CA est dans le truststore, le client fera confiance à tout certificat signé avec lui.
Vous devriez copier le file kafka.client.truststore.jks vers un emplacement connu sur votre ordinateur client et pointez dessus dans les paramètres.
Création du magasin de clés pour le courtier Kafka
Pour générer le certificat SSL Kafka broker puis le keystore kafka.server.keystore.jks, procédez comme suit :
Génération du certificat SSL
Ci-dessous, 999 est le nombre de jours de validité du keystore, et FQDN est le nom de domaine complet du client (nom d'hôte public du nœud).
NOTE: Il est important que le nom de domaine complet corresponde au nom d'hôte exact que le client Kafka utilisera pour se connecter au centre de contrôle. sudo mkdir -p /var/ssl/privé
sudo chown -R $USER : /var/ssl/private cd /var/ssl/private export FQDN=
keytool -keystore kafka.server.keystore.jks \ -alias serveur \ -validity 999 \ -genkey -keyalg RSA -ext SAN=dns:${FQDN}
Créez une demande de signature de certificat et stockez-la dans le file nommé cert-server-request :
keytool -keystore kafka.server.keystore.jks \ -alias serveur \ -certreq \ -file demande de serveur de certificat
Vous devez maintenant envoyer le file cert-server-request à votre autorité de certification (CA) si vous en utilisez une réelle. Il vous retournera ensuite le certificat signé. Nous y ferons référence comme cert-server-signed ci-dessous. Signature du certificat SSL à l'aide d'un certificat CA auto-créé
NOTE: Encore une fois, l'utilisation de votre propre autorité de certification n'est pas recommandée dans un système de production. Signez le certificat à l'aide de l'AC au moyen du file cert-server-request, qui produit le certificat signé cert-server-signed. Voir ci-dessous; ca-password est le mot de passe défini lors de la création du certificat 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 :{ca-password}
Importation du certificat signé dans le keystore
Importez le certificat racine ca-cert dans le magasin de clés :
keytool -keystore kafka.server.keystore.jks \ -alias ca-cert \ -import \ -file ${CA_PATH}/ca-certificat
Importez le certificat signé appelé cert-server-signed :
keytool -keystore kafka.server.keystore.jks \ -alias serveur \ -import \ -file cert-serveur-signé
Le file kafka.server.keystore.jks doit être copié dans un emplacement connu sur le serveur Control Center, puis référencé dans /etc/kafka/server.properties.
Utilisation de l'API de diffusion en continu

Général

L'API de streaming récupère à la fois les données de test et de surveillance. Il n'est pas possible de distinguer une de ces catégories.
L'API de diffusion en continu ne récupère pas les données des tests basés sur des scripts (ceux représentés par un rectangle au lieu d'une pièce de puzzle dans l'interface graphique du centre de contrôle), tels que les tests d'activation de service Ethernet et les tests de transparence.
Noms de sujet Kafka
Les noms de sujet Kafka pour l'API de streaming sont les suivants, où %s est le nom court du contrôle
Compte central (indiqué lors de la création du compte) :
const (exporterName = "kafka"metadataTopicTpl = "paa.public.accounts.%s.metadata" metricsTopicTpl = "paa.public.accounts.%s.metrics")
ExampUtilisation de l'API Streaming
L'exampLes chiers qui suivent se trouvent dans le tarball paa-streaming-api-client-examples.tar.gz contenu dans l'archive tar du Control Center.
Tout d'abord, il y a un ex de baseample démontrant comment les métriques et leurs métadonnées sont diffusées séparément et impriment simplement les messages reçus sur la console. Vous pouvez l'exécuter comme suit : sudo ./build.sh run-basic –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME
Il y a aussi un ex plus avancéampfichier où les métriques et les messages de métadonnées sont corrélés. Utilisez cette commande pour l'exécuter :
sudo ./build.sh run-advanced –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME Vous devez utiliser sudo pour exécuter des commandes Docker telles que celles ci-dessus. En option, vous pouvez suivre les étapes de post-installation de Linux pour pouvoir exécuter des commandes Docker sans sudo.
Pour plus de détails, rendez-vous sur docs.docker.com/engine/install/linux-postinstall.
Juniper Networks, le logo Juniper Networks, Juniper et Junos sont des marques déposées de Juniper Networks, Inc. aux États-Unis et dans d'autres pays. Toutes les autres marques commerciales, marques de service, marques déposées ou marques de service déposées sont la propriété de leurs propriétaires respectifs. Juniper Networks n'assume aucune responsabilité pour les éventuelles inexactitudes contenues dans ce document. Juniper Networks se réserve le droit de changer, modifier, transférer ou réviser de toute autre manière cette publication sans préavis. Copyright © 2022 Juniper Networks, Inc. Tous droits réservés.

Documents / Ressources

API de flux Juniper [pdf] Guide de l'utilisateur
API de diffusion en continu, API

Références

Manuel d'utilisation

Introduction