
Teknisk enkelhet
Streaming API-veiledning
Introduksjon
Denne guiden beskriver hvordan du trekker ut data fra Paragon Active Assurance via produktets streaming-API.
API så vel som strømmeklienten er inkludert i Paragon Active Assurance-installasjonen.
Det er imidlertid nødvendig med litt konfigurasjon før du kan bruke API. Dette er dekket i kapittelet "Konfigurere Streaming API" på side 1.
Overview
Dette kapittelet beskriver hvordan du konfigurerer Streaming API for å tillate abonnement på metrikkmeldinger via Kafka.
Nedenfor skal vi gå gjennom:
- Slik aktiverer du Streaming API
- Hvordan konfigurere Kafka til å lytte til eksterne klienter
- Hvordan konfigurere Kafka til å bruke ACLer og sette opp SSL-kryptering for nevnte klienter
Hva er Kafka?
Kafka er en event-streaming-plattform som tillater sanntidsfangst av data sendt fra ulike hendelseskilder (sensorer, databaser, mobile enheter) i form av hendelsesstrømmer, samt varig lagring av disse hendelsesstrømmene for senere henting og manipulering.
Med Kafka er det mulig å administrere hendelsesstrømmingen ende-til-ende på en distribuert, svært skalerbar, elastisk, feiltolerant og sikker måte.
NOTE: Kafka kan konfigureres på mange forskjellige måter og ble designet for skalerbarhet og redundante systemer. Dette dokumentet fokuserer kun på hvordan du konfigurerer det til å bruke Streaming API-funksjonen som finnes i Paragon Active Assurance Control Center. For mer avanserte oppsett henviser vi til den offisielle Kafka-dokumentasjonen: kafka.apache.org/26/documentation.html.
Terminologi
- Kafka: Event-streaming-plattform.
- Kafka-emne: Samling av hendelser.
- Kafka-abonnent/forbruker: Komponent ansvarlig for henting av hendelser som er lagret i et Kafka-emne.
- Kafka-megler: Lagringslagsserver til en Kafka-klynge.
- SSL/TLS: SSL er en sikker protokoll utviklet for å sende informasjon sikkert over Internett. TLS er etterfølgeren til SSL, introdusert i 1999.
- SASL: Rammeverk som gir mekanismer for brukerautentisering, kontroll av dataintegritet og kryptering.
- Streaming API-abonnent: Komponent som er ansvarlig for henting av hendelser lagret i emner definert i Paragon Active Assurance og ment for ekstern tilgang.
- Sertifiseringsinstans: En klarert enhet som utsteder og tilbakekaller offentlige nøkkelsertifikater.
- Sertifiseringsinstans rotsertifikat: Offentlig nøkkelsertifikat som identifiserer en sertifiseringsinstans.
Hvordan Streaming API fungerer
Som tidligere nevnt lar Streaming API eksterne klienter hente informasjon om beregninger fra Kafka.
Alle beregninger som samles inn av testagentene under en test- eller overvåkingsoppgave, sendes til Stream-tjenesten.
Etter en behandlingsfase publiserer Stream-tjenesten disse beregningene på Kafka sammen med ytterligere metadata.

Kafka-emner
Kafka har konseptet med emner som all data er publisert til. I Paragon Active Assurance er det mange slike Kafka-emner tilgjengelig; Imidlertid er bare et undersett av disse ment for ekstern tilgang.
Hver Paragon Active Assurance-konto i kontrollsenteret har to dedikerte emner. Nedenfor er ACCOUNT kontoens korte navn:
- paa.public.accounts.{ACCOUNT}.metrics
- Alle beregningsmeldinger for den gitte kontoen er publisert til dette emnet
- Store mengder data
- Høy oppdateringsfrekvens
- paa.public.accounts.{ACCOUNT}.metadata
- Inneholder metadata relatert til metrikkdataene, for eksempelample testen, monitoren eller testagenten knyttet til beregningene
- Små mengder data
- Lav oppdateringsfrekvens
Aktivering av Streaming API
NOTE: Disse instruksjonene skal kjøres på Control Center-serveren med sudo.
Siden Streaming API legger til noen overhead til kontrollsenteret, er det ikke aktivert som standard. For å aktivere API, må vi først aktivere publisering av beregninger til Kafka i hovedkonfigurasjonen file:
- /etc/netrounds/netrounds.conf
KAFKA_METRICS_ENABLED = Sant
ADVARSEL: Aktivering av denne funksjonen kan påvirke ytelsen til kontrollsenteret. Sørg for at du har dimensjonert instansen din deretter.
Deretter, for å aktivere videresending av disse beregningene til de riktige Kafka-emnene: - /etc/netrounds/metrics.yaml
streaming-api: sant
For å aktivere og starte Streaming API-tjenestene, kjør:
sudo ncc-tjenester aktiverer timescaledb-beregninger sudo ncc-tjenester starter timescaledb-beregninger
Til slutt, start tjenestene på nytt:
sudo ncc-tjenester starter på nytt
Kontrollerer at Streaming API fungerer i kontrollsenteret
NOTE: Disse instruksjonene skal kjøres på kontrollsenterserveren.
Du kan nå bekrefte at du mottar beregninger om de riktige Kafka-emnene. For å gjøre det, installer kafkacat-verktøyet:
sudo apt-get update sudo apt-get install kafkacat
Hvis du har en test eller skjerm som kjører i kontrollsenteret, bør du kunne bruke kafkacat for å motta beregninger og metadata om disse emnene.
Erstatt myaccount med det korte navnet på kontoen din (dette er det du ser i kontrollsenteret ditt URL):
eksport METRICS_TOPIC=paa.public.accounts.myaccount.metrics
eksport METADATA_TOPIC=paa.public.accounts.myaccount.metadata
Du bør nå se beregninger ved å kjøre denne kommandoen:
kafkacat -b ${KAFKA_FQDN}:9092 -t ${METRICS_TOPIC} -C -e
Til view metadata, kjør følgende kommando (merk at dette ikke vil oppdateres så ofte):
kafkacat -b ${KAFKA_FQDN}:9092 -t ${METADATA_TOPIC} -C -e
NOTE:
kafkacat” Kundeeksamples ”på side 14
Dette bekrefter at vi har et fungerende Streaming API fra kontrollsenteret. Men mest sannsynlig er du interessert i å få tilgang til dataene fra en ekstern klient i stedet. Den neste delen beskriver hvordan du åpner Kafka for ekstern tilgang.
Åpner Kafka for eksterne verter
NOTE: Disse instruksjonene skal kjøres på kontrollsenterserveren.
Som standard er Kafka som kjører på kontrollsenteret konfigurert til kun å lytte på localhost for intern bruk.
Det er mulig å åpne Kafka for eksterne klienter ved å endre Kafka-innstillingene.
Koble til Kafka: Caveats
FORSIKTIGHET: Vennligst les dette nøye, siden det er lett å støte på tilkoblingsproblemer med Kafka hvis du ikke har forstått disse konseptene.
I kontrollsenteroppsettet beskrevet i dette dokumentet er det bare en enkelt Kafka-megler.
Vær imidlertid oppmerksom på at en Kafka-megler er ment å kjøre som en del av en Kafka-klynge som kan bestå av mange Kafka-meglere.
Når du kobler til en Kafka-megler, settes en første tilkobling opp av Kafka-klienten. I denne forbindelse vil Kafka-megleren på sin side returnere en liste over "annonserte lyttere", som er en liste over en eller flere Kafka-meglere.
Ved mottak av denne listen vil Kafka-klienten koble fra, og deretter koble til en av disse annonserte lytterne igjen. De annonserte lytterne må inneholde vertsnavn eller IP-adresser som er tilgjengelige for Kafka-klienten, ellers vil klienten ikke koble til.
Hvis SSL-kryptering brukes, som involverer et SSL-sertifikat som er knyttet til et bestemt vertsnavn, er det enda viktigere at Kafka-klienten mottar riktig adresse å koble til, siden ellers tilkoblingen kan bli avvist.
Les mer om Kafka-lyttere her: www.confluent.io/blog/kafka-listeners-explained
SSL/TLS-kryptering
For å sikre at bare pålitelige klienter har tilgang til Kafka og Streaming API, må vi konfigurere følgende:
- Autentisering: Klienter må oppgi brukernavn og passord gjennom en SSL/TLS sikker forbindelse mellom klienten og Kafka.
- Autorisasjon: Autentiserte klienter kan utføre oppgaver regulert av ACLer.
Her er en overview:

