أفضل الممارسات لاستخدام Azure Data Lake Storage Gen2
تقدم هذه المقالة دليل إرشادي لأفضل الممارسات التي تساعدك على تحسين الأداء وتقليل التكاليف وتأمين حسابك Data Lake Storage Gen2 Azure Storage الذي تم تمكينه.
للحصول على اقتراحات عامة حول بناء مستودع بيانات، راجع هذه المقالات:
- نظرة عامة على Azure Data Lake Storage لسيناريو إدارة البيانات والتحليلات
- توفير حسابات Azure Data Lake Storage Gen2 الثالثة لكل منطقة هبوط بيانات
البحث عن الوثائق
لا تُعد Azure Data Lake Storage Gen2 خدمة مخصصة أو نوع حساب. إنها مجموعة من الإمكانات التي تدعم أحمال العمل التحليلية لمعدل النقل. تقدم وثائق Data Lake Storage Gen2 أفضل الممارسات والإرشادات لاستخدام هذه الإمكانات. بالنسبة لجميع الجوانب الأخرى لإدارة الحساب مثل إعداد أمان الشبكة، والتصميم لقابلية الوصول العالية، والتعافي من الكوارث، راجع محتوى وثائق تخزين Blob.
تقييم دعم الميزات والمشكلات الشائعة
استخدم النمط التالي أثناء تكوين حسابك لاستخدام ميزات تخزين Blob.
راجع مقالة دعم ميزة تخزين كائن ثنائي كبير الحجم في حسابات تخزين Azure لتحديد ما إذا كانت الميزة مدعومة بالكامل في حسابك. بعض الميزات لم يتوفر لها دعم بعد أو لديها دعم جزئي في الحسابات الممكنة Data Lake Storage Gen2. دائما هناك توسع لنطاق دعم الميزات، لذا تأكد من مراجعة هذه المقالة بشكل دوري للحصول على التحديثات.
راجع المقالة المشكلات الشائعة في Azure Data Lake Storage Gen2 لمعرفة ما إذا كانت هناك أي قيود أو إرشادات خاصة حول الميزة التي تنوي استخدامها.
افحص مقالات الميزات بحثا عن أي إرشادات خاصة بالحسابات الممكنة Data Lake Storage Gen2.
فهم المصطلحات المستخدمة في الوثائق
أثناء التنقل بين مجموعات المحتوى، ستلاحظ بعض الاختلافات الطفيفة في المصطلحات. على سبيل المثال، سيستخدم المحتوى المعروض في وثائق تخزين Blob المصطلح blob بدلا من الملف. من الناحية الفنية، تصبح الملفات التي تستوعبها في حساب التخزين الخاص بك نقاطا في حسابك. لذلك، فإن المصطلح صحيح. ومع ذلك، يمكن أن يسبب مصطلح blob ارتباكا إذا كنت معتادا على ملف المصطلح. سترى أيضا مصطلح الحاوية المستخدم للإشارة إلى نظام الملفات. اعتبر هذه المصطلحات مترادفة.
الوضع المتميز
إذا كانت أحمال العمل تتطلب زمن انتقال منخفض و/أو تتطلب عددا كبيرا من عمليات إخراج/الإدخال لكل ثانية (IOP)، ففكر في استخدام حساب تخزين كتلة متميز. يتيح هذا النوع من الحسابات البيانات عبر أجهزة عالية الأداء. يتم تخزين البيانات على محركات الأقراص ذات الحالة الصلبة (SSDs) التي تم تحسينها لزمن انتقال منخفض. توفر محركات الأقراص ذات الحالة الصلبة معدل نقل أعلى مقارنةً بالأقراص الصلبة التقليدية. تكاليف التخزين للأداء المتميز أعلى، ولكن تكاليف المعاملات أقل. لذلك، إذا نفذت أحمال العمل الخاصة بك عددا كبيرا من المعاملات، يمكن أن يكون حساب كائن ثنائي كبير الحجم لكتلة الأداء المتميز اقتصاديا.
إذا كان حساب التخزين لديك سيستخدم في التحليلات، فإننا نوصي بشدة استخدام Azure Data Lake Storage Gen2 إلى جانب حساب تخزين Premium للكائنات الثنائية كبيرة الحجم. يشار إلى هذا المزيج من استخدام حسابات تخزين blob المميزة إلى جانب حساب ممكن Data Lake Storage باسم الطبقة المميزة Azure Data Lake Storage.
التحسين لاستيعاب البيانات
عند استيعاب البيانات من نظام مصدر، أحيانا يحدث ازدحام في الجهاز المصدر أو أجهزة الشبكة المصدر أو اتصال الشبكة بحساب التخزين الخاص بك.
الأجهزة المصدر
سواء كنت تستخدم الأجهزة المحلية أو الأجهزة الظاهرية (VMs) في Azure، تأكد من تحديد الأجهزة المناسبة بعناية. بالنسبة لأجهزة القرص، فكر في استخدام محركات الأقراص ذات الحالة الصلبة (SSD) واختر أجهزة القرص التي تحتوي على محور دوران أسرع. بالنسبة لأجهزة الشبكة، استخدم أسرع وحدات تحكم واجهة الشبكة (NIC) قدر الإمكان. على مدخل Azure، نوصي باستخدام أجهزة Azure D14 الظاهرية، التي تحتوي على أجهزة القرص والشبكات القوية المناسبة.
اتصال الشبكة بحساب التخزين
قد يحدث ازدحام في اتصال الشبكة بين بيانات المصدر وحساب التخزين الخاص بك في بعض الأحيان. عندما تكون بيانات المصدر الخاصة بك على جهاز محلي، فكر في استخدام ارتباط مخصص مع Azure ExpressRoute. إذا كانت بيانات المصدر الخاصة بك موجودة في Azure، فستحصل على أداء أفضل عندما تكون البيانات في نفس منطقة Azure مثل حسابك الذي تم تمكينه Data Lake Storage Gen2.
تكوين أدوات استيعاب البيانات لتحقيق أقصى قدر من التوازي
لتحقيق أفضل أداء، استخدم كل معدلات النقل المتاحة من خلال إجراء أكبر عدد ممكن من عمليات القراءة ونقل المعلومات بالتوازي.
يلخص الجدول التالي الإعدادات الرئيسية للعديد من أدوات الاستيعاب الشائعة.
| الأداة | إعدادات |
|---|---|
| DistCp | -m (معين) |
| Azure Data Factory | parallelCopies |
| Sqoop | fs.azure.block.size, -m (معين) |
إشعار
يعتمد الأداء العام لعمليات الاستيعاب على عوامل أخرى خاصة بالأداة التي تستخدمها لاستيعاب البيانات. للحصول على أفضل إرشادات حديثة، راجع الوثائق الخاصة بكل أداة تنوي استخدامها.
يمكن توسيع نطاق حسابك لتوفير معدل النقل اللازم لجميع سيناريوهات التحليلات. بشكل افتراضي، يوفر الحساب الذي تم تمكين Data Lake Storage Gen2 معدل نقل عالي في تكوينه الافتراضي لتلبية احتياجات فئة واسعة من حالات الاستخدام. في حالة الوصول للحد الافتراضي، يمكن تكوين الحساب لتوفير مزيد من معدل النقل وذلك بالتواصل مع دعم Azure.
بنية مجموعات البيانات
فكر في التخطيط المسبق لبنية بياناتك. يمكن أن يؤثر تنسيق الملف وحجم الملف وبنية الدليل على الأداء والتكلفة.
تنسيقات الملفات
يمكن استيعاب البيانات بتنسيقات مختلفة. يمكن أن تظهر البيانات بتنسيقات قابلة للقراءة البشرية مثل JSON أو CSV أو XML أو بتنسيقات ثنائية مضغوطة مثل .tar.gz. ويمكن أن تأتي البيانات بأحجام مختلفة أيضا. يمكن أن تتكون البيانات من ملفات كبيرة (بضعة تيرابايت) مثل البيانات من تصدير جدول SQL من الأنظمة المحلية الخاصة بك. يمكن أن تأتي البيانات أيضا في شكل عدد كبير من الملفات الصغيرة (بضعة كيلوبايت) مثل البيانات من الأحداث في الوقت الفعلي من حل إنترنت الأشياء (IoT). يمكنك تحسين الكفاءة والتكلفة عن طريق اختيار تنسيق وحجم ملف مناسب.
يدعم Hadoop مجموعة من تنسيقات الملفات المحسنة لتخزين البيانات المنظمة ومعالجتها. بعض التنسيقات الشائعة هي تنسيق Avro و Parquet و Optimized Row Columnar (ORC). كل هذه التنسيقات تكون على شكل ملفات ثنائية يمكن قراءتها آليا. يتم ضغطها لمساعدتك في إدارة حجم الملف. يحتوي كل ملف على مخطط مضمن، مما يجعل الملفات واضحة. الفرق بين هذه التنسيقات هو في كيفية تخزين البيانات. يقوم Avro بتخزين البيانات بتنسيق يستند إلى الصف ويقوم تنسيقا Parquet و ORC بتخزين البيانات بتنسيق عمودي.
فكر في استخدام تنسيق ملف Avro في الحالات التي تكون فيها أنماط الإدخال/الإخراج كثيفة الكتابة، أو تفضل أنماط الاستعلام استرداد صفوف متعددة من السجلات بالكامل. على سبيل المثال، يعمل تنسيق Avro بشكل جيد مع ناقل رسائل مثل Event Hubs أو Kafka الذي يكتب أحداث/رسائل متعددة متتالية.
ضع في اعتبارك تنسيقات ملفات Parquet و ORC عندما تكون أنماط الإدخال/الإخراج كثيفة القراءة أو عندما تركز أنماط الاستعلام على مجموعة فرعية من الأعمدة في السجلات. يمكن تحسين معاملات القراءة لاسترداد أعمدة معينة بدلا من قراءة السجل بأكمله.
Apache Parquet هو تنسيق ملف مصدر مفتوح تم تحسينه للقراءة الكثيفة لتحليلات البنية الأساسية لبرنامج ربط العمليات التجارية. تتيح لك بنية التخزين العمودية لـ Parquet تخطي البيانات غير الهامة لك. تعد استعلاماتك أكثر كفاءة لأن بإمكانها تضيق نطاق البيانات التي يجب إرسالها من التخزين إلى محرك التحليلات. أيضا، نظرا لأنه يتم تخزين أنواع البيانات المماثلة (لعمود) معا، يدعم Parquet أنظمة ضغط البيانات وترميزها الفعالة التي يمكن أن تقلل من تكاليف تخزين البيانات. تتمتع خدمات مثل Azure Synapse Analytics و Azure Databricks و Azure Data Factory بوظائف أصلية تستفيد من تنسيقات ملفات Parquet.
حجم الملف
تعطي الملفات الأكبر حجما أداء أفضل وتكاليف أقل.
عادة ما تحتوي محركات التحليلات مثل HDInsight على نفقات عامة لكل ملف تتضمن مهام مثل الإدراج والتحقق من الوصول وتنفيذ عمليات بيانات التعريف المختلفة. إذا قمت بتخزين البيانات الخاصة بك كملفات صغيرة كثيرة، يمكن أن يؤثر ذلك سلبًا على الأداء. بشكل عام، احرص على تنظيم بياناتك في ملفات كبيرة الحجم للحصول على أداء أفضل (256 ميجابايت إلى 100 جيجابايت ). قد تواجه بعض المحركات والتطبيقات مشكلة في معالجة الملفات التي يزيد حجمها عن 100 جيجابايت بكفاءة.
يمكن أن تؤدي زيادة حجم الملف أيضا إلى خفض تكاليف المعاملات. تتم فوترة عمليات القراءة والكتابة بزيادات قدرها 4 ميغابايت بحيث يتم تحصيل رسوم منك مقابل التشغيل سواء كان الملف يحتوي على 4 ميغابايت أو بضعة كيلوبايت فقط. لمزيد من المعلومات، راجع Azure Data Lake Storage Gen2.
في بعض الأحيان، مسارات البيانات محدودة السيطرة على البيانات البسيطة، التي لديها الكثير من الملفات الصغيرة. بشكل عام، نوصي بأن يحتوي نظامك على نوع من العمليات لتجميع الملفات الصغيرة في ملفات أكبر لتستخدمها التطبيقات النهائية. إذا كنت تعالج البيانات في الوقت الحقيقي، يمكنك استخدام محرك دفق في الوقت الحقيقي (مثل Azure Stream Analytics أو Spark Streaming) مع وسيط رسائل (مثل مراكز الأحداث أو Apache Kafka) لتخزين بياناتك كملفات أكبر. أثناء تجميع الملفات الصغيرة في ملفات بحجم أكبر، فكر في حفظها بتنسيق محسن للقراءة مثل Apache Parquet للمعالجة النهائية.
بنية الدليل
لكل حمل عمل متطلبات مختلفة تتعلق بكيفية استهلاك البيانات، ولكن هذه بعض التخطيطات الشائعة التي يجب مراعاتها عند العمل مع إنترنت الأشياء (IoT) أو سيناريوهات الدفعات أو عند تحسين بيانات السلاسل الزمنية.
بنية إنترنت الأشياء
في أحمال عمل إنترنت الأشياء، قد يكون هناك أحجام كبيرة من البيانات التي يتم استيعابها وتربط عدد كبير من المنتجات والأجهزة والمؤسسات والعملاء. من المهم التخطيط المسبق لتخطيط الدليل للتنظيم والأمان ومعالجة بيانات المستهلكين النهائيين بفاعلية. قد يكون القالب العام الذي يجب التفكير به هو التخطيط التالي:
- {Region}/{SubjectMatter(s)}/{yyyy}/{mm}/{dd}/{hh}/
على سبيل المثال، قد تبدو بيانات تتبع الاستخدام عن بعد لهبوط محرك طائرة داخل المملكة المتحدة مثل البنية التالية:
- المملكة المتحدة/الطائرات/BA1293/Engine1/2017/08/11/12/
في هذا المثال، من خلال وضع التاريخ في نهاية بنية الدليل، يمكنك استخدام قوائم التحكم في الوصول لتأمين المناطق والأشياء الهامة للمستخدمين والمجموعات بسهولة أكبر. إذا وضعت بنية التاريخ في البداية، فسيكون من الصعب تأمين هذه المناطق والموضوعات. على سبيل المثال، إذا كنت ترغب في توفير الوصول فقط إلى بيانات المملكة المتحدة أو طائرات معينة، فستحتاج إلى تطبيق إذن منفصل للعديد من الدلائل ضمن دليل كل ساعة. ومن شأن هذه البنية أيضا أن تزيد من عدد الدلائل مع مرور الوقت.
بنية الوظائف الدفعية
النهج الشائع الاستخدام في معالجة دفعة بيانات هو وضع البيانات في دليل "في". بعد ذلك، بمجرد معالجة البيانات، ضع البيانات الجديدة في دليل "خارج" للعمليات النهائية لاستهلاكها. تستخدم بنية الدليل هذه أحيانا للمهام التي تتطلب معالجة الملفات الفردية، وقد لا تتطلب معالجة متوازية بشكل كبير عبر مجموعات البيانات الكبيرة. مثل بنية إنترنت الأشياء الموصى بها أعلاه، تحتوي بنية الدليل الجيدة على أدلة على المستوى الأصلي لأشياء مثل المنطقة والموضوعات (على سبيل المثال، المؤسسة أو المنتَج أو المنتِج). ضع في اعتبارك التاريخ والوقت في البنية للسماح بتنظيم أفضل وعمليات بحث مصفاة والأمان والأتمتة في المعالجة. يتم تحديد مستوى نقاوة بنية التاريخ من خلال الفاصل الزمني الذي يتم فيه تحميل البيانات أو معالجتها، مثل كل ساعة أو يوميا أو حتى شهريا.
في بعض الأحيان لا تنجح معالجة الملفات بسبب تلف البيانات أو التنسيقات غير المتوقعة. في مثل هذه الحالات، قد تستفيد بنية الدليل من مجلد /bad لنقل الملفات لإجراء مزيد من الفحص. قد تتعامل الوظيفة الدفعية أيضا مع الإبلاغ عن هذه الملفات السيئة أو الإخطار عنها للتدخل اليدوي. فكر في بنية القالب التالية:
- {Region}/{SubjectMatter(s)}/In/{yyyy}/{mm}/{dd}/{hh}/
- {Region}/{SubjectMatter(s)}/Out/{yyyy}/{mm}/{dd}/{hh}/
- {Region}/{SubjectMatter(s)}/Bad/{yyyy}/{mm}/{dd}/{hh}/
على سبيل المثال، تتلقى شركة تسويق مقتطفات بيانات يومية من تحديثات عملائها في أمريكا الشمالية. فيما يلي شكل المقتطف قبل المعالجة وبعدها:
- NA/Extracts/ACMEPaperCo/In/2017/08/14/updates_08142017.csv
- NA/Extracts/ACMEPaperCo/Out/2017/08/14/processed_updates_08142017.csv
في الحالة الشائعة لبيانات الدفعات التي تعالج مباشرة في قواعد بيانات مثل Hive أو قواعد بيانات SQL التقليدية، ليست هناك حاجة إلى دليل /in أو /out لأن الإخراج ينتقل بالفعل إلى مجلد منفصل لجدول Hive أو قاعدة بيانات خارجية. على سبيل المثال، ستصل المستخلصات اليومية من العملاء إلى الأدلة الخاصة بهم. بعد ذلك، ستقوم خدمة مثل Azure Data Factory أو Apache Oozie أو Apache Airflow بتشغيل وظيفة Hive أو Spark يوميا لمعالجة البيانات وكتابتها في جدول Hive.
بنية بيانات السلاسل الزمنية
بالنسبة لأحمال عمل Hive، يمكن أن يساعد تشذيب قسم بيانات السلاسل الزمنية بعض الاستعلامات على قراءة مجموعة فرعية فقط من البيانات، مما يحسن الأداء.
غالبا ما تضع البنية الأساسية لبرنامج ربط العمليات التجارية التي تستوعب بيانات السلاسل الزمنية ملفاتها بتسمية منظمة للملفات والمجلدات. نذكر فيما يلي مثال شائع للبيانات التي تم تنظيمها حسب التاريخ:
/DataSet/YYYY/MM/DD/datafile_YYYY_MM_DD.tsv
لاحظ أن معلومات datetime تظهر كمجلدات واسم ملف.
النمط التالي شائعا بالنسبة للتاريخ والوقت
/DataSet/YYYY/MM/DD/HH/mm/datafile_YYYY_MM_DD_HH_mm.tsv
تذكر أن الاختيار الذي تتخذه لتنظيم المجلد والملف يجب أن يحسن أحجام الملفات ذات الأحجام الكبيرة وتكون بعدد معقول من الملفات في كل مجلد.
إعداد الأمان
ابدأ بمراجعة التوصيات الواردة في مقالة توصيات الأمان لتخزين Blob. ستجد إرشادات أفضل الممارسات حول كيفية حماية بياناتك من الحذف العرضي أو الضار، وتأمين البيانات خلف جدار حماية، واستخدام معرف Microsoft Entra كأساس لإدارة الهوية.
ثم راجع المقالة حول نموذج التحكم في الوصول في Azure Data Lake Storage Gen2 للاطلاع على إرشادات خاصة بالحسابات الممكنة Data Lake Storage Gen2. تساعدك هذه المقالة على فهم كيفية استخدام أدوار التحكم في الوصول استناداً إلى دور Azure (Azure RBAC) مع قوائم التحكم في الوصول (ACLs) لفرض أذونات الأمان على الدلائل والملفات في نظام الملفات الهرمي.
استيعاب البيانات ومعالجتها وتحليلها
تتعدد مصادر البيانات وتختلف الطرق التي يمكن من خلالها استيعاب هذه البيانات في حساب ممكن Data Lake Storage Gen2.
على سبيل المثال، يمكنك استيعاب مجموعات كبيرة من البيانات من مجموعات HDInsight وHadoop أو مجموعات أصغر من البيانات المخصصة لتطبيقات النماذج الأولية. يمكنك استيعاب البيانات التي تم دفقها من مصادر مختلفة مثل التطبيقات والأجهزة وأجهزة الاستشعار. بالنسبة لهذا النوع من البيانات، يمكنك استخدام الأدوات لتسجيل البيانات ومعالجتها لكل حدث على حدة في الوقت الفعلي، ثم كتابة الأحداث على دفعات في حسابك. يمكنك أيضًا استيعاب سجلات خادم الويب الذي يحتوي على معلومات مثل محفوظات طلبات الصفحات. بالنسبة إلى بيانات السجل، فكر في كتابة نصوص برمجية أو تطبيقات مخصصة لتحميلها بحيث تتمتع بالمرونة اللازمة لتضمين مكون تحميل البيانات كجزء من تطبيق البيانات الضخمة.
بمجرد توفر البيانات في حسابك، يمكنك تشغيل عملية تحليل البيانات، وإنشاء عرض مرئي للبيانات، بل وتنزيل البيانات إلى جهازك المحلي أو إلى مستودعات أخرى مثل قاعدة بيانات Azure SQL أو مثيل SQL Server.
يوصي الجدول التالي بالأدوات التي يمكنك استخدامها لاستيعاب البيانات وتحليلها وعرضها مرئياً وتنزيلها. استخدم الارتباطات التشعبية الموجودة في هذا الجدول للبحث عن إرشادات حول كيفية تكوين كل أداة واستخدامها.
| الغرض | إرشادات الأدوات والأدوات |
|---|---|
| استيعاب البيانات المخصصة | مدخل Azure، Azure PowerShell، Azure CLI، REST،Azure Storage Explorer، Apache DistCp، AzCopy |
| استيعاب البيانات الارتباطية | Azure Data Factory |
| استيعاب سجلات خادم الويب | Azure PowerShell، Azure CLI، REST، Azure SDKs (.NET، Java، Python و Node.js)، Azure Data Factory |
| استيعاب البيانات من نظام مجموعة HDInsight | Azure Data factory، Apache DistCp، AzCopy |
| استيعاب البيانات من نظام مجموعة Hadoop | Azure Data Factory، Apache DistCp، WANdisco LiveData Migrator لـ Azure، Azure Data Box |
| استيعاب مجموعات البيانات الكبيرة (عدة تيرابايت) | Azure ExpressRoute |
| معالجة البيانات وتحليلها | تحليلات Azure Synapse، Azure HDInsight، Databricks |
| تصور البيانات | Power BI، تسريع استعلامAzure Data Lake Storage |
| تنزيل البيانات | مدخل Azure، PowerShell، Azure CLI، REST، Azure SDKs (.NET، Java، Pythonو Node.js)، Azure Storage Explorer، AzCopy، Azure Data Factory، Apache DistCp |
إشعار
لا يعكس هذا الجدول قائمة خدمات Azure الكاملة لدعم Data Lake Storage Gen2. لاستعراض قائمة خدمات Azure المدعومة، راجع خدمات Azure التي تدعم الجيل الثاني من قاعدة التخزين Azure Data.
مراقبة بيانات تتبع الاستخدام
تعد مراقبة الاستخدام والأداء جزءا مهما من تشغيل الخدمة. ومن أمثلة ذلك العمليات المتكررة أو العمليات ذات زمن انتقال عالي أو العمليات التي تسبب تقييد الخدمة.
تتوفر جميع عمليات بيانات تتبع الاستخدام عن بعد لحساب التخزين الخاص بك من خلال سجلات Azure Storage في Azure Monitor. تدمج هذه الميزة حساب التخزين الخاص بك مع Log Analytics و Event Hubs، وفي نفس الوقت تمكنك أيضا من أرشفة السجلات إلى حساب تخزين آخر. للاطلاع على القائمة الكاملة لسجلات المقاييس والموارد والمخطط الخاص بها، راجع مرجع بيانات مراقبة تخزين Azure.
يعتمد مكان تخزين السجلات الذي تختاره على الطريقة التي تخطط للوصول إليها. على سبيل المثال، إذا كنت ترغب في الوصول إلى سجلاتك في الوقت الفعلي تقريبا، وتكون قادرا على ربط الأحداث في السجلات بمقاييس أخرى من Azure Monitor، فيمكنك تخزين سجلاتك في مساحة عمل Log Analytics. ثم استعلم عن سجلاتك باستخدام استعلامات KQL والكاتب، والتي تقوم بتعداد StorageBlobLogs الجدول في مساحة العمل الخاصة بك.
إذا كنت ترغب في تخزين سجلاتك لكل من الاستعلام في وقت قريب من الوقت الحقيقي والاحتفاظ طويل الأمد، فيمكنك تكوين إعدادات التشخيص لإرسال السجلات إلى كل من مساحة عمل Log Analytics وحساب تخزين.
إذا كنت تريد الوصول إلى سجلاتك من خلال محرك استعلام آخر مثل Splunk، يمكنك تكوين إعدادات التشخيص لإرسال السجلات إلى مركز أحداث واستيعاب السجلات من مركز الأحداث إلى الوجهة التي اخترتها.
يمكن تمكين سجلات تخزين Azure في Azure Monitor من خلال قوالب مدخل Azure، و PowerShell و Azure CLI ومدير موارد Azure. بالنسبة لعمليات التوزيع واسع النطاق، يمكن استخدام نهج Azure مع الدعم الكامل لمهام المعالجة. لمزيد من المعلومات، راجع ciphertxt/AzureStoragePolicy.