Інженерна простота
Посібник із потокового API

вступ

У цьому посібнику описано, як отримати дані з Paragon Active Assurance за допомогою потокового API продукту.
API, а також потоковий клієнт входять до інсталяції Paragon Active Assurance.
Однак перед використанням API потрібно трохи налаштувати. Це описано в розділі «Налаштування потокового API» на сторінці 1.

закінченоview

У цьому розділі описано, як налаштувати Streaming API, щоб дозволити підписку на повідомлення метрик через Kafka.
Нижче ми розглянемо:

• Як увімкнути Streaming 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

Як згадувалося раніше, Streaming API дозволяє зовнішнім клієнтам отримувати інформацію про показники з Kafka.
Усі показники, зібрані тестовими агентами під час тестування або завдання моніторингу, надсилаються до служби Stream.
Після етапу обробки служба Stream публікує ці показники на Kafka разом із додатковими метаданими.

Теми Кафки

У Кафки є концепція тем, до яких публікуються всі дані. У Paragon Active Assurance доступно багато таких тем Kafka; однак лише частина з них призначена для зовнішнього доступу.
Кожен обліковий запис Paragon Active Assurance в Центрі керування має дві спеціальні теми. Нижче ACCOUNT — коротка назва облікового запису:

• paa.public.accounts.{ACCOUNT}.metrics
• Усі повідомлення про показники для даного облікового запису публікуються в цій темі
• Великі обсяги даних
• Висока частота оновлення
• paa.public.accounts.{ACCOUNT}.metadata
• Містить метадані, пов’язані з даними показників, напрampлише тест, монітор або тестовий агент, пов’язаний із показниками
• Невеликі обсяги даних
• Низька частота оновлення

Увімкнення потокового API

ПРИМІТКА: Ці інструкції слід виконувати на сервері Центру керування за допомогою sudo.
Оскільки Streaming API додає певні накладні витрати на Центр керування, він не ввімкнено за замовчуванням. Щоб увімкнути API, ми повинні спочатку ввімкнути публікацію метрик у Kafka в основній конфігурації file:

• /etc/netrounds/netrounds.conf
  KAFKA_METRICS_ENABLED = Правда
  УВАГА: Увімкнення цієї функції може вплинути на продуктивність Центру керування. Переконайтеся, що розміри вашого екземпляра відповідні.
  Далі, щоб увімкнути перенаправлення цих показників до правильних тем Kafka:
• /etc/netrounds/metrics.yaml
  потоковий API: правда

Щоб увімкнути та запустити служби Streaming API, виконайте:
Служби sudo ncc увімкнути метрики timescaledb Служби sudo ncc запустити метрики timescaledb
Нарешті, перезапустіть служби:
перезапуск служб sudo ncc

Перевірка роботи API потокового передавання в Центрі керування

ПРИМІТКА: Ці інструкції потрібно виконувати на сервері Центру керування.
Тепер ви можете переконатися, що ви отримуєте показники щодо правильних тем Kafka. Для цього встановіть утиліту kafkacat:
sudo apt-get update sudo apt-get install 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”Client Examples» на сторінці 14
Це підтверджує, що у нас є робочий API потокового передавання з Центру керування. Однак, швидше за все, ви зацікавлені в доступі до даних із зовнішнього клієнта. У наступному розділі описано, як відкрити Kafka для зовнішнього доступу.

Відкриття Kafka для зовнішніх хостів

ПРИМІТКА: Ці інструкції потрібно виконувати на сервері Центру керування.
За замовчуванням Kafka, запущена в Центрі керування, налаштована на прослуховування лише на локальному хості для внутрішнього використання.
Можна відкрити 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 та Streaming 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: A file містить довірені сертифікати ЦС.
Щоб налаштувати автентифікацію між зовнішнім клієнтом і Kafka, що працює в Центрі керування, обидві сторони повинні мати визначене сховище ключів із відповідним сертифікатом, підписаним центром сертифікації (CA), разом із кореневим сертифікатом CA.
Окрім цього, клієнт також повинен мати довірене сховище з кореневим сертифікатом ЦС.
Кореневий сертифікат ЦС є спільним для брокера Kafka та клієнта Kafka.
Створення необхідних сертифікатів
Це описано в «Додатку» на сторінці 17.
Конфігурація Kafka Broker SSL/TLS у Центрі керування
ПРИМІТКА: Ці інструкції потрібно виконувати на сервері Центру керування.
ПРИМІТКА: Перш ніж продовжити, ви повинні створити сховище ключів, яке містить сертифікат SSL, дотримуючись інструкцій у «Додатку» на сторінці 17. Шляхи, згадані нижче, походять із цих інструкцій.
Сховище ключів SSL – це a file зберігається на диску з file розширення .jks.
Коли у вас будуть доступні необхідні сертифікати, створені як для брокера Kafka, так і для клієнта Kafka, ви можете продовжити налаштування брокера Kafka, що працює в Центрі керування. Вам необхідно знати наступне:

• : загальнодоступне ім’я хосту Центру керування; це має бути вирішуваним і доступним для клієнтів Kafka.
• : пароль сховища ключів, наданий під час створення сертифіката SSL.
• і : це паролі, які ви хочете встановити для адміністратора та користувача клієнта відповідно.
  Зауважте, що ви можете додати більше користувачів, як зазначено у прикладіample.
  Відредагуйте або додайте (з доступом sudo) наведені нижче властивості в /etc/kafka/server.properties, вставивши наведені вище змінні, як показано:

УВАГА: Не видаляйте PLAINTEXT://localhost:9092 ; це порушить функціональність Центру керування, оскільки внутрішні служби не зможуть спілкуватися.
…# Адреси, які прослуховує брокер Kafka.
слухачі=ПЛАІНТЕКСТ://локальний хост: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=PLAIN
listener.name.sasl_ssl.plain.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginMo необхідний параметр \ ім'я користувача=”admin” \ пароль=” ” \ user_admin=” ” \ user_client=” ”; # ПРИМІТКА можна додати більше користувачів за допомогою user_ =
# Авторизація, увімкніть ACL authorizer.class.name=kafka.security.authorizer.AclAuthorizer super.users=Користувач:admin
Налаштування списків контролю доступу (ACL)
Увімкнення ACL на локальному хості
УВАГА: Спершу ми повинні налаштувати ACL для localhost, щоб сам Центр керування все ще міг отримати доступ до Kafka. Якщо цього не зробити, речі зламаються.
######### Записи ACL для анонімних користувачів
/usr/lib/kafka/bin/kafka-acls.sh \
–authorizer kafka.security.authorizer.AclAuthorizer \ –authorizer-properties zookeeper.connect=localhost:2181 \ –add –allow-principal Користувач: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 Користувач: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 Користувач:ANONYMOUS –allow-host 127.0.0.1 –group '*'
Потім нам потрібно ввімкнути ACL для зовнішнього доступу лише для читання, щоб зовнішні користувачі могли читати теми paa.public.*.
ПРИМІТКА: Для більш точного керування зверніться до офіційної документації Kafka.
######### Записи ACL для зовнішніх користувачів
/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 \
–тема paa.public. –resource-pattern-type префікс
Після цього потрібно перезапустити служби:
перезапуск служб sudo ncc
Щоб переконатися, що клієнт може встановити безпечне з’єднання, виконайте таку команду на зовнішньому клієнтському комп’ютері (не на сервері Центру керування). Нижче 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
ПРИМІТКА: Ці інструкції слід виконувати на клієнтському комп’ютері (а не на сервері Центру керування).
ПРИМІТКА: Щоб відобразити інформацію про показники, переконайтеся, що принаймні один монітор працює в Центрі керування.
Щоб перевірити та підтвердити підключення як зовнішнього клієнта, можна скористатися утилітою kafkacat, яку було встановлено в розділі «Перевірка роботи потокового API у Центрі керування» на сторінці 4.
Виконайте наступні дії:
ПРИМІТКА: Нижче CLIENT_USER – це користувач, попередньо вказаний у file /etc/kafka/server.properties в
Центр керування: а саме user_client і встановлений там пароль.
Кореневий сертифікат ЦС, який використовується для підпису сертифіката SSL на стороні сервера, має бути присутнім на клієнті.

• Створіть a file client.properties з таким вмістом:
  security.protocol=SASL_SSL
  ssl.ca.location={PATH_TO_CA_CERT}
  sasl.mechanisms=PLAIN
  sasl.username={CLIENT_USER}
  sasl.password={CLIENT_PASSWORD} де
  • {PATH_TO_CA_CERT} – це розташування кореневого сертифіката ЦС, який використовується брокером Kafka
  • {CLIENT_USER} і {CLIENT_PASSWORD} є обліковими даними користувача для клієнта.
  • Виконайте таку команду, щоб переглянути повідомлення, яке використовує kafkacat:
  експорт KAFKA_FQDN=
  експорт METRICS_TOPIC=paa.public.accounts. .metrics
  kafkacat -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -e
  де {METRICS_TOPIC} — назва теми Кафки з префіксом «paa.public.».

ПРИМІТКА: У старіших версіях kafkacat немає опції -F для читання налаштувань клієнта з a file. Якщо ви використовуєте таку версію, ви повинні вказати ті самі налаштування з командного рядка, як показано нижче.
kafkacat -b ${KAFKA_FQDN}:9093 \
-X security.protocol=SASL_SSL \
-X ssl.ca.location={ШЛЯХ_ДО_CA_CERT} \
-X sasl.mechanisms=PLAIN \
-X sasl.username={CLIENT_USER} \
-X sasl.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). Схеми для цих повідомлень відповідають такому формату:
Схема Protobuf метрики
синтаксис = “proto3”; імпортувати “google/protobuf/timestamp.proto”; пакет paa.streamingapi; option go_package = “.;paa_streamingapi”; Метрики повідомлення { google.protobuf.Timestamp часamp = 1; карта значення = 2; int32 вимірювання_id = 3; } /** * Значення метрики може бути цілим числом або числом з плаваючою точкою. */
повідомлення MetricValue { oneof type { int64 int_val = 1; float float_val = 2; }}
Схема метаданих Protobuf
синтаксис = “proto3”; пакет paa.streamingapi; option go_package = “.;paa_streamingapi”; Метадані повідомлення { int32 вимірювання_id = 1; рядок вимірювання_name = 2; карта tags = 13; }

Клієнт Прampлес

ПРИМІТКА: Ці команди призначені для запуску на зовнішньому клієнті, наприкладampзалиште свій ноутбук або щось подібне, а не в Центр керування.
ПРИМІТКА: Щоб відображати інформацію про показники, переконайтеся, що принаймні один монітор працює в Центрі керування.
Арарх Центр керування містить архів paa-streaming-api-client-examples.tar.gz (клієнт-examples), який містить example сценарій Python, який показує, як використовувати потоковий API.
Встановлення та налаштування клієнта Прampлес
Ви знаходите колишнього клієнтаampу папці Paragon Active Assurance Control Center:
експорт CC_VERSION=3.3.1
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-examples client-exampДля запуску les потрібен Docker. Завантаження та інструкції з встановлення Docker можна знайти за адресою https://docs.docker.com/engine/install.
Використання Client Exampлес
Клієнт-ексampінструменти les можна запускати в базовому або розширеному режимі для створення exampфайли різної складності. В обох випадках також можна запустити ексampфайли з конфігурацією file містить додаткові властивості для подальшого налаштування клієнтської сторони.
Базовий режим У базовому режимі показники та їх метадані передаються окремо. Для цього клієнт прослуховує кожну тему Kafka, доступну для зовнішнього доступу, і просто друкує отримані повідомлення на консоль.
Для початку виконання основного екзampфайли, запустіть: ./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 ACCOUNT_SHORTNAME \ –config-file client_config.properties
ПРИМІТКА: всі files, на які посилається наведена вище команда, мають бути розташовані в поточному каталозі та використовувати лише відносні шляхи. Це стосується як –config-file аргумент і до всіх записів у конфігурації file що описують file локації.
Перевірка автентифікації зовнішнього клієнта
Щоб перевірити автентифікацію клієнта поза Центром керування за допомогою client-examples, виконайте такі дії:

• З папки Paragon Active Assurance Control Center перейдіть до paa-streaming-api-clientexampпапка les:
  cd paa-streaming-api-client-exampлес
• Скопіюйте кореневий сертифікат CA-cert у поточний каталог.
• Створіть client.properties file з таким змістом:
  security.protocol=SASL_SSL
  ssl.ca.location=ca-cert
  sasl.mechanism=PLAIN
  sasl.username={CLIENT_USER}
  sasl.password={CLIENT_PASSWORD}
  де {CLIENT_USER} і {CLIENT_PASSWORD} – це облікові дані користувача для клієнта.
• Запустіть основний прикладamples:
  експорт KAFKA_FQDN= ./build.sh run-basic –kafka-brokers ${KAFKA_FQDN}:9093 \ –account ACCOUNT_SHORTNAME
  –конфігурація-file client.properties, де ACCOUNT_SHORTNAME – це коротка назва облікового запису, з якого ви хочете отримати показники.
• Запустіть розширений прикладamples:
  експорт KAFKA_FQDN= ./build.sh run-advanced –kafka-brokers ${KAFKA_FQDN}:9093 \ –account ACCOUNT_SHORTNAME–config-file client.properties

Додаток

У цьому додатку ми описуємо, як створити:

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

Створення сертифіката брокера Kafka
Створення сертифіката за допомогою справжнього центру сертифікації (рекомендовано)
Рекомендується отримати справжній SSL-сертифікат від довіреного ЦС.
Визначившись із ЦС, скопіюйте його кореневий сертифікат ЦС ca-cert file на свій власний шлях, як показано нижче:
експорт CA_PATH=~/my-ca mkdir ${CA_PATH} cp ca-cert ${CA_PATH}
Створіть свій власний центр сертифікації
ПРИМІТКА: Зазвичай ваш сертифікат повинен бути підписаний справжнім центром сертифікації; див. попередній підрозділ. Далі йде лише колишнійample.
Тут ми створюємо власний кореневий сертифікат центру сертифікації (CA). file дійсний протягом 999 днів (не рекомендовано для виробництва):
# Створіть каталог для зберігання експорту CA_PATH=~/my-ca mkdir ${CA_PATH}
# Створіть сертифікат CA openssl req -new -x509 -keyout ${CA_PATH}/ca-key -out ${CA_PATH}/ca-cert -days 999
Створення довірчого сховища клієнтів
Тепер ви можете створити довірче сховище file який містить ca-cert, створений вище. Це file знадобиться клієнту Kafka, який матиме доступ до потокового API:
keytool -keystore kafka.client.truststore.jks \ -alias CARoot \ -importcert -file ${CA_PATH}/ca-cert
Тепер, коли сертифікат ЦС знаходиться в довіреному сховищі, клієнт довіряє будь-якому сертифікату, підписаному ним.
Ви повинні скопіювати file kafka.client.truststore.jks у відоме місце на вашому клієнтському комп’ютері та вкажіть на нього в налаштуваннях.
Створення сховища ключів для брокера Kafka
Щоб створити сертифікат SSL брокера Kafka, а потім сховище ключів kafka.server.keystore.jks, виконайте такі дії:
Створення SSL-сертифікату
Нижче 999 – це кількість днів дійсності сховища ключів, а FQDN – це повне доменне ім’я клієнта (публічне ім’я хоста вузла).
ПРИМІТКА: Важливо, щоб повне доменне ім’я відповідало точному імені хосту, який клієнт Kafka використовуватиме для підключення до Центру керування. 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 \ -validity 999 \ -genkey -keyalg RSA -ext SAN=dns:${FQDN}
Створіть запит на підписання сертифіката та збережіть його в file іменований cert-server-request:
keytool -keystore kafka.server.keystore.jks \ -alias server \ -certreq \ -file cert-server-request
Тепер ви повинні надіслати file cert-server-request до вашого центру сертифікації (CA), якщо ви використовуєте справжній. Потім вони повернуть підписаний сертифікат. Нижче ми називатимемо це cert-server-signed. Підписання сертифіката SSL за допомогою власноруч створеного сертифіката ЦС
ПРИМІТКА: Знову ж таки, використання власного ЦС не рекомендується у виробничій системі. Підпишіть сертифікат за допомогою CA за допомогою file cert-server-request, який створює підписаний сертифікат cert-server-signed. Дивись нижче; ca-password — це пароль, встановлений під час створення сертифіката ЦС.
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}
Імпорт підписаного сертифіката в сховище ключів
Імпортуйте кореневий сертифікат ca-cert у сховище ключів:
keytool -keystore kafka.server.keystore.jks \ -alias ca-cert \ -import \ -file ${CA_PATH}/ca-cert
Імпортуйте підписаний сертифікат, який називається cert-server-signed:
keytool -keystore kafka.server.keystore.jks \ -alias server \ -import \ -file підписано cert-server
The file kafka.server.keystore.jks слід скопіювати у відоме місце на сервері Центру керування, а потім посилатися на нього в /etc/kafka/server.properties.
Використання потокового API

Загальний

API потокового передавання отримує як тестові дані, так і дані моніторингу. Виділити одну з цих категорій неможливо.
API потокової передачі не отримує дані з тестів на основі сценаріїв (тих, що представлені прямокутником замість фрагмента головоломки в графічному інтерфейсі Центру керування), таких як тести активації служби Ethernet і тести прозорості.
Назви тем Кафки
Назви тем Kafka для потокового API є такими, де %s — коротка назва елемента керування
Обліковий запис центру (вказується при створенні облікового запису):
const (exporterName = “kafka”metadataTopicTpl = “paa.public.accounts.%s.metadata” metricsTopicTpl = “paa.public.accounts.%s.metrics”)
Exampопис використання потокового API
Колишнійampнаступні файли можна знайти в архіві paa-streaming-api-client-examples.tar.gz міститься в архіві Центру керування.
По-перше, є базовий ексample демонструє, як метрики та їхні метадані передаються окремо, і просто друкує отримані повідомлення на консолі. Ви можете запустити його таким чином: sudo ./build.sh run-basic –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME
Є також більш просунутий ексampфайл, де метрики та повідомлення метаданих співвідносяться. Використовуйте цю команду, щоб запустити його:
sudo ./build.sh run-advanced –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME Щоб запускати такі команди Docker, як наведені вище, потрібно використовувати sudo. За бажанням ви можете виконати кроки після інсталяції Linux, щоб мати можливість запускати команди Docker без sudo.
Для отримання детальної інформації перейдіть на сторінку docs.docker.com/engine/install/linux-postinstall.
Juniper Networks, логотип Juniper Networks, Juniper і Junos є зареєстрованими товарними знаками Juniper Networks, Inc. у Сполучених Штатах та інших країнах. Усі інші торгові марки, знаки обслуговування, зареєстровані знаки або зареєстровані знаки обслуговування є власністю відповідних власників. Juniper Networks не несе відповідальності за будь-які неточності в цьому документі. Juniper Networks залишає за собою право змінювати, модифікувати, передавати або іншим чином переглядати цю публікацію без попередження. © Juniper Networks, Inc., 2022. Усі права захищено.

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

Juniper Streaming API [pdfПосібник користувача API потокового передавання, API

Список літератури

• Посібник користувача