*) Brukernavn/passordautentisering utført på en SSL-kryptert kanal
For å forstå hvordan SSL/TLS-krypteringen fungerer for Kafka, vennligst se den offisielle dokumentasjonen: docs.confluent.io/platform/current/kafka/encryption.html
SSL/TLS-sertifikat overview
NOTE: I denne underdelen vil vi bruke følgende terminologi:
Sertifikat: Et SSL-sertifikat signert av en sertifiseringsinstans (CA). Hver Kafka-megler har en.
Nøkkellager: Nøkkellageret file som lagrer sertifikatet. Nøkkellageret file inneholder den private nøkkelen til sertifikatet; derfor må den oppbevares trygt.
Truststore: A file som inneholder de klarerte CA-sertifikatene.
For å sette opp autentiseringen mellom en ekstern klient og Kafka som kjører i Kontrollsenter, må begge sider ha et nøkkellager definert med et relatert sertifikat signert av en sertifiseringsinstans (CA) sammen med CA-rotsertifikatet.
I tillegg til dette må klienten også ha en truststore med CA-rotsertifikatet.
CA-rotsertifikatet er felles for Kafka-megleren og Kafka-klienten.
Opprette de nødvendige sertifikatene
Dette er dekket i "Vedlegg" på side 17.
Kafka Broker SSL/TLS-konfigurasjon i kontrollsenteret
NOTE: Disse instruksjonene skal kjøres på kontrollsenterserveren.
NOTE: Før du fortsetter, må du opprette nøkkellageret som inneholder SSL-sertifikatet ved å følge instruksjonene i "Vedlegg" på side 17. Stiene nevnt nedenfor kommer fra disse instruksjonene.
SSL-nøkkellageret er en file lagret på disk med file utvidelse .jks.
Når du har de nødvendige sertifikatene opprettet for både Kafka-megleren og Kafka-klienten tilgjengelig, kan du fortsette ved å konfigurere Kafka-megleren som kjører i Kontrollsenter. Du må vite følgende:
- : Det offentlige vertsnavnet til kontrollsenteret; dette må være løst og tilgjengelig for Kafka-kunder.
- : Nøkkellagerpassordet som ble oppgitt når du opprettet SSL-sertifikatet.
- og : Dette er passordene du vil angi for henholdsvis admin og klientbruker.
Merk at du kan legge til flere brukere, som angitt i eksample.
Rediger eller legg til (med sudo-tilgang) egenskapene nedenfor i /etc/kafka/server.properties, og sett inn variablene ovenfor som vist:
ADVARSEL: Ikke fjern PLAINTEXT://localhost:9092 ; dette vil bryte kontrollsenterfunksjonaliteten siden interne tjenester ikke vil kunne kommunisere.
…# Adressene som Kafka-megleren lytter til.
listeners=PLAINTEXT://localhost:9092,SASL_SSL://0.0.0.0:9093
# Dette er vertene som annonseres tilbake til enhver klient som kobler til.
advertised.listeners=PLAINTEXT://localhost:9092,SASL_SSL:// :9093…
####### CUSTOM CONFIG
# SSL KONFIGURASJON
ssl.endpoint.identification.algorithm=
ssl.keystore.location=/var/ssl/private/kafka.server.keystore.jks
ssl.keystore.password=
ssl.key.password=
ssl.client.auth=ingen
ssl.protocol=TLSv1.2
# SASL-konfigurasjon sasl.enabled.mechanisms=PLAIN
listener.name.sasl_ssl.plain.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginMo dule kreves \ brukernavn=”admin” \ passord=” ” \ user_admin=” " \ user_client =" "; # MERK flere brukere kan legges til med user_ =
# Autorisasjon, slå på ACLs authorizer.class.name=kafka.security.authorizer.AclAuthorizer super.users=Bruker:admin
Sette opp tilgangskontrolllister (ACLs)
Slå på tilgangskontrollister på localhost
ADVARSEL: Vi må først sette opp ACLer for localhost, slik at Control Center selv fortsatt kan få tilgang til Kafka. Hvis dette ikke blir gjort, vil ting gå i stykker.
######### ACLs oppføringer for anonyme brukere
/usr/lib/kafka/bin/kafka-acls.sh \
–authorizer kafka.security.authorizer.AclAuthorizer \ –authorizer-properties zookeeper.connect=localhost:2181 \ –add –allow-principal Bruker: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 Bruker:ANONYM –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 Bruker:ANONYMOUS –allow-host 127.0.0.1 –gruppe '*'
Vi må da aktivere ACLer for ekstern skrivebeskyttet tilgang, slik at eksterne brukere kan lese paa.public.*-emnene.
NOTE: For mer finkornet kontroll, se den offisielle Kafka-dokumentasjonen.
######### ACLs oppføringer for eksterne brukere
/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 \–gruppe 'NCC'
/usr/lib/kafka/bin/kafka-acls.sh \
–authorizer kafka.security.authorizer.AclAuthorizer \
–authorizer-properties zookeeper.connect=localhost:2181 \
–add –allow-principal Bruker:* –operasjon les –operasjonsbeskriv \
–topic paa.public. –resource-pattern-type prefiks
Når du er ferdig med dette, må du starte tjenestene på nytt:
sudo ncc-tjenester starter på nytt
For å bekrefte at en klient kan opprette en sikker tilkobling, kjør følgende kommando på en ekstern klientdatamaskin (ikke på kontrollsenterserveren). Nedenfor er PUBLIC_HOSTNAME vertsnavnet for kontrollsenteret:
openssl s_client -debug -connect ${PUBLIC_HOSTNAME}:9093 -tls1_2 | grep "Sikker reforhandling støttes"
I kommandoutgangen bør du se serversertifikatet samt følgende:
Sikker reforhandling støttes
For å sikre at interne tjenester har fått tilgang til Kafka-serveren, vennligst sjekk følgende loggfiles:
Validerer ekstern klienttilkobling
kafkacat
NOTE: Disse instruksjonene skal kjøres på en klientdatamaskin (ikke på Control Center-serveren).
NOTE: For å vise metrikkinformasjon, sørg for at minst én skjerm kjører i kontrollsenteret.
For å verifisere og validere tilkobling som en ekstern klient, er det mulig å bruke kafkacat-verktøyet som ble installert i avsnittet "Bekrefte at Streaming API fungerer i kontrollsenteret" på side 4.
Utfør følgende trinn:
NOTE: Nedenfor er CLIENT_USER brukeren som tidligere er spesifisert i file /etc/kafka/server.properties i
Kontrollsenter: nemlig user_client og passordet som er satt der.
CA-rotsertifikatet som brukes til å signere SSL-sertifikatet på serversiden må være til stede på klienten.
- Lag en file client.properties med følgende innhold:
security.protocol=SASL_SSL
ssl.ca.location={PATH_TO_CA_CERT}
sasl.mechanisms=PLAIN
sasl.username={CLIENT_USER}
sasl.password={CLIENT_PASSWORD} hvor
• {PATH_TO_CA_CERT} er plasseringen av CA-rotsertifikatet som brukes av Kafka-megleren
• {CLIENT_USER} og {CLIENT_PASSWORD} er brukerlegitimasjonen for klienten.
• Kjør følgende kommando for å se meldingen konsumert av kafkacat:
eksport KAFKA_FQDN=
eksport METRICS_TOPIC=paa.public.accounts. .metrics
kafkacat -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -e
hvor {METRICS_TOPIC} er navnet på Kafka-emnet med prefikset "paa.public".
NOTE: Eldre versjoner av kafkacat gir ikke -F-alternativet for å lese klientinnstillingene fra en file. Hvis du bruker en slik versjon, må du angi de samme innstillingene fra kommandolinjen som vist nedenfor.
kafkacat -b ${KAFKA_FQDN}:9093 \
-X security.protocol=SASL_SSL \
-X ssl.ca.location={PATH_TO_CA_CERT} \
-X sasl.mechanisms=PLAIN \
-X sasl.brukernavn={CLIENT_USER} \
-X sasl.password={CLIENT_PASSWORD} \
-t ${METRICS_TOPIC} -C -e
For å feilsøke tilkoblingen kan du bruke alternativet -d:
Feilsøke forbrukerkommunikasjon
kafkacat -d forbruker -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -e
# Feilsøk meglerkommunikasjon
kafkacat -d megler -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -e
Sørg for å referere til dokumentasjonen for Kafka-klientbiblioteket som er i bruk, siden egenskapene kan avvike fra de i client.properties.
Meldingsformat
Meldingene som brukes for metrikkene og metadataemnene er serialisert i formatet Protocol buffers (protobuf) (se developers.google.com/protocol-buffers). Skjemaene for disse meldingene følger følgende format:
Metrics Protobuf Schema
syntaks = "proto3"; importer "google/protobuf/timestamp.proto"; pakke paa.streamingapi; option go_package = “.;paa_streamingapi”; melding Metrics { google.protobuf.Timestamp tidestamp = 1; kart verdier = 2; int32 measurement_id = 3; } /** * En metrisk verdi kan enten være et heltall eller en flytende. */
melding MetricValue { oneof type { int64 int_val = 1; float float_val = 2; } }
Metadata Protobuf-skjema
syntaks = "proto3"; pakke paa.streamingapi; option go_package = “.;paa_streamingapi”; melding Metadata { int32 measurement_id = 1; streng målenavn = 2; kart tags = 13; }
Kunde Eksamples
NOTE: Disse kommandoene er ment å kjøre på en ekstern klient, for eksempelampla den bærbare datamaskinen eller lignende, og ikke i kontrollsenteret.
NOTE: For å få vist metrikkinformasjon, sørg for at minst én skjerm kjører i kontrollsenteret.
Kontrollsenter-tarballen inkluderer arkivet paa-streaming-api-client-examples.tar.gz (klient-eksamples), som inneholder en eksampet Python-skript som viser hvordan du bruker Streaming API.
Installere og konfigurere klienteksamples
Du finner klient-eksamples i Paragon Active Assurance Control Center-mappen:
eksporter CC_VERSION=3.3.1
cd ./paa-control-center_${CC_VERSION} ls paa-streaming-api-client-examples*
For å installere klient-examples på din eksterne klientdatamaskin, fortsett som følger:
# Opprett katalog for å trekke ut innholdet til klienten eksamples tarball mkdir paa-streaming-api-client-examples
# Trekk ut innholdet til klienten eksamples tarball tar xzf paa-streaming-api-client-examples.tar.gz -C paa-streaming-api-client-examples
# Gå til den nyopprettede katalogen cd paa-streaming-api-client-examples klient-eksamples krever Docker for å kjøre. Nedlastinger og installasjonsinstruksjoner for Docker finner du på https://docs.docker.com/engine/install.
Ved å bruke klienteksamples
Klienten-eksamples-verktøy kan kjøres i enten grunnleggende eller avansert modus for å bygge eksamples av ulik kompleksitet. I begge tilfeller er det også mulig å kjøre examples med en konfigurasjon file som inneholder tilleggsegenskaper for ytterligere tilpasning av klientsiden.
Grunnleggende modus I grunnleggende modus strømmes beregningene og deres metadata separat. For dette formål lytter klienten til hvert Kafka-emne som er tilgjengelig for ekstern tilgang og skriver ganske enkelt ut de mottatte meldingene til konsollen.
For å starte utførelse av den grunnleggende eksamples, kjør: ./build.sh run-basic –kafka-brokers localhost:9092 –konto ACCOUNT_SHORTNAME
der ACCOUNT_SHORTNAME er det korte navnet på kontoen du vil hente beregningene fra.
For å avslutte henrettelsen av eksample, trykk Ctrl + C. (Det kan være en liten forsinkelse før utførelsen stopper fordi klienten venter på en timeout-hendelse.)
Avansert modus
NOTE: Beregninger vises bare for HTTP-monitorer som kjører i kontrollsenteret.
Utførelse i avansert modus viser korrelasjonen mellom metrikk og metadatameldinger. Dette er mulig takket være tilstedeværelsen i hver metrikkmelding av et strøm-id-felt som refererer til den tilsvarende metadatameldingen.
For å utføre den avanserte eksamples, run: ./build.sh run-advanced –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME der ACCOUNT_SHORTNAME er det korte navnet på kontoen du vil hente beregningene fra.
For å avslutte henrettelsen av eksample, trykk Ctrl + C. (Det kan være en liten forsinkelse før utførelsen stopper fordi klienten venter på en timeout-hendelse.)
Ytterligere innstillinger
Det er mulig å kjøre examples med ekstra konfigurasjon av klienten ved å bruke –config-file alternativ etterfulgt av en file navn som inneholder egenskaper i formen nøkkel=verdi.
./build.sh run-advanced \ –kafka-brokers localhost:9092 \ –account ACCOUNT_SHORTNAME \ –config-file client_config.properties
NOTE: Alle files referert til i kommandoen ovenfor må være plassert i den gjeldende katalogen og henvist kun ved hjelp av relative stier. Dette gjelder både for –config-file argument og til alle oppføringer i konfigurasjonen file som beskriver file steder.
Validerer ekstern klientautentisering
For å validere klientautentisering utenfor kontrollsenteret ved hjelp av klient-examples, utfør følgende trinn:
- Fra Paragon Active Assurance Control Center-mappen bytter du til paa-streaming-api-clientexamples mappe:
cd paa-streaming-api-klient-eksamples - Kopier CA-rotsertifikatet ca-cert til gjeldende katalog.
- Opprett en client.properties file med følgende innhold:
security.protocol=SASL_SSL
ssl.ca.location=ca-cert
sasl.mechanism=PLAIN
sasl.username={CLIENT_USER}
sasl.password={CLIENT_PASSWORD}
der {CLIENT_USER} og {CLIENT_PASSWORD} er brukerlegitimasjonen for klienten. - Kjør grunnleggende eksamples:
eksport KAFKA_FQDN= ./build.sh run-basic –kafka-brokers ${KAFKA_FQDN}:9093 \ –konto ACCOUNT_SHORTNAME
–config-file client.properties der ACCOUNT_SHORTNAME er det korte navnet på kontoen du vil hente beregningene fra. - Kjør avansert eksamples:
eksport KAFKA_FQDN= ./build.sh run-advanced –kafka-brokers ${KAFKA_FQDN}:9093 \ –account ACCOUNT_SHORTNAME–config-file klient.egenskaper
Vedlegg
I dette vedlegget beskriver vi hvordan du lager:
- et nøkkellager file for lagring av Kafka meglers SSL-sertifikat
- en tillitsbutikk file for lagring av Certificate Authority (CA) rotsertifikat som brukes til å signere Kafka meglersertifikatet.
Opprette et Kafka meglersertifikat
Opprette et sertifikat ved hjelp av en ekte sertifiseringsinstans (anbefalt)
Det anbefales at du får et ekte SSL-sertifikat fra en klarert CA.
Når du har bestemt deg for en CA, kopierer du CA-rotsertifikatet ca-cert file til din egen vei som vist nedenfor:
eksport CA_PATH=~/my-ca mkdir ${CA_PATH} cp ca-cert ${CA_PATH}
Opprett din egen sertifiseringsinstans
NOTE: Normalt bør du få sertifikatet ditt signert av en ekte sertifiseringsinstans; se foregående underavsnitt. Det som følger er bare en eksample.
Her lager vi vårt eget Certificate Authority (CA) rotsertifikat file gyldig i 999 dager (anbefales ikke i produksjon):
# Opprett en katalog for lagring av CA-eksporten CA_PATH=~/my-ca mkdir ${CA_PATH}
# Generer CA-sertifikatet openssl req -new -x509 -keyout ${CA_PATH}/ca-key -out ${CA_PATH}/ca-cert -days 999
Opprette Client Truststore
Nå kan du opprette en truststore file som inneholder ca-sertifikatet generert ovenfor. Dette file vil være nødvendig av Kafka-klienten som vil få tilgang til Streaming API:
keytool -keystore kafka.client.truststore.jks \ -alias CARoot \ -importcert -file ${CA_PATH}/ca-cert
Nå som CA-sertifikatet er i truststore, vil klienten stole på ethvert sertifikat som er signert med det.
Du bør kopiere file kafka.client.truststore.jks til en kjent plassering på klientdatamaskinen og pek på den i innstillingene.
Opprette nøkkellageret for Kafka-megleren
For å generere Kafka megler SSL-sertifikatet og deretter nøkkellageret kafka.server.keystore.jks, fortsett som følger:
Generering av SSL-sertifikatet
Nedenfor er 999 antall dager med gyldighet for nøkkellageret, og FQDN er det fullt kvalifiserte domenenavnet til klienten (offentlig vertsnavn for noden).
NOTE: Det er viktig at FQDN samsvarer med det eksakte vertsnavnet som Kafka-klienten vil bruke for å koble til kontrollsenteret. sudo mkdir -p /var/ssl/private
sudo chown -R $USER: /var/ssl/privat cd /var/ssl/privat eksport FQDN=
keytool -keystore kafka.server.keystore.jks \ -alias server \ -validity 999 \ -genkey -keyalg RSA -ext SAN=dns:${FQDN}
Opprett en forespørsel om sertifikatsignering og lagre den i file kalt cert-server-request:
keytool -keystore kafka.server.keystore.jks \ -alias server \ -certreq \ -file cert-server-request
Du bør nå sende file cert-server-request til sertifiseringsmyndigheten (CA) hvis du bruker en ekte. De vil da returnere det signerte sertifikatet. Vi vil referere til dette som cert-server-signert nedenfor. Signere SSL-sertifikatet ved å bruke et selvlaget CA-sertifikat
NOTE: Igjen, bruk av din egen CA anbefales ikke i et produksjonssystem. Signer sertifikatet ved hjelp av CA ved hjelp av file cert-server-request, som produserer det signerte sertifikatet cert-server-signed. Se nedenfor; ca-passord er passordet som ble satt når du oppretter CA-sertifikatet.
cd /var/ssl/private openssl x509 -req \ -CA ${CA_PATH}/ca-cert \ -CAkey ${CA_PATH}/ca-key \ -in cert-server-request \ -out cert-server-signed \ -days 999 -CAcreateserial \ -passin pass:{ca-password}
Importerer det signerte sertifikatet til nøkkellageret
Importer ca-cert rotsertifikatet til nøkkellageret:
keytool -keystore kafka.server.keystore.jks \ -alias ca-cert \ -import \ -file ${CA_PATH}/ca-cert
Importer det signerte sertifikatet referert til som cert-server-signed:
keytool -keystore kafka.server.keystore.jks \ -alias server \ -import \ -file cert-server-signert
De file kafka.server.keystore.jks skal kopieres til en kjent plassering på kontrollsenterserveren, og deretter refereres til i /etc/kafka/server.properties.
Bruke Streaming API
General
Streaming API henter både test- og overvåkingsdata. Det er ikke mulig å skille ut en av disse kategoriene.
Streaming-API-en henter ikke data fra skriptbaserte tester (de som er representert av et rektangel i stedet for et stikksag i Control Center GUI), for eksempel Ethernet-tjenesteaktiveringstester og gjennomsiktighetstester.
Kafka-emnenavn
Kafka-emnenavnene for streaming-API er som følger, hvor %s er det korte navnet på kontrollen
Senterkonto (angitt når du oppretter kontoen):
const (exporterName = “kafka”metadataTopicTpl = “paa.public.accounts.%s.metadata” metricsTopicTpl = “paa.public.accounts.%s.metrics”)
Examples om bruk av Streaming API
Eksamples som følger finnes i tarball paa-streaming-api-client-examples.tar.gz inneholdt i kontrollsenterets tarball.
For det første er det et grunnleggende eksample som demonstrerer hvordan metrikkene og deres metadata streames separat og ganske enkelt skrive ut de mottatte meldingene til konsollen. Du kan kjøre det som følger: sudo ./build.sh run-basic –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME
Det er også en mer avansert eksample hvor beregninger og metadatameldinger er korrelert. Bruk denne kommandoen for å kjøre den:
sudo ./build.sh run-advanced –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME Du må bruke sudo for å kjøre Docker-kommandoer som de ovenfor. Eventuelt kan du følge Linux-trinnene etter installasjonen for å kunne kjøre Docker-kommandoer uten sudo.
For detaljer, gå til docs.docker.com/engine/install/linux-postinstall.
Juniper Networks, Juniper Networks-logoen, Juniper og Junos er registrerte varemerker for Juniper Networks, Inc. i USA og andre land. Alle andre varemerker, servicemerker, registrerte merker eller registrerte servicemerker tilhører deres respektive eiere. Juniper Networks påtar seg intet ansvar for eventuelle unøyaktigheter i dette dokumentet. Juniper Networks forbeholder seg retten til å endre, modifisere, overføre eller på annen måte revidere denne publikasjonen uten varsel. Copyright © 2022 Juniper Networks, Inc. Alle rettigheter forbeholdt.

Dokumenter / Ressurser
![]() | Streaming API |
Referanser
- Brukerhåndbokmanual.tools
