Netdata ile MySQL ve PostgreSQL Veritabanı İzleme

Bykomut

Veritabanı sunucularınız gece yarısı sessizce yavaşlıyor, sorgu süreleri artıyor ama siz sabah gelene kadar hiçbir şeyin farkında olmuyorsunuz. Bu senaryoyu yaşadıysanız, doğru yere geldiniz. Netdata, MySQL ve PostgreSQL için gerçek zamanlı izleme konusunda ciddi bir çözüm sunuyor ve bu yazıda her iki veritabanını da nasıl düzgünce izleyeceğinizi anlatacağım.

Netdata’nın Veritabanı İzleme Mimarisi

Netdata, veritabanlarını izlemek için dahili collector’lar kullanıyor. Bu collector’lar Go ile yazılmış ve go.d.plugin altında çalışıyor. Eski Python tabanlı collector’larla karşılaştırıldığında çok daha az kaynak tüketiyor ve daha hızlı çalışıyor.

Temel mantık şu: Netdata her saniye veritabanına bağlanıyor, belirli status sorgularını çalıştırıyor ve bu verileri kendi time-series veritabanına yazıyor. MySQL için SHOW GLOBAL STATUS ve SHOW SLAVE STATUS gibi komutlar kullanılıyor. PostgreSQL için ise pg_stat_* view’ları sorgulanıyor.

Başlamadan önce Netdata’nın kurulu olduğunu varsayıyorum. Değilse hızlıca kuralım:

wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh
sh /tmp/netdata-kickstart.sh --nightly-channel

Kurulum tamamlandıktan sonra servis durumunu kontrol edin:

systemctl status netdata
# veya
service netdata status

MySQL İzleme Kurulumu

İzleme Kullanıcısı Oluşturma

Netdata’nın MySQL’e bağlanabilmesi için özel bir kullanıcı oluşturmanız gerekiyor. Root kullanıcısını asla kullanmayın. Sadece okuma yetkisi olan, minimum privilege’a sahip bir kullanıcı oluşturun:

mysql -u root -p

MySQL konsolunda:

CREATE USER 'netdata'@'localhost' IDENTIFIED BY 'guclu_bir_sifre_koy';
GRANT USAGE ON *.* TO 'netdata'@'localhost';
GRANT REPLICATION CLIENT ON *.* TO 'netdata'@'localhost';
FLUSH PRIVILEGES;

Eğer MySQL 8.0 veya üzerini kullanıyorsanız ve performans şeması verilerini de izlemek istiyorsanız birkaç ek yetki daha gerekiyor:

GRANT SELECT ON performance_schema.* TO 'netdata'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Netdata MySQL Collector Konfigürasyonu

Collector konfigürasyon dosyası şu konumda bulunuyor:

/etc/netdata/go.d/mysql.conf

Bu dosya varsayılan olarak gelmeyebilir. Örnek konfigürasyonu kopyalayalım:

cp /usr/lib/netdata/conf.d/go.d/mysql.conf /etc/netdata/go.d/mysql.conf

Şimdi bu dosyayı düzenleyelim. Tek bir MySQL instance için basit bir konfigürasyon:

jobs:
  - name: local
    dsn: netdata:guclu_bir_sifre_koy@tcp(127.0.0.1:3306)/

  - name: production_db
    dsn: netdata:guclu_bir_sifre_koy@tcp(192.168.1.100:3306)/
    timeout: 5

Birden fazla MySQL sunucusunu izlemek istiyorsanız jobs altına yeni bloklar eklemeniz yeterli. Her job ayrı bir veritabanı instance’ına karşılık geliyor ve Netdata panelinde ayrı ayrı görünüyor.

Konfigürasyonu kaydettikten sonra Netdata’yı yeniden başlatın:

systemctl restart netdata

MySQL Metriklerini Anlamak

Netdata MySQL için onlarca farklı metrik topluyor. Bunların hepsini ezberlemek zorunda değilsiniz ama kritik olanları bilmeniz gerekiyor:

Queries Per Second (QPS): Saniyede işlenen sorgu sayısı. Bu değerin ani düşüşleri veya beklenmedik artışları dikkat çekicidir. Gece 03:00’da normalin iki katı QPS görüyorsanız birinin backup aldığından veya toplu iş çalıştırdığından emin olun.

Connections: Aktif bağlantı sayısı. MySQL’de max_connections varsayılan değeri genellikle 151 oluyor. Bu değerin %80’ini geçtiğinizde alarm almanız gerekiyor.

InnoDB Buffer Pool: Bu MySQL’in kalbidir. Buffer pool hit ratio’nun %95’in altına düşmesi disk I/O’sunun arttığına işaret eder ve ciddi performans sorunlarına yol açar.

