Программное обеспечение API потоковой передачи Juniper NETWORKS

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

Технические характеристики

• Название продукта: Paragon Active Assurance
• Версия: 4.1
• Дата публикации: 2023 ноября 03 г.

Введение:
В этом руководстве представлены инструкции по извлечению данных из Paragon Active Assurance с помощью потокового API продукта. Клиент потоковой передачи и API включены в установку Paragon Active Assurance, но перед использованием API требуется определенная настройка. Процесс настройки описан в разделе «Настройка API потоковой передачи».

Настройка потокового API:
Следующие шаги описывают процесс настройки API потоковой передачи:

Надview
Kafka — это платформа потоковой передачи событий, предназначенная для сбора и хранения данных из различных источников в режиме реального времени. Он позволяет управлять потоками событий распределенным, масштабируемым, отказоустойчивым и безопасным способом. В этом руководстве основное внимание уделяется настройке Kafka для использования функции Streaming API в Центре управления Paragon Active Assurance.

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

Включение потокового API
Чтобы включить API потоковой передачи, выполните следующие действия:

1. Выполните следующие команды на сервере Центра управления с помощью 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 руководства пользователя.

FAQ (часто задаваемые вопросы)

• Вопрос: Что такое Paragon Active Assurance?
  О: Paragon Active Assurance — это продукт, предоставляющий возможности мониторинга и тестирования.
• Вопрос: Что такое API потоковой передачи?
  О: Streaming API — это функция Paragon Active Assurance, которая позволяет внешним клиентам получать информацию о метриках из Kafka.
• Вопрос: Как включить API потоковой передачи?
  О: Чтобы включить API потоковой передачи, выполните действия, описанные в разделе «Включение API потоковой передачи» руководства пользователя.
• Вопрос: Как я могу убедиться, что API потоковой передачи работает?
  О: Инструкции по проверке функциональности API потоковой передачи см. в разделе «Проверка работы API потоковой передачи в Центре управления».

Введение

В этом руководстве описывается, как извлекать данные из Paragon Active Assurance через потоковый API продукта.
API, а также клиент потоковой передачи включены в установку Paragon Active Assurance. Однако, прежде чем вы сможете использовать API, потребуется небольшая настройка. Это описано в главе «Настройка API потоковой передачи» на странице 1.

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

• Как включить потоковый API
• Как настроить Kafka для прослушивания внешних клиентов
• Как настроить Kafka для использования ACL и настроить шифрование SSL для указанных клиентов

Что такое Кафка?
Kafka — это платформа потоковой передачи событий, которая позволяет в режиме реального времени собирать данные, отправляемые из различных источников событий (сенсоры, базы данных, мобильные устройства) в виде потоков событий, а также надежно хранить эти потоки событий для последующего извлечения и обработки.
С помощью Kafka можно управлять сквозной потоковой передачей событий распределенным, масштабируемым, эластичным, отказоустойчивым и безопасным способом.

ПРИМЕЧАНИЕ: Kafka можно настроить разными способами, и он был разработан для обеспечения масштабируемости и резервирования систем. В этом документе основное внимание уделяется только настройке его для использования функции Streaming API, доступной в Центре управления Paragon Active Assurance. Для более сложных настроек мы обращаемся к официальной документации Kafka: kafka.apache.org/26/documentation.html.

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

• Kafka: платформа для потоковой передачи событий.
• Кафка тема: Коллекция событий.
• Подписчик/потребитель Kafka: компонент, отвечающий за получение событий, хранящихся в теме Kafka.
• Брокер Kafka: сервер уровня хранения кластера Kafka.
• SSL/TLS: SSL — это безопасный протокол, разработанный для безопасной отправки информации через Интернет. TLS является преемником SSL, представленного в 1999 году.
• SASL: платформа, обеспечивающая механизмы аутентификации пользователей, проверки целостности данных и шифрования.
• Подписчик Streaming API: компонент, отвечающий за получение событий, хранящихся в темах, определенных в Paragon Active Assurance и предназначенных для внешнего доступа.
• Центр сертификации: доверенное лицо, которое выдает и отзывает сертификаты открытого ключа.
• Корневой сертификат центра сертификации: сертификат открытого ключа, который идентифицирует центр сертификации.

Как работает потоковый API
Как упоминалось ранее, Streaming API позволяет внешним клиентам получать информацию о метриках из Kafka.

Все метрики, собранные агентами тестирования во время выполнения задачи тестирования или мониторинга, отправляются в службу Stream. После этапа обработки служба Stream публикует эти показатели в Kafka вместе с дополнительными метаданными.

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

• paa.public.accounts.{АККАУНТ}.метрики
  • Все сообщения метрик для данной учетной записи публикуются в этой теме
  • Большие объемы данных
  • Высокая частота обновления
• paa.public.accounts.{АККАУНТ}.метаданные
  • Содержит метаданные, связанные с данными метрик, например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 обновление
• sudo apt-get установить kafkacat

Если у вас запущен тест или монитор в Центре управления, вы сможете использовать kafkacat для получения метрик и метаданных по этим темам.
Замените myaccount на короткое имя вашей учетной записи (это то, что вы видите в своем Центре управления). 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

Это подтверждает, что у нас есть работающий Streaming API из Центра управления. Однако, скорее всего, вы заинтересованы в доступе к данным из внешнего клиента. В следующем разделе описывается, как открыть Kafka для внешнего доступа.

Открытие Kafka для внешних хостов

ПРИМЕЧАНИЕ: Эти инструкции должны выполняться на сервере Центра управления.

По умолчанию Kafka, работающий в Центре управления, настроен на прослушивание только на локальном хосте для внутреннего использования. Можно открыть Kafka для внешних клиентов, изменив настройки Kafka.

Подключение к Kafka: предостережения

ОСТОРОЖНОСТЬ: Пожалуйста, прочтите это внимательно, так как легко столкнуться с проблемами подключения к Kafka, если вы не понимаете этих концепций.

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

Шифрование SSL/TLS
Чтобы убедиться, что только доверенные клиенты имеют доступ к Kafka и Streaming API, мы должны настроить следующее:

• Аутентификация: Клиенты должны предоставить имя пользователя и пароль через безопасное соединение SSL/TLS между клиентом и Kafka.
• Авторизация: клиенты, прошедшие проверку подлинности, могут выполнять задачи, регулируемые списками управления доступом.

Вот болееview:

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

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

SSL/TLS-сертификат закончилсяview

ПРИМЕЧАНИЕ: В этом подразделе мы будем использовать следующую терминологию:

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

Чтобы настроить аутентификацию между внешним клиентом и Kafka, работающим в Центре управления, обе стороны должны иметь хранилище ключей, определенное с соответствующим сертификатом, подписанным центром сертификации (ЦС) вместе с корневым сертификатом ЦС.
В дополнение к этому у клиента также должно быть хранилище доверенных сертификатов с корневым сертификатом ЦС.
Корневой сертификат CA является общим для брокера Kafka и клиента Kafka.

Создание необходимых сертификатов
Это описано в «Приложении» на стр. 17.

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

ПРИМЕЧАНИЕ: Эти инструкции должны выполняться на сервере Центра управления.

ПРИМЕЧАНИЕ: Прежде чем продолжить, вы должны создать хранилище ключей, содержащее SSL-сертификат, следуя инструкциям в «Приложении» на стр. 17. Пути, указанные ниже, взяты из этих инструкций.
Хранилище ключей SSL — это file хранится на диске с file расширение .jks.

Когда у вас есть необходимые сертификаты, созданные как для брокера Kafka, так и для клиента Kafka, вы можете продолжить настройку брокера Kafka, работающего в Центре управления. Вам необходимо знать следующее:

• : общедоступное имя хоста Центра управления; это должно быть разрешаемым и доступным для клиентов Kafka.
• : пароль хранилища ключей, указанный при создании SSL-сертификата.
• и : это пароли, которые вы хотите установить для администратора и пользователя клиента соответственно. Обратите внимание, что вы можете добавить больше пользователей, как указано в примереampле.

Отредактируйте или добавьте (с доступом sudo) свойства ниже в /etc/kafka/server.properties, вставив вышеуказанные переменные, как показано:

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

• …
• # Адреса, которые прослушивает брокер Kafka.
• слушатели = PLAINTEXT://локальный: 9092, SASL_SSL://0.0.0.0:9093
• # Это хосты, объявляемые обратно любому подключающемуся клиенту.
• рекламируемые.слушатели=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.протокол = TLSv1.2
• # конфигурация SASL
• sasl.enabled.mechanisms=ОБЫЧНАЯ
• имя пользователя = ”админ” \
• пароль="" \
• user_admin="" \
• user_client="";
• # ПРИМЕЧАНИЕ. Можно добавить больше пользователей с помощью user_=
• # Авторизация, включение ACL
• authorizer.class.name=kafka.security.authorizer.AclAuthorizer super.users=Пользователь:admin

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

Включение ACL на локальном хосте

ПРЕДУПРЕЖДЕНИЕ. Сначала мы должны настроить ACL для локального хоста, чтобы сам Центр управления мог получить доступ к Kafka. Если этого не сделать, вещи сломаются.

• --authorizer kafka.security.authorizer.AclAuthorizer \
• –авторизатор-свойства zookeeper.connect=localhost:2181 \
• –add –allow-principal Пользователь: АНОНИМНЫЙ –allow-host 127.0.0.1 –cluster
• /usr/lib/kafka/bin/kafka-acls.sh \
• --authorizer kafka.security.authorizer.AclAuthorizer \
• –авторизатор-свойства zookeeper.connect=localhost:2181 \
• –add –allow-principal Пользователь: АНОНИМНЫЙ –allow-host 127.0.0.1 –topic ‘*’
• /usr/lib/kafka/bin/kafka-acls.sh \
• --authorizer kafka.security.authorizer.AclAuthorizer \
• –авторизатор-свойства zookeeper.connect=localhost:2181 \
• –add –allow-principal Пользователь: АНОНИМНЫЙ –allow-host 127.0.0.1 –group ‘*’

Затем нам нужно включить ACL для внешнего доступа только для чтения, чтобы внешние пользователи могли читать разделы paa.public.*.

### Записи ACL для анонимных пользователей /usr/lib/kafka/bin/kafka-acls.sh \

ПРИМЕЧАНИЕ: Для более детального контроля обратитесь к официальной документации Kafka.

• --authorizer kafka.security.authorizer.AclAuthorizer \
• –авторизатор-свойства zookeeper.connect=localhost:2181 \
• –add –allow-principal Пользователь:* –operation read –operation описать \ –group 'NCC'
• /usr/lib/kafka/bin/kafka-acls.sh \
• --authorizer kafka.security.authorizer.AclAuthorizer \
• –авторизатор-свойства zookeeper.connect=localhost:2181 \
• –add –allow-principal Пользователь:* –operation read –operation описать \ –topic paa.public. –префикс типа-шаблона-ресурса

После этого вам необходимо перезапустить службы:

### Записи ACL для внешних пользователей /usr/lib/kafka/bin/kafka-acls.sh \

• перезапуск службы sudo ncc

Чтобы убедиться, что клиент может установить безопасное соединение, выполните следующую команду на внешнем
клиентский компьютер (не на сервере Центра управления). Ниже PUBLIC_HOSTNAME — это имя хоста Центра управления:

• openssl s_client -debug -connect ${PUBLIC_HOSTNAME}:9093 -tls1_2 | grep «Secure Renegotiation IS поддерживается»

В выводе команды вы должны увидеть сертификат сервера, а также следующее:

• Поддерживается безопасное повторное согласование IS

Чтобы убедиться, что внутренним службам предоставлен доступ к серверу 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 и установленный там пароль.
Корневой сертификат ЦС, используемый для подписи SSL-сертификата на стороне сервера, должен присутствовать на клиенте.

Создать file client.properties со следующим содержимым:

• Security.protocol=SASL_SSL
• ssl.ca.location={PATH_TO_CA_CERT}
• sasl.mechanisms=ОБЫЧНЫЙ
• sasl.username={КЛИЕНТ_ПОЛЬЗОВАТЕЛЬ}
• sasl.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 для чтения настроек клиента из 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} \
• т ${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) (см. developer.google.com/protocol-buffers). Схемы для этих сообщений придерживаются следующего формата:

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

• синтаксис = «прото3»;
• импортировать «google/protobuf/timestamp.прото”;
• пакет paa.streamingapi;
• option go_package = «.;paa_streamingapi»;
• Метрики сообщения {
• google.protobuf.Timestamp времяamp = 1;
• значения карты = 2;
• int32stream_id = 3;
• }
• /**
• * Значение метрики может быть целым числом или числом с плавающей запятой.
• */
• сообщение MetricValue {
• один из типов {
• int64 int_val = 1;
• поплавок float_val = 2;
• }
• }

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

• синтаксис = «прото3»;
• пакет paa.streamingapi;
• option go_package = «.;paa_streamingapi»;
• Метаданные сообщения {
• int32stream_id = 1;
• строка имя_потока = 2;
• карта tags = 13;
• }

Клиент бывшийampле

ПРИМЕЧАНИЕ: Эти команды предназначены для запуска на внешнем клиенте, напримерample ваш ноутбук или аналогичный, а не в Центре управления.
ПРИМЕЧАНИЕ: Чтобы отображалась информация о метриках, убедитесь, что хотя бы один монитор запущен в Control Center.

В архив Центра управления входит архив paa-streaming-api-client-ex.amples.tar.gz (клиент-бывшийamples), который содержит example Сценарий Python, показывающий, как использовать Streaming API.

Установка и настройка клиента Exampле
Вы находите клиента-бывшегоampфайлы в папке Paragon Active Assurance Control Center:

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

Чтобы установить клиент-exampфайлы на внешнем клиентском компьютере, выполните следующие действия:

• # Создать каталог для извлечения содержимого клиентского exampЛе Тарбол
• mkdir paa-streaming-api-client-exampле
• # Извлечь содержимое клиентского exampЛе Тарбол
• 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.

Использование клиента Exampле
клиент-бывшийamples tools могут работать как в базовом, так и в расширенном режиме для создания exampлесов разной сложности. В обоих случаях также можно запустить exampфайлы с конфигурацией file содержащий дополнительные свойства для дальнейшей настройки клиентской части.

Базовый режим
В базовом режиме метрики и их метаданные передаются отдельно. Для этого клиент прослушивает каждую тему Kafka, доступную для внешнего доступа, и просто выводит полученные сообщения на консоль.
Чтобы начать выполнение основного exampЛес, беги:

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

где ACCOUNT_SHORTNAME — это короткое имя учетной записи, из которой вы хотите получить метрики.
Чтобы прекратить выполнение example, нажмите Ctrl + C. (Может быть небольшая задержка перед остановкой выполнения, поскольку клиент ожидает события тайм-аута.)

Расширенный режим

ПРИМЕЧАНИЕ: метрики отображаются только для HTTP-мониторов, работающих в Центре управления.

Выполнение в расширенном режиме показывает корреляцию между метриками и сообщениями метаданных. Это
возможно благодаря наличию в каждом сообщении метрики поля идентификатора потока, которое ссылается на соответствующее сообщение метаданных.
Чтобы выполнить расширенный exampЛес, беги:

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

где ACCOUNT_SHORTNAME — это короткое имя учетной записи, из которой вы хотите получить метрики.
Чтобы прекратить выполнение example, нажмите Ctrl + C. (Может быть небольшая задержка перед остановкой выполнения, поскольку клиент ожидает события тайм-аута.)

Дополнительные настройки
Можно запустить эксampфайлы с дополнительной настройкой клиента с помощью параметра –config-file вариант, за которым следует file имя, содержащее свойства в форме ключ=значение.

• build.sh расширенный запуск \
• –kafka-brokers локальный хост: 9092 \
• –аккаунт ACCOUNT_SHORTNAME \
• --config-file client_config.properties

ПРИМЕЧАНИЕ: Все files, на которые ссылается приведенная выше команда, должны находиться в текущем каталоге и ссылаться только на относительные пути. Это относится как к –config-file аргумент и ко всем записям в конфигурации file которые описывают file локации.

Проверка подлинности внешнего клиента
Чтобы проверить аутентификацию клиента из-за пределов Центра управления, используя client-examples, выполните следующие действия:

В папке Paragon Active Assurance Control Center переключитесь на файл paa-streaming-api-client-ex.ampпапка с файлами:

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

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

Security.protocol=SASL_SSL ssl.ca.location=ca-cert
sasl.mechanism=ОБЫЧНЫЙ
sasl.username={КЛИЕНТ_ПОЛЬЗОВАТЕЛЬ}
sasl.password={КЛИЕНТ_ПАРОЛЬ}

где {CLIENT_USER} и {CLIENT_PASSWORD} — учетные данные пользователя для клиента.

Выполнить базовый примерampле:

• экспорт KAFKA_FQDN=
• build.sh run-basic –kafka-brokers ${KAFKA_FQDN}:9093 \
• –аккаунт ACCOUNT_SHORTNAME
• --config-file client.properties

где ACCOUNT_SHORTNAME — это короткое имя учетной записи, из которой вы хотите получить метрики.

Запустить расширенный примерampле:

• экспорт KAFKA_FQDN=
• build.sh run-advanced –kafka-brokers ${KAFKA_FQDN}:9093 \
• –аккаунт ACCOUNT_SHORTNAME
• --config-file client.properties

Приложение

В этом приложении мы описываем, как создать:

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

Создание сертификата брокера Kafka
Создание сертификата с использованием реального центра сертификации (рекомендуется)
Рекомендуется получить настоящий SSL-сертификат от доверенного ЦС.
После того, как вы выбрали ЦС, скопируйте его корневой сертификат ЦС ca-cert. file на свой собственный путь, как показано ниже:

• экспортировать CA_PATH=~/my-ca
• мкдир ${CA_PATH}
• cp ca-серт ${CA_PATH}

Создайте свой собственный центр сертификации

ПРИМЕЧАНИЕ: Обычно ваш сертификат должен быть подписан настоящим центром сертификации; см. предыдущий подраздел. Далее следует просто бывшийampле.

Здесь мы создаем собственный корневой сертификат центра сертификации (CA). file действует 999 дней (не рекомендуется в продакшене):

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

Создание хранилища доверенных сертификатов клиента
Теперь вы можете создать доверенный магазин file который содержит сертификат ca, сгенерированный выше. Этот file понадобится клиенту Kafka, который будет обращаться к Streaming API:

• keytool -keystore kafka.client.truststore.jks \
  • псевдоним CARoot \
  • импортсерт -file ${CA_PATH}/ca-сертификат

Теперь, когда сертификат ЦС находится в хранилище доверенных сертификатов, клиент будет доверять любому сертификату, подписанному с ним.
Вам следует скопировать 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
• компакт-диск /var/ssl/частный
• экспортировать полное доменное имя = keytool -keystore kafka.server.keystore.jks \
• — псевдоним сервера \
• — срок действия 999\
• – genkey -keyalg RSA -ext SAN=dns:${FQDN}

Создайте запрос на подпись сертификата и сохраните его в file именованный сервер-сертификат-запрос:

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

Теперь вы должны отправить file cert-server-request в ваш центр сертификации (CA), если вы используете настоящий. Затем они вернут подписанный сертификат. Ниже мы будем называть это подписанным сервером сертификата.

Подписание 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-ключ \
  • – в запросе сертификата-сервера \
  • — вне сертификата, подписанного сервером \
  • – дней 999 -CAcreateserial\
  • – пароль: {ca-пароль}

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

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

• keytool -keystore kafka.server.keystore.jks \
  • — псевдоним ca-cert \
  • - Импортировать \
  • – file ${CA_PATH}/ca-сертификат

Импортируйте подписанный сертификат, называемый cert-server-signed:

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

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

Использование потокового API

В ЭТОМ РАЗДЕЛЕ

• Общие | 20
• Названия тем Кафки | 21
• Exampфайлов использования Streaming API | 21

Общий
API потоковой передачи извлекает как тестовые данные, так и данные мониторинга. Выделить одну из этих категорий невозможно.
API потоковой передачи не извлекает данные из тестов на основе скриптов (представленных прямоугольником, а не фрагментом мозаики в графическом интерфейсе Центра управления), таких как тесты активации службы Ethernet и тесты прозрачности.

Названия тем Кафки
Имена топиков Kafka для потокового API следующие, где %s — это краткое имя учетной записи Центра управления (указывается при создании учетной записи):

• константа (
• Имя экспортера = «Кафка»
• MetadataTopicTpl = «paa.public.accounts.%s.metadata» metricsTopicTpl = «paa.public.accounts.%s.metrics»)

Exampфайлы использования Streaming API
БывшийampСледующие файлы находятся в архиве paa-streaming-api-client-ex.amples.tar.gz, содержащийся в tar-архиве Центра управления.
Во-первых, есть базовый экс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 оставляет за собой право изменять, модифицировать, передавать или иным образом пересматривать эту публикацию без предварительного уведомления. Авторские права © 2023 Juniper Networks, Inc. Все права защищены.

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

Программное обеспечение API потоковой передачи Juniper NETWORKS [pdf] Руководство пользователя Программное обеспечение потокового API, Программное обеспечение API, Программное обеспечение

Ссылки

• Руководство пользователя