RabbitMQ Yönetim Arayüzü ve Kuyruk İzleme Rehberi

Üretim ortamında RabbitMQ çalıştırıyorsanız ve yönetim arayüzünü sadece “bi şeyler izliyorum” modunda kullanıyorsanız, aslında elinizin altındaki en güçlü aracı yarım kullanıyorsunuz demektir. Bu yazıda yönetim arayüzünü derinlemesine inceleyeceğiz, kuyruk izleme stratejilerini konuşacağız ve gerçek senaryolarda nasıl aksiyon alacağımıza bakacağız.

Yönetim Eklentisini Aktif Etmek

RabbitMQ kurulumundan sonra yönetim arayüzü varsayılan olarak gelmez. Önce eklentiyi etkinleştirmemiz gerekiyor:

rabbitmq-plugins enable rabbitmq_management

Bu komut sonrasında RabbitMQ’yu yeniden başlatmanıza gerek yok, eklenti sıcak olarak aktif olur. Varsayılan port 15672‘dir. Ama dikkat: bu portu dışarıya açmadan önce bir dakika durun. Üretim ortamında yönetim arayüzünü doğrudan internete açmak ciddi bir güvenlik riskidir. Nginx veya HAProxy arkasına koyun, en azından IP kısıtlaması uygulayın.

Eklenti durumunu kontrol etmek için:

rabbitmq-plugins list | grep management

Çıktıda [E*] görüyorsanız eklenti hem etkin hem de çalışıyor demektir.

Varsayılan Kullanıcı Meselesi

Kurulum sonrası gelen guest/guest kullanıcısı sadece localhost üzerinden bağlanabilir, bu aslında makul bir güvenlik önlemi. Ama takımınızın erişmesi için yeni bir kullanıcı oluşturmanız şart:

rabbitmqctl add_user monitoring_user GucluBirSifre123!
rabbitmqctl set_user_tags monitoring_user monitoring
rabbitmqctl set_permissions -p / monitoring_user ".*" ".*" ".*"

Burada monitoring tag’i önemli. RabbitMQ’da kullanıcı rolleri tag sistemiyle çalışır:

• administrator: Her şeye tam erişim, kullanıcı yönetimi dahil
• monitoring: Tüm virtual host’ları ve kuyrukları okuma yetkisi, değişiklik yapamaz
• management: Sadece kendi bağlantılarını ve kanallarını görebilir
• policymaker: Policy ve parametre yönetimi yapabilir
• impersonator: Başka kullanıcıların adına mesaj gönderebilir (nadiren kullanılır)

Ekip içinde monitoring kullanıcısını salt okuma yetkisiyle vermek en sağlıklı yaklaşım. Birisi yanlışlıkla kuyruk silmesin diye.

Arayüz Anatomisi: Hangi Sekme Ne İşe Yarar?

Yönetim arayüzünü açtığınızda üst menüde altı ana sekme görürsünüz. Çoğu sysadmin sadece Queues sekmesine bakıp geçer, ama diğerleri de en az o kadar değerli.

Overview Sekmesi

Genel sağlık durumu buradan okunur. Dikkat etmeniz gereken üç temel gösterge:

Message rates bölümünde publish, deliver ve ack hızlarını görürsünüz. Eğer publish hızı deliver hızının sürekli üzerindeyse kuyruğunuz birikmeye başlıyor demektir. Bu grafik saatler içinde yavaş yavaş yükselen bir trendle ilerliyorsa tatile girmeden önce consumer sayınızı artırın.

Nodes bölümü cluster yapısındaysanız kritik öneme sahip. Hangi node’un ne kadar bellek ve disk kullandığını buradan takip edersiniz. RabbitMQ’nun bellek limiti varsayılan olarak toplam RAM’in %40’ıdır, bu limite yaklaşılınca publisher’lar bloklanmaya başlar.

Ports and contexts kısmı ise hangi protokollerin hangi portlarda dinlendiğini gösterir. AMQP için 5672, AMQPS için 5671, MQTT etkinse 1883 gibi.

Connections ve Channels Sekmeleri

Bir üretim sorununda “neden bu kadar çok bağlantı var?” diye sorduğunuzda cevabı bu sekmede bulursunuz. Her satırda bağlantının geldiği IP, kullandığı virtual host, açık kanal sayısı ve durumu görünür.

Dikkat etmeniz gereken durum değerleri:

• running: Normal, her şey yolunda
• flow: Publisher flow control altında, mesaj göndermesi yavaşlatılıyor
• blocking: Publisher bloklanmak üzere
• blocked: Publisher tamamen bloklandı, disk veya bellek limiti aşıldı

Eğer connection listesinde yüzlerce kanal açık bir bağlantı görüyorsanız, muhtemelen uygulamanızda kanal sızıntısı var. Her operasyon için yeni kanal açıp kapatmayan bir uygulama zamanla bu sorunu yaratır.

Queues Sekmesi: Asıl İş Buradan

Kuyruk izlemenin kalbi bu sekme. Ama varsayılan görünümde bazı kolonlar gizlidir, önce “Columns” butonundan şunları aktif edin:

• Messages ready
• Messages unacknowledged
• Message rates (incoming/deliver/ack)
• Consumers
• State

Kuyruk Durumları

Bir kuyruğun state kolonunda görebileceğiniz değerler:

• running: Normal durum
• idle: Kuyrukta aktivite yok ama sorun değil
• flow: Kuyruk mesaj kabul etmede yavaşlatılıyor
• down: Cluster’da mirror lost, kısmi çalışma
• stopped: Kuyruk durdu, acil müdahale gerekli

Mesaj Birikmesi Tespiti

Gerçek dünyadan bir senaryo: E-ticaret sistemimizde sipariş bildirim kuyruğu vardı. Her gece 22:00-23:00 arası birikiyor, sabah 06:00’a kadar erişiyor, sonra consumer’lar yetişip temizliyordu. Bu pattern yönetim arayüzünde kuyruk detay sayfasındaki “Message rates” grafiğinde çok net görünüyordu. Sorunu tespit etmek kolaydı ama çözmek için consumer sayısını artırmak yetmedi, aslında o saatte e-posta servisimizin rate limit’ine takılıyorduk.

Önemli nokta: Kuyruk birikiyor diye hemen consumer eklemek çözüm değildir. Önce neden biriktiğini anlamak gerekir.

HTTP API ile Programatik İzleme

Yönetim arayüzünün en değerli özelliklerinden biri güçlü bir HTTP API sunmasıdır. Grafana dashboard’larınıza, Prometheus’a veya kendi monitoring scriptlerinize bu API üzerinden veri çekebilirsiniz.

Tüm kuyrukları listelemek için:

curl -s -u monitoring_user:GucluBirSifre123! 
  http://localhost:15672/api/queues | 
  python3 -m json.tool | head -50

Belirli bir kuyruğun detayını almak:

curl -s -u monitoring_user:GucluBirSifre123! 
  http://localhost:15672/api/queues/%2F/siparis_kuyrugu | 
  python3 -m json.tool

Virtual host adındaki / karakteri URL’de %2F olarak encode edilmeli, bunu unutmak sık yapılan bir hata.

Kuyruk derinliğini izleyen basit bir Bash script:

#!/bin/bash

RABBIT_HOST="localhost"
RABBIT_PORT="15672"
RABBIT_USER="monitoring_user"
RABBIT_PASS="GucluBirSifre123!"
QUEUE_NAME="siparis_kuyrugu"
VHOST="%2F"
THRESHOLD=1000

MESSAGES=$(curl -s -u "${RABBIT_USER}:${RABBIT_PASS}" 
  "http://${RABBIT_HOST}:${RABBIT_PORT}/api/queues/${VHOST}/${QUEUE_NAME}" | 
  python3 -c "import sys,json; print(json.load(sys.stdin).get('messages', 0))")

echo "Kuyrukta bekleyen mesaj: ${MESSAGES}"

if [ "${MESSAGES}" -gt "${THRESHOLD}" ]; then
  echo "UYARI: Kuyruk derinligi esigi asti! (${MESSAGES} > ${THRESHOLD})"
  # Buraya alerting entegrasyonu eklenebilir
  exit 1
fi

exit 0

Bu scripti cron’a ekleyip her 5 dakikada bir çalıştırabilirsiniz. Veya Nagios/Zabbix gibi monitoring sistemlerinizle entegre edebilirsiniz.

Prometheus ve Grafana Entegrasyonu

Modern ortamlarda yönetim arayüzü yerine metrics endpoint’i tercih edilir. RabbitMQ 3.8’den itibaren gelen Prometheus eklentisi bu iş için biçilmiş kaftan:

rabbitmq-plugins enable rabbitmq_prometheus

Bu eklenti varsayılan olarak 15692 portunda /metrics endpoint’i açar. Prometheus’un scrape konfigürasyonuna eklemek için:

# prometheus.yml içine eklenecek bölüm
scrape_configs:
  - job_name: 'rabbitmq'
    static_configs:
      - targets: ['rabbitmq-host:15692']
    scrape_interval: 15s

Grafana’da kullanabileceğiniz hazır dashboard ID’leri mevcut (resmi RabbitMQ dashboard’u 10991 numaralı). Import edip bağlandığınızda dakikalar içinde güzel bir görünüm elde edersiniz. Ama bu dashboard’ları olduğu gibi bırakmayın, kendi kritik metrikleriniz için özel paneller ekleyin.

Dead Letter Queue İzleme

DLQ izleme, genellikle atlanılan ama son derece kritik bir konu. Bir mesaj işlenemeden reddedildiğinde (nack + requeue=false) veya TTL süresi dolduğunda dead letter exchange’e yönlenir.

DLQ’yu tanımlamak için önce exchange ve kuyruk kurulumu:

# rabbitmqadmin aracıyla DLX exchange oluşturma
rabbitmqadmin declare exchange 
  name=dead_letter_exchange 
  type=direct 
  durable=true

# DLQ kuyruğu oluşturma
rabbitmqadmin declare queue 
  name=siparis_dlq 
  durable=true

# Binding
rabbitmqadmin declare binding 
  source=dead_letter_exchange 
  destination=siparis_dlq 
  routing_key=siparis_kuyrugu

# Ana kuyruğu DLX ile bağlama
rabbitmqadmin declare queue 
  name=siparis_kuyrugu 
  durable=true 
  arguments='{"x-dead-letter-exchange":"dead_letter_exchange","x-dead-letter-routing-key":"siparis_kuyrugu"}'

DLQ’daki mesajları periyodik olarak kontrol eden bir script:

#!/bin/bash

DLQ_COUNT=$(curl -s -u "monitoring_user:GucluBirSifre123!" 
  "http://localhost:15672/api/queues/%2F/siparis_dlq" | 
  python3 -c "import sys,json; d=json.load(sys.stdin); print(d.get('messages',0))")

if [ "${DLQ_COUNT}" -gt "0" ]; then
  echo "[$(date)] DIKKAT: DLQ'da ${DLQ_COUNT} islenmemis mesaj var"
  # Slack, PagerDuty veya e-posta bildirimi buraya
fi

DLQ’nuzda mesaj birikiyorsa bu bir uygulama hatası sinyalidir. Consumer log’larını inceleyin, hangi mesajlar neden reddediliyor bunu anlamadan DLQ’yu temizlemek problemi örtbas etmektir.

Policy ve TTL Yönetimi

Yönetim arayüzünün Admin sekmesindeki Policies bölümü, kuyruklara toplu kural uygulamanızı sağlar. Tek tek kuyruk tanımı yapmak yerine isim pattern’ine göre policy uygulayabilirsiniz.

Tüm *.tmp kuyrukları için 1 saatlik TTL ve max 10000 mesaj limiti:

rabbitmqctl set_policy gecici-kuyruk-policy 
  "^.*.tmp$" 
  '{"message-ttl": 3600000, "max-length": 10000, "overflow": "reject-publish"}' 
  --apply-to queues 
  --priority 10

Bu komuttaki parametreler:

• message-ttl: Milisaniye cinsinden mesaj yaşam süresi, 3600000ms = 1 saat
• max-length: Kuyrukta tutulacak maksimum mesaj sayısı
• overflow: Limit aşıldığında ne yapılacak, reject-publish publisher’ı reddeder, drop-head en eski mesajı siler
• priority: Birden fazla policy çakışırsa hangisinin geçerli olacağını belirler, yüksek kazanır

Policy uygulanıp uygulanmadığını kontrol etmek için yönetim arayüzünde ilgili kuyruğun detay sayfasına bakın. “Features” kolonunda policy adını ve hangi parametrelerin uygulandığını görürsünüz.

Cluster Sağlık Kontrolü

Cluster yapısında çalışıyorsanız node’ların birbirini görmesi kritik. Yönetim arayüzünden node durumunu kontrol etmenin yanı sıra CLI üzerinden de doğrulama yapın:

# Cluster durumu
rabbitmqctl cluster_status

# Tüm node'ların sağlık kontrolü
rabbitmq-diagnostics check_running
rabbitmq-diagnostics check_local_alarms

# Bellek kullanımı detayı
rabbitmq-diagnostics memory_breakdown

check_local_alarms komutu özellikle önemli. Eğer bir node’da bellek veya disk alarmı varsa bu komut sizi uyarır. Disk alarmı genellikle gözden kaçar, bellek alarmı daha dramatik olduğu için daha fazla dikkat çeker. Ama disk dolunca RabbitMQ yeni mesaj kabul etmeyi bırakır ve bu tam anlamıyla bir prodüksiyon felaketi olabilir.

Disk alarm eşiğini yönetim arayüzünde Admin > Cluster > Disk olmak üzere görebilirsiniz. Varsayılan değer {mem_relative, 1.0} yani toplam RAM kadar boş disk. Bu değer kurulum ortamına göre makul olmayabilir, rabbitmq.conf içinde özelleştirebilirsiniz:

# /etc/rabbitmq/rabbitmq.conf
disk_free_limit.absolute = 2GB

Shovel ve Federation ile İzleme

Eğer farklı data center’lar veya farklı RabbitMQ cluster’ları arasında mesaj taşıyorsanız Shovel eklentisi kullanıyorsunuzdur. Yönetim arayüzünde Admin > Shovel Status sekmesi shovel bağlantılarının durumunu gösterir.

Shovel durumunu API üzerinden kontrol etmek için:

curl -s -u "monitoring_user:GucluBirSifre123!" 
  http://localhost:15672/api/shovels | 
  python3 -c "
import sys, json
shovels = json.load(sys.stdin)
for s in shovels:
    print(f"Shovel: {s['name']}, Durum: {s['state']}")
"

Shovel state’i running değilse iki cluster arasındaki mesaj akışı durmuş demektir. Bu durumda önce ağ bağlantısını kontrol edin, ardından kaynak ve hedef cluster’ların sağlığına bakın.

Günlük Rutinler ve Kontrol Listesi

Bir sysadmin olarak RabbitMQ’yu ciddiye alıyorsanız sabah mesaiye geldiğinizde şu kontrolleri yapın:

Kuyruk derinlikleri dün geceden bu yana artmış mı? DLQ’larda mesaj birikmiş mi? Herhangi bir node alarmı var mı? Connection sayısı normalin çok üzerinde mi? Memory kullanımı %40 eşiğine yaklaşıyor mu?

Bu kontrolleri manuel yapmak yerine Grafana alerting veya basit bir monitoring scriptiyle otomatize edin. Sabah slack’e düşen “her şey yolunda” mesajı veya “şu kuyruğa bak” uyarısı iş hayatınızı kolaylaştırır.

Özellikle yüksek hacimli sistemlerde unacknowledged mesaj sayısına dikkat edin. Consumer’lar mesajları alıyor ama acknowledge etmiyorsa, zamanla prefetch limit dolacak ve consumer’lar yeni mesaj almayı bırakacaktır. Bu durum yönetim arayüzünde “Messages unacknowledged” kolonunun sürekli yükselmesiyle kendini belli eder.

Sonuç

RabbitMQ yönetim arayüzü, sadece kuyrukların dolu mu boş mu olduğunu görmekten ibaret değil. Bağlantı sağlığından cluster durumuna, policy yönetiminden DLQ izlemeye kadar geniş bir kapsama sahip. HTTP API sayesinde bu verileri kendi monitoring altyapınıza entegre etmek oldukça kolay.

En önemli nokta: reactive değil proactive izleme. Kuyruk patlayana kadar beklemek yerine eşik değerleri belirleyin, alerting kurun ve anormallikleri erkenden yakalayın. Bir kuyruğun yavaş yavaş dolması genellikle saatler öncesinden ipucu verir, bu ipuçlarını görmek için arayüzü ve API’yi etkin kullanmak gerekir.

Prometheus eklentisini henüz aktif etmediyseniz bugün etkinleştirin. Grafana dashboard’u kurun. DLQ yapınızı gözden geçirin. Bunlar zor işler değil ama yapıldığında gece 02:00’de telefonunuzun çalma ihtimalini ciddi ölçüde düşürür.