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
$SYStopic'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/#",$SYSifadesini 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:
- Bağlantı sayıları ve trafik.
$SYS/broker/clients/connectedyerine portaldaki broker panosunu kullanın. - Hangi topic'lerin canlı olduğu. Bir dizüstü bilgisayardan
#topic'ine abone olmak yerine canlı topic gezginini kullanın. - Cihaz başına varlık bilgisi. İlgilendiğiniz client ID'ler için
$SYS/broker/connection/{clientId}/statetopic'ine abone olun veya bir Last Will kullanın. - 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.
- 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.
- 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.



