Simplitatea ingineriei
Ghid API de streaming

Introducere

Acest ghid descrie cum să extrageți date din Paragon Active Assurance prin intermediul API-ului de streaming al produsului.
API-ul, precum și clientul de streaming sunt incluse în instalarea Paragon Active Assurance.
Cu toate acestea, este nevoie de puțină configurare înainte de a putea utiliza API-ul. Acest lucru este tratat în capitolul „Configurarea API-ului de streaming” la pagina 1.

Pesteview

Acest capitol descrie modul de configurare a API-ului Streaming pentru a permite abonarea la mesaje de valori prin Kafka.
Mai jos vom parcurge:

• Cum să activați API-ul de streaming
• Cum se configurează Kafka pentru a asculta clienții externi
• Cum să configurați Kafka să utilizeze ACL-uri și să configurați criptarea SSL pentru clienții menționați

Ce este Kafka?

Kafka este o platformă de streaming de evenimente care permite capturarea în timp real a datelor trimise din diverse surse de evenimente (senzori, baze de date, dispozitive mobile) sub formă de fluxuri de evenimente, precum și stocarea durabilă a acestor fluxuri de evenimente pentru recuperarea și manipularea ulterioară.
Cu Kafka este posibil să gestionați fluxul de evenimente de la capăt la capăt într-o manieră distribuită, extrem de scalabilă, elastică, tolerantă la erori și sigură.
NOTA: Kafka poate fi configurat în multe moduri diferite și a fost proiectat pentru scalabilitate și sisteme redundante. Acest document se concentrează numai asupra modului de configurare pentru a utiliza funcția API de streaming găsită în Centrul de control Paragon Active Assurance. Pentru setări mai avansate, ne referim la documentația oficială Kafka: kafka.apache.org/26/documentation.html.

Terminologie

• Kafka: platformă de streaming de evenimente.
• Subiect Kafka: Culegere de evenimente.
• Abonat/consumator Kafka: Componentă responsabilă pentru preluarea evenimentelor stocate într-un subiect Kafka.
• Broker Kafka: serverul stratului de stocare al unui cluster Kafka.
• SSL/TLS: SSL este un protocol securizat dezvoltat pentru a trimite informații în siguranță prin Internet. TLS este succesorul SSL, introdus în 1999.
• SASL: cadru care oferă mecanisme pentru autentificarea utilizatorilor, verificarea integrității datelor și criptare.
• Abonat Streaming API: Componentă responsabilă pentru preluarea evenimentelor stocate în subiectele definite în Paragon Active Assurance și destinate accesului extern.
• Autoritate de certificare: O entitate de încredere care emite și revocă certificate de cheie publică.
• Certificat rădăcină al autorității de certificare: certificat de cheie publică care identifică o autoritate de certificare.

Cum funcționează API-ul de streaming

După cum sa menționat anterior, API-ul Streaming permite clienților externi să preia informații despre valorile de la Kafka.
Toate valorile colectate de agenții de testare în timpul unei sarcini de testare sau monitorizare sunt trimise serviciului Stream.
După o fază de procesare, serviciul Stream publică acele valori pe Kafka împreună cu metadate suplimentare.

Subiecte Kafka

Kafka are conceptul de subiecte la care sunt publicate toate datele. În Paragon Active Assurance există multe astfel de subiecte Kafka disponibile; cu toate acestea, doar un subset dintre acestea sunt destinate accesului extern.
Fiecare cont Paragon Active Assurance din Control Center are două subiecte dedicate. Mai jos, ACCOUNT este numele scurt al contului:

• paa.public.accounts.{ACCOUNT}.metrics
• Toate mesajele de valori pentru contul dat sunt publicate în acest subiect
• Cantități mari de date
• Frecvență mare de actualizare
• paa.public.accounts.{ACCOUNT}.metadate
• Conține metadate legate de datele de valori, de exampeste testarea, monitorul sau agentul de testare asociat cu valorile
• Cantități mici de date
• Frecvență scăzută de actualizare

Activarea API-ului de streaming

NOTA: Aceste instrucțiuni trebuie să fie rulate pe serverul Control Center folosind sudo.
Deoarece API-ul de streaming adaugă o suprasarcină la Centrul de control, acesta nu este activat în mod implicit. Pentru a activa API-ul, trebuie mai întâi să activăm publicarea valorilor către Kafka în configurația principală file:

• /etc/netrounds/netrounds.conf
  KAFKA_METRICS_ENABLED = Adevărat
  AVERTIZARE: Activarea acestei funcții poate afecta performanța Centrului de control. Asigurați-vă că ați dimensionat instanța în consecință.
  Apoi, pentru a activa transmiterea acestor valori către subiectele Kafka corecte:
• /etc/netrounds/metrics.yaml
  streaming-api: adevărat

Pentru a activa și a porni serviciile API de streaming, rulați:
Serviciile sudo ncc activează valorile timecaledb. Serviciile sudo ncc pornesc valorile timescaledb
În cele din urmă, reporniți serviciile:
reporniți serviciile sudo ncc

Verificarea faptului că API-ul de streaming funcționează în Centrul de control

NOTA: Aceste instrucțiuni trebuie să fie rulate pe serverul Control Center.
Acum puteți verifica dacă primiți valori cu privire la subiectele Kafka corecte. Pentru a face acest lucru, instalați utilitarul kafkacat:
sudo apt-get update sudo apt-get install kafkacat
Dacă aveți un test sau un monitor care rulează în Centrul de control, ar trebui să puteți utiliza kafkacat pentru a primi valori și metadate despre aceste subiecte.
Înlocuiți myaccount cu numele scurt al contului dvs. (acesta este ceea ce vedeți în Centrul de control URL):
export METRICS_TOPIC=paa.public.accounts.myaccount.metrics
export METADATA_TOPIC=paa.public.accounts.myaccount.metadata
Ar trebui să vedeți acum valorile rulând această comandă:
kafkacat -b ${KAFKA_FQDN}:9092 -t ${METRICS_TOPIC} -C -e
La view metadate, executați următoarea comandă (rețineți că aceasta nu se va actualiza la fel de des):
kafkacat -b ${KAFKA_FQDN}:9092 -t ${METADATA_TOPIC} -C -e
NOTA:
kafkacat”Client Examples ”la pagina 14
Acest lucru verifică faptul că avem un API de streaming funcțional din Centrul de control. Cu toate acestea, cel mai probabil sunteți interesat să accesați datele de la un client extern. Următoarea secțiune descrie cum să deschideți Kafka pentru acces extern.

Deschiderea Kafka pentru gazde externe

NOTA: Aceste instrucțiuni trebuie să fie rulate pe serverul Control Center.
În mod implicit, Kafka care rulează în Centrul de control este configurat să asculte numai pe localhost pentru uz intern.
Este posibil să deschideți Kafka pentru clienți externi prin modificarea setărilor Kafka.
Conectarea la Kafka: Avertismente
ATENŢIE: Vă rugăm să citiți acest lucru cu atenție, deoarece este ușor să întâlniți probleme de legătură cu Kafka dacă nu ați înțeles aceste concepte.
În configurarea Centrului de control descrisă în acest document, există doar un singur broker Kafka.
Cu toate acestea, rețineți că un broker Kafka este menit să ruleze ca parte a unui cluster Kafka care poate consta din mulți brokeri Kafka.
Când vă conectați la un broker Kafka, clientul Kafka stabilește o conexiune inițială. Prin această conexiune, brokerul Kafka va returna la rândul său o listă de „ascultători anunțați”, care este o listă a unuia sau mai multor brokeri Kafka.
La primirea acestei liste, clientul Kafka se va deconecta, apoi se va reconecta la unul dintre acești ascultători anunțați. Ascultătorii anunțați trebuie să conțină nume de gazdă sau adrese IP care sunt accesibile clientului Kafka, altfel clientul nu se va conecta.
Dacă se folosește criptarea SSL, care implică un certificat SSL care este legat de un anumit nume de gazdă, este și mai important ca clientul Kafka să primească adresa corectă la care să se conecteze, deoarece în caz contrar conexiunea poate fi respinsă.
Citiți mai multe despre ascultătorii Kafka aici: www.confluent.io/blog/kafka-listeners-explained
Criptare SSL/TLS
Pentru a ne asigura că numai clienții de încredere au voie să acceseze Kafka și API-ul de streaming, trebuie să configuram următoarele:

• Autentificare: Clienții trebuie să furnizeze numele de utilizator și parola printr-o conexiune securizată SSL/TLS între client și Kafka.
• Autorizare: clienții autentificați pot îndeplini sarcini reglementate de ACL-uri.
  Iată o terminareview:

*) Autentificarea numelui de utilizator/parolă efectuată pe un canal criptat SSL
Pentru a înțelege pe deplin cum funcționează criptarea SSL/TLS pentru Kafka, consultați documentația oficială: docs.confluent.io/platform/current/kafka/encryption.html
Certificat SSL/TLS pesteview
NOTA: În această subsecțiune vom folosi următoarea terminologie:
Certificat: un certificat SSL semnat de o autoritate de certificare (CA). Fiecare broker Kafka are unul.
Magazin de chei: Depozitul de chei file care stochează certificatul. Depozitul de chei file conține cheia privată a certificatului; prin urmare, trebuie păstrat în siguranță.
Truststore: A file care conțin certificatele CA de încredere.
Pentru a configura autentificarea între un client extern și Kafka care rulează în Centrul de control, ambele părți trebuie să aibă un depozit de chei definit cu un certificat aferent semnat de o autoritate de certificare (CA) împreună cu certificatul rădăcină CA.
În plus, clientul trebuie să aibă și un truststore cu certificatul rădăcină CA.
Certificatul rădăcină CA este comun brokerului Kafka și clientului Kafka.
Crearea certificatelor necesare
Acest lucru este tratat în „Anexă” la pagina 17.
Configurare SSL/TLS Kafka Broker în Centrul de control
NOTA: Aceste instrucțiuni trebuie să fie rulate pe serverul Control Center.
NOTA: Înainte de a continua, trebuie să creați depozitul de chei care conține certificatul SSL urmând instrucțiunile din „Anexă” la pagina 17. Căile menționate mai jos provin din aceste instrucțiuni.
Depozitul de chei SSL este un file stocate pe disc cu file extensie .jks.
După ce aveți certificatele necesare create atât pentru brokerul Kafka, cât și pentru clientul Kafka, puteți continua prin configurarea brokerului Kafka care rulează în Centrul de control. Trebuie să știți următoarele:

• : numele de gazdă public al Centrului de control; acest lucru trebuie să fie rezolvabil și accesibil de către clienții Kafka.
• : Parola pentru depozitul de chei furnizată la crearea certificatului SSL.
• și : Acestea sunt parolele pe care doriți să le setați pentru utilizatorul administrator și, respectiv, client.
  Rețineți că puteți adăuga mai mulți utilizatori, așa cum este indicat în example.
  Editați sau adăugați (cu acces sudo) proprietățile de mai jos în /etc/kafka/server.properties, inserând variabilele de mai sus așa cum se arată:

AVERTIZARE: Nu eliminați PLAINTEXT://localhost:9092; acest lucru va întrerupe funcționalitatea Centrului de control, deoarece serviciile interne nu vor putea comunica.
…# Adresele pe care brokerul Kafka le ascultă.
listeners=PLAINTEXT://localhost:9092,SASL_SSL://0.0.0.0:9093
# Acestea sunt gazdele anunțate înapoi oricărui client care se conectează.
advertised.listeners=PLAINTEXT://localhost:9092,SASL_SSL:// :9093...
####### CONFIG. PERSONALIZĂ
# CONFIGURARE SSL
ssl.endpoint.identification.algorithm=
ssl.keystore.location=/var/ssl/private/kafka.server.keystore.jks
ssl.keystore.password=
ssl.key.parola=
ssl.client.auth=niciunul
ssl.protocol=TLSv1.2
# Configurare SASL sasl.enabled.mechanisms=PLAIN
listener.name.sasl_ssl.plain.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginMo este necesar \ username=”admin” \ password=” ” \ user_admin=" ” \ user_client=" ”; # NOTĂ pot fi adăugați mai mulți utilizatori cu user_ =
# Autorizare, activați ACL-uri authorizer.class.name=kafka.security.authorizer.AclAuthorizer super.users=Utilizator:admin
Configurarea listelor de control al accesului (ACL)
Activarea ACL-urilor pe localhost
AVERTIZARE: Mai întâi trebuie să setăm ACL-uri pentru localhost, astfel încât Centrul de control însuși să poată accesa în continuare Kafka. Dacă nu se face acest lucru, lucrurile se vor rupe.
######### Intrări ACL-uri pentru utilizatori anonimi
/usr/lib/kafka/bin/kafka-acls.sh \
–authorizer kafka.security.authorizer.AclAuthorizer \ –authorizer-properties zookeeper.connect=localhost:2181 \ –add –allow-principal Utilizator: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 Utilizator:ANONYMOUS –allow-host 127.0.0.1 –subiect „*”
/usr/lib/kafka/bin/kafka-acls.sh \
–authorizer kafka.security.authorizer.AclAuthorizer \ –authorizer-properties zookeeper.connect=localhost:2181 \ –add –allow-principal Utilizator:ANONYMOUS –allow-host 127.0.0.1 –grup „*”
Apoi, trebuie să activăm ACL-urile pentru acces extern doar pentru citire, astfel încât utilizatorii externi să aibă voie să citească subiectele paa.public.*.
NOTA: Pentru un control mai precis, vă rugăm să consultați documentația oficială Kafka.
######### Intrări ACL-uri pentru utilizatori externi
/usr/lib/kafka/bin/kafka-acls.sh \
–authorizer kafka.security.authorizer.AclAuthorizer \–authorizer-properties zookeeper.connect=localhost:2181 \
–add –allow-principal User:* –operation read –operation describe \–group 'NCC'
/usr/lib/kafka/bin/kafka-acls.sh \
–authorizer kafka.security.authorizer.AclAuthorizer \
–authorizer-properties zookeeper.connect=localhost:2181 \
–add –allow-principal User:* –operation read –operation describe \
–subiect paa.public. –prefix de tip-resurse-pattern
După ce ați terminat acest lucru, trebuie să reporniți serviciile:
reporniți serviciile sudo ncc
Pentru a verifica dacă un client poate stabili o conexiune securizată, executați următoarea comandă pe un computer client extern (nu pe serverul Control Center). Mai jos, PUBLIC_HOSTNAME este numele de gazdă a Centrului de control:
openssl s_client -debug -connect ${PUBLIC_HOSTNAME}:9093 -tls1_2 | grep „Renegociere sigură este acceptată”
În rezultatul comenzii, ar trebui să vedeți certificatul serverului, precum și următoarele:
Este acceptată renegocierea sigură
Pentru a vă asigura că serviciile interne au primit acces la serverul Kafka, vă rugăm să verificați următorul jurnalfiles:

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

Validarea conectivității clientului extern

kafkacat
NOTA: Aceste instrucțiuni trebuie să fie rulate pe un computer client (nu pe serverul Control Center).
NOTA: Pentru a afișa informații despre valori, asigurați-vă că cel puțin un monitor rulează în Centrul de control.
Pentru a verifica și valida conectivitatea ca client extern, este posibil să utilizați utilitarul kafkacat care a fost instalat în secțiunea „Verificarea faptului că API-ul de streaming funcționează în Centrul de control” la pagina 4.
Efectuați următorii pași:
NOTA: Mai jos, CLIENT_USER este utilizatorul specificat anterior în file /etc/kafka/server.properties în
Centru de control: și anume, user_client și parola setată acolo.
Certificatul rădăcină CA utilizat pentru a semna certificatul SSL pe partea serverului trebuie să fie prezent pe client.

• Creați o file client.properties cu următorul conținut:
  security.protocol=SASL_SSL
  ssl.ca.location={PATH_TO_CA_CERT}
  sasl.mechanisms=PLAIN
  sasl.username={CLIENT_USER}
  sasl.password={CLIENT_PASSWORD} unde
  • {PATH_TO_CA_CERT} este locația certificatului rădăcină CA folosit de brokerul Kafka
  • {CLIENT_USER} și {CLIENT_PASSWORD} sunt acreditările de utilizator pentru client.
  • Rulați următoarea comandă pentru a vedea mesajul consumat de kafkacat:
  exportă KAFKA_FQDN=
  export METRICS_TOPIC=paa.public.accounts. .metrice
  kafkacat -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -e
  unde {METRICS_TOPIC} este numele subiectului Kafka cu prefixul „paa.public.”.

NOTA: Versiunile mai vechi de kafkacat nu oferă opțiunea -F pentru citirea setărilor clientului din a file. Dacă utilizați o astfel de versiune, trebuie să furnizați aceleași setări din linia de comandă, așa cum se arată mai jos.
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
Pentru a depana conectivitatea, puteți utiliza opțiunea -d:
Depanați comunicațiile cu consumatorii
kafkacat -d consumer -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -e
# Depanați comunicațiile brokerului
kafkacat -d broker -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -e
Asigurați-vă că vă referiți la documentația pentru biblioteca client Kafka în uz, deoarece proprietățile pot diferi de cele din client.properties.

