أساسيات مراقبة PostgreSQL. أليكسي ليسوفسكي

أقترح عليك قراءة نص تقرير أليكسي ليسوفسكي من Data Egret "أساسيات مراقبة PostgreSQL"

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

اسمي Alexey Lesovsky ، وأنا أمثل Data Egret.

بضع كلمات عن نفسي. لقد بدأت منذ وقت طويل كمسؤول نظام.

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

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

الآن أنا أعمل بالفعل في PostgreSQL. أنا أكتب بالفعل شيئًا آخر يتيح لك العمل مع إحصائيات PostgreSQL. تسمى pgCenter (مقال عن حبري - حالة Postgres بدون أعصاب وتوتر).

مقدمة صغيرة. ما هي المواقف مع عملائنا ، مع عملائنا؟ هناك نوع من الحوادث المرتبطة بقاعدة البيانات. وعندما يتم استعادة قاعدة البيانات بالفعل ، يأتي رئيس القسم أو رئيس التطوير ويقول: "أيها الأصدقاء ، يجب علينا مراقبة قاعدة البيانات ، لأن شيئًا سيئًا حدث ومن الضروري ألا يحدث هذا في المستقبل." وهنا تبدأ العملية الممتعة لاختيار نظام مراقبة أو تكييف نظام مراقبة موجود حتى تتمكن من مراقبة قاعدة البيانات الخاصة بك - PostgreSQL أو MySQL أو غيرها. ويبدأ الزملاء في تقديم: "سمعت أن هناك قاعدة بيانات كذا وكذا. دعونا نستخدمها ". يبدأ الزملاء في الجدال مع بعضهم البعض. وفي النهاية اتضح أننا نختار نوعًا من قواعد البيانات ، لكن مراقبة PostgreSQL ممثلة بشكل ضعيف فيها وعلينا دائمًا إنهاء شيء ما. خذ بعض المستودعات من GitHub ، واستنسخها ، واضبط البرامج النصية ، وضبطها بطريقة ما. وفي النهاية يقع هذا في نوع من العمل اليدوي.

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

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

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

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

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

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

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

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

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

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

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

نحتاج أيضًا إلى مراقبة العملاء الذين يتصلون بقاعدة البيانات الخاصة بنا ، لأنهم يمكن أن يكونوا عملاء عاديين وعملاء ضارين يمكن أن يضروا بقاعدة البيانات. هم أيضا بحاجة إلى المراقبة والتعقب.

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

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

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

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

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

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

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

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

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

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

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

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

لتقدير عدد المعاملات ، يمكننا الرجوع مرة أخرى إلى عرض pg_stat_database. يمكننا إضافة عدد الارتباطات وعدد عمليات التراجع للحصول على عدد المعاملات في الثانية.

يفهم الجميع أن عدة طلبات يمكن أن تندرج في معاملة واحدة؟ لذلك تختلف TPS و QPS قليلاً.

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

يمكنك إضافة مقاييس إضافية إذا كنت ترغب في ذلك ، مما يساعد أيضًا في تقييم مدى توفر قاعدة البيانات الخاصة بنا وتتبع ما إذا كان هناك أي توقف.

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

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

لماذا يجب مراقبتها؟ لأن الفراغ أحيانًا يؤلم كثيرًا. يستهلك قدرًا كبيرًا من الموارد وتبدأ طلبات العملاء في المعاناة من هذا.

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

ميزة أخرى لـ PostgreSQL هي أن PostgreSQL سئمت جدًا من المعاملات الطويلة. على وجه الخصوص ، من المعاملات التي تتعطل لفترة طويلة ولا تفعل شيئًا. هذه هي ما يسمى الحالة الخاملة في المعاملات. مثل هذه الصفقة تحمل أقفالًا ، فهي تمنع الفراغ من العمل. ونتيجة لذلك - تنتفخ الطاولات ، ويزداد حجمها. والاستعلامات التي تعمل مع هذه الجداول ، تبدأ في العمل بشكل أبطأ ، لأنك تحتاج إلى تجريف جميع الإصدارات القديمة من الصفوف من الذاكرة إلى القرص والعكس. لذلك ، يجب أيضًا مراقبة الوقت ومدة المعاملات الأطول وطلبات الفراغ الأطول. وإذا رأينا بعض العمليات التي كانت تعمل لفترة طويلة جدًا ، لأكثر من 10-20-30 دقيقة لتحميل OLTP ، فنحن بحاجة إلى الاهتمام بها وإجبارها على الإنهاء ، أو تحسين التطبيق بحيث لم يتم استدعاؤهم ولا يتعطلون لفترة طويلة. بالنسبة للحمل التحليلي ، 10-20-30 دقيقة أمر طبيعي ، وهناك أيضًا حمولات أطول.

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

تعتبر المعلومات حول العملاء المتصلين مهمة لأنه ، من وجهة نظر PostgreSQL ، هناك أنواع مختلفة من العملاء. هناك عملاء جيدون وهناك عملاء سيئون.

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

هناك حالات يكون فيها العميل متصلاً ، ويحافظ على الاتصال ، لكنه لا يفعل شيئًا. إنه في حالة الخمول.

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

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

مثال آخر للرصد. وهنا لوحة قيادة جيدة. هناك معلومات عن الاتصالات من أعلى. اتصال DB - 8 قطع. وهذا كل شيء. ليس لدينا معلومات عن العملاء النشطين ، والعملاء العاطلين عن العمل ، ولا يفعلون شيئًا. لا توجد معلومات حول المعاملات المعلقة والوصلات المعلقة ، أي أن هذا الرقم يوضح عدد الاتصالات وهذا كل شيء. ثم خمن لنفسك.

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

إذا رأينا معاملات طويلة ، فيجب علينا إكمالها بالفعل. بالنسبة لتحميل OLTP ، تكون المعاملات الطويلة بالفعل أكثر من 1-2-3 دقائق. بالنسبة إلى تحميل OLAP ، تعتبر المعاملات الطويلة أمرًا طبيعيًا ، ولكن إذا استمرت لأكثر من ساعتين ، فهذه أيضًا علامة على وجود انحراف في مكان ما.

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

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

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

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

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

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

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

مثال آخر للرصد. أعتقد أن الكثير من الناس يتعرفون عليه لأنه يتمتع بشعبية كبيرة. من يستخدم في مشاريعهم محب العمل؟ ومن يستخدم هذا المنتج مع بروميثيوس؟ الحقيقة هي أنه في المستودع القياسي لهذه المراقبة توجد لوحة تحكم للعمل مع PostgreSQL - postgres_exporter بروميثيوس. لكن هناك تفاصيل سيئة واحدة هنا.

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

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

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

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

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

والآن سؤال صغير لك. ما هو السؤال عندما تلاحظ الحمل على خادم قاعدة البيانات؟ ما هو سؤالك القادم؟

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

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

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

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

يمكنك مراقبة الاستعلامات الأطول ، أي تلك الاستعلامات الأطول. يتم تشغيلها على المعالج ، وتستهلك I / O. يمكننا أيضًا تقييم ذلك من خلال الحقول total_time و mean_time و blk_write_time و blk_read_time.

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

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

ويمكنك أيضًا مراقبة الاستعلامات التي تستخدم الملفات المؤقتة أو الجداول المؤقتة.

ولا يزال لدينا عمليات خلفية. عمليات الخلفية هي في المقام الأول نقاط تفتيش أو تسمى أيضًا نقاط التفتيش ، وهي فراغ تلقائي وتكرار.

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

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

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

وفقًا لذلك ، من خلال pg_stat_bgwriter في الحقول المحددة ، يمكننا مراقبة عدد نقاط التفتيش التي تحدث. وإذا كان لدينا الكثير من نقاط التفتيش لفترة زمنية معينة (لمدة 10-15-20 دقيقة ، لمدة نصف ساعة) ، على سبيل المثال ، 3-4-5 ، فقد تكون هذه مشكلة بالفعل. وتحتاج بالفعل إلى البحث في قاعدة البيانات ، والبحث في التكوين ، ما الذي يسبب مثل هذه الوفرة من نقاط التفتيش. ربما يأتي بعض السجل الكبير. يمكننا بالفعل تقييم عبء العمل ، لأننا أضفنا بالفعل مخططات عبء العمل. يمكننا بالفعل تعديل معلمات نقطة التوقف والتأكد من أنها لا تؤثر بشكل كبير على أداء الاستعلام.

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

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

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

الآن لا يوجد عمليًا تثبيت PostgreSQL حيث لم يكن هناك نسخ متماثل للبث. النسخ المتماثل هو عملية نقل البيانات من نسخة رئيسية إلى نسخة متماثلة.

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

وفقًا لذلك ، يتم استخدام طريقة العرض pg_stat_replication لمراقبة تأخر النسخ المتماثل. لكن الأمر ليس سهلاً عليها. في الإصدار 10 ، خضع العرض لعدة تغييرات. أولاً ، تمت إعادة تسمية بعض الحقول. وأضيفت بعض الحقول. في الإصدار العاشر ، ظهرت الحقول التي تسمح لك بتقييم تأخر النسخ المتماثل في ثوانٍ. إنه مريح للغاية. قبل الإصدار 10 ، كان من الممكن تقدير تأخر النسخ بالبايت. ظلت هذه الميزة في الإصدار العاشر ، أي يمكنك اختيار ما هو أكثر ملاءمة لك - تقييم التأخر بالبايت أو تقييم التأخر في ثوانٍ. كثير يفعل كلا الأمرين.

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

في الإصدار 10 ، تمت إعادة تسمية هذه الوظيفة إلى pg_wal_lsn_diff (). بشكل عام ، في جميع الوظائف ، وجهات النظر ، والمرافق ، حيث تم العثور على كلمة "xlog" ، تم استبدالها بالقيمة "wal". هذا في كل من وجهات النظر والوظائف. هذا هو مثل هذا الابتكار.

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

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

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

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

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

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

ولكي تنتهي ، يجب أن يكون لديك دائمًا فكرة عما تعنيه الإحصائيات المقدمة وكيف يمكنك حل المشكلات بها.

وبعض النقاط الرئيسية:

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

إذا كنت مهتمًا بهذا الموضوع ، فيمكنك متابعة هذه الروابط.
http://bit.do/stats_collector هو التوثيق الرسمي من جامع الإحصاءات. يوجد وصف لجميع طرق العرض الإحصائية ووصف لجميع الحقول. يمكنك قراءتها وفهمها وتحليلها. وعلى أساسها ، قم ببناء المخططات الخاصة بك ، أضف إلى مراقبتك.

أمثلة الطلب:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

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

الأسئلة

سؤال: قلت إنك لن تعلن عن العلامات التجارية ، لكنني ما زلت أتساءل - ما نوع لوحات المعلومات التي تستخدمها في مشاريعك؟
الجواب: بطرق مختلفة. يحدث أننا نأتي إلى العميل ولديه بالفعل مراقبتة خاصة به. وننصح العميل بما يجب إضافته إلى مراقبته. أسوأ موقف مع Zabbix. لأنه لا يمتلك القدرة على بناء رسومات TopN. نحن أنفسنا نستخدم اوكمترلأننا استشرنا هؤلاء الأشخاص بشأن المراقبة. لقد قاموا بمراقبة PostgreSQL بناءً على TOR. أنا أكتب مشروع الحيوانات الأليفة الخاص بي ، والذي يجمع البيانات من خلال بروميثيوس ويرسمها جرافانا. مهمتي هي أن أجعل المصدر الخاص بي في بروميثيوس ثم أرسم كل شيء في جرافانا.

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

PS1 إذا كنت تستخدم postgres_exporter ، فما هي لوحة التحكم التي تستخدمها؟ هناك العديد منها. لقد عفا عليها الزمن بالفعل. هل يمكن للمجتمع إنشاء نموذج محدث؟

تمت إزالة PS2 pganalyze لأنه عرض SaaS خاص يركز على مراقبة الأداء واقتراحات الضبط الآلي.

يمكن للمستخدمين المسجلين فقط المشاركة في الاستطلاع. تسجيل الدخول، من فضلك.

ما هي مراقبة postgresql ذاتية الاستضافة (مع لوحة القيادة) التي تعتقد أنها الأفضل؟

• 30,0%إضافات Zabbix + من Alexey Lesovsky أو ​​zabbix 4.4 أو libzbxpgsql + zabbix libzbxpgsql + zabbix3

• 0,0%https://github.com/lesovsky/pgcenter0

• 0,0%https://github.com/pg-monz/pg_monz0

• 20,0%https://github.com/cybertec-postgresql/pgwatch22

• 20,0%https://github.com/postgrespro/mamonsu2

• 0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0

• 10,0%pganalyze هي SaaS مملوكة - لا يمكن حذفها 1

• 10,0%https://github.com/powa-team/powa1

• 0,0%https://github.com/darold/pgbadger0

• 0,0%https://github.com/darold/pgcluu0

• 0,0%https://github.com/zalando/PGObserver0

• 10,0%https://github.com/spotify/postgresql-metrics1

صوت 10 مستخدمين. امتنع 26 مستخدما عن التصويت.

المصدر: www.habr.com