MQTT Temelleri

MQTT $SYS Topic'leri: Broker Sistem Topic'leri Size Ne Anlatır?

$SYS topic ağacına pratik bir rehber: nereden geldiği, wildcard'ların neden onu atladığı, Mosquitto tarzı broker'ların orada ne yayınladığı ve ConnectMQ'da istemci bağlantı durumunun nasıl izleneceği.

Bir broker'dan bağlantı, istemci ve mesaj istatistiklerine dallanan MQTT SYS topic'lerinin illüstrasyonu
Bunu kendi MQTT broker’ınızda çalıştırınFree planla özel, yönetilen bir MQTT broker alın ve hazır kod örnekleriyle başlayın.
Ücretsiz deneyin Kod örnekleri Kart gerekmez

MQTT SYS topic'leri, topic ağacının bir broker'ın uygulama verisi yerine kendisi hakkında bilgi yayınladığı $SYS/... dalıdır. Bu yazıda bu geleneğin nereden geldiğini, düz bir # aboneliğinin neden onları hiçbir zaman göstermediğini, tipik bir broker'ın orada neleri sunduğunu ve ConnectMQ'nun yayınladığı tek sistem topic'ini istemci bağlantı durumunu takip etmek için nasıl kullanacağınızı öğreneceksiniz.

MQTT SYS Topic'leri Nedir?

MQTT spesifikasyonu, $ ile başlayan topic'leri broker'a özgü kullanım için ayırır. İstemcilerin bu topic'lerin altında uygulama verisi yayınlaması beklenmez ve spesifikasyon içeriklerini tamamen uygulamaya bırakır. Yıllar içinde $SYS/, broker telemetrisi için fiili standart önek hâline geldi: çalışma süresi, sürüm, bağlı istemci sayıları, mesaj ve bayt sayaçları ve benzeri yönetimsel veriler.

Buradaki kritik ifade "fiili"dir. Standart bir $SYS topic listesi, standart bir payload biçimi ya da belirli bir broker'ın bunlardan herhangi birini yayınlayacağına dair bir garanti yoktur. Mosquitto geniş bir ağacı yaygınlaştırdı; diğer broker'lar bir alt küme veya farklı bir düzen yayınlıyor, birçok yönetilen servis ise bunun büyük kısmını panolar ve API'lerle değiştiriyor. Her $SYS topic'ini, bağlı olduğunuz belirli broker'ın bir uygulama detayı olarak ele alın.

# Aboneliği Neden Onları Göstermez?

Bu durum ilk karşılaşıldığında neredeyse herkesi şaşırtır. # topic'ine abone olursanız broker'daki her uygulama mesajını alırsınız, ancak $SYS altından hiçbir şey gelmez. Bu bilinçli bir tasarımdır. mqtt.org'daki MQTT spesifikasyonu, wildcard (# veya +) ile başlayan bir topic filtresinin $ ile başlayan topic adlarıyla eşleşmemesi gerektiğini belirtir.

Bu kural, sıradan "her şeyi yakala" abonelerini broker istatistikleriyle boğulmaktan korur ve # topic'ini yansıtan araçların sistem verisini yanlışlıkla yeniden yayınlamasını engeller. Sistem topic'lerini okumak için $SYS önekini açıkça belirtmeniz gerekir:

#                  -> application topics only, never $SYS
$SYS/#             -> everything under $SYS (if the broker allows it)
$SYS/broker/+/+    -> a specific depth under $SYS/broker
+/broker/uptime    -> does NOT match $SYS/broker/uptime

Aynı mantık genel olarak MQTT topic'leri için wildcard kurallarına da uygulanır: wildcard'lar seviye seviye çalışır ve baştaki $ seviyesi, ilk konumda wildcard eşleşmesinin dışında tutulur.

Tipik Bir $SYS Ağacı (Mosquitto Örneği)

Mosquitto en yaygın referans olduğundan, sistem topic'lerinin neler içerebileceğini görmek için iyi bir örnektir. Varsayılan yapılandırmayla birkaç saniyede bir sayaçlarının anlık görüntüsünü yayınlar. Aralık mosquitto.conf içinde ayarlanır:

# mosquitto.conf
# $SYS güncellemelerini her 10 saniyede bir yayınla (0 periyodik güncellemeleri kapatır)
sys_interval 10

Yerel bir Mosquitto örneğinde göreceğiniz topic'lerden bir seçki:

Topic Anlamı
$SYS/broker/version Broker sürüm metni
$SYS/broker/uptime Broker başladığından beri geçen saniye
$SYS/broker/clients/connected Şu anda bağlı istemciler
$SYS/broker/clients/disconnected İstemcisi çevrimdışı olan kalıcı oturumlar
$SYS/broker/messages/received Başlangıçtan beri alınan toplam mesaj
$SYS/broker/messages/sent Başlangıçtan beri gönderilen toplam mesaj
$SYS/broker/subscriptions/count Etkin abonelikler
$SYS/broker/retained messages/count Tutulan retained message sayısı
$SYS/broker/load/messages/received/1min Alınan mesajların hareketli ortalaması
$SYS/broker/bytes/received Alınan toplam bayt

Bunları kendi Mosquitto broker'ınızda izlemek için kabuğun $SYS ifadesini genişletmemesi adına topic'i tırnak içine alın:

mosquitto_sub -h localhost -p 1883 -i sys-watcher-01 -t '$SYS/#' -v

Değerlerin çoğu retained message olarak yayınlanır; böylece yeni bir abone bir sonraki aralığı beklemek yerine en son anlık görüntüyü hemen alır. Sayaçlar broker yeniden başladığında sıfırlanır; bunları grafiğe dökerseniz bu önemlidir: sıfıra düşüş sakin bir saat değil, bir yeniden başlatma anlamına gelir.

$SYS Verisiyle İlgili Yaygın Hatalar

  • Taşınabilir olduğunu varsaymak. Mosquitto $SYS topic'leri üzerine kurulmuş bir pano, başka bir broker'a geçtiğiniz anda bozulur. Ayrıştırma mantığını tek bir yerde tutun.
  • Kabuğu unutmak. Bash'te çift tırnaklı "$SYS/#", $SYS ifadesini boş bir değişkene genişletir ve /# topic'ine abone olursunuz. Tek tırnak kullanın.
  • Herkese açık bırakmak. Kendi barındırdığınız bir broker'da sistem topic'leri istemci sayılarını ve sürüm numaralarını açığa çıkarır. Broker internetten erişilebiliyorsa bunları broker'ınızın yetkilendirme kurallarıyla kısıtlayın.
  • Çok sık sorgulamak. Çok kısa bir sys_interval, az fayda karşılığında trafik ekler. Operasyonel grafikler için on ila altmış saniye fazlasıyla yeterlidir.

Yönetilen Bir Broker'da MQTT SYS Topic'leri

Bir yönetilen MQTT broker'da genellikle büyük bir $SYS ağacına ihtiyaç duymazsınız, çünkü operatör broker metriklerini zaten toplar ve size gösterir. ConnectMQ da bu yaklaşımı benimser. Bağlantılar ve trafik gibi broker düzeyindeki bilgiler portal panosunda sunulur, canlı topic gezgini de hangi topic'lerin etkin olduğunu görmenizi sağlar; bu yüzden sayaçları sistem topic'lerinden ayrıştırmanız gerekmez.

ConnectMQ tam olarak bir sistem topic'i yayınlar:

$SYS/broker/connection/{clientId}/state

Bu topic, belirli bir client ID'nin bağlantı durumunu bildirir. Bu, uygulama kodunun gerçekten ihtiyaç duyduğu $SYS verisidir: "X cihazı şu anda çevrimiçi mi?" İstemci sayıları ve mesaj hızları gibi diğer her şey MQTT veri akışınıza değil, izlemeye aittir.

Bir İstemcinin Bağlantı Durumunu İzlemek

Aşağıdaki örnek, özel broker'ınızdaki bir cihazın durum topic'ine abone olmak için Python paho-mqtt 2.x kullanır. Yer tutucuları portalda oluşturulan kimlik bilgileriyle değiştirin ve DEVICE_ID değerini izlemek istediğiniz cihazın client ID'si olarak ayarlayın.

import ssl
import paho.mqtt.client as mqtt

