Mən sizə Aleksey Lesovskinin Data Egretdən “PostgreSQL monitorinqinin əsasları” adlı hesabatının stenoqramını oxumağı təklif edirəm.
Bu hesabatda Aleksey Lesovski post-qress statistikasının əsas məqamları, onların nə demək olduğu və monitorinqdə niyə iştirak etmələri barədə danışacaq; monitorinqdə hansı qrafiklərin olması, onları necə əlavə etmək və necə şərh etmək barədə. Hesabat verilənlər bazası administratorları, sistem administratorları və Postgres problemlərinin həlli ilə maraqlanan tərtibatçılar üçün faydalı olacaq.
Mənim adım Aleksey Lesovskidir, mən Data Egret şirkətini təmsil edirəm.
Özüm haqqında bir neçə kəlmə. Mən uzun müddət əvvəl sistem administratoru kimi fəaliyyətə başlamışam.
Mən hər cür müxtəlif Linux sistemlərini idarə etdim, Linux ilə əlaqəli müxtəlif şeylər üzərində işlədim, yəni virtuallaşdırma, monitorinq, proksilərlə işlədim və s. Amma bir anda daha çox verilənlər bazası, PostgreSQL ilə işləməyə başladım. Mən onu çox bəyəndim. Və bir anda iş vaxtımın çox hissəsini PostgreSQL üzərində işləməyə başladım. Və tədricən PostgreSQL DBA oldum.
Və karyeram boyu həmişə statistika, monitorinq və telemetriya mövzuları ilə maraqlanmışam. Mən sistem administratoru olanda Zabbix ilə çox sıx işləyirdim. Və kimi kiçik bir skript dəsti yazdım . O, öz dövründə kifayət qədər məşhur idi. Və orada çox fərqli vacib şeyləri, yalnız Linux-u deyil, həm də müxtəlif komponentləri izləmək mümkün idi.
İndi PostgreSQL üzərində işləyirəm. Artıq PostgreSQL statistikası ilə işləməyə imkan verən başqa bir şey yazıram. Bu adlanır (Habré haqqında məqalə - ).
Kiçik bir giriş qeydi. Müştərilərimizin, müştərilərimizin hansı vəziyyətləri var? Verilənlər bazası ilə bağlı bir növ qəza var. Və verilənlər bazası artıq bərpa olunanda, şöbə müdiri və ya inkişaf rəhbəri gəlib deyir: "Dostlar, biz məlumat bazasına nəzarət etməliyik, çünki pis bir şey baş verdi və gələcəkdə bunun qarşısını almalıyıq." Və burada verilənlər bazanıza - PostgreSQL, MySQL və ya digərlərinə nəzarət edə bilməniz üçün monitorinq sisteminin seçilməsi və ya mövcud monitorinq sisteminin uyğunlaşdırılması kimi maraqlı proses başlayır. Həmkarları isə təklif etməyə başlayırlar: “Eşitdim ki, filan məlumat bazası var. Gəlin istifadə edək”. Həmkarlar bir-biri ilə mübahisə etməyə başlayırlar. Və sonda məlum oldu ki, biz bir növ verilənlər bazası seçirik, lakin PostgreSQL monitorinqi orada olduqca zəif təqdim olunur və biz həmişə nəsə əlavə etməliyik. GitHub-dan bəzi depolar götürün, onları klonlayın, skriptləri uyğunlaşdırın və birtəhər onları fərdiləşdirin. Və sonda bir növ əl işi olur.
Buna görə də, bu çıxışda sizə təkcə PostgreSQL üçün deyil, həm də verilənlər bazası üçün monitorinqi necə seçmək barədə bəzi biliklər verməyə çalışacağam. Və sizə müəyyən fayda əldə etmək üçün monitorinqinizi başa çatdırmağa imkan verəcək biliklər verin ki, yarana biləcək hər hansı qarşıdan gələn fövqəladə halların qarşısını almaq üçün məlumat bazanıza fayda ilə nəzarət edə biləsiniz.
Və bu hesabatda olacaq ideyalar, istər DBMS, istərsə də noSQL olsun, birbaşa istənilən verilənlər bazasına uyğunlaşdırıla bilər. Buna görə də, təkcə PostgreSQL deyil, PostgreSQL-də bunu necə etmək barədə çoxlu reseptlər olacaq. PostgreSQL-in monitorinq üçün malik olduğu sorğuların nümunələri, obyektlərin nümunələri olacaq. Əgər sizin DBMS-də onları monitorinqə qoymağa imkan verən eyni şeylər varsa, siz də onları uyğunlaşdıra, əlavə edə bilərsiniz və bu, yaxşı olacaq.
Hesabatda olmayacağam
ölçüləri necə çatdırmaq və saxlamaq barədə danışın. Məlumatların sonrakı emal edilməsi və istifadəçiyə təqdim edilməsi haqqında heç nə deməyəcəyəm. Və xəbərdarlıq haqqında heç nə deməyəcəyəm.
Ancaq hekayə irəlilədikcə, mən mövcud monitorinqin müxtəlif skrinşotlarını göstərəcəyəm və birtəhər onları tənqid edəcəyəm. Amma buna baxmayaraq, çalışacağam ki, bu məhsullar üçün reklam və ya antireklam yaratmamaq üçün brendlərin adını çəkməyək. Buna görə də, bütün təsadüflər təsadüfi olur və sizin təsəvvürünüzə buraxılır.
Əvvəlcə monitorinqin nə olduğunu anlayaq. Monitorinq çox vacib bir şeydir. Bunu hamı başa düşür. Ancaq eyni zamanda, monitorinq biznes məhsuluna aid deyil və şirkətin mənfəətinə birbaşa təsir göstərmir, buna görə də həmişə qalıq əsasda monitorinq üçün vaxt ayrılır. Əgər vaxtımız varsa, monitorinq edirik, əgər vaxtımız yoxdursa, onda OK, onu geridə qoyacağıq və nə vaxtsa bu vəzifələrə qayıdacağıq.
Buna görə də, təcrübəmizdən, müştərilərə gəldikdə, monitorinq çox vaxt natamam olur və məlumat bazası ilə daha yaxşı iş görməmizə kömək edəcək heç bir maraqlı şey yoxdur. Və buna görə də monitorinq həmişə tamamlanmalıdır.
Verilənlər bazaları o qədər mürəkkəb şeylərdir ki, onlara da nəzarət etmək lazımdır, çünki verilənlər bazası məlumat anbarıdır. Və məlumat şirkət üçün çox vacibdir, onu heç bir şəkildə itirmək olmaz. Lakin eyni zamanda verilənlər bazaları çox mürəkkəb proqram parçalarıdır. Onlar çoxlu sayda komponentdən ibarətdir. Və bu komponentlərin çoxuna nəzarət etmək lazımdır.
Xüsusilə PostgreSQL-dən danışırıqsa, o zaman çoxlu sayda komponentdən ibarət sxem şəklində təqdim edilə bilər. Bu komponentlər bir-biri ilə qarşılıqlı təsir göstərir. Eyni zamanda, PostgreSQL-də Stats Collector adlanan alt sistem var ki, bu da bu altsistemlərin işləməsi haqqında statistik məlumatları toplamağa və idarəçi və ya istifadəçiyə bu statistikaya baxa bilməsi üçün bir növ interfeys təqdim etməyə imkan verir.
Bu statistikalar müəyyən funksiyalar və baxışlar toplusu şəklində təqdim olunur. Onları cədvəllər də adlandırmaq olar. Yəni, adi psql müştərisindən istifadə edərək verilənlər bazasına qoşula, bu funksiyalar və görünüşlər üzrə seçim edə və PostgreSQL alt sistemlərinin işləməsi ilə bağlı bəzi xüsusi nömrələr əldə edə bilərsiniz.
Siz bu nömrələri sevimli monitorinq sisteminizə əlavə edə, qrafiklər çəkə, funksiyalar əlavə edə və uzun müddətdə analitik əldə edə bilərsiniz.
Ancaq bu hesabatda bütün bu funksiyaları tam əhatə etməyəcəyəm, çünki bütün günü çəkə bilər. Mən sözün əsl mənasında iki, üç və ya dörd məsələyə toxunacağam və sizə onların monitorinqi yaxşılaşdırmağa necə kömək etdiyini söyləyəcəyəm.
Biz verilənlər bazası monitorinqi haqqında danışırıqsa, onda nəyə nəzarət etmək lazımdır? İlk növbədə, biz mövcudluğa nəzarət etməliyik, çünki verilənlər bazası müştərilərin məlumatlara çıxışını təmin edən xidmətdir və biz mövcudluğu izləməli, həmçinin onun bəzi keyfiyyət və kəmiyyət xüsusiyyətlərini təqdim etməliyik.
Biz həmçinin verilənlər bazamıza qoşulan müştərilərə nəzarət etməliyik, çünki onlar həm normal müştərilər, həm də verilənlər bazasına zərər verə biləcək zərərli müştərilər ola bilərlər. Onlara da nəzarət etmək və fəaliyyətlərini izləmək lazımdır.
Müştərilər verilənlər bazasına qoşulduqda, onların məlumatlarımızla işləməyə başladığı göz qabağındadır, ona görə də müştərilərin məlumatlarla necə işləməsinə nəzarət etməliyik: hansı cədvəllərlə və daha az dərəcədə, hansı indekslərlə. Yəni, müştərilərimiz tərəfindən yaradılan iş yükünü qiymətləndirməliyik.
Amma iş yükü də təbii ki, istəklərdən ibarətdir. Tətbiqlər verilənlər bazasına qoşulur, sorğulardan istifadə edərək məlumatlara daxil olur, ona görə də verilənlər bazasında hansı sorğularımız olduğunu qiymətləndirmək, onların adekvatlığına, əyri yazılmadığına, bəzi variantların yenidən yazılmalı və daha sürətli işləməsi üçün hazırlanmalı olduğuna nəzarət etmək vacibdir. və daha yaxşı performansla.
Biz verilənlər bazasından danışdığımız üçün verilənlər bazası həmişə fon prosesləridir. Fon prosesləri verilənlər bazası performansını yaxşı səviyyədə saxlamağa kömək edir, ona görə də onların işləməsi üçün müəyyən miqdarda resurs tələb olunur. Və eyni zamanda, onlar müştəri sorğusu resursları ilə üst-üstə düşə bilər, buna görə də acgöz fon prosesləri birbaşa müştəri sorğularının yerinə yetirilməsinə təsir göstərə bilər. Buna görə də, onları izləmək və izləmək lazımdır ki, fon prosesləri baxımından heç bir təhrif olmasın.
Və verilənlər bazası monitorinqi baxımından bütün bunlar sistem metrikasında qalır. Ancaq infrastrukturumuzun əksəriyyətinin buludlara keçdiyini nəzərə alsaq, fərdi hostun sistem göstəriciləri həmişə arxa plana keçir. Lakin verilənlər bazalarında onlar hələ də aktualdır və əlbəttə ki, sistem ölçülərini izləmək də lazımdır.
Sistem ölçüləri ilə hər şey az və ya çox gözəldir, bütün müasir monitorinq sistemləri artıq bu ölçüləri dəstəkləyir, lakin ümumiyyətlə, bəzi komponentlər hələ də kifayət deyil və bəzi şeyləri əlavə etmək lazımdır. Mən də onlara toxunacağam, onlar haqqında bir neçə slayd olacaq.
Planın birinci bəndi əlçatanlıqdır. Əlçatanlıq nədir? Anladığım qədər əlçatanlıq bazanın əlaqələrə xidmət göstərmək qabiliyyətidir, yəni baza qaldırılır, o, bir xidmət olaraq müştərilərdən bağlantıları qəbul edir. Və bu əlçatanlıq müəyyən xüsusiyyətlərlə qiymətləndirilə bilər. Bu xüsusiyyətləri tablosunda göstərmək çox rahatdır.
Tabloların nə olduğunu hər kəs bilir. Bu, lazımi məlumatların ümumiləşdirildiyi ekrana bir nəzər saldığınız zamandır. Və verilənlər bazasında problem olub-olmadığını dərhal müəyyən edə bilərsiniz.
Müvafiq olaraq, verilənlər bazasının mövcudluğu və digər əsas xüsusiyyətlər həmişə idarə panellərində göstərilməlidir ki, bu məlumat əlinizdə olsun və həmişə sizin üçün əlçatan olsun. Bəzi fövqəladə halların araşdırılması zamanı artıq insidentlərin araşdırılmasına kömək edən bəzi əlavə təfərrüatlar artıq ikinci dərəcəli idarə panellərində yerləşdirilməlidir və ya üçüncü tərəfin monitorinq sistemlərinə aparan qazma linklərində gizlənməlidir.
Tanınmış monitorinq sisteminin nümunəsi. Bu çox gözəl monitorinq sistemidir. O, çoxlu məlumat toplayır, amma mənim nöqteyi-nəzərimə görə, onun idarə panelləri haqqında qəribə bir anlayışı var. "İdarə paneli yaratmaq" üçün bir keçid var. Ancaq bir tablo yaratdığınız zaman iki sütunun siyahısını, qrafiklərin siyahısını yaradırsınız. Və bir şeyə baxmaq lazım olduqda, siçan ilə tıklamağa, sürüşməyə, istədiyiniz diaqramı axtarmağa başlayırsınız. Və bu vaxt tələb edir, yəni belə bir tablo yoxdur. Yalnız qrafiklərin siyahıları var.
Bu tablolara nə əlavə etməlisiniz? Cavab müddəti kimi bir xüsusiyyətlə başlaya bilərsiniz. PostgreSQL-də pg_stat_statements görünüşü var. Defolt olaraq qeyri-aktivdir, lakin həmişə aktiv edilməli və istifadə edilməli olan vacib sistem görünüşlərindən biridir. Verilənlər bazasında yerinə yetirilən bütün çalışan sorğular haqqında məlumatları saxlayır.
Müvafiq olaraq, ondan başlaya bilərik ki, biz bütün sorğuların ümumi icra müddətini götürə bilərik və yuxarıdakı sahələrdən istifadə edərək sorğuların sayına bölmək olar. Amma bu xəstəxanada orta temperaturdur. Biz digər sahələrdən başlaya bilərik - sorğunun minimum icra müddəti, maksimum və median. Və hətta faizlər də qura bilərik; PostgreSQL-in bunun üçün müvafiq funksiyaları var. Biz artıq tamamlanmış sorğular üçün verilənlər bazamızın cavab müddətini xarakterizə edən bəzi nömrələr əldə edə bilərik, yəni biz saxta sorğunu "1-i seçin" yerinə yetirmirik və cavab vaxtına baxırıq, lakin artıq tamamlanmış sorğular üçün cavab vaxtını təhlil edirik və çəkirik. ya ayrıca fiqur, ya da onun əsasında qrafik qururuq.
Hal-hazırda sistem tərəfindən yaradılan səhvlərin sayını izləmək də vacibdir. Bunun üçün pg_stat_database görünüşündən istifadə edə bilərsiniz. Biz xact_rollback sahəsinə diqqət yetiririk. Bu sahə verilənlər bazasında baş verən geri dönmələrin sayını göstərməklə yanaşı, xətaların sayını da nəzərə alır. Nisbətən desək, biz bu rəqəmi tablosumuzda göstərə və hazırda nə qədər səhvimiz olduğunu görə bilərik. Səhvlər çoxdursa, bu, qeydlərə baxmaq və onların hansı səhvlər olduğunu və niyə baş verdiyini görmək, sonra investisiya qoymaq və onları həll etmək üçün yaxşı bir səbəbdir.
Takometr kimi bir şey əlavə edə bilərsiniz. Bunlar saniyədə əməliyyatların sayı və saniyədə sorğuların sayıdır. Nisbətən desək, bu nömrələri verilənlər bazanızın cari performansı kimi istifadə edə və sorğularda piklərin, əməliyyatlarda piklərin olub olmadığını və ya əksinə, bəzi backendlər uğursuz olduğu üçün verilənlər bazasının yüklənmədiyini müşahidə edə bilərsiniz. Həmişə bu rəqəmə baxmaq və yadda saxlamaq lazımdır ki, layihəmiz üçün bu cür performans normaldır, lakin yuxarıda və aşağıda göstərilən dəyərlər artıq bir növ problemli və anlaşılmazdır, yəni bu rəqəmlərin niyə belə olduğuna baxmaq lazımdır. belə yüksək.
Əməliyyatların sayını təxmin etmək üçün yenidən pg_stat_database görünüşünə müraciət edə bilərik. Öhdəliklərin sayını və geri çəkilmələrin sayını əlavə edə və saniyədə əməliyyatların sayını əldə edə bilərik.
Hər kəs bir neçə sorğunun bir əməliyyata uyğun ola biləcəyini başa düşürmü? Buna görə TPS və QPS bir qədər fərqlidir.
Saniyədə sorğuların sayını pg_stat_statements-dən əldə etmək olar və sadəcə olaraq bütün tamamlanmış sorğuların cəmini hesablamaq olar. Aydındır ki, cari dəyəri əvvəlki ilə müqayisə edirik, onu çıxarırıq, deltanı alırıq və kəmiyyəti alırıq.
İstədiyiniz təqdirdə əlavə ölçülər əlavə edə bilərsiniz, bu da verilənlər bazamızın mövcudluğunu qiymətləndirməyə və hər hansı fasilələrin olub-olmamasına nəzarət etməyə kömək edir.
Bu göstəricilərdən biri iş vaxtıdır. Lakin PostgreSQL-də işləmə müddəti bir az çətin olur. Səbəbini deyəcəm. PostgreSQL işə salındıqda iş vaxtı hesabat verməyə başlayır. Ancaq bir anda, məsələn, gecə hansısa tapşırıq işləyirdisə, OOM-qatil gəlib PostgreSQL uşaq prosesini zorla dayandırıbsa, bu halda PostgreSQL bütün müştərilərin əlaqəsini dayandırır, parçalanmış yaddaş sahəsini sıfırlayır və bərpa etməyə başlayır. son keçid məntəqəsi. Yoxlama məntəqəsindən bu bərpa davam edərkən, verilənlər bazası əlaqələri qəbul etmir, yəni bu vəziyyət dayanma vaxtı kimi qiymətləndirilə bilər. Lakin iş vaxtı sayğacı sıfırlanmayacaq, çünki o, ilk andan postmasterin işə düşmə vaxtını nəzərə alır. Buna görə də, belə hallar atlana bilər.
Vakuum işçilərinin sayına da nəzarət etməlisiniz. PostgreSQL-də avtovakuumun nə olduğunu hamı bilirmi? Bu PostgreSQL-də maraqlı bir alt sistemdir. Onun haqqında çoxlu məqalələr yazılıb, çoxlu reportajlar hazırlanıb. Vakuum və onun necə işləməsi ilə bağlı çoxlu müzakirələr var. Çoxları bunu zəruri pislik hesab edir. Amma belədir. Bu, hər hansı bir əməliyyat üçün lazım olmayan sıraların köhnəlmiş versiyalarını təmizləyən və yeni cərgələr üçün cədvəllərdə və indekslərdə yer boşaldan bir növ zibil toplayıcının analoqudur.
Nə üçün ona nəzarət etmək lazımdır? Çünki vakuum bəzən çox ağrıyır. Böyük miqdarda resurs istehlak edir və nəticədə müştəri istəkləri əziyyət çəkməyə başlayır.
Və növbəti hissədə danışacağım pg_stat_activity görünüşü vasitəsilə izlənilməlidir. Bu görünüş verilənlər bazasındakı cari fəaliyyəti göstərir. Və bu fəaliyyət vasitəsilə biz hazırda işləyən vakuumların sayını izləyə bilərik. Biz vakuumları izləyə bilərik və görə bilərik ki, əgər həddi aşmışıqsa, bu, PostgreSQL parametrlərinə baxmaq və birtəhər vakuumun işini optimallaşdırmaq üçün bir səbəbdir.
PostgreSQL haqqında başqa bir şey PostgreSQL-in uzun əməliyyatlardan çox xəstə olmasıdır. Xüsusən də uzun müddət dayanan və heç nə etməyən əməliyyatlardan. Bu, əməliyyat zamanı statistik boşluq adlanır. Belə bir əməliyyat kilidləri saxlayır və vakuumun işləməsinə mane olur. Və nəticədə masalar şişir və ölçüləri artır. Və bu cədvəllərlə işləyən sorğular daha yavaş işləməyə başlayır, çünki cərgələrin bütün köhnə versiyalarını yaddaşdan diskə və arxaya kürəkləmək lazımdır. Bu səbəbdən ən uzun əməliyyatların müddəti, müddəti, ən uzun vakuum tələblərinin də izlənilməsi lazımdır. Çox uzun müddətdir ki, bir OLTP yükü üçün artıq 10-20-30 dəqiqədən çox davam edən bəzi prosesləri görsək, onlara diqqət yetirməli və onları zorla dayandırmalı və ya tətbiqi optimallaşdırmalıyıq ki, onlar çağırılmır və bu qədər uzun müddət asmayın. Analitik iş yükü üçün 10-20-30 dəqiqə normaldır, daha uzunları da var.
Sonra bağlı müştərilərlə seçimimiz var. Artıq tablosunu yaratdıqda və orada əsas əlçatanlıq göstəricilərini yerləşdirdikdə, orada qoşulmuş müştərilər haqqında əlavə məlumat da əlavə edə bilərik.
Əlaqədar müştərilər haqqında məlumat vacibdir, çünki PostgreSQL nöqteyi-nəzərindən müştərilər fərqlidir. Yaxşı müştərilər var, pis müştərilər də var.
Sadə bir misal. Müştəri ilə mən tətbiqi başa düşürəm. Tətbiq verilənlər bazasına qoşuldu və dərhal öz sorğularını ora göndərməyə başlayır, verilənlər bazası onları emal edir və icra edir və nəticələri müştəriyə qaytarır. Bunlar yaxşı və düzgün müştərilərdir.
Müştərinin qoşulduğu vəziyyətlər var, o, əlaqəni saxlayır, lakin heç nə etmir. Boş vəziyyətdədir.
Amma pis müştərilər var. Məsələn, eyni müştəri qoşuldu, əməliyyat açdı, verilənlər bazasında bir şey etdi və sonra koda girdi, məsələn, xarici mənbəyə daxil olmaq və ya orada alınan məlumatları emal etmək üçün. Lakin o, əməliyyatı bağlamadı. Və əməliyyat verilənlər bazasında asılır və xətt üzrə kiliddə saxlanılır. Bu pis vəziyyətdir. Və birdən-birə özündə bir yerdə bir tətbiq istisna olmaqla uğursuz olarsa, əməliyyat çox uzun müddət açıq qala bilər. Və bu birbaşa PostgreSQL performansına təsir edir. PostgreSQL daha yavaş olacaq. Buna görə də, belə müştəriləri vaxtında izləmək və onların işini zorla dayandırmaq vacibdir. Və belə halların baş verməməsi üçün tətbiqinizi optimallaşdırmalısınız.
Digər pis müştərilər müştəriləri gözləyir. Ancaq vəziyyətə görə pis olurlar. Məsələn, sadə bir boş əməliyyat: bir əməliyyat aça bilər, bəzi sətirlərdə kilidlər götürə bilər, sonra kodun bir yerində asılmış əməliyyatı tərk edərək uğursuz olacaq. Başqa bir müştəri gəlib eyni məlumatları tələb edəcək, lakin o, kilidlə qarşılaşacaq, çünki həmin asma əməliyyat artıq bəzi tələb olunan sıralarda kilidləri saxlayır. İkinci əməliyyat isə ilk əməliyyatın administrator tərəfindən tamamlanmasını və ya onu zorla bağlamasını gözləyəcək. Buna görə də, gözlənilən əməliyyatlar verilənlər bazası bağlantısı limitini toplaya və doldura bilər. Limit dolduqda isə proqram artıq verilənlər bazası ilə işləyə bilməz. Bu, artıq layihə üçün fövqəladə vəziyyətdir. Buna görə də pis müştəriləri izləmək və onlara vaxtında cavab vermək lazımdır.
Monitorinqin başqa bir nümunəsi. Və burada artıq layiqli bir idarə paneli var. Yuxarıda əlaqələr haqqında məlumat var. DB bağlantısı - 8 ədəd. Və hamısı budur. Hansı müştərilərin aktiv olması, hansının boş qalması, heç nə etməməsi barədə məlumatımız yoxdur. Gözləyən əməliyyatlar və gözləyən bağlantılar haqqında məlumat yoxdur, yəni bu, bağlantıların sayını göstərən rəqəmdir və bu qədərdir. Və sonra özünüz üçün təxmin edin.
Müvafiq olaraq, bu məlumatı monitorinqə əlavə etmək üçün pg_stat_activity sistem görünüşünə daxil olmalısınız. PostgreSQL-də çox vaxt keçirirsinizsə, bu, sizin dostunuza çevrilməli olan çox yaxşı bir görünüşdür, çünki PostgreSQL-də mövcud fəaliyyəti, yəni orada baş verənləri göstərir. Hər bir proses üçün bu proses haqqında məlumatları göstərən ayrıca sətir var: əlaqə hansı hostdan edilib, hansı istifadəçi altında, hansı adla, əməliyyat nə vaxt başlayıb, hazırda hansı sorğu işləyir, hansı sorğu sonuncu dəfə icra olunub. Və buna uyğun olaraq, stat sahəsindən istifadə edərək müştərinin vəziyyətini qiymətləndirə bilərik. Nisbətən desək, biz bu sahəyə görə qruplaşdıra və hazırda verilənlər bazasında olan statistik göstəriciləri və verilənlər bazasında bu statistikaya malik olan bağlantıların sayını əldə edə bilərik. Biz isə artıq alınmış rəqəmləri monitorinqimizə göndərə və onların əsasında qrafiklər çəkə bilərik.
Əməliyyatın müddətini qiymətləndirmək də vacibdir. Artıq dedim ki, vakuumların müddətini qiymətləndirmək vacibdir, lakin əməliyyatlar eyni şəkildə qiymətləndirilir. Xact_start və query_start sahələri var. Onlar, nisbətən desək, əməliyyatın başlama vaxtını və sorğunun başlama vaxtını göstərirlər. Cari vaxt damğasını göstərən now() funksiyasını götürürük və əməliyyat və sorğu vaxt damğasını çıxırıq. Və əməliyyatın müddətini, sorğunun müddətini alırıq.
Əgər uzun əməliyyatlar görsək, onları artıq tamamlamalıyıq. OLTP yükü üçün uzun əməliyyatlar artıq 1-2-3 dəqiqədən çoxdur. OLAP iş yükü üçün uzun əməliyyatlar normaldır, lakin onların başa çatdırılması iki saatdan çox vaxt aparırsa, bu həm də bir yerdə əyriliyimizə işarədir.
Müştərilər verilənlər bazasına qoşulduqdan sonra məlumatlarımızla işləməyə başlayırlar. Onlar cədvəllərə daxil olurlar, cədvəldən məlumat almaq üçün indekslərə daxil olurlar. Müştərilərin bu məlumatlarla necə qarşılıqlı əlaqədə olduğunu qiymətləndirmək vacibdir.
Bu, iş yükümüzü qiymətləndirmək və hansı cədvəllərin bizim üçün "ən isti" olduğunu anlamaq üçün lazımdır. Məsələn, bu, bir növ sürətli SSD yaddaşında "isti" masalar yerləşdirmək istədiyimiz vəziyyətlərdə lazımdır. Məsələn, uzun müddət istifadə etmədiyimiz bəzi arxiv cədvəlləri bir növ "soyuq" arxivə, SATA disklərinə köçürülə və orada yaşamasına icazə verilə bilər, lazım olduqda onlara daxil olacaqlar.
Bu, hər hansı buraxılış və yerləşdirmədən sonra anomaliyaları aşkar etmək üçün də faydalıdır. Deyək ki, layihə bəzi yeni xüsusiyyətlər buraxdı. Məsələn, verilənlər bazası ilə işləmək üçün yeni funksionallıq əlavə etdik. Və cədvəldən istifadə qrafiklərini tərtib etsək, bu qrafiklərdə bu anomaliyaları asanlıqla aşkar edə bilərik. Məsələn, partlayışları yeniləyin və ya partlayışları silin. Çox görünən olacaq.
Siz həmçinin “üzən” statistikada anomaliyaları aşkar edə bilərsiniz. Bunun mənası nədi? PostgreSQL çox güclü və çox yaxşı sorğu planlaşdırıcısına malikdir. Və tərtibatçılar onun inkişafına çox vaxt ayırırlar. O necə işləyir? Yaxşı planlar hazırlamaq üçün PostgreSQL cədvəllərdə verilənlərin müəyyən vaxt intervalında və müəyyən tezlikdə paylanmasına dair statistik məlumatlar toplayır. Bunlar ən ümumi dəyərlərdir: unikal dəyərlərin sayı, cədvəldə NULL haqqında məlumat, çoxlu məlumat.
Bu statistika əsasında planlaşdırıcı bir neçə sorğu qurur, ən optimalını seçir və sorğunun özünü yerinə yetirmək və məlumatları qaytarmaq üçün bu sorğu planından istifadə edir.
Və elə olur ki, statistika “üzər”. Cədvəldə keyfiyyət və kəmiyyət məlumatları birtəhər dəyişdi, lakin statistika toplanmadı. Və formalaşan planlar optimal olmaya bilər. Və əgər bizim planlarımız toplanmış monitorinqlər əsasında, cədvəllər əsasında qeyri-optimal olsa, biz bu anomaliyaları görə biləcəyik. Məsələn, haradasa məlumatlar keyfiyyətcə dəyişdi və indeks əvəzinə cədvəldən ardıcıl keçid istifadə olunmağa başladı, yəni. əgər sorğu yalnız 100 sətir qaytarmalıdırsa (100-ə qədər limit var), onda bu sorğu üçün tam axtarış aparılacaq. Və bu həmişə performansa çox pis təsir edir.
Biz bunu monitorinqdə görə bilərik. Artıq bu sorğuya baxın, bunun üçün izahat verin, statistika toplayın, yeni əlavə indeks yaradın. Və artıq bu problemə cavab verin. Buna görə də vacibdir.
Monitorinqin başqa bir nümunəsi. Düşünürəm ki, o, çox məşhur olduğu üçün çoxları onu tanıyıb. Kim öz layihələrində istifadə edir ? Bu məhsulu Prometey ilə birlikdə kim istifadə edir? Fakt budur ki, bu monitorinqin standart deposunda PostgreSQL ilə işləmək üçün bir tablo var - Prometey. Ancaq bir pis detal var.
Bir neçə qrafik var. Və baytlar birlik kimi göstərilir, yəni 5 qrafik var. Bunlar Məlumat daxil et, Məlumatı yenilə, Məlumatı sil, Məlumatı götür və Məlumatı qaytar. Ölçmə vahidi baytdır. Ancaq iş ondadır ki, PostgreSQL-də statistika məlumatları sətirlərdə (sətirlərdə) qaytarır. Və buna uyğun olaraq, bu qrafiklər iş yükünüzü bir neçə dəfə, onlarla dəfə azaltmaq üçün çox yaxşı bir yoldur, çünki bir kortej bayt deyil, bir sətir sətirdir, çox baytdır və həmişə dəyişən uzunluqdadır. Yəni, kortejlərdən istifadə edərək baytlarda iş yükünün hesablanması qeyri-real işdir və ya çox çətindir. Buna görə də, tablosundan və ya daxili monitorinqdən istifadə etdiyiniz zaman onun düzgün işlədiyini və düzgün qiymətləndirilmiş məlumatları sizə qaytardığını başa düşmək həmişə vacibdir.
Bu cədvəllər üzrə statistikanı necə əldə etmək olar? Bu məqsədlə PostgreSQL-də müəyyən baxış ailəsi var. Və əsas baxış budur . User_tables - bu istifadəçi adından yaradılmış cədvəllər deməkdir. Bunun əksinə olaraq PostgreSQL-in özü tərəfindən istifadə olunan sistem görünüşləri var. Həm sistem, həm də istifadəçi olanları əhatə edən Alltables xülasə cədvəli var. Onlardan ən çox bəyəndiyiniz hər hansı birindən başlaya bilərsiniz.
Yuxarıdakı sahələrdən istifadə edərək siz əlavələrin, yeniləmələrin və silinmələrin sayını təxmin edə bilərsiniz. İstifadə etdiyim tablosunun nümunəsi iş yükünün xüsusiyyətlərini qiymətləndirmək üçün bu sahələrdən istifadə edir. Ona görə də biz də onların üzərində qura bilərik. Ancaq xatırlamağa dəyər ki, bunlar bayt deyil, tuplelərdir, ona görə də biz bunu baytlarda edə bilmərik.
Bu məlumatlara əsaslanaraq biz TopN adlanan cədvəllər qura bilərik. Məsələn, Top-5, Top-10. Və başqalarından daha çox təkrar emal edilən isti masaları izləyə bilərsiniz. Məsələn, daxil etmək üçün 5 "isti" masa. Və bu TopN cədvəllərindən istifadə edərək biz iş yükümüzü qiymətləndiririk və hər hansı buraxılış, yeniləmə və yerləşdirmədən sonra iş yükünün partlamasını qiymətləndirə bilərik.
Cədvəlin ölçüsünü qiymətləndirmək də vacibdir, çünki bəzən tərtibatçılar yeni bir xüsusiyyət təqdim edirlər və cədvəllərimiz böyük ölçülərdə şişməyə başlayır, çünki onlar əlavə məlumat əlavə etmək qərarına gəldilər, lakin bunun necə olacağını təxmin etmədilər. verilənlər bazasının ölçüsünə təsir edir. Belə hallar bizim üçün də sürpriz olur.
İndi isə sizə kiçik bir sual. Verilənlər bazası serverinizdə yük olduğunu görəndə hansı sual yaranır? Növbəti sualınız nədir?
Amma əslində sual belə çıxır. Yük hansı sorğulara səbəb olur? Yəni yükün yaratdığı proseslərə baxmaq maraqlı deyil. Aydındır ki, əgər hostun verilənlər bazası varsa, onda verilənlər bazası orada işləyir və orada yalnız verilənlər bazalarının utilizasiya ediləcəyi aydındır. Topu açsaq, orada PostgreSQL-də nəsə edən proseslərin siyahısını görəcəyik. Onların nə etdikləri Topdan aydın olmayacaq.
Müvafiq olaraq, siz ən yüksək yükə səbəb olan sorğuları tapmalısınız, çünki tənzimləmə sorğuları, bir qayda olaraq, PostgreSQL və ya əməliyyat sistemi konfiqurasiyasını tənzimləməkdən, hətta aparatı tənzimləməkdən daha çox qazanc verir. Mənim təxminlərimə görə, bu, təxminən 80-85-90% təşkil edir. Və bu, daha sürətli edilir. Sorğunu düzəltmək konfiqurasiyanı düzəltməkdən, yenidən işə salmağı planlaşdırmaqdan, xüsusən də verilənlər bazası yenidən işə salına bilmirsə və ya avadanlıq əlavə etməkdən daha sürətlidir. Bu sorğudan daha yaxşı nəticə əldə etmək üçün sorğunu haradasa yenidən yazmaq və ya indeks əlavə etmək daha asandır.
Müvafiq olaraq, müraciətlərə və onların adekvatlığına nəzarət etmək lazımdır. Monitorinqlə bağlı başqa bir nümunə götürək. Burada da, deyəsən, əla monitorinq var. Replikasiya haqqında məlumat var, ötürmə qabiliyyəti, bloklama, resursdan istifadə haqqında məlumat var. Hər şey qaydasındadır, lakin müraciətlər barədə məlumat yoxdur. Verilənlər bazamızda hansı sorğuların işlədiyi, nə qədər müddət işlədiyi, bu sorğuların neçəsi olduğu aydın deyil. Monitorinqimizdə bu məlumat həmişə olmalıdır.
Və bu məlumatı əldə etmək üçün pg_stat_statements modulundan istifadə edə bilərik. Bunun əsasında müxtəlif qrafiklər qura bilərsiniz. Məsələn, ən çox görülən sorğular, yəni ən çox yerinə yetirilən sorğular haqqında məlumat əldə edə bilərsiniz. Bəli, yerləşdirmədən sonra ona baxmaq və sorğularda hər hansı bir artım olub olmadığını anlamaq da çox faydalıdır.
Siz ən uzun sorğuları, yəni tamamlanması ən uzun çəkən sorğuları izləyə bilərsiniz. Onlar prosessorda işləyirlər, I/O istehlak edirlər. Bunu total_time, mean_time, blk_write_time və blk_read_time sahələrindən istifadə etməklə də qiymətləndirə bilərik.
Resurs istifadəsi baxımından ən ağır sorğuları, diskdən oxuyanları, yaddaşla işləyənləri və ya əksinə, bir növ yazı yükü yarada bilənləri qiymətləndirə və nəzarət edə bilərik.
Ən səxavətli istəkləri qiymətləndirə bilərik. Bunlar çoxlu sayda sətir qaytaran sorğulardır. Məsələn, bu, limit təyin etməyi unutduqları bəzi sorğu ola bilər. Və sadəcə olaraq sorğulanan cədvəllər üzrə cədvəlin və ya sorğunun bütün məzmununu qaytarır.
Siz həmçinin müvəqqəti fayllardan və ya müvəqqəti cədvəllərdən istifadə edən sorğulara nəzarət edə bilərsiniz.
Və bizdə hələ də fon prosesləri var. Fon prosesləri ilk növbədə nəzarət nöqtələridir və ya onlara nəzarət nöqtələri də deyilir, bunlar avtovakuum və təkrarlamadır.
Monitorinqin başqa bir nümunəsi. Solda Baxım nişanı var, ona gedin və faydalı bir şey görəcəyinizə ümid edin. Ancaq burada yalnız vakuum əməliyyatı və statistika toplama vaxtıdır, başqa heç nə yoxdur. Bu, çox zəif məlumatdır, ona görə də bizim verilənlər bazamızda fon prosesləri necə işlədiyi və onların işində hər hansı problemin olub-olmaması haqqında məlumat həmişə olmalıdır.
Yoxlama məntəqələrinə baxdığımız zaman yadda saxlamalıyıq ki, yoxlama məntəqələri kirli səhifələri parçalanmış yaddaş sahəsindən diskə təmizləyir, sonra isə yoxlama nöqtəsi yaradır. Və PostgreSQL fövqəladə vəziyyətdə qəflətən dayandırılıbsa, bu keçid məntəqəsi bərpa üçün yer kimi istifadə edilə bilər.
Müvafiq olaraq, bütün "çirkli" səhifələri diskə silmək üçün müəyyən miqdarda yazmaq lazımdır. Və, bir qayda olaraq, böyük həcmdə yaddaşa malik sistemlərdə bu, çoxdur. Qısa bir aralıqda çox tez-tez yoxlama nöqtələri etsək, disk performansı çox əhəmiyyətli dərəcədə azalacaq. Və müştəri istəkləri resurs çatışmazlığından əziyyət çəkəcək. Onlar resurs uğrunda yarışacaq və məhsuldarlıqdan məhrum olacaqlar.
Müvafiq olaraq, göstərilən sahələrdən istifadə edərək pg_stat_bgwriter vasitəsilə biz baş verən yoxlama məntəqələrinin sayını izləyə bilərik. Müəyyən bir müddət ərzində (10-15-20 dəqiqə, yarım saat ərzində), məsələn, 3-4-5-də çoxlu keçid məntəqələrimiz varsa, bu, artıq problem ola bilər. Və artıq verilənlər bazasına baxmaq, konfiqurasiyaya baxmaq lazımdır, bu qədər çox sayda yoxlama məntəqəsinə nə səbəb olur. Ola bilsin ki, hansısa böyük səsyazma gedir. Artıq iş yükünü qiymətləndirə bilərik, çünki biz artıq iş yükü qrafiklərini əlavə etmişik. Biz artıq yoxlama nöqtəsi parametrlərini düzəldə bilərik və onların sorğu performansına çox təsir etmədiyinə əmin ola bilərik.
Mən yenidən avtovakuuma qayıdıram, çünki dediyim kimi, həm disk, həm də sorğu performansını asanlıqla birləşdirə bilən bir şeydir, ona görə də avtovakuumun miqdarını qiymətləndirmək həmişə vacibdir.
Verilənlər bazasında avtovakuum işçilərinin sayı məhduddur. Varsayılan olaraq, bunlardan üçü var, buna görə də verilənlər bazasında həmişə üç işçimiz varsa, bu o deməkdir ki, bizim avtovakuum konfiqurasiya edilməyib, biz limitləri yüksəltməli, avtovakuum parametrlərinə yenidən baxmalı və konfiqurasiyaya daxil olmalıyıq.
Hansı vakuum işçilərimizin olduğunu qiymətləndirmək vacibdir. Ya istifadəçi tərəfindən işə salındı, DBA gəldi və əl ilə bir növ vakuum işə saldı və bu, bir yük yaratdı. Bir növ problemimiz var. Və ya bu, əməliyyat sayğacını açan vakuumların sayıdır. PostgreSQL-in bəzi versiyaları üçün bunlar çox ağır vakuumlardır. Və onlar asanlıqla performansı əlavə edə bilərlər, çünki onlar bütün cədvəli oxuyurlar, həmin cədvəldəki bütün blokları skan edirlər.
Və təbii ki, vakuumların müddəti. Əgər çox uzun müddət işləyən uzunmüddətli vakuumlarımız varsa, bu o deməkdir ki, biz yenidən vakuum konfiqurasiyasına diqqət yetirməliyik və bəlkə də onun parametrlərinə yenidən baxmalıyıq. Çünki vakuum masa üzərində uzun müddət (3-4 saat) işlədikdə vəziyyət yarana bilər, lakin vakuumun işlədiyi müddət ərzində yenidən masada çoxlu sayda ölü cərgələr yığılmağa müvəffəq olub. Və vakuum tamamlanan kimi o, yenidən bu masanı tozsoran etməlidir. Və biz bir vəziyyətə gəlirik - sonsuz bir vakuum. Və bu vəziyyətdə, vakuum öz işinin öhdəsindən gəlmir və içindəki faydalı məlumatların həcmi eyni qalmasına baxmayaraq, cədvəllər tədricən ölçüdə şişməyə başlayır. Buna görə də, uzun vakuumlar zamanı biz həmişə konfiqurasiyaya baxırıq və onu optimallaşdırmağa çalışırıq, eyni zamanda müştəri sorğularının yerinə yetirilməsi zərər görməsin.
Hazırda axın replikasiyası olmayan PostgreSQL quraşdırması praktiki olaraq yoxdur. Replikasiya məlumatların masterdən replikaya köçürülməsi prosesidir.
PostgreSQL-də təkrarlama əməliyyat jurnalı vasitəsilə həyata keçirilir. Sehrbaz əməliyyat jurnalını yaradır. Tranzaksiya jurnalı şəbəkə bağlantısı üzərindən replikaya keçir və sonra o, replikada təkrarlanır. Bu sadədir.
Müvafiq olaraq, pg_stat_replication görünüşü replikasiya gecikməsinə nəzarət etmək üçün istifadə olunur. Ancaq onunla hər şey sadə deyil. 10-cu versiyada görünüş bir neçə dəyişikliyə məruz qalıb. Birincisi, bəzi sahələrin adı dəyişdirilib. Və bəzi sahələr əlavə edildi. 10-cu versiyada təkrarlama gecikməsini saniyələrlə qiymətləndirməyə imkan verən sahələr meydana çıxdı. Çox rahatdır. 10-cu versiyadan əvvəl təkrarlama gecikməsini baytlarla qiymətləndirmək mümkün idi. Bu seçim 10-cu versiyada qalır, yəni sizin üçün daha əlverişli olanı seçə bilərsiniz - gecikməni baytlarda qiymətləndirin və ya gecikməni saniyələrlə qiymətləndirin. Bir çox insan hər ikisini edir.
Ancaq buna baxmayaraq, təkrarlama gecikməsini qiymətləndirmək üçün əməliyyatda logun mövqeyini bilməlisiniz. Və bu əməliyyat jurnalı mövqeləri tam olaraq pg_stat_replication görünüşündədir. Nisbətən desək, pg_xlog_location_diff() funksiyasından istifadə edərək əməliyyat jurnalında iki nöqtə götürə bilərik. Aralarındakı deltanı hesablayın və təkrarlama gecikməsini baytlarla əldə edin. Çox rahat və sadədir.
10-cu versiyada bu funksiyanın adı pg_wal_lsn_diff() olaraq dəyişdirildi. Ümumiyyətlə, "xlog" sözünün tapıldığı bütün funksiyalarda, görünüşlərdə və köməkçi proqramlarda "wal" dəyəri ilə əvəz edilmişdir. Bu həm görünüşlərə, həm də funksiyalara aiddir. Bu belə bir yenilikdir.
Üstəlik, 10-cu versiyada gecikməni göstərən xətlər əlavə edildi. Bunlar yazma lag, flush lag, replay lag. Yəni bu işlərə nəzarət etmək vacibdir. Əgər bizdə replikasiya gecikməsi olduğunu görsək, o zaman bunun niyə yarandığını, haradan gəldiyini araşdırıb problemi həll etməliyik.
Sistem ölçüləri ilə demək olar ki, hər şey qaydasındadır. Hər hansı bir monitorinq başlayanda sistem ölçüləri ilə başlayır. Bu prosessorların, yaddaşın, svopun, şəbəkənin və diskin xaric edilməsidir. Ancaq bir çox parametrlər standart olaraq orada deyil.
Əgər təkrar emal prosesində hər şey qaydasındadırsa, o zaman diskin təkrar emalı ilə bağlı problemlər var. Bir qayda olaraq, monitorinq tərtibatçıları ötürmə qabiliyyəti haqqında məlumat əlavə edirlər. İop və ya baytda ola bilər. Lakin onlar gecikmə və disk cihazlarının istifadəsini unudurlar. Bunlar disklərimizin nə qədər yükləndiyini və nə qədər yavaş olduğunu qiymətləndirməyə imkan verən daha vacib parametrlərdir. Əgər yüksək gecikməmiz varsa, bu o deməkdir ki, disklərdə bəzi problemlər var. Yüksək istifadəmiz varsa, bu, disklərin öhdəsindən gəlmədiyini göstərir. Bunlar ötürmə qabiliyyətindən daha yaxşı xüsusiyyətlərdir.
Üstəlik, bu statistikanı təkrar emal prosessorlarında olduğu kimi /proc fayl sistemindən də əldə etmək olar. Bu məlumatın niyə monitorinqə əlavə edilmədiyini bilmirəm. Ancaq buna baxmayaraq, monitorinqinizdə bunun olması vacibdir.
Eyni şey şəbəkə interfeyslərinə də aiddir. Paketlərdə, baytlarda şəbəkə ötürmə qabiliyyəti haqqında məlumat var, lakin buna baxmayaraq, gecikmə haqqında məlumat yoxdur və istifadə haqqında məlumat yoxdur, baxmayaraq ki, bu da faydalı məlumatdır.
İstənilən monitorinqin çatışmazlıqları var. Hansı növ monitorinq aparmağınızdan asılı olmayaraq, o, həmişə bəzi meyarlara cavab verməyəcək. Ancaq buna baxmayaraq, onlar inkişaf edir, yeni xüsusiyyətlər və yeni şeylər əlavə olunur, ona görə də bir şey seçin və onu bitirin.
Və başa çatdırmaq üçün həmişə təqdim olunan statistikanın nə demək olduğu və problemləri həll etmək üçün onlardan necə istifadə edə biləcəyiniz barədə bir fikrə sahib olmalısınız.
Və bir neçə əsas məqam:
- Siz həmişə əlçatanlığa nəzarət etməli və idarə panellərinə sahib olmalısınız ki, verilənlər bazası ilə hər şeyin qaydasında olduğunu tez qiymətləndirə biləsiniz.
- Pis müştəriləri silmək və onları məhv etmək üçün həmişə verilənlər bazanızla hansı müştərilərin işlədiyi barədə bir fikrə sahib olmalısınız.
- Bu müştərilərin məlumatlarla necə işlədiyini qiymətləndirmək vacibdir. İş yükünüz haqqında təsəvvürünüz olmalıdır.
- Bu iş yükünün necə formalaşdığını, hansı sorğuların köməyi ilə qiymətləndirilməsi vacibdir. Siz sorğuları qiymətləndirə, onları optimallaşdıra, refaktor edə, onlar üçün indekslər yarada bilərsiniz. Bu çox vacibdir.
- Fon prosesləri müştəri sorğularına mənfi təsir göstərə bilər, ona görə də onların həddən artıq çox resurs istifadə etməməsinə nəzarət etmək vacibdir.
- Sistem ölçüləri sizə serverlərinizin miqyasını artırmaq və tutumunu artırmaq üçün planlar qurmağa imkan verir, buna görə də onları izləmək və qiymətləndirmək vacibdir.
Əgər bu mövzu ilə maraqlanırsınızsa, o zaman bu linkləri izləyə bilərsiniz.
- bu, statistika toplayıcısının rəsmi sənədləridir. Bütün statistik baxışların təsviri və bütün sahələrin təsviri var. Onları oxuya, anlaya və təhlil edə bilərsiniz. Və onlara əsaslanaraq, qrafiklərinizi qurun və monitorinqinizə əlavə edin.
Nümunə müraciətlər:
Bu, bizim və mənim korporativ depomuzdur. Onlar nümunə sorğuları ehtiva edir. Orada seriyadan* seçmə sorğusu yoxdur. Xam nömrələri oxunaqlı, rahat dəyərlərə çevirməyə imkan verən maraqlı funksiyalardan istifadə edərək artıq birləşmələrlə hazır sorğular var, yəni bunlar bayt, vaxtdır. Siz onları götürə, baxa, təhlil edə, monitorinqinizə əlavə edə, monitorinqinizi onların əsasında qura bilərsiniz.
Suallar
Sual: Brendləri reklam etməyəcəyinizi dediniz, amma mənə hələ də maraqlıdır - layihələrinizdə hansı idarə panellərindən istifadə edirsiniz?
Cavab: Fərqli olur. Elə olur ki, müştəriyə gəlirik və onun artıq öz monitorinqi var. Və biz müştəriyə onların monitorinqinə nə əlavə edilməli olduğunu məsləhət görürük. Ən pis vəziyyət Zabbix ilə bağlıdır. Çünki onun TopN qrafiklərini qurmaq qabiliyyəti yoxdur. Özümüz istifadə edirik , çünki biz monitorinqlə bağlı bu uşaqlarla məsləhətləşirdik. Texniki xüsusiyyətlərimiz əsasında PostgreSQL-ə nəzarət etdilər. Mən Prometey vasitəsilə məlumat toplayan və onu təqdim edən öz pet-layihəmi yazıram . Mənim vəzifəm Prometeydə öz ixracatçımı yaratmaq və sonra hər şeyi Grafana-da göstərməkdir.
Sual: AWR hesabatlarının analoqları və ya... toplama varmı? Belə bir şey haqqında məlumatınız varmı?
Cavab: Bəli, mən AWR-nin nə olduğunu bilirəm, gözəl şeydir. Hal-hazırda təxminən aşağıdakı modeli həyata keçirən müxtəlif velosipedlər var. Müəyyən vaxt intervalında bəzi əsas xətlər eyni PostgreSQL-ə və ya ayrıca yaddaşa yazılır. Onları internetdə google-da axtara bilərsiniz, onlar oradadır. Belə bir şeyin tərtibatçılarından biri PostgreSQL mövzusunda sql.ru forumunda oturur. Onu orada tuta bilərsiniz. Bəli, belə şeylər var, onlardan istifadə etmək olar. Üstəlik onun içində Mən də eyni şeyi etməyə imkan verən bir şey yazıram.
PS1 Əgər postgres_exporter istifadə edirsinizsə, hansı idarə panelindən istifadə edirsiniz? Onlardan bir neçəsi var. Onlar artıq köhnəlib. Bəlkə icma yenilənmiş şablon yaradacaq?
PS2 pganalyze silindi, çünki bu, performans monitorinqi və avtomatlaşdırılmış tənzimləmə təkliflərinə yönəlmiş xüsusi SaaS təklifidir.
Sorğuda yalnız qeydiyyatdan keçmiş istifadəçilər iştirak edə bilər. xahiş edirəm.
Hansı öz-özünə yerləşdirilən postgresql monitorinqini (iş paneli ilə) ən yaxşı hesab edirsiniz?
-
30,0%Zabbix + Aleksey Lesovskidə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 özəl SaaS-dir - onu 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 verib. 26 istifadəçi bitərəf qalıb.
Mənbə: www.habr.com