Format mesaj

Mesajele utilizate pentru subiectele de metrici și metadate sunt serializate în formatul tampon de protocol (protobuf) (vezi developers.google.com/protocol-buffers). Schemele pentru aceste mesaje respectă următorul format:
Metrics Protobuf Schema
sintaxă = „proto3”; import „google/protobuf/timestamp.proto”; pachet paa.streamingapi; opțiunea go_package = „.;paa_streamingapi”; Mesajul Metrics { google.protobuf.Timestamp ori mai multamp = 1; Hartă valori = 2; int32 măsura_id = 3; } /** * O valoare de metrică poate fi fie un număr întreg, fie un flotant. */
mesaj MetricValue { oneof type { int64 int_val = 1; float float_val = 2; } }
Schema Protobuf de metadate
sintaxă = „proto3”; pachet paa.streamingapi; opțiunea go_package = „.;paa_streamingapi”; Metadatele mesajului { int32 measurement_id = 1; șir nume_măsurare = 2; Hartă tags = 13; }

Client Examples

NOTA: Aceste comenzi sunt destinate să ruleze pe un client extern, de examplasă-ți laptopul sau similar, și nu în Centrul de control.
NOTA: Pentru a afișa informațiile despre valori, asigurați-vă că cel puțin un monitor rulează în Centrul de control.
Tarball-ul Centru de control include arhiva paa-streaming-api-client-examples.tar.gz (ex. clientamples), care conține un exampScriptul Python care arată cum să utilizați API-ul de streaming.
Instalarea și configurarea Client Examples
Găsiți client-exampfișiere din folderul Paragon Active Assurance Control Center:
export CC_VERSION=3.3.1
cd ./paa-control-center_${CC_VERSION} ls paa-streaming-api-client-examples*
Pentru a instala client-exampfișierele de pe computerul dumneavoastră client extern, procedați după cum urmează:
# Creați director pentru extragerea conținutului clientului examples tarball mkdir paa-streaming-api-client-examples
# Extrageți conținutul clientului examples tarball tar xzf paa-streaming-api-client-examples.tar.gz -C paa-streaming-api-client-examples
# Accesați directorul nou creat cd paa-streaming-api-client-examples client-exampfișierele necesită ca Docker să ruleze. Descărcări și instrucțiuni de instalare pentru Docker pot fi găsite la https://docs.docker.com/engine/install.
Utilizarea client Examples
Clientul-exampinstrumentele pot rula fie în modul de bază, fie în modul avansat pentru a construi exampfișiere de complexitate diferită. În ambele cazuri, este, de asemenea, posibil să rulați exampfișiere cu o configurație file care conțin proprietăți suplimentare pentru personalizarea ulterioară a părții client.
Modul de bază În modul de bază, valorile și metadatele lor sunt transmise în flux separat. În acest scop, clientul ascultă fiecare subiect Kafka disponibil pentru acces extern și pur și simplu imprimă mesajele primite pe consolă.
Pentru a începe execuția exampfișiere, rulați: ./build.sh run-basic –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME
unde ACCOUNT_SHORTNAME este numele scurt al contului de la care doriți să obțineți valorile.
Pentru a înceta executarea example, apăsați Ctrl + C. (Poate exista o ușoară întârziere înainte ca execuția să se oprească, deoarece clientul așteaptă un eveniment de timeout.)
Modul avansat
NOTA: Valorile sunt afișate numai pentru monitoarele HTTP care rulează în Centrul de control.
Execuția în modul avansat arată corelația dintre valorile și mesajele cu metadate. Acest lucru este posibil datorită prezenței în fiecare mesaj de valori a unui câmp de identificare a fluxului care se referă la mesajul de metadate corespunzător.
Pentru a executa exampfișiere, rulați: ./build.sh run-advanced –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME unde ACCOUNT_SHORTNAME este numele scurt al contului de la care doriți să obțineți valorile.
Pentru a înceta executarea example, apăsați Ctrl + C. (Poate exista o ușoară întârziere înainte ca execuția să se oprească, deoarece clientul așteaptă un eveniment de timeout.)
Setări suplimentare
Este posibil să rulați exampfișiere cu configurație suplimentară a clientului folosind –config-file opțiune urmată de a file nume care conține proprietăți sub forma cheie=valoare.
./build.sh run-advanced \ –kafka-brokers localhost:9092 \ –account ACCOUNT_SHORTNAME \ –config-file client_config.properties
NOTA: Toate fileelementele la care se face referire în comanda de mai sus trebuie să fie localizate în directorul curent și referite folosind doar căi relative. Acest lucru se aplică atât la –config-file argument și la toate intrările din configurație file care descriu file locații.
Validarea autentificarea clientului extern
Pentru a valida autentificarea clientului din afara Centrului de control folosind client-example, efectuați următorii pași:

• Din folderul Paragon Active Assurance Control Center, comutați la paa-streaming-api-clientexampfolderul les:
  cd paa-streaming-api-client-examples
• Copiați certificatul rădăcină CA ca-cert în directorul curent.
• Creați un client.properties file cu urmatorul continut:
  security.protocol=SASL_SSL
  ssl.ca.location=ca-cert
  sasl.mechanism=PLAIN
  sasl.username={CLIENT_USER}
  sasl.password={CLIENT_PASSWORD}
  unde {CLIENT_USER} și {CLIENT_PASSWORD} sunt acreditările de utilizator pentru client.
• Executați de bază examples:
  exportă KAFKA_FQDN= ./build.sh run-basic –kafka-brokers ${KAFKA_FQDN}:9093 \ –account ACCOUNT_SHORTNAME
  -config-file client.properties unde ACCOUNT_SHORTNAME este numele scurt al contului de la care doriți să obțineți valorile.
• Rulați ex. avansatamples:
  exportă KAFKA_FQDN= ./build.sh run-advanced –kafka-brokers ${KAFKA_FQDN}:9093 \ –account ACCOUNT_SHORTNAME–config-file client.proprietăţi

Apendice

În această anexă descriem cum să creați:

• un depozit de chei file pentru stocarea certificatului SSL al brokerului Kafka
• un truststore file pentru stocarea certificatului rădăcină al Autorității de certificare (CA) utilizat pentru a semna certificatul de broker Kafka.

Crearea unui certificat de broker Kafka
Crearea unui certificat folosind o autoritate de certificare reală (recomandat)
Este recomandat să obțineți un certificat SSL real de la o CA de încredere.
Odată ce v-ați decis asupra unui CA, copiați certificatul rădăcină CA ca-cert file pe propria ta cale, după cum se arată mai jos:
export CA_PATH=~/my-ca mkdir ${CA_PATH} cp ca-cert ${CA_PATH}
Creați-vă propria autoritate de certificare
NOTA: În mod normal, ar trebui să aveți certificatul semnat de o autoritate de certificare reală; vezi subsecțiunea precedentă. Ceea ce urmează este doar un fostample.
Aici creăm propriul certificat rădăcină al Autorității de Certificare (CA). file valabil 999 de zile (nu este recomandat în producție):
# Creați un director pentru stocarea exportului CA CA_PATH=~/my-ca mkdir ${CA_PATH}
# Generați certificatul CA openssl req -new -x509 -keyout ${CA_PATH}/ca-key -out ${CA_PATH}/ca-cert -days 999
Crearea clientului Truststore
Acum puteți crea un truststore file care conține ca-certul generat mai sus. Acest file va fi nevoie de clientul Kafka care va accesa API-ul de streaming:
keytool -keystore kafka.client.truststore.jks \ -alias CARoot \ -importcert -file ${CA_PATH}/ca-cert
Acum că certificatul CA este în truststore, clientul va avea încredere în orice certificat semnat cu acesta.
Ar trebui să copiați file kafka.client.truststore.jks la o locație cunoscută de pe computerul dvs. client și indicați-l în setări.
Crearea Keystore pentru Kafka Broker
Pentru a genera certificatul SSL al brokerului Kafka și apoi depozitul de chei kafka.server.keystore.jks, procedați după cum urmează:
Generarea certificatului SSL
Mai jos, 999 este numărul de zile de valabilitate a depozitului de chei, iar FQDN este numele de domeniu complet calificat al clientului (numele de gazdă public al nodului).
NOTA: Este important ca FQDN-ul să se potrivească exact cu numele de gazdă pe care clientul Kafka îl va folosi pentru a se conecta la Centrul de control. sudo mkdir -p /var/ssl/private
sudo chown -R $USER: /var/ssl/private cd /var/ssl/private export FQDN=
keytool -keystore kafka.server.keystore.jks \ -alias server \ -validitate 999 \ -genkey -keyalg RSA -ext SAN=dns:${FQDN}
Creați o cerere de semnare a certificatului și stocați-o în file numit cert-server-request:
keytool -keystore kafka.server.keystore.jks \ -alias server \ -certreq \ -file Cerere-server-cert
Acum ar trebui să trimiteți file cert-server-request către Autoritatea de Certificare (CA) dacă utilizați unul real. Ei vor returna apoi certificatul semnat. Ne vom referi mai jos la aceasta drept cert-server-semnated. Semnarea certificatului SSL utilizând un certificat CA auto-creat
NOTA: Din nou, utilizarea propriei CA nu este recomandată într-un sistem de producție. Semnați certificatul folosind CA prin intermediul file cert-server-request, care produce certificatul semnat cert-server-signed. Vezi mai jos; ca-parola este parola setată la crearea certificatului 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 \ -zile 999 -CAcreateserial \ -passin pass:{ca-parola}
Importarea certificatului semnat în Keystore
Importați certificatul rădăcină ca-cert în depozitul de chei:
keytool -keystore kafka.server.keystore.jks \ -alias ca-cert \ -import \ -file ${CA_PATH}/ca-cert
Importați certificatul semnat, denumit certificat-server-semnat:
keytool -keystore kafka.server.keystore.jks \ -alias server \ -import \ -file certificat-server-semnat
The file kafka.server.keystore.jks ar trebui copiat într-o locație cunoscută de pe serverul Centrului de control și apoi menționat în /etc/kafka/server.properties.
Folosind API-ul de streaming

