Logiciel API de streaming Juniper NETWORKS

Informations sur le produit

Caractéristiques

• Nom du produit : Assurance active Paragon
• Version: 4.1
• Date de publication : 2023-03-15

Introduction:
Ce guide fournit des instructions sur la façon d'extraire des données de Paragon Active Assurance à l'aide de l'API de streaming du produit. Le client de streaming et l'API sont inclus dans l'installation de Paragon Active Assurance, mais une certaine configuration est requise avant d'utiliser l'API. Le processus de configuration est couvert dans la section « Configuration de l'API Streaming ».

Configuration de l'API Streaming :
Les étapes suivantes décrivent le processus de configuration de l'API de streaming :

Surview
Kafka est une plateforme de streaming d'événements conçue pour la capture et le stockage en temps réel de données provenant de diverses sources. Il permet la gestion des flux d'événements de manière distribuée, évolutive, tolérante aux pannes et sécurisée. Ce guide se concentre sur la configuration de Kafka pour utiliser la fonctionnalité API Streaming dans Paragon Active Assurance Control Center.

Terminologie
L'API Streaming permet aux clients externes de récupérer des informations de métriques auprès de Kafka. 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 traitement, le service Stream publie ces métriques sur Kafka ainsi que des métadonnées supplémentaires.

Activation de l'API de diffusion en continu
Pour activer l'API Streaming, procédez comme suit :

1. Exécutez les commandes suivantes sur le serveur Control Center à l'aide de sudo :

KAFKA_METRICS_ENABLED = True Les services sudo ncc activent les métriques timescaledb Les services sudo ncc démarrent les métriques timescaledb Le redémarrage des services sudo ncc

Vérifier que l'API Streaming fonctionne dans Control Center :
Pour vérifier que vous recevez des métriques sur les bons sujets Kafka :

1. Installez l'utilitaire kafkacat avec les commandes suivantes :
   sudo apt-get update
   sudo apt-get install kafkacat

2. Remplacez « mon compte » par le nom court de votre compte dans le champ
   Centre de contrôle URL:
   export METRICS_TOPIC=paa.public.accounts.myaccount.metrics
   export METADATA_TOPIC=paa.public.accounts.myaccount.metadata

3. Exécutez la commande suivante pour view métrique:
   kafkacat -b ${KAFKA_FQDN}:9092 -t ${METRICS_TOPIC} -C -e
   Note: La commande ci-dessus affichera les métriques.
4. À view métadonnées, exécutez la commande suivante :
   kafkacat -b ${KAFKA_FQDN}:9092 -t ${METADATA_TOPIC} -C -e

Note: La commande ci-dessus affichera les métadonnées, mais elle ne sera pas mise à jour aussi fréquemment.

Ex clientamples
Pour ex-clientampPour plus d'informations, reportez-vous à la page 14 du manuel d'utilisation.

FAQ (Foire aux questions)

• Q : Qu'est-ce que Paragon Active Assurance ?
  R : Paragon Active Assurance est un produit qui offre des fonctionnalités de surveillance et de test.
• Q : Qu'est-ce que l'API Streaming ?
  R : L'API Streaming est une fonctionnalité de Paragon Active Assurance qui permet aux clients externes de récupérer des informations de métriques auprès de Kafka.
• Q : Comment puis-je activer l'API Streaming ?
  R : Pour activer l'API Streaming, suivez les étapes décrites dans la section « Activation de l'API Streaming » du manuel d'utilisation.
• Q : Comment puis-je vérifier que l'API Streaming fonctionne ?
  R : Reportez-vous à la section « Vérifier que l'API Streaming fonctionne dans le Centre de contrôle » pour obtenir des instructions sur la façon de vérifier la fonctionnalité de l'API Streaming.

Introduction

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 couvert dans le chapitre « Configuration de l'API 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.
pr
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 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 update
• 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):

• export METRICS_TOPIC=paa.public.accounts.myaccount.metrics
• export 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 exécuté sur le Control Center est configuré pour écouter uniquement 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 cryptage 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: Un certificat SSL signé par une autorité de certification (CA). Chaque courtier Kafka en possède 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é.
Banque de confiance: UN 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 : Ce sont les 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 Control Center puisque 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.
• adverted.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
• nom d'utilisateur = "admin" \
• mot de passe = » "\
• utilisateur_admin = » "\
• utilisateur_client = » » ;
• # REMARQUE : plus d'utilisateurs peuvent être ajoutés avec user_ =
• # Autorisation, activer les ACL
• authoriser.class.name=kafka.security.authorizer.AclAuthorizer super.users=Utilisateur: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 le Control Center lui-même puisse toujours accéder à Kafka. Si cela n’est pas fait, les choses vont se briser.

