العمل مع أدوات Azure Functions الأساسية
تتيح لك Azure Functions Core Tools تطوير الوظائف واختبارها على الحاسوب المحلي من موجه الأوامر أو المحطة الطرفية. يمكن لوظائفك المحلية الاتصال بخدمات Azure المباشرة، ويمكنك تصحيح وظائفك على الكمبيوتر المحلي باستخدام وقت تشغيل الوظائف الكامل. يمكنك حتى نشر تطبيق وظيفة لاشتراك Azure الخاص بك.
هام
لا تخلط بين التطوير المحلي وتطوير المدخل في نفس تطبيق الوظيفة. عند إنشاء وتوزيع وظائف من مشروع محلي يجب عدم محاولة الاحتفاظ أو تعديل التعليمة البرمجية للمشروع في المدخل.
تطوير وظائف على الكمبيوتر المحلي ونشرها إلى Azure باستخدام الأدوات الأساسية يتبع الخطوات الأساسية التالية:
المتطلبات الأساسية
تعتمد المتطلبات الأساسية المحددة للأدوات الأساسية على الميزات التي تخطط لاستخدامها:
النشر: تعتمد الأدوات الأساسية حاليا على Azure CLI أو Azure PowerShell للمصادقة باستخدام حساب Azure الخاص بك. وهذا يعني أنه يجب تثبيت إحدى هذه الأدوات لتكون قادرًا على النشر إلى Azure من أدوات Azure الأساسية الوظائف.
تثبيت الملحقات: لتثبيت الملحقات يدويا باستخدام Core Tools، يجب أن يكون لديك .NET Core 3.1 SDK مثبتا. يتم استخدام .NET Core SDK بواسطة Core Tools لتثبيت الملحقات من NuGet. لا تحتاج إلى معرفة .NET لاستخدام ملحقات Azure Functions.
إصدارات Core Tools
توجد أربعة إصدارات من أدوات Azure الأساسية للوظائف. يعتمد الإصدار الذي تستخدمه على بيئة التطوير المحلية واختيار اللغةومستوى الدعم المطلوب.
اختر علامة تبويب إصدار أدناه للتعرف على كل إصدار محدد وإرشادات التثبيت التفصيلية:
يدعم الإصدار 4.x من وقت تشغيل الوظائف. يدعم هذا الإصدار Windows وmacOS وLinux، ويستخدم مديري الحزم الخاصة بالأنظمة الأساسية أو npm للتثبيت. هذا هو الإصدار الموصى به من وقت تشغيل الدالات والأدوات الأساسية.
يمكنك تثبيت إصدار واحد فقط من الأدوات الأساسية على كمبيوتر معين. ما لم يذكر خلاف ذلك، الأمثلة في هذه المقالة هي للإصدار 3.x.
تثبيت الأدوات الأساسية لوظائف Azure
تتضمن أدوات Azure الدالات الأساسية إصدارًا من نفس وقت التشغيل الذي يعمل على تشغيل Azure Functions الذي يمكنك تشغيله على كمبيوتر التطوير المحلي. كما يوفر أوامر لإنشاء دالات، والاتصال Azure، ونشر مشاريع الوظائف.
بدءًا من الإصدار 2.x، تعمل الأدوات الأساسية على Windows، macOS، و Linux.
الخطوات التالية استخدام مثبت Windows (MSI) لتثبيت أدوات الأساسية v4.x. لمزيدٍ من المعلومات حول المثبتات الأخرى المستندة إلى الحزمة، راجع الملف الأساسي أدوات القراءة.
قم بتنزيل وتشغيل مثبت الأدوات الأساسية، استنادًا إلى إصدار Windows:
تغيير إصدارات الأدوات الأساسية
عند التغيير إلى إصدار مختلف من أدوات أساسية، يجب استخدام نفس إدارة الحزمة مثل التثبيت الأصلي للانتقال إلى إصدار حزمة مختلفة. على سبيل المثال، إذا قمت بتثبيت الإصدار 2.x أدوات الأساسية باستخدام npm، يجب استخدام الأمر التالي للترقية إلى الإصدار 3.x:
npm install -g azure-functions-core-tools@3 --unsafe-perm true
إذا استخدمت مثبت Windows (MSI) لتثبيت أدوات ذاكرة أساسية على Windows، يجب إلغاء تثبيت الإصدار القديم من إضافة إزالة البرامج قبل تثبيت إصدار آخر.
إنشاء مشروع دوال محلية
يحتوي دليل مشروع دالات على الملفات والمجلدات التالية دون النظر إلى اللغة:
| اسم الملف | الوصف |
|---|---|
| host.json | لمعرفة المزيد، راجع مرجع host.json. |
| local.settings.json | الإعدادات تستخدمها الأدوات الأساسية عند التشغيل محليًا، بما في ذلك إعدادات التطبيق. لمعرفة المزيد، راجع ملف الإعدادات المحلية. |
| .gitignore | يمنع نشر local.settings.js على الملف بطريق الخطأ إلى مستودع Git. لمعرفة المزيد، راجع ملف الإعدادات المحلية. |
| .vscode\extensions.json | إعدادات الملف المستخدم عند فتح مجلد المشروع في Visual Studio Code. |
لمعرفة المزيد حول مجلد مشروع الدالات، راجع دليل مطوري Azure Functions.
في إطار المحطة الطرفية أو من موجه الأوامر، قم بتشغيل الأمر التالي لإنشاء المشروع ومستودع Git المحلي:
func init MyFunctionProj
ينشئ هذا المثال مشروع دالات في MyFunctionProj مجلد جديد. تتم مطالبتك باختيار لغة افتراضية لمشروعك.
تنطبق الاعتبارات التالية على تهيئة المشروع:
إذا لم توفر
--worker-runtimeالخيار في الأمر، تتم مطالبتك باختيار لغتك. لمزيدٍ من المعلومات، راجع المرجع.عندما لا توفر اسم مشروع، تتم تهيئة المجلد الحالي.
إذا كنت تخطط لنشر المشروع الخاص بك إلى حاوية Linux مخصصة، استخدم
--dockerالخيار للتأكد من إنشاء Dockerfile للمشروع الخاص بك. لمعرفة المزيد، راجع إنشاء وظيفة على Linux باستخدام نسخة مخصصة.
قد يكون لبعض اللغات اعتبارات إضافية:
بشكل افتراضي، الإصدار 2.x والإصدارات الأحدث من "أدوات أساسية" إنشاء مشاريع التطبيق الدالة لوقت التشغيل .NET كC# مشاريع الفئة (.csproj). الإصدار 3.x أيضًا يعتمد إنشاء الدالات التي تعمل على .NET 5.0 في عملية معزولة. يتم ترجمة هذه المشاريع C#، التي يمكن استخدامها مع Visual Studio أو Visual Studio التعليمات البرمجية، في أثناء التصحيح وعند النشر إلى Azure.
استخدم
--csxالمعلمة إذا كنت تريد العمل محليًا مع ملفات البرنامج النصي C# (.csx). هذه هي نفس الملفات التي تحصل عليها عند إنشاء وظائف في مدخل Azure وعند استخدام الإصدار 1.x من أدوات Core. لمعرفة المزيد، راجع المرجع.
ملحقات التسجيل
بدءا من الإصدار 2.x من وقت التشغيل، يتم تنفيذ مشغلات الوظائف والروابط كحزم ملحق .NET (NuGet). بالنسبة لمشروعات C# المترجمة، يمكنك ببساطة الرجوع إلى حزم ملحقات NuGet للمشغلات والروابط المحددة التي تستخدمها. لا تتطلب روابط HTTP ومشغلات المؤقت الملحقات.
لتحسين تجربة التطوير للمشروعات غير C#، تتيح لك الدالات الرجوع إلى حزمة ملحقة تم إصدارها في host.jsعلى ملف المشروع. توفر حزم الإضافات جميع الإضافات لتطبيقك وتزيل فرصة وجود مشكلات في توافق الحزم بين الإضافات. تزيل حزم التمديد أيضًا شرط تثبيت SDK .NET Core 3.1 والاضطرار إلى التعامل مع ملف extensions.csproj.
حزم الملحقات هي النهج الموصى به لمشاريع الوظائف بخلاف المشاريع المتوافقة مع C#، بالإضافة إلى البرنامج النصي C#. بالنسبة لهذه المشروعات، يتم إنشاء إعداد حزمة الملحقات في host.js في الملف أثناء التهيئة. إذا لم يتم تمكين الحزم، فستحتاج إلى تحديث ملف host.json للمشروع.
أسهل طريقة لتثبيت ملحقات الربط هي تمكين حزم الملحقات. عند تمكين الحزم، يتم تثبيت مجموعة محددة مسبقًا من حزم الملحقات تلقائيًا.
لتمكين حزم الملحقات، افتح host.jsعلى الملف، وتحديث محتوياته؛ لمطابقة التعليمات البرمجية التالية:
{
"version": "2.0",
"extensionBundle": {
"id": "Microsoft.Azure.Functions.ExtensionBundle",
"version": "[2.*, 3.0.0)"
}
}
لمعرفة المزيد، راجع تسجيل ملحقات الربط لوظائف Azure.
قد توجد حالات في مشروع non-.NET لا يمكنك فيها استخدام حزم الإضافات، مثل عندما تحتاج إلى استهداف إصدار معين من ملحق ليس في الحزمة. في هذه الحالات النادرة، يمكنك استخدام Core Tools لتثبيت حزم الملحقات المحددة التي يتطلبها مشروعك محليا. لمعرفة المزيد، راجع تثبيت الملحقات.
الإعدادات المحلية
عند التشغيل في تطبيق وظائف في Azure، يتم تخزين الإعدادات المطلوبة بواسطة وظائفك بشكل آمن في إعدادات التطبيق. أثناء التطوير المحلي، تتم إضافة هذه الإعدادات بدلا من ذلك إلى Values الكائن في ملف local.settings.json. يخزن ملف local.settings.json أيضا الإعدادات المستخدمة بواسطة أدوات التطوير المحلية.
نظرًا إلى احتمالية احتواء الملف local.settings.json على أسرار، مثل سلاسل الاتصال، يجب عدم تخزينها في مستودع بعيد. لمعرفة المزيد حول الإعدادات المحلية، راجع ملف الإعدادات المحلية.
بشكل افتراضي، لا يتم ترحيل هذه الإعدادات تلقائيًا عند نشر المشروع إلى Azure. استخدم --publish-local-settings الخيار عند النشر للتأكد من إضافة هذه الإعدادات إلى تطبيق الوظائف في Azure. لا يتم نشر القيم الموجودة في مجموعة ConnectionStrings.
يمكن أيضًا قراءة قيم إعدادات تطبيق الدالة في التعليمات البرمجية كمتغيرات البيئة. لمزيدٍ من المعلومات، راجع قسم متغيرات البيئة من هذه المواضيع المرجعية الخاصة باللغة:
عند عدم تعيين أي سلسلة اتصال تخزين صالحة AzureWebJobsStorage يتم استخدام المحاكي، يتم عرض رسالة الخطأ التالية:
القيمة المفقودة لـ AzureWebJobsStorage في local.settings.js. هذا مطلوب لجميع المشغلات غير HTTP. يمكنك تشغيل "func azure functionapp fetch-app-settings <functionAppName>" أو تحديد سلسلة اتصال في local.settings.json.
الحصول على سلاسل اتصال التخزين
حتى عند استخدام Microsoft Azure Storage المحاكي للتطوير، قد تحتاج إلى تشغيل محليًا مع اتصال تخزين فعلي. بافتراض أنك قمت بإنشاء حساب تخزين بالفعل، يمكنك الحصول على سلسلة اتصال تخزين صالحة بإحدى الطرق المتعددة:
في مدخل Microsoft Azure، ابحث عن حسابات التخزين وحددها
حدد حساب التخزين، وحدد مفاتيح Access في الإعدادات، ثم انسخ إحدى قيم سلسلة الاتصال.
إنشاء وظيفة
لإنشاء دالة في مشروع موجود، قم بتشغيل الأمر التالي:
func new
في الإصدار 3.x/2.x، عند تشغيل func new تتم مطالبتك باختيار قالب في اللغة الافتراضية لتطبيق الدالة. بعد ذلك، ستتم مطالبتك باختيار اسم للدالة. في الإصدار 1.x، يطلب منك أيضًا اختيار اللغة.
يمكنك أيضًا تحديد اسم الدالة والقالب في func new الأمر. يستخدم المثال التالي --template الخيار لإنشاء مشغل HTTP المسمى MyHttpTrigger:
func new --template "Http Trigger" --name MyHttpTrigger
ينشئ هذا المثال مشغل تخزين قائمة انتظار المسمى MyQueueTrigger:
func new --template "Queue Trigger" --name MyQueueTrigger
لمعرفة المزيد، راجع func new أمر.
قم بتشغيل الدالات محليًا
لتشغيل مشروع دالات تشغيل المضيف دالات من دليل الجذر للمشروع الخاص بك. يعمل المضيف على تمكين مشغلات لكل الوظائف في المشروع. يختلف start الأمر استنادًا إلى لغة المشروع.
func start
ملاحظة
يتطلب الإصدار 1.x من وقت تشغيل الدالات بدلاً من ذلكfunc host start. لمعرفة المزيد، يُرجى الرجوع إلى أدوات ذاكرة أساسية لوظائف Azure.
عند بدء تشغيل مضيف دالات إخراج URL من الوظائف التي تم تشغيلها HTTP كما في المثال التالي:
Found the following functions: Host.Functions.MyHttpTrigger Job host started Http Function MyHttpTrigger: http://localhost:7071/api/MyHttpTrigger
هام
عند التشغيل محليًا، لا يتم فرض التخويل لنقاط نهاية HTTP. وهذا يعني أن تتم معالجة كل طلبات HTTP المحلية كـauthLevel = "anonymous". لمزيدٍ من المعلومات، راجع المقالة ربط HTTP.
تمرير بيانات الاختبار إلى دالة
لاختبار الدالات محليًا، يمكنك بدء تشغيل المضيف دالات ونقطة النهاية استدعاء على الملقم المحلي باستخدام طلبات HTTP. تعتمد نقطة النهاية التي تتصل بها على نوع الدالة.
ملاحظة
تستخدم الأمثلة في هذا الموضوع أداة cURL لإرسال طلبات HTTP من المحطة الطرفية أو موجه الأوامر. يمكنك استخدام أداة من اختيارك لإرسال طلبات HTTP إلى الخادم المحلي. تتوافر أداة cURL بشكل افتراضي على الأنظمة المستندة إلى لينكس Windows 10 إنشاء 17063 وما بعده. في Windows القديمة، يجب عليك أولاً تنزيل وتثبيتأداة cURL.
للحصول على مزيدٍ من المعلومات العامة حول وظائف الاختبار، راجع إستراتيجيات اختبار التعليمات البرمجية في وظائف Azure.
HTTP وwebhook يشغلان الوظائف
استدعاء نقطة النهاية التالية لتشغيل HTTP محليًا وwebhook لتشغيل الدالات:
http://localhost:{port}/api/{function_name}
تأكد من استخدام نفس اسم الخادم والمنفذ الذي يستمع إليه مضيف الوظائف. راجع هذا في الإخراج الذي تم إنشاؤه عند بدء تشغيل مضيف دالة. يمكنك استدعاء URL هذا باستخدام أي أسلوب HTTP معتمد من جانب المشغل.
الأمر cURL التالي بتشغيل MyHttpTrigger الدالة quickstart من طلب GET مع معلمة الاسم التي تم تمريرها في سلسلة الاستعلام.
curl --get http://localhost:7071/api/MyHttpTrigger?name=Azure%20Rocks
المثال التالي هو نفس الدالة التي تم استدعاؤها من اسم تمرير طلب POST في نص الطلب:
curl --request POST http://localhost:7071/api/MyHttpTrigger --data '{"name":"Azure Rocks"}'
يمكنك إجراء طلبات GET من مستعرض تمرير البيانات في سلسلة الاستعلام. أما جميع أساليب HTTP الأخرى، يجب استخدام cURL أو Fiddler أو Postman أو أداة اختبار HTTP مشابهة تدعم طلبات POST.
دالات غير HTTP مشغلة
لكافة الدالات الأخرى غير مشغلات HTTP وEvent Grid، يمكنك اختبار الوظائف محليًا باستخدام REST عن طريق استدعاء نقطة نهاية خاصة تُسمى نقطة نهاية إدارة. استدعاء نقطة النهاية هذه مع طلب HTTP POST على الخادم المحلي بتشغيل الدالة.
لاختبار وظائف تشغيل شبكة الأحداث محليًا، راجع الاختبار المحلي باستخدام تطبيق ويب المشاهد.
يمكنك اختياريًا تمرير بيانات الاختبار إلى التنفيذ في نص طلب POST. تشبه هذه الوظيفة علامة التبويب اختبار في مدخل Microsoft Azure.
استدعاء نقطة نهاية المسؤول التالية لتشغيل وظائف غير HTTP:
http://localhost:{port}/admin/functions/{function_name}
لتمرير بيانات الاختبار إلى نقطة نهاية المسؤول لدالة، يجب توفير البيانات في نص رسالة طلب POST. من الضروري أن يكون نص الرسالة بتنسيق JSON التالي:
{
"input": "<trigger_input>"
}
<trigger_input>تحتوي القيمة على بيانات بتنسيق متوقع من خلال الدالة. المثال cURL التالي هو POST إلى QueueTriggerJS دالة. في هذه الحالة، الإدخال هو سلسلة مكافئة للرسالة المتوقع العثور عليها في قائمة الانتظار.
curl --request POST -H "Content-Type:application/json" --data '{"input":"sample queue data"}' http://localhost:7071/admin/functions/QueueTrigger
عند استدعاء نقطة نهاية مسؤول على تطبيق الدالة في Azure، ينبغي توفير مفتاح وصول. لمعرفة المزيد، راجع مفاتيح الاختصار الخاصة بالوظيفة.
نشر إلى Azure
تدعم Azure Functions Core Tools نوعين من النشر:
| نوع التوزيع | الأمر | الوصف |
|---|---|---|
| ملفات المشروع | func azure functionapp publish |
نشر ملفات مشروع دالة مباشرة إلى تطبيق الوظائف باستخدام نشر zip. |
| مجموعة Kubernetes | func kubernetes deploy |
نشر تطبيق وظائف Linux كحاوية Docker مخصصة إلى مجموعة Kubernetes. |
قبل النشر
هام
يجب أن يكون لديك Azure CLI أو Azure PowerShell مركبًا محليًا لتتمكن من النشر إلى Azure من أدوات الذاكرة الأساسية.
قد يحتوي مجلد مشروع على ملفات ودلائل خاصة باللغة لا ينبغي نشرها. يتم سرد العناصر المستبعدة في ملف .funcignore في المجلد المشروع الجذر.
يجب أن تكون قد أنشأت تطبيقًا وظيفيًا في اشتراك Azure،والذي ستقوم بنشر التعليمات البرمجية له. يجب إنشاء المشاريع التي تتطلب التحويل البرمجي بحيث يمكن نشر الكائنات الكبيرة ثنائية الحجم.
لمعرفة كيفية إنشاء تطبيق دالة من موجه الأوامر أو نافذة المحطة الطرفية باستخدام Azure CLI أو Azure PowerShell، راجع إنشاء تطبيق دالة للتنفيذ بلا خادم.
هام
عند إنشاء تطبيق دالة في مدخل Microsoft Azure، فإنه يستخدم الإصدار 3.x من وقت تشغيل الدالة بشكل افتراضي. لجعل التطبيق وظيفة استخدام الإصدار 1.x من وقت التشغيل، اتبع الإرشادات في تشغيل على الإصدار 1.x. لا يمكنك تغيير إصدار وقت التشغيل لتطبيق دالة يحتوي على وظائف موجودة.
نشر ملفات المشروع
لنشر التعليمات البرمجية المحلية الخاصة بك إلى تطبيق دالة في Azure، استخدم الأمر publish:
func azure functionapp publish <FunctionAppName>
تنطبق الاعتبارات التالية على هذا النوع من النشر:
النشر يؤدي إلى الكتابة فوق الملفات الموجودة في تطبيق الدالة.
استخدم
--publish-local-settingsالخيار لإنشاء إعدادات التطبيق تلقائيًا في تطبيق الوظائف استنادًا إلى القيم الموجودة في ملف local.settings.json.يتم تنفيذ بناء بعيد على المشروعات المُحولة برمجيًا. يمكن التحكم في ذلك باستخدام
--no-buildالخيار.يتم نشر المشروع بحيث يتم تشغيله من حزمة النشر. لتعطيل وضع النشر الموصى به هذا، استخدم
--nozipالخيار.Java يستخدم Maven لنشر المشروع المحلي الخاص بك إلى Azure. بدلاً من ذلك، استخدم الأمر التالي للنشر إلى Azure:
mvn azure-functions:deploy. يتم إنشاء موارد Azure في أثناء النشر الأولي.ستتحصل على خطأ إذا حاولت النشر إلى
<FunctionAppName>اشتراك غير موجود.
مجموعة Kubernetes
وظائف يتيح لك أيضًا تحديد مشروع وظائف لتشغيل في حاوية Docker. استخدم --docker خيارfunc init إنشاء Dockerfile للغة معينة. ثم يتم استخدام هذا الملف عند إنشاء حاوية لنشر. لمعرفة كيفية نشر حاوية مخصصة إلى Azure من دون Kubernetes، راجع إنشاء دالة على Linux باستخدام حاوية مخصصة.
يمكن استخدام أدوات ذاكرة أساسية لنشر المشروع الخاص بك كصورة حاوية مخصصة إلى كتلة Kubernetes.
يستخدم الأمر التالي Dockerfile لإنشاء حاوية ونشرها إلى كتلة Kubernetes.
func kubernetes deploy --name <DEPLOYMENT_NAME> --registry <REGISTRY_USERNAME>
لمعرفة المزيد، راجع توزيع تطبيق الوظائف إلى Kubernetes.
تثبيت ملحقات
إذا لم تتمكن من استخدام حزم الملحقات، يمكنك استخدام Azure Functions Core Tools محليا لتثبيت حزم الملحقات المحددة التي يتطلبها مشروعك.
هام
لا يمكنك تثبيت الملحقات بشكل صريح في تطبيق الوظائف مع تمكين حزم الملحقات. أولا، قم بإزالة extensionBundle القسم في host.json قبل تثبيت الملحقات بشكل صريح.
تصف العناصر التالية بعض الأسباب التي قد تحتاج إلى تثبيت الملحقات يدويًا:
- تحتاج إلى الوصول إلى إصدار محدد من ملحق غير متوفر في مجموعة.
- تحتاج إلى الوصول إلى ملحق مخصص غير متوفر في مجموعة.
- تحتاج إلى الوصول إلى مجموعة محددة من الملحقات غير متوفرة في مجموعة واحدة.
عند تثبيت ملحقات بشكل صريح، يتم إضافة ملف مشروع .NET المسمى extensions.csproj إلى جذر المشروع الخاص بك. يُعرف هذا الملف مجموعة حزم NuGet المطلوبة من قبل الوظائف الخاصة بك. بينما يمكنك العمل مع مراجع حزمة NuGet في هذا الملف، تتيح لك Core Tools تثبيت الملحقات دون الحاجة إلى تحرير ملف مشروع C# هذا يدويا.
هناك عدة طرق لاستخدام Core Tools لتثبيت الملحقات المطلوبة في المشروع المحلي.
تثبيت كافة الملحقات
استخدم الأمر التالي لإضافة كافة حزم الملحقات المستخدمة من قبل الروابط في المشروع المحلي تلقائيًا:
func extensions install
يقرأ الأمر الملف function.json لمعرفة الحزم التي تحتاجها، يُثبتها، ثم يعيد بناء مشروع ملحقات (extensions.csproj). يضيف أي روابط جديدة في الإصدار الحالي ولكنه لا يقوم بتحديث الارتباطات الموجودة. استخدم --force الخيار لتحديث الارتباطات الموجودة إلى أحدث إصدار عند تثبيت روابط جديدة. لمعرفة المزيد، راجع func extensions install الأمر.
إذا كان تطبيق الوظائف يستخدم روابط أو حزم NuGet لا تتعرف عليها Core Tools، فيجب عليك تثبيت الملحق المحدد يدويا.
تثبيت ملحق محدد
استخدم الأمر التالي لتثبيت حزمة ملحق محددة في إصدار محدد، وفي هذه الحالة ملحق التخزين:
func extensions install --package Microsoft.Azure.WebJobs.Extensions.Storage --version 5.0.0
يمكنك استخدام هذا الأمر لتثبيت أي حزمة NuGet متوافقة. لمعرفة المزيد، راجع func extensions install الأمر.
مراقبة الدالات
الطريقة الموصى بها لمراقبة تنفيذ الدالة هي الدمج مع Azure Application Insights. يمكنك أيضًا دفق سجلات التنفيذ إلى الكمبيوتر المحلي. لمعرفة المزيد، يُرجى الرجوع إلى Monitor Azure وظائف.
تكامل رؤى التطبيق
يجب تمكين تكامل رؤى التطبيق عند إنشاء تطبيق الوظائف في Azure. إذا لم يكن تطبيق الوظائف متصلاً بتطبيق رؤى مثيل لسببٍ ما، فمن السهل إجراء هذا التكامل في مدخل Microsoft Azure. لمعرفة المزيد، راجع تمكين تكامل نتائج رؤى التطبيق
تمكين سجلات الدفق
يمكنك عرض دفق ملفات السجل التي يتم إنشاؤها بواسطة الدالات في جلسة عمل سطر الأوامر على الكمبيوتر المحلي.
دفق السجلات المضمّن
func azure functionapp logstream استخدم الأمر لبدء تلقي سجلات الدفق لتطبيق دالة معين يعمل في Azure، كما في المثال التالي:
func azure functionapp logstream <FunctionAppName>
ملاحظة
لم يتم تمكين دفق السجل المضمن بعد في Core Tools لتطبيقات الوظائف التي تعمل على Linux في خطة Consumption. بالنسبة لخطط الاستضافة هذه، تحتاج بدلا من ذلك إلى استخدام Live Metrics Stream لعرض السجلات في الوقت الفعلي تقريبا.
Live Metrics Stream
يمكنك عرض Live Metrics Stream لتطبيق الوظائف في نافذة متصفح جديدة عن طريق تضمين --browser الخيار، كما في المثال التالي:
func azure functionapp logstream <FunctionAppName> --browser
يتطلب هذا النوع من سجلات الدفق تمكين تكامل رؤى التطبيق لتطبيق الوظيفة.
الخطوات التالية
تعلم كيفية تطوير واختبار ونشر وظائف Azure باستخدام Azure وظائف الأساسية أدوات Microsoft تعلم وحدة Azure وظائف الأدوات الأساسية مفتوحة المصدر ومستضافة على GitHub.
لتقديم طلب خطأ أو ميزة، افتح مشكلة GitHub.