أحداث مجموعة Service Fabric Linux في Syslog

يعرض Service Fabric مجموعة من أحداث النظام الأساسي لإبلاغك بالنشاط المهم في مجموعتك. تتوفر القائمة الكاملة للأحداث التي يتم كشفها هنا. هناك طرق مختلفة يمكن من خلالها استهلاك هذه الأحداث. في هذه المقالة، نناقش كيفية تكوين Service Fabric لكتابة هذه الأحداث إلى Syslog.

مقدمة

في الإصدار 6.4، تم تقديم SyslogConsumer لإرسال أحداث النظام الأساسي Service Fabric إلى Syslog لمجموعات Linux. بمجرد التشغيل، تتدفق الأحداث تلقائيا إلى Syslog التي يمكن جمعها وإرسالها من قبل عامل Log Analytics.

يحتوي كل حدث Syslog على أربعة مكونات

  • المرافق
  • الهوية
  • رسالة
  • الأهمية

يكتب SyslogConsumer جميع أحداث النظام الأساسي باستخدام أداة إنشاء Local0. يمكنك التحديث إلى أي مرفق صالح عن طريق تغيير التكوين. الهوية المستخدمة هي ServiceFabric. يحتوي حقل الرسالة على الحدث بأكمله الذي تم تسلسله في JSON بحيث يمكن الاستعلام عنه واستهلاكه بواسطة أدوات مختلفة.

تمكين SyslogConsumer

لتمكين SyslogConsumer، تحتاج إلى إجراء ترقية لمجموعتك. يجب تحديث القسم fabricSettings بالتعليمة البرمجية التالية. لاحظ أن هذه التعليمة البرمجية تتضمن فقط الأقسام المتعلقة بـSyslogConsumer

    "fabricSettings": [
        {
            "name": "Diagnostics",
            "parameters": [
            {
                "name": "ConsumerInstances",
                "value": "AzureWinFabCsv, AzureWinFabCrashDump, AzureTableWinFabEtwQueryable, SyslogConsumer"
            }
            ]
        },
        {
            "name": "SyslogConsumer",
            "parameters": [
            {
                "name": "ProducerInstance",
                "value": "WinFabLttProducer"
            },
            {
            "name": "ConsumerType",
            "value": "SyslogConsumer"
            },
            {
                "name": "IsEnabled",
                "value": "true"
            }
            ]
        },
        {
            "name": "Common",
            "parameters": [
            {
                "name": "LinuxStructuredTracesEnabled",
                "value": "true"
            }
            ]
        }
    ],

فيما يلي التغييرات التي يجب استدعاؤها

  1. في القسم Common، هناك معلمة جديدة تسمى LinuxStructuredTracesEnabled. هذا مطلوب لجعل أحداث Linux منظمة ومتسلسلة عند إرسالها إلى Syslog.
  2. في قسم Diagnostics، تمت إضافة ConsumerInstance جديد: SyslogConsumer. هذا يخبر النظام الأساسي أن هناك مستهلكا آخر للأحداث.
  3. يحتاج القسم الجديد SyslogConsumer إلى أن يكون IsEnabled كـtrue. تم تكوينه لاستخدام منشأة Local0 تلقائيا. يمكنك تجاوز ذلك بإضافة معلمة أخرى.
    {
        "name": "New LogFacility",
        "value": "<Valid Syslog Facility>"
    }

تكامل سجلات Azure Monitor

يمكنك قراءة أحداث Syslog هذه في أداة مراقبة مثل سجلات Azure Monitor. يمكنك إنشاء مساحة عمل Log Analytics باستخدام Azure Marketplace باستخدام هذه الإرشادات.

تحتاج أيضا إلى إضافة عامل Log Analytics إلى مجموعتك لجمع هذه البيانات وإرسالها إلى مساحة العمل. هذا هو نفس العامل المستخدم لجمع عدادات الأداء.

  1. انتقل إلى Advanced Settings القسم

    إعدادات مساحة العمل

  2. تحديد Data

  3. تحديد Syslog

  4. قم بتكوين Local0 كأداة للتعقب. يمكنك إضافة أداة أخرى إذا قمت بالتغيير في fabricSettings

    تكوين Syslog

  5. توجه إلى مستكشف الاستعلام بالنقر فوق Logs في قائمة مورد مساحة العمل لبدء الاستعلام

    سجلات مساحة العمل

  6. يمكنك الاستعلام مقابل الجدول Syslog والبحث عن ServiceFabric كـProcessName. الاستعلام التالي هو مثال على كيفية تحليل JSON في الحدث وعرض محتوياته

    Syslog | where ProcessName == "ServiceFabric" | extend $payload = parse_json(SyslogMessage) | project $payload

استعلام Syslog

المثال أعلاه هو حدث NodeDown. يمكنك عرض القائمة الكاملة للأحداث هنا.

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