General

API-ul de streaming preia atât datele de testare, cât și cele de monitorizare. Nu este posibil să se evidențieze una dintre aceste categorii.
API-ul de streaming nu preia date din testele bazate pe script (cele reprezentate printr-un dreptunghi în loc de o piesă puzzle în GUI Control Center), cum ar fi testele de activare a serviciului Ethernet și testele de transparență.
Nume de subiecte Kafka
Numele subiectelor Kafka pentru API-ul de streaming sunt după cum urmează, unde %s este numele scurt al controlului
Cont de centru (indicat la crearea contului):
const (exporterName = „kafka”metadataTopicTpl = „paa.public.accounts.%s.metadata” metricsTopicTpl = „paa.public.accounts.%s.metrics”)
Exampfișierele de utilizare a API-ului de streaming
Exampfișierele care urmează se găsesc în tarball-ul paa-streaming-api-client-examples.tar.gz conținut în tarball-ul Centrului de control.
În primul rând, există un ex de bazăample demonstrează cum valorile și metadatele lor sunt transmise în flux separat și pur și simplu tipăriți mesajele primite pe consolă. Îl puteți rula după cum urmează: sudo ./build.sh run-basic –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME
Există și un ex mai avansatampchiul unde valorile și mesajele de metadate sunt corelate. Utilizați această comandă pentru a o executa:
sudo ./build.sh run-advanced –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME Trebuie să utilizați sudo pentru a rula comenzi Docker, cum ar fi cele de mai sus. Opțional, puteți urma pașii de post-instalare Linux pentru a putea rula comenzi Docker fără sudo.
Pentru detalii, accesați docs.docker.com/engine/install/linux-postinstall.
Juniper Networks, sigla Juniper Networks, Juniper și Junos sunt mărci comerciale înregistrate ale Juniper Networks, Inc. în Statele Unite și în alte țări. Toate celelalte mărci comerciale, mărci de servicii, mărci înregistrate sau mărci de servicii înregistrate sunt proprietatea deținătorilor respectivi. Juniper Networks nu își asumă nicio responsabilitate pentru eventualele inexactități din acest document. Juniper Networks își rezervă dreptul de a schimba, modifica, transfera sau revizui în alt mod această publicație fără notificare. Copyright © 2022 Juniper Networks, Inc. Toate drepturile rezervate.

Documente/Resurse

Juniper Streaming API [pdfGhid de utilizare API de streaming, API

Referințe

• Manual de utilizare