BROKER = "YOUR_BROKER_HOST"      # portalda gösterilir
PORT = 8883
DEVICE_ID = "YOUR_DEVICE_CLIENT_ID"
STATE_TOPIC = f"$SYS/broker/connection/{DEVICE_ID}/state"

def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code.is_failure:
        print(f"Connect failed: {reason_code}")
        return
    print("Connected, subscribing to", STATE_TOPIC)
    client.subscribe(STATE_TOPIC, qos=1)

def on_subscribe(client, userdata, mid, reason_code_list, properties):
    for rc in reason_code_list:
        print("SUBACK:", rc)

def on_message(client, userdata, msg):
    print(f"{msg.topic} -> {msg.payload.decode(errors='replace')}")

client = mqtt.Client(
    mqtt.CallbackAPIVersion.VERSION2,
    client_id="YOUR_CLIENT_ID",
    protocol=mqtt.MQTTv5,
)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_subscribe = on_subscribe
client.on_message = on_message

client.connect(BROKER, PORT, keepalive=60)
client.loop_forever()

Betiği çalıştırın, ardından cihazı kapatıp açın veya istemcisini durdurun. Cihaz bağlantıyı kesip yeniden bağlandıkça durum topic'inin değiştiğini göreceksiniz. Ayrıştırma mantığını yazmadan önce, kodunuzun varsaydığınız şeyle değil broker'ın gönderdiğiyle eşleşmesi için gerçek payload'a portalın tarayıcı içi MQTT istemcisinden bakın.

$SYS Durumu ve Last Will Karşılaştırması

Varlık bilgisini zaten bir Last Will and Testament mesajıyla takip ediyor olabilirsiniz. İki yaklaşım birbirini tamamlar:

Yaklaşım Kim yayınlar Güçlü yanı Sınırlaması
Last Will ve retained "online" mesajı Cihaz ve onun adına broker Her broker'da çalışır; topic ve payload size aittir Cihazın bunu doğru yapılandırması gerekir; yanlış yapılandırılmış bir istemci hiçbir zaman bildirim yapmaz
$SYS/broker/connection/{clientId}/state Broker Cihazda kod gerekmez; broker'ın gerçekte gördüğünü yansıtır Broker'a özgü topic düzeni

Mantıklı bir model, topic ağacınızı zaten anlayan uygulama tüketicileri için Last Will'i korumak, broker'ın durum topic'ini ise operasyon araçları ve Will tanımlanmamış cihazların düzgün davrandığını doğrulamak için kullanmaktır. MQTT cihaz çevrimiçi durumu rehberi, Will tabanlı modeli ayrıntılı olarak anlatır.

Büyük Bir $SYS Ağacı Olmadan İzleme Kontrol Listesi

Grafana grafiklerinin $SYS ile beslendiği, kendi barındırdığınız bir broker'dan geliyorsanız, aynı ihtiyaçları yönetilen bir serviste şu şekilde karşılayabilirsiniz:

  1. Bağlantı sayıları ve trafik. $SYS/broker/clients/connected yerine portaldaki broker panosunu kullanın.
  2. Hangi topic'lerin canlı olduğu. Bir dizüstü bilgisayardan # topic'ine abone olmak yerine canlı topic gezginini kullanın.
  3. Cihaz başına varlık bilgisi. İlgilendiğiniz client ID'ler için $SYS/broker/connection/{clientId}/state topic'ine abone olun veya bir Last Will kullanın.
  4. Veri üzerindeki eşik koşulları. Sıcaklık veya basınç gibi değerler için portalda alarm kuralları yapılandırın ve alarm günlüğünü inceleyin.
  5. Uzun vadeli metrik geçmişi. İhtiyacınız olan veriyi zaman serisi veritabanınıza yazan kendi abonenizi (Telegraf, küçük bir Python servisi veya Node-RED) çalıştırın.
  6. Kota farkındalığı. İstemci günlüklerinde MQTT 5 reason code 0x97 (kota aşıldı) değerini takip edin; bu kod bir plan limitine ulaşıldığını gösterir.

Herkese Açık Broker'da Test Etmek

Yalnızca topic yapısıyla deneme yapmak istiyorsanız, broker.connectmq.com adresindeki herkese açık MQTT test broker'ı, boş olmayan ve benzersiz herhangi bir client ID ile anonim bağlantıları kabul eder. Herkese açık alanın herkes tarafından okunabildiğini unutmayın; benzersiz bir önek kullanın ve asla hassas veri göndermeyin:

# Terminal 1: kendi demo önekinize abone olun
mosquitto_sub -h broker.connectmq.com -p 1883 -i sys-demo-sub-7f3a \
  -t 'connectmq/demo/7f3a/#' -v

# Terminal 2: bir test mesajı yayınlayın
mosquitto_pub -h broker.connectmq.com -p 1883 -i sys-demo-pub-7f3a \
  -t 'connectmq/demo/7f3a/hello' -m 'hi'

Terminal 1'deki # aboneliğinin mesajınızı gördüğüne, ancak $SYS altındaki hiçbir şeyi görmediğine dikkat edin; tam da spesifikasyonun gerektirdiği gibi. Topic'lerin, aboneliklerin ve broker'ın birbirine nasıl oturduğuna daha geniş bir bakış için MQTT eğitimi iyi bir sonraki okumadır; MQTT topic adlandırma kuralları ise kendi ağacınızı bir broker'ın sistem ağacı kadar düzenli tutmayı anlatır.

ConnectMQ ile Başlayın

$SYS sayaçlarını ayrıştırmadan broker metrikleri mi istiyorsunuz? app.connectmq.com adresinde kredi kartı gerektirmeden ücretsiz bir Serverless broker oluşturun. Birkaç dakika içinde oluşturulmuş kimlik bilgilerine, bir panoya, canlı topic gezginine ve cihaz başına varlık bilgisi için $SYS/broker/connection/{clientId}/state topic'ine sahip olursunuz.

Sık Sorulan Sorular

# aboneliği neden $SYS mesajlarını göstermiyor?

MQTT spesifikasyonu, wildcard ile başlayan topic filtrelerinin $ ile başlayan topic'lerle eşleşmemesi gerektiğini söyler. Broker'ınız sistem topic'leri yayınlıyor ve okumanıza izin veriyorsa açıkça $SYS/# topic'ine abone olun.

MQTT SYS topic'leri standart mı?

Hayır. Yalnızca $ önekli topic'lerin ayrılmış olması standarttır. Topic adları, payload'lar ve güncelleme aralıkları broker'dan broker'a değişir; bu nedenle onları okuyan kod broker'a özgüdür.

ConnectMQ hangi $SYS topic'ini yayınlar?

ConnectMQ, bir istemcinin bağlantı durumunu bildiren $SYS/broker/connection/{clientId}/state topic'ini yayınlar. Bağlantılar ve trafik gibi broker metrikleri ise portal panosunda gösterilir.

$SYS topic'lerine kendi mesajlarımı yayınlayabilir miyim?

Yayınlamamalısınız. $ öneki broker için ayrılmıştır ve çoğu broker oradaki istemci yayınlarını reddeder veya yok sayar. Kendi durum verinizi uygulama topic ağacınızın altına yerleştirin.

İlgili yazılar

MQTT'yi Kim İcat Etti? Petrol Boru Hatlarından IoT'ye Uzanan Tarih

MQTT, 1999'da IBM'den Andy Stanford-Clark ve Arcom'dan Arlen Nipper tarafından petrol boru hatlarını uydu üzerinden izlemek için icat edildi. Açık kaynağa, OASIS'e, ISO'ya ve bugünün yönetilen bulut broker'larına uzanan yolculuğunu izleyin.

7 dk okuma

MQTT Maksimum Mesaj Boyutu: Sınırlar ve Büyük Payload Stratejileri

MQTT teknik olarak 256 MB'lık bir paket taşıyabilir, ancak broker'lar, istemci kütüphaneleri ve cihazlar çok daha düşük sınırlar uygular. Gerçek sınırların nerede olduğunu, aşıldıklarında ne olduğunu ve büyük payload'ların nasıl gönderileceğini öğrenin.

6 dk okuma

Tüm yazılar →

Özel MQTT broker’ınız birkaç tık uzağınızda

Hesabınızı oluşturun, broker kimlik bilgilerinizi alın ve ilk cihazınızı bağlayın — kurulacak, yamalanacak ya da ölçeklendirilecek sunucu yok.