คู่มือผู้ใช้ Juniper Streaming API

ความเรียบง่ายทางวิศวกรรม
คู่มือการสตรีม API

การแนะนำ

คู่มือนี้อธิบายวิธีการดึงข้อมูลจาก Paragon Active Assurance ผ่าน API การสตรีมของผลิตภัณฑ์
API และไคลเอ็นต์การสตรีมจะรวมอยู่ในการติดตั้ง Paragon Active Assurance
อย่างไรก็ตาม จำเป็นต้องมีการกำหนดค่าเล็กน้อยก่อนที่คุณจะสามารถใช้ API ได้ ซึ่งครอบคลุมอยู่ใน "การกำหนดค่า Streaming API" ในหน้า 1 บท

เกินview

บทนี้อธิบายวิธีกำหนดค่า Streaming API เพื่ออนุญาตให้สมัครรับข้อความเมตริกผ่าน Kafka
ด้านล่างนี้เราจะผ่าน:

• วิธีเปิดใช้งาน Streaming API
• วิธีกำหนดค่า Kafka เพื่อฟังไคลเอนต์ภายนอก
• วิธีกำหนดค่า Kafka ให้ใช้ ACL และตั้งค่าการเข้ารหัส SSL สำหรับไคลเอนต์ดังกล่าว

คาฟคาคืออะไร?

Kafka เป็นแพลตฟอร์มการสตรีมเหตุการณ์ที่ช่วยให้สามารถจับภาพแบบเรียลไทม์ของข้อมูลที่ส่งจากแหล่งเหตุการณ์ต่างๆ (เซ็นเซอร์ ฐานข้อมูล อุปกรณ์พกพา) ในรูปแบบของสตรีมเหตุการณ์ ตลอดจนการจัดเก็บสตรีมเหตุการณ์เหล่านี้อย่างคงทนเพื่อการดึงข้อมูลและการจัดการในภายหลัง
ด้วย Kafka คุณสามารถจัดการการสตรีมเหตุการณ์แบบ end-to-end ในรูปแบบกระจาย ปรับขนาดได้สูง ยืดหยุ่น ทนต่อข้อผิดพลาด และปลอดภัย
บันทึก: Kafka สามารถกำหนดค่าได้หลายวิธีและได้รับการออกแบบมาสำหรับความสามารถในการปรับขนาดและระบบสำรอง เอกสารนี้มุ่งเน้นเฉพาะวิธีการกำหนดค่าเพื่อใช้คุณลักษณะ Streaming API ที่พบใน Paragon Active Assurance Control Center สำหรับการตั้งค่าขั้นสูงเพิ่มเติม เราอ้างอิงจากเอกสาร Kafka อย่างเป็นทางการ: kafka.apache.org/26/documentation.html.

คำศัพท์

• Kafka: แพลตฟอร์มการสตรีมกิจกรรม
• หัวข้อคาฟคา: การรวบรวมเหตุการณ์
• สมาชิก Kafka / ผู้บริโภค: ส่วนประกอบที่รับผิดชอบในการเรียกคืนเหตุการณ์ที่จัดเก็บไว้ในหัวข้อ Kafka
• โบรกเกอร์คาฟคา: เซิร์ฟเวอร์เลเยอร์สตอเรจของคลัสเตอร์คาฟคา
• SSL/TLS: SSL เป็นโปรโตคอลที่ปลอดภัยซึ่งพัฒนาขึ้นสำหรับการส่งข้อมูลอย่างปลอดภัยทางอินเทอร์เน็ต TLS เป็นตัวตายตัวแทนของ SSL ซึ่งเปิดตัวในปี 1999
• SASL: กรอบงานที่มีกลไกสำหรับการพิสูจน์ตัวตนผู้ใช้ การตรวจสอบความสมบูรณ์ของข้อมูล และการเข้ารหัส
• ผู้สมัครสมาชิก Streaming API: ส่วนประกอบที่รับผิดชอบในการเรียกคืนเหตุการณ์ที่จัดเก็บไว้ในหัวข้อที่กำหนดใน Paragon Active Assurance และมีความหมายสำหรับการเข้าถึงจากภายนอก
• ผู้ออกใบรับรอง: เอนทิตีที่เชื่อถือได้ซึ่งออกและเพิกถอนใบรับรองคีย์สาธารณะ
• ใบรับรองหลักของผู้ออกใบรับรอง: ใบรับรองคีย์สาธารณะที่ระบุผู้ออกใบรับรอง

