การกำหนดเส้นทางการทดสอบแบบ Active Streaming API
แนะนำ
การแนะนำ
คู่มือนี้จะอธิบายวิธีการดึงข้อมูลจาก Routing Active Testing ผ่านทาง API สตรีมมิ่งของผลิตภัณฑ์
API และไคลเอนต์สตรีมมิ่งจะรวมอยู่ในการติดตั้ง Routing Active Testing อย่างไรก็ตาม จำเป็นต้องมีการกำหนดค่าเล็กน้อยก่อนจึงจะใช้งาน API ได้ รายละเอียดนี้อธิบายไว้ในบท "การกำหนดค่า Streaming API" ในหน้า 1
การกำหนดค่าสตรีมมิ่ง API
เกินview
บทนี้อธิบายวิธีกำหนดค่า Streaming API เพื่ออนุญาตให้สมัครรับข้อความเมตริกผ่าน Kafka
ด้านล่างนี้เราจะผ่าน:
- วิธีเปิดใช้งาน Streaming API
- วิธีกำหนดค่า Kafka เพื่อฟังไคลเอนต์ภายนอก
- วิธีกำหนดค่า Kafka ให้ใช้ ACL และตั้งค่าการเข้ารหัส SSL สำหรับไคลเอนต์ดังกล่าว
คาฟคาคืออะไร?
Kafka เป็นแพลตฟอร์มการสตรีมเหตุการณ์ที่ช่วยให้สามารถจับภาพแบบเรียลไทม์ของข้อมูลที่ส่งจากแหล่งเหตุการณ์ต่างๆ (เซ็นเซอร์ ฐานข้อมูล อุปกรณ์พกพา) ในรูปแบบของสตรีมเหตุการณ์ ตลอดจนการจัดเก็บสตรีมเหตุการณ์เหล่านี้อย่างคงทนเพื่อการดึงข้อมูลและการจัดการในภายหลัง
ด้วย Kafka คุณสามารถจัดการการสตรีมเหตุการณ์แบบ end-to-end ในรูปแบบกระจาย ปรับขนาดได้สูง ยืดหยุ่น ทนต่อข้อผิดพลาด และปลอดภัย
บันทึก: Kafka สามารถกำหนดค่าได้หลากหลายวิธี และออกแบบมาเพื่อรองรับการขยายระบบและรองรับระบบที่ซ้ำซ้อน เอกสารนี้มุ่งเน้นเฉพาะวิธีการกำหนดค่าเพื่อใช้งานฟีเจอร์ Streaming API ที่พบใน Routing Active Testing Control Center สำหรับการตั้งค่าขั้นสูง โปรดดูเอกสารอย่างเป็นทางการของ Kafka: kafka.apache.org/26/documentation.html.
คำศัพท์
- Kafka: แพลตฟอร์มการสตรีมกิจกรรม
- หัวข้อคาฟคา: การรวบรวมเหตุการณ์
- สมาชิก Kafka / ผู้บริโภค: ส่วนประกอบที่รับผิดชอบในการเรียกคืนเหตุการณ์ที่จัดเก็บไว้ในหัวข้อ Kafka
- โบรกเกอร์คาฟคา: เซิร์ฟเวอร์เลเยอร์สตอเรจของคลัสเตอร์คาฟคา
- SSL/TLS: SSL เป็นโปรโตคอลที่ปลอดภัยซึ่งพัฒนาขึ้นสำหรับการส่งข้อมูลอย่างปลอดภัยทางอินเทอร์เน็ต TLS เป็นตัวตายตัวแทนของ SSL ซึ่งเปิดตัวในปี 1999
- SASL: กรอบงานที่มีกลไกสำหรับการพิสูจน์ตัวตนผู้ใช้ การตรวจสอบความสมบูรณ์ของข้อมูล และการเข้ารหัส
- ผู้สมัคร API การสตรีม: ส่วนประกอบที่รับผิดชอบในการดึงข้อมูลเหตุการณ์ที่เก็บไว้ในหัวข้อที่กำหนดไว้ในการทดสอบการกำหนดเส้นทางแบบแอคทีฟและมีไว้สำหรับการเข้าถึงจากภายนอก
- ผู้ออกใบรับรอง: เอนทิตีที่เชื่อถือได้ซึ่งออกและเพิกถอนใบรับรองคีย์สาธารณะ
- ใบรับรองหลักของผู้ออกใบรับรอง: ใบรับรองคีย์สาธารณะที่ระบุผู้ออกใบรับรอง
วิธีการทำงานของ Streaming API
ตามที่กล่าวไว้ก่อนหน้านี้ Streaming API อนุญาตให้ไคลเอ็นต์ภายนอกดึงข้อมูลเกี่ยวกับเมตริกจาก Kafka
เมตริกทั้งหมดที่รวบรวมโดย Test Agents ระหว่างการทดสอบหรืองานตรวจสอบจะถูกส่งไปยังบริการ Stream
หลังจากขั้นตอนการประมวลผล บริการสตรีมเผยแพร่เมตริกเหล่านั้นบน Kafka พร้อมกับข้อมูลเมตาเพิ่มเติม
หัวข้อคาฟคา
Kafka มีแนวคิดเรื่องหัวข้อที่ข้อมูลทั้งหมดจะถูกเผยแพร่ ใน Routing Active Testing มีหัวข้อ Kafka มากมายให้เลือกใช้ แต่มีเพียงบางส่วนเท่านั้นที่สามารถเข้าถึงได้จากภายนอก
แต่ละบัญชี Routing Active Testing ใน Control Center จะมีหัวข้อเฉพาะสองหัวข้อ ด้านล่างนี้คือชื่อย่อของบัญชี ACCOUNT:
- paa.public.accounts.{ACCOUNT}.เมตริก
- ข้อความเมตริกทั้งหมดสำหรับบัญชีที่ระบุได้รับการเผยแพร่ในหัวข้อนี้
- ข้อมูลจำนวนมาก
- ความถี่ในการอัปเดตสูง
- paa.public.accounts.{ACCOUNT}.เมตาดาต้า
- มีข้อมูลเมตาที่เกี่ยวข้องกับข้อมูลเมตริก เช่นampทดสอบ มอนิเตอร์ หรือ Test Agent ที่เกี่ยวข้องกับเมตริก
- ข้อมูลจำนวนน้อย
- ความถี่ในการอัปเดตต่ำ
เปิดใช้งาน Streaming API
บันทึก: คำแนะนำเหล่านี้จะต้องรันบนเซิร์ฟเวอร์ศูนย์ควบคุมโดยใช้ sudor
เนื่องจาก Streaming API เพิ่มโอเวอร์เฮดบางส่วนให้กับศูนย์ควบคุม จึงไม่ได้เปิดใช้งานตามค่าเริ่มต้น ในการเปิดใช้งาน API ก่อนอื่นเราต้องเปิดใช้งานการเผยแพร่ตัวชี้วัดไปยัง Kafka ในการกำหนดค่าหลัก file:
- /etc/netrounds/netrounds.conf
KAFKA_METRICS_ENABLED = จริง
KAFKA_PUBLISH_METADATA_FOR_STREAMS = จริง
คำเตือน: การเปิดใช้งานคุณลักษณะนี้อาจส่งผลต่อประสิทธิภาพของศูนย์ควบคุม ตรวจสอบให้แน่ใจว่าคุณได้กำหนดขนาดอินสแตนซ์ของคุณตามนั้น
ถัดไป เพื่อเปิดใช้งานการส่งต่อเมตริกเหล่านี้ไปยังหัวข้อคาฟคาที่ถูกต้อง:
- /etc/netrounds/metrics.yaml
สตรีมมิ่ง API: จริง
หากต้องการเปิดใช้งานและเริ่มบริการ Streaming API ให้เรียกใช้:
- บริการ sudo ncc เปิดใช้งานการวัด timescaledb
- บริการ sudo ncc เริ่มต้นการวัดขนาด db
สุดท้าย เริ่มบริการใหม่:
- บริการ sudo ncc เริ่มต้นใหม่
บันทึก: การตั้งค่า KAFKA_PUBLISH_RESOURCES เลิกใช้แล้ว ควรลบออกจากการกำหนดค่าของคุณ ให้ใช้ KAFKA_PUBLISH_METADATA_FOR_STREAMS = True แทน
การตรวจสอบว่า Streaming API ทำงานในศูนย์ควบคุม
บันทึก: คำแนะนำเหล่านี้จะต้องทำงานบนเซิร์ฟเวอร์ศูนย์ควบคุม
ตอนนี้คุณสามารถตรวจสอบว่าคุณได้รับเมตริกในหัวข้อ Kafka ที่ถูกต้องหรือไม่ โดยติดตั้งยูทิลิตี้ Kafka cat:
- sudo apt-get อัพเดต
- sudo apt-get ติดตั้ง kafkacat
หากคุณมีการทดสอบหรือมอนิเตอร์ที่ทำงานอยู่ในศูนย์ควบคุม คุณควรจะสามารถใช้ Kafka cat เพื่อรับเมตริกและข้อมูลเมตาเกี่ยวกับหัวข้อเหล่านี้ได้
แทนที่ 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 จะไม่ถอดรหัสตามค่าเริ่มต้น สำหรับการสมัครสมาชิกหัวข้อเหล่านี้อย่างถูกต้อง โปรดดูที่ "Client Examp“les” ในส่วนหน้า 13
นี่เป็นการยืนยันว่าเรามี 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/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
การสร้างใบรับรองที่จำเป็น
ซึ่งครอบคลุมอยู่ใน “ภาคผนวก” ในหน้า 16
การกำหนดค่า SSL/TLS ของโบรกเกอร์ Kafka ในศูนย์ควบคุม
บันทึก: คำแนะนำเหล่านี้จะต้องทำงานบนเซิร์ฟเวอร์ศูนย์ควบคุม
บันทึก: ก่อนดำเนินการต่อ คุณต้องสร้างคีย์สโตนที่มีใบรับรอง SSL โดยทำตามคำแนะนำใน "ภาคผนวก" ในหน้า 16 เส้นทางที่กล่าวถึงด้านล่างนี้มาจากคำแนะนำเหล่านี้ คีย์สโตร์ SSL คือ file เก็บไว้ในดิสก์ด้วย file นามสกุล .jks
เมื่อคุณสร้างใบรับรองที่จำเป็นสำหรับทั้งนายหน้า Kafka และไคลเอนต์ Kafka แล้ว คุณสามารถดำเนินการต่อโดยกำหนดค่านายหน้า Kafka ที่ทำงานในศูนย์ควบคุม คุณต้องรู้สิ่งต่อไปนี้:
- : ชื่อโฮสต์สาธารณะของศูนย์ควบคุม; สิ่งนี้จะต้องแก้ไขได้และเข้าถึงได้โดยไคลเอนต์ Kafka
- : รหัสผ่านที่เก็บคีย์ที่ให้ไว้เมื่อสร้างใบรับรอง SSL
- และ : นี่คือรหัสผ่านที่คุณต้องการตั้งสำหรับผู้ดูแลระบบและผู้ใช้ไคลเอ็นต์ตามลำดับ โปรดทราบว่าคุณสามารถเพิ่มผู้ใช้เพิ่มเติมได้ ดังที่ระบุไว้ในตัวอย่างนี้ampเล.
แก้ไขหรือเพิ่ม (ด้วยการเข้าถึง sudo) คุณสมบัติด้านล่างนี้ใน /etc/kafka/server.properties โดยแทรกคุณสมบัติข้างต้น
ตัวแปรดังที่แสดง:
คำเตือน: อย่าลบ PLAINTEXT://localhost:9092; สิ่งนี้จะทำให้การทำงานของศูนย์ควบคุมหยุดทำงานเนื่องจากบริการภายในจะไม่สามารถสื่อสารได้
-
# ที่อยู่ที่นายหน้าคาฟคารับฟัง
ผู้ฟัง=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=ธรรมดา
Listener.name.sasl_ssl.plain.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginMo
ครบกำหนดที่จำเป็น \
ชื่อผู้ใช้ =”ผู้ดูแลระบบ” \
รหัสผ่าน=” ” \
ผู้ใช้:admin=” -
ผู้ใช้ไคลเอนต์=” -
# หมายเหตุ สามารถเพิ่มผู้ใช้เพิ่มเติมได้ด้วย user_ =
# การอนุญาต เปิด ACL
authorizer.class.name=kafka.security.authorizer.AclAuthorizer
superusers=ผู้ใช้:ผู้ดูแลระบบ
การตั้งค่ารายการควบคุมการเข้าถึง (ACL)
เปิด ACL บน localhost
คำเตือน: ก่อนอื่นเราต้องตั้งค่า ACL สำหรับ localhost เพื่อให้ Control Center เองยังคงสามารถเข้าถึง Kafka ได้ ถ้าไม่ทำสิ่งต่าง ๆ จะพัง
######### รายการ ACL สำหรับผู้ใช้ที่ไม่ระบุชื่อ
/usr/lib/kafka/bin/kafka-acls.sh \
–ผู้อนุญาต kafka.security.authorizer.AclAuthorizer \
– ผู้อนุญาตคุณสมบัติ Zookeeper.connect=localhost:2181 \
–add –allow-principal ผู้ใช้: ANONYMOUS –allow-host 127.0.0.1 –cluster
/usr/lib/kafka/bin/kafka-acls.sh \
–ผู้อนุญาต kafka.security.authorizer.AclAuthorizer \
– ผู้อนุญาตคุณสมบัติ Zookeeper.connect=localhost:2181 \
– เพิ่ม – อนุญาตผู้ใช้หลัก: ไม่ระบุชื่อ – อนุญาตโฮสต์ 127.0.0.1 – หัวข้อ '*'
/usr/lib/kafka/bin/kafka-acls.sh \
–ผู้อนุญาต kafka.security.authorizer.AclAuthorizer \
– ผู้อนุญาตคุณสมบัติ Zookeeper.connect=localhost:2181 \
–add –allow-principal ผู้ใช้: ANONYMOUS –allow-host 127.0.0.1 –group '*'
จากนั้น เราจำเป็นต้องเปิดใช้งาน ACL สำหรับการเข้าถึงแบบอ่านอย่างเดียวจากภายนอก เพื่อให้ผู้ใช้ภายนอกสามารถอ่านหัวข้อ paa.public.* ได้
บันทึก: สำหรับการควบคุมที่ละเอียดยิ่งขึ้น โปรดดูเอกสาร Kafka อย่างเป็นทางการ
######### รายการ ACL สำหรับผู้ใช้ภายนอก
/usr/lib/kafka/bin/kafka-acls.sh \
–ผู้อนุญาต kafka.security.authorizer.AclAuthorizer \
– ผู้อนุญาตคุณสมบัติ Zookeeper.connect=localhost:2181 \
– เพิ่ม – ผู้ใช้หลักที่อนุญาต:* – การดำเนินการอ่าน – การดำเนินการอธิบาย \
–กลุ่ม 'ป.ป.ช.'
/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} เป็นข้อมูลรับรองผู้ใช้สำหรับไคลเอ็นต์
- รันคำสั่งต่อไปนี้เพื่อดูข้อความที่ 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 สำหรับการอ่านการตั้งค่าไคลเอ็นต์จาก 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.โปรโต”;
แพ็คเกจ 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;
}
}
เมตาโปรโตบัฟสคีมา
ไวยากรณ์ = “proto3”;
แพ็คเกจ paa.streamingapi;
option go_package = “.;paa_streamingapi”;
ข้อมูลเมตาของข้อความ {
int32 stream_id = 1;
สตริง stream_name = 2;
แผนที่ tags = 13;
}
ตัวอย่างลูกค้าampเลส
บันทึก: คำสั่งเหล่านี้มีวัตถุประสงค์เพื่อรันบนไคลเอนต์ภายนอก เช่นampแล็ปท็อปของคุณหรือที่คล้ายกัน และไม่ได้อยู่ในศูนย์ควบคุม
บันทึก: หากต้องการแสดงข้อมูลเมตริก ตรวจสอบให้แน่ใจว่ามีจอภาพอย่างน้อยหนึ่งจอทำงานในศูนย์ควบคุม
tarball ของศูนย์ควบคุมประกอบด้วยไฟล์เก็บถาวร paa-streaming-api-client-examples.tar.gz (ไคลเอนต์-อดีตampเลส) ซึ่งมี exampสคริปต์ Python แสดงวิธีใช้ Streaming API
การติดตั้งและกำหนดค่าไคลเอ็นต์ เช่นampเลส
คุณพบไคลเอนต์-อดีตamples ในโฟลเดอร์ Routing Active Testing Control Center:
ส่งออก CC_VERSION=4.6.0
ซีดี ./paa-control-center_${CC_VERSION}
ls paa-สตรีมมิ่ง-api-ไคลเอนต์-exampเลส*
ในการติดตั้งไคลเอ็นต์-exampไฟล์บนคอมพิวเตอร์ไคลเอ็นต์ภายนอกของคุณ ให้ดำเนินการดังนี้:
# สร้างไดเรกทอรีสำหรับการแยกเนื้อหาของลูกค้าเช่นampเลส ทาร์บอล
mkdir paa-สตรีมมิ่ง-api-ไคลเอนต์-exampเลส
# แยกเนื้อหาของลูกค้าเช่นampเลส ทาร์บอล
tar xzf paa-สตรีมมิ่ง-api-client-examples.tar.gz -C paa-สตรีมมิ่ง-api-client-exampเลส
# ไปที่ไดเร็กทอรีที่สร้างขึ้นใหม่
cd paa-สตรีมมิ่ง-api-client-exampเลส
ลูกค้า-อดีตampไฟล์ต้องการให้นักเทียบท่าทำงาน ดาวน์โหลดและคำแนะนำในการติดตั้งสำหรับ Docker ได้ที่ https://docs.docker.com/engine/install.
การใช้ไคลเอ็นต์เช่นampเลส
ลูกค้า-อดีตampเครื่องมือ les สามารถทำงานในโหมดพื้นฐานหรือขั้นสูงเพื่อสร้าง exampความซับซ้อนที่แตกต่างกัน ในทั้งสองกรณี คุณสามารถเรียกใช้ ex ได้เช่นกันampด้วยการกำหนดค่า file มีคุณสมบัติเพิ่มเติมสำหรับการปรับแต่งเพิ่มเติมของฝั่งไคลเอ็นต์
โหมดพื้นฐาน
ในโหมดพื้นฐาน เมตริกและข้อมูลเมตาจะถูกสตรีมแยกกัน ด้วยเหตุนี้ ลูกค้าจะรับฟังแต่ละหัวข้อของ Kafka ที่สามารถเข้าถึงได้จากภายนอก และเพียงพิมพ์ข้อความที่ได้รับไปยังคอนโซล
เพื่อเริ่มการดำเนินการของอดีตพื้นฐานampเลย, วิ่ง:
./build.sh run-basic –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME
โดยที่ ACCOUNT_SHORTNAME คือชื่อย่อของบัญชีที่คุณต้องการรับเมตริก
เพื่อยุติการบังคับคดีของอดีตampจากนั้นกด Ctrl + C (อาจมีการหน่วงเวลาเล็กน้อยก่อนที่การดำเนินการจะหยุดลง เนื่องจากไคลเอนต์รอเหตุการณ์การหมดเวลา)
โหมดขั้นสูง
บันทึก: เมตริกจะแสดงเฉพาะสำหรับจอภาพ HTTP ที่ทำงานในศูนย์ควบคุม
การดำเนินการในโหมดขั้นสูงแสดงความสัมพันธ์ระหว่างเมตริกและข้อความข้อมูลเมตา สิ่งนี้เกิดขึ้นได้เนื่องจากการมีอยู่ในแต่ละข้อความเมตริกของช่องรหัสสตรีมซึ่งอ้างถึงข้อความข้อมูลเมตาที่สอดคล้องกัน
เพื่อดำเนินการขั้นสูงเช่นampเลย, วิ่ง:
./build.sh run-advanced –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME
โดยที่ ACCOUNT_SHORTNAME คือชื่อย่อของบัญชีที่คุณต้องการรับเมตริก
เพื่อยุติการบังคับคดีของอดีตampจากนั้นกด Ctrl + C (อาจมีการหน่วงเวลาเล็กน้อยก่อนที่การดำเนินการจะหยุดลง เนื่องจากไคลเอนต์รอเหตุการณ์การหมดเวลา)
การตั้งค่าเพิ่มเติม
เป็นไปได้ที่จะเรียกใช้อดีตampด้วยการกำหนดค่าเพิ่มเติมของไคลเอ็นต์โดยใช้ –config-file ตัวเลือกตามด้วย file ชื่อที่มีคุณสมบัติในรูปแบบ key=value
./build.sh วิ่งขั้นสูง \
–kafka-โบรกเกอร์ localhost:9092 \
–บัญชี ACCOUNT_SHORTNAME \
–กำหนดค่า-file client_config.properties
บันทึก: ทั้งหมด fileการอ้างอิงในคำสั่งด้านบนต้องอยู่ในไดเร็กทอรีปัจจุบันและอ้างอิงโดยใช้พาธสัมพัทธ์เท่านั้น สิ่งนี้ใช้ได้ทั้งกับ –config-file อาร์กิวเมนต์และรายการทั้งหมดในการกำหนดค่า file ที่อธิบาย file สถานที่
การตรวจสอบความถูกต้องของไคลเอนต์ภายนอก
ในการตรวจสอบความถูกต้องของไคลเอนต์จากภายนอกศูนย์ควบคุมโดยใช้ไคลเอนต์-อดีตampให้ทำตามขั้นตอนต่อไปนี้:
- จากโฟลเดอร์ Routing Active Testing Control Center ให้สลับไปที่ paa-streaming-api-client-exampโฟลเดอร์ไฟล์:
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 ลูกค้า.คุณสมบัติ
โดยที่ ACCOUNT_SHORTNAME คือชื่อย่อของบัญชีที่คุณต้องการรับเมตริก - เรียกใช้ขั้นสูง เช่นampเลส:
ส่งออก KAFKA_FQDN=
./build.sh run-advanced –kafka-brokers ${KAFKA_FQDN}:9093 \
–บัญชี ACCOUNT_SHORTNAME
–กำหนดค่า-file ลูกค้า.คุณสมบัติ
ภาคผนวก
ในภาคผนวกนี้ เราจะอธิบายวิธีการสร้าง:
- ที่เก็บกุญแจ file สำหรับจัดเก็บใบรับรอง SSL ของโบรกเกอร์ Kafka
- ร้านค้าที่เชื่อถือได้ file สำหรับจัดเก็บใบรับรองหลักของผู้ออกใบรับรอง (CA) ที่ใช้ในการลงนามใบรับรองนายหน้าคาฟคา
การสร้างใบรับรองนายหน้าคาฟคา
การสร้างใบรับรองโดยใช้ผู้ออกใบรับรองจริง (แนะนำ)
ขอแนะนำให้คุณได้รับใบรับรอง SSL จริงจาก CA ที่เชื่อถือได้
เมื่อคุณตัดสินใจเลือก CA แล้ว ให้คัดลอกใบรับรอง CA หลัก ca-cert file สู่เส้นทางของตนเองดังภาพต่อไปนี้
ส่งออก CA_PATH=~/my-ca
mkdir ${CA_PATH}
ซีพี ใบรับรอง ca ${CA_PATH}
สร้างผู้ออกใบรับรองของคุณเอง
บันทึก: โดยปกติคุณควรให้ใบรับรองของคุณลงนามโดยผู้ออกใบรับรองตัวจริง ดูส่วนย่อยก่อนหน้านี้ ที่ตามมาก็แค่แฟนเก่าampเล.
ที่นี่เราสร้างใบรับรองหลักของผู้ออกใบรับรอง (CA) ของเราเอง file มีอายุ 999 วัน (ไม่แนะนำในการผลิต):
# สร้างไดเร็กทอรีสำหรับจัดเก็บ CA
ส่งออก CA_PATH=~/my-ca
mkdir ${CA_PATH}
# สร้างใบรับรอง CA
openssl req - ใหม่ -x509 -keyout ${CA_PATH}/ca-key -out ${CA_PATH}/ca-cert -วัน 999
การสร้าง Client Truststore
ตอนนี้คุณสามารถสร้าง truststore file ที่มี ca-cert ที่สร้างขึ้นด้านบน นี้ file จะต้องมีไคลเอนต์ Kafka ที่จะเข้าถึง Streaming API: keytool -keystore kafka.client.truststore.jks \
-นามแฝง CARoot \
-ใบรับรองนำเข้า-file ${CA_PATH}/ca-ใบรับรอง
เมื่อใบรับรอง CA อยู่ใน truststore แล้ว ไคลเอ็นต์จะเชื่อถือใบรับรองใดๆ ที่ลงนามด้วย
คุณควรคัดลอกไฟล์ file kafka.client.truststore.jks ไปยังตำแหน่งที่รู้จักในคอมพิวเตอร์ไคลเอนต์ของคุณ และชี้ไปที่ตำแหน่งนั้นในการตั้งค่า
การสร้างที่เก็บคีย์สำหรับนายหน้าคาฟคา
หากต้องการสร้างใบรับรอง SSL ของโบรกเกอร์ Kafka และที่เก็บคีย์ kafka.server.keystore.jks ให้ดำเนินการดังนี้:
การสร้างใบรับรอง SSL
ใช้คำสั่งเหล่านี้เพื่อสร้างใบรับรอง SSL ด้านล่าง 999 คือจำนวนวันที่คีย์สโตร์ใช้งานได้
sudo mkdir -p /var/ssl/private.php
sudo chown -R $USER: /var/ssl/private
ซีดี /var/ssl/private.cd
ส่งออก CC_IP=
keytool -keystore kafka.server.keystore.jks \
-เซิร์ฟเวอร์นามแฝง \
-ความถูกต้อง 999\
-genkey -keyalg RSA -ext SAN=ip:${CC_IP}
ในการตรวจสอบใบรับรอง SSL คุณสามารถใช้คำสั่งต่อไปนี้:
keytool -v -list -keystore kafka.server.keystore.jks -alias เซิร์ฟเวอร์
คุณควรตรวจสอบให้แน่ใจว่าพอร์ต 9093 สามารถเข้าถึงได้จากไคลเอนต์ภายนอก
สร้างคำขอลงนามใบรับรองและจัดเก็บไว้ใน file ชื่อ cert-server-request:
keytool -keystore kafka.server.keystore.jks \
-เซิร์ฟเวอร์นามแฝง \
-certreq \
-file ใบรับรองเซิร์ฟเวอร์คำขอ
ตอนนี้คุณควรส่ง file cert-server-request ไปยังผู้ออกใบรับรอง (CA) ของคุณ หากคุณใช้งานจริง จากนั้นพวกเขาจะส่งคืนใบรับรองที่ลงนามแล้ว เราจะเรียกสิ่งนี้ว่าลงนามโดยเซิร์ฟเวอร์ใบรับรองด้านล่าง
การลงนามใบรับรอง SSL โดยใช้ใบรับรอง CA ที่สร้างขึ้นเอง
บันทึก: ขอย้ำอีกครั้งว่าไม่แนะนำให้ใช้ CA ของคุณเองในระบบที่ใช้งานจริง
ลงนามใบรับรองโดยใช้ CA โดยวิธีการของ file cert-server-request ซึ่งสร้างใบรับรองที่ลงชื่อ cert-server-signed ดูด้านล่าง; ca-password เป็นรหัสผ่านที่ตั้งไว้เมื่อสร้างใบรับรอง CA
ซีดี /var/ssl/private.cd
openssl x509 -req \
- -CA ${CA_PATH}/ca-cert \
- -CAkey ${CA_PATH}/ca-คีย์ \
- - ในใบรับรองเซิร์ฟเวอร์คำขอ \
- - ออกใบรับรองเซิร์ฟเวอร์ที่ลงนาม \
- -วัน 999 -CAcreateserial \
- -passin ผ่าน:{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 สำหรับ Streaming API มีดังนี้ โดยที่ %s เป็นชื่อย่อของบัญชี Control Center (ระบุเมื่อสร้างบัญชี):
ค่าคงที่ (
ชื่อผู้ส่งออก = “คาฟคา”
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 ศูนย์ควบคุม
ประการแรกมีอดีตขั้นพื้นฐานample สาธิตวิธีการสตรีมเมทริกและข้อมูลเมตาแยกกัน และเพียงพิมพ์ข้อความที่ได้รับไปยังคอนโซล คุณสามารถรันได้ดังนี้:
sudo ./build.sh run-basic –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME นอกจากนี้ยังมี ex ขั้นสูงอีกด้วย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 ขอสงวนสิทธิ์ในการเปลี่ยนแปลง ดัดแปลง ถ่ายโอน หรือแก้ไขสิ่งพิมพ์นี้โดยไม่ต้องแจ้งให้ทราบล่วงหน้า ลิขสิทธิ์ © 2025 จูนิเปอร์ เน็ตเวิร์กส์,
Inc. สงวนลิขสิทธิ์
เอกสาร / แหล่งข้อมูล
 |
ข้อมูลสรุปโซลูชันการทดสอบเชิงรุกของ JUNIPER NETWORKS Routing [พีดีเอฟ] คู่มือการใช้งาน สรุปโซลูชันการทดสอบแบบแอคทีฟ, สรุปโซลูชันการทดสอบแบบแอคทีฟ, สรุปโซลูชันการทดสอบ, สรุปโซลูชัน |