إنشاء لوحات معلومات للرؤية التشغيلية

نُشغل جميعنا تطبيقات على أجهزة الكمبيوتر المحمول والأجهزة اللوحية والهواتف الذكية خاصتنا. من السهل لنا معرفة إذا كان الجهاز مزود بالطاقة وإذا كان اتصال شبكة Wi-Fi موصل عبر الإنترنت. نعرف أن شاشاتنا ستعرض أي إشعارات هامة مثل التحذيرات بانخفاض المساحة الحرة بالقرص. في الواقع يمكن للاستجابة والسرعة العامة لواجهة المستخدم أن تكون مؤشرًا جيدًا حول إذا كان الجهاز به موارد كافية، وذلك مثل الذاكرة ووحدة المعالجة المركزية من أجل تشغيل تطبيقاتنا.

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

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

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

نستخدم لوحات المعلومات كواحدة من الآليات لمواجهة تحدي البقاء على قمة النشاط في خدماتنا السحابية. لوحات المعلومات هي طرق عرض لأوجه بشرية بأنظمتنا توفر ملخصات دقيقة لكيفية عمل النظام من خلال عرض مقاييس للتسلسل الزمني والسجلات وحلات التعقب وبيانات للتنبيهات.

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

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

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

عندما يكون الحدث قيد التقدم، تساهم Amazon عادة بمعالجين «قيد الاستدعاء» متعددين. قد يستخدم المعالجون لوحات معلومات مختلفة نظرًا لتدرجهم في سلسلة من المهام. تتضمن هذه المهام عادة تحديد الأثر الواقع على العملاء وتتبع الخدمات المتعددة وتحديدها للوصول للسبب الأساسي للحدث ومراقبة تدفقات عمل المعالجة المؤتمتة وتنفيذ خطوات الحد من الهجمات على أساس الإجراءات التنفيذية والتحقق منها. أثناء ذلك تستخدم الفرق النظيرة وأصحاب مصالح الأعمال لوحات معلومات لمراقبة التأثير المتواصل خلال الحدث. يتواصل هؤلاء المشاركين المختلفين باستخدام أدوات إدارة الأحداث وغرف الدردشة (باستخدام روبوتات مثل AWS Chatbot) والمؤتمرات عبر الهواتف. يتبنى كل صحاب عمل رؤية مختلفة حول البيانات التي يراها في لوحات المعلومات.

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

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

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

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

يوضح الرسم التخطيطي التالي كيف توفر لوحات المعلومات المختلفة طرق عرض مختلفة في النظام بشكل مجمل:

في Amazon، تعتبر لوحات معلومات تجارب العملاء هي لوحات المعلومات الأكثر أهمية وأوسع استخدامًا. لوحات المعلومات هذه مصممة ليستخدمها مجموعة واسعة من المستخدمين تتضمن معالجين للخدمات وعديد من أصحاب المصالح الأخرى. يقدمون مقاييس بشكل فعال حول سلامة الخدمات إجمالًا والالتزام بالأهداف. يعرضون بيانات المراقبة والتي مصدرها يأتي من الخدمة ذاتها ومن أدوات العميل أيضًا ومن أدوات اختبار متواصلة (مثل عمليات الكناري لـ Amazon CloudWatch Synthetics) وأنظمة معالجة مؤتمتة. تحتوي لوحات المعلومات هذه أيضًا على بيانات تساعد المستخدمين في الإجابة على الأسئلة حول عمق واتساع التأثير. بعض من هذه الأسئلة من المحتمل أن تكون «كم عدد العملاء المتأثرين؟» و«أي العملاء أكثر تأثرًا؟»

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

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

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

ننشئ بعضًا من لوحات المعلومات لتسهيل التقييم السريع والشامل لتجارب العملاء ضمن مثيل خدمة فردي (قسم أو خلية). يضمن هذا العرض الضيق أن المعالجين الذين يعملون على مثيل خدمة فردي غير محملين ببيانات ليست ذات صلة بمثيلات خدمة أخرى.

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

بالنسبة لحالات الاستخدام ذات المدى الأطول، ننشئ أيضًا لوحات معلومات للتنبؤات والتخطيط للسعة لمساعدتنا على تصور نمو خدماتنا.

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

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

تعمل خدمتنا على البنية التحتية لـ AWS والتي تحذف عادة المقاييس، لذا خصصنا أيضًا لوحات معلومات للبنى التحتية. تركز لوحات المعلومات بشكل أساسي هذه على المقاييس التي تم حذفها بواسطة موارد الحوسبة التي تعمل على أنظمتنا، مثل مثيلات Amazon Elastic Compute Cloud (EC2) وحاويات Amazon Elastic Container Service (ECS)\Amazon Elastic Kubernetes Service (EKS) ووظائف AWS Lambda. المقاييس مثل استخدام وحدات المعالجة المركزية، وحركة مرور الشبكة وإدخال وإخراج القرص واستخدام المساحة يتم استخدمهم عادة في لوحات المعلومات هذه بجانب أي مجموعة ذات صلة وAuto Scaling ومقاييس الحصة ذات الارتباط بموارد الحوسبة هذه.

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

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

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

تبنينا قاعدة تصميم توحد مخطط البيانات بلوحة المعلومات. تُعرض لوحات المعلومات من أعلى إلى أسفل، كما يميل المستخدمين إلى تفسير الرسوم المعروضة بشكل مبدئي (مرئية عند تحميل لوحة المعلومات) بأنها الأكثر أهمية. وعليه، ترشدنا قاعدة التصميم إلى وضع أهم البيانات في أعلى لوحة المعلومات. اكتشفنا أن رسوم التوافر للملخص\المجمعة ورسوم القيم المئوية لزمن الوصول الشامل أنها عادة أهم لوحات معلومات لخدمات الويب.

ها هي لقطة شاشة لأعلى لوحة معلومات لخدمة «Foo» افتراضية.

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

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

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

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

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

توفر لوحات المعلومات خاصتنا أدوات تحكم من أجل تعديل الفاصل الزمني وفترة المقياس بسرعة لكل الرسوم. هناك نسب للدقة x للفاصل شائعة أيضًا كم أننا نستخدمها في لوحات المعلومات لدينا، وهي:

• -1ساعة x 1 دقيقة (60 نقطة بيانات) – وهي مفيدة للتكبير لمراقبة الأحداث المتواصلة
• 12-ساعة x 1 دقيقة (720 نقطة بيانات)
• 1-يوم x 5 دقائق (288 نقطة بيانات) – وهي مفيدة لعرض الاتجاهات اليومية
• 3-أيام x 5 دقائق (864 نقطة بيانات)
• 1-أسبوع x 1 ساعة (168 نقطة بيانات) – وهي مفيدة لعرض الاتجاهات الأسبوعية
• 1-شهر x 1 شهر (744 نقطة بيانات)
• 3-شهر x 1 يوم (90 نقطة بيانات) – وهي مفيدة لعرض الاتجاهات الربع سنوية
• 9-أشهر x 1 يوم (270 نقطة بيانات)
• 15-شهر x 1 يوم (450 نقطة بيانات) – وهي مفيدة لمراجعات السعة طويلة المدى
  

عندما نرسم مقاييس ذات صلة بالتنبيهات المؤتمتة، إذا كانت حدود التنبيهات ثابتة، نضيف رسوم بخطوط أفقية. إذا كانت حدود التنبيهات متغيرة، وترتكز على تنبؤات أو توقعات تم إنشاءها باستخدام الذكاء الاصطناعي (AI) أو تعلم الآلة (ML)، نعرض مقاييس الحدود والمقاييس الفعلية في نفس الرسم. إذا كان الرسم يعرض مقياسًا يقيس جانب من الخدمة لديها حدود معروفة (مثل «أقصى اختبار» للحد أو حد أقصى للموارد)، نضيف الرسم بخط أفقي مما يشير لمكان الحدود المعروفة والتي تم اختبارها. بالنسبة للمقاييس التي لديها أهداف، نضيف خطوط أفقية لجعل هذه الأهداف مرئية على الفور للمستخدم.

إذا أضفت خطوط أفقية لهذه الرسوم، فقد يجده المستخدمين صعبًا معرفة أي محور-y يرتبط بالخط الأفقي. لتجنب هذا الغموض، نقسم الرسوم مثل الشبيه بهذه إلى رسمين من أجل استخدم محور أفقي فردي فقط وإضافة خطوط أفقية فقط إلى الرسم المناسب.

نتجنب هذا الموقف لأنه يمكن أن ينتج عنه رؤية مخفضة داخل تنوع واحد أو أكثر من المقاييس. مثال على ذلك، هو عندما نرسم أزمنة استجابة p0 (كحد أدنى) وp100 (كحد أقصى) على نفس الرسم حيث تكون قيم نقاط بيانات p100 أوامر بحجم أكبر من نقاط بيانات p0.

يمكن للمحة العارضة في رسم ما باستخدام نطاق محور-y المحدود فقط لقيم نقاط البيانات أن يجعل المقياس يبدوا أكثر تغيرًا عما هو عليه فعليًا.

نريد ضمان عدم امتلاك إحصائيات عديدة أو مقاييس ليست ذات صلة في رسم واحد. على سبيل المثال، عند إضافة رسوم لمعالجة الطلبات، ننشئ عادة رسوم متجاورة منفصلة في لوحة المعلومات للتالي:

• التوافر % (الأعطال\الطلبات * 100)
• أزمنة استجابة لـ p10، المتوسط، p90
• أزمنة استجابة لـ p99.9، وأقصى حد (p100)
  

ينطبق هذا بالخصوص على مقاييس التطبيق المخصصة. نريد توفير سياق كاف في نص لوحة المعلومات، على سبيل المثال، مع نص الوصف بجانب أو أسفل كل رسم. يمكن للمعالج قراءة هذا النص لفهم ما يعنيه المقياس. بعد ذلك يمكن للمعالج تفسير ما يشبه «العادي» وما قد يعنيه إذا لم يكن الرسم «عادي.» بهذا النص، نوفر الروابط للموارد المرتبطة التي يمكن للمعالج استخدامها لتحديد السبب الأساسي. ها هي بعض الأمثلة لأنواع الروابط التي نوفرها:

• للإجراءات التنفيذية. بالنسبة للخبراء المتخصصين، يمكن أن تكون لوحة المعلومات هي الإجراءات التنفيذية.
• للوحات المعلومات ذات الصلة بـ «التعمق».
• للوحات المعلومات المكافئة لمجموعات أو أقسام أخرى.
• لمسارات معالجة النشر.
• لمعلومات الاتصال للتبعيات.
  

اعتمادًا على حالات الاستخدام للوحة المعلومات، نجد أن عرض عنصر واجهة مستخدم يحتوي على عدد فردي (مثل، أحدث قيمة للمقياس) أو حالة التنبيه تكون أحيانًا أكثر مناسبة من عرض رسم للتسلسل الزمني المعقد لكل نقاط البيانات الحديثة.

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

نقوم بذلك عندما نعرض رسوم للمقاييس التي تجمِّع السلوك متعدد النماذج في أنظمتنا. وفي بعض الظروف قد نفعل ما يلي:

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