• –autoriseur kafka.security.authorizer.AclAuthorizer \
• –authorizer-properties zookeeper.connect=localhost:2181 \
• –ajouter –autoriser-utilisateur principal : ANONYME –autoriser-hôte 127.0.0.1 –cluster
• /usr/lib/kafka/bin/kafka-acls.sh \
• –autoriseur kafka.security.authorizer.AclAuthorizer \
• –authorizer-properties zookeeper.connect=localhost:2181 \
• –ajouter –autoriser-utilisateur principal : ANONYME –autoriser-hôte 127.0.0.1 –sujet '*'
• /usr/lib/kafka/bin/kafka-acls.sh \
• –autoriseur kafka.security.authorizer.AclAuthorizer \
• –authorizer-properties zookeeper.connect=localhost:2181 \
• –add –allow-principal Utilisateur : ANONYME –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.*.

### Entrées ACL pour les utilisateurs anonymes /usr/lib/kafka/bin/kafka-acls.sh \

NOTE: Pour un contrôle plus précis, veuillez vous référer à la documentation officielle de Kafka.

• –autoriseur kafka.security.authorizer.AclAuthorizer \
• –authorizer-properties zookeeper.connect=localhost:2181 \
• –ajouter –autoriser l'utilisateur principal :* –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 \
• –ajouter –autoriser l'utilisateur principal :* –opération lire –opération décrire \ –sujet paa.public. –préfixe de type de modèle de ressource

Une fois cela fait, vous devez redémarrer les services :

### Entrées ACL pour les utilisateurs externes /usr/lib/kafka/bin/kafka-acls.sh \

• 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 serveur externe.
ordinateur client (pas sur le serveur Control Center). Ci-dessous, PUBLIC_HOSTNAME est le nom d'hôte du Control Center :

• 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:

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

Validation de la connectivité du client externe

chat kafka

NOTE: Ces instructions sont à exécuter sur un poste client (et non 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 Control Center : à 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 utilisateur du 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";
• paquet paa.streamingapi ;
• option go_package = « .;paa_streamingapi » ;
• message Métriques {
• google.protobuf.Timestamp foisamp = 1;
• carte valeurs = 2 ;
• int32 stream_id = 3;
• }
• /**
• * Une valeur métrique peut être un entier ou un flottant.
• */
• message Valeur Métrique {
• un du type {
• int64 int_val = 1;
• float float_val = 2;
• }
• }

Schéma Protobuf des métadonnées

• syntaxe = « proto3 » ;
• paquet paa.streamingapi ;
• option go_package = « .;paa_streamingapi » ;
• message Métadonnées {
• int32 stream_id = 1;
• chaîne nom_flux = 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=4.1.0
• 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 tarballs
• mkdir paa-streaming-api-client-examples
• # Extraire le contenu du client examples tarballs
• 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

ex-clientamples 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 rubrique 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 baseamples, exécutez :

• build.sh run-basic –kafka-brokers localhost:9092 –compte 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. C'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 –compte 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.)

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 \
• –compte 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, passez au paa-streaming-api-client-exampdossier 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-cert
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 \
• –compte ACCOUNT_SHORTNAME
• –config-file client.propriétés

où ACCOUNT_SHORTNAME est le nom abrégé du compte dont vous souhaitez obtenir les statistiques.

Exécuter l'ex avancéamples:

• exporter KAFKA_FQDN=
• build.sh run-advanced –kafka-brokers ${KAFKA_FQDN}:9093 \
• –compte 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=~/mon-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 le CA
• export CA_PATH=~/mon-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\
  • certificat d'importation -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 FQDN corresponde au nom d'hôte exact que le client Kafka utilisera pour se connecter au Control Center.

• sudo mkdir -p /var/ssl/private
• sudo chown -R $USER : /var/ssl/private
• cd /var/ssl/privé
• exporter le nom de domaine complet = keytool -keystore kafka.server.keystore.jks \
• – alias serveur \
• – validité 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. Ils renverront ensuite le certificat signé. Nous l'appellerons ci-dessous cert-server-signed.

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\
  • – Clé CA ${CA_PATH}/clé-ca \
  • – dans la demande de serveur de certificat \
  • – sur cert-server-signed \
  • – jours 999 -CAcreateserial \
  • – pass 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\
  • - importer \
  • – file ${CA_PATH}/ca-certificat

Importez le certificat signé appelé cert-server-signed :

• keytool -keystore kafka.server.keystore.jks \
  • – alias serveur \
  • - importer \
  • – 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

DANS CETTE SECTION

• Général | 20
• Noms des sujets Kafka | 21
• Exampleçons d'utilisation de l'API Streaming | 21

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 des sujets Kafka pour l'API de streaming sont les suivants, où %s est le nom court du compte Control Center (indiqué lors de la création du compte) :

• const (
• exportateurName = « 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 –compte 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 –compte ACCOUNT_SHORTNAME

Vous devez utiliser sudo pour exécuter des commandes Docker telles que celles ci-dessus. Vous pouvez éventuellement suivre les étapes post-installation de Linux pour pouvoir exécuter les commandes Docker sans sudo. Pour plus de détails, allez à 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 © 2023 Juniper Networks, Inc. Tous droits réservés.

Documents / Ressources

Logiciel API de streaming Juniper NETWORKS [pdf] Guide de l'utilisateur Logiciel API de streaming, Logiciel API, Logiciel

Références

• Manuel d'utilisation