pgBadger ile PostgreSQL Log Analizi
Bu yazıda yeni araştırmaya başladığım pgBadger aracını anlatmaya çalışacağım. Ön gereksinimler, pgBadger nedir-nasıl kullanılır kısmı, son olarak da log analiz çıktısının ekran görüntüleri üzerinden kısaca açıklamaya çalışacağım.
Ön Gereksinimler
TL;DR; Checkpoint, transactionların belirli aralıklarla diske yazılması işlemidir. WAL başarılı transaction loglarının tutulduğu ve veri bütünlüğünün sağlanmasına yarayan dosyalardır. Vacuum PostgreSQL’de garbage collection işlemine olanak sağlayan yapıdır.
İlk olarak PostgreSQL’de transactionlar nasıl gerçekleşiyor anlatmaya çalışacağım. PostgreSQL’e RAM’de bir alan ayrılır ve bu alan üzerinde çalışır. Kayıtlarda yapılan işlemler bu RAM üzerinde yapılır.
Sorguların çalışması (execution) için kullanılan hafıza birimi ise work_mem olarak adlandırılır ve 4 mb boyutundadır. Basit sorgularımız bu alan üzerinde RAM’ de çalıştırılır. Eğer sorgumuz karmaşık ise bu alan yeterli kalmayacak ve bu durumda diskte temp file oluşacak ve sorgu bu temp file üzerinde çalışacaktır. Karmaşık sorgularımızın yavaş çalışmasının nedeni de temp file’ların oluşması ve diskte çalışması ile alakalıdır. Sonuç olarak temp file’lar performans kaybına neden olmaktadır.
WAL (Write-Ahead Logging) data bütünlüğü sağlanma standardıdır. Veri değişikliği loglar diske yazıldıktan sonra gerçekleşir. (WAL= Transaction Log’u, 16 mb). Belirli bir checkpoint_timeout’ a kadar transactionlardaki veri değişim logları, commit edilmeden hemen önce wal(xlog) dosyalarına(diske) yazılır. Böylece her bir başarılı transaction commitinden sonra diske yazmak yerine belirli checkpoint işlemine göre diske yazılır. Ayrıca diske yazıldıktan sonra da WAL dosyası tekrar kullanılmak üzere temizlenir.
Başarılı transactionlar checkpoint işlemine göre toplu olarak işletilerek memory’den diske yazılır.
Transaction commitlerin logları (commit bilgisi) da clog’a commit işleminden hemen sonra diske yazılır. Bu iki log dosyaları sayesinde recovery işlemleri yapılabilir. Detaylı bilgi için şu kaynağa başvurabilirsiniz.
Checkpoint timeout olduğunda WAL dosyasına son transaction id’si kaydedilir ve bu aradaki veri değişikliği(dirty olarak adlandırılır) diske yazılır, ayrıca CLOG’da WAL’e kaydedilen id’ye kadar ilerletilir.
Diyelim CLOG’daki id(8 olsun) WAL dosyasındaki başarılı son transaction id’sinden (10 olsun) küçük ise REDO işlemi yapılarak transactionlar(10 ile 8 arasındaki 2 transaction) diske yazılır ve CLOG’daki değer ilerletilir böylece veri bütünlüğü sağlanır.
PostgreSQL’de DELETE işlemi yaptığımızda aslında kayıtlar silinmiyor kayıtlar sadece disable yapılıyor ve diskte durmaya devam ediyor. UPDATE işleminde de yine aynı mantıkla güncellenecek satır disable yapılıp yeni bir INSERT işlemi yapılıyor. Bu satırlar dead tuple(dead row) olarak adlandırılır. Dead rowlar kullanılmadığı halde diskte yer kaplamaya devam edecektir. Bu durumda bir garbage collection mekanizmamızın olması gerekir.
Vacuum PostgreSQL’ de oluşan dead rowların işaretlenmesi işlemidir. Analyze ise sorguların hızlı çalışması için tablolarda istatistik oluşturma işlemidir. Vacuum Full ise dead rowların diskten temizlenerek diskteki bu alanların tekrar kullanıma kazandırılmasıdır.
⚠️ Vacuum Full işlemi bir tablo üzerinde yapılıyorsa tabloda vacuum ile işaretlenmiş rowları kaldırıp yeni bir tabloya yazar. Daha sonra eski tablo silinir. Bu işlem tablodun kilitlenmesine (lock) neden olacaktır. O nedenle Vacuum Full işlemi transaction’ın az olacağı bir zamanda yapılması tavsiye edilir. Vacuum, analyze ve vacuum full ile ilgili detaylı bilgi için şu kaynağı inceleyebilirsiniz.
pgBadger Nedir?
İlk olarak pgBadger’ın ne olduğunu açıklamaya çalışacağım. pgBadger PostgreSQL için geliştirilmiş open source log analiz aracıdır. Perl dili ile yazılmış olan bu script grafik çizme ya da tablo oluşturmak için gerekli javascript kütüphanesi ve bootstrap gibi yapıları da kullandığı için dışarıdan herhangi bir modüle gerek duymaksızın çalışır.
pgBadger’ı Neden Kullanmalıyız?
Öncelikle log dosyaları text formatında olduğu için veritabanında bir sorun olduğunda log dosyasında gözle o sorunu bulmak çok zor olacaktır. Ayrıca veritabanındaki kaynak kullanımı ile ilgili bir rapor oluşturmak istediğimizde bir araç kullanmadığımızda en iyi ihtimalle bu raporu oluşturmak için bir script yazmamız gerekecektir. Ayrıca veritabanın optimizasyonu için yapılan işlemler tuning olarak adlandırılır. Tuning yapabilmek içinde bu aracın çıktılarından yararlanabiliriz. Kısaca pgBadger veritabanında anlamlı gözlem yapabilmemize imkan verir.
pgBadger Nasıl Kurulur?
Kurulum işlemini Windows sunucu için (PostgreSQL’in kurulu olduğunu varsayarak) adım adım anlatmaya çalışacağım:
1- İlk olarak pgBadger Perl ile yazıldığı için bir Perl derleyicisinin kurulu olması gerekir. Ben bunun için Strawberry Perl kullandım.
2- Derleyiciyi kurduktan sonra pgBadger github reposundan kodlar sunucuya çekilir.
3- Daha sonra repoda bulunan Perl scripti Perl derleyicisi ile çalıştırılır.
4- CMD’den ilgili dizine gittikten sonra 3. adımdan sonra oluşan Makefile dosyası gmake (linux’de make) komutu ile çalıştırılır.
5- Kurulumu test etmek için terminalden pgbadger -version komutu ile test edebiliriz.
6- Log analizinin yapılması ve daha fazla bilgi içerebilmesi için postgresql.conf dosyasında bazı konfigürasyonlar yapmamız gerekmektedir.
7- Altıncı adım da tamamlandıktan sonra log dosyaları parse edilerek log analiz dosyası html formatında oluşturulur.
postgresql.conf Dosyasının Düzenlenmesi
En basit gereksinim log_min_duration_statement = 0 değeri konfigurasyon dosyasına eklenir. Buradaki 0 değeri ms cinsindendir. Yani 0 ms’den fazla sürede çalışan sorgular(yani tüm sorgular) loglansın demiş oluyoruz.
Not: Eğer çok transaction alan bir veritabanınız varsa tüm sorguların loglanması da performans kaybına neden olabilir. Bu durumda sadece belirli bir süreden fazla çalışan sorguları loglayabilirsiniz.(Örneğin 5 ms’den fazla süren sorgular)
Daha sonra log formatınıza göre(stderr,syslog gibi conf doysasında belirtiliyor) bir log_line_prefix ekliyoruz. Bu da log entitylerinin log dosyasına yazılırken detaylı bilgiler içerecek şekilde yazılmasını sağlar.
Yukarıdaki örnekte kısaca özetlersem log entitysinin hangi veritabanından , hangi user’dan, hangi application, hangi client’tan geldiği gibi bilgileri belirterek log dosyasına kaydet demiş oluyoruz.(Buradaki %t ,%p gibi değerlerin açıklaması conf dosyasında mevcut.)
Log analizinin daha fazla bilgi içermesi için bazı değerleri ‘on’ yapmamız gerekecek. Fazla uzamaması için detaylı bilgi bu adreste mevcut.
Konfigürasyon kısmını da kısaca anlatmaya çalıştıktan sonra bizim yaptığımız konfigürasyonlara göre oluşan log dosyalarından analiz yapmaya bakabiliriz.
pgBadger Çalıştırma İşlemi
Konsoldan log file’ların bulunduğu (PostgreSQL 12 için C:\Program Files\PostgreSQL\12\data\log bu path değişebilir) dizine gittikten sonra
pgbadger postgresql.log -o result.html
komutunu çalıştıyoruz. postgresql.log dosyası bizim analiz edeceğimiz log dosyası, result.html ise analiz sonrası oluşacak çıktı dosyasıdır. Komutu çalıştırmak için birçok option’ı vardır (Örneğin sadece günlük olarak error loglarını yazdırabilirsiniz).
Log Analiz Çıktısının İncelenmesi
İlk olarak kısa kısa pgBadger ile neler yapabiliriz onlardan bahsedeceğim:
1- Tüm sorguların, sorgu türüne göre analizini yapabiliriz. Çalışan toplam sorgu sayısı, normalize edilmiş sorgu sayısı gibi bilgilere ulaşabiliriz.
2- En yavaş çalışan sorgular, en sık kullanılan sorgular, en fazla zaman harcayan sorguların analizi yapılabilir.
3- Veritabanına göre, user’a göre, application’a göre çalışan sorguların analizi yapılabilir.
4- Connection sayısı, session sayısı bir zamanda kurulan en fazla connection sayısı bilgisini öğrenebiliriz.
5- Oluşan temp file sayısı, boyutları ve bu temp file’ların oluşmasına neden olan sorgular hangileri öğrenebiliriz.
6- Veritabanlarında oluşan error, warning, panic ve fatal gibi logların sayılarını, nedenlerini öğrenebiliriz.
Ben kısaca genel neler yapılabilir özetlemeye çalıştım. Daha birçok bilgi içermektedir. Detaylı bilgiler için use it 🙂
Son olarak da bazı ekran görüntüleri paylaşıp bunlardan bazılarında açıklama yapacağım:
Global Stats kısmı genel bir özet kısmı olarak düşünebiliriz. Sorgu bilgileri, veritabanında yapılan işlemler sonucunda harcanan genel süre, eventler, connection, session, temp file sayısı, vacuum bilgisi gibi bilgileri içerir.
Ben ekran görüntülerinin genelini pgBadger’ ın örnek analiz çıktısından aldım. Buradan daha detaylı inceleyebilirsiniz. Yazının daha fazla uzamaması için burada sonlandırıyorum.
Sonuç
pgBadger hem basit kullanımı hem de sunduğu birçok özellik sayesinde PostgreSQL veritabanı kullananlar için yardımcı bir araç olarak kullanılabilir. Ancak performans kaybı yaşamamak için kendi veritabanınızın kullanım durumuna göre konfigurasyon yapmanızda fayda vardır. Örneğin log dosyasının çok büyük boyutlara ulaşmasını engelleyip saatlik olarak log dosyasından bir bin dosyası oluşturup log analizinin günlük olarak bu bin dosyalarından transactionın az olduğu bir zamanda parse edilmesini sağlayabilirsiniz. Gerekli konfigurasyonlardan sonra pgBadger aracını kullanarak veritabanında performans artırımı ve bazı analizler için kullanabiliriz.
Not: Eksik ya da yanlış gördüğünüz noktaları lütfen yazının daha iyi hale gelmesi için belirtiniz.
