Logo delle RETI di JuniperGuida all'API di streaming
Pubblicato
Numero di telefono: 2023-07-07
PUBBLICAZIONE
4.2

Introduzione

Questa guida descrive come estrarre i dati da Paragon Active Assurance tramite l'API di streaming del prodotto.
L'API e il client di streaming sono inclusi nell'installazione di Paragon Active Assurance.
Tuttavia, è necessaria un po' di configurazione prima di poter utilizzare l'API. Questo è trattato nel capitolo "Configurazione dell'API di streaming" a pagina 1.

Configurazione dell'API di streaming

Sopraview
Questo capitolo descrive come configurare l'API di streaming per consentire la sottoscrizione ai messaggi di metrica tramite Kafka.
pr
Di seguito esamineremo:

  • Come abilitare l'API di streaming
  • Come configurare Kafka per l'ascolto di client esterni
  • Come configurare Kafka per utilizzare gli ACL e impostare la crittografia SSL per detti client

Kafka è una piattaforma di streaming di eventi che consente l'acquisizione in tempo reale di dati inviati da varie fonti di eventi (sensori, database, dispositivi mobili) sotto forma di flussi di eventi, nonché l'archiviazione duratura di questi flussi di eventi per il successivo recupero e manipolazione.
Con Kafka è possibile gestire lo streaming degli eventi end-to-end in modo distribuito, altamente scalabile, elastico, fault-tolerant e sicuro.
NOTA: Kafka può essere configurato in molti modi diversi ed è stato progettato per scalabilità e sistemi ridondanti. Questo documento si concentra solo su come configurarlo per utilizzare la funzione Streaming API che si trova in Paragon Active Assurance Control Center. Per impostazioni più avanzate facciamo riferimento alla documentazione ufficiale di Kafka: kafka.apache.org/26/documentation.html.

Terminologia

  • Kafka: piattaforma di streaming di eventi.
  • Argomento di Kafka: raccolta di eventi.
  • Abbonato/consumatore Kafka: componente responsabile del recupero degli eventi archiviati in un argomento Kafka.
  • Broker Kafka: server del livello di archiviazione di un cluster Kafka.
  • SSL/TLS: SSL è un protocollo sicuro sviluppato per l'invio sicuro di informazioni su Internet. TLS è il successore di SSL, introdotto nel 1999.
  • SASL: framework che fornisce meccanismi per l'autenticazione dell'utente, il controllo dell'integrità dei dati e la crittografia.
  • Sottoscrittore dell'API di streaming: componente responsabile del recupero degli eventi archiviati negli argomenti definiti in Paragon Active Assurance e destinati all'accesso esterno.
  • Autorità di certificazione: entità attendibile che emette e revoca certificati a chiave pubblica.
  • Certificato radice dell'autorità di certificazione: certificato a chiave pubblica che identifica un'autorità di certificazione.

Come funziona l'API di streaming
Come accennato in precedenza, l'API di streaming consente ai client esterni di recuperare informazioni sulle metriche da Kafka.
Tutte le metriche raccolte dagli agenti di test durante un'attività di test o monitoraggio vengono inviate al servizio Stream.
Dopo una fase di elaborazione, il servizio Stream pubblica tali metriche su Kafka insieme a metadati aggiuntivi.Juniper NETWORKS Streaming API Active Assurance: come funziona l'API di streamingArgomenti di Kafka
Kafka ha il concetto di argomenti a cui vengono pubblicati tutti i dati. In Paragon Active Assurance sono disponibili molti di questi argomenti di Kafka; tuttavia, solo un sottoinsieme di questi è destinato all'accesso esterno.
Ogni account Paragon Active Assurance in Control Center ha due argomenti dedicati. Di seguito, ACCOUNT è il nome abbreviato dell'account:

  • paa.public.accounts.{ACCOUNT}.metriche
  • Tutti i messaggi relativi alle metriche per l'account specificato vengono pubblicati in questo argomento
  • Grandi quantità di dati
  • Elevata frequenza di aggiornamento
  • paa.public.accounts.{ACCOUNT}.metadati
  • Contiene metadati relativi ai dati delle metriche, ad esample il test, il monitor o l'agente di test associato alle metriche
  • Piccole quantità di dati
  • Bassa frequenza di aggiornamento

