Juniper NETWORKS Streaming API софтуер

Информация за продукта

Спецификации

• Име на продукта: Paragon Active Assurance
• Версия: 4.1
• Дата на публикуване: 2023-03-15

Въведение:
Това ръководство предоставя инструкции как да извлечете данни от Paragon Active Assurance с помощта на API за стрийминг на продукта. Клиентът за стрийминг и API са включени в инсталацията на Paragon Active Assurance, но е необходима известна конфигурация, преди да използвате API. Процесът на конфигуриране е разгледан в раздела „Конфигуриране на API за поточно предаване“.

Конфигуриране на API за поточно предаване:
Следните стъпки очертават процеса за конфигуриране на API за поточно предаване:

крайview
Kafka е платформа за стрийминг на събития, предназначена за улавяне и съхранение в реално време на данни от различни източници. Той позволява управление на потоци от събития по разпределен, мащабируем, устойчив на грешки и сигурен начин. Това ръководство се фокусира върху конфигурирането на Kafka за използване на функцията Streaming API в Paragon Active Assurance Control Center.

Терминология
API за поточно предаване позволява на външни клиенти да извличат информация за показатели от Kafka. Метриките, събрани от тестовите агенти по време на тестова или мониторингова задача, се изпращат до услугата Stream. След обработката услугата Stream публикува тези показатели на Kafka заедно с допълнителни метаданни.

Активиране на API за поточно предаване
За да активирате API за поточно предаване, изпълнете следните стъпки:

1. Изпълнете следните команди на сървъра на Control Center с помощта на sudo:

KAFKA_METRICS_ENABLED = Истински sudo ncc услуги активират timescaledb метрики sudo ncc услуги стартират timescaledb метрики sudo ncc услуги рестартират

Проверка дали API за поточно предаване работи в Центъра за управление:
За да проверите дали получавате показатели за правилните теми на Kafka:

1. Инсталирайте помощната програма kafkacat със следните команди:
   sudo apt-get актуализация
   sudo apt-get инсталирайте kafkacat

2. Заменете „myaccount“ с краткото име на вашия акаунт в
   Център за управление URL:
   експорт METRICS_TOPIC=paa.public.accounts.myaccount.metrics
   експортиране на METADATA_TOPIC=paa.public.accounts.myaccount.metadata

3. Изпълнете следната команда за view показатели:
   kafkacat -b ${KAFKA_FQDN}:9092 -t ${METRICS_TOPIC} -C -e
   Забележка: Горната команда ще покаже показателите.
4. до view метаданни, изпълнете следната команда:
   kafkacat -b ${KAFKA_FQDN}:9092 -t ${METADATA_TOPIC} -C -e

Забележка: Горната команда ще покаже метаданни, но няма да се актуализира толкова често.

Клиент Прampлес
За клиент прampи допълнителна информация вижте страница 14 от ръководството за потребителя.

ЧЗВ (Често задавани въпроси)

• Въпрос: Какво представлява Paragon Active Assurance?
  О: Paragon Active Assurance е продукт, който предоставя възможности за наблюдение и тестване.
• В: Какво представлява API за поточно предаване?
  О: API за поточно предаване е функция в Paragon Active Assurance, която позволява на външни клиенти да извличат информация за показатели от Kafka.
• В: Как да активирам API за поточно предаване?
  О: За да активирате API за поточно предаване, следвайте стъпките, описани в раздела „Активиране на API за поточно предаване“ на ръководството за потребителя.
• Въпрос: Как мога да проверя дали API за поточно предаване работи?
  О: Вижте раздела „Проверка дали API за поточно предаване работи в контролния център“ за инструкции как да проверите функционалността на API за поточно предаване.

Въведение

Това ръководство описва как да извлечете данни от Paragon Active Assurance чрез API за поточно предаване на продукта.
API, както и клиентът за стрийминг са включени в инсталацията на Paragon Active Assurance. Необходима е обаче малко конфигурация, преди да можете да използвате API. Това е описано в главата „Конфигуриране на API за поточно предаване“ на страница 1.

крайview
Тази глава описва как да конфигурирате API за поточно предаване, за да позволи абониране за съобщения с показатели чрез Kafka.
pr
По-долу ще преминем през:

• Как да активирате API за поточно предаване
• Как да конфигурирате Kafka да слуша външни клиенти
• Как да конфигурирате Kafka да използва ACL и да настрои SSL криптиране за споменатите клиенти

Какво е Кафка?
Kafka е платформа за стрийминг на събития, която позволява улавяне в реално време на данни, изпратени от различни източници на събития (сензори, бази данни, мобилни устройства) под формата на потоци от събития, както и трайно съхраняване на тези потоци от събития за по-късно извличане и манипулиране.
С Kafka е възможно да управлявате потока на събития от край до край по разпределен, силно мащабируем, еластичен, толерантен към грешки и сигурен начин.

ЗАБЕЛЕЖКА: Kafka може да бъде конфигуриран по много различни начини и е проектиран за мащабируемост и резервни системи. Този документ се фокусира само върху това как да го конфигурирате, за да използвате функцията Streaming API, намираща се в Paragon Active Assurance Control Center. За по-разширени настройки се обръщаме към официалната документация на Kafka: kafka.apache.org/26/documentation.html.

Терминология

• Kafka: Платформа за стрийминг на събития.
• Кафка тема: Колекция от събития.
• Абонат/потребител на Kafka: Компонент, отговорен за извличане на събития, съхранени в тема на Kafka.
• Брокер на Kafka: Сървър на слой за съхранение на клъстер на Kafka.
• SSL/TLS: SSL е защитен протокол, разработен за сигурно изпращане на информация през интернет. TLS е наследник на SSL, въведен през 1999 г.
• SASL: Рамка, която предоставя механизми за удостоверяване на потребителя, проверка на целостта на данните и криптиране.
• Абонат на API за поточно предаване: Компонент, отговорен за извличане на събития, съхранени в теми, дефинирани в Paragon Active Assurance и предназначени за външен достъп.
• Сертифициращ орган: доверен субект, който издава и отменя сертификати за публичен ключ.
• Основен сертификат на сертифициращия орган: Сертификат за публичен ключ, който идентифицира сертифициращ орган.

Как работи API за поточно предаване
Както бе споменато по-горе, API за поточно предаване позволява на външни клиенти да извличат информация за показатели от Kafka.

Всички показатели, събрани от тестовите агенти по време на тестова или мониторингова задача, се изпращат до услугата Stream. След фаза на обработка услугата Stream публикува тези показатели на Kafka заедно с допълнителни метаданни.

Теми на Кафка
Кафка има концепцията за теми, към които се публикуват всички данни. В Paragon Active Assurance има много такива теми на Кафка; обаче само част от тях са предназначени за външен достъп.
Всеки акаунт на Paragon Active Assurance в Control Center има две специални теми. По-долу ACCOUNT е краткото име на акаунта:

• paa.public.accounts.{ACCOUNT}.metrics
  • Всички съобщения за показатели за дадения акаунт се публикуват в тази тема
  • Големи количества данни
  • Висока честота на актуализация
• paa.public.accounts.{ACCOUNT}.metadata
  • Съдържа метаданни, свързани с данните за показателите, напрample теста, монитора или тестовия агент, свързан с показателите
  • Малки количества данни
  • Ниска честота на актуализиране

Активиране на API за поточно предаване

ЗАБЕЛЕЖКА: Тези инструкции трябва да се изпълняват на сървъра на Центъра за управление с помощта на sudo.

Тъй като API за поточно предаване добавя някои допълнителни разходи към Центъра за управление, той не е активиран по подразбиране. За да активираме API, първо трябва да активираме публикуването на показатели в Kafka в основната конфигурация file:

• /etc/netrounds/netrounds.conf

KAFKA_METRICS_ENABLED = Вярно

ПРЕДУПРЕЖДЕНИЕ: Активирането на тази функция може да повлияе на производителността на Центъра за управление. Уверете се, че сте оразмерили съответно вашия екземпляр.

След това, за да активирате препращането на тези показатели към правилните теми на Kafka:

• /etc/netrounds/metrics.yaml

стрийминг-api: вярно

За да активирате и стартирате услугите на API за поточно предаване, изпълнете:

• sudo ncc услугите позволяват timescaledb показатели
• sudo ncc услугите стартират timescaledb показатели

Накрая рестартирайте услугите:

• sudo ncc услуги рестартирайте

Проверка дали API за поточно предаване работи в Центъра за управление

ЗАБЕЛЕЖКА: Тези инструкции трябва да се изпълняват на сървъра на Центъра за управление.

Вече можете да проверите дали получавате показатели за правилните теми на Kafka. За да направите това, инсталирайте помощната програма kafkacat:

• sudo apt-get актуализация
• sudo apt-get инсталирайте kafkacat

Ако имате тест или монитор, работещ в Центъра за управление, трябва да можете да използвате kafkacat, за да получавате показатели и метаданни по тези теми.
Заменете моя акаунт с краткото име на вашия акаунт (това виждате във вашия Център за управление URL):

• експорт METRICS_TOPIC=paa.public.accounts.myaccount.metrics
• експортиране на METADATA_TOPIC=paa.public.accounts.myaccount.metadata

Сега трябва да видите показатели, като изпълните тази команда:

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

до view метаданни, изпълнете следната команда (имайте предвид, че това няма да се актуализира толкова често):

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

ЗАБЕЛЕЖКА:
kafkacat” Клиент Прamples ”на страница 14

Това потвърждава, че имаме работещ API за поточно предаване от Control Center. Най-вероятно обаче се интересувате от достъп до данните от външен клиент вместо това. Следващият раздел описва как да отворите Kafka за външен достъп.

Отваряне на Kafka за външни хостове

ЗАБЕЛЕЖКА: Тези инструкции трябва да се изпълняват на сървъра на Центъра за управление.

По подразбиране Kafka, работещ в Центъра за управление, е конфигуриран да слуша само на localhost за вътрешна употреба. Възможно е да отворите Kafka за външни клиенти, като промените настройките на Kafka.

Свързване с Кафка: предупреждения

ВНИМАНИЕ: Моля, прочетете това внимателно, тъй като е лесно да се натъкнете на проблеми с връзката с Kafka, ако не сте разбрали тези концепции.

В настройката на Центъра за управление, описана в този документ, има само един брокер Kafka.
Обърнете внимание обаче, че Kafka брокер е предназначен да работи като част от Kafka клъстер, който може да се състои от много Kafka брокери.
Когато се свързвате с брокер на Kafka, първоначалната връзка се настройва от клиента на Kafka. Чрез тази връзка брокерът на Kafka на свой ред ще върне списък с „рекламирани слушатели“, който е списък с един или повече брокери на Kafka.
При получаване на този списък клиентът на Kafka ще прекъсне връзката, след което ще се свърже отново с един от тези рекламирани слушатели. Обявените слушатели трябва да съдържат имена на хостове или IP адреси, които са достъпни за клиента Kafka, или клиентът няма да успее да се свърже.
Ако се използва SSL криптиране, включващо SSL сертификат, който е свързан с конкретно име на хост, още по-важно е клиентът на Kafka да получи правилния адрес, към който да се свърже, тъй като в противен случай връзката може да бъде отхвърлена.
Прочетете повече за слушателите на Кафка тук: www.confluent.io/blog/kafka-listeners-explained

SSL/TLS криптиране
За да сме сигурни, че само на доверени клиенти е разрешен достъп до Kafka и API за поточно предаване, трябва да конфигурираме следното:

• Удостоверяване: Клиентите трябва да предоставят потребителско име и парола чрез защитена SSL/TLS връзка между клиента и Kafka.
• Упълномощаване: Удостоверените клиенти могат да изпълняват задачи, регулирани от ACL.

Ето един надписview:

*) Удостоверяване на потребителско име/парола, извършено на SSL-криптиран канал

За да разберете напълно как SSL/TLS криптирането работи за Kafka, моля, вижте официалната документация: docs.confluent.io/platform/current/kafka/encryption.html

SSL/TLS сертификатът приключиview

ЗАБЕЛЕЖКА: В този подраздел ще използваме следната терминология:

Сертификат: SSL сертификат, подписан от Сертифициращ орган (CA). Всеки брокер Kafka има такъв.
Хранилище за ключове: Хранилището за ключове file който съхранява сертификата. Хранилището за ключове file съдържа частния ключ на сертификата; следователно трябва да се съхранява безопасно.
Truststore: А file съдържащ доверените CA сертификати.

За да настроите удостоверяването между външен клиент и Kafka, работещ в Центъра за управление, и двете страни трябва да имат дефинирано хранилище за ключове със свързан сертификат, подписан от Сертифициращ орган (CA) заедно с главния сертификат на CA.
В допълнение към това клиентът трябва също да има доверително хранилище с основния сертификат на CA.
Основният сертификат на CA е общ за брокера на Kafka и клиента на Kafka.

Създаване на необходимите сертификати
Това е описано в „Приложение“ на страница 17.

Kafka Broker SSL/TLS конфигурация в Центъра за управление

ЗАБЕЛЕЖКА: Тези инструкции трябва да се изпълняват на сървъра на Центъра за управление.

ЗАБЕЛЕЖКА: Преди да продължите, трябва да създадете хранилището за ключове, което съдържа SSL сертификата, като следвате инструкциите в „Приложение“ на страница 17. Пътищата, споменати по-долу, идват от тези инструкции.
SSL хранилището за ключове е a file съхранявани на диск с file разширение .jks.

След като имате необходимите сертификати, създадени както за брокера на Kafka, така и за клиента на Kafka, можете да продължите, като конфигурирате брокера на Kafka, работещ в Центъра за управление. Трябва да знаете следното:

• : Публичното име на хост на Центъра за управление; това трябва да е разрешимо и достъпно за клиенти на Kafka.
• : Паролата за хранилище на ключове, предоставена при създаването на SSL сертификата.
• и : Това са паролите, които искате да зададете съответно за администратора и клиентския потребител. Обърнете внимание, че можете да добавите още потребители, както е посочено в exampле.

Редактирайте или добавете (с sudo достъп) свойствата по-долу в /etc/kafka/server.properties, като вмъкнете горните променливи, както е показано:

ПРЕДУПРЕЖДЕНИЕ: Не премахвайте PLAINTEXT://localhost:9092; това ще наруши функционалността на Центъра за управление, тъй като вътрешните услуги няма да могат да комуникират.

• …
• # Адресите, които брокерът Kafka слуша.
• слушатели=ПЛАИНТЕКСТ://localhost:9092,SASL_SSL://0.0.0.0:9093
• # Това са хостовете, обявени обратно към всеки клиент, който се свързва.
• advertised.listeners=PLAINTEXT://localhost:9092,SASL_SSL:// :9093...
• ####### ПЕРСОНАЛИЗИРАНА КОНФИГ
• # SSL КОНФИГУРАЦИЯ
• ssl.endpoint.identification.algorithm=
  ssl.keystore.location=/var/ssl/private/kafka.server.keystore.jks
• ssl.keystore.password=
• ssl.key.password=
• ssl.client.auth=няма
• ssl.protocol=TLSv1.2
• # SASL конфигурация
• sasl.enabled.mechanisms=ОБИКНОВЕН
• потребителско име=”администратор” \
• парола=” ” \
• user_admin=” ” \
• user_client=” ”;
• # ЗАБЕЛЕЖКА Още потребители могат да бъдат добавени с user_ =
• # Упълномощаване, включете ACL
• authorizer.class.name=kafka.security.authorizer.AclAuthorizer super.users=Потребител:админ

Настройване на списъци за контрол на достъпа (ACL)

Включване на ACL на localhost

ПРЕДУПРЕЖДЕНИЕ: Първо трябва да настроим ACL за localhost, така че самият контролен център да може да има достъп до Kafka. Ако това не се направи, нещата ще се счупят.

• –authorizer kafka.security.authorizer.AclAuthorizer \
• –authorizer-properties zookeeper.connect=localhost:2181 \
• –add –allow-principal User: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 User:ANONYMOUS –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 User:ANONYMOUS –allow-host 127.0.0.1 –group '*'

След това трябва да активираме ACL за външен достъп само за четене, така че външните потребители да могат да четат темите paa.public.*.

### Записи в ACL за анонимни потребители /usr/lib/kafka/bin/kafka-acls.sh \

ЗАБЕЛЕЖКА: За по-фин контрол, моля, вижте официалната документация на Kafka.

• –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 Потребител:* –operation read –operation describe \ –topic paa.public. –resource-pattern-type префикс

След като приключите с това, трябва да рестартирате услугите:

### ACL записи за външни потребители /usr/lib/kafka/bin/kafka-acls.sh \

• sudo ncc услуги рестартирайте

За да проверите дали клиентът може да установи защитена връзка, изпълнете следната команда на външен
клиентски компютър (не на сървъра на Control Center). По-долу PUBLIC_HOSTNAME е името на хоста на контролния център:

• openssl s_client -debug -connect ${PUBLIC_HOSTNAME}:9093 -tls1_2 | grep „Поддържа се защитено предоговаряне“

В изхода на командата трябва да видите сертификата на сървъра, както и следното:

• Поддържа се защитено предоговаряне

За да сте сигурни, че вътрешните услуги са получили достъп до сървъра на Kafka, моля, проверете следния журналfiles:

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

Проверка на свързаността на външен клиент

кафкацат

ЗАБЕЛЕЖКА: Тези инструкции трябва да се изпълняват на клиентски компютър (не на сървъра на Центъра за управление).
ЗАБЕЛЕЖКА: За да покажете информация за показатели, уверете се, че поне един монитор работи в Центъра за управление.

За да проверите и валидирате свързаността като външен клиент, е възможно да използвате помощната програма kafkacat, която е инсталирана в раздела „Проверка, че API за поточно предаване работи в контролния център“ на страница 4.
Изпълнете следните стъпки:

ЗАБЕЛЕЖКА: По-долу CLIENT_USER е потребителят, посочен преди това в file /etc/kafka/server.properties в Центъра за управление: а именно user_client и зададената там парола.
Главният сертификат на CA, използван за подписване на SSL сертификата от страната на сървъра, трябва да присъства на клиента.

Създайте a file client.properties със следното съдържание:

• security.protocol=SASL_SSL
• ssl.ca.location={PATH_TO_CA_CERT}
• sasl.mechanisms=ОБИКНОВЕН
• sasl.username={CLIENT_USER}
• sasl.password={CLIENT_PASSWORD}

където

• {PATH_TO_CA_CERT} е местоположението на главния сертификат на CA, използван от брокера Kafka
• {CLIENT_USER} и {CLIENT_PASSWORD} са потребителските идентификационни данни за клиента.

Изпълнете следната команда, за да видите съобщението, консумирано от kafkacat:

• експорт KAFKA_FQDN=
• експорт METRICS_TOPIC=paa.public.accounts. .метрика
• kafkacat -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -e

където {METRICS_TOPIC} е името на темата на Kafka с префикс „paa.public.“.

ЗАБЕЛЕЖКА: По-старите версии на kafkacat не предоставят опцията -F за четене на настройките на клиента от a file. Ако използвате такава версия, трябва да предоставите същите настройки от командния ред, както е показано по-долу.

kafkacat -b ${KAFKA_FQDN}:9093 \

• X security.protocol=SASL_SSL \
• X ssl.ca.location={PATH_TO_CA_CERT} \
• X sasl.mechanisms=ОБИКНОВЕН \
• X sasl.username={CLIENT_USER} \
• X sasl.password={CLIENT_PASSWORD} \
• t ${METRICS_TOPIC} -C -e

За отстраняване на грешки в свързаността можете да използвате опцията -d:

Отстраняване на грешки в потребителските комуникации
kafkacat -d потребител -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -e
# Комуникации с посредник за отстраняване на грешки
kafkacat -d брокер -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -e

Не забравяйте да се обърнете към документацията за използваната клиентска библиотека Kafka, тъй като свойствата може да се различават от тези в client.properties.

Формат на съобщението
Съобщенията, използвани за темите за показатели и метаданни, са сериализирани във формат буфери на протокола (protobuf) (вж. developers.google.com/protocol-buffers). Схемите за тези съобщения се придържат към следния формат:

Схема на Metrics Protobuf

• синтаксис = “proto3”;
• импортирайте „google/protobuf/timestamp.proto”;
• пакет paa.streamingapi;
• опция go_package = “.;paa_streamingapi”;
• съобщение Metrics {
• google.protobuf.Timestamp времеamp = 1;
• карта стойности = 2;
• int32 stream_id = 3;
• }
• /**
• * Стойността на показателя може да бъде цяло число или число с плаваща фигура.
• */
• съобщение MetricValue {
• един от тип {
• int64 int_val = 1;
• float float_val = 2;
• }
• }

Схема на метаданни Protobuf

• синтаксис = “proto3”;
• пакет paa.streamingapi;
• опция go_package = “.;paa_streamingapi”;
• метаданни на съобщението {
• int32 stream_id = 1;
• низ stream_name = 2;
• карта tags = 13;
• }

Клиент Прampлес

ЗАБЕЛЕЖКА: Тези команди са предназначени за изпълнение на външен клиент, напрampпуснете вашия лаптоп или подобен, а не в Центъра за управление.
ЗАБЕЛЕЖКА: За да се показва информация за показателите, уверете се, че поне един монитор работи в Центъра за управление.

Тарболът на Центъра за управление включва архива paa-streaming-api-client-examples.tar.gz (клиентски прamples), който съдържа example Python скрипт, показващ как да използвате API за поточно предаване.

Инсталиране и конфигуриране на клиент Прampлес
Намирате бившия клиентampфайлове в папката Paragon Active Assurance Control Center:

• експортиране CC_VERSION=4.1.0
• cd ./paa-control-center_${CC_VERSION}
• ls paa-streaming-api-client-exampлес*

За да инсталирате client-exampфайлове на вашия външен клиентски компютър, продължете както следва:

• # Създайте директория за извличане на съдържанието на клиента напрamples tarball
• mkdir paa-streaming-api-client-exampлес
• # Извлечете съдържанието на клиента напрamples tarball
• tar xzf paa-streaming-api-client-examples.tar.gz -C paa-streaming-api-client-exampлес
• # Отидете в новосъздадената директория
• cd paa-streaming-api-client-exampлес

клиент-бamples изисква Docker за стартиране. Инструкции за изтегляне и инсталиране на Docker можете да намерите на https://docs.docker.com/engine/install.

Използване на Client Exampлес
Клиентът-бившamples tools могат да работят в основен или разширен режим за изграждане на exampфайлове с различна сложност. И в двата случая също е възможно да стартирате ексampфайлове с конфигурация file съдържащи допълнителни свойства за по-нататъшно персонализиране на клиентската страна.

Основен режим
В основния режим показателите и техните метаданни се предават отделно. За тази цел клиентът слуша всяка тема на Kafka, достъпна за външен достъп, и просто отпечатва получените съобщения на конзолата.
За да започнете изпълнението на основния прamples, тичам:

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

където ACCOUNT_SHORTNAME е краткото име на акаунта, от който искате да получите показателите.
Да се ​​прекрати изпълнението на изпample, натиснете Ctrl + C. (Възможно е да има малко забавяне, преди изпълнението да спре, защото клиентът чака събитие за изчакване.)

Разширен режим

ЗАБЕЛЕЖКА: Показателите се показват само за HTTP монитори, работещи в Центъра за управление.

Изпълнението в разширен режим показва връзката между показателите и съобщенията с метаданни. Това е
възможно благодарение на наличието във всяко съобщение за метрика на поле за идентификатор на поток, което препраща към съответното съобщение с метаданни.
За да изпълните напредналия изхamples, тичам:

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

където ACCOUNT_SHORTNAME е краткото име на акаунта, от който искате да получите показателите.
Да се ​​прекрати изпълнението на изпample, натиснете Ctrl + C. (Възможно е да има малко забавяне, преди изпълнението да спре, защото клиентът чака събитие за изчакване.)

Допълнителни настройки
Възможно е стартиране на ексampфайлове с допълнителна конфигурация на клиента с помощта на –config-file опция, последвана от a file име, съдържащо свойства във формата ключ=стойност.

• build.sh run-advanced \
• –kafka-brokers localhost:9092 \
• – акаунт ACCOUNT_SHORTNAME \
• –конфигурация-file client_config.properties

ЗАБЕЛЕЖКА: Всички files, посочени в командата по-горе, трябва да се намират в текущата директория и да се използват само относителни пътища. Това се отнася както за –config-file аргумент и към всички записи в конфигурацията file които описват file местоположения.

Валидиране на автентификация на външен клиент
За да потвърдите автентификацията на клиента извън Центъра за управление с помощта на client-examples, изпълнете следните стъпки:

От папката Paragon Active Assurance Control Center превключете към paa-streaming-api-client-exampпапка les:

cd paa-streaming-api-client-exampлес

• Копирайте основния сертификат на CA ca-cert в текущата директория.
• Създайте client.properties file със следното съдържание:

security.protocol=SASL_SSL ssl.ca.location=ca-серт
sasl.mechanism=ОБИКНОВЕН
sasl.username={CLIENT_USER}
sasl.password={CLIENT_PASSWORD}

където {CLIENT_USER} и {CLIENT_PASSWORD} са потребителските идентификационни данни за клиента.

Стартирайте основен изхampлес:

• експорт KAFKA_FQDN=
• build.sh run-basic –kafka-brokers ${KAFKA_FQDN}:9093 \
• – акаунт ACCOUNT_SHORTNAME
• –конфигурация-file client.properties

където ACCOUNT_SHORTNAME е краткото име на акаунта, от който искате да получите показателите.

Стартирайте разширен ексampлес:

• експорт KAFKA_FQDN=
• build.sh run-advanced –kafka-brokers ${KAFKA_FQDN}:9093 \
• – акаунт ACCOUNT_SHORTNAME
• –конфигурация-file client.properties

Приложение

В това приложение описваме как да създадете:

• хранилище за ключове file за съхранение на SSL сертификата на брокера Kafka
• доверителен магазин file за съхраняване на основния сертификат на сертифициращия орган (CA), използван за подписване на сертификата на брокер Kafka.

Създаване на сертификат за брокер Kafka
Създаване на сертификат с помощта на истински сертифициращ орган (препоръчително)
Препоръчително е да получите истински SSL сертификат от доверен CA.
След като сте избрали CA, копирайте техния CA-cert сертификат file към вашия собствен път, както е показано по-долу:

• експортиране на CA_PATH=~/my-ca
• mkdir ${CA_PATH}
• cp ca-cert ${CA_PATH}

Създайте свой собствен сертифициращ орган

ЗАБЕЛЕЖКА: Обикновено сертификатът ви трябва да е подписан от истински сертифициращ орган; вижте предходния подраздел. Това, което следва, е просто бившampле.

Тук създаваме наш собствен основен сертификат на Сертифициращ орган (CA). file валиден за 999 дни (не се препоръчва в производство):

• # Създайте директория за съхранение на CA
• експортиране на CA_PATH=~/my-ca
• mkdir ${CA_PATH}
• # Генериране на CA сертификат
• openssl req -new -x509 -keyout ${CA_PATH}/ca-key -out ${CA_PATH}/ca-cert -days 999

Създаване на Client Truststore
Сега можете да създадете truststore file който съдържа генерирания по-горе ca-cert. Това file ще са необходими на клиента на Kafka, който ще има достъп до API за поточно предаване:

• keytool -keystore kafka.client.truststore.jks \
  • псевдоним CARoot \
  • importcert -file ${CA_PATH}/ca-cert

Сега, когато CA сертификатът е в truststore, клиентът ще има доверие на всеки сертификат, подписан с него.
Трябва да копирате file kafka.client.truststore.jks към известно местоположение на вашия клиентски компютър и го посочете в настройките.

Създаване на Keystore за Kafka Broker
За да генерирате SSL сертификата на брокера на Kafka и след това хранилището за ключове kafka.server.keystore.jks, продължете както следва:

Генериране на SSL сертификат
По-долу 999 е броят дни на валидност на хранилището за ключове, а FQDN е ​​напълно квалифицираното име на домейн на клиента (публично име на хост на възела).

ЗАБЕЛЕЖКА: Важно е FQDN да съвпада с точното име на хост, което клиентът на Kafka ще използва, за да се свърже с Центъра за управление.

• sudo mkdir -p /var/ssl/private
• sudo chown -R $ПОТРЕБИТЕЛ: /var/ssl/private
• cd /var/ssl/private
• експортиране на FQDN= keytool -keystore kafka.server.keystore.jks \
• – псевдоним сървър \
• – валидност 999 \
• – genkey -keyalg RSA -ext SAN=dns:${FQDN}

Създайте заявка за подписване на сертификат и я запазете в file име cert-server-request:

• keytool -keystore kafka.server.keystore.jks \
  • – псевдоним сървър \
  • – certreq \
  • – file cert-сървър-заявка

Сега трябва да изпратите file cert-server-request до вашия Сертифициращ орган (CA), ако използвате истински. След това те ще върнат подписания сертификат. По-долу ще наричаме това cert-server-signed.

Подписване на SSL сертификата с помощта на собствено създаден CA сертификат

ЗАБЕЛЕЖКА: Отново, използването на собствен CA не се препоръчва в производствена система.

Подпишете сертификата с помощта на CA чрез file cert-server-request, който произвежда подписания сертификат cert-server-signed. Виж отдолу; ca-password е паролата, зададена при създаване на CA сертификат.

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

Импортиране на подписания сертификат в Keystore

Импортирайте основния сертификат ca-cert в хранилището за ключове:

• keytool -keystore kafka.server.keystore.jks \
  • – псевдоним ca-cert \
  • – внос \
  • – file ${CA_PATH}/ca-cert

Импортирайте подписания сертификат, наричан cert-server-signed:

• keytool -keystore kafka.server.keystore.jks \
  • – псевдоним сървър \
  • – внос \
  • – file сертификат-сървър-подписан

The file kafka.server.keystore.jks трябва да се копира на известно място на сървъра на Центъра за управление и след това да се използва в /etc/kafka/server.properties.

Използване на API за поточно предаване

В ТОЗИ РАЗДЕЛ

• Общи | 20
• Имена на темите на Кафка | 21
• Exampфайлове за използване на API за поточно предаване | 21

генерал
Приложният програмен интерфейс (API) за поточно предаване извлича както тестови, така и мониторни данни. Не е възможно да се отдели една от тези категории.
API за поточно предаване не извлича данни от базирани на скриптове тестове (тези, представени от правоъгълник вместо част от мозайката в графичния интерфейс на Центъра за управление), като тестове за активиране на Ethernet услуги и тестове за прозрачност.

Имена на темите на Кафка
Имената на темите на Kafka за API за стрийминг са както следва, където %s е краткото име на акаунта в Центъра за управление (посочен при създаването на акаунта):

• const (
• exporterName = “kafka”
• metadataTopicTpl = “paa.public.accounts.%s.metadata” metricsTopicTpl = “paa.public.accounts.%s.metrics” )

Exampфайлове за използване на API за поточно предаване
Бившиятampфайловете, които следват, се намират в tarball paa-streaming-api-client-examples.tar.gz, съдържащ се в архива на контролния център.
Първо, има основен изхample демонстрира как показателите и техните метаданни се предават отделно и просто отпечатват получените съобщения на конзолата. Можете да го стартирате по следния начин:

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

Има и по-напреднал ексample, където показателите и съобщенията за метаданни са корелирани. Използвайте тази команда, за да го стартирате:

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

Трябва да използвате sudo, за да изпълнявате Docker команди като тези по-горе. По желание можете да следвате стъпките след инсталирането на Linux, за да можете да изпълнявате Docker команди без sudo. За подробности отидете на docs.docker.com/engine/install/linux-postinstall.

Juniper Networks, логото на Juniper Networks, Juniper и Junos са регистрирани търговски марки на Juniper Networks, Inc. в Съединените щати и други страни. Всички други търговски марки, марки за услуги, регистрирани марки или регистрирани марки за услуги са собственост на съответните им собственици. Juniper Networks не поема отговорност за неточности в този документ. Juniper Networks си запазва правото да променя, модифицира, прехвърля или по друг начин да преработва тази публикация без предизвестие. Авторско право © 2023 Juniper Networks, Inc. Всички права запазени.

Документи / Ресурси

Juniper NETWORKS Streaming API софтуер [pdf] Ръководство за потребителя API софтуер за поточно предаване, API софтуер, софтуер

Референции

• Ръководство за потребителя