تحتوي طريقة العرض /root على الكائنات التالية بعد التثبيت الأولي لـ SKOOR Engine و Dashboards:

هيكل الكائن الموصى به

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

• /root

  • <Customer or project name>

    • Configurations

      • Graphs

      • Import / export

      • OPM

      • Schedule

      • ...

    • Devices

      • Databases

      • EEM (End to end monitoring robot devices)
        

      • Network

        • Firewalls

        • Load balancers
          

        • Routers

        • Switches

        • Wireless

        • ...

      • Other

      • Printers

      • Servers

        • Servers by location

          • London

            • lx203

            • lx204
              

          • Zürich

        • Servers by OS
          

          • Linux servers

            • Dev

            • Prod

              • lx203

                • ICMP

                • Disk space

                • CPU / Memory

                • Service slapd
                  

              • lx204 

                • ICMP

                • Disk space

                • CPU / Memory

                • Service slapd

          • Windows servers

          • ...

      • Storage

      • Virtualization hosts
        

    • Reports

      • Business service 1 service report
        

      • Business service 1 service report monthly scheduler

      • Business service 1 service report weekly scheduler

    • Services

      • SLCs

        • SLA Business service 1 monthly

          • Business service 1
            

        • SLA Business service 1 yearly

          • Business service 1
            

      • SLOs

        • Business service 1
          

          • Function DB
            

            • DB Server 1

            • DB Server 2
              

          • Function LDAP (correlation rule: 1 of 2)
            

            • LDAP Server 1

              • ICMP on lx203

              • Disk space on lx203

              • CPU / Memory on lx203

              • Service slapd on lx203

            • LDAP Server 2

              • ICMP on lx204

              • Disk space on lx204

              • CPU / Memory on lx204

              • Service slapd on lx204

          • Function Network

            • DHCP

              • DHCP 1

              • DHCP 2
                

            • DNS

            • NTP

          • Function Webserver

            • ...

        • IT service 1
          

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

جرد الأجهزة

عادةً ما تكون الخطوة الأولى هي إنشاء كائنات الأجهزة في مكان ما أسفل مجموعة الأجهزة. هنا، تم تنظيم مجموعة الأجهزة حسب وظيفة الجهاز (الخوادم، التخزين ...) أولاً، ثم إما حسب الوظيفة الفرعية أو معايير أخرى. على سبيل المثال، الخوادم Linux lx203 و lx204 موجودتان في مجموعة الخوادم حسب نظام التشغيل/خوادم Linux/الإنتاج. إذا أراد المرء تنظيمها حسب الموقع، فهذا ممكن أيضًا. لهذا الغرض، تم ربط الجهازين بمجموعة Servers by location/London (الخوادم حسب الموقع/لندن). جهازي خادم Linux الموجودان أسفل هاتين المجموعتين متطابقان، ولهما نفس معرّفات الكائنات ويحتويان على نفس مهام القياس. على سبيل المثال، سيظهر تغيير اسم lx203 أسفل كلتا مجموعتيه الأصلية. سيؤدي حذف lx203 إلى حذفه في كلتا المجموعتين. ومع ذلك، يمكنك فقط إلغاء ربطه بدلاً من حذفه، وبذلك سيبقى أسفل المجموعة الأم الأخرى.

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

نموذج الخدمة

تحتوي المجموعة الفرعية الخدمات/SLOs على كائنات الخدمة العليا. تمثل هذه الكائنات حالة الخدمة (الخدمات) النموذجية. أسفلها، يتم إنشاء شجرة نموذجية باستخدام كائنات مستوى الخدمة (SLOs)، والتي تسمح بتحديد قواعد الترابط لـ SLOs الفرعية.

بعد إنشاء أو استيراد الأجهزة وإنشاء مهام القياس أسفلها، يمكن ربط هذه المهام أسفل مجموعة الخدمات. عادةً ما يتم ربط المهام الفردية فقط بـ SLOs، ولكن يمكن أيضًا ربط أجهزة أو مجموعات كاملة بـ SLOs.

أسفل SLO Business service 1 الأعلى، يتم نمذجة وظائف الخدمة. يجب أن يمثل النموذج شجرة التبعية لـ Business service 1. على سبيل المثال، يتم إعداد وظيفة LDAP، التي تعتمد عليها هذه الخدمة، بحيث لا يلزم تشغيل سوى خادم LDAP واحد من الخادمين. في هذا المثال، أحد خادمي LDAP لا يعمل لأن خدمة slapd الخاصة به لا تعمل. ومع ذلك، لا تزال الخدمة متاحة للعميل. عادةً ما ينعكس هذا النوع من الإعداد في SKOOR باستخدام SLO مع قاعدة ارتباط (1 من 2). تكون حالة وظيفة LDAP ثانوية (برتقالية) إذا كان خادم LDAP واحد معطلاً، وتكون حالة وظيفة LDAP رئيسية (حمراء) إذا كان كلا الخادمين معطلين. يتم تكوين SLO Business service 1 بحيث يتم أخذ الحالات الرئيسية فقط من الوظائف أدناه في الاعتبار، لذلك تظل في حالة OK (خضراء) في مثل هذا السيناريو.

تحدد شجرة النموذج كيفية دفع الحالات من مستوى المهمة إلى وظيفة الخدمة وإلى كائن الخدمة الأعلى.

وحدات التحكم في مستوى الخدمة (SLC)

تحتوي المجموعة الفرعية Services/SLCs على كائنات وحدة التحكم في مستوى الخدمة. عادةً ما ترتبط SLCs بأعلى SLO لخدمة ما (على سبيل المثال، الخدمة التجارية 1) وتقيس مدى الوفاء باتفاقية مستوى الخدمة (SLA) بناءً على فترة زمنية محددة وهدف توفر (على سبيل المثال، 99.9٪). تحدد اتفاقية مستوى الخدمة (SLA)، وهي عقد بين مزود الخدمة ومستهلك الخدمة، أهدافًا قابلة للقياس ومتفق عليها للأداء و/أو التوافر.

الإنذار

يستخدم محرك SKOOR كائنات أجهزة الإنذار لاستشعار التغييرات في حالات الكائنات الموجودة أسفل شجرة الأجهزة أو الخدمات والتصرف بناءً على هذه التغييرات (على سبيل المثال، إرسال بريد إلكتروني إلى الشخص المسؤول عن الجهاز أو الخدمة). يمكن دمج أجهزة الإنذار هذه في مجموعات إنذار. في السيناريو أعلاه، يوجد عادةً مساران للإنذار:

1. الإنذار الفني تلاحظ
   مهام القياس الموجودة أسفل أي من الكائنات في شجرة الأجهزة الأعطال وتغير حالتها اعتمادًا على حدود الإنذار المكونة في كل مهمة. كل تغيير من هذه التغييرات في الحالة يصدر إنذارًا على المهمة والجهاز نفسه. قد لا تؤدي هذه الإنذارات الفنية إلى انقطاع الخدمة، ولكنها مع ذلك مهمة للموظفين الفنيين ويجب إصلاحها على المدى الطويل. لإعادة توجيه هذه الإنذارات إلى الأشخاص المسؤولين (عبر البريد الإلكتروني)، يتم إرفاق أجهزة الإنذار أو مجموعات الإنذار بالأجهزة الفردية أو مجموعة /root/<اسم العميل أو المشروع>/Devices.

2. إنذار الخدمة لا
   يهتم مديرو الخدمة عادةً بالأعطال الفنية التي لا تؤثر على خدمتهم. ومع ذلك، إذا تم نشر أي قياسات أسفل شجرة الخدمة إلى كائن الخدمة الأعلى، فإنهم يرغبون في أن يتم إخطارهم على الفور. لهذا الغرض، يتم إرفاق أجهزة إنذار أو مجموعات إنذار منفصلة بالخدمات الفردية الموجودة أسفل /root/<اسم العميل أو المشروع>/Services/SLOs. على سبيل المثال، إذا توقفت خدمة slapd على كلا خادمي LDAP عن العمل، ستتحول وظيفة LDAP إلى اللون الأحمر، وبالتالي ستتحول خدمة Business 1 أيضًا إلى اللون الأحمر. سيقوم كائن الإنذار المرفق بإرسال بريد إلكتروني إلى مدير الخدمة.

التقارير

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

بالإضافة إلى PDF، يمكن تكوين تقارير أخرى أيضًا، مثل تقارير CSV أو XML.