postgres_exporter ومراقبة مثيلات PostgreSQL مع قواعد بيانات متعددة

محدث: لقد فقدت الملاحظة أهميتها بإصدار 0.8.0. يمكن العثور على جميع الابتكارات في المقالة: ميزات جديدة من postgres_exporter لمراقبة PostgreSQL

مساء الخير أيها القراء!

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

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

هدف

في الواقع ، حول الغرض من المادة أو بالأحرى الملاحظات. ألاحظ على الفور أنني هنا لن أصف عمليات التجميع أو التكوين لـ Prometheus و postgres_exporter ، تفاعلهما. كل هذا موصوف في الوثائق وفي العديد من المصادر الأخرى.

أود أن أتطرق إلى بعض الحالات الخاصة لاستخدام postgres_exporter لحل مشاكل محددة ، وهي جمع المقاييس بواسطة وكيل واحد باستخدام:

1. عدة قواعد بيانات في حالة واحدة ؛
2. عدة نسخ
3. قواعد بيانات متعددة على حالات مختلفة.

postgres_exporter

ذاتي ، إيجابيات وسلبيات.

من الايجابيات:

1. الميزة الأولى والمهمة هي سهولة التسليم وتكوين الوكيل. العامل - هو ملف قابل للتنفيذ (اختياريًا ، ملف yaml مع مجموعة من مقاييس المستخدم). هذا تطبيق قائم بذاته تم تجميعه للتوزيع والهندسة الضروريين ، ولا يتطلب تثبيت حزم إضافية على الخادم. يمكن تثبيت العامل على نفس العقدة مثل مثيل الكتلة وعلى عقدة منفصلة؛
2. يتصل الوكيل بـ DBMS كعميل sql منتظم. من الممكن الاتصال عبر آينت أو عبر مقبس يونيكس ؛
3. القدرة على تلقي المقاييس بواسطة وكيل واحد ، من عدة مثيلات و / أو من عدة قواعد بيانات لمثيل واحد ؛
4. يتم جمع القياسات حسب طلب بروميثيوس أو جامع آخر ؛
5. القدرة على تلقي المقاييس مع طلب HTTP بسيط ؛
6. الاستلام التلقائي ، من قبل وكيل ، لقائمة قواعد البيانات على مثيل PostgreSQL واحد ، مع إصدار postgres_exporter 0.5.0+ ، ظهر خيار --auto-discover-قواعد البيانات.

من السلبيات:

1. عدم وجود ترخيص ؛
2. نقل البيانات فقط عبر HTTP. سيتم نقل جميع المقاييس في نص واضح. وهذا أمر سيئ ، حيث يمكن للمهاجم عند اعتراضه الحصول على قائمة موثوقة من قواعد البيانات والأدوار ؛
3. لا مخبأ المقاييس. وبالتالي ، على سبيل المثال ، عندما يكون الوكيل غير متاح للشبكة ، لن يتم استلام البيانات الخاصة بفترة عدم التوافر من قِبل Prometheus ؛
4. عند استخدام خيار --auto-discover-database ، لا يمكن استبعاد بعض قواعد البيانات من القائمة. هذا مؤقت إلى حد ما ، لأنه في الإصدار التالي ، يجب أن يظهر هذا الاحتمال بالفعل (الخيار - استثناء قواعد البيانات).

قواعد بيانات متعددة في مثيل واحد

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

لدينا نسخة اختبار مع مجموعة من قواعد البيانات:

List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges -----------+----------+----------+------------+------------+----------------------- dbtest1 | postgres | UTF8 | en_US.utf8 | en_US.utf8 | dbtest2 | postgres | UTF8 | en_US.utf8 | en_US.utf8 | dbtest3 | postgres | UTF8 | en_US.utf8 | en_US.utf8 | postgres | postgres | UTF8 | en_US.utf8 | en_US.utf8 | 

نبدأ postgres_exporter ، مع وجود خيار - قواعد اكتشاف السيارات - (إذا لم يكن اسم قاعدة البيانات محددًا في سلسلة الاتصال ، فسيتم الاتصال بقاعدة البيانات باسم المستخدم):

 $ DATA_SOURCE_NAME="postgresql://postgres@127.0.0.1:5432/?sslmode=disable" ./postgres_exporter --auto-discover-databases --log.format=logger:stdout 

• DATA_SOURCE_NAME - متغير بيئة يحتوي على معلمات للاتصال بمثيل PostgreSQL

في إخراج الوكيل ، نلاحظ صورة مثالية ، تم إطلاقها وتمكنت من الاتصال بجميع قواعد البيانات في المجموعة (على الرغم من أنها لا تكتب إلى قواعد البيانات ، ولكن نأمل أن تكون ثابتة):

 INFO[0000] Established new database connection to "127.0.0.1:5432". source="postgres_exporter.go:788" INFO[0000] Established new database connection to "127.0.0.1:5432". source="postgres_exporter.go:788" INFO[0000] Semantic Version Changed on "127.0.0.1:5432": 0.0.0 -> 11.5.0 source="postgres_exporter.go:1251" INFO[0000] Semantic Version Changed on "127.0.0.1:5432": 0.0.0 -> 11.5.0 source="postgres_exporter.go:1251" INFO[0000] Established new database connection to "127.0.0.1:5432". source="postgres_exporter.go:788" INFO[0000] Semantic Version Changed on "127.0.0.1:5432": 0.0.0 -> 11.5.0 source="postgres_exporter.go:1251" INFO[0000] Established new database connection to "127.0.0.1:5432". source="postgres_exporter.go:788" INFO[0000] Semantic Version Changed on "127.0.0.1:5432": 0.0.0 -> 11.5.0 source="postgres_exporter.go:1251" INFO[0000] Established new database connection to "127.0.0.1:5432". source="postgres_exporter.go:788" INFO[0000] Semantic Version Changed on "127.0.0.1:5432": 0.0.0 -> 11.5.0 source="postgres_exporter.go:1251" INFO[0000] Starting Server: :9187 source="postgres_exporter.go:1490" 

أعتقد أن القارئ المهتم سوف يلاحظ وجود أربع قواعد في المجموعة (يتم تجاهل postgres و dbtest1 و dbtest2 و dbtest3 و template0 و template1) ، وهناك خمسة اتصالات. في حالتنا ، ينشئ postgres_exporter اتصالين لقاعدة بيانات postgres. ومع هذه الميزة تحتاج إلى أن تكون حذرا للغاية. لماذا؟ سنكتشف المزيد حول هذا الموضوع.

حسنًا ، دعنا نستمر ونحاول الحصول على المقاييس:

 $ curl http://localhost:9178/metrics 

نتيجة لذلك ، في الإخراج نحصل على تحذيرات حول التكرارات "تم جمعها من قبل بنفس الاسم وقيم التصنيف" (ولكن في سجل postgres_exporter ، لن نشاهد تحذيرات):

 ... * collected metric pg_stat_activity_max_tx_duration label:<name:"datname" value:"dbtest1" > label:<name:"server" value:"127.0.0.1:5432" > label:<name:"state" value:"fastpath function call" > gauge:<value:0 > was collected before with the same name and label values * collected metric pg_stat_bgwriter_checkpoints_timed label:<name:"server" value:"127.0.0.1:5432" > counter:<value:1 > was collected before with the same name and label values ... 

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

أعد تشغيل postgres_exporter مع خيارات إضافية:

 $ DATA_SOURCE_NAME="postgresql://postgres@127.0.0.1:5432/?sslmode=disable" ./postgres_exporter --auto-discover-databases --log.format=logger:stdout --disable-default-metrics --disable-settings-metrics 

محاولة الحصول على المقاييس:

 $ curl http://localhost:9178/metrics 

وهكذا ، ذهب كل شيء وفقًا للخطة ، لكن لا يوجد مقياس واحد يرتبط بـ PostgreSQL في الإخراج:

 # HELP go_gc_duration_seconds A summary of the GC invocation durations. # TYPE go_gc_duration_seconds summary go_gc_duration_seconds{quantile="0"} 0 go_gc_duration_seconds{quantile="0.25"} 0 go_gc_duration_seconds{quantile="0.5"} 0 go_gc_duration_seconds{quantile="0.75"} 0 go_gc_duration_seconds{quantile="1"} 0 go_gc_duration_seconds_sum 0 go_gc_duration_seconds_count 0 ... # HELP process_virtual_memory_bytes Virtual memory size in bytes. # TYPE process_virtual_memory_bytes gauge process_virtual_memory_bytes 1.3832192e+07 

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

بالنسبة للاختبار ، سنقوم بجمع مقاييس من علاقة pg_statio_user_tables. للقيام بذلك ، قم بإنشاء ملف queries.yaml بالمحتويات التالية:

 pg_statio_user_tables: query: "SELECT current_database() as datname, schemaname, relname, heap_blks_read, heap_blks_hit FROM pg_statio_user_tables" metrics: - datname: usage: "LABEL" description: "Name of database" - schemaname: usage: "LABEL" description: "Name of the schema that this table is in" - relname: usage: "LABEL" description: "Name of this table" - heap_blks_read: usage: "COUNTER" description: "Number of disk blocks read from this table" - heap_blks_hit: usage: "COUNTER" description: "Number of buffer hits in this table" 

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

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

وهكذا ، نطلق وكيلنا مع الخيار --extend.query-path (هنا يشار إلى المسار إلى ملف yaml مع وصف المقاييس):

 DATA_SOURCE_NAME="postgresql://postgres@127.0.0.1:5432?sslmode=disable" ./postgres_exporter --log.format=logger:stdout --auto-discover-databases --disable-default-metrics --disable-settings-metrics --extend.query-path=./queries.yaml 

نحاول الحصول على المقاييس (للتوضيح ، نأخذ فقط pg_statio_user_tables_heap_blks_hit):

 curl -s http://localhost:9187/metrics | grep pg_statio_user_tables_heap_blks_hit 

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

 # HELP pg_statio_user_tables_heap_blks_hit Number of buffer hits in this table # TYPE pg_statio_user_tables_heap_blks_hit counter pg_statio_user_tables_heap_blks_hit{datname="dbtest1",relname="t1",schemaname="public",server="127.0.0.1:5432"} 0 pg_statio_user_tables_heap_blks_hit{datname="dbtest1",relname="t2",schemaname="public",server="127.0.0.1:5432"} 0 pg_statio_user_tables_heap_blks_hit{datname="dbtest2",relname="t1",schemaname="public",server="127.0.0.1:5432"} 0 pg_statio_user_tables_heap_blks_hit{datname="dbtest2",relname="t2",schemaname="public",server="127.0.0.1:5432"} 0 pg_statio_user_tables_heap_blks_hit{datname="dbtest3",relname="t1",schemaname="public",server="127.0.0.1:5432"} 0 pg_statio_user_tables_heap_blks_hit{datname="dbtest3",relname="t2",schemaname="public",server="127.0.0.1:5432"} 0 

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

حالات متعددة

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

 $ DATA_SOURCE_NAME="postgresql://postgres@127.0.0.1:5432/postgres?sslmode=disable,postgresql://postgres@127.0.0.1:5434/postgres?sslmode=disable" ./postgres_exporter --log.format=logger:stdout 

نحن هنا نصل إلى حالتين نظاميتين مختلفتين تعملان ، في حالتنا ، على العقدة المحلية. إليك ما يبدو في السجلات:

 INFO[0000] Established new database connection to "127.0.0.1:5432". source="postgres_exporter.go:788" INFO[0000] Semantic Version Changed on "127.0.0.1:5432": 0.0.0 -> 11.5.0 source="postgres_exporter.go:1251" INFO[0000] Established new database connection to "127.0.0.1:5434". source="postgres_exporter.go:788" INFO[0000] Semantic Version Changed on "127.0.0.1:5434": 0.0.0 -> 11.5.0 source="postgres_exporter.go:1251" INFO[0000] Starting Server: :9187 source="postgres_exporter.go:1490" 

بعد ذلك ، نحاول الحصول على المقاييس (للتوضيح ، نقصر أنفسنا على مقياس pg_stat_database_blk_read_time):

 curl -s http://localhost:9187/metrics | grep pg_stat_database_blk_read_time 

نتيجة لذلك ، من وكيل واحد ، نحصل على مقاييس لكلتا الحالتين:

 # HELP pg_stat_database_blk_read_time Time spent reading data file blocks by backends in this database, in milliseconds # TYPE pg_stat_database_blk_read_time counter pg_stat_database_blk_read_time{datid="1",datname="template1",server="127.0.0.1:5432"} 0 pg_stat_database_blk_read_time{datid="1",datname="template1",server="127.0.0.1:5434"} 0 pg_stat_database_blk_read_time{datid="13116",datname="template0",server="127.0.0.1:5432"} 0 pg_stat_database_blk_read_time{datid="13116",datname="template0",server="127.0.0.1:5434"} 0 pg_stat_database_blk_read_time{datid="13117",datname="postgres",server="127.0.0.1:5432"} 0 pg_stat_database_blk_read_time{datid="13117",datname="postgres",server="127.0.0.1:5434"} 0 pg_stat_database_blk_read_time{datid="16384",datname="dbtest1",server="127.0.0.1:5432"} 0 pg_stat_database_blk_read_time{datid="16385",datname="dbtest2",server="127.0.0.1:5432"} 0 pg_stat_database_blk_read_time{datid="16386",datname="dbtest3",server="127.0.0.1:5432"} 0 

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

ملخص

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

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

مصادر

• بروميثيوس [ 1 ] هو تطبيق مفتوح المصدر يستخدم لمراقبة الأحداث وتنبيهها. يكتب مقاييس في الوقت الحقيقي إلى قاعدة بيانات سلسلة زمنية تم إنشاؤها باستخدام نموذج طلب HTTP ، مع استعلامات مرنة وتنبيهات في الوقت الحقيقي.
• postgres_exporter هي مصدر لقياسات PostgreSQL لـ Prometheus.

الإصدار ، وقت كتابة هذا التقرير ، الإصدار 0.5.1. الإصدارات المدعومة من PostgreSQL 9.4+ (الإصدار 9.1 + التقييد المشار إليه في شفرة المصدر).