مشاركة عبر

استكشاف مشكلات عامل Log Analytics لنظام التشغيل Linux وإصلاحها

  • مقالة

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

تنبيه

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

أداة استكشاف الأخطاء وإصلاحها في Log Analytics

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

استخدام أداة "استكشاف الأخطاء وإصلاحها"

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

sudo /opt/microsoft/omsagent/bin/troubleshooter

تثبيت يدوي

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

  1. تأكد من تثبيت مصحح أخطاء مشروع GNU (GDB) على الجهاز حيث يعتمد مستكشف الأخطاء ومصلحها عليه.
  2. انسخ مجموعة مستكشف الأخطاء ومصلحها على جهازك: wget https://raw.github.com/microsoft/OMS-Agent-for-Linux/master/source/code/troubleshooter/omsagent_tst.tar.gz
  3. فك المجموعة: tar -xzvf omsagent_tst.tar.gz
  4. تشغيل التثبيت اليدوي: sudo ./install_tst

السيناريوهات التي تمت تغطيتها

تتحقق أداة "استكشاف الأخطاء وإصلاحها" من السيناريوهات التالية:

  • العامل غير سليم، رسالة كشف أخطاء الاتصال لا تعمل بشكل صحيح.
  • العامل لا يبدأ، أو لا يمكنه الاتصال بخدمات Log Analytics.
  • عامل Syslog لا يعمل.
  • عامل يستخدم CPU أو ذاكرة عالية.
  • العامل لديه مشكلات في التثبيت.
  • سجلات العامل المخصصة لا تعمل.
  • لا يمكن جمع سجلات العامل.

لمزيد من المعلومات، راجع وثائق أداة "استكشاف الأخطاء وإصلاحها" في GitHub.

إشعار

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

مسح عامل Linux وإعادة تثبيته

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

  1. تحميل البرنامج النصي للمسح:

    $ wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-Linux/master/tools/purge_omsagent.sh

  2. تشغيل البرنامج النصي للمسح (مع أذونات sudo):

    $ sudo sh purge_omsagent.sh

مواقع السجل الهامة وأداة "جامع السجلات"

الملف المسار
عامل Log Analytics لملف سجل نظام التشغيل Linux /var/opt/microsoft/omsagent/<workspace id>/log/omsagent.log
ملف سجل تكوين عامل Log Analytics /var/opt/microsoft/omsconfig/omsconfig.log

نوصيك باستخدام أداة "جامع السجلات" لاسترداد سجلات مهمة لاستكشاف الأخطاء وإصلاحها أو قبل إرسال مشكلة GitHub. لمزيد من المعلومات حول الأداة وكيفية تشغيلها، راجع "جامع السجلات" لعامل OMS Linux.

ملفات التكوين الهامة

الفئة موقع الملف
Syslog /etc/syslog-ng/syslog-ng.conf أو /etc/rsyslog.conf أو /etc/rsyslog.d/95-omsagent.conf
الأداء وNagios وZabbix وإخراج Log Analytics والعامل العام /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf
تكوينات إضافية /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/*.conf

إشعار

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

sudo /opt/microsoft/omsconfig/Scripts/OMS_MetaConfigHelper.py --disable && sudo rm /etc/opt/omi/conf/omsconfig/configuration/Current.mof* /etc/opt/omi/conf/omsconfig/configuration/Pending.mof*

رموز خطأ التثبيت

رمز الخطأ المعنى
NOT_DEFINED نظرًا لعدم تثبيت التبعيات الضرورية، لن يتم تثبيت الوظيفة الإضافية لـ auoms auditd. فشل تثبيت auoms. تثبيت auditd للحزمة.
2 خيار غير صالح موفر إلى مجموعة shell. تشغيل sudo sh ./omsagent-*.universal*.sh --help للاستخدام.
3 لا يوجد خيار موفر إلى مجموعة shell. تشغيل sudo sh ./omsagent-*.universal*.sh --help للاستخدام.
4 نوع الحزمة غير صالح أو إعدادات الوكيل غير صالحة. يمكن تثبيت حزم omsagent-rpm.sh فقط على الأنظمة المستندة إلى RPM. يمكن تثبيت حزم omsagent-deb.sh فقط على الأنظمة المستندة إلى Debian. يوصى باستخدام المثبت الشامل من أحدث إصدار. راجع أيضا للتحقق من إعدادات الوكيل.
5 كان يجب تنفيذ مجموعة shell كجذر أو كان هناك خطأ 403 تم إرجاعه أثناء الإلحاق. شغل الأمر باستخدام sudo.
6 بنية الحزمة غير صالحة أو كان هناك خطأ 200 تم إرجاعه أثناء الإلحاق. يمكن تثبيت حزم omsagent-*x64.sh فقط على أنظمة 64 بت. يمكن تثبيت حزم omsagent-*x86.sh فقط على أنظمة 32 بت. نزّل الحزمة الصحيحة لتصميمك من أحدث إصدار.
17 فشل تثبيت حزمة OMS. ابحث في مخرجات الأمر عن فشل الجذر.
18 فشل تثبيت حزمة OMSConfig. ابحث في مخرجات الأمر عن فشل الجذر.
19 فشل تثبيت حزمة OMI. ابحث في مخرجات الأمر عن فشل الجذر.
20 فشل تثبيت حزمة SCX. ابحث في مخرجات الأمر عن فشل الجذر.
21 فشل تثبيت مجموعات أدوات الموفر. ابحث في مخرجات الأمر عن فشل الجذر.
22 فشل تثبيت الحزمة المجمعة. البحث في مخرجات الأمر عن فشل الجذر
23 حزمة SCX أو حزمة OMI مثبتة بالفعل. استخدم --upgrade بدلًا من --install لتثبيت مجموعة shell.
30 خطأ داخلي في المجموعة. سجّل مشكلة GitHub مع التفاصيل من المخرجات.
55 إصدار openssl غير مدعوم أو لا يمكن الاتصال بـ Azure Monitor أو تم تأمين dpkg أوتم فقد برنامج curl.
61 مكتبة Python ctypes المفقودة. تثبيت مكتبة أو حزمة Python ctypes (python-ctypes).
62 برنامج tar مفقود. ثبت tar.
63 برنامج sed مفقود. ثبت sed.
64 برنامج curl مفقود. ثبت curl.
65 برنامج gpg مفقود. ثبّت gpg.

إلحاق رموز الأخطاء

رمز الخطأ المعنى
2 الخيار المقدم إلى البرنامج النصي لـ omsadmin غير صالح. تشغيل sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h للاستخدام.
3 التكوين المقدم إلى البرنامج النصي لـ omsadmin غير صالح. تشغيل sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h للاستخدام.
4 الوكيل المقدم إلى البرنامج النصي لـ omsadmin غير صالح. تحقق من الوكيل وراجعوثائق استخدام وكيل HTTP.
5 خطأ 403 HTTP المستلم من Azure Monitor. راجع المخرجات الكاملة من البرنامج النصي لـ omsadmin للحصول على التفاصيل.
6 خطأ HTTP غير 200 المستلم من Azure Monitor. راجع المخرجات الكاملة من البرنامج النصي لـ omsadmin للحصول على التفاصيل.
7 يتعذر الاتصال بـ Azure Monitor. راجع المخرجات الكاملة من البرنامج النصي لـ omsadmin للحصول على التفاصيل.
8 خطأ في الإلحاق بمساحة عمل Log Analytics. راجع المخرجات الكاملة من البرنامج النصي لـ omsadmin للحصول على التفاصيل.
30 خطأ داخلي في البرنامج النصي. سجّل مشكلة GitHub مع التفاصيل من المخرجات.
31 خطأ في إنشاء معرّف العامل. سجّل مشكلة GitHub مع التفاصيل من المخرجات.
32 خطأ في إنشاء الشهادات. راجع المخرجات الكاملة من البرنامج النصي لـ omsadmin للحصول على التفاصيل.
33 خطأ في إنشاء metaconfiguration لـ omsconfig. سجّل مشكلة GitHub مع التفاصيل من المخرجات.
34 البرنامج النصي لإنشاء metaconfiguration غير موجود. إعادة محاولة الإلحاق باستخدام sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key>.

تمكين تسجيل تتبع الأخطاء

تتبع أخطاء المكون الإضافي لإخراج OMS

يسمح FluentD بمستويات تسجيل خاصة بالمكون الإضافي مما يسمح لك بتحديد مستويات تسجيل مختلفة للمدخلات والمخرجات. لتحديد مستوى سجل مختلف لإخراج OMS، حرّر تكوين العامل العام في /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf.

في المكون الإضافي لإخراج OMS، قبل نهاية ملف التكوين، غيّر log_level الخاصية من info إلى debug:

<match oms.** docker.**>
  type out_oms
  log_level debug
  num_threads 5
  buffer_chunk_limit 5m
  buffer_type file
  buffer_path /var/opt/microsoft/omsagent/<workspace id>/state/out_oms*.buffer
  buffer_queue_limit 10
  flush_interval 20s
  retry_limit 10
  retry_wait 30s
</match>

يسمح لك تسجيل تتبع الأخطاء بمراجعة التحميلات المُنفذة على دفعات إلى Azure Monitor مفصولة حسب النوع، وعدد عناصر البيانات، والوقت المستغرق للإرسال.

مثال سجل تتبع الأخطاء الممكن:

Success sending oms.nagios x 1 in 0.14s
Success sending oms.omi x 4 in 0.52s
Success sending oms.syslog.authpriv.info x 1 in 0.91s

إخراج مطول

بدلاً من استخدام المكون الإضافي لإخراج OMS يمكنك أيضًا إخراج عناصر البيانات مباشرة إلى stdout، والتي تظهر في عامل Log Analytics لملف سجل Linux.

في ملف تكوين عامل عام لـ Log Analytics في /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf، علّق على المكون الإضافي لإخراج OMS بإضافة # أمام كل سطر:

#<match oms.** docker.**>
#  type out_oms
#  log_level info
#  num_threads 5
#  buffer_chunk_limit 5m
#  buffer_type file
#  buffer_path /var/opt/microsoft/omsagent/<workspace id>/state/out_oms*.buffer
#  buffer_queue_limit 10
#  flush_interval 20s
#  retry_limit 10
#  retry_wait 30s
#</match>

أسفل الوظيفة الإضافية للإخراج، قم بإلغاء التعليق على القسم التالي عن طريق إزالة # أمام كل سطر:

<match **>
  type stdout
</match>

المشكلة: تعذر الاتصال من خلال الوكيل إلى Azure Monitor

الأسباب المحتملة

  • الوكيل المحدد أثناء الإلحاق غير صحيح.
  • لا يتم تضمين نقاط تقديم خدمة Azure Automation وAzure Monitor في القائمة المعتمدة في مركز البيانات الخاص بك.

نوع الحل

  1. إعادة الإلحاق إلى Azure Monitor باستخدام عامل Log Analytics لنظام التشغيل Linux باستخدام الأمر التالي مع تمكين الخيار -v. يسمح بإخراج verbose للعامل المتصل عبر الوكيل إلى Azure Monitor: /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key> -p <Proxy Conf> -v

  2. راجع القسم تحديث إعدادات الوكيل للتحقق من تكوين الوكيل بشكل صحيح للاتصال من خلال خادم وكيل.

  3. تحقق مرة إضافية من إضافة نقاط النهاية الموضحة في قائمة متطلبات جدار حماية شبكة Azure Monitor إلى قائمة السماح بشكل صحيح. إذا كنت تستخدم Azure Automation، يتم ربط خطوات تكوين الشبكة الضرورية أعلاه أيضًا.

المشكلة: تتلقى خطأ 403 عند محاولة الإلحاق

الأسباب المحتملة

  • التاريخ والوقت غير صحيحين على خادم Linux.
  • معرف مساحة العمل ومفتاح مساحة العمل غير صحيحين.

نوع الحل

  1. تحقق من الوقت على خادم Linux الخاص بك مع تاريخ الأمر. إذا كان الوقت هو +/- 15 دقيقة من الوقت الحالي، فحينئذٍ يفشل الإلحاق. لتصحيح ذلك، حدّث التاريخ والمنطقة الزمنية أو كليهما لخادم Linux.
  2. تحقق من تثبيت أحدث إصدار من عامل Log Analytics لنظام التشغيل Linux. يُعلمك الإصدار الأحدث الآن إذا تسبب انحراف الوقت في فشل الإلحاق.
  3. أعد الإلحاق باستخدام "معرف مساحة العمل" الصحيح و"مفتاح مساحة العمل" باتباع إرشادات التثبيت في هذه المقالة.

المشكلة: ترى خطأ 500 و404 في ملف السجل مباشرة بعد إعادة الإلحاق

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

المشكلة: ترى omiagent يستخدم CPU 100٪

الأسباب المحتملة

تسبب تراجع حزمة nss-pem v1.0.3-5.el7 في حدوث مشكلة خطيرة في الأداء. لقد رأينا هذه المشكلة تظهر كثيرا في توزيعات Redhat/CentOS 7.x. لمعرفة المزيد من المعلومات حول هذه المشكلة، راجع تراجع أداء 1667121 في libcurl.

الأخطاء المتعلقة بالأداء لا تحدث طوال الوقت، ومن الصعب جدًا إعادة إنشائها. إذا واجهت مثل هذه المشكلة مع omiagent، استخدم البرنامج النصي omiHighCPUDiagnostics.sh، الذي سيجمع تتبع مكدس omiagent عند تجاوز حد معين.

  1. قم بتنزيل البرنامج النصي:
    wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-Linux/master/tools/LogCollector/source/omiHighCPUDiagnostics.sh

  2. تشغيل التشخيصات لمدة 24 ساعة مع حد وحدة المعالجة المركزية بنسبة 30٪:
    bash omiHighCPUDiagnostics.sh --runtime-in-min 1440 --cpu-threshold 30

  3. سيتم تفريغ Callstack في ملف omiagent_trace. إذا لاحظت العديد من استدعاءات وظيفة curl وNSS، فاتبع خطوات الحل هذه.

نوع الحل

  1. ترقية حزمة nss-pem إلى الإصدار 1.0.3-5.el7_6.1:
    sudo yum upgrade nss-pem

  2. إذا لم يكن nss-pem متوفرا للترقية، والذي يحدث في الغالب على CentOS، فتراجع إلى 7.29.0-46. إذا قمت بتشغيل "تحديث yum" عن طريق الخطأ، ستتم ترقية curl إلى 7.29.0-51 وستحدث المشكلة مرة أخرى:
    sudo yum downgrade curl libcurl

  3. إعادة تشغيل OMI:
    sudo scxadmin -restart

المشكلة: أنت لا ترى رسائل Syslog التي تم إعادة توجيهها

الأسباب المحتملة

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

نوع الحل

  • تحقق من التكوين في مساحة عمل Log Analytics لـ Syslog لديه كافة أدوات الإنشاء ومستويات السجل الصحيحة. راجع تكوين مجموعة Syslog في مدخل Microsoft Azure.
  • تحقق من أن برامج الرسائل الأصلية الخفية لـ syslog (rsyslog وsyslog-ng) قادرة على استلام الرسائل التي تم إعادة توجيهها.
  • تحقق من إعدادات جدار الحماية على خادم Syslog للتأكد من أن الرسائل لا يتم منعها.
  • محاكاة رسالة Syslog إلى Log Analytics باستخدام أمر logger :
    logger -p local0.err "This is my test message"

المشكلة: أنت تستلم عنوان Errno قيد الاستخدام بالفعل في ملف سجل omsagent

أنت ترى [error]: unexpected error error_class=Errno::EADDRINUSE error=#<Errno::EADDRINUSE: Address already in use - bind(2) for "127.0.0.1" port 25224> في omsagent.log.

الأسباب المحتملة

يشير هذا الخطأ إلى أن ملحق تشخيص Linux (LAD) مثبتًا جنبًا إلى جنب مع ملحق الجهاز الظاهري لـ Linux في Log Analytics. إنه يستخدم نفس المنفذ لتجميع بيانات Syslog مثل omsagent.

نوع الحل

  1. كجذر، قم بتنفيذ الأوامر التالية. لاحظ أن 25224 مثال ومن الممكن أن تشاهد في البيئة رقم منفذ مختلفة المستخدمة من قبل LAD.

    /opt/microsoft/omsagent/bin/configure_syslog.sh configure LAD 25229

sed -i -e 's/25224/25229/' /etc/opt/microsoft/omsagent/LAD/conf/omsagent.d/syslog.conf

    تحتاج بعد ذلك إلى تحرير الملف الصحيح rsyslogd أو ملف التكوين syslog_ng وتغيير التكوين المتعلق بـ LAD للكتابة إلى المنفذ 25229.

  2. إذا كان الجهاز الظاهري قيد التشغيل rsyslogd، فإن الملف الذي سيتم تعديله هو: /etc/rsyslog.d/95-omsagent.conf (إذا كان موجودًا، وإلا /etc/rsyslog). إذا كان الجهاز الظاهري قيد التشغيل syslog_ng، فإن الملف الذي سيتم تعديله هو /etc/syslog-ng/syslog-ng.conf.

  3. إعادة تشغيل omsagent sudo /opt/microsoft/omsagent/bin/service_control restart.

  4. أعد تشغيل خدمة Syslog.

المشكلة: أنت غير قادر على إلغاء تثبيت omsagent باستخدام خيار المسح

الأسباب المحتملة

  • تم تثبيت ملحق تشخيص Linux.
  • تم تثبيت ملحق تشخيص Linux وتم إلغاء تثبيته، ولكنك لا تزال ترى خطأ حول omsagent المستخدم من قبل mdsd ولا يمكن إزالته.

نوع الحل

  1. ألغ تثبيت ملحق تشخيص Linux.
  2. أزّل ملفات ملحق تشخيص Linux من الجهاز إذا كانت موجودة في الموقع التالي: /var/lib/waagent/Microsoft.Azure.Diagnostics.LinuxDiagnostic-<version>/ و/var/opt/microsoft/omsagent/LAD/.

المشكلة: لا يمكنك رؤية أي بيانات من بيانات Nagios

الأسباب المحتملة

  • مستخدم omsagent ليس لديه أذونات للقراءة من ملف سجل Nagios.
  • لم يتم إلغاء التعليق على مصدر وعامل تصفية Nagios من ملف omsagent.conf.

نوع الحل

  1. أضف مستخدم omsagent للقراءة من ملف Nagios باتباع هذه الإرشادات.

  2. في عامل Log Analytics لملف التكوين العام لنظام التشغيل Linux في /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf، تأكد من عدم تعليق كل من مصدر وعامل تصفية Nagios.

    <source>
  type tail
  path /var/log/nagios/nagios.log
  format none
  tag oms.nagios
</source>

<filter oms.nagios>
  type filter_nagios_log
</filter>

المشكلة: أنت لا ترى أي بيانات لـ Linux

الأسباب المحتملة

  • فشل الإلحاق بـ Azure Monitor.
  • تم منع الاتصال بـ Azure Monitor.
  • تم إعادة تشغيل الجهاز الظاهري.
  • تمت ترقية حزمة OMI يدويًا إلى إصدار أحدث مقارنة بما تم تثبيته من قبل عامل Log Analytics لحزمة Linux.
  • تم تجميد OMI، ومنع عامل OMS.
  • خطأ فئة سجلات موارد DSC غير موجودة في ملف السجل omsconfig.log.
  • يتم نسخ عامل Log Analytics للبيانات احتياطيًا.
  • سجلات DSC التكوين الحالي غير موجود. تنفيذ الأمر Start-DscConfiguration مع المعلمة -Path لتحديد ملف تكوين وإنشاء تكوين حالي أولا. في omsconfig.log ملف السجل، ولكن لا توجد رسالة سجل حول PerformRequiredConfigurationChecks العمليات.

نوع الحل

  1. ثبت كافة التبعيات مثل الحزمة auditd.

  2. تحقق من نجاح الإلحاق بـ Azure Monitor عن طريق التحقق مما إذا كان الملف التالي موجودًا: /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf. إذا لم يكن كذلك، أعد الإلحاق باستخدام إرشاداتسطر الأوامر omsadmin.sh.

  3. إذا كنت تستخدم وكيلًا، تحقق من الخطوات السابقة لاستكشاف الأخطاء وإصلاحها الخاصة بالوكيل.

  4. في بعض أنظمة التوزيع لـ Azure، لا يبدأ تشغيل برنامج خفي لخادم omid OMI بعد إعادة تشغيل الجهاز الظاهري. إذا كانت هذه هي الحالة، فلن ترى بيانات التدقيق أو ChangeTracking أو UpdateManagement المتعلقة بالحل. الحل البديل هو بدء تشغيل خادم OMI يدويًا عن طريق تشغيل sudo /opt/omi/bin/service_control restart.

  5. بعد ترقية حزمة OMI يدويًا إلى إصدار أحدث، يجب إعادة تشغيلها يدويًا لعامل Log Analytics لمواصلة العمل. هذه الخطوة مطلوبة لبعض عمليات التوزيع حيث لا يتم تشغيل خادم OMI تلقائيًا بعد أن تتم ترقيته. شغل sudo /opt/omi/bin/service_control restart لإعادة تشغيل OMI.

    في بعض الحالات، يمكن تجميد OMI. قد يدخل عامل OMS في حالة منع في انتظار OMI، مما يمنع كافة عمليات تجميع البيانات. سيتم تشغيل عملية عامل OMS ولكن لن يكون هناك أي نشاط، كما يتضح من عدم وجود أسطر سجل جديدة (مثل إرسال رسائل كشف أخطاء الاتصال) موجودة في omsagent.log. أعد تشغيل OMI باستخدام sudo /opt/omi/bin/service_control restart لاسترداد العامل.

  6. إذا رأيت خطأ لم يتم العثور على فئة مورد DSC في omsconfig.log، فقم بتشغيل sudo /opt/omi/bin/service_control restart.

  7. في بعض الحالات، عندما يتعذر على عامل Log Analytics لنظام التشغيل Linux التحدث إلى Azure Monitor، يتم نسخ البيانات الموجودة على العامل احتياطيًا إلى حجم المخزن المؤقت الكامل: 50 ميغابايت. يجب إعادة تشغيل العامل بتشغيل الأمر التالي: /opt/microsoft/omsagent/bin/service_control restart.

    إشعار

    يتم إصلاح هذه المشكلة في إصدار عامل 1.1.0-28 أو أحدث.

    • إذا لم يشير ملف السجل omsconfig.log إلى أن PerformRequiredConfigurationChecks العمليات تعمل بشكل دوري على النظام، قد تكون هناك مشكلة في وظيفة/خدمة cron. تأكد من وجود وظيفة cron ضمن /etc/cron.d/OMSConsistencyInvoker. إذا لزم الأمر، شغّل الأوامر التالية لإنشاء وظيفة cron:

      mkdir -p /etc/cron.d/
echo "*/15 * * * * omsagent /opt/omi/bin/OMSConsistencyInvoker >/dev/null 2>&1" | sudo tee /etc/cron.d/OMSConsistencyInvoker

    • تأكد أيضًا من تشغيل خدمة cron. يمكنك استخدام service cron status مع Debian أو Ubuntu أو SUSE أو service crond status مع RHEL وCentOS وOracle Linux للتحقق من حالة هذه الخدمة. إذا كانت الخدمة غير موجودة، يمكنك تثبيت الثنائيات وبدء تشغيل الخدمة باستخدام الإرشادات التالية:

      Ubuntu/Debian

      # To Install the service binaries
sudo apt-get install -y cron
# To start the service
sudo service cron start

      SUSE

      # To Install the service binaries
sudo zypper in cron -y
# To start the service
sudo systemctl enable cron
sudo systemctl start cron

      RHEL/CentOS

      # To Install the service binaries
sudo yum install -y crond
# To start the service
sudo service crond start

      Oracle Linux

      # To Install the service binaries
sudo yum install -y cronie
# To start the service
sudo service crond start

المشكلة: عند تكوين مجموعة من المدخل لعدادات أداء Syslog أو Linux، لا يتم تطبيق الإعدادات

الأسباب المحتملة

  • لم يلتقط عامل Log Analytics لنظام التشغيل Linux أحدث التكوينات.
  • لم يتم تطبيق الإعدادات التي تم تغييرها في المدخل.

نوع الحل

الخلفية: omsconfig هو عامل Log Analytics لعامل تكوين Linux الذي يبحث عن تكوين جديد من جانب المدخل كل خمس دقائق. ثم يتم تطبيق هذا التكوين على عامل Log Analytics لملفات تكوين Linux الموجودة في /etc/opt/microsoft/omsagent/conf/omsagent.conf.

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

  1. تحقق من omsconfig تثبيت العامل عن طريق تشغيل dpkg --list omsconfig أو rpm -qi omsconfig. إذا لم يتم تثبيته، أعد تثبيت أحدث إصدار من عامل Log Analytics لنظام التشغيل Linux.

  2. تحقق من أن العامل omsconfig يمكنه الاتصال بـ Azure Monitor عن طريق تشغيل الأمر التالي sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'. يُرجع هذا الأمر التكوين الذي يستلمها العامل من الخدمة، بما في ذلك إعدادات Syslog وعدادات أداء Linux والسجلات المخصصة. إذا فشل هذا الأمر، قم بتشغيل الأمر التالي: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'. يفرض هذا الأمر على عامل omsconfig التحدث إلى Azure Monitor واسترداد أحدث تكوين.

المشكلة: أنت لا ترى أي بيانات سجل مخصصة

الأسباب المحتملة

  • فشل الإلحاق بـ Azure Monitor.
  • لم يتم تحديد الإعداد تطبيق التكوين التالي على خوادم Linux.
  • omsconfig لم يلتقط أحدث تكوين لسجل مخصص من الخدمة.
  • عامل Log Analytics لمستخدم Linux omsagent غير قادر على الوصول إلى السجل المخصص بسبب الأذونات أو عدم العثور عليه. قد ترى الأخطاء التالية:
    • [DATETIME] [warn]: file not found. Continuing without tailing it.
    • [DATETIME] [error]: file not accessible by omsagent.
  • مشكلة معروفة في حالة تعارض تم إصلاحها في عامل Log Analytics لنظام التشغيل Linux الإصدار 1.1.0-217.

نوع الحل

  1. تحقق من نجاح الإلحاق بـ Azure Monitor عن طريق التحقق مما إذا كان الملف التالي موجودًا: /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf. إذا لم يكن كذلك، إما:

    1. أعد الإلحاق باستخدام إرشاداتسطر الأوامر omsadmin.sh.
    2. ضمن الإعدادات المتقدمة في مدخل Azure، تأكد من تمكين الإعداد تطبيق التكوين التالي على خوادم Linux.

  2. تحقق من أن العامل omsconfig يمكنه الاتصال بـ Azure Monitor عن طريق تشغيل الأمر التالي sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'. يُرجع هذا الأمر التكوين الذي يستلمها العامل من الخدمة، بما في ذلك إعدادات Syslog وعدادات أداء Linux والسجلات المخصصة. إذا فشل هذا الأمر، قم بتشغيل الأمر التالي: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'. يفرض هذا الأمر على عامل omsconfigالتحدث إلى Azure Monitor واسترداد أحدث تكوين.

الخلفية: بدلاً من تشغيل وكيل Log Analytics لنظام التشغيل Linux كمستخدم ذي امتياز - root، يعمل الوكيل كمستخدم omsagent. في معظم الحالات، يجب منح إذن صريح لهذا المستخدم لكي تتم قراءة ملفات معينة. لمنح الإذن omsagent للمستخدم، قم بتشغيل الأوامر التالية:

  1. أضف المستخدم omsagent إلى مجموعة معينة: sudo usermod -a -G <GROUPNAME> <USERNAME>.
  2. منح حق الوصول إلى القراءة الشاملة للملف المطلوب: sudo chmod -R ugo+rx <FILE DIRECTORY>.

هناك مشكلة معروفة تتعلق بحالة تعارض مع عامل Log Analytics لإصدار Linux الأقدم من 1.1.0-217. بعد التحديث إلى أحدث عامل، شغّل الأمر التالي للحصول على أحدث إصدار من المكون الإضافي للإخراج: sudo cp /etc/opt/microsoft/omsagent/sysconf/omsagent.conf /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf.

المشكلة: أنت تحاول إعادة الإلحاق إلى مساحة عمل جديدة

عند محاولة إعادة إلحاق عامل إلى مساحة عمل جديدة، يجب تنظيف تكوين وكيل Log Analytics قبل إعادة إلحاقه. لتنظيف التكوين القديم من العامل، قم بتشغيل مجموعة shell باستخدام --purge:

sudo sh ./omsagent-*.universal.x64.sh --purge

أو

sudo sh ./onboard_agent.sh --purge

يمكنك الاستمرار في إعادة الإلحاق بعد استخدام الخيار --purge.

تم وضع علامة ملحق عامل Log Analytics في مدخل Microsoft Azure بحالة فشل: فشل التوفير

الأسباب المحتملة

  • تمت إزالة عامل Log Analytics من نظام التشغيل.
  • خدمة عامل Log Analytics متوقفة عن التشغيل أو معطلة أو غير مكوّنة.

نوع الحل

  1. أزّل الملحق من مدخل Microsoft Azure.
  2. ثبت العامل باتباع الإرشادات التالية.
  3. أعد تشغيل العامل عن طريق تشغيل الأمر التالي:
    sudo /opt/microsoft/omsagent/bin/service_control restart.
  4. انتظر عدة دقائق حتى تتغير حالة التوفير إلى عملية توفير ناجحة.

المشكلة: ترقية عامل Log Analytics عند الطلب

الأسباب المحتملة

حزم عامل Log Analytics على المضيف قديمة.

نوع الحل

  1. تحقق من أحدث إصدار في صفحة GitHub.

  2. نزّل البرنامج النصي للتثبيت (1.4.2-124 هو إصدار مثال):

    wget https://github.com/Microsoft/OMS-Agent-for-Linux/releases/download/OMSAgent_GA_v1.4.2-124/omsagent-1.4.2-124.universal.x64.sh

  3. ترقية الحزم بتنفيذ sudo sh ./omsagent-*.universal.x64.sh --upgrade.

المشكلة: فشل التثبيت قائلاً إن Python2 لا يمكنه دعم ctypes، على الرغم من استخدام Python3

الأسباب المحتملة

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

نوع الحل

تغيير اللغة البيئية للجهاز الظاهري إلى اللغة الإنجليزية:

export LANG=en_US.UTF-8