اصول نظارت PostgreSQL. الکسی لسوفسکی

پیشنهاد می کنم با رونوشت گزارش الکسی لسوفسکی از Data Egret "مبانی نظارت PostgreSQL" آشنا شوید.

در این گزارش، الکسی لسوفسکی در مورد نکات کلیدی آمارهای postgres، معنای آنها و اینکه چرا آنها باید در نظارت گنجانده شوند صحبت می کند. در مورد اینکه چه نمودارهایی باید در نظارت باشد، چگونه آنها را اضافه کنیم و چگونه تفسیر کنیم. این گزارش برای مدیران پایگاه داده، مدیران سیستم و توسعه دهندگانی که علاقه مند به عیب یابی Postgres هستند مفید خواهد بود.

نام من Alexey Lesovsky است، من نماینده Data Egret هستم.

چند کلمه در مورد خودم من مدتها پیش به عنوان یک مدیر سیستم شروع کردم.

من انواع مختلف لینوکس را مدیریت کردم، کارهای مختلفی در رابطه با لینوکس انجام دادم، مانند مجازی سازی، نظارت، کار با پراکسی ها و غیره. اما در مقطعی بیشتر درگیر پایگاه های داده، PostgreSQL شدم. من او را خیلی دوست داشتم. و در برخی موارد، من شروع به سر و کار با PostgreSQL در بیشتر اوقات کاری خود کردم. و بنابراین به تدریج من یک PostgreSQL DBA شدم.

و در طول کارم همیشه به موضوعات آمار، مانیتورینگ، تله متری علاقه داشتم. و زمانی که من یک مدیر سیستم بودم، روی Zabbix بسیار سخت کار می کردم. و مجموعه کوچکی از اسکریپت ها را نوشت zabbix-extensions. او در زمان خود بسیار محبوب بود. و در آنجا امکان نظارت بر موارد مهم بسیار متفاوت وجود داشت، نه تنها لینوکس، بلکه اجزای مختلف.

اکنون من در حال انجام PostgreSQL هستم. من قبلاً چیز دیگری می نویسم که به شما امکان می دهد با آمار PostgreSQL کار کنید. نامیده می شود pgCenter (مقاله در Habré - وضعیت Postgres بدون اعصاب و تنش).

یک مقدمه کوچک شرایط با مشتریان ما، با مشتریان ما چگونه است؟ نوعی تصادف مرتبط با پایگاه داده وجود دارد. و وقتی دیتابیس از قبل بازسازی شد، رئیس اداره یا رئیس توسعه می‌آید و می‌گوید: «دوستان باید پایگاه داده را رصد کنیم، چون اتفاق بدی افتاده و لازم است در آینده این اتفاق نیفتد». و در اینجا روند جالب انتخاب یک سیستم نظارت یا تطبیق یک سیستم نظارتی موجود آغاز می شود تا بتوانید پایگاه داده خود - PostgreSQL، MySQL یا برخی دیگر را نظارت کنید. و همکاران شروع به ارائه می کنند: "شنیدم که فلان پایگاه داده وجود دارد. از آن استفاده کنیم.» همکاران شروع به مشاجره با یکدیگر می کنند. و در پایان، معلوم می شود که ما نوعی پایگاه داده را انتخاب می کنیم، اما نظارت PostgreSQL در آن نسبتا ضعیف نشان داده شده است و ما همیشه باید کاری را به پایان برسانیم. چند مخزن از GitHub بگیرید، آنها را شبیه سازی کنید، اسکریپت ها را تطبیق دهید، به نحوی آنها را تنظیم کنید. و در پایان به نوعی کار دستی می افتد.

بنابراین، در این گزارش، سعی خواهم کرد اطلاعاتی در مورد نحوه انتخاب مانیتورینگ نه تنها برای PostgreSQL، بلکه برای پایگاه داده به شما ارائه دهم. و دادن دانشی که به شما امکان می دهد نظارت خود را به پایان برسانید تا از مزایای آن بهره مند شوید، تا بتوانید پایگاه داده خود را با منفعت نظارت کنید تا از هر گونه موقعیت اضطراری آتی که ممکن است به موقع ایجاد شود جلوگیری کنید.

و ایده‌هایی که در این گزارش وجود خواهند داشت، می‌توانند مستقیماً با هر پایگاه داده، خواه DBMS یا noSQL سازگار شوند. بنابراین، نه تنها PostgreSQL در اینجا، بلکه دستور العمل های زیادی در مورد نحوه انجام این کار در PostgreSQL وجود خواهد داشت. نمونه هایی از پرس و جوها، نمونه هایی از موجودیت هایی که PostgreSQL برای نظارت دارد، وجود خواهد داشت. و اگر DBMS شما همان چیزهایی را دارد که به شما امکان می دهد آنها را در مانیتورینگ قرار دهید، می توانید آنها را نیز تطبیق دهید، اضافه کنید و خوب می شود.

من گزارش نمی دهم
در مورد نحوه تحویل و ذخیره معیارها صحبت کنید. در مورد پس از پردازش داده ها و ارائه آن به کاربر چیزی نمی گویم. و من چیزی در مورد هشدار نمی گویم.
اما در طول داستان، اسکرین شات های مختلفی از مانیتورینگ های موجود را نشان می دهم، به نوعی آنها را نقد خواهم کرد. با این وجود سعی می کنم از برندها نامی نبرم تا برای این محصولات تبلیغاتی یا ضد تبلیغاتی ایجاد نکنم. بنابراین، همه تصادفات تصادفی هستند و در تخیل شما باقی می مانند.

ابتدا بیایید بفهمیم نظارت چیست. نظارت یک چیز بسیار مهم است. همه این را می فهمند. اما در عین حال، نظارت مربوط به یک محصول تجاری نیست و مستقیماً بر سود شرکت تأثیر نمی گذارد، بنابراین نظارت همیشه به صورت باقیمانده زمان داده می شود. اگر وقت داشتیم، مشغول نظارت هستیم، اگر وقت نشد، خوب، آن را در کارنامه عقب مانده قرار می دهیم و روزی به این وظایف برمی گردیم.

بنابراین، از روی عمل ما، وقتی به مشتریان می‌رسیم، نظارت اغلب توسعه نیافته است و هیچ چیز جالبی ندارد که به ما کمک کند کار بهتری با پایگاه داده داشته باشیم. و بنابراین نظارت همیشه باید به پایان برسد.