Abilitazione dell'API di streaming
NOTA: Queste istruzioni devono essere eseguite sul server Control Center utilizzando sudo.
Poiché l'API di streaming aggiunge un sovraccarico al Centro di controllo, non è abilitata per impostazione predefinita. Per abilitare l'API, dobbiamo prima abilitare la pubblicazione delle metriche su Kafka nella configurazione principale file:

  • /etc/netrounds/netrounds.conf

KAFKA_METRICS_ENABLED = Vero
AVVERTIMENTO: L'abilitazione di questa funzione potrebbe influire sulle prestazioni di Control Center. Assicurati di aver dimensionato la tua istanza di conseguenza.
Successivamente, per abilitare l'inoltro di queste metriche agli argomenti Kafka corretti:

  • /etc/netrounds/metrics.yaml

streaming-api: vero
Per abilitare e avviare i servizi API di streaming, eseguire:
I servizi sudo ncc abilitano le metriche b su scala cronologica
I servizi sudo ncc avviano le metriche timescaleb
Infine, riavvia i servizi:
i servizi sudo ncc si riavviano
Verifica del funzionamento dell'API di streaming in Control Center
NOTA: Queste istruzioni devono essere eseguite sul server Control Center.
Ora puoi verificare di ricevere le metriche sugli argomenti Kafka corretti. Per fare ciò, installa l'utilità kafkacat:
sudo apt-get aggiornamento
sudo apt-get install kafkacat
Se hai un test o un monitor in esecuzione in Control Center, dovresti essere in grado di utilizzare kafkacat per ricevere metriche e metadati su questi argomenti.
Sostituisci myaccount con il nome breve del tuo account (questo è ciò che vedi nel tuo Control Center URL):
esporta METRICS_TOPIC=paa.public.accounts.myaccount.metrics
esporta METADATA_TOPIC=paa.public.accounts.myaccount.metadata
Ora dovresti vedere le metriche eseguendo questo comando:
kafkacat -b ${KAFKA_FQDN}:9092 -t ${METRICS_TOPIC} -C -e
A view metadati, eseguire il seguente comando (si noti che questo non si aggiornerà così frequentemente):
kafkacat -b ${KAFKA_FQDN}:9092 -t ${METADATA_TOPIC} -C -e
NOTA:
kafkacat”Cliente Example” a pagina 14
Ciò verifica che disponiamo di un'API di streaming funzionante all'interno di Control Center. Tuttavia, molto probabilmente sei invece interessato ad accedere ai dati da un client esterno. La sezione successiva descrive come aprire Kafka per l'accesso esterno.
Apertura di Kafka per host esterni
NOTA: Queste istruzioni devono essere eseguite sul server Control Center.
Per impostazione predefinita, Kafka in esecuzione sul Control Center è configurato per l'ascolto solo su localhost per uso interno.
È possibile aprire Kafka per client esterni modificando le impostazioni di Kafka.
Connessione a Kafka: avvertimenti
Juniper NETWORKS Streaming API Active Assurance - Simboli ATTENZIONE: Si prega di leggere attentamente, poiché è facile incorrere in problemi di connessione con Kafka se non si sono compresi questi concetti.
Nella configurazione del Centro di controllo descritta in questo documento, esiste un solo broker Kafka.
Tuttavia, tieni presente che un broker Kafka deve essere eseguito come parte di un cluster Kafka che può essere costituito da molti broker Kafka.
Quando ci si connette a un broker Kafka, viene impostata una connessione iniziale dal client Kafka. Su questa connessione il broker Kafka restituirà a sua volta un elenco di "ascoltatori pubblicizzati", che è un elenco di uno o più broker Kafka.
Alla ricezione di questo elenco, il client Kafka si disconnetterà, quindi si ricollegherà a uno di questi ascoltatori annunciati. I listener annunciati devono contenere nomi host o indirizzi IP accessibili al client Kafka, altrimenti il ​​client non riuscirà a connettersi.
Se viene utilizzata la crittografia SSL, che coinvolge un certificato SSL legato a un particolare nome host, è ancora più importante che il client Kafka riceva l'indirizzo corretto a cui connettersi, poiché altrimenti la connessione potrebbe essere rifiutata.
Leggi di più sugli ascoltatori di Kafka qui: www.confluent.io/blog/kafka-listeners-explained
Crittografia SSL/TLSE
Per assicurarci che solo i client fidati possano accedere a Kafka e all'API di streaming, dobbiamo configurare quanto segue:

  • Autenticazione: i client devono fornire nome utente e password tramite una connessione sicura SSL/TLS tra il client e Kafka.
  • Autorizzazione: i client autenticati possono eseguire attività regolate dagli ACL.

Ecco un overview:
Juniper NETWORKS Streaming API Active Assurance: funzionamento dell'API Streaming 1*) Autenticazione con nome utente/password eseguita su un canale crittografato con SSL

Per comprendere appieno come funziona la crittografia SSL/TLS per Kafka, fare riferimento alla documentazione ufficiale: docs.confluent.io/platform/current/kafka/encryption.html
Certificato SSL/TLS scadutoview
NOTA: in questa sottosezione utilizzeremo la seguente terminologia:
Certificato: un certificato SSL firmato da un'autorità di certificazione (CA). Ogni broker Kafka ne ha uno.
Archivio chiavi: l'archivio chiavi file che memorizza il certificato. L'archivio delle chiavi file contiene la chiave privata del certificato; pertanto, deve essere conservato in modo sicuro.
Negozio fiduciario: A file contenente i certificati CA attendibili.
Per impostare l'autenticazione tra un client esterno e Kafka in esecuzione in Control Center, entrambe le parti devono disporre di un keystore definito con un certificato correlato firmato da un'autorità di certificazione (CA) insieme al certificato radice della CA.
Inoltre, il client deve disporre anche di un truststore con il certificato root CA.
Il certificato radice CA è comune al broker Kafka e al client Kafka.
Creazione dei certificati richiesti
Questo è trattato nell'"Appendice" a pagina 17.
Configurazione SSL/TLS di Kafka Broker nel Centro di controllo
NOTA: queste istruzioni devono essere eseguite sul server Control Center.
NOTA: Prima di continuare, è necessario creare il keystore che contiene il certificato SSL seguendo le istruzioni nell'“Appendice” a pagina 17. I percorsi indicati di seguito provengono da queste istruzioni.
Il keystore SSL è un file memorizzato su disco con il file estensione .jks.
Dopo aver creato i certificati richiesti sia per il broker Kafka che per il client Kafka, puoi continuare configurando il broker Kafka in esecuzione in Control Center. Devi sapere quanto segue:

  • : il nome host pubblico di Control Center; questo deve essere risolvibile e accessibile dai client Kafka.
  • : la password dell'archivio chiavi fornita durante la creazione del certificato SSL.
  • E : queste sono le password che desideri impostare rispettivamente per l'amministratore e l'utente client. Tieni presente che puoi aggiungere più utenti, come indicato nell'examplui.

Modifica o aggiungi (con accesso sudo) le proprietà sottostanti in /etc/kafka/server.properties, inserendo le variabili di cui sopra come mostrato:
Juniper NETWORKS Streaming API Active Assurance - Simboli ATTENZIONE: non rimuovere PLAINTEXT://localhost:9092; ciò interromperà la funzionalità del Centro di controllo poiché i servizi interni non saranno in grado di comunicare.


