Oprogramowanie API do przesyłania strumieniowego Juniper NETWORKS

Informacje o produkcie

Specyfikacje

• Nazwa produktu: Paragon Active Assurance
• Wersja: 4.1
• Data publikacji: 2023-03-15

Wstęp:
W tym przewodniku znajdują się instrukcje dotyczące sposobu wyodrębniania danych z Paragon Active Assurance przy użyciu interfejsu API przesyłania strumieniowego produktu. Klient przesyłania strumieniowego i interfejs API są zawarte w instalacji Paragon Active Assurance, ale przed użyciem interfejsu API wymagana jest pewna konfiguracja. Proces konfiguracji jest omówiony w sekcji „Konfigurowanie interfejsu API przesyłania strumieniowego”.

Konfigurowanie interfejsu API przesyłania strumieniowego:
Poniższe kroki przedstawiają proces konfiguracji interfejsu API przesyłania strumieniowego:

Nadview
Kafka to platforma strumieniowania zdarzeń zaprojektowana do przechwytywania i przechowywania danych w czasie rzeczywistym z różnych źródeł. Umożliwia zarządzanie strumieniami zdarzeń w sposób rozproszony, skalowalny, odporny na błędy i bezpieczny. Ten przewodnik koncentruje się na konfiguracji Kafki w celu wykorzystania funkcji Streaming API w Paragon Active Assurance Control Center.

Terminologia
Interfejs API przesyłania strumieniowego umożliwia klientom zewnętrznym pobieranie informacji metryk z Kafki. Metryki zebrane przez agentów testowych podczas zadania testowego lub monitorującego są wysyłane do usługi Stream. Po przetworzeniu usługa Stream publikuje te metryki w Kafce wraz z dodatkowymi metadanymi.

Włączanie interfejsu API przesyłania strumieniowego
Aby włączyć API przesyłania strumieniowego, wykonaj następujące kroki:

1. Uruchom następujące polecenia na serwerze Centrum sterowania za pomocą sudo:

KAFKA_METRICS_ENABLED = Prawda sudo ncc services enable timescaledb metrics sudo ncc services start timescaledb metrics sudo ncc services restart

Sprawdzanie, czy interfejs API przesyłania strumieniowego działa w Centrum sterowania:
Aby sprawdzić, czy otrzymujesz dane metryczne dotyczące właściwych tematów Kafki:

1. Zainstaluj narzędzie Kafkacat za pomocą następujących poleceń:
   sudo apt-get update
   sudo apt-get zainstaluj kafkacat

2. Zastąp „myaccount” krótką nazwą swojego konta w
   Centrum sterowania URL:
   eksportuj METRICS_TOPIC=paa.public.accounts.myaccount.metrics
   eksportuj METADATA_TOPIC=paa.public.accounts.myaccount.metadata

3. Uruchom następujące polecenie, aby view metryka:
   kafkacat -b ${KAFKA_FQDN}:9092 -t ${METRICS_TOPIC} -C -e
   Notatka:Powyższe polecenie wyświetli metryki.
4. Do view metadane, uruchom następujące polecenie:
   kafkacat -b ${KAFKA_FQDN}:9092 -t ${METADATA_TOPIC} -C -e

Notatka:Powyższe polecenie wyświetli metadane, ale nie będą one aktualizowane tak często.

Klient Examples
Dla byłego klientaampWięcej informacji znajdziesz na stronie 14 instrukcji obsługi.

FAQ (najczęściej zadawane pytania)

• P: Czym jest Paragon Active Assurance?
  A: Paragon Active Assurance to produkt zapewniający możliwości monitorowania i testowania.
• P: Czym jest API strumieniowe?
  A: Interfejs API przesyłania strumieniowego to funkcja Paragon Active Assurance umożliwiająca klientom zewnętrznym pobieranie informacji o metrykach z Kafki.
• P: Jak włączyć API przesyłania strumieniowego?
  A: Aby włączyć interfejs API przesyłania strumieniowego, wykonaj czynności opisane w sekcji „Włączanie interfejsu API przesyłania strumieniowego” w podręczniku użytkownika.
• P: Jak mogę sprawdzić, czy API przesyłania strumieniowego działa?
  A: Instrukcje dotyczące sposobu weryfikacji funkcjonalności interfejsu API przesyłania strumieniowego można znaleźć w sekcji „Weryfikacja działania interfejsu API przesyłania strumieniowego w Centrum sterowania”.

Wstęp

W tym przewodniku opisano, jak wyodrębnić dane z Paragon Active Assurance za pośrednictwem interfejsu API przesyłania strumieniowego produktu.
API, jak również klient strumieniowy są zawarte w instalacji Paragon Active Assurance. Jednak przed użyciem API wymagana jest pewna konfiguracja. Jest to omówione w rozdziale „Konfigurowanie API strumieniowego” na stronie 1.

Nadview
W tym rozdziale opisano, jak skonfigurować interfejs API przesyłania strumieniowego, aby umożliwić subskrybowanie komunikatów metryk za pośrednictwem platformy Kafka.
pr
Poniżej omówimy:

• Jak włączyć interfejs API przesyłania strumieniowego
• Jak skonfigurować Kafkę do nasłuchiwania klientów zewnętrznych
• Jak skonfigurować Kafkę do korzystania z list ACL i skonfigurować szyfrowanie SSL dla wspomnianych klientów

Co to jest Kafka?
Kafka to platforma do strumieniowego przesyłania zdarzeń, która umożliwia przechwytywanie w czasie rzeczywistym danych przesyłanych z różnych źródeł zdarzeń (czujniki, bazy danych, urządzenia mobilne) w postaci strumieni zdarzeń, a także trwałe przechowywanie tych strumieni zdarzeń w celu późniejszego wyszukiwania i manipulacji.
Dzięki Kafce możliwe jest kompleksowe zarządzanie strumieniowaniem zdarzeń w sposób rozproszony, wysoce skalowalny, elastyczny, odporny na błędy i bezpieczny.

NOTATKA: Kafka może być konfigurowana na wiele różnych sposobów i została zaprojektowana dla skalowalności i redundantnych systemów. Ten dokument koncentruje się tylko na tym, jak skonfigurować ją, aby wykorzystać funkcję Streaming API dostępną w Paragon Active Assurance Control Center. Aby uzyskać bardziej zaawansowane konfiguracje, zapoznaj się z oficjalną dokumentacją Kafka: kafka.apache.org/26/documentation.html.

Terminologia

• Kafka: platforma do strumieniowego przesyłania wydarzeń.
• Temat Kafki: Zbiór zdarzeń.
• Abonent/konsument Kafki: Komponent odpowiedzialny za pobieranie zdarzeń przechowywanych w temacie Kafki.
• Broker Kafka: serwer warstwy pamięci masowej klastra Kafka.
• SSL/TLS: SSL to bezpieczny protokół opracowany w celu bezpiecznego przesyłania informacji przez Internet. TLS jest następcą protokołu SSL wprowadzonego w 1999 r.
• SASL: Struktura zapewniająca mechanizmy uwierzytelniania użytkowników, sprawdzania integralności danych i szyfrowania.
• Abonent Streaming API: Komponent odpowiedzialny za pobieranie zdarzeń przechowywanych w tematach zdefiniowanych w Paragon Active Assurance i przeznaczonych do dostępu zewnętrznego.
• Urząd certyfikacji: Zaufany podmiot, który wystawia i unieważnia certyfikaty klucza publicznego.
• Certyfikat główny urzędu certyfikacji: certyfikat klucza publicznego identyfikujący urząd certyfikacji.

Jak działa interfejs API przesyłania strumieniowego
Jak wspomniano wcześniej, Streaming API umożliwia klientom zewnętrznym pobieranie informacji o metrykach z platformy Kafka.

Wszystkie metryki zebrane przez agentów testowych podczas zadania testowego lub monitorującego są wysyłane do usługi Stream. Po fazie przetwarzania usługa Stream publikuje te metryki w Kafce wraz z dodatkowymi metadanymi.

Tematyka Kafki
Kafka ma koncepcję tematów, do których publikowane są wszystkie dane. W Paragon Active Assurance dostępnych jest wiele takich tematów Kafki; jednakże tylko część z nich jest przeznaczona do dostępu zewnętrznego.
Każde konto Paragon Active Assurance w Control Center ma dwa dedykowane tematy. Poniżej ACCOUNT znajduje się krótka nazwa konta:

• paa.public.accounts.{KONTO}.metrics
  • Wszystkie komunikaty dotyczące metryk dla danego konta są publikowane w tym temacie
  • Duże ilości danych
  • Wysoka częstotliwość aktualizacji
• paa.public.accounts.{KONTO}.metadane
  • Zawiera metadane związane z danymi metryk, npample test, monitor lub agent testowy powiązany z metrykami
  • Mała ilość danych
  • Niska częstotliwość aktualizacji

Włączanie interfejsu API przesyłania strumieniowego

NOTATKA: Te instrukcje należy uruchomić na serwerze Centrum sterowania za pomocą sudo.

Ponieważ interfejs API przesyłania strumieniowego dodaje pewne obciążenie do Centrum sterowania, nie jest on domyślnie włączony. Aby włączyć API, musimy najpierw włączyć publikowanie metryk do Kafki w głównej konfiguracji file:

• /etc/netrounds/netrounds.conf

KAFKA_METRICS_ENABLED = Prawda

OSTRZEŻENIE: Włączenie tej funkcji może mieć wpływ na wydajność Centrum sterowania. Upewnij się, że odpowiednio zwymiarowałeś instancję.

Następnie, aby umożliwić przekazywanie tych metryk do właściwych tematów Kafki:

• /etc/netrounds/metrics.yaml

streaming-api: prawda

Aby włączyć i uruchomić usługi Streaming API, uruchom:

• Usługi sudo ncc umożliwiają metryki w skali czasowejb
• Usługi sudo ncc rozpoczynają się od wskaźników czasowychb

Na koniec uruchom ponownie usługi:

• ponowne uruchomienie usług sudo ncc

Sprawdzanie, czy interfejs API przesyłania strumieniowego działa w Centrum sterowania

NOTATKA: Instrukcje te należy uruchomić na serwerze Control Center.

Możesz teraz sprawdzić, czy otrzymujesz dane dotyczące właściwych tematów Kafki. Aby to zrobić, zainstaluj narzędzie kafkacat:

• sudo apt-get update
• sudo apt-get zainstaluj kafkacat

Jeśli masz test lub monitor działający w Centrum sterowania, powinieneś móc używać kafkacat do otrzymywania metryk i metadanych na te tematy.
Zastąp moje konto krótką nazwą swojego konta (to jest to, co widzisz w Centrum sterowania URL):

• eksportuj METRICS_TOPIC=paa.public.accounts.myaccount.metrics
• eksportuj METADATA_TOPIC=paa.public.accounts.myaccount.metadata

Powinieneś teraz zobaczyć metryki, uruchamiając to polecenie:

• kafkacat -b ${KAFKA_FQDN}:9092 -t ${METRICS_TOPIC} -C -e

Do view metadane, uruchom następujące polecenie (pamiętaj, że nie będzie ono aktualizowane tak często):

• kafkacat -b ${KAFKA_FQDN}:9092 -t ${METADATA_TOPIC} -C -e

NOTATKA:
kafkacat”Klient Examples” na stronie 14

To sprawdza, czy mamy działający interfejs API przesyłania strumieniowego z poziomu Centrum sterowania. Jednak najprawdopodobniej zamiast tego interesuje Cię dostęp do danych od klienta zewnętrznego. W następnej sekcji opisano, jak otworzyć Kafkę na dostęp zewnętrzny.

Otwieranie Kafki dla hostów zewnętrznych

NOTATKA: Instrukcje te należy uruchomić na serwerze Control Center.

Domyślnie Kafka uruchomiona w Centrum sterowania jest skonfigurowana tak, aby nasłuchiwać tylko na localhost do użytku wewnętrznego. Możliwe jest otwarcie Kafki dla klientów zewnętrznych poprzez modyfikację ustawień Kafki.

Łączenie z Kafką: zastrzeżenia

OSTROŻNOŚĆ: Przeczytaj to uważnie, ponieważ jeśli nie rozumiesz tych pojęć, łatwo jest napotkać problemy z połączeniem z Kafką.

W konfiguracji Centrum sterowania opisanej w tym dokumencie istnieje tylko jeden broker Kafka.
Należy jednak pamiętać, że broker Kafka ma działać jako część klastra Kafka, który może składać się z wielu brokerów Kafka.
Podczas łączenia się z brokerem Kafka klient Kafka ustanawia połączenie początkowe. W związku z tym broker Kafka z kolei zwróci listę „reklamowanych słuchaczy”, która jest listą jednego lub większej liczby brokerów Kafki.
Po otrzymaniu tej listy klient Kafki rozłączy się, a następnie ponownie połączy z jednym z tych reklamowanych słuchaczy. Reklamowane odbiorniki muszą zawierać nazwy hostów lub adresy IP dostępne dla klienta Kafka, w przeciwnym razie klient nie będzie mógł się połączyć.
Jeśli używane jest szyfrowanie SSL, obejmujące certyfikat SSL powiązany z konkretną nazwą hosta, jeszcze ważniejsze jest, aby klient Kafki otrzymał prawidłowy adres, z którym może się połączyć, ponieważ w przeciwnym razie połączenie może zostać odrzucone.
Przeczytaj więcej o słuchaczach Kafki tutaj: www.confluent.io/blog/kafka-listeners-explained

Szyfrowanie SSL/TLS
Aby mieć pewność, że tylko zaufani klienci będą mieli dostęp do Kafki i API przesyłania strumieniowego, musimy skonfigurować następujące elementy:

• Uwierzytelnianie:Klienci muszą podać nazwę użytkownika i hasło za pośrednictwem bezpiecznego połączenia SSL/TLS pomiędzy klientem a Kafką.
• Upoważnienie:Uwierzytelnieni klienci mogą wykonywać zadania regulowane przez listy kontroli dostępu.

Oto ponadview:

*) Uwierzytelnianie nazwą użytkownika/hasłem przeprowadzane na kanale szyfrowanym SSL

Aby w pełni zrozumieć, jak działa szyfrowanie SSL/TLS w przypadku platformy Kafka, zapoznaj się z oficjalną dokumentacją: docs.confluent.io/platform/current/kafka/encryption.html

Certyfikat SSL/TLS dobiegł końcaview

NOTATKA: W tym podrozdziale będziemy posługiwać się następującą terminologią:

Certyfikat: Certyfikat SSL podpisany przez Urząd Certyfikacji (CA). Każdy broker Kafka ma taki certyfikat.
Magazyn kluczy: Magazyn kluczy file który przechowuje certyfikat. Magazyn kluczy file zawiera klucz prywatny certyfikatu; dlatego należy go bezpiecznie przechowywać.
Sklep zaufania: A file zawierające certyfikaty zaufanego urzędu certyfikacji.

Aby skonfigurować uwierzytelnianie między klientem zewnętrznym a Kafką działającą w Centrum sterowania, obie strony muszą mieć zdefiniowany magazyn kluczy z powiązanym certyfikatem podpisanym przez urząd certyfikacji (CA) wraz z certyfikatem głównym urzędu certyfikacji.
Oprócz tego klient musi także posiadać magazyn zaufanych certyfikatów z certyfikatem głównym urzędu certyfikacji.
Certyfikat główny urzędu certyfikacji jest wspólny dla brokera Kafka i klienta Kafka.

Tworzenie wymaganych certyfikatów
Omówiono to w „Załączniku” na stronie 17.

Konfiguracja protokołu SSL/TLS brokera Kafka w Centrum sterowania

NOTATKA: Instrukcje te należy uruchomić na serwerze Control Center.

NOTATKA: Zanim będziesz kontynuować, musisz utworzyć magazyn kluczy zawierający certyfikat SSL, postępując zgodnie z instrukcjami zawartymi w „Dodatku” na stronie 17. Ścieżki wymienione poniżej pochodzą z tych instrukcji.
Magazyn kluczy SSL to: file zapisane na dysku z rozszerzeniem file rozszerzenie .jks.

Po utworzeniu wymaganych certyfikatów zarówno dla brokera Kafka, jak i klienta Kafka, możesz kontynuować konfigurowanie brokera Kafka działającego w Control Center. Musisz wiedzieć, co następuje:

• : Publiczna nazwa hosta Centrum sterowania; musi to być możliwe do rozwiązania i dostępne dla klientów Kafki.
• : Hasło magazynu kluczy podane podczas tworzenia certyfikatu SSL.
• I : To są hasła, które chcesz ustawić odpowiednio dla administratora i klienta. Pamiętaj, że możesz dodać więcej użytkowników, jak wskazano w przykładzieample.

Edytuj lub dodaj (z dostępem sudo) poniższe właściwości w pliku /etc/kafka/server.properties, wstawiając powyższe zmienne, jak pokazano:

OSTRZEŻENIE: Nie usuwaj PLAINTEXT://localhost:9092. Spowoduje to przerwanie działania Centrum sterowania, ponieważ wewnętrzne usługi nie będą mogły się komunikować.

• …
• # Adresy, na których nasłuchuje broker Kafka.
• słuchacze=PLAINTEXT://localhost:9092,SASL_SSL://0.0.0.0:9093
• # To są hosty reklamowane każdemu klientowi łączącemu się.
• reklamowane.listeners=PLAINTEXT://localhost:9092,SASL_SSL:// :9093 …
• ####### KONFIG. NIESTANDARDOWA
• # KONFIGURACJA SSL
• ssl.endpoint.identification.algorithm=
  ssl.keystore.location=/var/ssl/private/kafka.server.keystore.jks
• ssl.keystore.password=
• ssl.key.password=
• ssl.client.auth=brak
• ssl.protocol=TLSv1.2
• # Konfiguracja SASL
• sasl.enabled.mechanisms=ZWYKŁY
• nazwa użytkownika=”administrator” \
• hasło=” ” \
• użytkownik_admin=” ” \
• użytkownik_klient=” ”;
• # UWAGA, za pomocą user_ można dodać więcej użytkowników =
• # Autoryzacja, włącz listy ACL
• authorizer.class.name=kafka.security.authorizer.AclAuthorizer super.users=Użytkownik:admin

Konfigurowanie list kontroli dostępu (ACL)

Włączanie list ACL na serwerze lokalnym

OSTRZEŻENIE: Najpierw musimy skonfigurować ACL dla localhost, aby samo Control Center nadal miało dostęp do Kafki. Jeśli tego nie zrobimy, wszystko się zepsuje.

• –autor kafka.security.authorizer.AclAuthorizer \
• –właściwości autora zookeeper.connect=localhost:2181 \
• –add –allow-principal Użytkownik:ANONYMOUS –allow-host 127.0.0.1 –cluster
• /usr/lib/kafka/bin/kafka-acls.sh \
• –autor kafka.security.authorizer.AclAuthorizer \
• –właściwości autora zookeeper.connect=localhost:2181 \
• –add –allow-principal Użytkownik:ANONYMOUS –allow-host 127.0.0.1 –temat „*”
• /usr/lib/kafka/bin/kafka-acls.sh \
• –autor kafka.security.authorizer.AclAuthorizer \
• –właściwości autora zookeeper.connect=localhost:2181 \
• –add –allow-principal Użytkownik:ANONYMOUS –allow-host 127.0.0.1 –grupa „*”

Następnie musimy włączyć listy ACL dla zewnętrznego dostępu tylko do odczytu, aby użytkownicy zewnętrzni mogli czytać tematy paa.public.*.

### Wpisy ACL dla użytkowników anonimowych /usr/lib/kafka/bin/kafka-acls.sh \

NOTATKA:Aby uzyskać bardziej szczegółową kontrolę, zapoznaj się z oficjalną dokumentacją Kafki.

• –autor kafka.security.authorizer.AclAuthorizer \
• –właściwości autora zookeeper.connect=localhost:2181 \
• –add –allow-principal Użytkownik:* –operacja odczyt –operacja opis \ –grupa 'NCC'
• /usr/lib/kafka/bin/kafka-acls.sh \
• –autor kafka.security.authorizer.AclAuthorizer \
• –właściwości autora zookeeper.connect=localhost:2181 \
• –add –allow-principal Użytkownik:* –operacja odczyt –operacja opis \ –topic paa.public. –resource-pattern-type z prefiksem

Gdy już to zrobisz, musisz ponownie uruchomić usługi:

### Wpisy ACL dla użytkowników zewnętrznych /usr/lib/kafka/bin/kafka-acls.sh \

• ponowne uruchomienie usług sudo ncc

Aby sprawdzić, czy klient może nawiązać bezpieczne połączenie, uruchom następujące polecenie na komputerze zewnętrznym
komputer kliencki (nie na serwerze Control Center). Poniżej PUBLIC_HOSTNAME jest nazwą hosta Control Center:

• openssl s_client -debug -connect ${PUBLIC_HOSTNAME}:9093 -tls1_2 | grep „Bezpieczna renegocjacja jest obsługiwana”

W wynikach polecenia powinieneś zobaczyć certyfikat serwera oraz następujące informacje:

• Obsługiwana jest bezpieczna renegocjacja

Aby upewnić się, że usługi wewnętrzne otrzymały dostęp do serwera Kafka, sprawdź poniższy logfiles:

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

Sprawdzanie łączności klienta zewnętrznego

kafkakot

NOTATKA: Instrukcje te należy uruchamiać na komputerze klienckim (a nie na serwerze Centrum sterowania).
NOTATKAAby wyświetlić informacje metryczne, upewnij się, że w Centrum sterowania jest uruchomiony co najmniej jeden monitor.

Aby zweryfikować i potwierdzić łączność jako klient zewnętrzny, można użyć narzędzia kafkacat, które zostało zainstalowane w sekcji „Sprawdzanie, czy API przesyłania strumieniowego działa w Centrum sterowania” na stronie 4.
Wykonaj następujące kroki:

NOTATKA: Poniżej CLIENT_USER to użytkownik określony wcześniej w file /etc/kafka/server.properties w Centrum sterowania: mianowicie klient_użytkownika i ustawione tam hasło.
Na kliencie musi znajdować się certyfikat główny urzędu certyfikacji używany do podpisywania certyfikatu SSL po stronie serwera.

Utwórz file client.properties o następującej treści:

• security.protocol=SASL_SSL
• ssl.ca.location={PATH_TO_CA_CERT}
• sasl.mechanisms=ZWYKŁY
• sasl.username={CLIENT_USER}
• sasl.password={CLIENT_PASSWORD}

Gdzie

• {PATH_TO_CA_CERT} to lokalizacja certyfikatu głównego urzędu certyfikacji używanego przez brokera Kafka
• {CLIENT_USER} i {CLIENT_PASSWORD} to dane uwierzytelniające użytkownika klienta.

Uruchom następujące polecenie, aby zobaczyć wiadomość wykorzystaną przez kafkacat:

• eksportuj KAFKA_FQDN=
• eksportuj METRICS_TOPIC=paa.public.accounts. .metryka
• kafkacat -b ${KAFKA_FQDN}:9093 -F właściwości klienta -t ${METRICS_TOPIC} -C -e

gdzie {METRICS_TOPIC} to nazwa tematu Kafki z przedrostkiem „paa.public.”.

NOTATKA: Starsze wersje kafkacat nie udostępniają opcji -F do odczytywania ustawień klienta z pliku file. Jeśli używasz takiej wersji, musisz podać te same ustawienia z wiersza poleceń, jak pokazano poniżej.

kafkacat -b ${KAFKA_FQDN}:9093 \

• X security.protokół=SASL_SSL \
• X ssl.ca.location={ŚCIEŻKA_DO_CERTU_CA} \
• X sasl.mechanisms=ZWYKŁY \
• X sasl.username={UŻYTKOWNIK_KLIENTA} \
• X sasl.password={HASŁO_KLIENTA} \
• t ${METRICS_TOPIC} -C -e

Aby debugować łączność, możesz użyć opcji -d:

Debuguj komunikację konsumencką
kafkacat -d konsument -b ${KAFKA_FQDN}:9093 -F właściwości klienta -t ${METRICS_TOPIC} -C -e
# Debuguj komunikację brokera
kafkacat -d broker -b ${KAFKA_FQDN}:9093 -F właściwości klienta -t ${METRICS_TOPIC} -C -e

Pamiętaj, aby zapoznać się z dokumentacją używanej biblioteki klienta Kafka, ponieważ właściwości mogą różnić się od tych w pliku client.properties.

Format wiadomości
Komunikaty używane w tematach dotyczących metryk i metadanych są serializowane w formacie buforów protokołu (protobuf) (zobacz Developers.google.com/protocol-buffers). Schematy tych komunikatów mają następujący format:

Metryki Schemat Protobufa

• składnia = „proto3”;
• zaimportuj „google/protobuf/timestamp.proto”;
• pakiet paa.streamingapi;
• opcja go_package = „.;paa_streamingapi”;
• Metryki wiadomości {
• google.protobuf.Timestamp godzinaamp = 1;
• mapa wartości = 2;
• int32 id_strumienia = 3;
• }
• /**
• * Wartość metryki może być liczbą całkowitą lub zmiennoprzecinkową.
• */
• wiadomość Wartość metryki {
• jeden z typów {
• int64 int_val = 1;
• float float_val = 2;
• }
• }

Schemat metadanych Protobuf

• składnia = „proto3”;
• pakiet paa.streamingapi;
• opcja go_package = „.;paa_streamingapi”;
• metadane wiadomości {
• int32 id_strumienia = 1;
• string nazwa_strumienia = 2;
• mapa tags = 13;
• }

Klient Examples

NOTATKA: Polecenia te są przeznaczone do uruchamiania na kliencie zewnętrznym, npample na swoim laptopie lub podobnym urządzeniu, a nie w Control Center.
NOTATKA: Aby wyświetlić informacje o metrykach, upewnij się, że co najmniej jeden monitor działa w Centrum sterowania.

Paczka tar Centrum sterowania zawiera archiwum paa-streaming-api-client-examples.tar.gz (klient-npamples), który zawiera example Skrypt w języku Python pokazujący, jak korzystać z interfejsu API przesyłania strumieniowego.

Instalacja i konfiguracja klienta Examples
Znajdujesz byłego klientaamppliki w folderze Paragon Active Assurance Control Center:

• eksportuj CC_VERSION=4.1.0
• cd ./paa-control-center_${CC_VERSION}
• ls paa-streaming-api-client-examplas*

Aby zainstalować klienta-exampplików na zewnętrznym komputerze klienckim, wykonaj następujące czynności:

• # Utwórz katalog do wyodrębnienia zawartości klienta npampplik tarball
• mkdir paa-streaming-api-client-examples
• # Wyodrębnij zawartość klienta npampplik tarball
• tar xzf paa-streaming-api-client-examples.tar.gz -C paa-streaming-api-client-examples
• # Przejdź do nowo utworzonego katalogu
• cd paa-streaming-api-client-examples

były klientamples wymaga uruchomienia Dockera. Pliki do pobrania i instrukcje instalacji dla Dockera można znaleźć pod adresem https://docs.docker.com/engine/install.

Korzystanie z klienta Examples
Klient-byłyampNarzędzia les mogą działać w trybie podstawowym lub zaawansowanym, aby zbudować npamppliki o różnym stopniu złożoności. W obu przypadkach możliwe jest także uruchomienie examppliki z konfiguracją file zawierające dodatkowe właściwości umożliwiające dalszą personalizację strony klienta.

Tryb podstawowy
W trybie podstawowym metryki i ich metadane są przesyłane strumieniowo osobno. W tym celu klient odsłuchuje każdy temat Kafki dostępny do dostępu zewnętrznego i po prostu drukuje odebrane wiadomości na konsolę.
Aby rozpocząć wykonywanie podstawowego examples, uruchom:

• build.sh run-basic –kafka-brokers localhost:9092 –account KONTO_SKRÓCONA_NAZWA

gdzie ACCOUNT_SHORTNAME to krótka nazwa konta, z którego chcesz uzyskać dane.
Aby zakończyć wykonywanie example, naciśnij Ctrl + C. (Przed zatrzymaniem wykonywania może wystąpić niewielkie opóźnienie, ponieważ klient czeka na przekroczenie limitu czasu).

Tryb zaawansowany

NOTATKA:Metryki są wyświetlane tylko dla monitorów HTTP uruchomionych w Centrum sterowania.

Wykonanie w trybie zaawansowanym pokazuje korelację między metrykami i komunikatami metadanych. To jest
możliwe dzięki obecności w każdej wiadomości metrycznej pola identyfikatora strumienia, które odnosi się do odpowiadającej jej wiadomości metadanych.
Aby wykonać zaawansowany examples, uruchom:

• build.sh run-advanced –kafka-brokers localhost:9092 –account KONTO_SKRÓCONA_NAZWA

gdzie ACCOUNT_SHORTNAME to krótka nazwa konta, z którego chcesz uzyskać dane.
Aby zakończyć wykonywanie example, naciśnij Ctrl + C. (Przed zatrzymaniem wykonywania może wystąpić niewielkie opóźnienie, ponieważ klient czeka na przekroczenie limitu czasu).

Ustawienia dodatkowe
Istnieje możliwość uruchomienia examppliki z dodatkową konfiguracją klienta za pomocą opcji –config-file opcja, po której następuje a file nazwa zawierająca właściwości w postaci klucz=wartość.

• build.sh uruchom-zaawansowane \
• –kafka-brokers localhost:9092 \
• –konto ACCOUNT_SHORTNAME \
• –konfiguracja-file Client_config.properties

NOTATKA: Wszystko files, do których odwołuje się powyższe polecenie, muszą znajdować się w bieżącym katalogu i odnosić się do nich wyłącznie za pomocą ścieżek względnych. Dotyczy to zarówno –config-file argumentu i do wszystkich wpisów w konfiguracji file które opisują file lokalizacje.

Sprawdzanie uwierzytelnienia klienta zewnętrznego
Aby sprawdzić uwierzytelnienie klienta spoza Centrum sterowania przy użyciu Client-examples, wykonaj następujące kroki:

Z folderu Paragon Active Assurance Control Center przejdź do paa-streaming-api-client-exampfolder plików:

cd paa-streaming-api-client-examples

• Skopiuj certyfikat główny urzędu certyfikacji ca-cert do bieżącego katalogu.
• Utwórz plik client.properties file o następującej treści:

security.protocol=SASL_SSL ssl.ca.location=ca-cert
sasl.mechanizm=ZWYKŁY
sasl.username={CLIENT_USER}
sasl.password={CLIENT_PASSWORD}

gdzie {CLIENT_USER} i {CLIENT_PASSWORD} to dane uwierzytelniające użytkownika klienta.

Uruchom podstawowy npamples:

• eksportuj KAFKA_FQDN=
• build.sh run-basic –kafka-brokers ${KAFKA_FQDN}:9093 \
• –konto ACCOUNT_SHORTNAME
• –konfiguracja-file właściwości klienta

gdzie ACCOUNT_SHORTNAME to krótka nazwa konta, z którego chcesz uzyskać dane.

Uruchom zaawansowane npamples:

• eksportuj KAFKA_FQDN=
• build.sh run-advanced –kafka-brokers ${KAFKA_FQDN}:9093 \
• –konto ACCOUNT_SHORTNAME
• –konfiguracja-file właściwości klienta

Załącznik

W tym dodatku opisujemy jak utworzyć:

• magazyn kluczy file do przechowywania certyfikatu SSL brokera Kafka
• magazyn zaufania file do przechowywania certyfikatu głównego urzędu certyfikacji (CA) używanego do podpisywania certyfikatu brokera Kafka.

Tworzenie certyfikatu brokera Kafka
Tworzenie certyfikatu przy użyciu prawdziwego urzędu certyfikacji (zalecane)
Zalecane jest uzyskanie prawdziwego certyfikatu SSL od zaufanego urzędu certyfikacji.
Kiedy już zdecydujesz się na urząd certyfikacji, skopiuj jego certyfikat główny urzędu certyfikacji ca-cert file na własną ścieżkę, jak pokazano poniżej:

• eksport CA_PATH=~/my-ca
• mkdir ${CA_PATH}
• cp ca-cert ${CA_PATH}

Utwórz własny urząd certyfikacji

NOTATKA: Zwykle powinieneś mieć swój certyfikat podpisany przez prawdziwy urząd certyfikacji; patrz poprzedni podrozdział. To, co następuje, to tylko byłyample.

Tutaj tworzymy własny certyfikat główny urzędu certyfikacji (CA). file ważny 999 dni (niezalecany w produkcji):

• # Utwórz katalog do przechowywania urzędu certyfikacji
• eksport CA_PATH=~/my-ca
• mkdir ${CA_PATH}
• # Wygeneruj certyfikat CA
• openssl req -new -x509 -keyout ${CA_PATH}/ca-key -out ${CA_PATH}/ca-cert -days 999

Tworzenie magazynu zaufania klienta
Teraz możesz utworzyć magazyn zaufanych certyfikatów file który zawiera wygenerowany powyżej certyfikat ca-cert. Ten file będzie potrzebny klientowi Kafki, który będzie miał dostęp do Streaming API:

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

Teraz, gdy certyfikat urzędu certyfikacji znajduje się w magazynie zaufanych certyfikatów, klient będzie ufał każdemu certyfikatowi podpisanemu za jego pomocą.
Powinieneś skopiować file kafka.client.truststore.jks do znanej lokalizacji na komputerze klienckim i wskaż ją w ustawieniach.

Tworzenie magazynu kluczy dla brokera Kafka
Aby wygenerować certyfikat SSL brokera Kafka, a następnie magazyn kluczy kafka.server.keystore.jks, wykonaj następujące czynności:

Generowanie certyfikatu SSL
Poniżej 999 to liczba dni ważności magazynu kluczy, a FQDN to w pełni kwalifikowana nazwa domeny klienta (publiczna nazwa hosta węzła).

NOTATKA: Ważne jest, aby nazwa FQDN odpowiadała dokładnej nazwie hosta, której klient Kafka będzie używał do łączenia się z Centrum sterowania.

• sudo mkdir -p /var/ssl/private
• sudo chown -R $USER: /var/ssl/private
• cd /var/ssl/private
• eksportuj FQDN= keytool -keystore kafka.server.keystore.jks \
• – alias serwera \
• – ważność 999 \
• – genkey -keyalg RSA -ext SAN=dns:${FQDN}

Utwórz żądanie podpisania certyfikatu i zapisz je w pliku file o nazwie żądanie serwera certyfikatu:

• keytool -keystore kafka.server.keystore.jks \
  • – alias serwera \
  • – certyfikat \
  • – file żądanie serwera certyfikatu

Powinieneś teraz wysłać file cert-server-request do urzędu certyfikacji (CA), jeśli używasz prawdziwego. Następnie zwrócą podpisany certyfikat. Poniżej będziemy nazywać to certyfikatem-serwerem-podpisanym.

Podpisywanie certyfikatu SSL przy użyciu samodzielnie utworzonego certyfikatu CA

NOTATKA: Ponownie, nie zaleca się korzystania z własnego urzędu certyfikacji w systemie produkcyjnym.

Podpisz certyfikat za pomocą urzędu certyfikacji za pomocą polecenia file cert-server-request, który generuje podpisany certyfikat cert-server-signed. Zobacz poniżej; ca-password to hasło ustawione podczas tworzenia certyfikatu CA.

• cd /var/ssl/private openssl x509 -req \
  • – CA ${CA_PATH}/ca-cert \
  • – CAkey ${CA_PATH}/ca-key \
  • – w cert-server-request \
  • – out cert-server-signed \
  • – dni 999 -CAcreateserial \
  • – passin pass:{ca-password}

Importowanie podpisanego certyfikatu do magazynu kluczy

Zaimportuj certyfikat główny ca-cert do magazynu kluczy:

• keytool -keystore kafka.server.keystore.jks \
  • – alias ca-cert \
  • – importuj \
  • – file ${CA_PATH}/ca-cert

Zaimportuj podpisany certyfikat o nazwie cert-server-signed:

• keytool -keystore kafka.server.keystore.jks \
  • – alias serwera \
  • – importuj \
  • – file podpisany przez serwer certyfikatu

Ten file kafka.server.keystore.jks należy skopiować do znanej lokalizacji na serwerze Control Center, a następnie odnieść się do pliku /etc/kafka/server.properties.

Korzystanie z interfejsu API przesyłania strumieniowego

W TEJ SEKCJI

• Ogólne | 20
• Nazwy tematów Kafki | 21
• Examples korzystania z interfejsu API przesyłania strumieniowego | 21

Ogólny
Interfejs API przesyłania strumieniowego pobiera dane testowe i monitorujące. Nie da się wyodrębnić jednej z tych kategorii.
Interfejs API przesyłania strumieniowego nie pobiera danych z testów opartych na skryptach (tych reprezentowanych przez prostokąt zamiast elementu układanki w graficznym interfejsie użytkownika Centrum sterowania), takich jak testy aktywacji usług Ethernet i testy przezroczystości.

Nazwy tematów Kafki
Nazwy tematów Kafki dla API przesyłania strumieniowego są następujące, gdzie %s to krótka nazwa konta Centrum sterowania (wskazywana podczas tworzenia konta):

• stała (
• nazwa_eksportera = „kafka”
• metadataTopicTpl = „paa.public.accounts.%s.metadata” metrykiTopicTpl = „paa.public.accounts.%s.metrics” )

Examppliki dotyczące korzystania z interfejsu API przesyłania strumieniowego
ByłyampPoniższe pliki znajdują się w archiwum paa-streaming-api-client-examples.tar.gz zawarty w archiwum tar Centrum sterowania.
Po pierwsze, istnieje podstawowy przykładampplik demonstrujący, w jaki sposób metryki i ich metadane są przesyłane strumieniowo oddzielnie i po prostu drukują odebrane komunikaty na konsoli. Można go uruchomić w następujący sposób:

• sudo ./build.sh run-basic –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME

Istnieje również bardziej zaawansowany exampplik, w którym skorelowane są metryki i metadane. Użyj tego polecenia, aby go uruchomić:

• sudo ./build.sh run-advanced –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME

Aby uruchamiać polecenia Dockera, takie jak te powyżej, musisz użyć sudo. Opcjonalnie możesz wykonać kroki poinstalacyjne systemu Linux, aby móc uruchamiać polecenia Dockera bez sudo. Aby uzyskać szczegółowe informacje, przejdź do https://docs.docker.com/engine/install/linux-postinstall.

Juniper Networks, logo Juniper Networks, Juniper i Junos są zarejestrowanymi znakami towarowymi Juniper Networks, Inc. w Stanach Zjednoczonych i innych krajach. Wszystkie inne znaki towarowe, znaki usługowe, zarejestrowane znaki towarowe lub zarejestrowane znaki usługowe są własnością ich odpowiednich właścicieli. Juniper Networks nie ponosi odpowiedzialności za jakiekolwiek nieścisłości w tym dokumencie. Juniper Networks zastrzega sobie prawo do zmiany, modyfikacji, przeniesienia lub w inny sposób rewizji tej publikacji bez powiadomienia. Copyright © 2023 Juniper Networks, Inc. Wszelkie prawa zastrzeżone.

Dokumenty / Zasoby

Oprogramowanie API do przesyłania strumieniowego Juniper NETWORKS [plik PDF] Instrukcja użytkownika Oprogramowanie API do przesyłania strumieniowego, Oprogramowanie API, Oprogramowanie

Odniesienia

• Instrukcja obsługi