Кіраўніцтва па API струменевай перадачы
Апублікавана
2023-07-07
ВЫЗВАЛЕННЕ
4.2
Уводзіны
У гэтым кіраўніцтве апісваецца, як атрымаць даныя з Paragon Active Assurance праз API струменевай перадачы прадукту.
API, а таксама струменевы кліент уключаны ва ўстаноўку Paragon Active Assurance.
Аднак перад выкарыстаннем API патрабуецца невялікая канфігурацыя. Пра гэта распавядаецца ў раздзеле «Наладжванне Streaming API» на старонцы 1.
Налада Streaming API
Скончана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.
- SSL/TLS: SSL - гэта бяспечны пратакол, распрацаваны для бяспечнай адпраўкі інфармацыі праз Інтэрнэт. TLS з'яўляецца пераемнікам SSL, уведзенага ў 1999 годзе.
- SASL: структура, якая забяспечвае механізмы аўтэнтыфікацыі карыстальнікаў, праверкі цэласнасці даных і шыфравання.
- Падпісчык Streaming API: кампанент, які адказвае за атрыманне падзей, якія захоўваюцца ў тэмах, вызначаных у Paragon Active Assurance і прызначаных для знешняга доступу.
- Цэнтр сертыфікацыі: давераная арганізацыя, якая выдае і адклікае сертыфікаты адкрытых ключоў.
- Каранёвы сертыфікат цэнтра сертыфікацыі: сертыфікат адкрытага ключа, які ідэнтыфікуе цэнтр сертыфікацыі.
Як працуе Streaming API
Як згадвалася раней, Streaming API дазваляе знешнім кліентам атрымліваць інфармацыю аб паказчыках з Kafka.
Усе паказчыкі, сабраныя тэставымі агентамі падчас тэставання або задачы маніторынгу, адпраўляюцца ў службу Stream.
Пасля фазы апрацоўкі сэрвіс Stream публікуе гэтыя паказчыкі на Kafka разам з дадатковымі метададзенымі.
Тэмы Кафкі
У Кафкі ёсць канцэпцыя тэм, па якіх публікуюцца ўсе дадзеныя. У Paragon Active Assurance ёсць шмат такіх тэм Кафкі; аднак толькі частка з іх прызначана для вонкавага доступу.
Кожны ўліковы запіс Paragon Active Assurance ў Цэнтры кіравання мае дзве спецыяльныя тэмы. Ніжэй ACCOUNT - кароткая назва ўліковага запісу:
- paa.public.accounts.{ACCOUNT}.metrics
- Усе паведамленні метрык для дадзенага ўліковага запісу публікуюцца ў гэтай тэме
- Вялікі аб'ём дадзеных
- Высокая частата абнаўлення
- paa.public.accounts.{ACCOUNT}.metadata
- Змяшчае метаданыя, звязаныя з дадзенымі метрык, напрыкладample тэст, манітор або тэставы агент, звязаны з паказчыкамі
- Невялікія аб'ёмы даных
- Нізкая частата абнаўлення
Уключэнне Streaming 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
Праверка працы Streaming API у Цэнтры кіравання
УВАГА: Гэтыя інструкцыі павінны выконвацца на серверы Цэнтра кіравання.
Цяпер вы можаце пераканацца, што вы атрымліваеце паказчыкі па правільных тэмах Кафкі. Для гэтага ўсталюйце ўтыліту kafkacat:
sudo apt-get update
sudo apt-get install 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”Кліент Exampлес» на старонцы 14
Гэта пацвярджае, што ў нас ёсць працоўны API Streaming з Цэнтра кіравання. Аднак, хутчэй за ўсё, вы хочаце атрымаць доступ да даных з вонкавага кліента. У наступным раздзеле апісваецца, як адкрыць 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/TLSE
Каб пераканацца, што толькі давераным кліентам дазволены доступ да Kafka і Streaming API, мы павінны наладзіць наступнае:
- Аўтэнтыфікацыя: кліенты павінны ўвесці імя карыстальніка і пароль праз бяспечнае злучэнне SSL/TLS паміж кліентам і Kafka.
- Аўтарызацыя: аўтэнтыфікаваныя кліенты могуць выконваць задачы, якія рэгулююцца ACL.
Вось канецview:
*) Аўтэнтыфікацыя імя карыстальніка/пароля выконваецца на канале, зашыфраваным SSL
Каб цалкам зразумець, як працуе шыфраванне SSL/TLS для Kafka, звярніцеся да афіцыйнай дакументацыі: docs.confluent.io/platform/current/kafka/encryption.html
Скончаны сертыфікат SSL/TLSview
УВАГА: у гэтым падраздзеле мы будзем выкарыстоўваць наступную тэрміналогію:
Сертыфікат: сертыфікат SSL, падпісаны цэнтрам сертыфікацыі (CA). У кожнага брокера Kafka ёсць адзін.
Keystore: сховішча ключоў file які захоўвае сертыфікат. Сховішча ключоў file змяшчае закрыты ключ сертыфіката; таму яго трэба бяспечна захоўваць.
Truststore: А file які змяшчае надзейныя сертыфікаты ЦС.
Каб наладзіць аўтэнтыфікацыю паміж знешнім кліентам і Kafka, якая працуе ў Цэнтры кіравання, абодва бакі павінны мець сховішча ключоў, вызначанае адпаведным сертыфікатам, падпісаным Цэнтрам сертыфікацыі (CA), разам з каранёвым сертыфікатам CA.
У дадатак да гэтага кліент таксама павінен мець даверанае сховішча з каранёвым сертыфікатам ЦС.
Каранёвы сертыфікат CA з'яўляецца агульным для брокера Kafka і кліента Kafka.
Стварэнне неабходных сертыфікатаў
Гэта разглядаецца ў «Дадатку» на старонцы 17.
Kafka Broker Канфігурацыя SSL/TLS у Цэнтры кіравання
ЗАЎВАГА: гэтыя інструкцыі трэба выконваць на серверы Цэнтра кіравання.
УВАГА: Перш чым працягнуць, вы павінны стварыць сховішча ключоў, якое змяшчае сертыфікат SSL, выконваючы інструкцыі ў «Дадатку» на старонцы 17. Шляхі, згаданыя ніжэй, паходзяць з гэтых інструкцый.
Сховішча ключоў SSL - гэта a file захоўваецца на дыску з file пашырэнне .jks.
Калі ў вас будуць даступныя неабходныя сертыфікаты, створаныя як для брокера Kafka, так і для кліента Kafka, вы можаце працягнуць, наладзіўшы брокер Kafka, які працуе ў Цэнтры кіравання. Вы павінны ведаць наступнае:
- : публічнае імя хаста Цэнтра кіравання; гэта павінна быць вырашальным і даступным кліентам Kafka.
- : пароль сховішча ключоў, указаны пры стварэнні сертыфіката SSL.
- і : гэта паролі, якія вы хочаце ўсталяваць для адміністратара і кліента адпаведна. Звярніце ўвагу, што вы можаце дадаць больш карыстальнікаў, як паказана ў прыкладзеampле.
Адрэдагуйце або дадайце (з доступам sudo) уласцівасці ніжэй у /etc/kafka/server.properties, устаўляючы вышэйпаказаныя зменныя, як паказана:
ПАПЯРЭДЖАННЕ: Не выдаляйце PLAINTEXT://localhost:9092; гэта парушыць функцыянальнасць Цэнтра кіравання, бо ўнутраныя службы не змогуць звязвацца.
…
# Адрасы, якія праслухоўвае брокер Kafka.
слухачы=PLAINTEXT://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=ЗВЫЧАЙНЫ
listener.name.sasl_ssl.plain.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginMo
дуле патрабуецца \
імя карыстальніка=”адміністратар” \
пароль=” ” \
user_admin=” ” \
user_client=” ”;
# УВАГА больш карыстальнікаў можна дадаць з user_ =
# Аўтарызацыя, уключыце ACL
authorizer.class.name=kafka.security.authorizer.AclAuthorizer
super.users=Карыстальнік:адмін
Настройка спісаў кантролю доступу (ACL)
Уключэнне ACL на лакальным хасце
ПАПЯРЭДЖАННЕ: Спачатку мы павінны наладзіць ACL для лакальнага хоста, каб сам Цэнтр кіравання ўсё яшчэ мог атрымаць доступ да Kafka. Калі гэтага не рабіць, рэчы ламаюцца.
######### Запісы ACL для ананімных карыстальнікаў
/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 –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.*.
УВАГА: Каб атрымаць больш дакладны кантроль, звярніцеся да афіцыйнай дакументацыі 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 \
–гурт «НКЦ»
/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. –з прэфіксам шаблону рэсурсу
Пасля завяршэння гэтага неабходна перазапусціць службы:
перазапуск паслуг 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, якая была ўсталявана ў раздзеле «Праверка працы Streaming 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={CLIENT_USER}
sasl.password={CLIENT_PASSWORD}
дзе
- {PATH_TO_CA_CERT} - гэта месца каранёвага сертыфіката ЦС, які выкарыстоўваецца брокерам 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} - назва тэмы Кафкі з прэфіксам "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={ПАРОЛЬ_КЛІЕНТА} \
-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 Schema
сінтаксіс = “proto3”;
імпартаваць «google/protobuf/timestamp.прата”;
пакет paa.streamingapi;
option go_package = “.;paa_streamingapi”;
Метрыкі паведамлення {
google.protobuf.Timestamp часamp = 1;
карта значэння = 2;
int32 stream_id = 3;
}
/**
* Метрычнае значэнне можа быць як цэлым лікам, так і лікам з плаваючай часткай.
*/
паведамленне MetricValue {
адзін з тыпаў {
int64 int_val = 1;
паплавок 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 (кліент-эксamples), які змяшчае example скрыпт Python, які паказвае, як карыстацца Streaming API.
Ўстаноўка і налада кліента Exampлес
Вы знаходзіце былога кліентаampфайлы ў тэчцы Paragon Active Assurance Control Center:
экспарт CC_VERSION=4.2.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лес
кліент-эксamples патрабуе 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_SHORTNAME
дзе ACCOUNT_SHORTNAME - кароткая назва ўліковага запісу, з якога вы хочаце атрымаць паказчыкі.
Спыніць выкананне выклample, націсніце Ctrl + C. (Можа быць невялікая затрымка, перш чым выкананне спыніцца, таму што кліент чакае падзеі тайм-аўту.)
Пашыраны рэжым
УВАГА: Метрыкі адлюстроўваюцца толькі для манітораў HTTP, якія працуюць у Цэнтры кіравання.
Выкананне ў пашыраным рэжыме паказвае карэляцыю паміж метрыкамі і паведамленнямі метаданых. Гэта магчыма дзякуючы наяўнасці ў кожным паведамленні метрыкі поля ідэнтыфікатара патоку, якое спасылаецца на адпаведнае паведамленне метададзеных.
Для таго, каб выканаць пашыраны exampлес, запусціце:
./build.sh run-advanced –kafka-brokers localhost:9092 –рахунак ACCOUNT_SHORTNAME
дзе ACCOUNT_SHORTNAME - кароткая назва ўліковага запісу, з якога вы хочаце атрымаць паказчыкі.
Спыніць выкананне выклample, націсніце Ctrl + C. (Можа быць невялікая затрымка, перш чым выкананне спыніцца, таму што кліент чакае падзеі тайм-аўту.)
Дадатковыя налады
Можна запусціць эксampфайлы з дадатковай канфігурацыяй кліента з дапамогай –config-file варыянт, за якім ідзе a file імя, якое змяшчае ўласцівасці ў форме ключ=значэнне.
./build.sh для прасунутага \
–kafka-brokers лакальны хост:9092 \
– уліковы запіс ACCOUNT_SHORTNAME \
-канфігурацыя-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=РАВЫННЫ
sasl.username={CLIENT_USER}
sasl.password={CLIENT_PASSWORD}
дзе {CLIENT_USER} і {CLIENT_PASSWORD} - уліковыя даныя карыстальніка для кліента. - Запусціце базавы exampлес:
экспарт 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-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}
# Стварыце сертыфікат ЦС
openssl req -new -x509 -keyout ${CA_PATH}/ca-key -out ${CA_PATH}/ca-cert -days 999
Стварэнне кліента Truststore
Цяпер вы можаце стварыць даверанае сховішча file які змяшчае ca-cert, створаны вышэй. гэта file спатрэбіцца кліенту Kafka, які будзе атрымліваць доступ да Streaming 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 - поўнае даменнае імя кліента (публічнае імя хаста вузла).
УВАГА: Важна, каб 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 названы сертыфікацыйны-сервер-запыт:
keytool -keystore kafka.server.keystore.jks \
-псеўданім сервера \
-certreq \
-file сертыфікат-сервер-запыт
Цяпер вы павінны адправіць file cert-server-request у ваш цэнтр сертыфікацыі (CA), калі вы выкарыстоўваеце сапраўдны. Затым яны вернуць падпісаны сертыфікат. Ніжэй мы будзем называць гэта подпісам сертыфікаванага сервера.
Падпісанне сертыфіката SSL з выкарыстаннем сертыфіката ЦС, створанага самастойна
УВАГА: Зноў жа, выкарыстанне ўласнага ЦС не рэкамендуецца ў вытворчай сістэме.
Падпішыце сертыфікат з дапамогай CA з дапамогай file cert-server-request, які стварае падпісаны сертыфікат cert-server-signed. Глядзі ніжэй; ca-пароль - гэта пароль, усталяваны пры стварэнні сертыфіката ЦС.
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 \
-дзён 999 -CAcreateserial \
-passin pass: {ca-пароль}
Імпарт падпісанага сертыфіката ў сховішча ключоў
Імпартуйце каранёвы сертыфікат ca-cert у сховішча ключоў:
keytool -keystore kafka.server.keystore.jks \
-псеўданім ca-cert \
-імпарт \
-file ${CA_PATH}/ca-cert
Імпартуйце падпісаны сертыфікат, які называецца сертыфікатам сертыфіката:
keytool -keystore kafka.server.keystore.jks \
-псеўданім сервера \
-імпарт \
-file падпісаны сертыфікатам-серверам
The file kafka.server.keystore.jks трэба скапіяваць у вядомае месца на серверы Цэнтра кіравання, а потым спасылацца на яго ў /etc/kafka/server.properties.
Выкарыстанне Streaming API
Генерал
API струменевай перадачы атрымлівае як тэставыя, так і маніторныя даныя. Вылучыць адну з гэтых катэгорый немагчыма.
API струменевай перадачы не атрымлівае даных з тэстаў на аснове сцэнарыяў (прадстаўленых прамавугольнікам замест фрагмента галаваломкі ў графічным інтэрфейсе Цэнтра кіравання), такіх як тэсты актывацыі службы Ethernet і тэсты празрыстасці.
Імёны тэм Кафкі
Назвы тэм Kafka для струменевага API наступныя, дзе %s - кароткая назва ўліковага запісу Цэнтра кіравання (пазначаецца пры стварэнні ўліковага запісу):
канстанта (
exporterName = “кафка”
metadataTopicTpl = “paa.public.accounts.%s.metadata”
metricsTopicTpl = “paa.public.accounts.%s.metrics”
)
Exampпадрабязнасці па выкарыстанні Streaming API
Былыampнаступныя файлы знаходзяцца ў архіве paa-streaming-api-client-examples.tar.gz змяшчаецца ў архіве Цэнтра кіравання.
Па-першае, ёсць базавы эксample, які дэманструе, як метрыкі і іх метададзеныя перадаюцца асобна, і проста раздрукоўвае атрыманыя паведамленні на кансолі. Вы можаце запусціць яго наступным чынам:
sudo ./build.sh run-basic –kafka-brokers localhost:9092 –рахунак ACCOUNT_SHORTNAME
Ёсць і больш прасунуты эксample, дзе метрыкі і паведамленні метададзеных суадносяцца. Выкарыстоўвайце гэтую каманду, каб запусціць яго:
sudo ./build.sh run-advanced –kafka-brokers localhost:9092 –рахунак 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 Active Assurance [pdfКіраўніцтва карыстальніка Streaming API Active Assurance, API Active Assurance, Active Assurance, Assurance |