# Gli indirizzi su cui è in ascolto il broker Kafka.
ascoltatori=PLAINTEXT://localhost:9092,SASL_SSL://0.0.0.0:9093
# Questi sono gli host segnalati a qualsiasi client che si connette.
Advertised.listeners=PLAINTEXT://localhost:9092,SASL_SSL:// :9093

####### CONFIGURAZIONE PERSONALIZZATA
# CONFIGURAZIONE SSL
ssl.endpoint.identification.algorithm=
ssl.keystore.location=/var/ssl/private/kafka.server.keystore.jks
ssl.keystore.password=
ssl.key.password=
ssl.client.auth=nessuno
ssl.protocollo=TLSv1.2
# Configurazione SASL
sasl.enabled.mechanisms=Semplice
listener.name.sasl_ssl.plain.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginMo
richiesto \
nomeutente="admin" \
parola d'ordine = " "\
utente_admin=" "\
cliente_utente=" ”;
# NOTA è possibile aggiungere più utenti con user_ =
# Autorizzazione, attiva gli ACL
Authorizer.class.name=kafka.security.authorizer.AclAuthorizer
super.users=Utente:admin

Impostazione di elenchi di controllo di accesso (ACL)
Attivazione degli ACL su localhost
Juniper NETWORKS Streaming API Active Assurance - Simboli AVVERTIMENTO: Dobbiamo prima configurare gli ACL per localhost, in modo che Control Center stesso possa ancora accedere a Kafka. Se questo non viene fatto, le cose si rompono.

######## Voci ACL per utenti anonimi
/usr/lib/kafka/bin/kafka-acls.sh \
–authorizer kafka.security.authorizer.AclAuthorizer \
–authorizer-properties zookeeper.connect=localhost:2181 \
–add –allow-principal Utente: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 Utente:ANONIMO –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 Utente:ANONIMO –allow-host 127.0.0.1 –group '*'

Dobbiamo quindi abilitare gli ACL per l'accesso esterno in sola lettura, in modo che gli utenti esterni possano leggere gli argomenti paa.public.*.
NOTA: Per un controllo più dettagliato, fare riferimento alla documentazione ufficiale di Kafka.

######## Voci ACL per utenti esterni
/usr/lib/kafka/bin/kafka-acls.sh \
–authorizer kafka.security.authorizer.AclAuthorizer \
–authorizer-properties zookeeper.connect=localhost:2181 \
–add –allow-principal Utente:* –operazione read –operazione describe \
–gruppo "NCC"
/usr/lib/kafka/bin/kafka-acls.sh \
–authorizer kafka.security.authorizer.AclAuthorizer \
–authorizer-properties zookeeper.connect=localhost:2181 \
–add –allow-principal Utente:* –operazione read –operazione describe \
–topic paa.public. –resource-pattern-type preceduto

Una volta terminato, è necessario riavviare i servizi:
i servizi sudo ncc si riavviano
Per verificare che un client possa stabilire una connessione protetta, eseguire il seguente comando su un computer client esterno (non sul server Control Center). Di seguito, PUBLIC_HOSTNAME è il nome host di Control Center:
openssl s_client -debug -connect ${PUBLIC_HOSTNAME}:9093 -tls1_2 | grep “È supportata la rinegoziazione sicura”
Nell'output del comando dovresti vedere il certificato del server e quanto segue:
La rinegoziazione sicura è supportata
Per garantire che ai servizi interni sia stato concesso l'accesso al server Kafka, controllare il seguente registrofiles:

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

Convalida della connettività del client esterno
gatto kafka
NOTA: Queste istruzioni devono essere eseguite su un computer client (non sul server Control Center).
NOTA: Per visualizzare le informazioni sulle metriche, assicurarsi che almeno un monitor sia in esecuzione in Control Center.
Per verificare e convalidare la connettività come client esterno, è possibile utilizzare l'utilità kafkacat che è stata installata nella sezione "Verifica del funzionamento dell'API di streaming in Control Center" a pagina 4.
Eseguire i seguenti passaggi:
NOTA: Di seguito, CLIENT_USER è l'utente precedentemente specificato nel file file /etc/kafka/server.properties nel Centro di controllo: vale a dire user_client e la password impostata lì.
Il certificato radice CA utilizzato per firmare il certificato SSL lato server deve essere presente sul client.

  • Crea un file client.properties con il seguente contenuto:

security.protocol=SASL_SSL
ssl.ca.location={PATH_TO_CA_CERT}
sasl.mechanisms=PIANALE
sasl.nomeutente={CLIENT_USER}
sasl.password={CLIENT_PASSWORD}
Dove

  • {PATH_TO_CA_CERT} è il percorso del certificato radice CA utilizzato dal broker Kafka
  • {CLIENT_USER} e {CLIENT_PASSWORD} sono le credenziali utente per il client.
  • Esegui il comando seguente per visualizzare il messaggio consumato da kafkacat:

esporta KAFKA_FQDN=
export METRICS_TOPIC=paa.public.accounts. .metrica
kafkacat -b ${KAFKA_FQDN}:9093 -F cliente.properties -t ${METRICS_TOPIC} -C -e
dove {METRICS_TOPIC} è il nome dell'argomento Kafka con prefisso "paa.public.".

NOTA: Le versioni precedenti di kafkacat non forniscono l'opzione -F per leggere le impostazioni del client da a file. Se stai utilizzando una versione di questo tipo, devi fornire le stesse impostazioni dalla riga di comando come mostrato di seguito.

kafkacat -b ${KAFKA_FQDN}:9093 \
-X security.protocol=SASL_SSL\
-X ssl.ca.location={PERCORSO_CA_CERT} \
-X sasl.meccanismi=PLAIN \
-X sasl.nomeutente={CLIENT_USER} \
-X sasl.password={CLIENT_PASSWORD} \
-t ${METRICS_TOPIC} -C -e
Per eseguire il debug della connettività, puoi utilizzare l'opzione -d:

Eseguire il debug delle comunicazioni dei consumatori
kafkacat -d consumatore -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -e
# Debug delle comunicazioni del broker
kafkacat -d broker -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -e

Assicurati di fare riferimento alla documentazione per la libreria client Kafka in uso, poiché le proprietà potrebbero differire da quelle in client.properties.
Formato del messaggio
I messaggi utilizzati per le metriche e gli argomenti dei metadati sono serializzati nel formato Protocol buffers (protobuf) (vedere developer.google.com/protocol-buffers). Gli schemi per questi messaggi aderiscono al seguente formato:

Schema protobuf delle metriche

sintassi = “proto3”;
importa “google/protobuf/timestamp.proto”;
pacchetto paa.streamingapi;
opzione go_package = “.;paa_streamingapi”;
Metriche del messaggio {
google.protobuf.Timestamp tempiamp = 1;
carta geografica valori = 2;
int32 stream_id = 3;
}
/**
* Un valore metrico può essere un numero intero o un valore in virgola mobile.
*/
messaggio MetricValue {
uno di tipo {
int64 int_val = 1;
float valore_float = 2;
}
}

Schema del protobuf dei metadati

sintassi = “proto3”;
pacchetto paa.streamingapi;
opzione go_package = “.;paa_streamingapi”;
Metadati del messaggio {
int32 stream_id = 1;
stringa nome_flusso = 2;
carta geografica tags = 13;
}

Cliente Esamples

NOTA: Questi comandi sono pensati per essere eseguiti su un client esterno, ad esamplascia il tuo laptop o simile, e non in Control Center.
NOTA: Per visualizzare le informazioni sulle metriche, assicurarsi che almeno un monitor sia in esecuzione in Control Center.
Il tarball di Control Center include l'archivio paa-streaming-api-client-examples.tar.gz (client-esamples), che contiene un examplo script Python che mostra come utilizzare l'API di streaming.
Installazione e configurazione del client Examples
Trovi client-example nella cartella Paragon Active Assurance Control Center:

esporta CC_VERSION=4.2.0
cd ./paa-control-center_${CC_VERSION}
ls paa-streaming-api-client-example*
Per installare client-example sul computer client esterno, procedere come segue:
# Crea una directory per estrarre il contenuto del client esampil tarball
mkdir paa-streaming-api-client-examples
# Estrai il contenuto del client esampil tarball
tar xzf paa-streaming-api-client-examples.tar.gz -C paa-streaming-api-client-examples
# Vai alla directory appena creata
cd paa-streaming-api-client-examples
cliente-esamples richiede l'esecuzione di Docker. I download e le istruzioni di installazione per Docker sono disponibili all'indirizzo https://docs.docker.com/engine/install.

Utilizzando il client esamples
Il cliente-esampgli strumenti possono essere eseguiti in modalità di base o avanzata per compilare example di varia complessità. In entrambi i casi è possibile eseguire anche l'example con una configurazione file contenente proprietà aggiuntive per un'ulteriore personalizzazione del lato client.
Modalità base
Nella modalità di base, le metriche e i relativi metadati vengono trasmessi in streaming separatamente. A tal fine, il client ascolta ogni argomento Kafka disponibile per l'accesso esterno e stampa semplicemente i messaggi ricevuti sulla console.
Per avviare l'esecuzione della base examples, esegui:
./build.sh run-basic –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME
dove ACCOUNT_SHORTNAME è il nome breve dell'account da cui vuoi ottenere le metriche.
Per terminare l'esecuzione dell'example, premi Ctrl + C. (Potrebbe esserci un leggero ritardo prima che l'esecuzione si interrompa perché il client attende un evento di timeout.)
Modalità avanzata
NOTA: Le metriche vengono visualizzate solo per i monitor HTTP in esecuzione in Control Center.
L'esecuzione in modalità avanzata mostra la correlazione tra metriche e messaggi di metadati. Questo è possibile grazie alla presenza in ogni messaggio di metrica di un campo stream id che rimanda al corrispondente messaggio di metadati.
Per eseguire l'avanzato examples, esegui:
./build.sh run-advanced –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME
dove ACCOUNT_SHORTNAME è il nome breve dell'account da cui vuoi ottenere le metriche.
Per terminare l'esecuzione dell'example, premi Ctrl + C. (Potrebbe esserci un leggero ritardo prima che l'esecuzione si interrompa perché il client attende un evento di timeout.)
Impostazioni aggiuntive
È possibile eseguire l'example con configurazione aggiuntiva del client utilizzando il –config-file opzione seguita da a file nome contenente proprietà nella forma chiave=valore.
./build.sh esegui-avanzato \
–kafka-brokers localhost:9092 \
–account ACCOUNT_SHORTNAME \
–config-file client_config.properties

NOTA: Tutto fileI messaggi a cui si fa riferimento nel comando precedente devono trovarsi nella directory corrente e fare riferimento utilizzando solo percorsi relativi. Questo vale sia per il –config-file argomento e a tutte le voci nella configurazione file che descrivono file posizioni.
Convalida dell'autenticazione del client esterno
Per convalidare l'autenticazione del client dall'esterno del Centro di controllo utilizzando client-example, eseguire i seguenti passaggi:

  • Dalla cartella Paragon Active Assurance Control Center, passa a paa-streaming-api-clientexampcartella file:
    cd paa-streaming-api-client-examples
  • Copiare il certificato radice della CA ca-cert nella directory corrente.
  • Crea un client.properties file con il seguente contenuto:
    security.protocol=SASL_SSL
    ssl.ca.location=ca-cert
    sasl.meccanismo=PIANALE
    sasl.nomeutente={CLIENT_USER}
    sasl.password={CLIENT_PASSWORD}
    dove {CLIENT_USER} e {CLIENT_PASSWORD} sono le credenziali utente per il client.
  • Esegui di base esamples:
    esporta KAFKA_FQDN=
    ./build.sh run-basic –kafka-brokers ${KAFKA_FQDN}:9093 \
    –account ACCOUNT_SHORTNAME
    –config-file proprietà.cliente
    dove ACCOUNT_SHORTNAME è il nome breve dell'account da cui vuoi ottenere le metriche.
  • Esegui avanzato esamples:
    esporta KAFKA_FQDN=
    ./build.sh run-advanced –kafka-brokers ${KAFKA_FQDN}:9093 \
    –account ACCOUNT_SHORTNAME
    –config-file proprietà.cliente

Appendice
In questa appendice descriviamo come creare:

  • un archivio chiavi file per l'archiviazione del certificato SSL del broker Kafka
  • un deposito fiduciario file per l'archiviazione del certificato radice dell'autorità di certificazione (CA) utilizzato per firmare il certificato del broker Kafka.

Creazione di un certificato di Kafka Broker
Creazione di un certificato utilizzando una vera autorità di certificazione (consigliato)
Si consiglia di ottenere un vero certificato SSL da una CA attendibile.
Dopo aver scelto una CA, copia il loro certificato root CA ca-cert file al tuo percorso come mostrato di seguito:
esporta CA_PATH=~/mio-ca
mkdir ${CA_PATH}
cp certificato ca ${CA_PATH}
Crea la tua autorità di certificazione
NOTA: Normalmente dovresti far firmare il tuo certificato da una vera Autorità di Certificazione; vedere la sottosezione precedente. Quello che segue è solo un examplui.
Qui creiamo il nostro certificato radice dell'autorità di certificazione (CA). file valido per 999 giorni (non consigliato in produzione):
# Crea una directory per archiviare la CA
esporta CA_PATH=~/mio-ca
mkdir ${CA_PATH}
# Genera il certificato CA
openssl req -new -x509 -keyout ${CA_PATH}/ca-key -out ${CA_PATH}/ca-cert -days 999

Creazione del Truststore del cliente
Ora puoi creare un truststore file che contiene il certificato ca generato sopra. Questo file sarà necessario al client Kafka che accederà all'API di streaming:

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

Ora che il certificato CA si trova nel truststore, il client considererà attendibile qualsiasi certificato firmato con esso.
Dovresti copiare il file file kafka.client.truststore.jks in una posizione nota sul computer client e indicarla nelle impostazioni.
Creazione del keystore per Kafka Broker
Per generare il certificato SSL di Kafka broker e quindi il keystore kafka.server.keystore.jks, procedere come segue:
Generazione del certificato SSL
Di seguito, 999 è il numero di giorni di validità del keystore e FQDN è il nome di dominio completo del client (nome host pubblico del nodo).
NOTA: È importante che l'FQDN corrisponda esattamente al nome host che il client Kafka utilizzerà per connettersi al Centro di controllo.
sudo mkdir -p /var/ssl/private
sudo chown -R $UTENTE: /var/ssl/private
cd /var/ssl/private
esporta FQDN=
keytool -keystore kafka.server.keystore.jks \
-alias server \
-validità 999 \
-genkey -keyalg RSA -ext SAN=dns:${FQDN}
Creare una richiesta di firma del certificato e archiviarla nel file file denominato cert-server-request:
keytool -keystore kafka.server.keystore.jks \
-alias server \
-certreq \
-file richiesta-cert-server

Ora dovresti inviare il file file cert-server-request alla tua autorità di certificazione (CA) se ne stai utilizzando una reale. Restituiranno quindi il certificato firmato. Faremo riferimento a questo come certificato-server-firmato di seguito.
Firma del certificato SSL utilizzando un certificato CA creato autonomamente
NOTA: Ancora una volta, l'utilizzo della propria CA non è consigliabile in un sistema di produzione.
Firmare il certificato utilizzando la CA tramite il file cert-server-request, che produce il certificato firmato cert-server-signed. Vedi sotto; ca-password è la password impostata durante la creazione del certificato CA.

cd /var/ssl/private
openssl x509 -req \
-CA ${CA_PATH}/ca-cert \
-CAkey ${CA_PATH}/ca-key \
-in richiesta-server-cert \
-out certificato-server-firmato \
-giorni 999 -CAcreateserial \
-passin pass:{ca-password}

Importazione del certificato firmato nel keystore
Importa il certificato root ca-cert nel keystore:
keytool -keystore kafka.server.keystore.jks \
-alias ca-cert \
-importa \
-file ${CA_PATH}/ca-cert
Importa il certificato firmato denominato cert-server-signed:
keytool -keystore kafka.server.keystore.jks \
-alias server \
-importa \
-file cert-server-firmato
IL file kafka.server.keystore.jks deve essere copiato in una posizione nota sul server Control Center e quindi indicato in /etc/kafka/server.properties.

Utilizzo dell'API di streaming

Generale
L'API di streaming recupera sia i dati di test che quelli di monitoraggio. Non è possibile individuare una di queste categorie.
L'API di streaming non recupera i dati dai test basati su script (quelli rappresentati da un rettangolo anziché da un pezzo di puzzle nella GUI di Control Center), come i test di attivazione del servizio Ethernet e i test di trasparenza.

Nomi degli argomenti di Kafka
I nomi degli argomenti Kafka per l'API di streaming sono i seguenti, dove %s è il nome breve dell'account Control Center (indicato durante la creazione dell'account):

cost (
nomeEsportatore = “kafka”
metadataTopicTpl = “paa.public.accounts.%s.metadata”
metricsTopicTpl = “paa.public.accounts.%s.metrics”
)

Exampfile sull'utilizzo dell'API di streaming
L'exampi che seguono si trovano nel tarball paa-streaming-api-client-examples.tar.gz contenuto nel tarball di Control Center.
Innanzitutto, c'è un ex di baseample che dimostra come le metriche e i relativi metadati vengono trasmessi in streaming separatamente e stampa semplicemente i messaggi ricevuti sulla console. Puoi eseguirlo come segue:
sudo ./build.sh run-basic –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME
C'è anche un ex più avanzatoample dove i messaggi di metriche e metadati sono correlati. Usa questo comando per eseguirlo:
sudo ./build.sh run-advanced –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME
È necessario utilizzare sudo per eseguire comandi Docker come quelli sopra. Facoltativamente, puoi seguire i passaggi post-installazione di Linux per poter eseguire i comandi Docker senza sudo. Per i dettagli, vai a docs.docker.com/engine/install/linux-postinstall.

Juniper Networks, il logo Juniper Networks, Juniper e Junos sono marchi registrati di Juniper Networks, Inc. negli Stati Uniti e in altri paesi. Tutti gli altri marchi, marchi di servizio, marchi registrati o marchi di servizio registrati sono di proprietà dei rispettivi proprietari. Juniper Networks non si assume alcuna responsabilità per eventuali inesattezze presenti nel presente documento. Juniper Networks si riserva il diritto di cambiare, modificare, trasferire o altrimenti rivedere questa pubblicazione senza preavviso. Copyright © 2023 Juniper Networks, Inc. Tutti i diritti riservati.

Logo delle RETI di Juniper

Documenti / Risorse

API di streaming Juniper NETWORKS Active Assurance [pdf] Guida utente
API di streaming Active Assurance, API Active Assurance, Active Assurance, Assurance

Riferimenti

Lascia un commento

Il tuo indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *