Routing Active Testing Streaming API
გზამკვლევი

შესავალი

This guide describes how to extract data from Routing Active Testing via the product’s streaming API.
The API as well as the streaming client are included in the Routing Active Testing installation. However, a bit of configuration is needed before you can use the API. This is covered in the “Configuring the Streaming API” on page 1 chapter.
Streaming API-ს კონფიგურაცია

დასრულდაview

ეს თავი აღწერს, თუ როგორ უნდა დააკონფიგურიროთ Streaming API, რათა მოხდეს მეტრიკის შეტყობინებების გამოწერა კაფკას მეშვეობით.
ქვემოთ განვიხილავთ:

• როგორ ჩართოთ Streaming API
• როგორ დავაკონფიგურიროთ კაფკა გარე კლიენტების მოსასმენად
• როგორ დავაკონფიგურიროთ კაფკა, რომ გამოიყენოს ACL და დააყენოს SSL დაშიფვრა აღნიშნული კლიენტებისთვის

რა არის კაფკა?
კაფკა არის მოვლენის სტრიმინგის პლატფორმა, რომელიც საშუალებას აძლევს რეალურ დროში გადაიღოს სხვადასხვა მოვლენის წყაროდან (სენსორები, მონაცემთა ბაზები, მობილური მოწყობილობები) გაგზავნილი მონაცემები მოვლენის ნაკადების სახით, ასევე ამ მოვლენების ნაკადების გრძელვადიანი შენახვა შემდგომი მოძიებისა და მანიპულირებისთვის.
კაფკასთან ერთად შესაძლებელია ღონისძიების სტრიმინგის თავიდან ბოლომდე მართვა განაწილებული, ძალიან მასშტაბირებადი, ელასტიური, ხარვეზებისადმი ტოლერანტული და უსაფრთხო გზით.
შენიშვნა: Kafka can be configured in many different ways and was designed for scalability and redundant systems. This document focuses only on how to configure it to make use of the Streaming API feature found in Routing Active Testing Control Center. For more advanced setups we refer to the official Kafka documentation: kafka.apache.org/26/documentation.html.
ტერმინოლოგია

• კაფკა: ღონისძიების სტრიმინგის პლატფორმა.
• კაფკას თემა: მოვლენათა კრებული.
• კაფკას აბონენტი/მომხმარებელი: კომპონენტი, რომელიც პასუხისმგებელია კაფკას თემაში შენახული მოვლენების მოძიებაზე.
• კაფკას ბროკერი: კაფკას კლასტერის შენახვის ფენის სერვერი.
• SSL/TLS: SSL არის უსაფრთხო პროტოკოლი, რომელიც შემუშავებულია ინფორმაციის უსაფრთხოდ გასაგზავნად ინტერნეტით. TLS არის SSL-ის მემკვიდრე, რომელიც დაინერგა 1999 წელს.
• SASL: ჩარჩო, რომელიც უზრუნველყოფს მომხმარებლის ავთენტიფიკაციის, მონაცემთა მთლიანობის შემოწმების და დაშიფვრის მექანიზმებს.
• Streaming API subscriber: Component responsible for retrieval of events stored in topics defined in Routing Active Testing and meant for external access.
• სერტიფიკატის ავტორიტეტი: სანდო სუბიექტი, რომელიც გასცემს და აუქმებს საჯარო გასაღების სერტიფიკატებს.
• სერტიფიკატის ავტორიტეტის ძირეული სერტიფიკატი: საჯარო გასაღების სერტიფიკატი, რომელიც განსაზღვრავს სერტიფიკატის ორგანოს.

როგორ მუშაობს Streaming API
როგორც უკვე აღვნიშნეთ, Streaming API საშუალებას აძლევს გარე კლიენტებს მიიღონ ინფორმაცია მეტრიკის შესახებ კაფკადან.
ტესტის აგენტების მიერ ტესტირების ან მონიტორინგის დავალების დროს შეგროვებული ყველა მეტრიკა იგზავნება Stream სერვისში.
დამუშავების ფაზის შემდეგ, Stream სერვისი აქვეყნებს ამ მაჩვენებლებს კაფკაზე დამატებით მეტამონაცემებთან ერთად.
კაფკას თემები
Kafka has the concept of topics to which all data is published. In Routing Active Testing there are many such Kafka topics available; however, only a subset of these are meant for external access.
Each Routing Active Testing account in Control Center has two dedicated topics. Below, ACCOUNT is the account short name:

• paa.public.accounts.{ACCOUNT}.metrics
• ყველა მეტრიკის შეტყობინება მოცემული ანგარიშისთვის გამოქვეყნებულია ამ თემაზე
• დიდი რაოდენობით მონაცემები
• განახლების მაღალი სიხშირე
• paa.public.accounts.{ACCOUNT}.მეტამონაცემები
• შეიცავს მეტამონაცემებს, რომლებიც დაკავშირებულია მეტრიკის მონაცემებთან, მაგampმეტრიკასთან დაკავშირებული ტესტი, მონიტორი ან ტესტის აგენტი
• მცირე რაოდენობით მონაცემები
• განახლების დაბალი სიხშირე

Streaming API-ის ჩართვა
შენიშვნა: These instructions are to be run on the Control Center server using sudor.
მას შემდეგ, რაც Streaming API ამატებს გარკვეულ ზედნადებს საკონტროლო ცენტრს, ის არ არის ჩართული ნაგულისხმევად. API-ს ჩასართავად, ჯერ უნდა გავააქტიუროთ მეტრიკის გამოქვეყნება კაფკაზე მთავარ კონფიგურაციაში. file:

• /etc/netrounds/netrounds.conf

KAFKA_METRICS_ENABLED = მართალია
KAFKA_PUBLISH_METADATA_FOR_STREAMS = True

გაფრთხილება: ამ ფუნქციის ჩართვამ შესაძლოა გავლენა მოახდინოს საკონტროლო ცენტრის მუშაობაზე. დარწმუნდით, რომ თქვენი ინსტანციის განზომილება შესაბამისად გაქვთ.
შემდეგი, ამ მეტრიკის გადაგზავნა კაფკას სწორ თემებზე:

• /etc/netrounds/metrics.yaml

ნაკადი-api: მართალია
Streaming API სერვისების ჩასართავად და დასაწყებად, გაუშვით:

• sudo ncc სერვისები რთავს timescaledb მეტრიკას
• sudo ncc სერვისები იწყება timescaledb მეტრიკა

და ბოლოს, გადატვირთეთ სერვისები:

• sudo ncc სერვისების გადატვირთვა

შენიშვნა: The KAFKA_PUBLISH_RESOURCES setting has been deprecated. It should be removed from your configuration. Use KAFKA_PUBLISH_METADATA_FOR_STREAMS = True instead.
დადასტურება, რომ Streaming API მუშაობს საკონტროლო ცენტრში
შენიშვნა: ეს ინსტრუქციები უნდა იყოს გაშვებული საკონტროლო ცენტრის სერვერზე.
You can now verify that you are receiving metrics on the correct Kafka topics. To do so, install the Kafka cat utility:

• sudo apt-get განახლება
• sudo apt-get install kafkacat

If you have a test or monitor running in Control Center, you should be able to use Kafka cat to receive metrics and metadata on these topics.
შეცვალეთ 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

შენიშვნა: This is just a sanity check to make sure things are being published correctly. The data you see being published will be in binary form, which kafkacat will not decode by default. For properly subscribing to these topics, please see the “Client Examples” on page 13 section.
ეს ადასტურებს, რომ ჩვენ გვაქვს მოქმედი Streaming API საკონტროლო ცენტრიდან. თუმცა, სავარაუდოდ, თქვენ დაინტერესებული ხართ გარე კლიენტის მონაცემებზე წვდომით. შემდეგი განყოფილება აღწერს, თუ როგორ უნდა გახსნათ კაფკა გარე წვდომისთვის.
კაფკას გახსნა გარე მასპინძლებისთვის
შენიშვნა: ეს ინსტრუქციები უნდა იყოს გაშვებული საკონტროლო ცენტრის სერვერზე.
ნაგულისხმევად, საკონტროლო ცენტრში გაშვებული კაფკა არის კონფიგურირებული, რომ მოუსმინოს მხოლოდ ლოკალჰოსტს შიდა გამოყენებისთვის.
შესაძლებელია კაფკას გახსნა გარე კლიენტებისთვის კაფკას პარამეტრების შეცვლით.
კაფკასთან დაკავშირება: გაფრთხილებები
სიფრთხილე: გთხოვთ, ყურადღებით წაიკითხოთ ეს, რადგან ადვილია კაფკასთან კავშირთან დაკავშირებული საკითხების გაჩენა, თუ ეს ცნებები არ გესმით.
ამ დოკუმენტში აღწერილი საკონტროლო ცენტრის კონფიგურაციაში არის მხოლოდ ერთი კაფკას ბროკერი.
თუმცა, გაითვალისწინეთ, რომ კაფკას ბროკერი გამიზნულია იმუშაოს როგორც კაფკას კლასტერის ნაწილი, რომელიც შეიძლება შედგებოდეს მრავალი კაფკას ბროკერისგან.
კაფკას ბროკერთან დაკავშირებისას, საწყისი კავშირი იქმნება კაფკას კლიენტის მიერ. ამასთან დაკავშირებით, კაფკას ბროკერი თავის მხრივ დააბრუნებს „რეკლამირებული მსმენელთა“ სიას, რომელიც არის ერთი ან რამდენიმე კაფკას ბროკერის სია.
ამ სიის მიღებისას კაფკას კლიენტი გათიშავს და შემდეგ ხელახლა დაუკავშირდება ამ რეკლამირებულ მსმენელს. რეკლამირებული მსმენელები უნდა შეიცავდეს ჰოსტის სახელებს ან IP მისამართებს, რომლებიც ხელმისაწვდომია კაფკას კლიენტისთვის, წინააღმდეგ შემთხვევაში კლიენტი ვერ დაუკავშირდება.
თუ გამოიყენება SSL დაშიფვრა, რომელიც მოიცავს SSL სერთიფიკატს, რომელიც დაკავშირებულია კონკრეტულ ჰოსტის სახელთან, კიდევ უფრო მნიშვნელოვანია, რომ კაფკას კლიენტმა მიიღოს სწორი მისამართი დასაკავშირებლად, რადგან წინააღმდეგ შემთხვევაში კავშირი შეიძლება უარყოფილი იყოს.
წაიკითხეთ მეტი კაფკას მსმენელების შესახებ აქ: www.confluent.io/blog/kafka-listeners-explained
SSL/TLS დაშიფვრა
იმისათვის, რომ დავრწმუნდეთ, რომ მხოლოდ სანდო კლიენტებს აქვთ წვდომა Kafka-სა და Streaming API-ზე, ჩვენ უნდა დავაკონფიგურიროთ შემდეგი:

• ავტორიზაცია: კლიენტებმა უნდა მიაწოდონ მომხმარებლის სახელი და პაროლი SSL/TLS უსაფრთხო კავშირის საშუალებით კლიენტსა და კაფკას შორის.
• ავტორიზაცია: ავთენტიფიცირებულ კლიენტებს შეუძლიათ შეასრულონ ამოცანები, რომლებიც რეგულირდება ACL-ებით.

აქ არის დასრულდაview:
იმის გასაგებად, თუ როგორ მუშაობს SSL/TLS დაშიფვრა კაფკასთვის, გთხოვთ, გაეცნოთ ოფიციალურ დოკუმენტაციას: docs.confluent.io/platform/current/kafka/encryption.html
SSL/TLS სერთიფიკატი დასრულდაview
შენიშვნა: ამ ქვეგანყოფილებაში ჩვენ გამოვიყენებთ შემდეგ ტერმინოლოგიას:
სერთიფიკატი: SSL სერთიფიკატი, რომელსაც ხელს აწერს სერტიფიკატის ორგანო (CA). კაფკას თითოეულ ბროკერს ჰყავს ერთი.
Keystore: გასაღების მაღაზია file რომელიც ინახავს სერთიფიკატს. გასაღებების მაღაზია file შეიცავს სერტიფიკატის პირად გასაღებს; ამიტომ საჭიროა მისი უსაფრთხოდ შენახვა.
Truststore: ა file შეიცავს სანდო CA სერთიფიკატებს.
კონტროლის ცენტრში გაშვებულ გარე კლიენტსა და კაფკას შორის ავტორიზაციის დასაყენებლად, ორივე მხარეს უნდა ჰქონდეს გასაღების საცავი განსაზღვრული შესაბამისი სერტიფიკატით, რომელსაც ხელს აწერს სერტიფიკატის ორგანო (CA) CA root სერთიფიკატთან ერთად.
გარდა ამისა, კლიენტს ასევე უნდა ჰქონდეს Truststore CA root სერთიფიკატით.
CA root სერთიფიკატი საერთოა კაფკას ბროკერისთვის და კაფკას კლიენტისთვის.
საჭირო სერთიფიკატების შექმნა
ეს მოცემულია „დანართში“ მე-16 გვერდზე.
კაფკა ბროკერის SSL/TLS კონფიგურაცია საკონტროლო ცენტრში
შენიშვნა: ეს ინსტრუქციები უნდა იყოს გაშვებული საკონტროლო ცენტრის სერვერზე.
შენიშვნა: Before continuing, you must create the keystone which contains the SSL certificate by following the instructions in the “Appendix” on page 16. The paths mentioned below come from these instructions. The SSL keystore is a file ინახება დისკზე ერთად file გაფართოება .jks.
მას შემდეგ რაც თქვენ გექნებათ საჭირო სერთიფიკატები შექმნილი როგორც კაფკას ბროკერისთვის, ასევე კაფკას კლიენტისთვის, შეგიძლიათ გააგრძელოთ საკონტროლო ცენტრში გაშვებული კაფკას ბროკერის კონფიგურაცია. თქვენ უნდა იცოდეთ შემდეგი:

• : საკონტროლო ცენტრის საჯარო ჰოსტის სახელი; ეს უნდა იყოს მოგვარებადი და ხელმისაწვდომი კაფკას კლიენტებისთვის.
• : გასაღების მაღაზიის პაროლი, რომელიც მითითებულია SSL სერთიფიკატის შექმნისას.
• და : ეს არის პაროლები, რომლებიც გსურთ დააყენოთ ადმინისტრატორისა და კლიენტის მომხმარებლისთვის, შესაბამისად. გაითვალისწინეთ, რომ თქვენ შეგიძლიათ დაამატოთ მეტი მომხმარებელი, როგორც ეს მითითებულია ყოფილშიampლე.

Edit or append (with sudo access) the properties below in /etc/kafka/server.properties, inserting the above
variables as shown:
გაფრთხილება: არ წაშალოთ PLAINTEXT://localhost:9092; ეს დაარღვევს საკონტროლო ცენტრის ფუნქციონირებას, რადგან შიდა სერვისები ვერ შეძლებენ კომუნიკაციას.
…
# მისამართები, რომლებსაც კაფკას ბროკერი უსმენს.
მსმენელები=PLAINTEXT://localhost:9092,SASL_SSL://0.0.0.0:9093
# ეს არის მასპინძლები, რომლებიც რეკლამირებულია ნებისმიერ კლიენტთან, რომელიც აკავშირებს.
advertised.listeners=PLAINTEXT://localhost:9092,SASL_SSL:// :9093
… ####### CUSTOM CONFIG
# SSL კონფიგურაცია
ssl.endpoint.identification.algorithm=
ssl.keystore.location=/var/ssl/private/kafka.server.keystore.jks
ssl.keystore.password=
ssl.key.password=
ssl.client.auth=none
ssl.protocol=TLSv1.2
# SASL კონფიგურაცია
sasl.enabled.mechanisms=PLAIN
listener.name.sasl_ssl.plain.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginMo
დულე საჭიროა \
მომხმარებლის სახელი=”ადმინ” \
პაროლი =” ” \
User:admin=”<admin_pwd>” \
user client=”<client_pwd>”;
# შენიშვნა მომხმარებლის_თან შეიძლება დაემატოს მეტი მომხმარებელი =
# ავტორიზაცია, ჩართეთ ACL
autorizer.class.name=kafka.security.authorizer.AclAuthorizer
superusers=User:admin
წვდომის კონტროლის სიების (ACL) დაყენება
ACL-ების ჩართვა ლოკალჰოსტზე
  გაფრთხილება: ჩვენ ჯერ უნდა დავაყენოთ ACL ლოკალური ჰოსტისთვის, რათა თავად საკონტროლო ცენტრმა მაინც შეძლოს კაფკაზე წვდომა. თუ ეს არ გაკეთდა, ყველაფერი იშლება.
######### ACL-ის ჩანაწერები ანონიმური მომხმარებლებისთვის
/usr/lib/kafka/bin/kafka-acls.sh \
–ავტორიზატორი kafka.security.authorizer.AclAuthorizer \
–autorizer-properties zookeeper.connect=localhost:2181 \
–add –allow-principal User: ANONYMOUS –allow-host 127.0.0.1 –cluster
/usr/lib/kafka/bin/kafka-acls.sh \
–ავტორიზატორი kafka.security.authorizer.AclAuthorizer \
–autorizer-properties zookeeper.connect=localhost:2181 \
–add –allow-ძირითადი მომხმარებელი:ANONYMOUS –allow-host 127.0.0.1 –თემა '*'
/usr/lib/kafka/bin/kafka-acls.sh \
–ავტორიზატორი kafka.security.authorizer.AclAuthorizer \
–autorizer-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.security.authorizer.AclAuthorizer \
–autorizer-properties zookeeper.connect=localhost:2181 \
–დამატება –დაშვება–ძირითადი მომხმარებელი:* –ოპერაცია წაკითხვა –ოპერაცია აღწერა \
- ჯგუფი "NCC"
/usr/lib/kafka/bin/kafka-acls.sh \
–ავტორიზატორი kafka.security.authorizer.AclAuthorizer \
–autorizer-properties zookeeper.connect=localhost:2181 \
–დამატება –დაშვება–ძირითადი მომხმარებელი:* –ოპერაცია წაკითხვა –ოპერაცია აღწერა \
–თემა პაა.საჯარო. -რესურსების-თარგის ტიპის პრეფიქსი
ამის დასრულების შემდეგ, თქვენ უნდა გადატვირთოთ სერვისები:
sudo ncc სერვისების გადატვირთვა
იმის დასადასტურებლად, რომ კლიენტს შეუძლია უსაფრთხო კავშირის დამყარება, გაუშვით შემდეგი ბრძანება გარე კლიენტის კომპიუტერზე (არა საკონტროლო ცენტრის სერვერზე). ქვემოთ, PUBLIC_HOSTNAME არის საკონტროლო ცენტრის ჰოსტის სახელი:
openssl s_client -debug -დაკავშირება ${PUBLIC_HOSTNAME}:9093 -tls1_2 | grep "უსაფრთხო ხელახალი მოლაპარაკება მხარდაჭერილია"
ბრძანების გამომავალში თქვენ უნდა ნახოთ სერვერის სერთიფიკატი, ასევე შემდეგი:
უსაფრთხო ხელახალი მოლაპარაკება არის მხარდაჭერილი
იმის უზრუნველსაყოფად, რომ შიდა სერვისებს მიენიჭათ წვდომა კაფკას სერვერზე, გთხოვთ, შეამოწმოთ შემდეგი ჟურნალიfiles:

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

გარე კლიენტებთან კავშირის დადასტურება
კაფკაკატი
შენიშვნა: ეს ინსტრუქციები უნდა იყოს გაშვებული კლიენტის კომპიუტერზე (არა საკონტროლო ცენტრის სერვერზე).
შენიშვნა: მეტრიკის ინფორმაციის საჩვენებლად, დარწმუნდით, რომ მინიმუმ ერთი მონიტორი მუშაობს საკონტროლო ცენტრში.
კავშირის, როგორც გარე კლიენტის შესამოწმებლად და დასადასტურებლად, შესაძლებელია გამოიყენოთ kafkacat პროგრამა, რომელიც დაინსტალირებული იყო განყოფილებაში „გადამოწმება, რომ Streaming API მუშაობს საკონტროლო ცენტრში“ მე-4 გვერდზე.
შეასრულეთ შემდეგი ნაბიჯები:
შენიშვნა: ქვემოთ, CLIENT_USER არის ადრე მითითებული მომხმარებელი file /etc/kafka/ server.properties in Control Center: namely, user_client and the password set there. The CA root certificate used to sign the server side SSL certificate must be present on the client.
შექმენით ა file კლიენტი.თვისებები შემდეგი შინაარსით:
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} არის CA root სერტიფიკატის მდებარეობა, რომელსაც იყენებს კაფკა ბროკერი
• {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=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
დარწმუნდით, რომ მიმართეთ დოკუმენტაციას გამოყენებული კაფკას კლიენტის ბიბლიოთეკისთვის, რადგან თვისებები შეიძლება განსხვავდებოდეს client.properties-ში.
შეტყობინების ფორმატი
The messages used for the metrics and metadata topics are serialized in the Protocol buffers (protobuf)format (see developers.google.com/protocol-buffers). ამ შეტყობინებების სქემები შეესაბამება შემდეგ ფორმატს:
Metrics Protobuf სქემა
სინტაქსი = “proto3”;
იმპორტი „google/protobuf/timestamp.პროტო”;
პაკეტი paa.streamingapi;
ვარიანტი go_package = „.;paa_streamingapi“;
შეტყობინების მეტრიკა {
google.protobuf.Timestamp დროისamp = 1;
რუკა მნიშვნელობები = 2;
int32 stream_id = 3;
}
/**
* მეტრიკული მნიშვნელობა შეიძლება იყოს მთელი რიცხვი ან float.
*/
შეტყობინება MetricValue {
ერთი ტიპის {
int64 int_val = 1;
float float_val = 2;
}
}
მეტამონაცემების Protobuf სქემა
სინტაქსი = “proto3”;
პაკეტი paa.streamingapi;
ვარიანტი go_package = „.;paa_streamingapi“;
შეტყობინების მეტამონაცემები {
int32 stream_id = 1;
სიმებიანი ნაკადის_სახელი = 2;
რუკა tags = 13;
}
კლიენტი ეგamples
შენიშვნა: ეს ბრძანებები გამიზნულია გარე კლიენტზე გასაშვებად, მაგampთქვენი ლეპტოპი ან მსგავსი, და არა საკონტროლო ცენტრში.
შენიშვნა: მეტრიკის ინფორმაციის ჩვენებისთვის, დარწმუნდით, რომ მინიმუმ ერთი მონიტორი მუშაობს საკონტროლო ცენტრში.
საკონტროლო ცენტრის tarball მოიცავს არქივს paa-streaming-api-client-examples.tar.gz (კლიენტი-ექსamples), რომელიც შეიცავს ყოფილიample Python სკრიპტი, რომელიც აჩვენებს, თუ როგორ გამოიყენოთ Streaming API.
კლიენტის ინსტალაცია და კონფიგურაცია Examples
თქვენ იპოვით კლიენტ-ყოფილსamples in the Routing Active Testing Control Center folder:
ექსპორტი CC_VERSION=4.6.0
cd ./paa-control-center_${CC_VERSION}
ls paa-streaming-api-client-examples*
კლიენტის ყოფილი ინსტალაციისთვისampთქვენს გარე კლიენტ კომპიუტერზე, გააგრძელეთ შემდეგნაირად:
# შექმენით დირექტორია კლიენტის შინაარსის ამოსაღებადamples tarball
mkdir paa-streaming-api-client-examples
# ამოიღეთ კლიენტის შინაარსი examples tarball
tar xzf paa-streaming-api-client-examples.tar.gz -C paa-streaming-api-client-examples
# გადადით ახლად შექმნილ დირექტორიაში
cd paa-streaming-api-client-examples
კლიენტი-ყოფილიamples მოითხოვს Docker-ის გასაშვებად. Docker-ის ჩამოტვირთვების და ინსტალაციის ინსტრუქციები შეგიძლიათ იხილოთ აქ https://docs.docker.com/engine/install.
კლიენტის გამოყენება Examples
კლიენტი-ყოფილიamples ინსტრუმენტებს შეუძლიათ იმუშაონ როგორც საბაზისო, ისე გაფართოებულ რეჟიმში ყოფილი ასაშენებლადampსხვადასხვა სირთულის. ორივე შემთხვევაში შესაძლებელია ყოფილის გაშვებაცamples კონფიგურაციით file შეიცავს დამატებით თვისებებს კლიენტის მხარის შემდგომი პერსონალიზაციისთვის.
ძირითადი რეჟიმი
საბაზისო რეჟიმში, მეტრიკა და მათი მეტამონაცემები ცალ-ცალკე გადაიცემა. ამ მიზნით, კლიენტი უსმენს კაფკას თითოეულ თემას, რომელიც ხელმისაწვდომია გარე წვდომისთვის და უბრალოდ ბეჭდავს მიღებულ შეტყობინებებს კონსოლში.
ძირითადი ყოფილი აღსრულების დასაწყებადamples, გაუშვით:
./build.sh run-basic –kafka-brokers localhost:9092 –ანგარიში ACCOUNT_SHORTNAME
სადაც ACCOUNT_SHORTNAME არის ანგარიშის მოკლე სახელი, საიდანაც გსურთ მიიღოთ მეტრიკა.
შეწყვიტოს აღსრულება ყოფილიample, დააჭირეთ Ctrl + C. (შეიძლება იყოს მცირე შეფერხება შესრულების შეწყვეტამდე, რადგან კლიენტი ელოდება დროის ამოწურვის მოვლენას.)
გაფართოებული რეჟიმი
შენიშვნა: მეტრიკა ნაჩვენებია მხოლოდ საკონტროლო ცენტრში გაშვებული HTTP მონიტორებისთვის.
გაფართოებულ რეჟიმში შესრულება აჩვენებს მეტრიკასა და მეტამონაცემების შეტყობინებებს შორის კორელაციას. ეს შესაძლებელია თითოეულ მეტრულ შეტყობინებაში ნაკადის id ველის არსებობის წყალობით, რომელიც ეხება შესაბამის მეტამონაცემების შეტყობინებას.
შეასრულოს მოწინავე ყოფილიamples, გაუშვით:
./build.sh run-advanced –kafka-brokers localhost:9092 –ანგარიში ACCOUNT_SHORTNAME
სადაც ACCOUNT_SHORTNAME არის ანგარიშის მოკლე სახელი, საიდანაც გსურთ მიიღოთ მეტრიკა.
შეწყვიტოს აღსრულება ყოფილიample, დააჭირეთ Ctrl + C. (შეიძლება იყოს მცირე შეფერხება შესრულების შეწყვეტამდე, რადგან კლიენტი ელოდება დროის ამოწურვის მოვლენას.)
დამატებითი პარამეტრები
შესაძლებელია ყოფილი გაშვებაamples კლიენტის დამატებითი კონფიგურაციით –config--ის გამოყენებითfile ვარიანტი მოჰყვება ა file სახელი, რომელიც შეიცავს თვისებებს ფორმაში key=value.
./build.sh run-advanced \
–kafka-brokers localhost:9092 \
-ანგარიში ACCOUNT_SHORTNAME \
-კონფიგურაცია-file client_config.properties
შენიშვნა: ყველა fileზემოთ მოცემულ ბრძანებაში მითითებული s უნდა იყოს განთავსებული მიმდინარე დირექტორიაში და მითითებული იყოს მხოლოდ შედარებითი ბილიკების გამოყენებით. ეს ეხება როგორც –config--სfile არგუმენტი და ყველა ჩანაწერი კონფიგურაციაში file რომ აღწერს file ლოკაციები.
გარე კლიენტის ავთენტიფიკაციის დადასტურება
კლიენტის ავთენტიფიკაციის დასადასტურებლად საკონტროლო ცენტრის გარედან კლიენტ-ექსის გამოყენებითamples, შეასრულეთ შემდეგი ნაბიჯები:

• From the Routing Active Testing Control Center folder, switch to the paa-streaming-api-client-examples საქაღალდე:
  cd paa-streaming-api-client-examples
• დააკოპირეთ CA root სერტიფიკატის ca-cert მიმდინარე დირექტორიაში.
• შექმენით კლიენტი.თვისებები file შემდეგი შინაარსით:
  security.protocol=SASL_SSL
  ssl.ca.location=ca-cert
  სასლ.მექანიზმი=სადა
  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 კლიენტი.თვისებები
  სადაც ACCOUNT_SHORTNAME არის ანგარიშის მოკლე სახელი, საიდანაც გსურთ მიიღოთ მეტრიკა.
• გაუშვით მოწინავე ყოფილიamples:
  ექსპორტი KAFKA_FQDN=
  ./build.sh run-advanced –kafka-brokers ${KAFKA_FQDN}:9093 \
  -ანგარიში ACCOUNT_SHORTNAME
  -კონფიგურაცია-file კლიენტი.თვისებები

დანართი

ამ დანართში ჩვენ აღწერს როგორ შევქმნათ:

• გასაღების მაღაზია file კაფკას ბროკერის SSL სერთიფიკატის შესანახად
• ნდობის მაღაზია file სასერთიფიკატო ორგანოს (CA) ძირეული სერტიფიკატის შესანახად, რომელიც გამოიყენება კაფკას ბროკერის სერტიფიკატზე ხელმოწერისთვის.

კაფკას ბროკერის სერთიფიკატის შექმნა
სერტიფიკატის შექმნა რეალური სერტიფიკატის ავტორიტეტის გამოყენებით (რეკომენდირებულია)
რეკომენდირებულია მიიღოთ რეალური SSL სერთიფიკატი სანდო CA-სგან.
მას შემდეგ რაც გადაწყვეტთ CA-ს შესახებ, დააკოპირეთ მათი CA root სერტიფიკატის ca-cert file საკუთარ გზაზე, როგორც ნაჩვენებია ქვემოთ:
ექსპორტი CA_PATH=~/my-ca
mkdir ${CA_PATH}
cp ca-cert ${CA_PATH}
შექმენით თქვენი საკუთარი სერტიფიკატის ავტორიტეტი
შენიშვნა: ჩვეულებრივ, თქვენ უნდა გქონდეთ თქვენი სერტიფიკატი ხელმოწერილი რეალური სერტიფიკატის ორგანოს მიერ; იხილეთ წინა ქვეპუნქტი. რაც მოყვება არის მხოლოდ ყოფილიampლე.
აქ ჩვენ ვქმნით ჩვენს საკუთარ სერტიფიკატის ორგანოს (CA) ძირეულ სერტიფიკატს file მოქმედებს 999 დღის განმავლობაში (წარმოებაში არ არის რეკომენდებული):
# შექმენით დირექტორია CA-ს შესანახად
ექსპორტი CA_PATH=~/my-ca
mkdir ${CA_PATH}
# შექმენით CA სერთიფიკატი
openssl req -new -x509 -keyout ${CA_PATH}/ca-key -out ${CA_PATH}/ca-cert -days 999
კლიენტების Truststore-ის შექმნა
ახლა თქვენ შეგიძლიათ შექმნათ ნდობის მაღაზია file რომელიც შეიცავს ზემოთ გენერირებულ ca-სერთიფიკატს. ეს file will be needed by the Kafka client that will access the Streaming API: keytool -keystore kafka.client.truststore.jks \
-ასევე CARoot \
-იმპორტისტი -file ${CA_PATH}/ca-cert
ახლა, როდესაც CA სერთიფიკატი არის truststore-ში, კლიენტი ენდობა მასთან ხელმოწერილ ნებისმიერ სერტიფიკატს.
თქვენ უნდა დააკოპიროთ file kafka.client.truststore.jks თქვენს კლიენტის კომპიუტერის ცნობილ ადგილას და მიუთითეთ მასზე პარამეტრებში.
Keystore-ის შექმნა კაფკას ბროკერისთვის
Kafka ბროკერის SSL სერთიფიკატის და შემდეგ keystore kafka.server.keystore.jks-ის გენერირებისთვის, გააკეთეთ შემდეგი:
SSL სერთიფიკატის გენერირება
Use these commands to generate the SSL certificate. Below, 999 is the number of days of validity of the keystore.
sudo mkdir -p /var/ssl/private
sudo chown -R $USER: /var/ssl/პირადი
cd /var/ssl/private
export CC_IP=<Control Center IP>
keytool -keystore kafka.server.keystore.jks \
-ასევე სერვერი \
-მოქმედების ვადა 999 \
-genkey -keyalg RSA -ext SAN=ip:${CC_IP}
To verify the SSL certificate, you can use the following command:
keytool -v -list -keystore kafka.server.keystore.jks -alias server
You should ensure that the port 9093 is accessible from external clients.
შექმენით სერტიფიკატის ხელმოწერის მოთხოვნა და შეინახეთ მასში file დასახელებული cert-server-მოთხოვნა:
keytool -keystore kafka.server.keystore.jks \
-ასევე სერვერი \
-certreq \
-file სერთიფიკატი-სერვერი-მოთხოვნა
ახლა თქვენ უნდა გამოაგზავნოთ file cert-server-მოთხოვნა თქვენი სერტიფიკატის ორგანოს (CA), თუ იყენებთ რეალურს. შემდეგ ისინი დააბრუნებენ ხელმოწერილ სერთიფიკატს. ამას ქვემოთ მოვიხსენიებთ, როგორც სერტიფიკატის სერვერზე ხელმოწერილი.
SSL სერთიფიკატზე ხელმოწერა თვითშექმნილი CA სერთიფიკატის გამოყენებით
შენიშვნა: ისევ და ისევ, საკუთარი CA-ს გამოყენება არ არის რეკომენდებული წარმოების სისტემაში.
ხელი მოაწერეთ სერთიფიკატს CA-ს საშუალებით file cert-server-request, რომელიც აწარმოებს ხელმოწერილ სერთიფიკატს cert-server-signed. Იხილეთ ქვემოთ; ca-password არის პაროლი დაყენებული CA სერთიფიკატის შექმნისას.
cd /var/ssl/private
openssl x509 -req \

• -CA ${CA_PATH}/ca-cert \
• -CAkey ${CA_PATH}/ca-key \
• -სერთიფიკატის სერვერის მოთხოვნა \
• -გამოვიდა სერთიფიკატი სერვერზე ხელმოწერილი \
• -days 999 -CAcreateserial \
• -passin pass:{ca-password}

ხელმოწერილი სერთიფიკატის იმპორტი Keystore-ში
Ca-cert root სერთიფიკატის იმპორტი გასაღების მაღაზიაში:
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 არ იღებს მონაცემებს სკრიპტზე დაფუძნებული ტესტებიდან (ისინი, რომლებიც წარმოდგენილია მართკუთხედით საკონტროლო ცენტრის GUI-ში სტრიმინგის ნაცვლად), როგორიცაა Ethernet სერვისის აქტივაციის ტესტები და გამჭვირვალობის ტესტები.

კაფკას თემების სახელები

კაფკას თემების სახელები ნაკადის API-სთვის შემდეგია, სადაც %s არის საკონტროლო ცენტრის ანგარიშის მოკლე სახელი (მითითებულია ანგარიშის შექმნისას):
კონსტი (
exporterName = „კაფკა“
metadataTopicTpl = "paa.public.accounts.%s.metadata"
metricsTopicTpl = "paa.public.accounts.%s.metrics"
)
Exampსტრიმინგის API-ს გამოყენება
ყოფილმაampქვემოთ მოყვანილი ინფორმაცია გვხვდება tarball paa-streaming-api-client-ex-შიamples.tar.gz შეიცავს საკონტროლო ცენტრის tarball-ში.
პირველი, არსებობს ძირითადი ყოფილიampაჩვენეთ, თუ როგორ ხდება მეტრიკა და მათი მეტამონაცემების სტრიმინგი ცალკე და უბრალოდ დაბეჭდეთ მიღებული შეტყობინებები კონსოლში. მისი გაშვება შეგიძლიათ შემდეგნაირად:
sudo ./build.sh run-basic –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME There is also a more advanced exampსადაც მეტრიკა და მეტამონაცემების შეტყობინებები კორელაციაშია. გამოიყენეთ ეს ბრძანება მის გასაშვებად:
sudo ./build.sh run-advanced –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME You need to use sudo to run Docker commands such as the ones above. Optionally, you can follow the Linux post-installation steps to be able to run Docker commands without sudo. For details, go to docs.docker.com/engine/install/linux-postinstall.
Juniper Networks, Juniper Networks-ის ლოგო, Juniper და Junos არის Juniper Networks, Inc.-ის რეგისტრირებული სავაჭრო ნიშნები შეერთებულ შტატებში და სხვა ქვეყნებში. ყველა სხვა სავაჭრო ნიშანი, მომსახურების ნიშანი, რეგისტრირებული ან რეგისტრირებული სერვისის ნიშანი მათი შესაბამისი მფლობელების საკუთრებაა. Juniper Networks არ იღებს პასუხისმგებლობას ამ დოკუმენტის უზუსტობებზე. Juniper Networks იტოვებს უფლებას შეცვალოს, შეცვალოს, გადაიტანოს ან სხვაგვარად გადახედოს ამ პუბლიკაციას შეტყობინების გარეშე. საავტორო უფლება © 2025 Juniper Networks,
Inc. ყველა უფლება დაცულია.

დოკუმენტები / რესურსები

JUNIPER NETWORKS Routing Active Testing Solution Brief [pdf] მომხმარებლის სახელმძღვანელო Routing Active Testing Solution Brief, Active Testing Solution Brief, Testing Solution Brief, Solution Brief

ცნობები

• მომხმარებლის სახელმძღვანელო