Sparkplug Rebirth İstekleri: Ne Zaman ve Nasıl Tetiklenir?

Sparkplug rebirth, bir host uygulamasının bir edge node'a NBIRTH ve DBIRTH mesajlarını yeniden yayınlatmak için gönderdiği bir komuttur; böylece host o node'un eksiksiz ve güncel bir görünümünü yeniden kurabilir. Bu rehberde hangi durumların rebirth gerektirdiğini, elle nasıl rebirth göndereceğinizi, doğru çalışan bir edge node'un nasıl yanıt verdiğini ve sahada en sık karşılaşılan sorunu, yani durmadan rebirth yapan node'ları nasıl teşhis edeceğinizi öğreneceksiniz.

Rebirth Ne Yapar?

Sparkplug tüketicileri birth mesajlarına üç şey için güvenir: metrik listesi, alias'lardan adlara ve veri tiplerine eşleme ve her metriğin güncel değeri. Bir host bir birth'ü kaçırırsa veya sıra takibini kaybederse, node modeli eksik kalır. Rebirth bunu MQTT bağlantısını düşürmeden düzeltir.

Komut, spBv1.0/{group}/NCMD/{edge_node} üzerinde, true olarak ayarlanmış Node Control/Rebirth adlı bir boolean metrik içeren bir NCMD mesajıdır. Edge node, seq'i 0'a sıfırlanmış ve mevcut oturumundaki bdSeq ile aynı olan yeni bir NBIRTH yayınlayarak, ardından her cihaz için bir DBIRTH göndererek yanıt verir. Ayrı bir cihaz seviyesi rebirth yoktur; bir node rebirth'ü her zaman tüm cihazlarını yeniden yayınlar.

Bir Host Ne Zaman Rebirth İstemeli?

Düzgün çalışan host uygulamaları bunları otomatik olarak gönderir. Kendi tüketicinizi yazıyorsanız, ilk üç tetikleyiciyi uygulamak gerçek durumların çoğunu karşılar.

Edge Node Nasıl Yanıt Vermeli?

1. NCMD'yi alır ve Node Control/Rebirth metriğinin true olduğunu doğrular.
2. seq'i 0'a sıfırlar.
3. Her node metriğini, güncel değerini, mevcut bdSeq'i ve tekrar false yapılmış Node Control/Rebirth metriğini içeren NBIRTH yayınlar.
4. Şu anda bağlı olan her cihaz için bir DBIRTH yayınlar.
5. NDATA ve DDATA'ya, seq birth mesajlarından devam edecek şekilde geri döner.

MQTT oturumu ve dolayısıyla kaydedilmiş NDEATH will'i değişmediği için bdSeq aynı kalır. Yeniden bağlanmadan rebirth'te bdSeq'i artıran bir node, daha sonra bir death geldiğinde bdSeq'i kontrol eden host'ların kafasını karıştırır. Sertifika kurallarının tamamı Sparkplug birth ve death sertifikaları yazısında açıklanıyor.

Elle Rebirth Gönderin

Devreye alma sırasında rebirth'ü kendiniz tetiklemek faydalıdır. Bu Python betiği paho-mqtt 2.x'i ve Eclipse Tahu sparkplug_b.proto dosyasından üretilmiş sınıfları kullanır (tek seferlik üretim adımı için Python ile Sparkplug B çözme eğitimimize bakın):

import sys
import time
import uuid

import paho.mqtt.client as mqtt
import sparkplug_b_pb2 as spb

if len(sys.argv) != 3:
    sys.exit("usage: python rebirth.py <group_id> <edge_node_id>")

group, node = sys.argv[1], sys.argv[2]

payload = spb.Payload()
payload.timestamp = int(time.time() * 1000)
metric = payload.metrics.add()
metric.name = "Node Control/Rebirth"
metric.timestamp = payload.timestamp
metric.datatype = 11  # Boolean
metric.boolean_value = True

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=f"rebirth-{uuid.uuid4().hex[:8]}")
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_start()
info = client.publish(f"spBv1.0/{group}/NCMD/{node}", payload.SerializeToString(), qos=0)
info.wait_for_publish()
client.disconnect()
client.loop_stop()
print(f"rebirth sent to {group}/{node}")

Betiği herkese açık MQTT test broker'ındaki bir simülatöre karşı çalıştırın, örneğin python rebirth.py demo-3f9a1c line1; bu sırada grubu izleyin:

mosquitto_sub -h broker.connectmq.com -p 1883 -i rebirth-watch-77d2 -v \
  -t "spBv1.0/demo-3f9a1c/#"

NCMD'yi, ardından birkaç an içinde bir NBIRTH ve DBIRTH görmelisiniz. Bir üretim broker'ında 8883 portu üzerinden TLS ve portal kimlik bilgilerinizle bağlanın ve gerçek ekipmana yalnızca yetkili host uygulamalarının komut göndermesi gerektiğini unutmayın.

Sorun Giderme Akışı

Bir host bayat veya eksik metrikler gösterdiğinde, bu adımları sırayla izleyin:

1. Node bağlı mı? Bağlantısını kontrol edin. ConnectMQ'da node'un client ID'si için $SYS/broker/connection/{clientId}/state topic'ine abone olun veya portala bakın.
2. Node birth mesajlarını yayınladı mı? Topic'lerinde NBIRTH ve DBIRTH arayın. Bağlandıktan sonra hiçbiri görünmüyorsa, STATE'ini göremediği bir primary host uygulamasını bekliyor olabilir.
3. Node NCMD'ye abone mi? Elle bir rebirth gönderin. Hiçbir şey olmazsa, node spBv1.0/{group}/NCMD/{node} topic'ine abone değildir veya rebirth'ü uygulamıyordur.
4. Birth mesajları tüm metrikleri içeriyor mu? Çözülmüş DBIRTH'ü beklediğiniz tag'lerle karşılaştırın. Eksik metrikler bir taşıma sorunu değil, node yapılandırma sorunudur.
5. seq kesintisiz mi? Birth'ten sonraki birkaç veri mesajını izleyin. Boşluklar mesaj kaybına veya aynı edge node ID'sini kullanan ikinci bir client'a işaret eder.
6. Alias'lar çözümleniyor mu? NDATA veya DDATA'daki her alias en son birth'te görünmelidir. Görünmüyorsa, node hiç bildirmediği alias'lar gönderiyordur.
7. Host birth mesajlarını doğru işliyor mu? Broker doğru birth mesajlarını gösteriyor ancak host hâlâ bayat veri gösteriyorsa, sorun host tarafındadır.

Çözülmüş payload'ları görmek 2, 4, 5 ve 6. adımları çok hızlandırır. ConnectMQ, portaldaki topic gezgininde Sparkplug B'yi çözer; böylece bir decoder yazmadan bir birth'teki metrik listesini okuyabilir, seq değerlerini kontrol edebilir ve alias'ları fark edebilirsiniz.

Rebirth Fırtınaları ve Nasıl Durdurulur?

Rebirth fırtınası, bir node'un sürekli rebirth yaparak broker'ı ve host'u birth mesajlarıyla boğduğu bir döngüdür. Tipik nedenler:

Son satır, paylaşımlı altyapıda dikkat gerektirir. Herkese açık broker client başına saniyede 10 mesaja ve mesaj başına 64 KB'a izin verir; Serverless planlarının ise kendi mesaj boyutu sınırları vardır. Binlerce metriğe sahip bir node büyük bir birth üretebilir; bu yüzden bir simülatörden gerçek ekipmana geçerken boyutları kontrol edin.

Host'lar da kendi isteklerine hız sınırı koymalıdır. Basit bir kural: node başına en fazla bir bekleyen rebirth, NBIRTH geldiğinde temizlenir ve birth hiç gelmezse bir geri çekilme (backoff) uygulanır.

Önleme Kontrol Listesi

1. Grup başına benzersiz edge node ID'leri ve bağlantı başına benzersiz MQTT client ID'leri.
2. Birth mesajları her zaman veriden önce yayınlanır ve her metrik ile alias bildirilir.
3. Her NBIRTH'te seq 0'a sıfırlanır; rebirth'te bdSeq değişmez.
4. Host'un boşluk algılaması 255'ten 0'a dönüşü ele alır.
5. Üretimde komut göndermesine izin verilen tek bir belirlenmiş host.
6. Birth boyutları broker sınırlarına göre kontrol edilir.

Taşıma Katmanını Güvenilir Tutun

Rebirth'lerin çoğu, daha yukarıdaki bir şeyin belirtisidir: kopan bağlantılar, yinelenen ID'ler veya bir host'un yeniden başlaması. Kararlı bir broker ilk kategoriyi azaltır. Yönetilen bir MQTT broker veya bir bulut MQTT broker, yamalama, sertifikalar ve izleme yükünü sizden alır. Tesis mimarilerinde Sparkplug'ın daha geniş resmi için MQTT ile Endüstriyel IoT rehberini okuyun.

ConnectMQ ile Başlayın

app.connectmq.com adresinde kredi kartı gerekmeden ücretsiz bir Serverless broker oluşturun. Edge node'larınızı ve host'unuzu bağlayın, yukarıdaki betikle bir rebirth tetikleyin ve çözülmüş birth mesajlarını ConnectMQ topic gezgininde inceleyin.

Sık Sorulan Sorular

Sparkplug rebirth edge node'un bağlantısını keser mi?

Hayır. Node bağlı kalır ve birth mesajlarını aynı MQTT oturumunda yeniden yayınlar. Bu yüzden rebirth sırasında bdSeq değişmez.

Tek bir cihaz için rebirth isteyebilir miyim?

Hayır. Rebirth komutu edge node'u hedefler; node da ardından NBIRTH'ünü ve bağlı her cihaz için bir DBIRTH'ü yeniden yayınlar.

Host'um neden sürekli rebirth istiyor?

En yaygın nedenler; yinelenen edge node ID'leri, birth mesajlarında bildirilmemiş alias'lar veya seq'in 255'ten 0'a normal dönüşünü boşluk olarak değerlendiren host mantığıdır.

Rebirth'lerden kaçınmak için birth mesajları retained olmalı mı?

Hayır. Sparkplug birth mesajları asla retained değildir. Daha sonra başlayan bir host, her zaman güncel değerleri alabilmek için rebirth ister.