Table Locks: Yüksek tablo kilit bekleme sayıları, optimize edilmemiş sorgularınız olduğunu gösterir.

Slow Queries: Slow query log’u aktif olsa bile Netdata bunu gerçek zamanlı olarak gösterir.

PostgreSQL İzleme Kurulumu

İzleme Kullanıcısı Oluşturma

PostgreSQL için de benzer bir yaklaşım izliyoruz. Netdata’ya özel bir kullanıcı oluşturuyoruz:

sudo -u postgres psql

PostgreSQL konsolunda:

CREATE USER netdata WITH PASSWORD 'guclu_bir_sifre_koy';
GRANT pg_monitor TO netdata;

pg_monitor rolü PostgreSQL 10 ve üzerinde mevcut. Bu rol, tüm monitoring view’larına okuma erişimi sağlıyor. Eğer daha eski bir PostgreSQL sürümü kullanıyorsanız:

GRANT SELECT ON pg_stat_database TO netdata;
GRANT SELECT ON pg_stat_replication TO netdata;
GRANT SELECT ON pg_stat_user_tables TO netdata;
GRANT SELECT ON pg_stat_user_indexes TO netdata;

pg_hba.conf Düzenlemesi

Netdata’nın yerel olarak bağlanabilmesi için pg_hba.conf dosyasını düzenlemeniz gerekebilir:

sudo nano /etc/postgresql/14/main/pg_hba.conf

Şu satırı ekleyin (sürüm numaranızı değiştirin):

local   all   netdata   md5

Değişikliğin aktif olması için PostgreSQL’i reload edin:

sudo systemctl reload postgresql

Netdata PostgreSQL Collector Konfigürasyonu

cp /usr/lib/netdata/conf.d/go.d/postgres.conf /etc/netdata/go.d/postgres.conf
nano /etc/netdata/go.d/postgres.conf

Konfigürasyon içeriği:

jobs:
  - name: local
    dsn: "host=localhost dbname=postgres user=netdata password=guclu_bir_sifre_koy sslmode=disable"

  - name: production
    dsn: "host=192.168.1.101 port=5432 dbname=uygulama_db user=netdata password=guclu_bir_sifre_koy sslmode=require"
    timeout: 5
    max_db_tables: 0
    max_db_indexes: 0

max_db_tables ve max_db_indexes değerlerini 0 yaparak tüm tabloları ve indexleri izleyebilirsiniz. Ama çok büyük veritabanlarında bu performansı etkileyebilir, dikkatli olun.

Netdata’yı yeniden başlatın:

systemctl restart netdata

PostgreSQL Metriklerini Anlamak

PostgreSQL metrikleri MySQL’den biraz farklı bir yapıya sahip:

Connections: PostgreSQL bağlantı yönetimi MySQL’den farklıdır. Her bağlantı için ayrı bir process fork edilir. max_connections değerinize yaklaşıyorsanız PgBouncer gibi bir connection pooler kullanmayı ciddi düşünün.

Cache Hit Ratio: blks_hit / (blks_hit + blks_read) formülüyle hesaplanır. Bu oranın %99’un üzerinde olması hedef. Düşük cache hit ratio, RAM’inizin yetersiz olduğunu ve çok fazla disk okuma yapıldığını gösterir.

Transactions Per Second: Commit ve rollback sayıları. Yüksek rollback oranı uygulama kodunda hatalar olduğunu gösterebilir.

Dead Tuples: PostgreSQL’de silinen veya güncellenen satırlar hemen fiziksel olarak silinmez. VACUUM işlemi bunları temizler. Dead tuple sayısının sürekli artması VACUUM’un yeterince çalışmadığını gösterir.

Replication Lag: Primary-replica kurulumunuzda replication gecikmesini gerçek zamanlı takip edebilirsiniz.

Gerçek Dünya Senaryosu: Production Alarm Kuralları

Teorik bilgi güzel ama gerçekte ne izlememiz gerektiğini konuşalım. Production ortamında karşılaştığım sorunlardan yola çıkarak alarm kuralları yazdım.

Netdata alarm konfigürasyonları /etc/netdata/health.d/ dizininde tutuluyor. MySQL için özel alarm dosyası oluşturalım:

nano /etc/netdata/health.d/mysql_custom.conf
# MySQL bağlantı sayısı %80'i geçerse uyar
alarm: mysql_connections_high
on: mysql.connections_active
lookup: average -1m percentage of connections
units: %
every: 30s
warn: $this > 80
crit: $this > 95
info: MySQL aktif bağlantı sayısı yüksek. max_connections değerini artırmayı düşünün.
to: sysadmin

# InnoDB buffer pool cache hit ratio %90 altına düşerse uyar  
alarm: innodb_buffer_pool_low
on: mysql.innodb_buffer_pool_read_requests
lookup: average -5m percentage of reads_not_cached
units: %
every: 1m
warn: $this > 10
crit: $this > 20
info: InnoDB buffer pool hit ratio düşük. innodb_buffer_pool_size artırılabilir.
to: sysadmin

PostgreSQL için de benzer şekilde:

nano /etc/netdata/health.d/postgres_custom.conf
# PostgreSQL cache hit ratio düşerse uyar
alarm: postgres_cache_hit_low
on: postgres.db_cache_io_ratio
lookup: average -5m
units: %
every: 1m
warn: $this < 95
crit: $this < 90
info: PostgreSQL cache hit ratio düşük. shared_buffers veya RAM artışı gerekebilir.
to: sysadmin

# Dead tuple oranı yüksekse uyar
alarm: postgres_dead_tuples_high
on: postgres.table_dead_rows_ratio
lookup: max -1m
units: %
every: 5m
warn: $this > 10
crit: $this > 20
info: Yüksek dead tuple oranı. VACUUM'un düzgün çalıştığını kontrol edin.
to: sysadmin

Alarm konfigürasyonlarını aktif etmek için:

systemctl reload netdata

Collector Loglarını Kontrol Etme

Bir şeyler yanlış giderse ilk bakacağınız yer loglar olmalı. Netdata collector loglarını şu şekilde kontrol edebilirsiniz:

# Genel Netdata logları
tail -f /var/log/netdata/error.log

# Go plugin loglarına bakmak için
journalctl -u netdata -f

# Collector'ın çalışıp çalışmadığını test etmek için
sudo -u netdata /usr/lib/netdata/plugins.d/go.d.plugin -d -m mysql

# PostgreSQL collector testi
sudo -u netdata /usr/lib/netdata/plugins.d/go.d.plugin -d -m postgres

Eğer collector düzgün çalışmıyorsa debug modda çalıştırarak hangi adımda hata aldığını görebilirsiniz. Genellikle bağlantı sorunları veya yetki eksiklikleri bu şekilde yakalanıyor.

Netdata Cloud ile Merkezi İzleme

Birden fazla sunucunuz varsa Netdata Cloud ücretsiz planı işinizi ciddi kolaylaştırıyor. Tüm sunucularınızdaki MySQL ve PostgreSQL metriklerini tek ekrandan görebiliyorsunuz.

Mevcut Netdata kurulumunuzu Cloud’a bağlamak için:

netdata-claim.sh -token=YOUR_CLOUD_TOKEN -rooms=YOUR_ROOM_ID -url=https://app.netdata.cloud

Token bilgisini Netdata Cloud hesabınızdan alabilirsiniz. Bağlantı kurulduktan sonra verileriniz doğrudan tarayıcınızdan erişilebilir hale geliyor ve herhangi bir güvenlik duvarı değişikliği yapmak zorunda kalmıyorsunuz. Çünkü bağlantı dışarıdan içeriye değil, içeriden dışarıya doğru kuruluyor.

MySQL Replication İzleme

Master-slave yapısı çalıştırıyorsanız replication durumunu izlemek kritik önem taşıyor. Netdata bu konuda da hazır collector’lar sunuyor. Slave sunucusunda bağlantı kullanıcısına REPLICATION CLIENT yetkisi verdiğinizden emin olun.

Slave sunucusunda /etc/netdata/go.d/mysql.conf dosyasına şu satırları ekleyin:

jobs:
  - name: slave
    dsn: netdata:sifre@tcp(127.0.0.1:3306)/
    # Replication metrikleri otomatik olarak toplanacak

Netdata otomatik olarak şu metrikleri toplar:

  • Seconds_Behind_Master: Slave’in master’dan ne kadar geride olduğu
  • Slave_SQL_Running: SQL thread’inin çalışıp çalışmadığı
  • Slave_IO_Running: IO thread’inin çalışıp çalışmadığı

Replication durdu mu? Hemen alarm alırsınız. Seconds_Behind_Master sürekli artıyor mu? Slave sunucunuzun kapasitesini artırma zamanı gelmiş demektir.

Performans İpuçları: Netdata ve Veritabanı

Netdata’nın kendisi de bir kaynak tüketici. Her saniye sorgu attığı için veritabanı üzerinde minimal ama var olan bir yük oluşturuyor. Yoğun production sistemlerinde bunu göz önünde bulundurun:

Sorgu aralığını artırabilirsiniz. update_every parametresi saniye cinsinden sorgu aralığını belirliyor. Kritik olmayan sistemlerde bunu 5 saniyeye çıkarabilirsiniz:

jobs:
  - name: local
    dsn: netdata:sifre@tcp(127.0.0.1:3306)/
    update_every: 5

Ama şunu söyleyeyim: Netdata’nın veritabanı üzerindeki etkisi genellikle ihmal edilebilir düzeyde. Özellikle modern donanımlarda saniyede bir sorgu atmak neredeyse hiç fark yaratmıyor.

Pratik Dashboard Kullanımı

Netdata’nın default dashboard’u http://sunucu-ip:19999 adresinden erişilebilir. MySQL ve PostgreSQL bölümleri sol menüde görünüyor.

Dashboard’da dikkat etmeniz gereken birkaç panel:

MySQL için:

  • mysql_local.queries: QPS grafiği, trafik piklerini görmek için ideal
  • mysql_local.connections_active: Bağlantı kullanımı
  • mysql_local.innodb_io: InnoDB disk okuma/yazma operasyonları
  • mysql_local.innodb_buffer_pool_pages: Buffer pool doluluk oranı
  • mysql_local.table_locks: Kilit çakışmaları

PostgreSQL için:

  • postgres_local.db_transactions_ratio: Commit vs rollback oranı
  • postgres_local.db_cache_io_ratio: Cache hit performansı
  • postgres_local.db_size: Veritabanı boyutu takibi
  • postgres_local.vacuum_analyses: VACUUM ve ANALYZE frekansları
  • postgres_local.replication_standby_delta: Replication lag

Her grafiğin üzerine geldiğinizde anlık değerleri görebilir, grafik üzerinde zoom yapabilir ve anomali yaşanan zamanı tam olarak tespit edebilirsiniz. Saat 02:47’de yaşanan performans sorununun nedenini sabah 09:00’da araştırmak artık mümkün.

Sık Karşılaşılan Sorunlar ve Çözümleri

Collector bağlanamıyor hatası: En sık karşılaşılan sorun. MySQL’de netdata kullanıcısının sadece localhost‘tan mı yoksa 127.0.0.1‘den mi bağlandığını kontrol edin. Unix socket ile TCP/IP bağlantısı farklı davranıyor.

mysql -u netdata -p --host=127.0.0.1 --port=3306
# Bağlantı başarısızsa:
mysql -u netdata -p --socket=/var/run/mysqld/mysqld.sock

DSN’de socket kullanmak için:

dsn: "netdata:sifre@unix(/var/run/mysqld/mysqld.sock)/"

PostgreSQL SSL hatası: Bazı PostgreSQL kurulumlarında SSL zorunlu oluyor. DSN’de sslmode=disable yerine sslmode=require kullanın veya sertifika yollarını belirtin.

Metrikler görünmüyor: go.d.plugin servisinin çalışıp çalışmadığını kontrol edin:

ps aux | grep go.d
# Çalışmıyorsa
systemctl restart netdata

Çok fazla alert geliyor: İlk kurulumda Netdata’nın varsayılan alarmları çok hassas ayarlanmış olabilir. Gerekli olmayan alarmları devre dışı bırakmak için:

nano /etc/netdata/health.d/mysql.conf
# İlgili alarm bloğunun başına ekleyin:
# to: silent

Sonuç

Netdata ile MySQL ve PostgreSQL izlemek, eski usul Nagios veya Zabbix agent kurulumlarıyla karşılaştırıldığında çok daha az zahmetli. Kurulum birkaç dakika süruyor, konfigürasyon minimal ve sonuç olarak gerçek zamanlı veritabanı metrikleri anında elinizde oluyor.

En değerli yanı şu: Bir sorun yaşandığında “ne zaman başladı?” sorusunu yanıtlayabiliyorsunuz. Sorgu sürelerinin ne zaman arttığını, bağlantı havuzunun ne zaman dolmaya başladığını, cache hit ratio’sunun ne zaman düştüğünü tam zamanlamasıyla görebiliyorsunuz. Bu, root cause analysis için paha biçilmez bir bilgi.

Alarm kurallarını kendi ortamınıza göre ince ayar yapmanızı tavsiye ediyorum. Her production ortamı farklı, bir e-ticaret sitesinin normal QPS değeri bir kurumsal ERP sisteminkinden çok farklı olabilir. Birkaç hafta veri topladıktan sonra kendi baseline’ınızı belirleyin ve alarmlarınızı bu değerlere göre ayarlayın.

Son bir not: İzleme sistemleri ancak düzenli bakakılırsa değerli. Haftalık olarak metrikleri gözden geçirme alışkanlığı edinin. Çoğu büyük problem, büyümeden önce grafiklerde küçük anomaliler olarak kendini gösterir. Bunları zamanında yakalamak, sizi gece yarısı acil müdahalelerden kurtarır.

Benzer Konular

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir