Ялівець-логотип

Програмне забезпечення Juniper NETWORKS Streaming APIJuniper-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.

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

Теми Кафки
Streaming API використовує теми Kafka для організації та зберігання показників і метаданих. Теми Kafka можна створювати та керувати відповідно до конкретних вимог.

Увімкнення потокового API
Щоб увімкнути Streaming API, виконайте такі дії:

  1. Виконайте такі команди на сервері Центру керування за допомогою sudo:
KAFKA_METRICS_ENABLED = Справжні служби sudo ncc увімкнути метрики timescaledb служби sudo ncc запустити метрики timescaledb перезапустити служби sudo ncc

Перевірка роботи потокового API в Центрі керування:
Щоб переконатися, що ви отримуєте показники щодо правильних тем Kafka:

  1. Встановіть утиліту kafkacat за допомогою таких команд:
    sudo apt-get update
    sudo apt-get install kafkacat
  1. Замініть «myaccount» короткою назвою вашого облікового запису в
    Центр управління URL:
    експорт METRICS_TOPIC=paa.public.accounts.myaccount.metrics
    експорт METADATA_TOPIC=paa.public.accounts.myaccount.metadata
  1. Виконайте наступну команду для view метрики:
    kafkacat -b ${KAFKA_FQDN}:9092 -t ${METRICS_TOPIC} -C -e
    Примітка: наведена вище команда відобразить показники.
  2. до view метаданих, виконайте таку команду:
    kafkacat -b ${KAFKA_FQDN}:9092 -t ${METADATA_TOPIC} -C -e

Примітка: наведена вище команда відображатиме метадані, але оновлюватиметься не так часто.

Клієнт Прampлес
Для клієнта напрampі додаткову інформацію дивіться на сторінці 14 посібника користувача.

FAQ (Часті запитання)

  • З: Що таке Paragon Active Assurance?
    A: Paragon Active Assurance — це продукт, який забезпечує можливості моніторингу та тестування.
  • З: Що таке API потокового передавання?
    A: Streaming API — це функція в Paragon Active Assurance, яка дозволяє зовнішнім клієнтам отримувати інформацію про показники з Kafka.
  • З: Як увімкнути API потокового передавання?
    A: Щоб увімкнути Streaming API, виконайте кроки, описані в розділі «Увімкнення Streaming API» посібника користувача.
  • З: Як я можу перевірити, чи працює потоковий API?
    A: Зверніться до розділу «Перевірка роботи API потокового передавання в Центрі керування», щоб дізнатися, як перевірити функціональність API потокового передавання.

вступ

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

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

  • Як увімкнути 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 разом із додатковими метаданими.

Juniper-NETWORKS-Streaming-API-Software- (1)

Теми Кафки
У Кафки є концепція тем, до яких публікуються всі дані. У 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:

KAFKA_METRICS_ENABLED = Правда

УВАГА: Увімкнення цієї функції може вплинути на продуктивність Центру керування. Переконайтеся, що розміри вашого екземпляра відповідні.

Далі, щоб увімкнути перенаправлення цих показників до правильних тем Kafka:

потоковий 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:

Juniper-NETWORKS-Streaming-API-Software- (2)

*) Автентифікація за іменем користувача/паролем виконується на каналі, зашифрованому SSL

Щоб повністю зрозуміти, як працює шифрування SSL/TLS для Kafka, перегляньте офіційну документацію: docs.confluent.io/platform/current/kafka/encryption.html

Сертифікат SSL/TLS завершеноview

ПРИМІТКА: У цьому підрозділі ми будемо використовувати таку термінологію:

Сертифікат: сертифікат SSL, підписаний центром сертифікації (CA). Кожен брокер Kafka має один.
Сховище ключів: сховище ключів file який зберігає сертифікат. Сховище ключів file містить закритий ключ сертифіката; тому його потрібно зберігати безпечно.
Truststore: А 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
  • ім'я користувача=”адміністратор” \
  • пароль=” ” \
  • user_admin=” ” \
  • user_client=” ”;
  • # ПРИМІТКА: за допомогою user_ можна додати більше користувачів =
  • # Авторизація, увімкніть ACL
  • authorizer.class.name=kafka.security.authorizer.AclAuthorizer super.users=Користувач:адміністратор

Налаштування списків контролю доступу (ACL)

Увімкнення ACL на локальному хості

ПОПЕРЕДЖЕННЯ: спершу ми повинні налаштувати ACL для локального хосту, щоб сам Центр керування все ще міг отримати доступ до 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 Користувач: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

Щоб переконатися, що клієнт може встановити безпечне з’єднання, виконайте таку команду на зовнішньому пристрої
клієнтський комп’ютер (не на сервері Центру керування). Нижче 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={PATH_TO_CA_CERT} \
  • X sasl.mechanisms=PLAIN \
  • 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). Схеми для цих повідомлень відповідають такому формату:

Схема Protobuf метрики

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

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

  • синтаксис = “proto3”;
  • пакет paa.streamingapi;
  • option go_package = “.;paa_streamingapi”;
  • метадані повідомлення {
  • int32 stream_id = 1;
  • рядок stream_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=4.1.0
  • cd ./paa-control-center_${CC_VERSION}
  • ls paa-streaming-api-client-exampлес*

Щоб встановити client-exampна зовнішньому клієнтському комп’ютері виконайте такі дії:

  • # Створіть каталог для вилучення вмісту клієнта напрampархівований файл
  • mkdir paa-streaming-api-client-exampлес
  • # Витягти вміст клієнта напрampархівований файл
  • tar xzf paa-streaming-api-client-examples.tar.gz -C paa-streaming-api-client-exampлес
  • # Перейдіть до щойно створеного каталогу
  • cd paa-streaming-api-client-exampлес

клієнт-ексampДля запуску les потрібен Docker. Завантаження та інструкції з встановлення Docker можна знайти за адресою https://docs.docker.com/engine/install.

Використання Client Exampлес
Клієнт-ексampінструменти les можна запускати в базовому або розширеному режимі для створення exampфайли різної складності. В обох випадках також можна запустити ексampфайли з конфігурацією file містить додаткові властивості для подальшого налаштування клієнтської сторони.

Базовий режим
У базовому режимі показники та їхні метадані передаються окремо. Для цього клієнт прослуховує кожну тему Kafka, доступну для зовнішнього доступу, і просто друкує отримані повідомлення на консоль.
Для початку виконання основного екзamples, run:

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

де ACCOUNT_SHORTNAME – це коротка назва облікового запису, з якого ви хочете отримати показники.
Припинити виконання вихample, натисніть Ctrl + C. (Може виникнути невелика затримка, перш ніж виконання зупиниться, оскільки клієнт очікує події тайм-ауту.)

Розширений режим

ПРИМІТКА: Метрики відображаються лише для моніторів HTTP, що працюють у Центрі керування.

Виконання в розширеному режимі показує кореляцію між метриками та повідомленнями метаданих. Це
це можливо завдяки наявності в кожному повідомленні метрики поля ідентифікатора потоку, яке посилається на відповідне повідомлення метаданих.
Для виконання розширеного вихamples, run:

  • build.sh run-advanced –kafka-brokers localhost:9092 –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-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_SHORTNAME
  • –конфігурація-file client.properties

де ACCOUNT_SHORTNAME – це коротка назва облікового запису, з якого ви хочете отримати показники.

Запустіть розширений прикладamples:

  • експорт 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-cert file на свій власний шлях, як показано нижче:

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

Створіть свій власний центр сертифікації

ПРИМІТКА: Зазвичай ваш сертифікат повинен бути підписаний справжнім центром сертифікації; див. попередній підрозділ. Далі йде лише колишнійample.

Тут ми створюємо власний кореневий сертифікат центру сертифікації (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

Створення довірчого сховища клієнтів
Тепер ви можете створити довірче сховище file який містить ca-cert, створений вище. Це file знадобиться клієнту Kafka, який матиме доступ до потокового API:

  • keytool -keystore kafka.client.truststore.jks \
    • псевдонім CARoot \
    • сертифікат імпорту -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
  • експорт 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-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 \
    • – у cert-server-request \
    • – out cert-server-signed \
    • – дні 999 -CAcreateserial \
    • – passin pass:{ca-password}

Імпорт підписаного сертифіката в сховище ключів

Імпортуйте кореневий сертифікат 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 підписано cert-server

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наступні файли можна знайти в архіві 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

Ви повинні використовувати 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 залишає за собою право змінювати, модифікувати, передавати або іншим чином переглядати цю публікацію без попередження. © Juniper Networks, Inc., 2023. Усі права захищено.

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

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

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

Залиште коментар

Ваша електронна адреса не буде опублікована. Обов'язкові поля позначені *