Alexey Lesovsky from Data Egret presents an overview of the report "Fundamentals of PostgreSQL Monitoring".
In this report, Alexey Lesovsky will discuss key moments of PostgreSQL statistics, what they mean, and why they should be included in monitoring; which graphs should be in monitoring, how to add them, and how to interpret them. The report will be useful for database administrators, system administrators, and developers interested in troubleshooting Postgres.
My name is Alexey Lesovsky, and I represent Data Egret.
A few words about myself. I started a long time ago as a system administrator.
I administered various Linux systems and worked on various Linux-related tasks, such as virtualization, monitoring, proxy work, etc. But at some point, I began focusing more on databases, especially PostgreSQL. I liked it a lot. Eventually, I started to spend most of my working hours on PostgreSQL, and gradually I became a PostgreSQL DBA.
Throughout my career, I've always been interested in topics like statistics, monitoring, and telemetry collection. When I was a system administrator, I was heavily involved with Zabbix. I even wrote a small set of scripts called It was quite popular at the time. It allowed monitoring many important things, not just Linux but also various components.
Now I am focused on PostgreSQL. I am working on a different tool that allows working with PostgreSQL statistics. It's called (article on Habr — ).
A brief introduction. What situations do our clients face? An incident occurs related to the database. Once the database is restored, the department head or project manager says: "Friends, we need to monitor the database because something bad happened, and we need to prevent this from happening in the future." This initiates an interesting process of choosing a monitoring system or adapting an existing one to monitor their database — whether it's PostgreSQL, MySQL, or others. Colleagues start suggesting: "I've heard there's such a database. Let's use it." They argue, and in the end, we choose a particular database; however, monitoring PostgreSQL within it is often poorly supported, leading to the need for modifications. We have to take some repositories from GitHub, clone them, adapt the scripts, and do some fine-tuning. Ultimately, it turns into manual work.
Bu səbəbdən bu hesabatda PostgreSQL və digər verilənlər bazaları üçün monitorinq seçiminə dair biliklər təqdim etməyə çalışacağam. Monitorinqinizi inkişaf etdirmək üçün sizə biliklər vermək və verilənlər bazanızı faydalı şəkildə monitorinq etmək, qarşıdan gələn fövqəladə halları vaxtında xəbərdar etmək üçün məlumat verməyə çalışacağam.
Hesabatdakı ideyaları istənilən verilənlər bazasına, istər SQL, istərsə də noSQL olsun, birbaşa uyğunlaşdırmaq mümkündür. Buna görə burada yalnız PostgreSQL deyil, həm də PostgreSQL-də bunu necə etmək üçün bir çox reseptlər olacaq. Monitorinq üçün PostgreSQL-də mövcud olan sorğu nümunələri, varlıq nümunələri olacaq. Və əgər sizin verilənlər bazanız da monitorinq üçün bu cür imkanlara malikdirsə, siz də onları uyğunlaşdırıb əlavə edə bilərsiniz və bu yaxşı olacaq.
Hesabatda
metriklərin götürülməsi və saxlanılması haqqında danışmayacağam. Məlumatların sonrakı emalından və istifadəçiyə təqdim edilməsindən də bəhs etməyəcəyəm. Həmçinin, alarmlardan da danışmayacağam.
Amma hekayə boyu mövcud monitorinqlərin müxtəlif ekran görüntülərini göstərəcəyəm, onları bir qədər tənqid edəcəyəm. Lakin brendləri adlandırmamağa çalışacağam, bu məhsullara reklam və ya anti-reklam yaratmamaq üçün. Bu səbəbdən bütün təsadüflər təsadüfidir və sizin fantaziyanıza aiddir.
İlk əvvəl monitorinqin nə olduğunu anlamağa çalışaq. Monitorinq – olması lazım olan çox vacib bir şeydir. Bunu hər kəs başa düşür. Lakin eyni zamanda, monitorinq biznes məhsuluna aid deyil və birbaşa şirkətin gəlirinə təsir etmir, buna görə monitorinqə həmişə artı vaxt ayrılır. Əgər vaxt varsa, monitorinqlə məşğul oluruq, vaxt yoxdur isə, problem deyil, bunu geridə saxlayırıq və bir gün bu vəzifələrə qayıdarıq.
Bu səbəbdən müştərilərə gəldikdə, monitorinqin tez-tez tam olmayan və işimizdə verilənlər bazası ilə əlaqədar daha yaxşı iş görməyə kömək etməyəcək maraqlı şeylərdən məhrum olduğunu görmüşük. Bu səbəbdən monitorinq həmişə inkişaf etdirilməlidir.
Verilənlər bazaları mürəkkəb sistemlərdir, onların da monitorinqini aparmaq lazımdır, çünki verilənlər bazaları məlumat yığımıdır. Məlumat şirkət üçün çox vacibdir, onu itirmək olmaz. Eyni zamanda, verilənlər bazaları çox mürəkkəb proqram təminatı parçalarıdır. Onlar bir çox komponentdən ibarətdir. Bu komponentlərin əksəriyyəti monitorinq edilməlidir.
PostgreSQL haqqında danışdığımızda, onu bir çox komponentdən ibarət olan bir sxem kimi təsəvvür etmək mümkündür. Bu komponentlər bir-biri ilə qarşılıqlı əlaqədədir. Eyni zamanda, PostgreSQL-də Stats Collector adlı bir alt sistem var ki, bu da bu alt sistemlərin fəaliyyəti haqda statistikaların toplanmasına imkan tanıyır və administratorun və ya istifadəçinin bu statistikaları gözdən keçirməsi üçün bir interfeys təmin edir.
Bu statistikalar müəyyən funksiyalar və görünüşlər (view) şəklində təqdim olunur. Onlara cədvəllər da demək olar. Yəni adi psql müştərisi ilə verilənlər bazasına qoşulub bu funksiyalara və görünüşlərə seçmə (select) sorğusu verərək PostgreSQL alt sistemlərinin fəaliyyətinə dair konkret rəqəmlər əldə edə bilərsiniz.
Bu rəqəmləri sevdiyiniz monitorinq sisteminə əlavə edə, qrafiklər çəkə, funksiyalar əlavə edə və uzunmüddətli perspektivdə analiz edə bilərsiniz.
Amma bu təqdimatda mən bu funksiyaların hamısını ətraflı izah etməyəcəyəm, çünki bu, günün tamamını alacaq. Mən sadəcə iki-üç-dörd konkret məsələyə toxunacam və onların monitorinqi necə daha yaxşı etməyə kömək etdiyini izah edəcəm.
Verilənlər bazasının monitorinqi haqqında danışarkən, nəyi monitorinq etməliyik? Əvvəlcə əlçatanlığı monitorinq etməliyik, çünki verilənlər bazası müştərilərə məlumatlara çıxış təqdim edən bir xidmətdir və biz onun əlçatanlığını, həmçinin bəzi keyfiyyət və kəmiyyət göstəricilərini monitorinq etməliyik.
Eyni zamanda, müştəri qoşulmalarını monitorinq etməliyik, çünki müştərilərimiz həm normal, həm də verilənlər bazasına zərər verə biləcək təhlükəli müştərilərlə ola bilər. Onları da monitorinq etməli və fəaliyyətlərini izləməliyik.
Müştərilər verilənlər bazasına qoşulduqda, açıqdır ki, onlar bizim məlumatlarımızla işləməyə başlayır, buna görə də müştərilərin məlumatlarla necə işlədiyini izləməliyik: hansı cədvəllərlə, daha az dərəcədə hansı indekslərlə. Yəni müştərilərimizin yaratdığı iş yükünü (workload) qiymətləndirməliyik.
Amma iş yükü, əlbəttə ki, sorğulardan ibarətdir. Tətbiqlər verilənlər bazasına qoşulur, məlumatlara sorğular vasitəsilə müraciət edirlər, buna görə də verilənlər bazamızda hansı sorğuların olduğunu qiymətləndirmək, onların uyğunluğunu izləmək, yanlış yazılmış sorğular varsa onları yenidən yazmaq və daha sürətli və daha yaxşı performansla işləməsini təmin etmək vacibdir.
Məlumat bazasından danışdığımız zaman, məlumat bazası həmişə arxa planda işləyən proseslər deməkdir. Arxa planda işləyən proseslər, məlumat bazasının performansını yaxşı səviyyədə saxlamaya imkan tanıyır, buna görə də onların işləməsi müəyyən qədər resurs tələb edir. Eyni zamanda bu proseslər müştəri sorğularının resursları ilə kəsişə bilər, buna görə də arxa planda işləyən proseslərin tələbatı müştəri sorğularının performansına birbaşa təsir göstərə bilər. Buna görə də, onların monitorinqini aparmaq və resurslarda balansın olmadığını izləmək vacibdir.
Bu kontekstdə məlumat bazasının monitorinqi sistem metrikalarında qalır. Ancaq nəzərə alsaq ki, infrastrukturun əksəriyyəti buludlara köçür, fərdi hostun sistem metrikaları həmişə ikinci plana keçə bilər. Lakin məlumat bazalarında bunlar hələ də aktualdır və sistem metrikalarını izləmək də vacibdir.
Sistem metrikaları ilə ümumiyyətlə hər şey yaxşıdır, müasir monitorinq sistemlərinin əksəriyyəti bu metrikaları dəstəkləyir, lakin bəzi komponentlər hələ də çatışmır və müəyyən şeylərin əlavə edilməsi lazımdır. Mən bununla bağlı da bir neçə slayd təqdim edəcəyəm.
Planın birinci bəndi – müştəriyə əlçatanlıqdır. Əlçatanlıq nə deməkdir? Mənim nəzərimdə, əlçatanlıq, məlumat bazasının əlaqələri idarə etmək qabiliyyətidir, yəni baza aktivdir, müştərilərdən gələn bağlantıları qəbul edir. Bu əlçatanlıq bir sıra xüsusiyyətlərlə qiymətləndirilə bilər. Bu xüsusiyyətləri panelə çıxarmaq çox rahatdır.
Hər kəs panelin nə olduğunu bilir. Bu, ekrana bir baxış atdığınız zaman, lazım olan məlumatın təqdim olunduğu yerdir. Və siz dərhal müəyyən edə bilərsiniz – bazada problem var, ya yox.
Beləliklə, məlumat bazasının əlçatanlığı və digər əsas xüsusiyyətlər həmişə paneldə olmalıdır ki, bu məlumat əlinizin altında, sizinlə olsun. Bəzi əlavə detalları, hansı ki, hadisələrin araşdırılmasında, bəzi təcili vəziyyətlərin araşdırılmasında kömək edir, onları ikincil panellərə çıxarmaq və ya xarici monitorinq sistemlərinə yönləndirilən drilldown linklərində gizlətmək lazım olacaq.
Bir məşhur monitorinq sisteminin nümunəsi. Bu, çox zəhmətkeş bir monitorinq sistemidir. O, çoxlu məlumat toplayır, lakin mənim fikrimcə, onun panel anlayışı qəribədir. Orada "panel yarat" linki var. Lakin paneli yaratdıqda, siz iki sütundan ibarət müəyyən bir siyahı, bir növ qrafiklər siyahısı yaradırsınız. Və nəyisə görmək istədikdə, mouse ilə klikləməyə, səhifə ətrafında dövr etməyə, lazım olan qrafiki axtarmağa başlayırsınız. Bu isə vaxt aparır, yəni panel kimi bir şey yoxdur. Sadəcə qrafiklərin siyahısı var.
Bu dəftərlərə nələri əlavə etmək lazımdır? Cavab vaxtı kimi bir göstərici ilə başlamaq olar. PostgreSQL-də pg_stat_statements adlı bir görünüş var. Bu, standart olaraq deaktivdir, lakin onu həmişə aktiv etmək və istifadə etmək vacib olan sistem görünüşlərindən biridir. Bu görünüş, verilənlər bazasında icra olunan bütün sorğular haqqında məlumat saxlayır.
Buna əsasən, bütün sorğuların həyata keçirilmə müddətinin ümumi vaxtını götürüb, yuxarıda göstərilən sahələrdən istifadə edərək, sorğuların sayına bölə bilərik. Lakin bu, xəstəxanada ortalama temperatur kimidir. Biz digər sahələrə də baxa bilərik – sorğuların minimal, maksimal və median vaxtlarına. Hətta percentile-lər qura bilərik, bunun üçün PostgreSQL-də müvafiq funksiyalar mövcuddur. Beləliklə, icra olunmuş sorğularımıza əsaslanaraq, verilənlər bazamızın cavab vaxtını xarakterizə edən bəzi rəqəmlər əldə edə bilərik; yəni, biz saxta bir sorğu olan 'select 1'i icra etmirik, sadəcə artıq icra olunmuş sorğuların cavab vaxtlarını analiz edirik və ya ayrı bir rəqəm kimi, ya da onun əsasında qrafik qururuq.
Eyni zamanda, sistemin hal-hazırda istehsal etdiyi xətaların sayını izləmək də vacibdir. Bunun üçün pg_stat_database görünüşündən istifadə edə bilərik. Biz xact_rollback sahəsinə nəzər salırıq. Bu sahə, yalnız verilənlər bazasında baş verən rollback-ların sayını göstərmir, həmçinin xətaların sayını da əhatə edir. Şəxsi, bu rəqəmi dəftərimizə yerləşdirə və hal-hazırda nə qədər xəta olduğunu izləyə bilərik. Əgər xətalar çoxdursa, bu, artıq log fayllarına baxmaq və bu xətaların nə olduğunu, niyə baş verdiyini araşdırmaq üçün yaxşı bir səbəbdir.
Bir Tachometr əlavə etmək olar. Bu, ikinciyə düşən tranzaksiyaların sayı və sorğuların sayı deməkdir. Şəxsi, bu rəqəmləri verilənlər bazamızın cari performansı olaraq istifadə edə və sorğuların, tranzaksiyaların piklərini izləyə bilərsiniz, yoxsa əksinə, verilənlər bazamız aşağı yüklənib, çünki hansısa bir backend düşüb. Bu rəqəmi həmişə izləmək və xatırlamaq vacibdir ki, layihəmiz üçün bu cür performans normaldır, daha yüksək və daha aşağı olan rəqəmlər artıq problemli və anlaşılmazdır, deməli, niyə belə rəqəmlər var, ona baxmalıyıq.
Tranzaksiyaların sayını qiymətləndirmək üçün yenidən pg_stat_database görünüşünə müraciət edə bilərik. Biz commit və rollback sayını toplamaqla, bu zaman sekuntda tranzaksiyaların sayını əldə edə bilərik.
Hamı başa düşür ki, bir tranzaksiyaya bir neçə sorğu sığa bilər? Buna görə də TPS və QPS bir az fərqlidir.
Saniyyələrdə alınan sorğuların sayını pg_stat_statements vasitəsilə əldə etmək və yerinə yetirilmiş bütün sorğuların cəmini hesablamaq mümkündür. Aydındır ki, biz cari dəyəri əvvəlki ilə müqayisə edirik, çıxarırıq, deyişimi əldə edirik, sayını müəyyən edirik.
İstəyə bağlı olaraq əlavə metrikalar əlavə etmək mümkündür ki, bunlar da bazamızın əlçatanlığını qiymətləndirməkdə və hər hansı bir dövrün olub-olmamasını izləməkdə kömək edir.
Bu metrikalardan biri uptime-dır. Lakin PostgreSQL-də uptime bir az mürəkkəb məsələdir. Niyə olduğunu izah edəcəyəm. PostgreSQL başladıqda, uptime hesablamağa başlanılır. Ancaq, məsələn, gecə hansısa bir iş görülərkən, OOM-killer gəlib PostgreSQL-in törəmə prosesini zorla dayandırsa, bu halda PostgreSQL bütün müştəri bağlantılarını sona çatdırır, shard edilmiş yaddaş sahəsini boşaldır və son kontrol nöqtəsindən bərpa etməyə başlayır. Kontrol nöqtəsindən bərpa edildiyi müddət ərzində baza bağlantıları qəbul etmir, yəni bu vəziyyəti downtime olaraq qiymətləndirmək olar. Ancaq uptime sayğacı sıfırlanmayacaq, çünki bu, postmaster-in ilk başladığı andan etibarən zamanını hesablayır. Beləliklə, bu cür hallar gözardı edilə bilər.
Eyni zamanda, vacuum işçilərinin sayını da izləmək lazımdır. Hamı PostgreSQL-də autovacuum-un nə olduğunu bilir? Bu, PostgreSQL-də maraqlı bir alt sistemdir. Haqqında çoxlu məqalələr yazılıb, çoxlu təqdimatlar hazırlanıb. Bəzi müzakirələr vacuum haqqındadır, onun necə işləməsi lazım olduğu ilə bağlıdır. Çoxları onu qaçılmaz bir bəlaya bənzədir. Amma belədir. Bu, köhnəlmiş sətirlərin, heç bir tranzaksiyaya lazım olmayanların, təmizlənməsi və yeni sətirlər üçün tablolar, indekslər içərisində yer boşaltması üçün bənzər bir zibil toplayan analoqudur.
Niyə bunu izləmək lazımdır? Çünki vacuum bəzən çox ziyanlı olur. O, çoxlu resursları yeyir və müştəri sorğuları bundan əziyyət çəkir.
Vakuumu pg_stat_activity vasitəsilə izləmək lazımdır, onun haqqında mən növbəti müddəada danışacağam. Bu görünüş statistik aktivliyi göstərir. Və bu aktivlik vasitəsilə biz hazırda işləyən vacuum-ların sayını izləyə bilərik. Vakuumları izləyə bilərik və görsək ki, limitimizi aşmışıq, bu, PostgreSQL konfiqurasiyasına nəzər yetirmək və vacuum-un işini optimallaşdırmaq üçün bir səbəbdir.
PostgreSQL-in digər bir xüsusiyyəti budur ki, uzun tranzaksiyalardan çox əziyyət çəkir. Xüsusilə, uzun müddət asılı qalan və heç nə etməyən tranzaksiyalarla. Bunlar, adətən, stat idle-in-transaction-lardır. Belə bir tranzaksiya kilidləri saxlayır, vacuum-un işini çətinləşdirir. Nəticədə, tablolar böyüyür, ölçüləri artır. Və bu tablolarla işləyən sorğular, köhnə sətirləri yaddaşdan diska qaldırmaq və geri qaytarmaq üçün daha uzun çətinliklə işləməyə başlayır. Buna görə, ən uzun tranzaksiyaların, ən uzun boşluq sorğularının müddəti də izlənilməlidir. Və əgər biz uzun müddət işləyən proseslər, OLTP yükü üçün artıq 10-20-30 dəqiqədən çox çalışanlar görsək, onlara diqqət yetirməli və ya onları məcburi olaraq dayandırmalıyıq, ya da tətbiqi optimallaşdırmalıyıq ki, belə uzun müddət işləməsinlər. Analitik yük üçün 10-20-30 dəqiqə normaldır, burada daha uzun olanları da ola bilər.
Daha sonra müştərilərlə bağlı variantımız var. Artıq panelimizi qurduqdan sonra, əsas mövcudluq metrikalarını göstərdikdən sonra, əlavə müştəri məlumatlarını da əlavə edə bilərik.
Müştərilərlə bağlı məlumat vacibdir, çünki PostgreSQL nöqteyi-nəzərdən müştərilər fərqli olur. Yaxşı müştərilər və pis müştərilər olur.
Sadə bir misal. Müştəri dedikdə, tətbiqi nəzərdə tuturam. Tətbiq verilənlər bazasına qoşulur və dərhal oraya sorğular göndərməyə başlayır, verilənlər bazası onları emal edir və nəticələri müştəriyə qaytarır. Bunlar yaxşı və düzgün müştərilərdəndir.
Bəzi hallarda müştəri qoşulur, bağlantını saxlayır, lakin heç nə etmir. O, idle (boş) vəziyyətdədir.
Amma pis müştərilər də olur. Məsələn, eyni müştəri qoşulur, tranzaksiya açır, verilənlər bazasında bir şeylər edəndən sonra, xarici mənbəyə müraciət etmək və ya alınan məlumatları emal etmək üçün kodda düşür. Ancaq o, tranzaksiyanı bağlamır. Və tranzaksiya verilənlər bazasında qalır və bir sətrin bloklanmasına səbəb olur. Bu, pis bir vəziyyətdir. Və əgər tətbiq içəridə bir sıra xətalar (Exception) səbəbiylə çöksə, tranzaksiya uzun müddət açıq qala bilər. Bu, PostgreSQL-in performansına birbaşa təsir edir. PostgreSQL daha yavaş işləyəcək. Buna görə də, belə müştəriləri vaxtında izləmək və onların fəaliyyətini məcburi olaraq dayandırmaq vacibdir. Tətbiqinizi optimallaşdırmaq və belə halların baş verməməsini təmin etmək lazımdır.
Digər pis müştərilər, gözləyən müştərilərdir. Lakin, onlar şəraitlərdən dolayı pis olurlar. Məsələn, sadə dayanan bir əməliyyat: bir əməliyyat açacaq, bəzi sətirlərdə kilidlər götürəcək, sonra bir yerdə kodda bu səhv baş verəcək və bir dayanan əməliyyat qalacaq. Başqa bir müştəri eyni məlumatları soruşacaq, lakin kilidlənmə ilə qarşılaşacaq, çünki o dayanan əməliyyat artıq lazım olan bəzi sətirlərə kilid qoyur. İkinci əməliyyat isə birincisi tamamlanana qədər və ya onun idarəçisi onu zorla bağlayana qədər gözləyəcək. Beləliklə, gözləyən əməliyyatlar yığılaraq verilənlər bazasına qoşulma limitini aşır. Və limit aşılarsa, tətbiq artıq verilənlər bazası ilə işləyə bilmir. Bu artıq layihə üçün fövqəladə vəziyyətdir. Buna görə pis müştəriləri izləmək və vaxtında reaksiya vermək lazımdır.
Başqa bir monitorinq nümunəsi. Burada isə artıq müvafiq bir panel var. Üst hissədə qoşulmalar haqqında məlumat var. DB connection – 8 ədəd. Və bu, hər şeydir. Aktiv müştərilər, sadəcə məşğul olmayan müştərilər haqqında heç bir məlumatımız yoxdur. Dayanan əməliyyatlar və gözləyən qoşulmalar barədə məlumat yoxdur, yəni bu, sadəcə qoşulmaların sayını göstərən bir ədəddir. Qalanını özünüz düşünün.
Beləliklə, bu məlumatı monitorinqə əlavə etmək üçün pg_stat_activity sistem görünüşünə müraciət etmək lazımdır. Əgər PostgreSQL-dən çox vaxt keçirirsinizsə, bu, sizin dostunuz olmalı olan çox gözəl bir görünüşdür, çünki bu, PostgreSQL-də baş verən cari aktivliyi göstərir. Hər proses üçün ayrı bir sətir var, bu da həmin proses haqqında məlumatları göstərir: hansı host-dan qoşulma həyata keçirilib, hansı istifadəçi ilə, hansı ad altında, əməliyyat nə zaman başlandı, indiki icra edilən sorğu nədir, ən son icra edilən sorğu nədir. Və nəticədə, müştərinin vəziyyətini stat sahəsi üzrə qiymətləndirə bilərik. Şərti olaraq, bu sahə üzrə qruplaşma apara bilərik və verilənlər bazasında olan müvafiq stats-ları və bu stat-la olan qoşulmaların sayını əldə edə bilərik. Artıq əldə olunan rəqəmləri monitorinqimizə göndərə və onların üzrə qrafiklər çizə bilərik.
Eyni zamanda, əməliyyatın davamlılığını dəyərləndirmək vacibdir. Mən artıq vakuumların davamlılığını dəyərləndirməyin vacib olduğunu demişdim, amma əməliyyatlar da tam eyni şəkildə dəyərləndirilir. Xact_start və query_start sahələri var. Şərti olaraq, bunlar əməliyyatın başlama vaxtını və sorğunun başlama vaxtını göstərir. İndiki vaxtı göstərən now() funksiyasını götürürük və əməliyyatın və sorğunun zaman möhürünü çıxarırıq. Və əməliyyatın, sorğunun davamlılığını alırıq.
Əgər uzun əməliyyatlar görsək, artıq onları başa çatdırmalıyıq. OLTP yükü için uzun işlemler 1-2-3 dakikadan daha fazlasını içerir.. OLAP yükü için uzun işlemler normaldir, ancak iki saatten fazlaysa, bu durum dengesizlik olduğunu gösterir.
Müşteriler veritabanına bağlandıklarında, verilerimizle çalışmaya başlarlar. Tablo ve indekslere başvurarak verileri alırlar. Bu verilerle nasıl çalıştıklarını değerlendirmek önemlidir.
Bu, yükümüzü değerlendirmek ve hangi tablolarımızın en 'aktif' olduğunu anlamak için gereklidir. Örneğin, 'aktif' tabloları hızlı bir SSD depolama alanına yerleştirmek istediğimiz durumlarda faydalıdır. Uzun zamandır kullanmadığımız arşiv tablolarını 'soğuk' arşivde, SATA disklerde saklayabiliriz; ihtiyaç duydukça onlara erişim sağlanır.
Ayrıca, çeşitli sürüm ve dağıtımlardan sonra anormallikleri tespit etmek için de faydalıdır. Örneğin, bir proje yeni bir özellik çıkardı. Veritabanı ile çalışma işlevselliği eklendi. Eğer tablo kullanım grafiklerini oluşturursak, bu grafiklerde bu anormallikleri kolayca tespit edebiliriz. Örneğin, güncellemelerde ya da silmelerde ani artışlar gözlemlenecektir.
Ayrıca, 'kaçan' istatistikleri tespit etmek mümkündür. Bu ne demektir? PostgreSQL, güçlü bir sorgu planlayıcısına sahiptir. Geliştiriciler bu planlayıcı üzerinde çok zaman harcarlar. Nasıl çalışır? İyi planlar oluşturabilmek için, PostgreSQL belirli aralıklarla, tabloların veri dağılımı hakkında istatistik toplar. Bu, en sık rastlanan değerlerdir: benzersiz değerlerin sayısı, tabloda bulunan NULL bilgisi gibi çok sayıda bilgi.
Bu istatistiklere dayanarak, planlayıcı birkaç sorgu oluşturur, en optimal olanı seçer ve bu sorgu planını sorguyu çalıştırmak ve verileri geri döndürmek için kullanır.
Ve istatistiklerin 'kaçtığı' durumlar olabilir. Tablo içinde verilerin kalitesi veya miktarı değişebilir, ancak istatistik toplanmamış olabilir. Oluşturulan planlar optimum olmayabilir. Eğer planlarımız, toplanan izlemeye göre optimum değilse, bu anormallikleri görebiliriz. Örneğin, veriler kalitesizleştiğinde ve indekse göre tablo üzerinde ardışık geçiş yapılmaya başlandığında, sadece 100 satır döndürmesi gereken bir sorgu, tam bir tarama gerçekleştirebilir (limit 100 sınırlaması var). Bu durum, performans açısından her zaman olumsuz etkiler yaratır.
Və bunu monitorinqdə görə biləcəyik. Bu sorğuya baxıb, onun üçün explain yerinə yetirib, statistika toplayıb, yeni əlavə indeks qurmağımız mümkündür. Beləliklə, bu problemi vaxtında aradan qaldıra bilərik. Buna görə də bu vacibdir.
Başqa bir monitorinq nümunəsi. Düşünürəm ki, bir çoxları bununla tanışdır, çünki çox populyardır. Kim öz layihələrində bunu istifadə edir? ? А кто использует этот продукт совместно с Prometheus? Дело в том, что в стандартном репозитории этого мониторинга есть дашборд для работы с PostgreSQL – Prometheus. Amma burada bir məsələ var.
Bəzi qrafiklər mövcuddur. Vahid olaraq baytlar göstərilib, yəni orada 5 qrafik var. Bunlar Insert data, Update data, Delete data, Fetch data və Return data-dır. Ölçü vahidi kimi baytlar göstərilib. Lakin məsələ bundadır ki, PostgreSQL-də statistikalar tuple (sətirlər) şəklində geri qaytarılır. Buna görə də, bu qrafiklər sizin iş yükünüzü bir neçə dəfə, yüzlərlə dəfə aşağı salmağın çox yaxşı bir yolu ola bilər, çünki tuple bir bayt deyil, tuple bir sətirdir, çox sayda baytdan ibarətdir və həmişə dəyişkən uzunluqludur. Yəni, baytlarla tuple-lardan iş yükünü hesablamaq mümkün deyil, yaxud da çox çətin bir işdir. Buna görə də, xəritədən və ya daxili monitorinqdən istifadə edərkən, onun düzgün işlədiyini və sizə dəqiq qiymətləndirilmiş məlumatları qaytardığını başa düşmək həmişə vacibdir.
Bu cədvəllər üzrə statistikaları necə əldə etmək olar? Bunun üçün PostgreSQL-də bir neçə görünüş ailəsi mövcuddur. Əsas görünüş isə dir. User_tables – bu, istifadəçi tərəfindən yaradılmış cədvəlləri ifadə edir. Bunun əksinə, PostgreSQL tərəfindən istifadə olunan sistem görünüşləri var. Həmçinin, həm sistem, həm də istifadəçi cədvəllərini əhatə edən Alltables adlı ümumi cədvəl var. Siz hansının sizin üçün daha uyğun olduğunu seçə bilərsiniz.
Yuxarıda qeyd olunan sahələr əsasında insert, update və delete sayını qiymətləndirmək mümkündür. İstifadə etdiyim o panel nümunəsi məhz bu sahələri iş yükü xüsusiyyətlərini qiymətləndirmək üçün istifadə edir. Buna görə də, biz bunlara əsaslaya bilərik. Amma unutmaq olmaz ki, bu tuples-dir, baytlar deyil, buna görə də, bunu sadəcə baytlara çevirmək mümkün deyil.
Bu məlumatlara əsaslanaraq, TopN cədvəllərini qurmaq mümkündür. Məsələn, Top-5, Top-10. Və daha çox istifadə olunan “isti” cədvəlləri izləmək olar. Məsələn, insert üzrə 5 “isti” cədvəl. Bu TopN cədvəlləri əsasında iş yükümüzü qiymətləndiririk və müxtəlif versiyaların və yeniləmələrin, və yerləşdirmələrin ardından iş yükündəki artımları qiymətləndirə bilərik.
Həmçinin, cədvəlin ölçüsünü qiymətləndirmək də vacibdir, çünki bəzən inkişaf etdiricilər yeni bir xüsusiyyət buraxırlar və cədvəllərimizin ölçüləri böyüməyə başlayır, çünki əlavə məlumat yazmağı qərara alırlar, lakin bunun verilənlər bazasının ölçüsünə necə təsir edəcəyini proqnozlaşdıra bilməzlər. Belə hallar da bizim üçün sürpriz ola bilər.
Və indi sizə kiçik bir sual var. Verilənlər bazasında server yükü müşahidə edəndə hansı sual yaranır? Nə sual düşünürsünüz?
Amma əslində bu sual doğurur: H hansı sorğular yük yaradır? Yəni yüklənməyə səbəb olan prosesləri izləmək maraqlı deyil. Aydın məsələdir ki, əgər host verilənlər bazasıdırsa, orada verilənlər bazası işə salınmışdır və aydındır ki, yalnız verilənlər bazaları orada resurslardan istifadə edəcək. Əgər Top-u açsaq, PostgreSQL-də nələrin baş verdiyinə dair proseslərin siyahısını görəcəyik. Top-dan onların nə etdiyini başa düşmək mümkün olmayacaq.
Beləliklə, ən çox yükləmə yaradan sorğuları müəyyənləşdirmək lazımdır, çünki sorğuların tüninqi adətən PostgreSQL-in və ya əməliyyat sisteminin konfiqurasiyasının tüninqindən, hətta texniki avadanlığın tüninqindən daha çox fayda verir. Mənim hesablamalarıma görə, bu, təxminən 80-85-90% təşkil edir. Və bu, çox daha sürətli həyata keçirilir. Sorğunu düzəltmək konfiqurasiyanı düzəltməkdən, planlı yenidən işə salmağı təşkil etməkdən daha tezdir, xüsusən də verilənlər bazasını yenidən işə salmaq mümkün deyilsə, ya da əlavə avadanlıq əlavə etmək lazım olarsa. Daha asandır ki, harada isə sorğunu yenidən yazmaq və ya indeks əlavə etmək ki, bu sorğudan daha yaxşı nəticə əldə edək.
Beləliklə, sorğuları və onların adekvatlığını monitorinq etməliyik. Gəlin monitorinqin başqa bir nümunəsini götürək. Burada da gözəl bir monitorinq var. Replikasiya məlumatları var, ötürmə qabiliyyəti, bloklanmalar, resursların istifadəsi haqqında məlumat var. Hər şey gözəl, amma sorğularla bağlı heç bir məlumat yoxdur. Verilənlər bazamızda hansı sorğuların yerinə yetirildiyi, onların nə qədər zamanda yerinə yetirildiyi, neçə sorğunun olduğu aydın deyil. Monitorinqimizdə hər zaman bu məlumatlara sahib olmalıyıq.
Və bu məlumatları əldə etmək üçün pg_stat_statements modulundan istifadə edə bilərik. Onun əsasında müxtəlif qrafiklər qurmaq mümkündür. Məsələn, ən tez-tez icra olunan sorğular haqqında məlumatı ala bilərik, yəni ən çox yerinə yetirilən sorğulara. Bəli, yayım proseslərindən sonra bunu izləmək çox faydalıdır və hansısa sorğu sıçrayışı olub-olmadığını başa düşmək üçün.
Ən uzun icra olunan sorğuları da izləyə bilərik, yəni ən çox zaman sərf edən sorğuları. Onlar prosessoru işə salır, giriş-çıxış resurslarını istehlak edir. Biz bunu total_time, mean_time, blk_write_time və blk_read_time sahələri ilə də ölçə bilərik.
Resurs istifadəsində ən ağır sorğuları da qiymətləndirmək və monitorinq etmək mümkündür, yəni diskdən oxuyan, yaddaşla işləyən və ya əksinə, yazma yükü yaradan sorğuları.
Ən bol sorğuları qiymətləndirə bilərik. Bunlar çox sayda sətir qaytaran sorğulardır. Məsələn, bu, limit qoymağı unudulan bir sorğu ola bilər. Və o, sadəcə olaraq, cədvəlin bütün məzmununu və ya tələb olunan cədvəllərdəki sorğunu qaytarır.
Eyni zamanda, müvəqqəti faylları və ya müvəqqəti cədvəlləri istifadə edən sorğuları da izləyə bilərik.
Və arxa plan proseslərimiz qaldı. Arxa plan prosesləri, birincisi, yoxlama nöqtələri və ya onların kontrol nöqtələri, autovacuum və replikasiyadır.
Başqa bir monitorinq nümunəsi. Solda Maintenance tabına keçirik və faydalı bir şey görməyi ümid edirik. Ancaq burada yalnız vakuumun işləmə vaxtı və statistikaların toplanması vardır, daha heç nə. Bu, çox zəif bir məlumatdır, buna görə də həmişə verilənlər bazasında fon proseslərinin necə işlədiyi və onların fəaliyyətindən hər hansı bir problemin olub-olmadığı haqqında məlumat olmalıdır.
Nəhayət, yoxlama nöqtələrini nəzərdən keçirərkən, yoxlama nöqtələrinin ‘çirkli’ səhifələri parçalanmış yaddaş sahəsindən diskə atdığını və daha sonra yoxlama nöqtəsi yaratdığını unutmaq olmaz. Və bu yoxlama nöqtəsi daha sonra bərpa zamanı istifadə olunan bir yer ola bilər, əgər PostgreSQL qəfildən dayandırılıbsa.
Beləliklə, bütün ‘çirkli’ səhifələri diskinə atmaq üçün bir qədər yazma əməliyyatları həyata keçirmək lazımdır. Və adətən, böyük miqdarda yaddaşa sahib sistemlərdə bu, çox şeydir. Və əgər yoxlama nöqtələri qısa bir müddət ərzində çox tez-tez həyata keçirilirsə, disk performansı ciddi şəkildə pisləşəcək. Və müştəri sorğuları resurs çatışmazlığından əziyyət çəkəcək. Onlar resurslar üçün mübarizə aparacaqlar və performansdan məhrum olacaqlar.
Beləliklə, pg_stat_bgwriter tərəfindən göstərilən sahələr vasitəsilə baş verən yoxlama nöqtələrinin sayını izləyə bilərik. Və əgər müəyyən bir zaman aralığında (10-15-20 dəqiqə, yarım saat) çox sayda yoxlama nöqtəsi varsa, məsələn, 3-4-5, bu artıq problem ola bilər. Və verilənlər bazasına baxmaq, konfiqurasiyaya baxmaq və bu cür yoxlama nöqtələrinin çoxluğuna səbəb olan bir şey olduğunu müəyyən etməyə ehtiyac var. Yəqin ki, böyük bir yazma baş verir. İş yükünü qiymətləndirə bilərik, çünki iş yükü qrafiklərimiz artıq əlavə olunub. Yoxlama nöqtələrinin parametrlərini yaxşılaşdırıb sorğuların performansına çox təsir etməyəcək şəkildə təsir edə bilərik.
Mən yenidən autovacuum-a qayıdıram, çünki bu, həm disklərin, həm də sorğuların performansını asanlıqla poza biləcək bir şeydir, buna görə autovacuum sayını qiymətləndirmək həmişə əhəmiyyətlidir.
Verilənlər bazasında autovacuum işçilərinin sayı məhduddur. Standart olaraq, onların sayı üçdür, buna görə də əgər bazada daim üç işçi işləyirsə, bu, autovacuum-un düzgün ayarlanmadığını göstərir, limitləri artırmaq, autovacuum ayarlarını gözden keçirmək və konfiqurasiyaya girmək lazımdır.
Hansı vakuum işçilərinin işlədiyini qiymətləndirmək vacibdir. Ya bu, istifadəçi tərəfindən işə salınmış, DBA tərəfindən əl ilə işə salınmış bir vakuumdur və bu, yük yaradır. Bizdə hansısa bir problem ortaya çıxır. Ya da bu, tranzaksiya sayını azaltan vakuumların sayıdır. Bəzi PostgreSQL versiyaları üçün bunlar çox ağır vakuumlardır. Və onlar asanlıqla performansı poza bilərlər, çünki onlar bütün cədvəli tam olaraq oxuyur, bu cədvəldəki bütün blokları skan edir.
Və əlbəttə, vakuumların müddəti. Əgər bizim uzun müddət işləyən vakuumlarımız varsa, bu, deməkdir ki, yenidən vakuumun konfiqurasiyasına diqqət yetirməliyik və bəlkə də onun parametrlərini gözdən keçirməliyik. Çünki bir vəziyyət yarana bilər ki, vakuum uzun müddət (3-4 saat) bir cədvəldə işləyir, lakin işləmə müddəti ərzində cədvəldə yenidən böyük bir ölçekdə ölü sətirlər yığılır. Və vakuum başa çatdıqda, bu cədvəli yenidən vacuum etməsi lazım gəlir. Və biz sonsuz vacuum vəziyyətinə gəlib çıxırıq. Belə bir halda vakuum öz işini yerinə yetirə bilmir və cədvəllər tədricən ölçülcə böyüyür, halbuki onun daxilindəki faydalı məlumatların həcmi eyni qalır. Buna görə də uzun müddət vakuumlarda hər zaman konfiqurasiyaya baxırıq və onu optimallaşdırmağa çalışırıq, lakin müştəri sorğularının performansını da zərər vermədən.
İndi demək olar ki, PostgreSQL-in hər bir qurulmasında axın replikasiyası var. Replikasiya - məlumatların ustadan replikaya daşınma prosesidir.
PostgreSQL-də replikasiya tranzaksiya jurnalından istifadə edilərək həyata keçirilir. Usta tranzaksiya jurnalını yaradır. Tranzaksiya jurnalı şəbəkə bağlantısı ilə replikaya gedir, daha sonra replikada bərpa edilir. Hər şey sadədir.
Müvafiq olaraq, replikasiya lagını izləmək üçün pg_stat_replication görünüşü istifadə olunur. Lakin bununla hamısı sadə deyil. 10-cu versiyada görünüş bir neçə dəyişikliklərə uğradı. Birincisi, bəzi sahələr adlandırıldı. Və bəzi sahələr əlavə edildi. 10-cu versiyada replikasiya lagını saniyələrlə qiymətləndirmək üçün sahələr yarandı. Bu, çox rahatdır. 10-cu versiyadan əvvəl replikasiya lagını baytlarla qiymətləndirmək imkanı var idi. Bu imkana 10-cu versiyada da davam edilib, yəni istədiyinizə görə replikasiya lagını baytlarla və ya saniyələrlə qiymətləndirmək seçimini edə bilərsiniz. Bir çoxu həm bunu, həm də bunu edir.
Lakin replikasiya lagını qiymətləndirmək üçün tranzaksiyada jurnalın mövqeyini bilmək lazım. Bu tranzaksiya jurnalı mövqeləri elə pg_stat_replication görünüşündə mövcuddur. Şərti olaraq, pg_xlog_location_diff() funksiyası vasitəsilə tranzaksiya jurnalında iki nöqtə əldə edə bilərik. Onlar arasındakı fərqi hesablayıb replikasiya lagını baytlarla əldə edə bilərik. Bu, çox rahatdır və sadədir.
10-cu versiyada bu funksiya pg_wal_lsn_diff() olaraq adlandırıldı. Ümumiyyətlə, funksiyalarda, görünüşlərdə, utilitlərdə 'xlog' sözü olan bütün funksiyalar 'wal' ilə əvəz edildi. Bu, həm görünüşlərdə, həm də funksiyalarda baş verir. Bu, yeni bir yenilikdir.
10-cu versiyada spesifik lagı gösteren sətirlər əlavə edildi. Bu, write lag, flush lag, replay lag-dır. Yəni bu şeyləri izləmək vacibdir. Əgər replikasiya lagını görsək, nəyə görə meydana gəldiyini, haradan gəldiyini öyrənməli və problemi həll etməliyik.
Sistem metrikaları ilə bütün işlər qaydasındadır. Hər hansı bir monitorinq başladıqda, sistem metrikalarından başlayır. Bu, prosessorların, yaddaşın, swap'ın, şəbəkənin və disk istifadəsidir. Lakin, buna baxmayaraq, bir çox parametr orada standart olaraq yoxdur.
Əgər prosessor istifadəsində hər şey qaydasındadırsa, disk istifadəsində problemlər var. Adətən, monitorinq inkişaf etdiriciləri ötürmə qabiliyyəti haqqında məlumatı əlavə edirlər. Bu, iops və ya baytlarda ola bilər. Lakin, onlar gecikmə və disk cihazlarının istifadəsini unudurlar. Bu, diskimizin nə qədər yüklü olduğunu və nə qədər gecikdiyini qiymətləndirmək üçün daha vacib parametrlərdir. Əgər gecikməmiz yüksəkdirsə, bu, disk problemlərinin olduğuna işarədir. Əgər istifadəmiz yüksəkdirsə, bu, disklərin yüklənmədiyini bildirir. Bu, ötürmə qabiliyyətinə nisbətən daha keyfiyyətli xüsusiyyətlərdir.
Bu statistikaları /proc fayl sistemindən də əldə etmək olar, bu prosessor istifadəsi üçün necə edilir. Niyə bu məlumatları monitorinqlərə əlavə etmirik, bilmirəm. Lakin, buna baxmayaraq, onu monitorinqdə saxlamaq vacibdir.
Şəbəkə interfeysləri üçün də eyni şeydir. Şəbəkənin paketlərdə, baytlarda ötürmə qabiliyyəti haqqında məlumat var, lakin gecikmə məlumatı yoxdur və istifadə haqqında məlumat yoxdur, baxmayaraq ki, bu da faydalı məlumatdır.
Hər hansı bir monitorinqin çatışmazlıqları var. Hansi monitorinqi götürsəniz, o həmişə müəyyən kriteriyalara uyğun gəlməyəcək. Lakin, buna baxmayaraq, onları inkişaf etdirirlər, yeni xüsusiyyətlər əlavə edilir, buna görə də bir şey seçin və onu inkişaf etdirin.
Və inkişaf etdirmək üçün, verilən statistikaların nə olduğunu və bununla necə problemləri həll edə biləcəyinizi həmişə başa düşməlisiniz.
Və bir neçə əsas məqam:
- Həmişə əlçatanlığı monitorinq etmək lazımdır, beləliklə siz sürətlə qiymətləndirmək üçün panel olacaq ki, məlumat bazasında hər şey qaydasındadır.
- Həmişə müştərilərinizin məlumat bazası ilə necə işlədiyini bilmək vacibdir, buna görə də pis müştəriləri ayırmaq və onları aradan qaldırmaq mümkündür.
- Bu müştərilərin verilənlərlə necə işlədiyini qiymətləndirmək vacibdir. İş yükünüzü başa düşmək lazımdır.
- Bu iş yükünün necə formalaşdığını, hansı sorğularla müəyyənləşdirmək vacibdir. Sorğuları qiymətləndirə və onları optimallaşdıra, refaktorizasiya edə, onlara indekslər qura bilərsiniz. Bu, çox vacibdir.
- Fon prosesləri müştəri sorğularına mənfi təsir göstərə bilər, bu səbəbdən də onların çoxlu resurs istifadəsi üçün izləmək vacibdir.
- Sistem metrikaları, serverlərinin tutumunu artırmağı planlamağınıza imkan verir, buna görə də onları izləmək və qiymətləndirmək də vacibdir.
Bu mövzuyla maraqlanırsınızsa, bu linklərə baxa bilərsiniz.
— bu statistik kollektorları üçün rəsmi sənəddir. Orada bütün statistik görünüşlərin təsviri və bütün sahələrin izahı var. Siz onları oxuya, başa düşə və analiz edə bilərsiniz. Və əsasında öz qrafiklərinizi qurub, öz monitorinqlərinizə əlavə edə bilərsiniz.
Sorğu nümunələri:
Bu bizim korporativ depozitimizdir və özüm üçün. Orada sorğu nümunələri var. Orada select* from bir şey yoxdur. Orada artıq hazır sorğular var, join-lərlə, maraqlı funksiyaların tətbiqi ilə hazırlanan, xam rəqəmlərdən oxunaqlı, rahat dəyərlər yaradır, yəni bunlar baytlar, vaxtdır. Siz onları araşdıra, baxa, analiz edə, öz monitorinqlərinizə əlavə edə, onlardan öz monitorinqlərinizi qura bilərsiniz.
Suallar
Sual: Dediniz ki, brendləri reklam etməyəcəksiniz, amma mənim üçün maraqlıdır – öz layihələrinizdə hansı dashboardlardan istifadə edirsiniz?
Cavab: Müxtəlif olur. Bəzən müştəriyə gedirik və onun artıq öz monitorinqi var. Və biz müştəriyə onun monitorinqinə nə əlavə etməli olduğu barədə məsləhət veririk. Zabbix ilə işlər pisdir. Çünki onun TopN-qrafiklər qurmaq imkanı yoxdur. Biz özümüz , çünki bu oğlanlara monitorinq sahəsində məsləhət verdik. Onlar bizim TSh-nin əsasında PostgreSQL üçün monitorinq hazırladılar. Mən öz pet layihəmi yazıram, hansı ki, məlumatları Prometheus vasitəsilə toplayır və onları şəklini çəkir. Mənim vəzifəm Prometheus-da öz eksportatorumu yaratmaqdır və daha sonra bütününü Grafana-da vizuallaşdırmaqdır.
Sual: AWR hesabatlarının və ya ... agregasiyanın analoqları varmı? Sizə belə bir şey məlumdirmi?
Cavab: Bəli, AWR-in nə olduğunu bilirəm, bu əla bir şeydir. Hazırda müxtəlif modelləri reallaşdıran bir çox variantlar var. Müəyyən bir vaxt intervalında bəzi baselainlər eyni PostgreSQL-ə və ya ayrı bir saxlama yerinə yazılır. Onları internetdə tapmaq mümkündür, var. Belə bir şeyin bir inkişafçısı sql.ru forumunda PostgreSQL bölməsində oturur. Orada onu tutmaq mümkündür. Bəli, belə şeylər var, bunları istifadə etmək olar. Üstəlik, mən də öz şeyimi yazıram ki, eyni şeyi edə bilir.
P.S.1 Əgər siz postgres_exporter istifadə edirsinizsə, hansı dashboarddan istifadə edirsiniz? Orada bir neçə var. Onlar artıq köhnədir. Ola bilsin ki, icma yenilənmiş şablon yaratsın?
P.S.2 pganalyze-ni çıxardım, çünki bu, performans monitorinqinə və avtomatlaşdırılmış tənzimləmə təkliflərinə yönəlmiş mülkiyyətçi SaaS təklifidir.
Yalnız qeydiyyatdan keçmiş istifadəçilər sorğuda iştirak edə bilərlər. , xahiş edirəm.
Hansı self-hosted postgresql monitorinqini (dashboard ilə) ən yaxşı hesab edirsiniz?
30,0%Zabbix + Aleksey Lesovski tərəfindən əlavələr və ya zabbix 4.4 və ya 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 mülkiyyətçi SaaS-dir — silə bilmirəm1
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 istifadəçi səs verdi. 26 istifadəçi ehtiyatlı qaldı.
Mənbə: habr.com