پایگاه‌های داده چیزهای پیچیده‌ای هستند که شما نیز باید آن‌ها را رصد کنید، زیرا پایگاه‌های اطلاعاتی مخزن اطلاعات هستند. و اطلاعات برای شرکت بسیار مهم است، به هیچ وجه نمی توان آن را از دست داد. اما در عین حال پایگاه های داده نرم افزارهای بسیار پیچیده ای هستند. آنها از اجزای بسیاری تشکیل شده اند. و بسیاری از این اجزاء نیاز به نظارت دارند.

اگر به طور خاص در مورد PostgreSQL صحبت می کنیم، می توان آن را به عنوان چنین طرحی نشان داد که از تعداد زیادی مؤلفه تشکیل شده است. این اجزا با یکدیگر در تعامل هستند. و در عین حال PostgreSQL دارای زیرسیستم جمع‌آوری آمار است که به شما امکان می‌دهد آماری از عملکرد این زیرسیستم‌ها جمع‌آوری کنید و یک رابط در اختیار مدیر یا کاربر قرار دهید تا بتواند این آمار را مشاهده کند.

این آمار در قالب مجموعه ای از توابع و نماها (نما) ارائه شده است. می توان آنها را جدول نیز نامید. یعنی با استفاده از یک کلاینت معمولی psql می‌توانید به پایگاه داده متصل شوید، این توابع و نماها را انتخاب کنید و اعداد خاصی در مورد عملکرد زیرسیستم‌های PostgreSQL دریافت کنید.

می توانید این اعداد را به سیستم مانیتورینگ مورد علاقه خود اضافه کنید، نمودارها را ترسیم کنید، ویژگی ها را اضافه کنید و در دراز مدت تجزیه و تحلیل دریافت کنید.

اما در این گزارش بدون استثنا به همه این عملکردها نمی پردازم، زیرا ممکن است یک روز کامل طول بکشد. من به معنای واقعی کلمه به دو، سه یا چهار مورد اشاره خواهم کرد و به شما خواهم گفت که چگونه به بهبود نظارت کمک می کنند.

و اگر در مورد نظارت بر پایگاه داده صحبت کنیم، پس چه چیزی باید نظارت شود؟ اول از همه، ما نیاز به نظارت بر در دسترس بودن داریم، زیرا پایگاه داده سرویسی است که دسترسی به داده ها را برای مشتریان فراهم می کند و ما نیاز به نظارت بر در دسترس بودن داریم و همچنین برخی از ویژگی های کیفی و کمی آن را ارائه می دهیم.

ما همچنین باید کلاینت هایی را که به پایگاه داده ما متصل می شوند نظارت کنیم، زیرا آنها می توانند هم کلاینت های عادی و هم مشتریان مضری باشند که می توانند به پایگاه داده آسیب برسانند. آنها همچنین نیاز به نظارت و ردیابی دارند.

هنگامی که مشتریان به پایگاه داده متصل می شوند، واضح است که آنها شروع به کار با داده های ما می کنند، بنابراین ما باید نحوه کار مشتریان با داده ها را نظارت کنیم: با کدام جداول، تا حدی با کدام شاخص ها. یعنی باید حجم کاری که توسط مشتریان ما ایجاد می شود را ارزیابی کنیم.

اما حجم کار نیز البته شامل درخواست ها است. برنامه ها به پایگاه داده متصل می شوند، با استفاده از پرس و جو به داده ها دسترسی پیدا می کنند، بنابراین مهم است که بررسی کنیم چه پرس و جوهایی در پایگاه داده داریم، بر کفایت آنها نظارت کنیم، کج نباشند، برخی از گزینه ها باید بازنویسی و ساخته شوند تا سریعتر کار کنند و با عملکرد بهتر

و از آنجایی که ما در مورد پایگاه داده صحبت می کنیم، پایگاه داده همیشه فرآیندهای پس زمینه است. فرآیندهای پس‌زمینه عملکرد پایگاه داده را در سطح خوبی نگه می‌دارند، بنابراین برای اجرا به مقدار مشخصی منابع برای خود نیاز دارند. و در عین حال، آنها می توانند با منابع درخواست مشتری همپوشانی داشته باشند، بنابراین کار حریصانه فرآیندهای پس زمینه می تواند مستقیماً بر عملکرد درخواست های مشتری تأثیر بگذارد. بنابراین، آنها نیز نیاز به نظارت و ردیابی دارند تا هیچ گونه تحریفی از نظر فرآیندهای پس زمینه وجود نداشته باشد.

و این همه از نظر نظارت پایگاه داده در متریک سیستم باقی می ماند. اما با توجه به اینکه در بیشتر موارد کل زیرساخت ما به ابرها می رود، معیارهای سیستم یک میزبان فردی همیشه در پس زمینه محو می شود. اما در پایگاه های داده، آنها همچنان مرتبط هستند و البته نظارت بر معیارهای سیستم نیز ضروری است.

با معیارهای سیستم، همه چیز کم و بیش خوب است، همه سیستم های نظارتی مدرن در حال حاضر از این معیارها پشتیبانی می کنند، اما به طور کلی، برخی از مؤلفه ها هنوز کافی نیستند و برخی چیزها باید اضافه شوند. من همچنین آنها را لمس خواهم کرد، چندین اسلاید در مورد آنها خواهد بود.

اولین نکته طرح دسترسی است. دسترسی چیست؟ در دسترس بودن در درک من، توانایی پایگاه برای سرویس دهی به اتصالات است، یعنی پایه بالا می رود، به عنوان یک سرویس، اتصالات را از مشتریان می پذیرد. و این دسترسی را می توان با برخی ویژگی ها ارزیابی کرد. این ویژگی ها برای نمایش روی داشبورد بسیار راحت هستند.

همه می دانند که داشبورد چیست. این زمانی است که یک نگاه به صفحه انداختید که اطلاعات لازم را خلاصه کرد. و شما می توانید بلافاصله تعیین کنید که آیا مشکلی در پایگاه داده وجود دارد یا خیر.
بر این اساس، در دسترس بودن پایگاه داده و سایر مشخصات کلیدی باید همیشه روی داشبوردها قرار داده شود تا این اطلاعات همیشه در دسترس شما باشد. برخی از جزئیات اضافی که قبلاً به بررسی حوادث کمک می کند، در بررسی برخی موقعیت های اضطراری، باید قبلاً روی داشبوردهای ثانویه قرار داده شوند یا در پیوندهای حفاری که به سیستم های نظارت شخص ثالث منتهی می شوند پنهان شوند.

نمونه ای از یک سیستم نظارتی شناخته شده. این یک سیستم مانیتورینگ بسیار جالب است. داده های زیادی جمع آوری می کند، اما از دید من، مفهوم عجیبی از داشبورد دارد. یک پیوند "ایجاد داشبورد" وجود دارد. اما وقتی یک داشبورد ایجاد می‌کنید، یک لیست دو ستونی، فهرستی از نمودارها ایجاد می‌کنید. و هنگامی که نیاز دارید به چیزی نگاه کنید، شروع به کلیک کردن، پیمایش و جستجوی نمودار مورد نظر با ماوس می کنید. و این زمان می برد، یعنی هیچ داشبوردی وجود ندارد. فقط لیستی از نمودارها وجود دارد.

چه چیزی باید به این داشبوردها اضافه شود؟ می توانید با مشخصه ای مانند زمان پاسخ شروع کنید. PostgreSQL نمای pg_stat_statements را دارد. به طور پیش فرض غیرفعال است، اما یکی از نماهای مهم سیستمی است که همیشه باید فعال و استفاده شود. اطلاعات مربوط به تمام پرس و جوهای در حال اجرا را که در پایگاه داده اجرا شده اند ذخیره می کند.

بر این اساس، می‌توانیم از این واقعیت شروع کنیم که می‌توانیم کل زمان اجرای همه درخواست‌ها را گرفته و با استفاده از فیلدهای بالا بر تعداد درخواست‌ها تقسیم کنیم. اما این دمای متوسط ​​در بیمارستان است. ما می‌توانیم روی فیلدهای دیگر بسازیم - حداقل زمان اجرای پرس و جو، حداکثر و میانه. و حتی می توانیم صدک بسازیم، PostgreSQL توابع مربوطه را برای این کار دارد. و ما می‌توانیم اعدادی را دریافت کنیم که زمان پاسخ‌دهی پایگاه داده ما را برای درخواست‌های از قبل تکمیل‌شده مشخص می‌کنند، یعنی درخواست جعلی 'انتخاب 1' را اجرا نمی‌کنیم و زمان پاسخ را تماشا می‌کنیم، اما زمان پاسخ را برای درخواست‌های از قبل تکمیل‌شده تجزیه و تحلیل می‌کنیم و یکی را ترسیم می‌کنیم. یک شکل جداگانه، یا بر اساس آن یک نمودار می سازیم.

ردیابی تعداد خطاهایی که سیستم در حال حاضر ایجاد می کند نیز مهم است. و برای این کار می توانید از نمای pg_stat_database استفاده کنید. ما فیلد xact_rollback را هدف قرار می دهیم. این فیلد نه تنها تعداد بازگشت هایی که در پایگاه داده رخ می دهد را نشان می دهد، بلکه تعداد خطاها را نیز در نظر می گیرد. به طور نسبی، می توانیم این رقم را در داشبورد خود نمایش دهیم و ببینیم در حال حاضر چه تعداد خطا داریم. اگر خطاهای زیادی وجود دارد، پس این دلیل خوبی برای بررسی گزارش‌ها و بررسی نوع خطاها و دلیل رخ دادن آن‌ها است، و سپس سرمایه‌گذاری و حل‌شان می‌شود.

می توانید چیزی به عنوان سرعت سنج اضافه کنید. اینها تعداد تراکنش در ثانیه و تعداد درخواست در ثانیه است. به طور نسبی، می توانید از این اعداد به عنوان عملکرد فعلی پایگاه داده خود استفاده کنید و مشاهده کنید که آیا اوج در درخواست ها، اوج در تراکنش ها وجود دارد یا برعکس، پایگاه داده زیر بارگذاری شده است زیرا نوعی backend از کار افتاده است. مهم است که همیشه به این رقم نگاه کنید و به یاد داشته باشید که برای پروژه ما چنین عملکردی طبیعی است و مقادیر بالا و پایین قبلاً به نوعی مشکل ساز و غیرقابل درک هستند، به این معنی که ما باید به این نگاه کنیم که چرا چنین اعدادی وجود دارد. .

برای تخمین تعداد تراکنش ها می توان دوباره به نمای pg_stat_database مراجعه کرد. می‌توانیم تعداد commit‌ها و تعداد بازگشت‌ها را اضافه کنیم تا تعداد تراکنش‌ها در هر ثانیه به دست آید.

همه می دانند که چندین درخواست می توانند در یک تراکنش قرار بگیرند؟ بنابراین TPS و QPS کمی متفاوت هستند.

تعداد درخواست ها در ثانیه را می توان از pg_stat_statements به دست آورد و به سادگی مجموع تمام درخواست های اجرا شده را محاسبه کرد. واضح است که مقدار فعلی را با مقدار قبلی مقایسه می کنیم، کم می کنیم، دلتا را می گیریم، مقدار را می گیریم.

در صورت تمایل می‌توانید معیارهای دیگری را اضافه کنید، که به ارزیابی در دسترس بودن پایگاه داده ما و ردیابی در صورت خرابی کمک می‌کند.

یکی از این معیارها زمان کار است. اما uptime در PostgreSQL کمی مشکل است. من به شما می گویم چرا. هنگامی که PostgreSQL راه اندازی می شود، شروع به گزارش زمان آپدیت می کند. اما اگر در نقطه‌ای، برای مثال، فلان کار در شب اجرا می‌شد، یک OOM-killer آمد و به زور فرآیند فرزند PostgreSQL را خاتمه داد، در این حالت PostgreSQL اتصال همه کلاینت‌ها را قطع می‌کند، ناحیه حافظه خرد شده را بازنشانی می‌کند و بازیابی را شروع می‌کند. آخرین ایست بازرسی و در حالی که این بازیابی از چک پوینت طول می کشد، پایگاه داده اتصالات را نمی پذیرد، یعنی این وضعیت را می توان به عنوان خرابی ارزیابی کرد. اما این کار شمارشگر آپتایم را بازنشانی نمی کند، زیرا زمانی را در نظر می گیرد که مدیر پست از همان لحظه اول شروع به کار کرده است. بنابراین می توان از چنین موقعیت هایی چشم پوشی کرد.

همچنین باید بر تعداد کارگران جاروبرقی نظارت داشته باشید. همه می دانند که autovacuum در PostgreSQL چیست؟ این یک زیرسیستم جالب در PostgreSQL است. مقالات زیادی در مورد آن نوشته شده است، گزارش های زیادی ارائه شده است. بحث های زیادی در مورد خلاء، نحوه کارکرد آن. بسیاری آن را شر ضروری می دانند. اما آن است. این نوعی جمع‌آوری زباله است که نسخه‌های منسوخ ردیف‌هایی را که مورد نیاز هیچ یک از تراکنش‌ها نیست پاک می‌کند و فضایی را در جداول و فهرست‌ها برای ردیف‌های جدید آزاد می‌کند.

چرا باید نظارت شود؟ چون جاروبرقی گاهی به شدت درد دارد. این مقدار زیادی از منابع را مصرف می کند و درخواست های مشتری از این رنج می برند.

و باید از طریق نمای pg_stat_activity نظارت شود که در قسمت بعدی در مورد آن صحبت خواهم کرد. این نمای فعالیت فعلی در پایگاه داده را نشان می دهد. و از طریق این فعالیت، می توانیم تعداد جاروهایی را که در حال حاضر کار می کنند، ردیابی کنیم. ما می‌توانیم خلاءها را نظارت کنیم و ببینیم که اگر از حد مجاز فراتر رفته‌ایم، این فرصتی است که به تنظیمات PostgreSQL نگاه کنیم و به نوعی عملکرد خلاء را بهینه کنیم.

یکی دیگر از ویژگی های PostgreSQL این است که PostgreSQL از تراکنش های طولانی بسیار خسته است. به خصوص، از معاملاتی که برای مدت طولانی معلق هستند و هیچ کاری انجام نمی دهند. اینها به اصطلاح stat idle-in-transaction هستند. چنین معامله ای قفل ها را نگه می دارد، از کارکرد خلاء جلوگیری می کند. و در نتیجه - جداول متورم می شوند، اندازه آنها افزایش می یابد. و پرس و جوهایی که با این جداول کار می کنند، آهسته تر شروع به کار می کنند، زیرا شما باید تمام نسخه های قدیمی ردیف ها را از حافظه به دیسک و برگردانید. بنابراین، زمان، مدت طولانی ترین تراکنش ها، طولانی ترین درخواست های خلاء نیز نیاز به نظارت دارند. و اگر برخی از فرآیندها را می بینیم که برای مدت زمان بسیار طولانی، بیش از 10-20-30 دقیقه برای بارگذاری OLTP در حال اجرا هستند، باید به آنها توجه کنیم و آنها را مجبور به پایان یابند یا برنامه را بهینه کنیم تا آنها نامیده نمی شوند و برای مدت طولانی آویزان نمی شوند. برای یک بار تحلیلی، 10-20-30 دقیقه طبیعی است، همچنین موارد طولانی تر نیز وجود دارد.

در مرحله بعد ما گزینه ای با مشتریان متصل داریم. هنگامی که قبلاً داشبوردی تشکیل داده‌ایم، معیارهای دسترسی کلیدی را روی آن ارسال کرده‌ایم، می‌توانیم اطلاعات اضافی درباره مشتریان متصل را نیز در آنجا اضافه کنیم.

اطلاعات مربوط به مشتریان متصل مهم است زیرا از دیدگاه PostgreSQL انواع مختلفی از کلاینت ها وجود دارد. مشتریان خوب هستند و مشتریان بد.

یک مثال ساده منظورم از کلاینت اپلیکیشن است. اپلیکیشن به پایگاه داده متصل شده و بلافاصله درخواست های خود را در آنجا ارسال می کند، پایگاه داده آنها را پردازش و اجرا می کند و نتایج را به مشتری برمی گرداند. اینها مشتریان خوب و درستی هستند.

شرایطی وجود دارد که مشتری متصل است، اتصال را حفظ می کند، اما کاری انجام نمی دهد. در حالت بیکار است.

اما مشتریان بدی وجود دارند. به عنوان مثال، همان کلاینت متصل شد، تراکنش را باز کرد، کاری در پایگاه داده انجام داد و سپس وارد کد شد، مثلاً برای دسترسی به یک منبع خارجی یا پردازش داده های دریافتی در آنجا. اما در عین حال معامله را نبست. و تراکنش در پایگاه داده آویزان می شود و قفل را روی خط نگه می دارد. این وضعیت بدی است. و اگر به طور ناگهانی برنامه در جایی در داخل آن با یک استثنا (Exception) سقوط کند، تراکنش می تواند برای مدت طولانی باز بماند. و این به طور مستقیم بر عملکرد PostgreSQL تأثیر می گذارد. PostgreSQL کندتر اجرا خواهد شد. بنابراین، پیگیری به موقع چنین مشتریانی و خاتمه اجباری کار آنها بسیار مهم است. و باید اپلیکیشن خود را طوری بهینه کنید که چنین شرایطی وجود نداشته باشد.

سایر مشتریان بد مشتریان منتظر هستند. اما به دلیل شرایط بد می شوند. به عنوان مثال، یک تراکنش غیرفعال ساده: می تواند یک تراکنش را باز کند، روی برخی از خطوط قفل کند، سپس در جایی از کد می افتد و یک تراکنش معلق باقی می گذارد. مشتری دیگری می آید، همان داده ها را درخواست می کند، اما با یک قفل مواجه می شود، زیرا آن تراکنش معلق از قبل قفل هایی را در برخی از ردیف های ضروری نگه می دارد. و تراکنش دوم در انتظار زمانی که تراکنش اول تکمیل شود یا مدیر آن به اجبار آن را ببندد معلق خواهد ماند. بنابراین، تراکنش‌های معلق می‌توانند محدودیت اتصال پایگاه داده را انباشته و سرریز کنند. و وقتی محدودیت کامل شد، برنامه دیگر نمی تواند با پایگاه داده کار کند. این در حال حاضر یک وضعیت اضطراری برای پروژه است. بنابراین، مشتریان بد باید ردیابی شوند و به موقع به آنها پاسخ داده شود.

نمونه دیگری از نظارت و اینجا یک داشبورد مناسب است. اطلاعاتی در مورد اتصالات از بالا وجود دارد. اتصال DB - 8 قطعه. و این همه است. ما هیچ اطلاعاتی در مورد اینکه کدام کلاینت ها فعال هستند، کدام کلاینت ها بیکار هستند و هیچ کاری انجام نمی دهند، نداریم. هیچ اطلاعاتی در مورد معاملات معلق و اتصالات معلق وجود ندارد، یعنی این رقمی است که تعداد اتصالات را نشان می دهد و تمام. و بعد خودت حدس بزن

بر این اساس، برای افزودن این اطلاعات به مانیتورینگ، باید به نمای سیستم pg_stat_activity مراجعه کنید. اگر زمان زیادی را در PostgreSQL می گذرانید، پس این نمای بسیار خوبی است که باید دوست شما شود، زیرا فعالیت فعلی PostgreSQL را نشان می دهد، یعنی آنچه در آن اتفاق می افتد. برای هر فرآیند یک خط جداگانه وجود دارد که اطلاعات مربوط به این فرآیند را نشان می دهد: اتصال از کدام میزبان، تحت چه کاربری، با چه نامی، زمانی که تراکنش شروع شده است، چه درخواستی در حال حاضر اجرا می شود، آخرین درخواستی که اجرا شده است. و بر این اساس، می توانیم وضعیت مشتری را با فیلد stat ارزیابی کنیم. به طور نسبی، می‌توانیم بر اساس این فیلد گروه‌بندی کنیم و آمارهایی را که اکنون در پایگاه داده هستند و تعداد اتصالاتی که با این آمار در پایگاه داده هستند را بدست آوریم. و ما می توانیم اعداد دریافتی را به مانیتورینگ خود بفرستیم و نمودارهایی را روی آنها ترسیم کنیم.
همچنین ارزیابی مدت معامله مهم است. قبلاً گفته ام که ارزیابی مدت خلاء مهم است، اما تراکنش ها نیز به همین ترتیب ارزیابی می شوند. فیلدهای xact_start و query_start وجود دارد. آنها، به طور نسبی، زمان شروع معامله و زمان شروع درخواست را نشان می دهند. تابع now() را می گیریم که مهر زمانی فعلی را نشان می دهد و تراکنش را کم می کنیم و مهر زمانی درخواست می کنیم. و ما مدت زمان معامله، مدت زمان درخواست را دریافت می کنیم.

اگر تراکنش های طولانی می بینیم، باید آنها را از قبل تکمیل کنیم. برای بار OLTP، تراکنش های طولانی در حال حاضر بیش از 1-2-3 دقیقه است. برای بار OLAP، تراکنش‌های طولانی طبیعی هستند، اما اگر بیش از دو ساعت اجرا شوند، این نیز نشانه‌ای است که در جایی دچار انحراف هستیم.

هنگامی که مشتریان به پایگاه داده متصل شدند، شروع به کار با داده های ما می کنند. آنها به جداول دسترسی دارند، آنها برای دریافت داده ها از یک جدول به فهرست ها دسترسی دارند. و ارزیابی نحوه کار مشتریان با این داده ها بسیار مهم است.

این برای ارزیابی حجم کاری ما و تقریباً درک اینکه کدام جداول "گرمترین" را داریم، ضروری است. به عنوان مثال، این در شرایطی ضروری است که می‌خواهیم جداول «داغ» را روی نوعی حافظه SSD سریع قرار دهیم. به عنوان مثال، برخی از جداول بایگانی را که مدت زیادی از آنها استفاده نکرده ایم، می توان به نوعی آرشیو "سرد"، به دیسک های SATA منتقل کرد و اجازه داد در آنجا زندگی کنند، در صورت نیاز به آنها دسترسی پیدا می شود.

همچنین برای تشخیص ناهنجاری ها پس از انتشار و استقرار مفید است. بیایید بگوییم که این پروژه ویژگی جدیدی را ارائه کرده است. به عنوان مثال، ما عملکرد جدیدی را برای کار با پایگاه داده اضافه کردیم. و اگر نمودارهایی را برای استفاده از جداول بسازیم، به راحتی می توانیم این ناهنجاری ها را در این نمودارها تشخیص دهیم. به عنوان مثال، انفجارها را به روز کنید یا انفجارها را حذف کنید. بسیار قابل مشاهده خواهد بود.

همچنین امکان تشخیص ناهنجاری های آمارهای «شناور» وجود دارد. چه مفهومی داره؟ PostgreSQL یک برنامه ریز پرس و جو بسیار قوی و بسیار خوب دارد. و توسعه دهندگان زمان زیادی را به توسعه آن اختصاص می دهند. او چگونه کار می کند؟ به منظور ایجاد برنامه های خوب، PostgreSQL آماری را در مورد توزیع داده ها در جداول با بازه زمانی معین و با مقداری تناوب جمع آوری می کند. اینها متداول ترین مقادیر هستند: تعداد مقادیر منحصر به فرد، اطلاعات مربوط به NULL در جدول، اطلاعات زیادی.

بر اساس این آمار، برنامه ریز چندین پرس و جو می سازد، بهینه ترین را انتخاب می کند و از این طرح پرس و جو برای اجرای خود پرس و جو و برگرداندن داده ها استفاده می کند.

و این اتفاق می افتد که آمار "شناور" است. داده های کمی و کیفی به نحوی در جدول تغییر کرد، اما آمار جمع آوری نشد. و برنامه های شکل گرفته ممکن است بهینه نباشد. و اگر برنامه های ما از نظر نظارت های جمع آوری شده کمتر از حد مطلوب باشد، طبق جداول، شاهد این ناهنجاری ها خواهیم بود. به عنوان مثال، در جایی داده ها از نظر کیفی تغییر کردند و به جای شاخص، از یک گذر متوالی از جدول استفاده شد، یعنی. اگر پرس و جو نیاز به بازگشت تنها 100 سطر داشته باشد (محدودیت 100 وجود دارد)، آنگاه یک شمارش کامل برای این پرس و جو انجام می شود. و این همیشه تأثیر بسیار بدی بر عملکرد دارد.

و ما می توانیم آن را در نظارت مشاهده کنیم. و از قبل به این پرس و جو نگاه کنید، برای آن توضیح دهید، آمار جمع آوری کنید، یک نمایه اضافی جدید بسازید. و در حال حاضر به این مشکل پاسخ داده است. بنابراین مهم است.

نمونه دیگری از نظارت فکر می کنم خیلی ها او را می شناسند چون بسیار محبوب است. کسانی که در پروژه های خود استفاده می کنند تیتان فرزند پاپتوس? و چه کسی از این محصول در ارتباط با پرومتئوس استفاده می کند؟ واقعیت این است که در مخزن استاندارد این نظارت یک داشبورد برای کار با PostgreSQL وجود دارد - postgres_exporter پرومتئوس اما یک جزئیات بد در اینجا وجود دارد.

چندین نمودار وجود دارد. و بایت ها به عنوان وحدت مشخص می شوند، یعنی 5 نمودار وجود دارد. اینها عبارتند از درج داده، به روز رسانی داده، حذف داده، واکشی داده و داده برگردان. بایت ها به عنوان بعد واحد مشخص می شوند. اما واقعیت این است که آمار در PostgreSQL داده ها را به صورت چند تایی (ردیف) برمی گرداند. و بر این اساس، این نمودارها راه بسیار خوبی برای دست کم گرفتن حجم کار شما چندین بار، ده ها بار است، زیرا یک تاپل یک بایت نیست، یک تاپل یک رشته است، تعداد زیادی بایت دارد و همیشه دارای طول متغیر است. یعنی محاسبه حجم کار بر حسب بایت با استفاده از تاپل ها یک کار غیر واقعی یا بسیار دشوار است. بنابراین، هنگامی که از داشبورد یا مانیتورینگ داخلی استفاده می‌کنید، همیشه مهم است که بدانید درست کار می‌کند و داده‌های ارزیابی شده را به درستی به شما برمی‌گرداند.

چگونه می توان آمار این جداول را بدست آورد؟ برای انجام این کار، PostgreSQL یک خانواده از view ها دارد. و نمای اصلی این است pg_stat_user_tables. User_tables - به این معنی است که جداول از طرف کاربر ایجاد می شوند. در مقابل، نماهای سیستمی وجود دارد که توسط خود PostgreSQL استفاده می شود. و یک جدول خلاصه Alltables وجود دارد که شامل سیستم و کاربر است. می توانید از هر کدام از آنها که بیشتر دوست دارید شروع کنید.

از فیلدهای بالا می توان برای تخمین تعداد درج ها، به روز رسانی ها و حذف ها استفاده کرد. داشبورد نمونه ای که من استفاده کردم از این فیلدها برای ارزیابی ویژگی های حجم کار استفاده می کند. بنابراین، ما نیز می توانیم بر روی آنها بسازیم. اما شایان ذکر است که اینها تاپل هستند، نه بایت، بنابراین ما نمی توانیم آن را بگیریم و آن را بایت کنیم.

بر اساس این داده ها، می توانیم به اصطلاح جدول های 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 ارزیابی کنیم.

می‌توانیم سنگین‌ترین درخواست‌ها را از نظر مصرف منابع ارزیابی و نظارت کنیم، درخواست‌هایی که از دیسک می‌خوانند، آن‌هایی که با حافظه کار می‌کنند، یا برعکس، نوعی بار نوشتن ایجاد می‌کنند.

ما می توانیم سخاوتمندانه ترین درخواست ها را ارزیابی کنیم. اینها کوئری هایی هستند که تعداد زیادی ردیف را برمی گرداند. به عنوان مثال، ممکن است نوعی درخواست باشد که در آن فراموش کرده اند محدودیتی را تعیین کنند. و فقط کل محتوای جدول یا پرس و جو را در جداول درخواستی برمی گرداند.

و همچنین می توانید پرس و جوهایی را که از فایل های موقت یا جداول موقت استفاده می کنند نظارت کنید.

و ما هنوز فرآیندهای پس زمینه را داریم. فرآیندهای پس‌زمینه در درجه اول نقاط بازرسی هستند یا به آنها پست‌های بازرسی نیز گفته می‌شود، اینها autovacuum و replication هستند.

نمونه دیگری از نظارت یک برگه Maintenance در سمت چپ وجود دارد، به آن بروید و امیدوار باشید که چیز مفیدی ببینید. اما اینجا فقط زمان خلاء و جمع آوری آمار نه چیز دیگر. این اطلاعات بسیار ضعیف است، بنابراین شما همیشه باید اطلاعاتی در مورد نحوه عملکرد فرآیندهای پس‌زمینه در پایگاه داده ما و اینکه آیا مشکلی در کار آنها وجود دارد، داشته باشید.

وقتی به نقاط بازرسی نگاه می کنیم، باید به خاطر داشت که ایست های بازرسی ما صفحات "کثیف" را از ناحیه حافظه خرد شده به دیسک می ریزند، سپس یک ایست بازرسی ایجاد می کنند. و اگر PostgreSQL به طور ناگهانی در مواقع اضطراری خاتمه داده شود، می‌توان از این پست بازرسی در حین بازیابی به عنوان مکانی استفاده کرد.

بر این اساس، برای شستشوی تمام صفحات "کثیف" روی دیسک، باید مقدار مشخصی رایتینگ انجام دهید. و، به عنوان یک قاعده، در سیستم هایی با مقدار زیادی حافظه، این مقدار زیادی است. و اگر پست های بازرسی را اغلب در فاصله زمانی کوتاه ایجاد کنیم، عملکرد دیسک بسیار کاهش می یابد. و درخواست های مشتری از کمبود منابع رنج خواهند برد. آنها برای منابع رقابت خواهند کرد و بهره وری ندارند.

بر این اساس، از طریق pg_stat_bgwriter در فیلدهای مشخص شده، می‌توانیم تعداد چک پوینت‌هایی را که پیش می‌آیند نظارت کنیم. و اگر برای مدت معینی (برای 10-15-20 دقیقه، به مدت نیم ساعت)، پست های بازرسی زیادی داشته باشیم، به عنوان مثال، 3-4-5، آنگاه این می تواند مشکل ساز باشد. و شما در حال حاضر باید در پایگاه داده نگاه کنید، به پیکربندی نگاه کنید، چه چیزی باعث چنین فراوانی نقاط بازرسی می شود. شاید یک رکورد بزرگ در راه است. ما قبلاً می توانیم حجم کار را ارزیابی کنیم، زیرا قبلاً نمودارهای حجم کار را اضافه کرده ایم. ما از قبل می‌توانیم پارامترهای نقطه شکست را تغییر دهیم و مطمئن شویم که تأثیر زیادی روی عملکرد پرس‌وجو ندارند.

من دوباره به autovacuum برمی گردم زیرا همانطور که گفتم این چیزی است که به راحتی می تواند عملکرد دیسک و پرس و جو را افزایش دهد، بنابراین اندازه گیری مقدار autovacuum همیشه مهم است.

تعداد کارگران autovacuum در پایگاه داده محدود است. به طور پیش‌فرض، سه مورد از آنها وجود دارد، بنابراین اگر سه کارگر همیشه در پایگاه داده کار می‌کنند، به این معنی است که autovacuum ما پیکربندی نشده است، باید محدودیت‌ها را افزایش دهیم، تنظیمات autovacuum را اصلاح کنیم و از قبل به پیکربندی برویم.
این مهم است که ارزیابی کنیم که کدام کارگران وکیوم برای ما کار می کنند. یا از کاربر راه اندازی می شد، DBA وارد شد و با دستان خود نوعی خلاء راه اندازی کرد و این یک بار ایجاد کرد. یه مشکلی داریم یا این تعداد جاروهایی است که پیچ شمارنده تراکنش را باز می کند. برای برخی از نسخه های PostgreSQL، اینها خلاءهای بسیار سنگینی هستند. و آنها به راحتی می توانند عملکرد را اضافه کنند زیرا کل جدول را کم می کنند و تمام بلوک های این جدول را اسکن می کنند.

و البته مدت زمان جاروبرقی. اگر جاروهای طولانی داریم که برای مدت زمان طولانی کار می کنند، پس این بدان معناست که باید دوباره به پیکربندی جاروبرقی توجه کنیم و شاید تنظیمات آن را تجدید نظر کنیم. زیرا ممکن است شرایطی پیش بیاید که جاروبرقی برای مدت طولانی (3-4 ساعت) روی میز کار کند، اما در حین کار خلاء، دوباره مقدار زیادی از ردیف های مرده در جدول جمع می شود. و به محض اینکه خلاء تمام شد، باید دوباره این میز را جاروبرقی بکشد. و به موقعیتی می رسیم - خلاء بی نهایت. و در این حالت ، خلاء با کار خود مقابله نمی کند و جداول به تدریج شروع به بزرگ شدن می کنند ، اگرچه مقدار داده های مفید موجود در آن ثابت می ماند. بنابراین، در خلاهای طولانی، ما همیشه به پیکربندی نگاه می کنیم و سعی می کنیم آن را بهینه کنیم، اما در عین حال، به گونه ای که عملکرد درخواست های مشتری آسیب نبیند.

اکنون عملاً هیچ نصب PostgreSQL وجود ندارد که در آن هیچ تکرار جریانی وجود نداشته باشد. Replication فرآیند انتقال داده از Master به Replica است.

تکرار در PostgreSQL از طریق یک گزارش تراکنش مرتب می شود. Master یک گزارش تراکنش ایجاد می کند. گزارش تراکنش در اتصال شبکه به ماکت می رود، سپس روی ماکت تولید می شود. همه چیز ساده است.

بر این اساس، نمای pg_stat_replication برای نظارت بر تاخیر تکرار استفاده می شود. اما برای او آسان نیست. در نسخه 10، نما دستخوش تغییرات متعددی شده است. ابتدا برخی از فیلدها تغییر نام داده اند. و برخی از فیلدها اضافه شده است. در نسخه 10، فیلدهایی ظاهر شد که به شما امکان می دهد تاخیر تکرار را در چند ثانیه ارزیابی کنید. خیلی راحت است. قبل از نسخه 10، تخمین تاخیر تکرار بر حسب بایت امکان پذیر بود. این ویژگی در نسخه 10 باقی مانده است، یعنی می توانید آنچه را که برای شما راحت تر است انتخاب کنید - تاخیر را در بایت ارزیابی کنید یا تاخیر را در چند ثانیه ارزیابی کنید. خیلی ها هر دو را انجام می دهند.

با این حال، برای ارزیابی تاخیر تکرار، باید موقعیت لاگ در تراکنش را بدانید. و این موقعیت های گزارش تراکنش فقط در نمای pg_stat_replication هستند. به طور نسبی، می توانیم از تابع ()pg_xlog_location_diff برای گرفتن دو نقطه در گزارش تراکنش استفاده کنیم. دلتای بین آنها را محاسبه کنید و تاخیر تکرار را بر حسب بایت دریافت کنید. بسیار راحت و ساده است.

در نسخه 10 این تابع به pg_wal_lsn_diff تغییر نام داد. به طور کلی در تمام توابع، نماها، ابزارهای کاربردی که با کلمه xlog مواجه می شد، مقدار wal جایگزین آن می شد. این هم در نماها و هم در توابع است. این چنین نوآوری است.

به علاوه، در نسخه 10، خطوطی اضافه شد که به طور خاص تاخیر را نشان می دهد. اینها تأخیر نوشتن، تأخیر فلاش، تأخیر پخش مجدد هستند. یعنی نظارت بر این موارد مهم است. اگر دیدیم که تاخیر تکرار داریم، باید بررسی کنیم که چرا ظاهر شد، از کجا آمده و مشکل را برطرف کنیم.

با معیارهای سیستم، تقریباً همه چیز مرتب است. هنگامی که هر نظارتی متولد می شود، با معیارهای سیستم شروع می شود. این استفاده از پردازنده، حافظه، مبادله، شبکه و دیسک است. اما با این وجود، بسیاری از پارامترها به طور پیش فرض وجود ندارند.

اگر همه چیز با دفع فرآیند درست باشد، در دفع دیسک مشکلاتی وجود دارد. به عنوان یک قاعده، توسعه دهندگان مانیتورینگ اطلاعات پهنای باند را اضافه می کنند. می تواند به صورت iop یا بایت باشد. اما آنها تأخیر و استفاده از دستگاه دیسک را فراموش می کنند. اینها پارامترهای مهمتری هستند که به ما امکان می دهند میزان بارگذاری دیسک های ما و میزان کاهش سرعت آنها را ارزیابی کنیم. اگر تاخیر بالایی داشته باشیم، به این معنی است که دیسک ها مشکلاتی دارند. اگر استفاده بالایی داشته باشیم، این بدان معناست که دیسک ها نمی توانند با آن مقابله کنند. اینها ویژگی های کیفی بیشتری نسبت به پهنای باند دارند.

با این حال، این آمار را می توان از سیستم فایل /proc نیز به دست آورد، همانطور که برای بازیافت پردازنده انجام می شود. چرا این اطلاعات به نظارت اضافه نمی شود، نمی دانم. اما همچنان مهم است که آن را در نظارت خود داشته باشید.

همین امر در مورد رابط های شبکه نیز صادق است. اطلاعاتی در مورد پهنای باند شبکه در بسته ها، بر حسب بایت وجود دارد، اما با این وجود هیچ اطلاعاتی در مورد تأخیر و هیچ اطلاعاتی در مورد استفاده وجود ندارد، اگرچه این نیز اطلاعات مفیدی است.

هر نظارتی معایبی دارد. و مهم نیست که چه نوع نظارتی انجام می دهید، همیشه معیارهای خاصی را برآورده نمی کند. اما با این وجود، آنها توسعه می یابند، ویژگی های جدید اضافه می شوند، چیزهای جدید، بنابراین چیزی را انتخاب کنید و آن را تمام کنید.

و برای به پایان رساندن، همیشه باید ایده ای داشته باشید که آمار داده شده به چه معناست و چگونه می توانید مشکلات را با آن حل کنید.

و چند نکته کلیدی:

• شما همیشه باید در دسترس بودن را کنترل کنید، داشبوردهایی داشته باشید تا بتوانید به سرعت ارزیابی کنید که همه چیز با پایه درست است.
• شما همیشه باید ایده ای از مشتریانی که با پایگاه داده شما کار می کنند داشته باشید تا مشتریان بد را از بین ببرید و آنها را شلیک کنید.
• ارزیابی نحوه کار این مشتریان با داده ها بسیار مهم است. شما باید در مورد حجم کاری خود ایده ای داشته باشید.
• ارزیابی چگونگی شکل‌گیری این حجم کار با کمک چه پرسش‌هایی مهم است. شما می توانید پرس و جوها را ارزیابی کنید، می توانید آنها را بهینه کنید، آنها را اصلاح کنید، برای آنها ایندکس بسازید. این خیلی مهمه.
• فرآیندهای پس‌زمینه می‌توانند بر درخواست‌های مشتری تأثیر منفی بگذارند، بنابراین مهم است که مطمئن شوید آنها از منابع زیادی استفاده نمی‌کنند.
• معیارهای سیستم به شما این امکان را می دهد که برای مقیاس گذاری، برای افزایش ظرفیت سرورهای خود برنامه ریزی کنید، بنابراین پیگیری و ارزیابی آنها نیز بسیار مهم است.

اگر به این موضوع علاقه دارید، می توانید این لینک ها را دنبال کنید.
http://bit.do/stats_collector مستندات رسمی جمع آوری کننده آمار است. شرح تمامی نماهای آماری و شرح تمامی فیلدها وجود دارد. می توانید آنها را بخوانید، درک کنید و تجزیه و تحلیل کنید. و بر اساس آنها، نمودارهای خود را بسازید، به نظارت خود اضافه کنید.

درخواست نمونه:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

این مخزن شرکتی ما و متعلق به من است. آنها درخواست های نمونه دارند. هیچ درخواستی از مجموعه انتخاب* از سری وجود ندارد، چیزی در آنجا وجود دارد. در حال حاضر درخواست های آماده با اتصال وجود دارد، با استفاده از توابع جالب که به شما امکان می دهد مقادیر قابل خواندن و راحت را از اعداد خام بسازید، یعنی اینها بایت، زمان هستند. شما می توانید آنها را انتخاب کنید، تماشا کنید، آنها را تجزیه و تحلیل کنید، آنها را به نظارت های خود اضافه کنید، نظارت های خود را بر اساس آنها بسازید.

پرسش

سوال: شما گفتید که برندها را تبلیغ نمی کنید، اما من هنوز در این فکر هستم که از چه نوع داشبوردهایی در پروژه های خود استفاده می کنید؟
پاسخ: به طرق مختلف. این اتفاق می افتد که ما به مشتری مراجعه می کنیم و او قبلاً نظارت خود را دارد. و به مشتری توصیه می کنیم که چه چیزی باید به نظارت او اضافه شود. بدترین وضعیت مربوط به Zabbix است. چون قابلیت ساخت TopN-graphics را ندارد. ما خودمان استفاده می کنیم اوک مترزیرا ما در مورد نظارت با این افراد مشورت کردیم. آنها نظارت PostgreSQL را بر اساس TOR ما انجام دادند. من در حال نوشتن پروژه حیوان خانگی خود هستم که داده ها را از طریق Prometheus جمع آوری می کند و آن ها را وارد می کند گرافانا. وظیفه من این است که صادرکننده خودم را در Prometheus بسازم و سپس همه چیز را در Grafana بکشم.

سوال: آیا هیچ گونه مشابهی از گزارش های AWR یا ... وجود دارد؟ آیا از چنین چیزی مطلع هستید؟
پاسخ: بله، من می دانم AWR چیست، چیز جالبی است. در حال حاضر دوچرخه های مختلفی وجود دارد که تقریباً مدل زیر را اجرا می کنند. در یک بازه زمانی، برخی از خطوط پایه در همان PostgreSQL یا در یک فضای ذخیره‌سازی جداگانه نوشته می‌شوند. می توانید آنها را در اینترنت در گوگل جستجو کنید، آنها هستند. یکی از توسعه دهندگان چنین چیزی در انجمن sql.ru در موضوع PostgreSQL نشسته است. میتونی اونجا بگیریش بله، چنین چیزهایی وجود دارد، می توان از آنها استفاده کرد. به علاوه در آن pgCenter من همچنین چیزی می نویسم که به شما امکان می دهد همین کار را انجام دهید.

PS1 اگر از postgres_exporter استفاده می کنید، از چه داشبوردی استفاده می کنید؟ چندین مورد از آنها وجود دارد. آنها قبلاً منسوخ شده اند. آیا انجمن می تواند یک الگوی به روز ایجاد کند؟

PS2 حذف شد pganalyze زیرا یک پیشنهاد SaaS اختصاصی است که بر نظارت بر عملکرد و پیشنهادات تنظیم خودکار تمرکز دارد.

فقط کاربران ثبت نام شده می توانند در نظرسنجی شرکت کنند. ورود، لطفا.

به نظر شما کدام مانیتورینگ postgresql خود میزبان (با داشبورد) بهترین است؟

• ٪۱۰۰Zabbix + اضافه شده از Alexey Lesovsky یا zabbix 4.4 یا libzbxpgsql + zabbix libzbxpgsql + zabbix3

• ٪۱۰۰https://github.com/lesovsky/pgcenter0

• ٪۱۰۰https://github.com/pg-monz/pg_monz0

• ٪۱۰۰https://github.com/cybertec-postgresql/pgwatch22

• ٪۱۰۰https://github.com/postgrespro/mamonsu2

• ٪۱۰۰https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0

• ٪۱۰۰pganalyze یک SaaS اختصاصی است - نمی توان آن را حذف کرد

• ٪۱۰۰https://github.com/powa-team/powa1

• ٪۱۰۰https://github.com/darold/pgbadger0

• ٪۱۰۰https://github.com/darold/pgcluu0

• ٪۱۰۰https://github.com/zalando/PGObserver0

• ٪۱۰۰https://github.com/spotify/postgresql-metrics1

10 کاربر رای دادند. 26 کاربر رای ممتنع دادند.

منبع: www.habr.com