MQTT broker izleme, müşterileriniz size mesajların akmadığını söylemeden önce sizin bunu bilmenizi sağlar. Bu rehber gerçekten önemli olan metrikleri, yani bağlantıları, mesaj hızlarını, düşürülen mesajları, gecikmeyi ve retained sayılarını, bunları gürültü yaratmadan nasıl uyarılara dönüştüreceğinizi ve basit bir uçtan uca sondayı nasıl oluşturacağınızı ele alıyor. Ayrıca bir broker'ı ConnectMQ portalında nasıl izleyeceğinizi de göreceksiniz.
Broker İzleme Neden Farklıdır?
Bir web sunucusu arızası genellikle gürültülüdür: istekler başarısız olur ve hata oranları sıçrar. MQTT arızaları ise çoğu zaman sessizdir. Bir abone bağlı kalabilir ama kalıcı oturum olmadan yapılan bir yeniden bağlanmanın ardından aboneliği kaybolduğu için mesaj almayı bırakabilir. Cihazlar bağlı olabilir ama bir sensör sürücüsü takıldığı için hiçbir şey yayınlamıyor olabilir. Çevrimdışı bir client için kuyruk, limitlere ulaşılana kadar sessizce büyüyebilir.
Bu nedenle iyi bir izleme üç görünümü birleştirir:
- Broker tarafı metrikleri: broker'ın gördükleri; bağlantılar, iş hacmi ve düşürmeler gibi.
- Client tarafı metrikleri: cihazların ve uygulamaların gördükleri; bağlantı hataları ve yeniden bağlanma sayıları gibi.
- Uçtan uca sondalar: yayın yapıp mesaj alan ve sistemin bir bütün olarak çalışıp çalışmadığını ölçen sentetik bir client.
Hareketli parçalar konusunda yeniyseniz, bir MQTT broker'ın ne yaptığı ile başlayın.
MQTT Broker İzlemede Önemli Metrikler
| Metrik | Size ne söyler | Tipik uyarı |
|---|---|---|
| Bağlı client'lar | Filo sağlığı, kesintiler, bağlanma fırtınaları | Referans değere göre ani düşüş veya sıçrama |
| Bağlantı denemeleri ve hataları | Kimlik bilgisi sorunları, saldırılar, limitler | Normalin üzerinde hata oranı |
| Saniye başına alınan mesajlar | Yayın etkinliği | Yoğun olduğu bilinen bir filoda sıfıra yakın düşüş |
| Saniye başına gönderilen mesajlar | Abonelere iletim | Beklenen dağıtımdan (fan-out) sapma |
| Düşürülen veya reddedilen mesajlar | Dolu kuyruklar, boyut veya kota limitleri | Sürekli sıfırdan farklı herhangi bir oran |
| Uçuştaki ve kuyruktaki mesajlar | Yavaş veya çevrimdışı tüketiciler | İstikrarlı artış |
| Uçtan uca gecikme | Kullanıcının hissettiği gecikme | Birkaç dakika boyunca hedefinizin üzerinde |
| Retained message sayısı | Topic düzeni, depolama artışı | Beklenmedik artış |
| Abonelik sayısı | Client kodundaki sızıntılar | Yeni client olmadan istikrarlı artış |
| Kaynak kullanımı (kendi sunucunuzda) | CPU, bellek, dosya tanımlayıcıları | Limitlere yaklaşma |
Bağlantılar
Bağlı client sayısı filonuzun nabzıdır. Bunu bir zaman serisi olarak takip edin ve günlük şeklini öğrenin. Bir uçurum; bir kesinti, ağ sorunu veya süresi dolmuş bir sertifika anlamına gelir. Düşüş ve toparlanmalardan oluşan testere dişi bir desen genellikle client'ların tekrar tekrar bağlantısının kesildiği anlamına gelir; bunun nedeni çoğu zaman yinelenen client ID'ler veya kararsız ağlarda fazla kısa bir keepalive'dır.
Mesaj Hızları
Alınan ve gönderilen hızlar verinin hareket edip etmediğini gösterir. Her dakika rapor veren bir filo için alınan hız kabaca öngörülebilir olmalıdır. Gönderileni alınanla karşılaştırın: oran dağıtımı yansıtır, dolayısıyla ani bir değişiklik abonelerin kaybolduğu ya da ortaya çıktığı anlamına gelir.
Düşürülen ve Reddedilen Mesajlar
Broker'lar mesajları somut nedenlerle düşürür veya reddeder: payload çok büyük, kota aşıldı, yavaş bir tüketici için kuyruk dolu ya da yetişemeyen bir client'a giden QoS 0 mesajları. MQTT 5'te bunların çoğu client'a 0x97 (Quota exceeded) gibi reason code'lar olarak görünür. Reason code'ları client tarafında loglayın; çoğu zaman mevcut en hızlı teşhis bunlardır.
Gecikme
Gecikme, kullanıcıların hissettiği şeydir. Uçtan uca ölçün: mesaja yayıncıda zaman damgası ekleyin ve bir aboneye ulaştığında karşılaştırın. Yalnızca ortalamaları değil yüzdelik dilimleri takip edin; çünkü sağlıklı bir medyan uzun bir kuyruğu gizleyebilir. Bölge de önemlidir; bölgeye göre MQTT broker gecikmesi yazısına bakın.
Retained Message'lar ve Abonelikler
Retained message'lar ve abonelikler topic tasarımınızla uyumlu olmalıdır. Sınırsız artış genellikle zaman damgası içeren dinamik topic adları ya da her yeniden bağlanmada tekrar abone olan client'lar gibi bir hataya işaret eder.
Client Tarafı Metrikleri Unutmayın
Broker yalnızca kendisine ulaşanı görür. Cihazlar ve arka uç servisleri kendi sağlıklarını raporlamalıdır: kaç bağlantı denemesinin başarısız olduğu ve nedeni, ne sıklıkla yeniden bağlandıkları, çevrimdışı tamponda kaç okuma beklediği ve CONNACK, PUBACK ve DISCONNECT'te dönen reason code'lar. Birkaç dakikada bir bir durum topic'ine kompakt bir sağlık mesajı yayınlayın; panoların her zaman en son değeri göstermesi için retained olarak. Bir saha karardığında, bu son raporlar çoğu zaman kimse oraya gitmeden nedenini açıklar.
Kendi Sunucunuzdaki Broker'lar: Metrikler Nereden Gelir?
Kendi broker'ınızı çalıştırıyorsanız metrikler broker'ın kendisinden gelir. Örneğin Mosquitto, istatistikleri $SYS/broker/clients/connected ve $SYS/broker/messages/received gibi $SYS/ topic'lerinde yayınlar. Kümelenmiş broker'lar genellikle toplama (scraping) için HTTP API'leri veya metrik uç noktaları sunar. Ardından bunları izleme sisteminize bağlar, panolar oluşturur, uyarılar tanımlar ve CPU, bellek ve açık dosya tanımlayıcıları gibi host metriklerini eklersiniz. Mosquitto belgeleri mevcut $SYS topic'lerini listeler.
Uçtan Uca Bir Gecikme Sondası Oluşturun
Hangi broker'ı kullanırsanız kullanın, sentetik bir sonda en değerli tek kontroldür. Normal bir client olarak bağlanır, özel bir topic'e zaman damgalı bir mesaj yayınlar, onu geri alır ve gidiş dönüş süresini kaydeder. Bu Python sondası paho-mqtt 2.x kullanır ve yazıldığı hâliyle herkese açık MQTT test broker'ına karşı çalışır; canlı ortam için özel broker kimlik bilgilerinize ve 8883 portuna geçin.
import json
import statistics
import time
import uuid
import paho.mqtt.client as mqtt
HOST, PORT = "broker.connectmq.com", 1883
PROBE_ID = uuid.uuid4().hex[:8]
TOPIC = f"connectmq/demo/{PROBE_ID}/probe"
INTERVAL = 5 # sondalar arasındaki saniye
ALERT_MS = 500 # gidiş dönüş süresi için uyarı eşiği
latencies = []
def on_connect(client, userdata, flags, reason_code, properties):
print("Probe connected:", reason_code)
client.subscribe(TOPIC, qos=1)
def on_disconnect(client, userdata, flags, reason_code, properties):
print("Probe disconnected:", reason_code)
def on_message(client, userdata, msg):
sent = json.loads(msg.payload)["t"]
rtt_ms = (time.time() - sent) * 1000
latencies.append(rtt_ms)
flag = " ALERT" if rtt_ms > ALERT_MS else ""
print(f"rtt={rtt_ms:.0f} ms{flag}")
if len(latencies) % 12 == 0:
recent = latencies[-12:]
print(f"last 12: median={statistics.median(recent):.0f} ms max={max(recent):.0f} ms")
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"probe-{PROBE_ID}")
# Canlı ortam: client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD"); client.tls_set(); PORT = 8883
client.on_connect = on_connect
client.on_disconnect = on_disconnect
client.on_message = on_message
client.reconnect_delay_set(min_delay=1, max_delay=60)
client.connect(HOST, PORT, keepalive=30)
client.loop_start()
try:
while True:
if client.is_connected():
client.publish(TOPIC, json.dumps({"t": time.time()}), qos=1)
else:
print("ALERT: probe not connected")
time.sleep(INTERVAL)
except KeyboardInterrupt:
client.loop_stop()
client.disconnect()
Sondayı yalnızca veri merkezinizden değil, cihazlarınızın kullandığı ağlardan da çalıştırın ve uyarılarını çağrı veya sohbet aracınıza iletin.
Metrikleri Kullanışlı Uyarılara Dönüştürmek
Uyarı yorgunluğu izlemeyi öldürür. Bazı pratik kurallar:
- Nedenlere değil, belirtilere uyarı kurun. "Sonda üç dakikadır başarısız" eyleme dönüştürülebilir; "CPU %70'te" genellikle değildir.
- Referans değerler kullanın. Bağlantı sayılarını sabit bir sayı yerine geçen haftanın aynı saatiyle karşılaştırın.
- Süreklilik şartı koyun. Kısa aksaklıkları absorbe etmek için yalnızca bir koşul birkaç dakika sürdükten sonra tetikleyin.
- Uyarıyı çağrıdan ayırın. Kuyruktaki mesajlarda yavaş artış bir kayıt (ticket) konusudur; yoğun bir filodan sıfır mesaj ise acil çağrı gerektirir.
- İzleyenleri de izleyin. Sondanın kendisi rapor vermeyi bırakırsa uyarı verin.
ConnectMQ'da İzleme
Yönetilen bir MQTT broker ile altyapıyı sağlayıcı izler, ancak kendi trafiğinizi görmeye yine de ihtiyacınız vardır. ConnectMQ portalda size birkaç araç sunar:
- Broker'ınıza genel bakış sunan pano.
- Mesajların gerçek zamanlı gelişini izlemek ve sessizleşen topic'leri fark etmek için canlı topic gezgini.
- Hiçbir şey kurmadan hızlı kontroller için yayın yapıp abone olabileceğiniz tarayıcı içi MQTT client.
- Ekipmanları ISA-95 seviyelerine göre düzenleyen, endüstriyel filolar için faydalı cihaz görünümü.
- Aralık dışı değerlerin daha sonra gözden geçirebileceğiniz uyarılar oluşturması için eşik tabanlı uyarı kuralları ve uyarı kaydı.
Cihaz başına bağlantı durumu için broker, bağlantı durumunu $SYS/broker/connection/{clientId}/state üzerinde yayınlar. Bir arka uç servisi, ağ geçitleri gibi önemli client'ların durum topic'ine abone olabilir ve biri çevrimdışı olduğunda tepki verebilir. Cihazlarınızdan gelen Last Will mesajları ve yukarıdaki sondayla birleştiğinde bu, hem broker düzeyindeki hem de uygulama düzeyindeki sağlığı kapsar. Portalın dışında, ConnectMQ VS Code eklentisi ve Desktop MQTT explorer, geliştirme sırasında trafiği incelemek için kullanışlıdır.
ConnectMQ ile Başlayın
Kredi kartı gerekmeden app.connectmq.com adresinde ücretsiz bir Serverless broker oluşturun ve ilk mesajlarınızı dakikalar içinde canlı topic gezgininde izleyin. Ardından canlıya geçmeden önce yukarıdaki sonda ve MQTT canlı ortam kontrol listesi ile eşleştirin. Bulut MQTT broker rehberi barındırma tablosunun geri kalanını ele alır.
Sık Sorulan Sorular
En önemli MQTT broker metriği hangisidir?
Uçtan uca bir sondayla birlikte bağlı client sayısı. Birlikte, cihazların çevrimiçi olup olmadığını ve mesajların gerçekten akıp akmadığını gösterirler.
MQTT gecikmesini nasıl ölçerim?
Zaman damgası içeren bir mesaj yayınlayın ve bir abone onu aldığında farkı hesaplayın. Yüzdelik dilimleri zaman içinde takip edin ve sondaları cihazlarınızın kullandığı ağlardan çalıştırın.
Bağlantı sayılarım neden testere dişi bir desenle düşüp toparlanıyor?
Yaygın nedenler; birbirini düşüren yinelenen client ID'ler, ağ için fazla kısa keepalive aralıkları ya da cihaz tarafında client'ları yeniden başlatan bir watchdog'dur.
Yönetilen bir broker'da yine de izlemeye ihtiyacım var mı?
Evet. Sağlayıcı kendi altyapısını izler, ancak cihazlarınızın ne göndermesi gerektiğini yalnızca siz bilirsiniz; bu yüzden kendi trafiğinizi izleyin ve sentetik bir sonda ekleyin.
