Apache NiFi على Azure

Azure Application Gateway
Azure Log Analytics
Azure Virtual Machines
Azure Virtual Network
Azure Virtual Machine Scale Sets

تنبيه

تشير هذه المقالة إلى CentOS، وهو توزيع Linux هو نهاية العمر الافتراضي (EOL). يرجى مراعاة استخدامك والتخطيط وفقا لذلك. لمزيد من المعلومات، راجع إرشادات نهاية العمر الافتراضي CentOS.

يوضح هذا السيناريو مثال كيفية تشغيل Apache NiFi على Azure. NiFi توفر نظاماً لمعالجة البيانات وتوزيعها.

تعد Apache® وApache NiFi® وNiFi® إما علامات تجارية مسجلة أو علامات تجارية لمؤسسة Apache Software Foundation في الولايات المتحدة و/أو دول أخرى. لا توجد موافقة ضمنية من Apache Software Foundation باستخدام هذه العلامات.

بناء الأنظمة

رسم تخطيطي للبنية يوضح التدفق التلقائي للبيانات من خلال حل Azure الذي يستخدم Apache NiFi وApache ZooKeeper.

قم بتنزيل ملف Visio لهذه البنية.

‏‏سير العمل‬

  • يشغل تطبيق NiFi على أجهزة VMs في ‏‏عقدة نظام المجموعة NiFi. توجد VMs في مجموعة تغيير حجم الجهاز الظاهري يوزعها التكوين عبر مناطق التوفر.

  • يشغل Apache ZooKeeper على VMs في نظام مجموعة منفصلة. تستخدم NiFi نظام مجموعة ZooKeeper لهذه الأغراض:

    • لاختيار عقدة منسق نظام مجموعة أجهزة
    • لتنسيق تدفق البيانات
  • توفر بوابة تطبيق Azure موازنة تحميل الطبقة 7 لواجهة المستخدم التي تشغل على عُقد NiFi.

  • تقوم ميزة المراقبة وتحليلات السجل الخاصة بها بجمع وتحليل وعمل بيانات تتبع الاستخدام من نظام NiFi. يتضمن بيانات تتبع الاستخدام سجل النظام NiFi وقياسات صحة النظام وقياسات الأداء.

  • يقوم Azure Key Vault بتخزين الشهادات والمفاتيح بشكل آمن لمجموعة أجهزة NiFi.

  • يوفر معرف Microsoft Entra تسجيل الدخول الأحادي (SSO) والمصادقة متعددة العوامل.

المكونات

  • NiFi توفر نظاماً لمعالجة البيانات وتوزيعها.
  • ZooKeeper هو خادم مفتوح المصدر يدير الأنظمة الموزعة.
  • الأجهزة الظاهرية هي أحد عروض البنية التحتية كخدمة (IaaS). يمكنك استخدام الأجهزة الظاهرية لتوزيع موارد الحوسبة القابلة للتطوير عند الطلب. توفر الأجهزة الظاهرية مرونة ظاهرية واجهة المستخدم ولكنها تلغي متطلبات الصيانة للأجهزة المادية.
  • مجموعات Azure Virtual Machine Scale Sets توفر طريقة لإدارة مجموعة من VMs. ذات رصيد الحمل. يمكن أن يزيد عدد مثيلات VM في مجموعة أو ينقص تلقائياً استجابةً للطلب أو جدول محدد.
  • مناطق التوفر هي مواقع مادية فريدة داخل منطقة Azure. تعمل هذه العروض عالية التوفر على حماية التطبيقات والبيانات من حالات فشل مراكز البيانات.
  • بوابة Application عبارة عن موازن تحميل يدير نسبة استخدام الشبكة إلى تطبيقات الويب.
  • المراقبة تجمع البيانات الموجودة في البيئات وموارد Azure وتحللها. تتضمن هذه البيانات بيانات تتبع الاستخدام للتطبيق، مثل مقاييس الأداء وسجلات النشاط. لمزيد من المعلومات، راجع اعتبارات المراقبة لاحقاً في هذه المقالة.
  • Log Analytics هي أداة مدخل Microsoft Azure تقوم بتشغيل الاستعلامات على بيانات سجل المراقبة. يوفر تحليلات السجل أيضاً ميزات لرسم المخططات والتحليل الإحصائي لنتائج الاستعلام.
  • Azure DevOps Services توفر الخدمات، والأدوات، والبيئات لإدارة مشاريع الترميز وعمليات التوزيع.
  • Key Vault يخزن أسرار النظام ويتحكم في الوصول إلى البيانات السرية، مثل مفاتيح API، وكلمات المرور، والشهادات، ومفاتيح التشفير.
  • معرف Microsoft Entra هو خدمة هوية مستندة إلى السحابة تتحكم في الوصول إلى Azure وتطبيقات السحابة الأخرى.

البدائل

تفاصيل السيناريو

في هذا السيناريو، يتم تشغيل NiFi في تكوين مجمع عبر أجهزة Azure الظاهرية في مجموعة تغيير الحجم. لكن معظم توصيات هذه المقالة تنطبق أيضاً على السيناريوهات التي تقوم بتشغيل NiFi في وضع المثيل الفردي على جهاز ظاهري واحد (VM). توضح أفضل الممارسات الواردة في هذه المقالة عملية توزيع آمنة وقابلة لتغيير الحجم وقابلية التوفر.

حالات الاستخدام المحتملة

تعمل NiFi بشكل جيد لنقل البيانات وإدارة تدفق البيانات:

  • يعيّن الأنظمة المنفصلة في السحابة
  • نقل البيانات من وإلى Azure Storage ومخازن البيانات الأخرى
  • دمج تطبيقات السحابة من الحافة إلى السحابة والتطبيقات السحابية المختلطة مع Azure IoT وAzure Stack وAzure Kubernetes Service (AKS)

نتيجة لذلك، ينطبق هذا الحل على العديد من المساحات:

  • تجمع مستودعات البيانات الحديثة (MDWs) البنيات المنظمة وغير المهيكلة معاً على نطاق تغيير الحجم. يقومون بجمع وتخزين البيانات من مختلف المصادر، والمتلقيات، والأشكال. تتفوق NiFi في إدخال البيانات إلى MDWs في Azure للمتابعات التالية:

    • يتوفر أكثر من 200 معالج لقراءة البيانات، وكتابتها، ومعالجته.
    • يدعم النظام خدمات التخزين مثل Azure Blob Storage وAzure Data Lake Storage، ومراكز الأحداث، وAzure Queue Storage، وAzure Cosmos DB، وAzure Synapse Analytics.
    • مصدر بيانات قوي لإصدار البيانات إمكانية تنفيذ الحلول المتوافقة. للحصول على معلومات بشأن نقطة ارتكاز مصدر البيانات في ميزة Log Analytics في Azure Monitor، راجع اعتبارات الإبلاغ وإعداد التقارير لاحقاً في هذه المقالة.
  • يمكن تشغيل NiFi على أساس مستقل على الأجهزة صغيرة الحجم. في مثل هذه الحالات، يتيح NiFi إمكانية معالجة بيانات الحافة ونقل تلك البيانات إلى مثيلات أو نظام المجموعة NiFi أكبر في السحابة. تساعد NiFi على تصفية بيانات الحافة وتحويلها وتحديد أولوياتها، ما يضمن تدفقات موثوقة وفعالة للبيانات.

  • تدير حلول IoT الصناعية (IIoT) تدفق البيانات من الحافة إلى مركز البيانات. يبدأ هذا التدفق بالحصول على البيانات من أنظمة وعناصر التحكم الصناعي. تنتقل البيانات بعد ذلك إلى حلول إدارة البيانات وMDWs. تقدم NiFi إمكانات تجعلها مناسبة تماماً لاكتساب البيانات وحركتها:

    • وظيفة معالجة بيانات الحافة
    • دعم البروتوكولات التي تستخدمها بوابات وأجهزة IoT
    • التكامل مع مراكز الأحداث وخدمات التخزين

    يمكن لتطبيقات IoT في مجالات الصيانة التنبُئية وإدارة سلسلة التوريد الاستفادة من هذه الوظيفة.

التوصيات

ضع النقاط التالية في الاعتبار عند استخدام هذا الحل:

عند تشغيل هذا الحل على Azure، نوصي باستخدام الإصدار 1.13.2+ من NiFi. يمكنك تشغيل إصدارات أخرى، ولكنها قد تتطلب تكوينات مختلفة عن تلك الموجودة في هذا الدليل.

لتركيب NiFi على Azure VMs، من الأفضل تنزيل الخانات الملائمة من صفحة تنزيلات NiFi. يمكنك أيضاً إنشاء الخانات من التعليمة البرمجية للمصدر.

بالنسبة لمثال حمل العمل هذا، نوصي باستخدام الإصدارات 3.5.5 والإصدارات الأحدث أو 3.6.x من ZooKeeper.

يمكنك تركيب ZooKeeper على Azure VMs باستخدام خانات الراحة الرسمية أو التعليمة البرمجية المصدر. كلاهما متاح في صفحة الإصدارات Apache ZooKeeper.

الاعتبارات

تنفذ هذه الاعتبارات ركائز Azure Well-Architected Framework، وهو عبارة عن مجموعة من المبادئ التوجيهية التي يمكن استخدامها لتحسين جودة حمل العمل. لمزيد من المعلومات، يرجى مراجعةMicrosoft Azure Well-Architected Framework.

للحصول على معلومات بشأن تكوين NiFi، راجع إرشاد مسؤول نظام Apache NiFi. ضع هذه الاعتبارات في الاعتبار أيضا عند تنفيذ هذا الحل.

تحسين التكلفة

يركز تحسين التكلفة على البحث عن طرق للحد من النفقات غير الضرورية وتحسين الكفاءة التشغيلية. لمزيد من المعلومات، راجع نظرة عامة على ركيزة تحسين التكلفة.

اعتبارات VM

توفر الأقسام التالية مخططاً تفصيلياً لكيفية تكوين أجهزة NiFi VM:

حجم الجهاز الظاهري

يسرد هذا الجدول أحجام VM الموصى بها للبدء بها. بالنسبة لمعظم تدفقات البيانات ذات الأغراض العامة، فإن Standard_D16s_v3 هو الأفضل. لكن لكل تدفق بيانات في NiFi متطلبات مختلفة. اختبر التدفق الخاص بك وقم بتغيير الحجم حسب الحاجة بناءً على متطلبات التدفق الفعلية.

ضع في اعتبارك تمكين الشبكات المسرعة على الأجهزة الظاهرية لزيادة أداء الشبكة. لمزيد من المعلومات، راجع إنشاء شبكات لمجموعات تحجيم الجهاز الظاهري في Azure.

حجم الجهاز الظاهري vCPU الذاكرة في GB الحد الأقصى لمعدل نقل البيانات غير المخزنة مؤقتاً في عمليات الإدخال / الإخراج في الثانية (IOPS) لكل MBps* الحد الأقصى من واجهات الشبكة (بطاقات NIC) / النطاق الترددي المتوقع للشبكة (Mbps)
Standard_D8s_v3 8 32 12800/192 4/4,000
Standard_D16s_v3** 16 64 25,600/384 8/8,000
Standard_D32s_v3 32 128 51,200/768 8/16,000
Standard_M16m 16 437.5 10,000/250 8/4,000

* تعطيل التخزين المؤقت لكتابة قرص البيانات لجميع أقراص البيانات التي تستخدمها على عُقد NiFi.

** نوصي بـ SKU هذا لمعظم تدفقات البيانات ذات الأغراض العامة. يجب أن تكون وحدات التخزين Azure VM SKU ذات تكوينات وحدة المعالجة المركزية الظاهرية والذاكرة المماثلة كافية أيضاً.

نظام تشغيل VM (OS)

نوصي بتشغيل NiFi في Azure على أحد أنظمة تشغيل الضيف التالية:

  • Ubuntu 18.04 LTS أو أحدث
  • CentOS 7.9

للوفاء بالمتطلبات المحددة لتدفق البيانات الخاصة بك، من المهم ضبط العديد من إعدادات مستوى OS بما في ذلك:

  • الحد الأقصى للعمليات المعالجة.
  • مؤشرات الملفات القصوى.
  • وقت الوصول، atime.

بعد ضبط OS ليناسب حالة الاستخدام المتوقعة، استخدم Azure VM Image Builder لتدوين إنشاء تلك الصور المضبوطة. للحصول على إرشادات خاصة بـ NiFi، راجع Configuration Best Practices في إرشاد مسؤول نظام Apache NiFi.

التخزين

قم بتخزين مستودعات NiFi المختلفة على أقراص البيانات وليس على قرص OS لثلاثة أسباب رئيسية:

  • غالباً ما يكون للتدفقات متطلبات معدل النقل عالية للقرص لا يمكن لقرص واحد تلبيتها.
  • من الأفضل فصل عمليات قرص NiFi عن عمليات قرص نظام التشغيل.
  • لا ينبغي أن تكون المستودعات في التخزين المؤقت.

متابعة إرشادات مخطط تفصيلي الأقسام التالية لتكوين أقراص البيانات. هذه الإرشادات خاصة بـ Azure. لمزيد من المعلومات بشأن تكوين المستودعات، راجع State Management في إرشاد مسؤول نظام Apache NiFi.

نوع وحجم قرص البيانات

ضع في اعتبارك هذه العوامل عند تكوين أقراص البيانات لـ NiFi:

  • نوع القرص
  • حجم القرص
  • عدد الملفات المنسوخة للأقراص

إشعار

للحصول على معلومات محدثة بشأن أنواع الأقراص والتحجيم والأسعار، راجع مقدمة بشأن الأقراص المدارة من Azure.

يعرض الجدول التالي أنواع الأقراص المُدارة المتوفرة حالياً في Azure. يمكنك استخدام NiFi مع أي من أنواع الأقراص هذه. ولكن بالنسبة لتدفقات البيانات عالية معدل النقل، نوصي باستخدام Premium SSD.

Ultra Disk Storage (NVM Express (NVMe)) Premium SSD Standard SSD Standard HDD
نوع القرص SSD SSD SSD HDD
الحد الأقصى لحجم القرص 65,536 جيجابايت 32,767 جيجابايت 32,767 جيجابايت 32,767 جيجابايت
الحد الأقصى لمعدل النقل 2,000 ميبي بايت/ثانية 900 ميبي بايت/ثانية 750 ميبي بايت/ثانية 500 ميبي بايت/ثانية
الحد الأقصى ل IOPS 160,000 20,000 6,000 2,000

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

يسرد الجدول التالي الحجم المناسب وأرقام معدل النقل لكل حجم ونوع قرص.

Standard HDD S15 Standard HDD S20 Standard HDD S30 Standard SSD S15 Standard SSD S20 Standard SSD S30 Premium SSD P15 Premium SSD P20 Premium SSD P30
حجم القرص بـ GB 256 512 1,024 256 512 1,024 256 512 1,024
IOPS لكل قرص ما يصل إلى 500 ما يصل إلى 500 ما يصل إلى 500 ما يصل إلى 500 ما يصل إلى 500 ما يصل إلى 500 1,100 2,300 5,000
معدل النقل لكل قرص Up to 60 MBps Up to 60 MBps Up to 60 MBps Up to 60 MBps Up to 60 MBps Up to 60 MBps 125 MBps 150 MBps 200 ميغابت في الثانية

إذا وصل النظام إلى حدود الجهاز الظاهري، فقد لا تؤدي إضافة المزيد من الأقراص إلى زيادة معدل النقل:

  • تعتمد حدود IOPS ومعدل النقل على حجم القرص.
  • يضع حجم الجهاز الظاهري الذي تختاره IOPS وحدود معدل النقل لـ VM على جميع أقراص البيانات.

لمعرفة حدود معدل نقل القرص على مستوى VM، راجع أحجام أجهزة Linux الظاهرية في Azure.

قرص VM التخزين المؤقت

في Azure VMs، تدير ميزة Host Caching التخزين المؤقت للكتابة على القرص. لزيادة سرعة معدل النقل أقراص البيانات التي تستخدمها للمستودعات، قم بإيقاف تشغيل التخزين المؤقت للكتابة على القرص عن طريق تعيين Host Caching على None.

تكوين المستودع

تتمثل أفضل إرشادات الممارسات الخاصة بـ NiFi في استخدام قرص أو أقراص منفصلة لكل من هذه المستودعات:

  • المحتوى
  • FlowFile
  • Provenance

يتطلب هذا النهج ما لا يقل عن ثلاثة أقراص.

تدعم NiFi أيضاً التخطيط على مستوى التطبيق. تعمل هذه الوظيفة على زيادة حجم أو أداء مستودعات البيانات.

القصاصة البرمجية التالية من nifi.propertiesملف التكوين. يقوم هذا التكوين بتقسيم المستودعات وتخطيطها عبر الأقراص المرفقة المتصلة بـ VMs:

nifi.provenance.repository.directory.stripe1=/mnt/disk1/ provenance_repository
nifi.provenance.repository.directory.stripe2=/mnt/disk2/ provenance_repository
nifi.provenance.repository.directory.stripe3=/mnt/disk3/ provenance_repository
nifi.content.repository.directory.stripe1=/mnt/disk4/ content_repository
nifi.content.repository.directory.stripe2=/mnt/disk5/ content_repository
nifi.content.repository.directory.stripe3=/mnt/disk6/ content_repository
nifi.flowfile.repository.directory=/mnt/disk7/ flowfile_repository

لمزيد من المعلومات بشأن التصميم لتخزين عالي الأداء، راجع تخزين Azure المتميز: التصميم لأداء عالٍ.

إعداد التقرير

تتضمن NiFi مهمة إعداد تقارير عن المصدر لميزة Log Analytics.

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

يمكنك أيضاً استخدام هذه المهمة مع مساحة تخزين ذات ذاكرة مضمنة متطايرة (مؤقتة). في العديد من السيناريوهات، يمكنك بعد ذلك تحقيق زيادة في معدل النقل. لكن هذا النهج محفوف بالمخاطر إذا كنت بحاجة إلى الحفاظ على بيانات الحدث. تأكد من أن التخزين المتطاير يلبي متطلبات المتانة لأحداث المصدر. لمزيد من المعلومات، راجع Provenance Repository في إرشاد مسؤول نظام Apache NiFi.

قبل استخدام هذه العملية، قم بإنشاء مساحة عمل Log Analytics في اشتراك Azure الخاص بك. من الأفضل إعداد مساحة العمل في نفس منطقة حجم العمل لديك.

لتكوين مهمة الإبلاغ عن المصدر:

  1. افتح إعدادات وحدة التحكم في NiFi.
  2. حدد قائمة مهام إعداد التقارير.
  3. حدد Create a new reporting task.
  4. حدد Azure Log Analytics Reporting Task.

تُظهر لقطة الشاشة التالية قائمة الخصائص لمهمة إعداد التقارير هذه:

لقطة شاشة لنافذة NiFi Configure Reporting Task. قائمة Properties مرئية. يسرد قيم إعدادات Log Analytics.

مطلوب خاصيتين:

  • معرف مساحة عمل Log Analytics
  • مفتاح مساحة عمل Log Analytics

يمكنك العثور على هذه القيم في مدخل Microsoft Azure بالانتقال إلى مساحة عمل Log Analytics.

تتوفر أيضاً خيارات أخرى لتخصيص أحداث المصدر التي يرسلها النظام وتصفيتها.

الأمان

ويوفر عامل الأمان ضمانات للحماية من الهجمات المتعمدة واستغلال البيانات والأنظمة القيمة الخاصة بك. للمزيد من المعلومات، يرجى الرجوع إلى نظرة عامة على ركيزة الأمان.

يمكنك تأمين NiFi من وجهة نظر المصادقة والتخويل. يمكنك أيضاً تأمين NiFi لجميع اتصالات الشبكة بما في ذلك:

  • داخل نظام مجموعة أجهزة.
  • بين نظام مجموعة الأجهزة وZooKeeper.

راجع دليل مسؤولي Apache NiFi للحصول على إرشادات بشأن تشغيل الخيارات التالية:

  • Kerberos
  • بروتوكول الوصول الخفيف إلى الدليل (LDAP)
  • المصادقة على أساس الشهادة والتحويل
  • طبقة مآخذ توصيل آمنة ثنائية الاتجاه (SSL) نظام مجموعة الاتصالات

إذا قمت بتشغيل الوصول الآمن للعميل ZooKeeper، فقم بتكوين NiFi عن طريق إضافة الخصائص ذات الصلة إلى ملف التكوين bootstrap.conf الخاص به. توفر إدخالات التكوين التالية مثالاً:

java.arg.18=-Dzookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty
java.arg.19=-Dzookeeper.client.secure=true
java.arg.20=-Dzookeeper.ssl.keyStore.location=/path/to/keystore.jks
java.arg.21=-Dzookeeper.ssl.keyStore.password=[KEYSTORE PASSWORD]
java.arg.22=-Dzookeeper.ssl.trustStore.location=/path/to/truststore.jks
java.arg.23=-Dzookeeper.ssl.trustStore.password=[TRUSTSTORE PASSWORD]

للحصول على توصيات عامة، راجع أساس أمان Linux.

أمن الشبكة

عند تنفيذ هذا الحل، ضع في اعتبارك النقاط التالية بشأن أمان الشبكة:

مجموعات أمان الشبكة

في Azure، يمكنك استخدام مجموعات أمان الشبكة لتقييد نسبة استخدام الشبكة.

نوصي باستخدام Jumpbox للاتصال بنظام مجموعة NiFi لأداء المهام الإدارية. استخدم VM المشدد من حيث الأمان مع الوصول في نفس الوقت (JIT) أو Azure Bastion. قم بإعداد مجموعات أمان الشبكة للتحكم في كيفية منحك الوصول إلى Jumpbox أو Azure Bastion. يمكنك تحقيق عزل الشبكة وعنصر التحكم فيها باستخدام مجموعات أمان الشبكة بحكمة على الشبكات الفرعية المختلفة للبنية.

تُظهر لقطة الشاشة التالية المكونات الموجودة في شبكة ظاهرية نموذجية. يحتوي على شبكة فرعية مشتركة لـ Jumpbox، ومجموعة تغيير سعة جهاز ظاهري وZooKeeper VMs. يعمل تخطيط الشبكة المبسط هذا على تجميع المكونات في شبكة فرعية واحدة. اتبع إرشادات مؤسستك لفصل المهام وتصميم الشبكة.

لقطة شاشة لجدول يسرد الأجهزة والأنواع والشبكات الفرعية لمكونات شبكة ظاهرية.

النظر في الوصول إلى الإنترنت الصادرة

لا يحتاج NiFi في Azure إلى الوصول إلى الإنترنت العام لتشغيله. إذا لم يكن تدفق البيانات بحاجة إلى الوصول إلى الإنترنت لاسترداد البيانات، فقم بتحسين أمان النظام للمجموعة باتباع هذه الخطوات لتعطيل الوصول إلى الإنترنت الصادر:

  1. قم بإنشاء قاعدة مجموعة أمان إضافية للشبكة في الشبكة الظاهرية.

  2. استخدم الإعدادات التالية:

    • المصدر: Any
    • الوجهة: Internet
    • الإجراء: Deny

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

مع تطبيق هذه القاعدة، لا يزال بإمكانك الوصول إلى بعض خدمات Azure من تدفق البيانات إذا قمت بتكوين نقطة نهاية خاصة في الشبكة الظاهرية. استخدم Azure Private Link لهذا الغرض. توفر هذه الخدمة وسيلة لنقل نسبة استخدام الشبكة الخاصة بك على شبكة Microsoft الأساسية بينما لا تتطلب أي وصول آخر للشبكة الخارجية. تدعم NiFi حالياً الارتباط الخاص لمعالجات Blob Storage وتخزين مستودع البيانات. إذا لم يكن خادم بروتوكول وقت الشبكة (NTP) متوفرا في شبكتك الخاصة، فاسمح بالوصول الصادر إلى NTP. للحصول على معلومات تفصيلية، راجع مزامنة الوقت لأجهزة Linux VMs في Azure.

حماية البيانات

من الممكن تشغيل NiFi دون تأمين، دون تشفير سلكي، وإدارة الهوية والوصول (IAM)، أو تشفير البيانات. ولكن من الأفضل تأمين الإنتاج وعمليات التوزيع على السحابة العامة بهذه الطرق:

  • تشفير الاتصال بأمان طبقة النقل (TLS)
  • استخدام آلية مصادقة وتحويل مدعومة
  • تشفير بيانات ثابتة

يوفر Azure Storage تشفيراً شفافاً للبيانات من جانب الخادم. ولكن بدءاً من الإصدار 1.13.2، لا يقوم NiFi بتكوين تشفير الأسلاك أو IAM افتراضياً. قد يتغير هذا السلوك في الإصدارات المستقبلية.

توضح الأقسام التالية كيفية تأمين عمليات التوزيع بهذه الطرق:

  • تفعيل تشفير الأسلاك باستخدام TLS
  • تكوين المصادقة المستندة إلى الشهادات أو معرف Microsoft Entra
  • إدارة التخزين المشفر على Azure
تشفير القرص

لتحسين الأمان، استخدم تشفير قرص Azure. للحصول على إجراء تفصيلي، راجع تشفير OS وأقراص البيانات المرفقة في تغيير حجم جهاز ظاهري تم تعيينه باستخدام Azure CLI. يحتوي هذا المستند أيضاً على إرشادات بشأن توفير مفتاح التشفير الخاص بك. توضح الخطوات التالية مثالاً أساسياً لـ NiFi يعمل مع معظم عمليات التوزيع:

  1. لتشغيل تشفير القرص في مثيل Key Vault موجود، استخدم الأمر التالي Azure CLI:

    az keyvault create --resource-group myResourceGroup --name myKeyVaultName --enabled-for-disk-encryption
    
  2. قم بتشغيل تشفير أقراص بيانات مجموعة تغيير حجم الجهاز الظاهري باستخدام الأمر التالي:

    az vmss encryption enable --resource-group myResourceGroup --name myScaleSet --disk-encryption-keyvault myKeyVaultID --volume-type DATA
    
  3. يمكنك اختياريا استخدام مفتاح تشفير مفتاح (KEK). استخدم الأمر التالي Azure CLI للتشفير باستخدام KEK:

    az vmss encryption enable --resource-group myResourceGroup --name  myScaleSet  \
    --disk-encryption-keyvault myKeyVaultID \
    --key-encryption-keyvault myKeyVaultID \
    --key-encryption-key https://<mykeyvaultname>.vault.azure.net/keys/myKey/<version> \
    --volume-type DATA
    
    

إشعار

إذا قمت بتكوين تغيير حجم الجهاز الظاهري الخاص بك على وضع التحديث اليدوي، فقم بتشغيل الأمر update-instances. قم بتضمين إصدار مفتاح التشفير الذي قمت بتخزينه في Key Vault.

التشفير أثناء النقل

يدعم NiFi TLS 1.2 للتشفير أثناء النقل. يوفر هذا البروتوكول الحماية لوصول المستخدم إلى واجهة UI. مع مقاطع تخزينية، يحمي البروتوكول الاتصال بين عُقد NiFi. يمكنه أيضاً حماية التواصل مع ZooKeeper. عند تمكين TLS، تستخدم NiFi بروتوكول TLS المتبادل (mTLS) للمصادقة المتبادلة من أجل:

  • مصادقة العميل المستندة إلى الشهادة إذا قمت بتكوين هذا النوع من المصادقة.
  • جميع الاتصالات داخل المجموعات.

لتمكين TLS، اتبع الخطوات التالية:

  1. إنشاء مخزن مفاتيح ومخزن ثقة لاتصالات ومصادقة العميل والخادم وداخل المجموعة.

  2. تكوين $NIFI_HOME/conf/nifi.properties. قم بتعيين القيم التالية:

    • اسم المضيف
    • منافذ
    • خصائص مخزن المفاتيح
    • خصائص مخزن الثقة
    • خصائص أمان نظام المجموعة وZooKeeper، إن أمكن
  3. يكوّن المصادقة في $NIFI_HOME/conf/authorizers.xml، عادةً مع مستخدم أولي لديه مصادقة قائمة على شهادة أو خيار آخر.

  4. قم بتكوين mTLS ونهج قراءة الوكيل اختيارياً بين NiFi وأي خوادم وكيلة أو موازنات تحميل أو نقاط نهاية خارجية.

للحصول على إرشادات كاملة، راجع تأمين NiFi باستخدام TLS في وثائق مشروع Apache.

إشعار

اعتباراً من الإصدار 1.13.2:

  • لا يقوم NiFi بتمكين TLS افتراضياً.
  • لا يوجد دعم خارجي لوصول مجهول ومستخدم فردي لمثيلات NiFi التي تُمكن TLS.

لتمكين TLS للتشفير أثناء النقل، هيئ مجموعة مستخدمين وموفر نهج للمصادقة والتحويل في $NIFI_HOME/conf/authorizers.xml. لمزيد من المعلومات، راجع التحكم في الهوية والوصول لاحقاً في هذه المقالة.

الشهادات والمفاتيح ومخازن المفاتيح

لدعم TLS، قم بإنشاء الشهادات، وتخزينها في Java KeyStore وTrustStore، وتوزيعها عبر مجموعة أجهزة NiFi. هناك خياران عامان للشهادات:

  • الشهادات الموقعة ذاتيًا
  • الشهادات التي توقعها المراجع المصدقة

باستخدام الشهادات الموقعة من قِبل المرجع المصدق، من الأفضل استخدام مرجع مصدق وسيط لإنشاء شهادات للعقد في نظام المجموعة.

KeyStore وTrustStore هما حاويات المفاتيح والشهادات في نظام Java الأساسي. KeyStore يخزن المفتاح الخاص وشهادة العقدة في نظام المجموعة. يقوم TrustStore بتخزين أحد أنواع الشهادات التالية:

  • جميع الشهادات الموثوقة، للشهادات الموقعة ذاتياً في KeyStore
  • شهادة من CA، للشهادات الموقعة من CA في KeyStore

ضع في اعتبارك قابلية التوسع في نظام مجموعة NiFi عند اختيار حاوية. على سبيل المثال، قد ترغب في زيادة أو تقليل عدد العقد في نظام المجموعة في المستقبل. اختر الشهادات الموقعة من CA في KeyStore وشهادة واحدة أو أكثر من CA في TrustStore في هذه الحالة. باستخدام هذا الخيار، ليست هناك حاجة لتحديث TrustStore الموجودة في العقد الحالية لنظام مجموعة. يثق TrustStore الموجود ويقبل الشهادات من هذه الأنواع من العقد:

  • العقد التي تضيفها إلى نظام مجموعة
  • العقد التي تحل محل العقد الأخرى في نظام مجموعة
تكوين NiFi

لتمكين TLS لـ NiFi، استخدم $NIFI_HOME/conf/nifi.properties لتكوين الخصائص في هذا الجدول. تأكد من أن الخصائص التالية تتضمن اسم المضيف الذي تستخدمه للوصول إلى NiFi:

  • nifi.web.https.host أو nifi.web.proxy.host
  • الاسم المعين لشهادة المضيف أو الأسماء البديلة للموضوع

وإلا، فقد يؤدي فشل التحقق من اسم المضيف أو فشل التحقق من عنوان HTTP HOST إلى رفض الوصول.

اسم الخاصية ‏‏الوصف قيم الأمثلة
nifi.web.https.host اسم المضيف أو عنوان IP المراد استخدامه لـ UL وREST API. يجب أن تكون هذه القيمة قابلة للحل داخلياً. نوصي بعدم استخدام اسم متاح للجميع. nifi.internal.cloudapp.net
nifi.web.https.port منفذ HTTPS لاستخدامه في لـ UL وREST API. 9443 (افتراضي)
nifi.web.proxy.host قائمة مفصولة بفواصل لأسماء المضيفين البديلة التي يستخدمها العملاء للوصول إلى UI وREST API. تتضمن هذه القائمة عادةً أي اسم مضيف يتم تحديده كاسم بديل للموضوع (SAN) في شهادة الخادم. يمكن أن تشتمل القائمة أيضاً على أي اسم مضيف ومنفذ يستخدمه موازن التحميل أو الوكيل أو وحدة تحكم إدخال Kubernetes. 40.67.218.235, 40.67.218.235:443, nifi.westus2.cloudapp.com, nifi.westus2.cloudapp.com:443
nifi.security.keystore المسار إلى ملف تخزين المفاتيح JKS أو PKCS12 الذي يحتوي على المفتاح الخاص للشهادة. ./conf/keystore.jks
nifi.security.keystoreType نوع مخزن المفاتيح. JKS أو PKCS12
nifi.security.keystorePasswd كلمة مرور مخزن المفاتيح. O8SitLBYpCz7g/RpsqH+zM
nifi.security.keyPasswd (اختياري) كلمة المرور للمفتاح الخاص.
nifi.security.truststore المسار إلى مخزن الثقة JKS أو PKCS12 الذي يحتوي على شهادات أو شهادات CA التي تصادق المستخدمين الموثوق بهم وعقد نظام المجموعة. ./conf/truststore.jks
nifi.security.truststoreType نوع مخزن الثقة. JKS أو PKCS12
nifi.security.truststorePasswd كلمة مرور مخزن الثقة. RJlpGe6/TuN5fG+VnaEPi8
nifi.cluster.protocol.is.secure حالة TLS للاتصال داخل العنقود. إذا كانت nifi.cluster.is.node هي true، فاضبط هذه القيمة على true لتمكين TLS لنظام المجموعة. true
nifi.remote.input.secure حالة TLS للاتصال من موقع إلى موقع. true

يوضح المثال التالي كيف تظهر هذه الخصائص في $NIFI_HOME/conf/nifi.properties. لاحظ أن قيم nifi.web.http.host وnifi.web.http.port فارغة.

nifi.remote.input.secure=true
nifi.web.http.host=
nifi.web.http.port=
nifi.web.https.host=nifi.internal.cloudapp.net
nifi.web.https.port=9443
nifi.web.proxy.host=40.67.218.235, 40.67.218.235:443, nifi.westus2.cloudapp.com, nifi.westus2.cloudapp.com:443
nifi.security.keystore=./conf/keystore.jks 
nifi.security.keystoreType=JKS          
nifi.security.keystorePasswd=O8SitLBYpCz7g/RpsqH+zM                  
nifi.security.keyPasswd=
nifi.security.truststore=./conf/truststore.jks                                   
nifi.security.truststoreType=JKS
nifi.security.truststorePasswd=RJlpGe6/TuN5fG+VnaEPi8
nifi.cluster.protocol.is.secure=true
تكوين ZooKeeper

للحصول على إرشادات بشأن تمكين TLS في Apache ZooKeeper لاتصالات الحصة ووصول العميل، راجع إرشاد مسؤول ZooKeeper. تدعم الإصدارات 3.5.5 أو الأحدث هذه الوظيفة فقط.

تستخدم NiFi ZooKeeper للتجميع الصفري وتنسيق نظام مجموعة. بدءاً من الإصدار 1.13.0، تدعم NiFi وصول العميل الآمن إلى مثيلات ZooKeeper التي تدعم TLS. يخزن ZooKeeper عضوية نظام المجموعة وحالة المعالج ذو النطاق العنقودي في نص عادي. لذلك من المهم استخدام وصول العميل الآمن إلى ZooKeeper لمصادقة طلبات عميل ZooKeeper. قم أيضاً بتشفير القيم الحساسة أثناء النقل.

لتمكين TLS لوصول عميل NiFi إلى ZooKeeper، قم بتعيين الخصائص التالية في $NIFI_HOME/conf/nifi.properties. إذا قمت بتعيين nifi.zookeeper.client.secure true دون تكوين الخصائص nifi.zookeeper.security ، فإن NiFi يعود إلى مخزن المفاتيح ومخزن الثقة الذي تحدده في nifi.securityproperties.

اسم الخاصية ‏‏الوصف قيم الأمثلة
nifi.zookeeper.client.secure حالة TLS للعميل عند الاتصال بـ ZooKeeper. true
nifi.zookeeper.security.keystore المسار إلى مخزن مفاتيح JKS أو PKCS12 أو PEM الذي يحتوي على المفتاح الخاص للشهادة المقدمة إلى ZooKeeper للمصادقة. ./conf/zookeeper.keystore.jks
nifi.zookeeper.security.keystoreType نوع مخزن المفاتيح. JKS، أو PKCS12، أو PEM، أو الكشف التلقائي عن طريق الملحق
nifi.zookeeper.security.keystorePasswd كلمة مرور مخزن المفاتيح. caB6ECKi03R/co+N+64lrz
nifi.zookeeper.security.keyPasswd (اختياري) كلمة المرور للمفتاح الخاص.
nifi.zookeeper.security.truststore المسار إلى مخزن الثقة JKS أو PKCS12 أو PEM الذي يحتوي على شهادات أو شهادات CA المستخدمة لمصادقة ZooKeeper. ./conf/zookeeper.truststore.jks
nifi.zookeeper.security.truststoreType نوع مخزن الثقة. JKS، أو PKCS12، أو PEM، أو الكشف التلقائي عن طريق الملحق
nifi.zookeeper.security.truststorePasswd كلمة مرور مخزن الثقة. qBdnLhsp+mKvV7wab/L4sv
nifi.zookeeper.connect.string سلسلة الاتصال بمضيف ZooKeeper أو الحصة. هذه السلسلة عبارة عن قائمة من قيم host:port مفصولة بفواصل. عادةً ما تختلف قيمة secureClientPort عن قيمة clientPort. راجع تكوين ZooKeeper الخاص بك لمعرفة القيمة الصحيحة. zookeeper1.internal.cloudapp.net:2281, zookeeper2.internal.cloudapp.net:2281, zookeeper3.internal.cloudapp.net:2281

يوضح المثال التالي كيف تظهر هذه الخصائص في $NIFI_HOME/conf/nifi.properties:

nifi.zookeeper.client.secure=true
nifi.zookeeper.security.keystore=./conf/keystore.jks
nifi.zookeeper.security.keystoreType=JKS
nifi.zookeeper.security.keystorePasswd=caB6ECKi03R/co+N+64lrz
nifi.zookeeper.security.keyPasswd=
nifi.zookeeper.security.truststore=./conf/truststore.jks
nifi.zookeeper.security.truststoreType=JKS
nifi.zookeeper.security.truststorePasswd=qBdnLhsp+mKvV7wab/L4sv
nifi.zookeeper.connect.string=zookeeper1.internal.cloudapp.net:2281,zookeeper2.internal.cloudapp.net:2281,zookeeper3.internal.cloudapp.net:2281

لمزيد من المعلومات بشأن تأمين ZooKeeper باستخدام TLS، راجع دليل إدارة Apache NiFi.

الهوية وعناصر التحكم في الوصول

في NiFi، تتحقق الهوية والتحكم في الوصول من خلال مصادقة المستخدم والتحويل. لمصادقة المستخدم، لدى NiFi خيارات متعددة للاختيار من بينها: مستخدم واحد، LDAP، Kerberos، Security Assertion Markup Language (SAML)، وOpenID Connect (OIDC). إذا لم تقم بتكوين أحد الخيارات، فإن NiFi تستخدم شهادات العميل لمصادقة المستخدمين عبر HTTPS.

إذا كنت تفكر في المصادقة متعددة العوامل، نوصي بمزيج من معرف Microsoft Entra وOIDC. يدعم Microsoft Entra ID تسجيل الدخول الأحادي (SSO) الأصلي على السحابة باستخدام OIDC. باستخدام هذه المجموعة، يمكن للمستخدمين الاستفادة من العديد من ميزات أمان المؤسسة:

  • التسجيل والتنبيه بشأن الأنشطة المشبوهة من حسابات المستخدمين
  • مراقبة محاولات الوصول إلى معلومات تسجيل الدخول المعطلة
  • تنبيه بشأن سلوك غير معتاد لتسجيل الدخول إلى الحساب

للتخويل، توفر NiFi تطبيقاً يعتمد على نُهج المستخدم والمجموعة والوصول. توفر NiFi هذا الإنفاذ من خلال UserGroupProviders وAccessPolicyProviders. بشكل افتراضي، يتضمن الموفرون UserGroupProviders المستندة إلى File وLDAP وShell وAzure Graph. باستخدام AzureGraphUserGroupProvider، يمكنك مصدر مجموعات المستخدمين من معرف Microsoft Entra. يمكنك بعد ذلك تعيين نُهج لهذه المجموعات. للحصول على إرشادات التكوين، راجع إرشاد إدارة Apache NiFi.

AccessPolicyProviders التي تستند إلى الملفات وApache Ranger متاحة حالياً لإدارة وتخزين نُهج المستخدم والمجموعات. للحصول على معلومات مفصلة، راجع وثائق Apache NiFi ووثائق Apache Ranger.

بوابة التطبيق

توفر بوابة التطبيق موازنة تحميل مُدار من الطبقة 7 لواجهة NiFi. قم بتكوين بوابة التطبيق لاستخدام مجموعة تغيير حجم الجهاز الظاهري لعقد NiFi كمجموعة خلفية لها.

بالنسبة لمعظم عمليات تثبيت NiFi، نوصي بتكوين بوابة Application التالية:

  • المستوى: قياسي
  • حجم SKU: متوسط
  • عدد المثيلات: اثنان أو أكثر

استخدم اختبار الحالة لمراقبة سلامة خادم الويب على كل عقدة. قم بإزالة العقد غير الصحية من دوران موازن التحميل. هذا النهج يجعل من السهل عرض واجهة المستخدم عندما تكون نظام المجموعة أجهزة الكلية غير صحية. يوجهك المستعرض فقط إلى العقد السليمة حالياً والتي تستجيب للطلبات.

هناك نوعان من التحقيقات الصحية الرئيسية للنظر فيها. يوفران معاً نبضات قلب منتظمة على الحالة العامة لكل عقدة في نظام المجموعة. قم بتكوين مسبار الحالة الأول للإشارة إلى المسار /NiFi. يحدد هذا المسبار صحة واجهة مستخدم NiFi على كل عقدة. قم بتكوين اختبار صحة ثانٍ للمسار /nifi-api/controller/cluster. يشير هذا التحقيق إلى ما إذا كانت كل عقدة في الوقت الحالي سليمة ومتصلة بنظام المجموعة.

لديك خياران لتكوين عنوان IP الأمامي لبوابة التطبيق:

  • مع عنوان IP عام
  • مع عنوان IP للشبكة الفرعية الخاصة

قم بتضمين عنوان IP عام فقط إذا احتاج المستخدمون إلى الوصول إلى UI عبر الإنترنت العام. إذا لم يكن الوصول العام إلى الإنترنت للمستخدمين مطلوباً، فقم بالوصول إلى الواجهة الأمامية لموازنة التحميل من صندوق القفز في الشبكة الظاهرية أو من خلال النظر إلى شبكتك الخاصة. إذا قمت بتكوين بوابة التطبيق بعنوان IP عام، فإننا نوصي بتمكين مصادقة شهادة العميل لـ NiFi وتمكين TLS لواجهة مستخدم NiFi. يمكنك أيضاً استخدام مجموعة أمان الشبكة في الشبكة الفرعية لبوابة التطبيق المفوَّض لتقييد عناوين IP للمصدر.

التشخيص والمراقبة الصحية

ضمن إعدادات التشخيص الخاصة لبوابة Application، يوجد خيار تكوين لإرسال القياسات وسجلات الوصول. باستخدام هذا الخيار، يمكنك إرسال هذه المعلومات من موازن التحميل إلى أماكن مختلفة:

  • A حساب تخزين
  • مراكز الأحداث
  • مساحة عمل Log Analytics

يعد تشغيل هذا الإعداد مفيداً لتصحيح مشكلة موازنة التحميل والحصول على نتيجة تحليلات بشأن صحة عقد نظام المجموعة.

يعرض طلب البحث التالي Log Analytics سلامة عقدة نظام المجموعة بمرور الوقت من منظور بوابة التطبيق. يمكنك استخدام استعلام مشابه لإنشاء تنبيهات أو إجراءات إصلاح آلية للعقد غير الصحية.

AzureDiagnostics
| summarize UnHealthyNodes = max(unHealthyHostCount_d), HealthyNodes = max(healthyHostCount_d) by bin(TimeGenerated, 5m)
| render timechart

يُظهر الرسم البياني التالي لنتائج الاستعلام عرضاً زمنياً لسلامة نظام المجموعة:

لقطة شاشة لمخطط شريطي. تظهر الأشرطة عددا ثابتا من العقد الصحية على مدار 24 ساعة ولا توجد عقد غير صحية.

التوافر

عند تنفيذ هذا الحل، ضع في اعتبارك النقاط التالية بشأن التوفر:

موازن التحميل

استخدم موازن التحميل لـ UI لزيادة توفر UI وقت تعطل العقدة.

VMs منفصلة

لزيادة التوفر، قم بتوزيع مجموعة ZooKeeper على أجهزة ظاهرية منفصلة عن VMs في نظام مجموعة NiFi. لمزيد من المعلومات بشأن تكوين ZooKeeper، راجع إدارة الحالة في إرشاد مسؤول نظام Apache NiFi.

مجموعات التوافر

قم بتوزيع كلاً من نظام مجموعة تغيير حجم الجهاز الظاهري NiFi ومجموعة أجهزة ZooKeeper في تكوين عبر المنطقة لزيادة الإتاحة إلى أقصى حد. عندما يتخطى الاتصال بين العقد في نظام المجموعة في مناطق التوفر، فإنه يقدم مقداراً صغيراً من زمن الانتقال. لكن زمن الانتقال هذا عادةً ما يكون له تأثير إجمالي ضئيل على معدل النقل في نظام المجموعة.

مجموعات توسيع الجهاز الافتراضي

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

مراقبة‬

لمراقبة صحة وأداء نظام مجموعة NiFi، استخدم مهام إعداد التقارير.

الإبلاغ عن المراقبة القائمة على المهام

للمراقبة، يمكنك استخدام مهمة إعداد التقارير التي تقوم بتكوينها وتشغيلها في NiFi. كما يناقش التشخيص ومراقبة الحالة، يوفر Log Analytics مهمة إعداد التقارير في حزمة NiFi Azure. يمكنك استخدام مهمة إعداد التقارير هذه لدمج المراقبة مع Log Analytics وأنظمة المراقبة أو التسجيل الحالية.

استفسارات Log Analytics

يمكن أن تساعدك نماذج الاستعلامات في الأقسام التالية على البدء. للحصول على نظرة عامة بشأن كيفية الاستعلام عن بيانات Log Analytics، راجع استعلامات سجل Azure Monitor.

تستخدم استعلامات السجل في Monitor وLog Analytics إصدارا من Kusto Query Language. ولكن توجد اختلافات بين استعلامات السجل واستعلامات Kusto. لمزيد من المعلومات، راجع نظرة عامة على استعلام Kusto.

لمزيد من التعلم المنظم، راجع هذه الدروس:

مهمة تقارير Log Analytics

بشكل افتراضي، ترسل NiFi بيانات القياسات إلى الجدول nifimetrics. ولكن يمكنك تكوين وجهة مختلفة في خصائص مهمة إعداد التقارير. تلتقط مهمة إعداد التقارير قياسات NiFi التالية:

نوع المقياس اسم قياسي
قياسات NiFi FlowFilesReceived
قياسات NiFi FlowFilesSent
قياسات NiFi FlowFilesQueued
قياسات NiFi BytesReceived
قياسات NiFi BytesWritten
قياسات NiFi BytesRead
قياسات NiFi BytesSent
قياسات NiFi BytesQueued
قياسات حالة المنفذ InputCount
قياسات حالة المنفذ InputBytes
قياسات حالة الاتصال QueuedCount
قياسات حالة الاتصال QueuedBytes
قياسات حالة المنفذ OutputCount
قياسات حالة المنفذ OutputBytes
مقاييس الجهاز الظاهري Java (JVM) jvm.uptime
قياسات JVM jvm.heap_used
قياسات JVM jvm.heap_usage
قياسات JVM jvm.non_heap_usage
قياسات JVM jvm.thread_states.runnable
قياسات JVM jvm.thread_states.blocked
قياسات JVM jvm.thread_states.timed_waiting
قياسات JVM jvm.thread_states.terminated
قياسات JVM jvm.thread_count
قياسات JVM jvm.daemon_thread_count
قياسات JVM jvm.file_descriptor_usage
قياسات JVM jvm.gc.runs jvm.gc.runs.g1_old_generation jvm.gc.runs.g1_young_generation
قياسات JVM jvm.gc.time jvm.gc.time.g1_young_generation jvm.gc.time.g1_old_generation
قياسات JVM jvm.buff_pool_direct_capacity
قياسات JVM jvm.buff_pool_direct_count
قياسات JVM jvm.buff_pool_direct_mem_used
قياسات JVM jvm.buff_pool_mapped_capacity
قياسات JVM jvm.buff_pool_mapped_count
قياسات JVM jvm.buff_pool_mapped_mem_used
قياسات JVM jvm.mem_pool_code_cache
قياسات JVM jvm.mem_pool_compressed_class_space
قياسات JVM jvm.mem_pool_g1_eden_space
قياسات JVM jvm.mem_pool_g1_old_gen
قياسات JVM jvm.mem_pool_g1_survivor_space
قياسات JVM jvm.mem_pool_metaspace
قياسات JVM jvm.thread_states.new
قياسات JVM jvm.thread_states.waiting
قياسات مستوى المعالج BytesRead
قياسات مستوى المعالج BytesWritten
قياسات مستوى المعالج FlowFilesReceived
قياسات مستوى المعالج FlowFilesSent

فيما يلي نموذج استعلام BytesQueued لمقياس نظام المجموعة:

let table_name = nifimetrics_CL;
let metric = "BytesQueued";
table_name
| where Name_s == metric
| where Computer contains {ComputerName}
| project TimeGenerated, Computer, ProcessGroupName_s,  Count_d, Name_s
| summarize sum(Count_d) by bin(TimeGenerated, 1m),  Computer, Name_s
| render timechart 

ينتج عن هذا الاستعلام مخطط مثل المخطط الموجود في لقطة الشاشة هذه:

لقطة شاشة لمخطط خطي. تعرض الأسطر عدد وحدات البايت في قائمة الانتظار على مدى فترة أربع ساعات.

إشعار

عندما تقوم بتشغيل NiFi على Azure، فأنت لست مقيداً بمهمة إعداد تقارير Log Analytics. تدعم NiFi إعداد التقارير للعديد من تقنيات المراقبة التابعة لجهات خارجية. للحصول على قائمة بمهام إعداد التقارير المدعومة، راجع مهام إعداد التقارير في قسم فهرس Apache NiFi Documentation.

مراقبة البنية الأساسية لـ NiFi

بالإضافة إلى مهمة إعداد التقارير، قم بتثبيت ملحق Log Analytics VM على عقدتي NiFi وZooKeeper. يجمع هذا الملحق السجلات والقياسات الإضافية على مستوى VM والقياسات من ZooKeeper.

سجلات مخصصة لتطبيق NiFi والمستخدم وbootstrap وZooKeeper

لتسجيل المزيد من السجلات، اتبع الخطوات التالية:

  1. في مدخل Microsoft Azure، حدد مساحة عمل Log Analytics، ثم حدد مساحة العمل الخاصة بك.

  2. ضمن Settings، حدد Custom logs.

    لقطة شاشة لصفحة MyWorkspace في مدخل Microsoft Azure. يتم استدعاء الإعدادات والسجلات المخصصة.

  3. حدد Add custom log.

    لقطة شاشة لصفحة السجلات المخصصة في مدخل Microsoft Azure مع استدعاء إضافة سجل مخصص.

  4. قم بإعداد سجل مخصص بهذه القيم:

    • الاسم: NiFiAppLogs
    • نوع المسار: Linux
    • اسم المسار: /opt/nifi/logs/nifi-app.log

    لقطة شاشة لنافذة NiFi. قيم التكوين لسجل مخصص لتطبيق NiFi مرئية.

  5. قم بإعداد سجل مخصص بهذه القيم:

    • الاسم: NiFiBootstrapAndUser
    • نوع المسار الأول: Linux
    • اسم المسار الأول: /opt/nifi/logs/nifi-user.log
    • نوع المسار الثاني: Linux
    • اسم المسار الثاني: /opt/nifi/logs/nifi-bootstrap.log

    لقطة شاشة لنافذة NiFi. قيم التكوين لسجل مخصص ل NiFi bootstrap والمستخدم مرئية.

  6. قم بإعداد سجل مخصص بهذه القيم:

    • الاسم: NiFiZK
    • نوع المسار: Linux
    • اسم المسار: /opt/zookeeper/logs/*.out

    لقطة شاشة لنافذة NiFi. قيم التكوين لسجل مخصص ل ZooKeeper مرئية.

فيما يلي نموذج استعلام للجدول المخصص NiFiAppLogs الذي أنشأه المثال الأول:

NiFiAppLogs_CL
| where TimeGenerated > ago(24h)
| where Computer contains {ComputerName} and RawData contains "error"
| limit 10

ينتج عن هذا الاستعلام نتائج مشابهة للنتائج التالية:

لقطة شاشة لنتائج الاستعلام التي تتضمن طابعا زمنيا، والكمبيوتر، والبيانات الأولية، والنوع، والمورد I D.

تكوين سجل البنية الأساسية

يمكنك استخدام الشاشة لمراقبة وإدارة VMs أو أجهزة الكمبيوتر الفعلية. يمكن أن تكون هذه الموارد في مركز البيانات المحلي أو بيئة سحابية أخرى. لإعداد هذه المراقبة، قم بتوزيع عامل Log Analytics. تكوين العامل لتقديم تقرير إلى مساحة عمل Log Analytics. لمزيد من المعلومات، راجع نظرة عامة على عامل Log Analytics.

تُظهر لقطة الشاشة التالية نموذج تكوين عامل لأجهزة NiFi VMs. يخزن الجدول Perf البيانات التي تم جمعها.

لقطة شاشة تعرض نافذة الإعدادات المتقدمة. يتم تمييز قائمة Data وLinux Performance Counters. إعدادات عداد الأداء مرئية.

فيما يلي نموذج استعلام تطبيق NiFi Perfسجلات :

let cluster_name = {ComputerName};
// The hourly average of CPU usage across all computers.
Perf
| where Computer contains {ComputerName}
| where CounterName == "% Processor Time" and InstanceName == "_Total"
| where ObjectName == "Processor"
| summarize CPU_Time_Avg = avg(CounterValue) by bin(TimeGenerated, 30m), Computer

ينتج عن هذا الاستعلام تقرير مثل ذلك الموجود في لقطة الشاشة هذه:

لقطة شاشة لمخطط خطي. تظهر الأسطر النسبة المئوية لوحدة المعالجة المركزية التي استخدمتها أجهزة NiFi الظاهرية على مدى فترة أربع ساعات.

التنبيهات

استخدم مراقباً لإنشاء تنبيهات بشأن صحة وأداء نظام المجموعة NiFi. تتضمن أمثلة التنبيهات ما يلي:

  • تجاوز إجمالي عدد قوائم الانتظار حد.
  • قيمة BytesWritten أقل من الحد المتوقع.
  • قيمة FlowFilesReceived أقل من الحد الأدنى.
  • نظام مجموعة أجهزة غير صحية.

لمزيد من المعلومات بشأن إعداد التنبيهات في الشاشة، راجع نظرة عامة على التنبيهات في Microsoft Azure.

معلمات التكوين

تناقش الأقسام التالية التكوينات الموصى بها وغير الافتراضية لـ NiFi وتوابعها، بما في ذلك ZooKeeper وJava. هذه الإعدادات مناسبة لأحجام أنظمة مجموعة الأجهزة الممكنة في السحابة. قم بتعيين الخصائص في ملفات التكوين التالية:

  • $NIFI_HOME/conf/nifi.properties
  • $NIFI_HOME/conf/bootstrap.conf
  • $ZOOKEEPER_HOME/conf/zoo.cfg
  • $ZOOKEEPER_HOME/bin/zkEnv.sh

للحصول على معلومات تفصيلية بشأن ملفات وخصائص التكوين المتاحة، راجع إرشاد مسؤول نظام Apache NiFi وإرشاد مسؤول ZooKeeper.

NiFi

لتوزيع Azure، ضع في اعتبارك تعديل الخصائص في $NIFI_HOME/conf/nifi.properties. يسرد الجدول التالي أهم الخصائص. لمزيد من التوصيات والتفاصيل، راجع قوائم بريد Apache NiFi.

المعلمة ‏‏الوصف‬ الإعداد الافتراضي التوصية
nifi.cluster.node.connection.timeout كم من الوقت ينتظر عند فتح اتصال بعقد نظام المجموعة الأجهزة الأخرى. 5 seconds 60 ثانية
nifi.cluster.node.read.timeout كم من الوقت ينتظر الرد عند تقديم طلب لعقدة نظام المجموعة الأجهزة الأخرى. 5 seconds 60 ثانية
nifi.cluster.protocol.heartbeat.interval كم مرة يتم إرسال رسالة كشف أخطاء الاتصال مرة أخرى إلى منسق نظام المجموعة الأجهزة. 5 seconds 60 ثانية
nifi.cluster.node.max.concurrent.requests ما هو مستوى التوازي الذي يجب استخدامه عند تكرار استدعاءات HTTP مثل استدعاءات REST API لعقد مجموعة الأجهزة الأخرى. 100 500
nifi.cluster.node.protocol.threads حجم تجمع مؤشر الترابط الأولي للاتصالات بين نظام المجموعة/الاتصالات المنسوخة نسخا متماثلا. 10 50
nifi.cluster.node.protocol.max.threads الحد الأقصى لعدد مؤشرات الترابط التي يجب استخدامها للاتصالات بين نظام المجموعة/المنسوخة نسخا متماثلا. 50 75
nifi.cluster.flow.election.max.candidates عدد العقد التي يجب استخدامها عند تحديد التدفق الحالي. هذه القيمة تقصر التصويت على الرقم المحدد. فارغ 75
nifi.cluster.flow.election.max.wait.time كم من الوقت تنتظر العقد قبل أن تقرر ما هو التدفق الحالي. 5 دقائق 5 دقائق

سلوك نظام المجموعة الأجهزة

عندما تقوم بتكوين مجموعة الأجهزة، ضع في اعتبارك النقاط التالية.

المهلة

لضمان الحالة العامة لمجموعة الأجهزة وعقدها، قد يكون من المفيد زيادة المهلات. تساعد هذه الممارسة على ضمان ألا تنجم الأعطال عن مشاكل عابرة في الشبكة أو أحمال عالية.

في النظام الموزع، يختلف أداء الأنظمة الفردية. يشمل هذا الاختلاف اتصالات الشبكة وزمن انتقال، والذي يؤثر عادةً على الاتصال بين العقد وبين مجموعات الأجهزة. يمكن أن تتسبب البنية الأساسية للشبكة أو النظام نفسه في حدوث هذا الاختلاف. نتيجة لذلك، من المحتمل جداً أن يكون احتمال الإعجاب في مجموعات كبيرة من الأنظمة. في تطبيقات Java قيد التحميل، يمكن أن تؤثر التوقفات المؤقتة في تجميع البيانات المهملة (GC) في جهاز Java الظاهري (JVM) أيضاً على أوقات استجابة الطلب.

استخدم الخصائص في الأقسام التالية لتكوين المهلات لتناسب احتياجات نظامك:

nifi.cluster.node.connection.timeout وnifi.cluster.node.read.timeout

الـ nifi.cluster.node.connection.timeout تحدد الخاصية مدة الانتظار عند فتح اتصال. الـ nifi.cluster.node.read.timeout تحدد الخاصية مدة الانتظار عند تلقي البيانات بين الطلبات. القيمة الافتراضية لكل خاصية خمس ثوان. تنطبق هذه الخصائص على طلبات عقدة إلى عقدة. تساعد زيادة هذه القيم في التخفيف من العديد من المشكلات ذات الصلة:

  • أن يتم قطع الاتصال من قبل منسق نظام المجموعة بسبب انقطاعات في رسالة كشف أخطاء الاتصال
  • فشل التدفق من المنسق عند الانضمام إلى نظام المجموعة
  • إنشاء اتصالات من موقع إلى موقع (S2S) وموازنة الحمل

ما لم تكن مجموعة نظام المجموعة بك تحتوي على مجموعة تغيير الحجم صغيرة جداً، مثل ثلاث عقد أو أقل، فاستخدم قيماً أكبر من القيم الافتراضية.

nifi.cluster.protocol.heartbeat.interval

كجزء من إستراتيجية تجميع NiFi، تصدر كل عقدة رسالة كشف أخطاء الاتصال لتوصيل حالتها الصحية. بشكل افتراضي، ترسل العقد رسالة كشف أخطاء الاتصال كل خمس ثوان. إذا اكتشف منسق نظام المجموعة أن ثماني رسائل لكشف أخطاء الاتصال من عقدة قد فشلت، فإنه يفصل العقدة. قم بزيادة الفاصل الزمني الذي تم تعيينه في الخاصية nifi.cluster.protocol.heartbeat.interval للمساعدة في استيعاب رسالة كشف أخطاء الاتصال البطيئة ومنع نظام المجموعة من فصل العقد دون داع.

التزامن

استخدم الخصائص في الأقسام التالية لتكوين إعدادات التزامن:

nifi.cluster.node.protocol.threads وnifi.cluster.node.protocol.max.threads

nifi.cluster.node.protocol.max.threads تحدد خاصية الحد الأقصى لعدد مؤشرات الترابط التي يجب استخدامها في اتصالات كل أنظمة المجموعة مثل موازنة تحميل S2S وتجميع واجهة UI. الافتراضي لهذه الخاصية هو 50 مؤشر ترابط. بالنسبة لأنظمة المجموعات الكبيرة، قم بزيادة هذه القيمة لحساب العدد الأكبر من الطلبات التي تتطلبها هذه العمليات.

nifi.cluster.node.protocol.threadsتحدد الخاصية الحجم الأولي لمجمع مؤشرات الترابط. القيمة الافتراضية هي 10 مؤشرات ترابط. هذه القيمة هي الحد الأدنى. ينمو حسب الحاجة حتى يصل إلى الحد الأقصى المحدد في nifi.cluster.node.protocol.max.threads. قم بزيادة nifi.cluster.node.protocol.threads قيمة لأنظمة المجموعة التي تستخدم تغييراً واسعاً للحجم تم تعيينه عند التشغيل.

nifi.cluster.node.max.concurrent.requests

تحتاج العديد من طلبات HTTP مثل استدعاءات REST API واستدعاءات UI إلى النسخ المتماثل إلى العقد الأخرى في أنظمة المجموعة. مع نمو حجم نظام المجموعة، يتم تكرار عدد متزايد من الطلبات. nifi.cluster.node.max.concurrent.requestsتحدد الخاصية عدد الطلبات المعلقة. يجب أن تتجاوز قيمتها حجم مجموعة أجهزة الكمبيوتر المتوقع. القيمة الافتراضية هي 100 طلب متزامن. ما لم تكن تقوم بتشغيل نظام المجموعة صغيرة من ثلاث عقد أو أقل، امنع الطلبات الفاشلة عن طريق زيادة هذه القيمة.

اختيار التدفق

استخدم الخصائص في الأقسام التالية لتكوين إعدادات انتخابات التدفق:

nifi.cluster.flow.election.max.candidates

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

بشكل افتراضي، تكون الخاصية nifi.cluster.flow.election.max.candidates هي أقصى وقت انتظار تحدده الخاصية nifi.cluster.flow.election.max.wait.time. عندما تكون هذه القيمة عالية جداً، يمكن أن يكون بدء التشغيل بطيئاً. القيمة الافتراضية لـ nifi.cluster.flow.election.max.wait.time خمس دقائق. عيّن الحد الأقصى لعدد العناصر عامل التصفية على قيمة غير فارغة مثل 1 أو أكبر للتأكد من أن فترة الانتظار لم تعد مطلوبة. إذا قمت بتعيين هذه الخاصية، فقم بتعيين قيمة تتوافق مع حجم نظام المجموعة أو جزء الأغلبية من حجم نظام المجموعة المتوقع. بالنسبة لنظام المجموعات الصغيرة الثابتة المكونة من 10 عقد أو أقل، قم بتعيين هذه القيمة على عدد العقد في نظام المجموعة.

nifi.cluster.flow.election.max.wait.time

في بيئة السحابة المرنة، يؤثر وقت توفير المضيفين على وقت بدء تشغيل التطبيق. nifi.cluster.flow.election.max.wait.timeتحدد الخاصية مدة انتظار NiFi قبل اتخاذ قرار بشأن التدفق. اجعل هذه القيمة تتناسب مع وقت التشغيل الإجمالي لأنظمة المجموعة بحجمها الأولي. في الاختبار الأولي، خمس دقائق أكثر من كافية في جميع مناطق Azure مع أنواع المثيلات الموصى بها. ولكن يمكنك زيادة هذه القيمة إذا تجاوز وقت التوفير بشكل منتظم الوقت الافتراضي.

Java

نوصي باستخدام إصدار LTS من Java. من بين هذه الإصدارات، يُفضل Java 11 قليلاً على Java 8 لأن Java 11 يدعم تنفيذ تجميع البيانات المهملة بشكل أسرع. ومع ذلك، من الممكن الحصول على توزيع NiFi عالي الأداء باستخدام أي من الإصدارين.

تناقش الأقسام التالية تكوينات JVM الشائعة لاستخدامها عند تشغيل NiFi. قم بتعيين معلمات JVM في ملف تكوين التمهيد في $NIFI_HOME/conf/bootstrap.conf.

جامع المهملات

إذا كنت تقوم بتشغيل Java 11، فإننا نوصي باستخدام أداة جامع المهملات G1 (G1GC) في معظم المواقف. قام G1GC بتحسين الأداء على ParallelGC لأن G1GC يقلل من طول فترات توقف GC إيقافاً مؤقتاً. G1GC هو الإعداد الافتراضي في Java 11، ولكن يمكنك تهيئته بشكل صريح عن طريق تعيين القيمة التالية في bootstrap.conf:

java.arg.13=-XX:+UseG1GC

إذا كنت تقوم بتشغيل Java 8، فلا تستخدم G1GC. استخدم ParallelGC بدلاً من ذلك. هناك أوجه قصور في تنفيذ Java 8 لـ G1GC تمنعك من استخدامه مع تطبيقات المستودع الموصى بها. ParallelGC أبطأ من G1GC. ولكن مع ParallelGC، لا يزال بإمكانك توزيع NiFi عالي الأداء باستخدام Java 8.

كومة ذاكرة مؤقتة

تحدد مجموعة الخصائص في bootstrap.conf ملف تكوين كومة ذاكرة مؤقتة NiFi JVM. للحصول على تدفق قياسي، قم بتكوين كومة ذاكرة مؤقتة 32-GB باستخدام هذه الإعدادات:

java.arg.3=-Xmx32g
java.arg.2=-Xms32g

لاختيار حجم كومة الذاكرة المؤقتة الأمثل لتطبيقه على عملية JVM، ضع في اعتبارك عاملين:

  • خصائص تدفق البيانات
  • الطريقة التي تستخدم بها NiFi الذاكرة في معالجتها

للحصول على وثائق مفصلة، راجع Apache NiFi في العمق.

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

عند ضبط إعدادات ذاكرة JVM، ضع في اعتبارك هذه العوامل المهمة:

  • عدد FlowFiles، أو سجلات بيانات NiFi النشطة في فترة معينة. يتضمن هذا الرقم ملفات FlowFiles التي تم الضغط عليها مرة أخرى أو في قائمة الانتظار.

  • عدد السمات التي تم تحديدها في FlowFiles.

  • مقدار الذاكرة الذي يحتاجه المعالج لمعالجة جزء معين من المحتوى.

  • الطريقة التي يعالج بها المعالج البيانات:

    • بيانات متدفقة
    • استخدام معالجات التسجيل
    • الاحتفاظ بجميع البيانات في الذاكرة دفعة واحدة

هذه التفاصيل مهمة. أثناء المعالجة، يحتفظ NiFi بالمراجع والسمات لكل ملف FlowFile في الذاكرة. في ذروة الأداء، يتناسب حجم الذاكرة التي يستخدمها النظام مع عدد ملفات FlowFiles الحية وجميع السمات التي تحتوي عليها. يتضمن هذا الرقم ملفات FlowFiles في قائمة الانتظار. يمكن لـ NiFi التبديل إلى القرص. لكن تجنب هذا الخيار لأنه يضر بالأداء.

ضع في اعتبارك أيضاً استخدام ذاكرة العنصر الأساسي. على وجه التحديد، اجعل كومة الذاكرة المؤقتة كبيرة بما يكفي للاحتفاظ بالعناصر في الذاكرة. ضع في اعتبارك هذه النصائح لتكوين إعدادات الذاكرة:

  • قم بتشغيل التدفق الخاص بك باستخدام البيانات التمثيلية والحد الأدنى من الضغط الخلفي بالبدء بالإعداد -Xmx4G ثم زيادة الذاكرة بشكل متحفظ حسب الحاجة.
  • قم بتشغيل التدفق الخاص بك ببيانات تمثيلية وأعلى ضغط رجعي بالبدء بالإعداد -Xmx4G ثم زيادة حجم نظام المجموعة بشكل متحفظ حسب الحاجة.
  • قم بإنشاء ملف تعريف للتطبيق أثناء تشغيل التدفق باستخدام أدوات مثل VisualVM وYourKit.
  • إذا لم تؤدِّ الزيادات المتحفظة في كومة الذاكرة المؤقتة إلى تحسين الأداء بشكل ملحوظ، ففكر في إعادة تصميم التدفقات والمعالجات والجوانب الأخرى لنظامك.
معلمات JVM إضافية

يسرد الجدول التالي خيارات JVM الإضافية. كما يوفر القيم التي عملت بشكل أفضل في الاختبار الأولي. لاحظت الاختبارات نشاط GC واستخدام الذاكرة واستخدمت جمع معلومات الدقيق.

المعلمة ‏‏الوصف‬ JVM الافتراضي التوصية
InitiatingHeapOccupancyPercent مقدار كومة الذاكرة المؤقتة المستخدمة قبل بدء دورة وضع المشغّل. 45 35
ParallelGCThreads عدد مؤشرات الترابط التي يستخدمها GC. تم تحديد نقطة الارتكاز هذه للحد من التأثير الكلي على النظام. 5/8 من عدد وحدات المعالجة المركزية الظاهرية 8
ConcGCThreads عدد مؤشرات الترابط GC المراد تشغيلها بالتوازي. يتم زيادة هذه القيمة لحساب ParallelGCThreads نقطة ارتكاز. 1/4 من قيمة ParallelGCThreads 4
G1ReservePercent النسبة المئوية للذاكرة الاحتياطية للاحتفاظ بها خالية. يتم زيادة هذه القيمة لتجنب استنفاد الفضاء، ما يساعد على تجنب GC الكامل. 10 20
UseStringDeduplication ما إذا كانت ستتم محاولة تحديد وإزالة المراجع لسلاسل متطابقة. يمكن أن يؤدي تشغيل هذه الميزة إلى توفير الذاكرة. - present

قم بتكوين هذه الإعدادات عن طريق إضافة الإدخالات التالية إلى NiFi bootstrap.conf:

java.arg.17=-XX:+UseStringDeduplication
java.arg.18=-XX:G1ReservePercent=20
java.arg.19=-XX:ParallelGCThreads=8
java.arg.20=-XX:ConcGCThreads=4
java.arg.21=-XX:InitiatingHeapOccupancyPercent=35

ZooKeeper

لتحسين التسامح مع الخطأ، قم بتشغيل ZooKeeper كنظام المجموعة. اتبع هذا النهج على الرغم من أن معظم عمليات توزيع NiFi تضع عبئاً متواضعاً نسبياً على ZooKeeper. قم بتشغيل الأنظمة المجموعة لـ ZooKeeper بشكل صريح. بشكل افتراضي، يشغل ZooKeeper في وضع الخادم الفردي. للحصول على معلومات مفصلة، راجع نظام مجموعة (متعدد الخوادم) في إرشاد مسؤول ZooKeeper.

باستثناء إعدادات تكوين أنظمة المجموعات، استخدم القيم الافتراضية لتكوين ZooKeeper الخاص بك.

إذا كان لديك مجموعة NiFi كبيرة، فقد تحتاج إلى استخدام عدد أكبر من خوادم ZooKeeper. بالنسبة لأحجام نظام المجموعة الأصغر، تكون أحجام VM الأصغر والأقراص المُدارة القياسية لـ SSD كافية.

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكاتب الرئيسي:

لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.

الخطوات التالية

جاءت المواد والتوصيات الواردة في هذه الوثيقة من عدة مصادر:

  • الاختبار
  • أفضل ممارسات Azure
  • معلومات مجتمع NiFi وأفضل الممارسات والتوثيق

لمزيد من المعلومات، راجع الموارد التالية: