تحتوي طريقة العرض / الجذر على الكائنات التالية بعد التثبيت الأولي لمحرك SKOOR ولوحات المعلومات:

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

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

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

جرد الأجهزة

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

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

نموذج الخدمات

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

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

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

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

وحدات تحكم مستوى الخدمة (SLCs)

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

الإنذار

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

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

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

التقارير

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

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