البساطة الهندسية
دليل دفق API

مقدمة

يصف هذا الدليل كيفية استخراج البيانات من Paragon Active Assurance عبر واجهة برمجة تطبيقات دفق المنتج.
يتم تضمين API وكذلك عميل البث في تثبيت Paragon Active Assurance.
ومع ذلك ، هناك حاجة إلى القليل من التكوين قبل أن تتمكن من استخدام واجهة برمجة التطبيقات. هذا مغطى في "تكوين Streaming API" في الصفحة 1 الفصل.

زيادةview

يصف هذا الفصل كيفية تكوين Streaming API للسماح بالاشتراك في رسائل المقاييس عبر كافكا.
أدناه سوف نذهب من خلال:

• كيفية تمكين Streaming API
• كيفية تكوين كافكا للاستماع للعملاء الخارجيين
• كيفية تكوين كافكا لاستخدام قوائم التحكم في الوصول وإعداد تشفير SSL للعملاء المذكورين

ما هو كافكا؟

كافكا عبارة عن نظام أساسي لدفق الأحداث يسمح بالتقاط البيانات المرسلة في الوقت الفعلي من مصادر الأحداث المختلفة (أجهزة الاستشعار وقواعد البيانات والأجهزة المحمولة) في شكل تدفقات الأحداث ، فضلاً عن التخزين الدائم لتدفقات الأحداث هذه لاسترجاعها ومعالجتها لاحقًا.
مع كافكا ، من الممكن إدارة تدفق الحدث من طرف إلى طرف بطريقة موزعة ، وقابلة للتطوير بدرجة عالية ، ومرنة ، ومتسامحة مع الأخطاء ، وآمنة.
ملحوظة: يمكن تكوين كافكا بعدة طرق مختلفة وقد تم تصميمه لقابلية التوسع والأنظمة الزائدة عن الحاجة. يركز هذا المستند فقط على كيفية تكوينه للاستفادة من ميزة Streaming API الموجودة في Paragon Active Assurance Control Center. لمزيد من الإعدادات المتقدمة ، نشير إلى وثائق كافكا الرسمية: kafka.apache.org/26/documentation.html.

مصطلحات

• كافكا: منصة بث الأحداث.
• موضوع كافكا: مجموعة من الأحداث.
• مشترك / مستهلك كافكا: مكون مسؤول عن استرجاع الأحداث المخزنة في موضوع كافكا.
• وسيط كافكا: خادم طبقة التخزين لمجموعة كافكا.
• SSL / TLS: بروتوكول SSL هو بروتوكول آمن تم تطويره لإرسال المعلومات بأمان عبر الإنترنت. TLS هو خليفة SSL ، الذي تم تقديمه في 1999.
• SASL: إطار يوفر آليات لمصادقة المستخدم وفحص تكامل البيانات والتشفير.
• مشترك دفق API: مكون مسؤول عن استرجاع الأحداث المخزنة في الموضوعات المحددة في Paragon Active Assurance والمخصصة للوصول الخارجي.
• المرجع المصدق: كيان موثوق به يصدر شهادات المفاتيح العامة ويلغيها.
• الشهادة الجذر للمرجع المصدق: شهادة المفتاح العام التي تحدد المرجع المصدق.

كيف يعمل Streaming API

كما ذكرنا سابقًا ، تسمح واجهة برمجة التطبيقات Streaming API للعملاء الخارجيين باسترداد معلومات حول المقاييس من كافكا.
يتم إرسال جميع المقاييس التي تم جمعها بواسطة وكلاء الاختبار أثناء مهمة الاختبار أو المراقبة إلى خدمة البث.
بعد مرحلة المعالجة ، تنشر خدمة البث تلك المقاييس على كافكا جنبًا إلى جنب مع البيانات الوصفية الإضافية.

مواضيع كافكا

كافكا لديه مفهوم الموضوعات التي يتم نشر جميع البيانات عليها. يتوفر في Paragon Active Assurance العديد من موضوعات كافكا ؛ ومع ذلك ، فقط مجموعة فرعية من هذه مخصصة للوصول الخارجي.
يحتوي كل حساب Paragon Active Assurance في مركز التحكم على موضوعين مخصصين. أدناه ، ACCOUNT هو الاسم المختصر للحساب:

• paa.public.accounts. {ACCOUNT} .metrics
• يتم نشر جميع رسائل المقاييس للحساب المحدد في هذا الموضوع
• كميات كبيرة من البيانات
• تردد تحديث عالي
• paa.public.accounts. {ACCOUNT} .metadata
• يحتوي على البيانات الوصفية المتعلقة ببيانات المقاييس ، على سبيل المثالampفي الاختبار أو المراقبة أو وكيل الاختبار المرتبط بالمقاييس
• كميات صغيرة من البيانات
• تردد تحديث منخفض

تمكين دفق API

ملحوظة: يجب تشغيل هذه التعليمات على خادم مركز التحكم باستخدام sudo.
نظرًا لأن Streaming API تضيف بعض النفقات العامة إلى مركز التحكم ، فلا يتم تمكينها افتراضيًا. لتمكين واجهة برمجة التطبيقات ، يجب علينا أولاً تمكين نشر المقاييس على كافكا في التكوين الرئيسي file:

• /etc/netrounds/netrounds.conf
  KAFKA_METRICS_ENABLED = صحيح
  تحذير: قد يؤثر تمكين هذه الميزة على أداء مركز التحكم. تأكد من تحديد أبعاد المثيل الخاص بك وفقًا لذلك.
  بعد ذلك ، لتمكين إعادة توجيه هذه المقاييس إلى موضوعات كافكا الصحيحة:
• /etc/netrounds/metrics.yaml
  تدفق API: صحيح

لتمكين خدمات واجهة برمجة التطبيقات المتدفقة وبدء تشغيلها ، قم بتشغيل:
sudo ncc services enable timescaledb metrics sudo ncc services start timescaledb metrics
أخيرًا ، أعد تشغيل الخدمات:
إعادة تشغيل خدمات sudo ncc

التحقق من أن Streaming API يعمل في مركز التحكم

ملحوظة: يجب تشغيل هذه التعليمات على خادم مركز التحكم.
يمكنك الآن التحقق من أنك تتلقى مقاييس حول موضوعات كافكا الصحيحة. للقيام بذلك ، قم بتثبيت الأداة المساعدة kafkacat:
sudo apt-get update sudo apt-get install kafkacat
إذا كان لديك اختبار أو شاشة تعمل في مركز التحكم ، فيجب أن تكون قادرًا على استخدام kafkacat لتلقي المقاييس والبيانات الوصفية حول هذه الموضوعات.
استبدل حسابي بالاسم المختصر لحسابك (هذا ما تراه في مركز التحكم الخاص بك 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 metadata ، قم بتشغيل الأمر التالي (لاحظ أن هذا لن يتم تحديثه بشكل متكرر):
kafkacat -b $ {KAFKA_FQDN}: 9092 -t $ {METADATA_TOPIC} -C -e
ملحوظة:
kafkacat ”Client Examples "في الصفحة 14
هذا يتحقق من أن لدينا واجهة برمجة تطبيقات دفق عاملة من داخل مركز التحكم. ومع ذلك ، فأنت على الأرجح مهتم بالوصول إلى البيانات من عميل خارجي بدلاً من ذلك. يصف القسم التالي كيفية فتح كافكا للوصول الخارجي.

فتح كافكا للمضيفين الخارجيين

ملحوظة: يجب تشغيل هذه التعليمات على خادم مركز التحكم.
افتراضيًا ، يتم تكوين كافكا الذي يعمل على مركز التحكم للاستماع فقط على المضيف المحلي للاستخدام الداخلي.
من الممكن فتح كافكا للعملاء الخارجيين من خلال تعديل إعدادات كافكا.
الاتصال بكافكا: محاذير
حذر: من فضلك اقرأ هذا بعناية ، لأنه من السهل أن تواجه مشكلات في الاتصال بكافكا إذا لم تكن قد فهمت هذه المفاهيم.
في إعداد مركز التحكم الموضح في هذا المستند ، لا يوجد سوى وسيط كافكا واحد.
ومع ذلك ، لاحظ أن وسيط كافكا من المفترض أن يعمل كجزء من مجموعة كافكا التي قد تتكون من العديد من وسطاء كافكا.
عند الاتصال بسمسار كافكا ، يتم إعداد اتصال أولي بواسطة عميل كافكا. من خلال هذا الصدد ، سيعيد وسيط كافكا بدوره قائمة "المستمعين المُعلنين" ، وهي قائمة بواحد أو أكثر من وسطاء كافكا.
عند استلام هذه القائمة ، سينقطع اتصال عميل كافكا ، ثم يعيد الاتصال بأحد هؤلاء المستمعين المُعلن عنه. يجب أن يحتوي المستمعون المعلنون على أسماء مضيفين أو عناوين IP يمكن الوصول إليها من قبل عميل كافكا ، وإلا سيفشل العميل في الاتصال.
إذا تم استخدام تشفير SSL ، والذي يتضمن شهادة SSL مرتبطة باسم مضيف معين ، فمن الأهمية بمكان أن يتلقى عميل كافكا العنوان الصحيح للاتصال به ، لأنه بخلاف ذلك قد يتم رفض الاتصال.
اقرأ المزيد عن مستمعي كافكا هنا: www.confluent.io/blog/kafka-listeners-explained
تشفير SSL/TLS
للتأكد من السماح للعملاء الموثوق بهم فقط بالوصول إلى كافكا وواجهة برمجة تطبيقات البث ، يجب علينا تكوين ما يلي:

• المصادقة: يجب على العملاء تقديم اسم المستخدم وكلمة المرور من خلال اتصال آمن SSL / TLS بين العميل و Kafka.
• التفويض: يمكن للعملاء المصادق عليهم أداء المهام التي تنظمها قوائم ACL.
  هنا هو أكثرview:

*) يتم إجراء مصادقة اسم المستخدم / كلمة المرور على قناة مشفرة باستخدام بروتوكول SSL
لفهم كيفية عمل تشفير SSL / TLS لكافكا تمامًا ، يرجى الرجوع إلى الوثائق الرسمية: docs.confluent.io/platform/current/kafka/encryption.html
انتهت شهادة SSL / TLSview
ملحوظة: سنستخدم في هذا القسم الفرعي المصطلحات التالية:
الشهادة: شهادة SSL موقعة من المرجع المصدق (CA). كل وسيط كافكا لديه واحد.
مخزن المفاتيح: مخزن المفاتيح file الذي يخزن الشهادة. مخزن المفاتيح file يحتوي على المفتاح الخاص للشهادة ؛ لذلك ، يجب أن يتم الاحتفاظ بها بأمان.
متجر الثقة: A file تحتوي على شهادات CA الموثوقة.
لإعداد المصادقة بين عميل خارجي و كافكا يعملان في مركز التحكم ، يجب أن يكون لدى كلا الجانبين مخزن مفاتيح محدد بشهادة ذات صلة موقعة من قبل المرجع المصدق (CA) مع شهادة جذر المرجع المصدق (CA).
بالإضافة إلى ذلك ، يجب أن يكون لدى العميل أيضًا Truststore مع شهادة جذر المرجع المصدق (CA).
شهادة جذر المرجع المصدق (CA) شائعة بين وسيط كافكا وعميل كافكا.
إنشاء الشهادات المطلوبة
هذا مغطى في "الملحق" في الصفحة 17.
تهيئة Kafka Broker SSL / TLS في مركز التحكم
ملحوظة: يجب تشغيل هذه التعليمات على خادم مركز التحكم.
ملحوظة: قبل المتابعة ، يجب عليك إنشاء ملف تخزين المفاتيح الذي يحتوي على شهادة SSL باتباع الإرشادات الموجودة في "الملحق" في الصفحة 17. تأتي المسارات المذكورة أدناه من هذه الإرشادات.
مخزن مفاتيح SSL هو ملف file المخزنة على القرص بامتداد file التمديد .jks.
بمجرد حصولك على الشهادات المطلوبة التي تم إنشاؤها لكل من وسيط Kafka وعميل Kafka ، يمكنك المتابعة من خلال تكوين وسيط Kafka الذي يعمل في Control Center. تحتاج إلى معرفة ما يلي:

• : اسم المضيف العام لمركز التحكم ؛ يجب أن يكون هذا قابلاً للحل ويمكن الوصول إليه من قبل عملاء كافكا.
• : كلمة مرور تخزين المفاتيح المقدمة عند إنشاء شهادة SSL.
• و :هذه هي كلمات المرور التي تريد تعيينها لمستخدم المسؤول ومستخدم العميل على التوالي.
  لاحظ أنه يمكنك إضافة المزيد من المستخدمين، كما هو موضح في المثالampليه.
  قم بتحرير أو إلحاق (مع وصول sudo) الخصائص أدناه في /etc/kafka/server.properties ، مع إدخال المتغيرات المذكورة أعلاه كما هو موضح:

تحذير: لا تقم بإزالة PLAINTEXT://localhost:9092؛ سيؤدي هذا إلى تعطيل وظيفة مركز التحكم نظرًا لأن الخدمات الداخلية لن تكون قادرة على التواصل.
...# العناوين التي يستمع إليها وسيط Kafka.
المستمعون = PLAINTEXT: // localhost: 9092، SASL_SSL: //0.0.0.0: 9093
# هذه هي المضيفات التي تم الإعلان عنها مرة أخرى لأي عميل متصل.
المعلن. المستمعين=PLAINTEXT://localhost:9092,SASL_SSL:// :9093…
####### تهيئة مخصصة
# تكوين SSL
ssl.endpoint.identification.algorithm =
ssl.keystore.location = / var / ssl / private / kafka.server.keystore.jks
ssl.keystore.password =
ssl.key.password =
ssl.client.auth = لا شيء
ssl.protocol = TLSv1.2
# تكوين SASL sasl.enabled.mechanisms=PLAIN
المستمع.اسم.sasl_ssl.plain.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginMo مطلوب \ اسم المستخدم = "admin" \ كلمة المرور = " ” \ user_admin=” ” \ user_client=” "# ملاحظة: يمكن إضافة المزيد من المستخدمين باستخدام user_ =
# التفويض، قم بتشغيل قوائم التحكم في الوصول authorizer.class.name=kafka.security.authorizer.AclAuthorizer super.users=User:admin
إعداد قوائم التحكم في الوصول (ACL)
تشغيل ACLs على المضيف المحلي
تحذير: يجب علينا أولاً إعداد قوائم ACL للمضيف المحلي ، بحيث يظل بإمكان مركز التحكم نفسه الوصول إلى كافكا. إذا لم يتم ذلك ، فسوف تنكسر الأشياء.
######### إدخالات قوائم التحكم في الوصول للمستخدمين المجهولين
/usr/lib/kafka/bin/kafka-acls.sh \
–authorizer kafka.security.authorizer.AclAuthorizer \ –authorizer-properties zookeeper.connect=localhost:2181 \ –add –allow-principal المستخدم: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 المستخدم: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 المستخدم: ANONYMOUS –allow-host 127.0.0.1 –group '*'
نحتاج بعد ذلك إلى تمكين قوائم التحكم في الوصول (ACL) للوصول الخارجي للقراءة فقط ، بحيث يُسمح للمستخدمين الخارجيين بقراءة المواضيع paa.public. *.
ملحوظة: لمزيد من التحكم الدقيق ، يرجى الرجوع إلى وثائق كافكا الرسمية.
######### إدخالات قوائم التحكم في الوصول (ACL) للمستخدمين الخارجيين
/usr/lib/kafka/bin/kafka-acls.sh \
–authorizer kafka.security.authorizer.AclAuthorizer \–authorizer-properties zookeeper.connect=localhost:2181 \
–add –allow-principal المستخدم:* –operation read –operation describe \–group 'NCC'
/usr/lib/kafka/bin/kafka-acls.sh \
- المصرح kafka.security.authorizer.AclAuthorizer \
–authorizer-properties zookeeper.connect = localhost: 2181 \
- إضافة - السماح للمستخدم الرئيسي: * - قراءة التشغيل - وصف العملية \
–topic paa.p public. - نوع نمط المورد مسبوق
بمجرد الانتهاء من ذلك ، تحتاج إلى إعادة تشغيل الخدمات:
إعادة تشغيل خدمات sudo ncc
للتحقق من أن العميل يمكنه إنشاء اتصال آمن ، قم بتشغيل الأمر التالي على كمبيوتر عميل خارجي (وليس على خادم مركز التحكم). أدناه ، PUBLIC_HOSTNAME هو اسم مضيف مركز التحكم:
openssl s_client -debug -connect $ {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 في
مركز التحكم: أي 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. .metrics
  kafkacat -b $ {KAFKA_FQDN}: 9093 -F client.properties -t $ {METRICS_TOPIC} -C -e
  حيث {METRICS_TOPIC} هو اسم موضوع كافكا بالبادئة "paa.public.".

ملحوظة: لا توفر الإصدارات القديمة من kafkacat الخيار -F لقراءة إعدادات العميل من ملف file. إذا كنت تستخدم مثل هذا الإصدار ، فيجب عليك توفير نفس الإعدادات من سطر الأوامر كما هو موضح أدناه.
kafkacat -b $ {KAFKA_FQDN}: 9093 \
-X security.protocol = SASL_SSL \
-X ssl.ca.location = {PATH_TO_CA_CERT} \
-X sasl.mechanisms = سهل \
-X sasl.username = {CLIENT_USER} \
-X sasl.password = {CLIENT_PASSWORD} \
-t $ {METRICS_TOPIC} -C -e
لتصحيح الاتصال ، يمكنك استخدام الخيار -d:
تصحيح أخطاء اتصالات المستهلك
kafkacat -d Consumer -b $ {KAFKA_FQDN}: 9093 -F client.properties -t $ {METRICS_TOPIC} -C -e
# اتصالات وسيط التصحيح
kafkacat -d broker -b $ {KAFKA_FQDN}: 9093 -F client.properties -t $ {METRICS_TOPIC} -C -e
تأكد من الرجوع إلى الوثائق الخاصة بمكتبة عميل كافكا المستخدمة ، حيث قد تختلف الخصائص عن تلك الموجودة في client.properties.

تنسيق الرسالة

يتم تسلسل الرسائل المستخدمة للقياسات وموضوعات البيانات الوصفية في تنسيق المخازن المؤقتة للبروتوكول (بروتوبوف) (انظر developer.google.com/protocol-buffers). المخططات الخاصة بهذه الرسائل تلتزم بالتنسيق التالي:
مقاييس مخطط Protobuf
بناء الجملة = “proto3”؛ استيراد “google/protobuf/timestamp.proto”; حزمة paa.streamingapi؛ الخيار go_package = “.;paa_streamingapi”؛ الرسالة المقاييس { google.protobuf.Timestamp توقيتamp = 1; خريطة القيم = 2؛ int32 measurement_id = 3؛ } /** * يمكن أن تكون قيمة المقياس عددًا صحيحًا أو عددًا عشريًا. */
الرسالة MetricValue { oneof type { int64 int_val = 1; float float_val = 2; } }
مخطط Protobuf للبيانات الوصفية
syntax = “proto3”; package paa.streamingapi; option go_package = “.;paa_streamingapi”; message البيانات الوصفية { int32 measurement_id = 1; string measurement_name = 2; map tags = 13؛ }

العميل السابقampليه

ملحوظة: تهدف هذه الأوامر للتشغيل على عميل خارجي ، على سبيل المثالampلو الكمبيوتر المحمول الخاص بك أو ما شابه ، وليس في مركز التحكم.
ملحوظة: لعرض معلومات المقاييس ، تأكد من تشغيل جهاز عرض واحد على الأقل في مركز التحكم.
تتضمن كرة تار مركز التحكم أرشيف paa-streaming-api-client-examples.tar.gz (العميل السابقamples) ، والتي تحتوي على exampيوضح البرنامج النصي le Python كيفية استخدام واجهة برمجة تطبيقات البث.
تثبيت وتكوين العميل السابقampليه
تجد العميل السابقamples في مجلد Paragon Active Assurance Control Center:
تصدير CC_VERSION = 3.3.1
cd ./paa-control-center_${CC_VERSION} ls paa-streaming-api-client-exampليه *
لتثبيت برنامج client-exampعلى جهاز الكمبيوتر العميل الخارجي ، تابع ما يلي:
# إنشاء دليل لاستخراج محتوى العميل على سبيل المثالampملف tarball mkdir paa-streaming-api-client-exampليه
# استخراج محتوى العميل السابقينampملف tarball 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ليه متفاوتة التعقيد. في كلتا الحالتين ، من الممكن أيضًا تشغيل exampليه مع التكوين file تحتوي على خصائص إضافية لمزيد من التخصيص من جانب العميل.
الوضع الأساسي في الوضع الأساسي، يتم بث المقاييس وبياناتها الوصفية بشكل منفصل. ولتحقيق هذه الغاية، يستمع العميل إلى كل موضوع Kafka متاح للوصول الخارجي ويطبع الرسائل المستلمة ببساطة على وحدة التحكم.
لبدء تنفيذ ex الأساسيamples، قم بتشغيل: ./build.sh run-basic –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME
حيث ACCOUNT_SHORTNAME هو الاسم المختصر للحساب الذي تريد الحصول على المقاييس منه.
لإنهاء تنفيذ السابقample ، اضغط على Ctrl + C. (قد يكون هناك تأخير بسيط قبل أن يتوقف التنفيذ لأن العميل ينتظر حدث انتهاء المهلة.)
الوضع المتقدم
ملحوظة: يتم عرض المقاييس فقط لشاشات HTTP التي تعمل في مركز التحكم.
يُظهر التنفيذ في الوضع المتقدم الارتباط بين المقاييس ورسائل البيانات الوصفية. هذا ممكن بفضل التواجد في كل رسالة مقاييس لحقل معرف التدفق الذي يشير إلى رسالة البيانات الوصفية المقابلة.
لتنفيذ ex المتقدمamples، قم بتشغيل: ./build.sh run-advanced –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME حيث ACCOUNT_SHORTNAME هو الاسم المختصر للحساب الذي تريد الحصول على المقاييس منه.
لإنهاء تنفيذ السابقample ، اضغط على Ctrl + C. (قد يكون هناك تأخير بسيط قبل أن يتوقف التنفيذ لأن العميل ينتظر حدث انتهاء المهلة.)
الإعدادات الإضافية
من الممكن تشغيل السابقamples مع تكوين إضافي للعميل باستخدام –config-file الخيار الذي يليه أ file الاسم الذي يحتوي على خصائص في مفتاح النموذج = القيمة.
./build.sh run-advanced \ –kafka-brokers localhost:9092 \ –account ACCOUNT_SHORTNAME \ –config-file client_config.properties
ملحوظة: الجميع fileيجب وضع s المشار إليه في الأمر أعلاه في الدليل الحالي والإشارة إليه باستخدام المسارات النسبية فقط. ينطبق هذا على كل من –config-file حجة وجميع الإدخالات في التكوين file هذا الوصف file المواقع.
التحقق من مصادقة العميل الخارجي
للتحقق من مصادقة العميل من خارج مركز التحكم باستخدام client-examples ، قم بتنفيذ الخطوات التالية:

• من مجلد Paragon Active Assurance Control Center ، قم بالتبديل إلى paa-streaming-api-clientexampمجلد les:
  cd paa-streaming-api-client-exampليه
• انسخ شهادة CA الجذر 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} هما بيانات اعتماد المستخدم للعميل.
• قم بتشغيل Basic exampليه:
  تصدير KAFKA_FQDN= ./build.sh تشغيل أساسي –kafka-brokers ${KAFKA_FQDN}:9093 \ –account ACCOUNT_SHORTNAME
  - تكوين-file client.properties حيث ACCOUNT_SHORTNAME هو الاسم المختصر للحساب الذي تريد الحصول على المقاييس منه.
• تشغيل متقدم على سبيل المثالampليه:
  تصدير KAFKA_FQDN= ./build.sh تشغيل متقدم –kafka-brokers ${KAFKA_FQDN}:9093 \ –account ACCOUNT_SHORTNAME–config-file العميل

زائدة

في هذا الملحق ، نصف كيفية الإنشاء:

• مفتاح file لتخزين شهادة SSL للوسيط كافكا
• متجر Truststore file لتخزين شهادة جذر المرجع المصدق (CA) المستخدمة لتوقيع شهادة وسيط كافكا.

إنشاء شهادة وسيط كافكا
إنشاء شهادة باستخدام مرجع مصدق حقيقي (موصى به)
يوصى بالحصول على شهادة SSL حقيقية من مرجع مصدق موثوق به.
بمجرد اتخاذ قرار بشأن المرجع المصدق ، انسخ شهادة جذر المرجع المصدق (CA) الخاصة بهم file لمسارك الخاص كما هو موضح أدناه:
تصدير CA_PATH=~/my-ca mkdir ${CA_PATH} cp ca-cert ${CA_PATH}
قم بإنشاء المرجع المصدق الخاص بك
ملحوظة: عادة يجب أن تكون شهادتك موقعة من قبل سلطة تصديق حقيقية ؛ انظر القسم الفرعي السابق. ما يلي هو مجرد سابقampليه.
هنا نقوم بإنشاء شهادة الجذر الخاصة بالمرجع المصدق (CA) الخاص بنا file صالحة لمدة 999 يومًا (غير موصى بها في الإنتاج):
# إنشاء دليل لتخزين CA export 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 سيحتاجه عميل كافكا الذي سيصل إلى واجهة برمجة تطبيقات البث:
keytool -keystore kafka.client.truststore.jks \ -alias CARoot \ -importcert -file $ {CA_PATH} / ca-cert
الآن بعد أن أصبحت شهادة CA في Truststore ، سيثق العميل في أي شهادة موقعة معها.
يجب عليك نسخ ملف file kafka.client.truststore.jks إلى موقع معروف على جهاز الكمبيوتر العميل وأشر إليه في الإعدادات.
إنشاء Keystore لوسيط كافكا
لإنشاء شهادة SSL للوسيط كافكا ثم ملف تخزين المفاتيح kafka.server.keystore.jks ، تابع كما يلي:
إنشاء شهادة SSL
أدناه ، 999 هو عدد أيام صلاحية مخزن المفاتيح ، و 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 \ -alias server \ -validity 999 \ -genkey -keyalg RSA -ext SAN=dns:${FQDN}
أنشئ طلب توقيع شهادة وقم بتخزينه في ملف file طلب خادم سير مسمى:
keytool -keystore kafka.server.keystore.jks \ -alias server \ -certreq \ -file سيرت سيرفر طلب
يجب عليك الآن إرسال file cert-server-request إلى هيئة الشهادات (CA) الخاصة بك إذا كنت تستخدم هيئة حقيقية. ثم ستقوم الهيئة بإرجاع الشهادة الموقعة. سنشير إلى ذلك باسم cert-server-signed أدناه. توقيع شهادة SSL باستخدام شهادة CA تم إنشاؤها ذاتيًا
ملحوظة: مرة أخرى، لا يُنصح باستخدام CA الخاص بك في نظام الإنتاج. قم بتوقيع الشهادة باستخدام CA عن طريق file cert-server-request ، الذي ينتج الشهادة الموقعة التي تم توقيعها بواسطة الخادم. انظر أدناه؛ 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 \ -days 999 -CAcreateserial \ -passin pass:{ca-password}
استيراد الشهادة الموقعة في Keystore
قم باستيراد شهادة الجذر ca-cert إلى مخزن المفاتيح:
keytool -keystore kafka.server.keystore.jks \ -alias ca-cert \ -import \ -file $ {CA_PATH} / ca-cert
استيراد الشهادة الموقعة المشار إليها باسم شهادة موقعة من الخادم:
keytool -keystore kafka.server.keystore.jks \ -alias server \ -import \ -file شهادة موقعة من الخادم
ال file يجب نسخ kafka.server.keystore.jks إلى موقع معروف على خادم مركز التحكم ، ثم الإشارة إليه في /etc/kafka/server.properties.
باستخدام واجهة برمجة التطبيقات المتدفقة

عام

تجلب واجهة برمجة التطبيقات المتدفقة بيانات الاختبار والمراقبة. لا يمكن تمييز إحدى هذه الفئات.
لا تجلب واجهة برمجة التطبيقات المتدفقة البيانات من الاختبارات المستندة إلى البرنامج النصي (تلك التي يمثلها مستطيل بدلاً من قطعة بانوراما في Control Center GUI) ، مثل اختبارات تنشيط خدمة Ethernet واختبارات الشفافية.
أسماء موضوع كافكا
أسماء موضوعات Kafka لواجهة برمجة التطبيقات المتدفقة هي كما يلي، حيث %s هو الاسم المختصر لعنصر التحكم
حساب المركز (المشار إليه عند إنشاء الحساب):
ثابت (اسم المصدر = "kafka" metadataTopicTpl = "paa.public.accounts.%s.metadata" metricsTopicTpl = "paa.public.accounts.%s.metrics")
Exampليه من استخدام دفق API
السابقampتم العثور على les التالية في tarball paa-streaming-api-client-examples.tar.gz الموجودة داخل مركز التحكم tarball.
أولاً ، هناك مثال أساسيampيوضح هذا المثال كيفية بث المقاييس وبياناتها الوصفية بشكل منفصل وطباعة الرسائل المستلمة ببساطة على وحدة التحكم. يمكنك تشغيله على النحو التالي: sudo ./build.sh run-basic –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME
هناك أيضًا مثال أكثر تقدمًاample حيث ترتبط المقاييس ورسائل البيانات الوصفية. استخدم هذا الأمر لتشغيله:
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. جميع الحقوق محفوظة.

المستندات / الموارد

واجهة برمجة تطبيقات البث Juniper [بي دي اف] دليل المستخدم واجهة برمجة التطبيقات للبث المباشر، واجهة برمجة التطبيقات

مراجع

• دليل المستخدم