วิธีการทำงานของ Streaming API

ตามที่กล่าวไว้ก่อนหน้านี้ Streaming API อนุญาตให้ไคลเอ็นต์ภายนอกดึงข้อมูลเกี่ยวกับเมตริกจาก Kafka
เมตริกทั้งหมดที่รวบรวมโดย Test Agents ระหว่างการทดสอบหรืองานตรวจสอบจะถูกส่งไปยังบริการ Stream
หลังจากขั้นตอนการประมวลผล บริการสตรีมเผยแพร่เมตริกเหล่านั้นบน Kafka พร้อมกับข้อมูลเมตาเพิ่มเติม

หัวข้อคาฟคา

คาฟคามีแนวคิดเกี่ยวกับหัวข้อที่จะเผยแพร่ข้อมูลทั้งหมด ใน Paragon Active Assurance มีหัวข้อ Kafka มากมายให้เลือก อย่างไรก็ตาม มีเพียงบางส่วนเท่านั้นที่มีไว้สำหรับการเข้าถึงจากภายนอก
บัญชี Paragon Active Assurance แต่ละบัญชีในศูนย์ควบคุมมีสองหัวข้อเฉพาะ ด้านล่าง ACCOUNT คือชื่อย่อของบัญชี:

• paa.public.accounts.{ACCOUNT}.เมตริก
• ข้อความเมตริกทั้งหมดสำหรับบัญชีที่ระบุได้รับการเผยแพร่ในหัวข้อนี้
• ข้อมูลจำนวนมาก
• ความถี่ในการอัปเดตสูง
• paa.public.accounts.{ACCOUNT}.เมตาดาต้า
• มีข้อมูลเมตาที่เกี่ยวข้องกับข้อมูลเมตริก เช่นampทดสอบ มอนิเตอร์ หรือ Test Agent ที่เกี่ยวข้องกับเมตริก
• ข้อมูลจำนวนน้อย
• ความถี่ในการอัปเดตต่ำ

เปิดใช้งาน Streaming API

บันทึก: คำแนะนำเหล่านี้จะต้องทำงานบนเซิร์ฟเวอร์ศูนย์ควบคุมโดยใช้ sudo
เนื่องจาก Streaming API เพิ่มโอเวอร์เฮดบางส่วนให้กับศูนย์ควบคุม จึงไม่ได้เปิดใช้งานตามค่าเริ่มต้น ในการเปิดใช้งาน API ก่อนอื่นเราต้องเปิดใช้งานการเผยแพร่ตัวชี้วัดไปยัง Kafka ในการกำหนดค่าหลัก file:

• /etc/netrounds/netrounds.conf
  KAFKA_METRICS_ENABLED = จริง
  คำเตือน: การเปิดใช้งานคุณลักษณะนี้อาจส่งผลต่อประสิทธิภาพของศูนย์ควบคุม ตรวจสอบให้แน่ใจว่าคุณได้กำหนดขนาดอินสแตนซ์ของคุณตามนั้น
  ถัดไป เพื่อเปิดใช้งานการส่งต่อเมตริกเหล่านี้ไปยังหัวข้อคาฟคาที่ถูกต้อง:
• /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 ติดตั้ง kafkacat
หากคุณมีการทดสอบหรือการตรวจสอบที่ทำงานอยู่ในศูนย์ควบคุม คุณควรจะสามารถใช้คาฟคาแคทเพื่อรับเมตริกและข้อมูลเมตาในหัวข้อเหล่านี้ได้
แทนที่ myaccount ด้วยชื่อย่อของบัญชีของคุณ (นี่คือสิ่งที่คุณเห็นในศูนย์ควบคุมของคุณ URL):
ส่งออก METRICS_TOPIC=paa.public.accounts.myaccount.metrics
ส่งออก METADATA_TOPIC=paa.public.accounts.myaccount.metadata
ตอนนี้คุณควรเห็นเมตริกโดยเรียกใช้คำสั่งนี้:
คาฟคาแคท -b ${KAFKA_FQDN}:9092 -t ${METRICS_TOPIC} -C -e
ถึง view ข้อมูลเมตา เรียกใช้คำสั่งต่อไปนี้ (โปรดทราบว่าคำสั่งนี้จะไม่อัปเดตบ่อยนัก):
คาฟคาแคท -b ${KAFKA_FQDN}:9092 -t ${METADATA_TOPIC} -C -e
บันทึก:
kafkacat” ลูกค้าเก่าampน้อยลง” บนหน้าที่ 14
นี่เป็นการยืนยันว่าเรามี Streaming API ที่ใช้งานได้จากภายในศูนย์ควบคุม อย่างไรก็ตาม เป็นไปได้มากว่าคุณสนใจที่จะเข้าถึงข้อมูลจากไคลเอ็นต์ภายนอกแทน ส่วนถัดไปจะอธิบายวิธีเปิด Kafka สำหรับการเข้าถึงจากภายนอก

การเปิด Kafka สำหรับโฮสต์ภายนอก

บันทึก: คำแนะนำเหล่านี้จะต้องทำงานบนเซิร์ฟเวอร์ศูนย์ควบคุม
ตามค่าเริ่มต้น Kafka ที่ทำงานบนศูนย์ควบคุมจะได้รับการกำหนดค่าให้ฟังเฉพาะใน localhost สำหรับการใช้งานภายใน
เป็นไปได้ที่จะเปิด Kafka สำหรับไคลเอนต์ภายนอกโดยแก้ไขการตั้งค่า Kafka
การเชื่อมต่อกับคาฟคา: คำเตือน
คำเตือน: โปรดอ่านอย่างละเอียด เนื่องจากเป็นเรื่องง่ายที่จะพบกับปัญหาการเชื่อมต่อกับ Kafka หากคุณไม่เข้าใจแนวคิดเหล่านี้
ในการตั้งค่าศูนย์ควบคุมที่อธิบายไว้ในเอกสารนี้ มีโบรกเกอร์ Kafka เพียงแห่งเดียวเท่านั้น
อย่างไรก็ตาม โปรดทราบว่าโบรกเกอร์ Kafka มีไว้เพื่อให้ทำงานเป็นส่วนหนึ่งของคลัสเตอร์ Kafka ซึ่งอาจประกอบด้วยโบรกเกอร์ Kafka จำนวนมาก
เมื่อเชื่อมต่อกับโบรกเกอร์ Kafka การเชื่อมต่อเริ่มต้นจะถูกตั้งค่าโดยไคลเอนต์ Kafka ในการเชื่อมต่อนี้ โบรกเกอร์ Kafka จะส่งกลับรายการของ "ผู้ฟังที่โฆษณา" ซึ่งเป็นรายชื่อของโบรกเกอร์ Kafka หนึ่งรายขึ้นไป
เมื่อได้รับรายการนี้ ไคลเอนต์ Kafka จะยกเลิกการเชื่อมต่อ จากนั้นเชื่อมต่อกับหนึ่งในผู้ฟังที่โฆษณาเหล่านี้อีกครั้ง Listener ที่โฆษณาต้องมีชื่อโฮสต์หรือที่อยู่ IP ที่ไคลเอนต์ Kafka สามารถเข้าถึงได้ มิฉะนั้นไคลเอนต์จะไม่สามารถเชื่อมต่อได้
หากใช้การเข้ารหัส SSL ซึ่งเกี่ยวข้องกับใบรับรอง SSL ซึ่งเชื่อมโยงกับชื่อโฮสต์เฉพาะ ไคลเอนต์ Kafka จะได้รับที่อยู่ที่ถูกต้องเพื่อเชื่อมต่อนั้นสำคัญยิ่งกว่า เนื่องจากมิฉะนั้นการเชื่อมต่ออาจถูกปฏิเสธ
อ่านเพิ่มเติมเกี่ยวกับผู้ฟังคาฟคาได้ที่นี่: www.confluent.io/blog/kafka-listeners-explaed
การเข้ารหัส SSL/TLS
เพื่อให้แน่ใจว่าไคลเอนต์ที่เชื่อถือได้เท่านั้นที่ได้รับอนุญาตให้เข้าถึง Kafka และ Streaming API เราต้องกำหนดค่าต่อไปนี้:

• การรับรองความถูกต้อง: ลูกค้าต้องระบุชื่อผู้ใช้และรหัสผ่านผ่านการเชื่อมต่อที่ปลอดภัย SSL/TLS ระหว่างไคลเอ็นต์และ Kafka
• การอนุญาต: ไคลเอนต์ที่รับรองความถูกต้องสามารถปฏิบัติงานที่ควบคุมโดย ACL
  นี่เป็นมากกว่าview:

*) การตรวจสอบชื่อผู้ใช้/รหัสผ่านดำเนินการบนช่องทางที่เข้ารหัส SSL
เพื่อให้เข้าใจอย่างถ่องแท้ว่าการเข้ารหัส SSL/TLS ทำงานอย่างไรสำหรับ Kafka โปรดดูเอกสารอย่างเป็นทางการ: docs.confluent.io/platform/current/kafka/encryption.html
ใบรับรอง SSL/TLS เกินview
บันทึก: ในส่วนย่อยนี้ เราจะใช้คำศัพท์ต่อไปนี้:
ใบรับรอง: ใบรับรอง SSL ที่ลงนามโดยผู้ออกใบรับรอง (CA) โบรกเกอร์ Kafka แต่ละรายมีหนึ่ง
ที่เก็บคีย์: ที่เก็บกุญแจ file ที่เก็บใบรับรอง ที่เก็บกุญแจ file มีรหัสส่วนตัวของใบรับรอง ดังนั้นจึงจำเป็นต้องเก็บไว้อย่างปลอดภัย
ทรัสต์สโตร์: A file มีใบรับรอง CA ที่เชื่อถือได้
ในการตั้งค่าการรับรองความถูกต้องระหว่างไคลเอนต์ภายนอกและ Kafka ที่ทำงานในศูนย์ควบคุม ทั้งสองฝ่ายต้องมีที่เก็บคีย์ที่กำหนดด้วยใบรับรองที่เกี่ยวข้องซึ่งลงนามโดยผู้ออกใบรับรอง (CA) ร่วมกับใบรับรองรูทของ CA
นอกจากนี้ ไคลเอนต์ยังต้องมี truststore ที่มีใบรับรองรูทของ CA
ใบรับรองรูทของ CA นั้นใช้ร่วมกันกับนายหน้า Kafka และไคลเอนต์ Kafka
การสร้างใบรับรองที่จำเป็น
ซึ่งครอบคลุมอยู่ใน “ภาคผนวก” ในหน้า 17
การกำหนดค่า SSL/TLS ของโบรกเกอร์ Kafka ในศูนย์ควบคุม
บันทึก: คำแนะนำเหล่านี้จะต้องทำงานบนเซิร์ฟเวอร์ศูนย์ควบคุม
บันทึก: ก่อนดำเนินการต่อ คุณต้องสร้างที่เก็บคีย์ซึ่งมีใบรับรอง SSL โดยทำตามคำแนะนำใน “ภาคผนวก” บนหน้าที่ 17 เส้นทางที่กล่าวถึงด้านล่างมาจากคำแนะนำเหล่านี้
ที่เก็บคีย์ SSL คือ 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
# เหล่านี้คือโฮสต์ที่โฆษณากลับไปยังไคลเอนต์ที่เชื่อมต่อ
โฆษณา.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.โปรโตคอล=TLSv1.2
# การกำหนดค่า SASL sasl.enabled.mechanisms=PLAIN
Listener.name.sasl_ssl.plain.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginMo dule ที่จำเป็น \ username=”admin” \ password=” ” \ user_admin=” ” \ user_client=” ”; # หมายเหตุสามารถเพิ่มผู้ใช้ได้มากขึ้นด้วย user_ =
# การอนุญาต เปิด ACLs authorizer.class.name=kafka.security.authorizer.AclAuthorizer super.users=User:admin
การตั้งค่ารายการควบคุมการเข้าถึง (ACL)
เปิด ACL บน localhost
คำเตือน: ก่อนอื่นเราต้องตั้งค่า ACL สำหรับ localhost เพื่อให้ Control Center เองยังคงสามารถเข้าถึง 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 \
–เพิ่ม –อนุญาตผู้ใช้หลัก:* –การดำเนินการอ่าน –การดำเนินการอธิบาย \–กลุ่ม 'NCC'
/usr/lib/kafka/bin/kafka-acls.sh \
–ผู้อนุญาต kafka.security.authorizer.AclAuthorizer \
– ผู้อนุญาตคุณสมบัติ Zookeeper.connect=localhost:2181 \
– เพิ่ม – ผู้ใช้หลักที่อนุญาต:* – การดำเนินการอ่าน – การดำเนินการอธิบาย \
– หัวข้อ paa.public. – คำนำหน้าประเภทรูปแบบทรัพยากร
เมื่อดำเนินการเสร็จแล้ว คุณต้องเริ่มบริการใหม่:
บริการ sudo ncc เริ่มต้นใหม่
ในการตรวจสอบว่าไคลเอนต์สามารถสร้างการเชื่อมต่อที่ปลอดภัย ให้รันคำสั่งต่อไปนี้บนคอมพิวเตอร์ไคลเอ็นต์ภายนอก (ไม่ใช่บนเซิร์ฟเวอร์ศูนย์ควบคุม) ด้านล่างนี้ PUBLIC_HOSTNAME คือชื่อโฮสต์ของศูนย์ควบคุม:
openssl s_client -debug -เชื่อมต่อ ${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 และรหัสผ่านที่ตั้งไว้ที่นั่น
ใบรับรองหลัก CA ที่ใช้ในการลงนามใบรับรอง 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} คือตำแหน่งของใบรับรองหลัก CA ที่ใช้โดยนายหน้า Kafka
  • {CLIENT_USER} และ {CLIENT_PASSWORD} เป็นข้อมูลรับรองผู้ใช้สำหรับลูกค้า
  • รันคำสั่งต่อไปนี้เพื่อดูข้อความที่คาฟคาแคทใช้:
  ส่งออก 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 สำหรับการอ่านการตั้งค่าไคลเอ็นต์จาก file. หากคุณใช้เวอร์ชันดังกล่าว คุณต้องระบุการตั้งค่าเดียวกันจากบรรทัดคำสั่งตามที่แสดงด้านล่าง
คาฟคาแคท -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} \
-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) (ดู developer.google.com/protocol-buffers). แบบแผนสำหรับข้อความเหล่านี้เป็นไปตามรูปแบบต่อไปนี้:
ตัวชี้วัด Protobuf Schema
ไวยากรณ์ = "proto3"; นำเข้า “google/protobuf/timestamp.proto”; แพ็คเกจ paa.streamingapi; ตัวเลือก go_package = “.;paa_streamingapi”; เมตริกข้อความ { google.protobuf.Timestamp ครั้งamp = 1; แผนที่ ค่า = 2; การวัด int32_id = 3; } /** * ค่าเมตริกเป็นจำนวนเต็มหรือทศนิยมก็ได้ */
ข้อความ MetricValue { oneof ประเภท { int64 int_val = 1; ลอย float_val = 2; } }
เมตาโปรโตบัฟสคีมา
ไวยากรณ์ = "proto3"; แพ็คเกจ paa.streamingapi; ตัวเลือก go_package = “.;paa_streamingapi”; ข้อความ ข้อมูลเมตา { int32 การวัด _id = 1; สตริง การวัดชื่อ = 2; แผนที่ tags = 13; -

ตัวอย่างลูกค้าampเลส

บันทึก: คำสั่งเหล่านี้มีวัตถุประสงค์เพื่อรันบนไคลเอนต์ภายนอก เช่นampแล็ปท็อปของคุณหรือที่คล้ายกัน และไม่ได้อยู่ในศูนย์ควบคุม
บันทึก: หากต้องการแสดงข้อมูลเมตริก ตรวจสอบให้แน่ใจว่ามีจอภาพอย่างน้อยหนึ่งจอทำงานในศูนย์ควบคุม
tarball ของศูนย์ควบคุมประกอบด้วยไฟล์เก็บถาวร paa-streaming-api-client-examples.tar.gz (ไคลเอนต์-อดีตampเลส) ซึ่งมี exampสคริปต์ Python แสดงวิธีใช้ Streaming API
การติดตั้งและกำหนดค่าไคลเอ็นต์ เช่นampเลส
คุณพบไคลเอนต์-อดีตampไฟล์ในโฟลเดอร์ Paragon Active Assurance Control Center:
ส่งออก CC_VERSION=3.3.1
cd ./paa-control-center_${CC_VERSION} ls paa-สตรีมมิ่ง-api-ไคลเอนต์-exampเลส*
ในการติดตั้งไคลเอ็นต์-exampไฟล์บนคอมพิวเตอร์ไคลเอ็นต์ภายนอกของคุณ ให้ดำเนินการดังนี้:
# สร้างไดเรกทอรีสำหรับการแยกเนื้อหาของลูกค้าเช่นampไฟล์ tarball mkdir paa-streaming-api-client-exampเลส
# แยกเนื้อหาของลูกค้าเช่นampไฟล์ tarball tar xzf paa-streaming-api-client-examples.tar.gz -C paa-สตรีมมิ่ง-api-client-exampเลส
# ไปที่ไดเร็กทอรีที่สร้างขึ้นใหม่ cd paa-streaming-api-client-exampจากไคลเอนต์-อดีตampไฟล์ต้องการให้นักเทียบท่าทำงาน ดาวน์โหลดและคำแนะนำในการติดตั้งสำหรับ Docker ได้ที่ https://docs.docker.com/engine/install.
การใช้ไคลเอ็นต์เช่นampเลส
ลูกค้า-อดีตampเครื่องมือ les สามารถทำงานในโหมดพื้นฐานหรือขั้นสูงเพื่อสร้าง exampความซับซ้อนที่แตกต่างกัน ในทั้งสองกรณี คุณสามารถเรียกใช้ ex ได้เช่นกันampด้วยการกำหนดค่า file มีคุณสมบัติเพิ่มเติมสำหรับการปรับแต่งเพิ่มเติมของฝั่งไคลเอ็นต์
โหมดพื้นฐาน ในโหมดพื้นฐาน เมตริกและข้อมูลเมตาจะถูกสตรีมแยกกัน เพื่อจุดประสงค์นี้ ลูกค้าจะฟังหัวข้อคาฟคาแต่ละหัวข้อที่มีให้สำหรับการเข้าถึงจากภายนอก และเพียงแค่พิมพ์ข้อความที่ได้รับไปยังคอนโซล
เพื่อเริ่มการดำเนินการของอดีตพื้นฐานampไฟล์, รัน: ./build.sh run-basic –kafka-brokers localhost:9092 –account_SHORTNAME
โดยที่ ACCOUNT_SHORTNAME คือชื่อย่อของบัญชีที่คุณต้องการรับเมตริก
เพื่อยุติการบังคับคดีของอดีตampจากนั้นกด Ctrl + C (อาจมีการหน่วงเวลาเล็กน้อยก่อนที่การดำเนินการจะหยุดลง เนื่องจากไคลเอนต์รอเหตุการณ์การหมดเวลา)
โหมดขั้นสูง
บันทึก: เมตริกจะแสดงเฉพาะสำหรับจอภาพ HTTP ที่ทำงานในศูนย์ควบคุม
การดำเนินการในโหมดขั้นสูงแสดงความสัมพันธ์ระหว่างเมตริกและข้อความข้อมูลเมตา สิ่งนี้เกิดขึ้นได้เนื่องจากการมีอยู่ในแต่ละข้อความเมตริกของช่องรหัสสตรีมซึ่งอ้างถึงข้อความข้อมูลเมตาที่สอดคล้องกัน
เพื่อดำเนินการขั้นสูงเช่นampไฟล์ run: ./build.sh run-advanced –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME โดยที่ ACCOUNT_SHORTNAME คือชื่อย่อของบัญชีที่คุณต้องการรับตัวชี้วัด
เพื่อยุติการบังคับคดีของอดีตampจากนั้นกด Ctrl + C (อาจมีการหน่วงเวลาเล็กน้อยก่อนที่การดำเนินการจะหยุดลง เนื่องจากไคลเอนต์รอเหตุการณ์การหมดเวลา)
การตั้งค่าเพิ่มเติม
เป็นไปได้ที่จะเรียกใช้อดีตampด้วยการกำหนดค่าเพิ่มเติมของไคลเอ็นต์โดยใช้ –config-file ตัวเลือกตามด้วย file ชื่อที่มีคุณสมบัติในรูปแบบ key=value
./build.sh run-advanced \ –kafka-brokers localhost:9092 \ –account ACCOUNT_SHORTNAME \ –config-file client_config.properties
บันทึก: ทั้งหมด fileการอ้างอิงในคำสั่งด้านบนต้องอยู่ในไดเร็กทอรีปัจจุบันและอ้างอิงโดยใช้พาธสัมพัทธ์เท่านั้น สิ่งนี้ใช้ได้ทั้งกับ –config-file อาร์กิวเมนต์และรายการทั้งหมดในการกำหนดค่า file ที่อธิบาย file สถานที่
การตรวจสอบความถูกต้องของไคลเอนต์ภายนอก
ในการตรวจสอบความถูกต้องของไคลเอนต์จากภายนอกศูนย์ควบคุมโดยใช้ไคลเอนต์-อดีตampให้ทำตามขั้นตอนต่อไปนี้:

• จากโฟลเดอร์ Paragon Active Assurance Control Center ให้สลับไปที่ paa-streaming-api-clientexampโฟลเดอร์ไฟล์:
  cd paa-สตรีมมิ่ง-api-client-exampเลส
• คัดลอกใบรับรองหลัก CA ca-cert ลงในไดเร็กทอรีปัจจุบัน
• สร้าง client.properties file โดยมีเนื้อหาดังนี้:
  security.protocol=SASL_SSL
  ssl.ca.location=ca-ใบรับรอง
  sasl.mechanism=ธรรมดา
  sasl.username={CLIENT_USER}
  sasl.password={CLIENT_PASSWORD}
  โดยที่ {CLIENT_USER} และ {CLIENT_PASSWORD} เป็นข้อมูลรับรองผู้ใช้สำหรับลูกค้า
• เรียกใช้พื้นฐานเช่นampเลส:
  ส่งออก KAFKA_FQDN= ./build.sh run-basic –kafka-brokers ${KAFKA_FQDN}:9093 \ –account_SHORTNAME
  –กำหนดค่า-file client.properties โดยที่ ACCOUNT_SHORTNAME คือชื่อย่อของบัญชีที่คุณต้องการรับเมตริก
• เรียกใช้ขั้นสูง เช่นampเลส:
  ส่งออก KAFKA_FQDN= ./build.sh เรียกใช้ขั้นสูง –kafka-brokers ${KAFKA_FQDN}:9093 \ –account ACCOUNT_SHORTNAME–config-file ลูกค้า.คุณสมบัติ

ภาคผนวก

ในภาคผนวกนี้ เราจะอธิบายวิธีการสร้าง:

• ที่เก็บกุญแจ file สำหรับจัดเก็บใบรับรอง SSL ของโบรกเกอร์ Kafka
• ร้านค้าที่เชื่อถือได้ file สำหรับจัดเก็บใบรับรองหลักของผู้ออกใบรับรอง (CA) ที่ใช้ในการลงนามใบรับรองนายหน้าคาฟคา

การสร้างใบรับรองนายหน้าคาฟคา
การสร้างใบรับรองโดยใช้ผู้ออกใบรับรองจริง (แนะนำ)
ขอแนะนำให้คุณได้รับใบรับรอง SSL จริงจาก CA ที่เชื่อถือได้
เมื่อคุณตัดสินใจเลือก CA แล้ว ให้คัดลอกใบรับรอง CA หลัก 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
การสร้าง Client Truststore
ตอนนี้คุณสามารถสร้าง truststore file ที่มี ca-cert ที่สร้างขึ้นด้านบน นี้ file ไคลเอนต์ Kafka จะต้องการการเข้าถึง Streaming API:
keytool -keystore kafka.client.truststore.jks \ -นามแฝง CARoot \ -importcert -file ${CA_PATH}/ca-ใบรับรอง
เมื่อใบรับรอง CA อยู่ใน truststore แล้ว ไคลเอ็นต์จะเชื่อถือใบรับรองใดๆ ที่ลงนามด้วย
คุณควรคัดลอกไฟล์ file kafka.client.truststore.jks ไปยังตำแหน่งที่รู้จักในคอมพิวเตอร์ไคลเอนต์ของคุณ และชี้ไปที่ตำแหน่งนั้นในการตั้งค่า
การสร้างที่เก็บคีย์สำหรับนายหน้าคาฟคา
หากต้องการสร้างใบรับรอง SSL ของโบรกเกอร์ Kafka และที่เก็บคีย์ kafka.server.keystore.jks ให้ดำเนินการดังนี้:
การสร้างใบรับรอง SSL
ด้านล่าง 999 คือจำนวนวันที่ที่เก็บคีย์ใช้ได้ และ FQDN คือชื่อโดเมนแบบเต็มของไคลเอนต์ (ชื่อโฮสต์สาธารณะของโหนด)
บันทึก: สิ่งสำคัญคือ FQDN จะต้องตรงกับชื่อโฮสต์ที่ไคลเอนต์ Kafka จะใช้เพื่อเชื่อมต่อกับศูนย์ควบคุม sudo mkdir -p /var/ssl/private
sudo chown -R $USER: /var/ssl/private cd /var/ssl/private export FQDN=
keytool -keystore kafka.server.keystore.jks \ -เซิร์ฟเวอร์นามแฝง \ -ความถูกต้อง 999 \ -genkey -keyalg RSA -ext SAN=dns:${FQDN}
สร้างคำขอลงนามใบรับรองและจัดเก็บไว้ใน file ชื่อ cert-server-request:
keytool -keystore kafka.server.keystore.jks \ -เซิร์ฟเวอร์นามแฝง \ -certreq \ -file ใบรับรองเซิร์ฟเวอร์คำขอ
ตอนนี้คุณควรส่ง file cert-server-request ไปยัง Certificate Authority (CA) ของคุณ หากคุณใช้ใบรับรองจริง จากนั้นพวกเขาจะส่งคืนใบรับรองที่ลงนามแล้ว เราจะเรียกสิ่งนี้ว่า cert-server-signed ด้านล่าง การลงนามใบรับรอง 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 \ -in 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-server-signed:
keytool -keystore kafka.server.keystore.jks \ -เซิร์ฟเวอร์นามแฝง \ -นำเข้า \ -file ใบรับรองเซิร์ฟเวอร์ลงนาม
การ file ควรคัดลอก kafka.server.keystore.jks ไปยังตำแหน่งที่รู้จักบนเซิร์ฟเวอร์ศูนย์ควบคุม จากนั้นอ้างอิงใน /etc/kafka/server.properties
การใช้ Streaming API

ทั่วไป

API การสตรีมดึงข้อมูลทั้งการทดสอบและการตรวจสอบ ไม่สามารถแยกแยะประเภทใดประเภทหนึ่งเหล่านี้ออกได้
API การสตรีมไม่ดึงข้อมูลจากการทดสอบตามสคริปต์ (ซึ่งแสดงด้วยสี่เหลี่ยมผืนผ้าแทนชิ้นส่วนจิ๊กซอว์ใน Control Center GUI) เช่น การทดสอบการเปิดใช้งานบริการอีเทอร์เน็ต และการทดสอบความโปร่งใส
ชื่อหัวข้อคาฟคา
ชื่อหัวข้อ Kafka สำหรับ API การสตรีมมีดังนี้ โดยที่ %s เป็นชื่อย่อของ Control
บัญชีกลาง (ระบุเมื่อสร้างบัญชี):
const (ชื่อผู้ส่งออก = “kafka”metadataTopicTpl = “paa.public.accounts.%s.metadata” metricsTopicTpl = “paa.public.accounts.%s.metrics”)
Exampของการใช้ Streaming API
อดีตampไฟล์ที่ตามมาพบได้ใน tarball paa-streaming-api-client-examples.tar.gz อยู่ภายใน tarball ศูนย์ควบคุม
ประการแรกมีอดีตขั้นพื้นฐานampสาธิตวิธีสตรีมข้อมูลเมตริกและข้อมูลเมตาแยกจากกัน และพิมพ์ข้อความที่ได้รับไปยังคอนโซล คุณสามารถเรียกใช้ได้ดังต่อไปนี้: 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 ขอสงวนสิทธิ์ในการเปลี่ยนแปลง แก้ไข โอน หรือแก้ไขสิ่งพิมพ์นี้โดยไม่ต้องแจ้งให้ทราบล่วงหน้า ลิขสิทธิ์ © 2022 Juniper Networks, Inc. สงวนลิขสิทธิ์