Bir MQTT broker'ı gerçek cihazlara hizmet vermeden önce bu MQTT broker test kontrol listesini baştan sona uygulayın: her biri bir komut ve beklenen sonuçla birlikte gelen 25 somut kontrol. Liste bağlantı, TLS, kimlik doğrulama, ACL'ler, mesaj semantiği, dayanıklılık ve kapasiteyi kapsar; yani production olaylarının gerçekten başladığı alanları.
Tüm örnekler Mosquitto komut satırı istemcilerini (mosquitto_pub, mosquitto_sub) ve broker.connectmq.com adresini kullanır. Host, port ve kimlik bilgilerini kendi broker'ınızınkilerle değiştirin. Aksi belirtilmedikçe istemciler MQTT 3.1.1 konuşur; MQTT 5 davranışını test etmek için -V mqttv5 ekleyin.
export HOST=broker.connectmq.com
export T=testmqtt/checklist-$RANDOM # bu çalıştırmaya özel benzersiz topic öneki
export AUTH="-u $MQTT_USER -P $MQTT_PASS"
export TLS="-p 8883 --capath /etc/ssl/certs"Bağlantı (kontrol 1–5)
1. DNS beklenen adrese çözümleniyor. dig +short $HOST, istemcilerinizin kullandığı her ağın (ofis, bulut VPC'si, hücresel APN) içinden beklediğiniz IP'leri döndürmelidir.
2. Her listener portuna erişilebiliyor. Açmayı planladığınız her port için succeeded (veya open), açmadıklarınız için hata bekleyin:
for p in 1883 8883 8083 8084; do nc -zv -w 3 $HOST $p; done3. İstemci bir CONNACK alıyor. mosquitto_pub -h $HOST -t $T/ping -m hi -d komutu Client … received CONNACK (0) yazdırır. Başka herhangi bir çıktı ya da takılma; firewall, proxy veya listener sorununa işaret eder.
4. WebSocket endpoint'i upgrade yapıyor. Tarayıcılar /mqtt path'i ile 8084 portuna ihtiyaç duyar. Handshake HTTP/1.1 101 Switching Protocols ile yanıt vermelidir:
curl -si --http1.1 -m 5 https://$HOST:8084/mqtt \
-H "Connection: Upgrade" -H "Upgrade: websocket" \
-H "Sec-WebSocket-Version: 13" -H "Sec-WebSocket-Protocol: mqtt" \
-H "Sec-WebSocket-Key: $(openssl rand -base64 16)" | head -1Ardından gerçek bir tarayıcının da çalıştığını doğrulamak için online MQTT istemcisinden bağlanın.
5. Bağlantı süresi bütçe dahilinde. Cihazlarınızın bulunduğu bölgeden TLS üzerinden time mosquitto_pub -h $HOST $TLS $AUTH -t $T/ping -m hi çalıştırın. Bir bütçe belirleyin (örneğin hücresel ağda 1–2 saniye) ve bunun üzerindeki sonuçları başarısız sayın.
TLS ve kimlik doğrulama (kontrol 6–11)
6. Sertifika zinciri ve hostname doğrulanıyor. Verify return code: 0 (ok) ve aylar sonrasına ait bir son kullanma tarihi bekleyin:
openssl s_client -connect $HOST:8883 -servername $HOST -verify_return_error </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -enddateBuradaki bir hata, cihazların ileride certificate verify failed olarak raporlayacağı şeydir. MQTT TLS bağlantısını test etmek her varyantı ele alır.
7. Düz metin, kapalı olması gereken yerde kapalı. Production istemcileri TLS kullanmak zorundaysa production broker'ınızdaki 1883 portu bağlantıları reddetmelidir (kontrol 2, 1883 için başarısız olmalıdır).
8. Anonim istemciler reddediliyor. Kimlik bilgisi olmadan Connection error: Connection Refused: not authorised. bekleyin.
mosquitto_pub -h $HOST $TLS -t $T/anon -m x9. Hatalı şifreler reddediliyor. Yanlış bir şifreyle Connection Refused: bad user name or password. bekleyin (MQTT 5'te reason code 0x86). Diğer kodlara MQTT reason code aracı ile bakabilirsiniz.
mosquitto_pub -h $HOST $TLS -u "$MQTT_USER" -P wrong-password -t $T/auth -m x10. ACL'ler yabancı topic'leri engelliyor. Bir cihaz kullanıcısıyla giriş yapın ve onun namespace'i dışına publish edin. MQTT 3.1.1'de broker mesajı sessizce atar; bu yüzden yetkili bir subscriber ile hiçbir şeyin ulaşmadığını doğrulayın. MQTT 5 ve QoS 1'de ret bilgisi PUBACK içinde gelir; debug çıktısında RC:135 (0x87 Not authorized) görünür:
mosquitto_pub -h $HOST $TLS $AUTH -V mqttv5 -q 1 -d -t other-tenant/secret -m x11. Cihaz kullanıcıları # topic'ine abone olamıyor. mosquitto_sub -h $HOST $TLS $AUTH -t '#' -C 1 -W 5 komutu All subscription requests were denied. yazdırmalıdır. Eksiksiz bir ACL matrisi testi için MQTT ACL izinlerini test etmek makalesine bakın.
Mesaj semantiği (kontrol 12–18)
12. Publish/subscribe gidiş-dönüşü çalışıyor. Abone olun, benzersiz bir token yayınlayın ve bir zaman aşımı içinde alın. Bir dakikalık smoke test betiği tam olarak bunu, başarılı/başarısız çıkış koduyla yapar.
13. QoS 1 onaylanıyor. mosquitto_pub -h $HOST -q 1 -d -t $T/qos -m x çıktısında received PUBACK görünür. -q 2 ile PUBREC ve PUBCOMP bekleyin.
14. Retained mesajlar saklanıyor ve temizleniyor.
mosquitto_pub -h $HOST -t $T/retained -m on -r -q 1
mosquitto_sub -h $HOST -t $T/retained -C 1 -W 5 -v # retained değeri yazdırır
mosquitto_pub -h $HOST -t $T/retained -r -n # boş retained payload onu temizler
mosquitto_sub -h $HOST -t $T/retained -C 1 -W 5 -v # zaman aşımı: retained mesaj kalmadı15. Temiz olmayan bağlantı kopmasında Last Will yayınlanıyor.
mosquitto_sub -h $HOST -t $T/status -v &
mosquitto_sub -h $HOST -i lwt-check -k 5 -t $T/none \
--will-topic $T/status --will-payload offline &
sleep 2; kill -9 $! # simüle edilmiş çökmeİlk subscriber …/status offline yazdırır. Temiz bir DISCONNECT bunu tetiklememelidir.
16. Kalıcı oturumlar çevrimdışı mesajları kuyruğa alıyor. Sabit bir client ID ve -c (clean session kapalı) ile bağlanın, istemciyi durdurun, QoS 1 ile publish edin ve aynı komutla yeniden bağlanın; kuyruktaki mesaj gelir:
mosquitto_sub -h $HOST -i queue-check -c -q 1 -t $T/queue -W 3 # oturumu oluşturur
mosquitto_pub -h $HOST -q 1 -t $T/queue -m while-offline
mosquitto_sub -h $HOST -i queue-check -c -q 1 -t $T/queue -C 1 -W 517. Tekrarlanan client ID'ler beklendiği gibi davranıyor. Aynı -i ile iki istemci başlatın; broker ilkinin bağlantısını keser. Her cihazın benzersiz bir ID ürettiğinden emin olun (client ID oluşturucu yardımcı olur), aksi halde bitmeyen yeniden bağlanma döngüleri görürsünüz.
18. Maksimum mesaj boyutu biliniyor. En büyük gerçek mesajınızın hemen üzerinde bir payload yayınlayın ve broker'ın davranışını doğrulayın. Büyük MQTT payload'larını test etmek bir boyut tarama betiği içerir.
Dayanıklılık (kontrol 19–22)
19. İstemciler broker yeniden başlatıldıktan sonra yeniden bağlanıyor. Staging'de broker'ı yeniden başlatın (docker restart mosquitto veya systemctl restart mosquitto) ve her istemci türünün elle müdahale olmadan yeniden bağlandığını, yeniden abone olduğunu ve publish etmeye devam ettiğini doğrulayın.
20. Ölü bağlantılar tespit ediliyor. Broker'a giden trafiği sessizce düşürün (sudo iptables -A OUTPUT -p tcp --dport 8883 -j DROP) ve istemcinin bunu yaklaşık 1,5 × keep-alive aralığı içinde fark ettiğini doğrulayın; ardından kuralı kaldırın. MQTT için kaos testi, bunu tc netem ve Toxiproxy ile nasıl otomatikleştireceğinizi gösterir.
21. Yeniden bağlanmalar jitter'lı backoff kullanıyor. Yeniden başlatmadan sonra bağlantı denemeleri tek bir tepe noktasında yığılmak yerine birkaç saniyeye yayılmalıdır. İstemci log'larını veya broker'ın bağlantı hızı grafiğini kontrol edin.
22. Cluster kullanıyorsanız failover çalışıyor. Bir node'u durdurun; istemcilerin başka bir node'a geçtiğini, oturumların tasarlandığı gibi korunduğunu ve hiçbir retained durumun kaybolmadığını doğrulayın.
Kapasite ve operasyon (kontrol 23–25)
23. Broker beklenen tepe yükün 2 katını kaldırıyor. Gerçek payload boyutunuz, QoS seviyeniz ve topic yapınızla bir yük testi çalıştırın (MQTT broker yük testi makalesine bakın) ve p99 gecikmeyi ile hata oranını kaydedin.
24. Metrikler görünür durumda. Bağlı istemciler, mesaj hızları ve atılan mesajlar bir dashboard'da görünür. Mosquitto'da (izin verilen yerlerde): mosquitto_sub -h $HOST $AUTH -t '$SYS/broker/clients/connected' -C 1 -v.
25. Alarmlar gerçekten tetikleniyor. Bilerek bir alarm tetikleyin: her zaman çevrimiçi olması gereken bir test istemcisini durdurun ya da bir kontrolü süresi dolmak üzere olan bir sertifikaya yönlendirin ve alarmın bir insana ulaştığını doğrulayın.
Kontrol listesini betiğe dönüştürmek
| Kontroller | Elle süre | Nasıl otomatikleştirilir |
|---|---|---|
| 1–6, 8–9, 12–16 | Dakikalar | mosquitto_pub/mosquitto_sub kullanan, her kontrol için çıkış kodu veren Bash betiği |
| 10–11, 17–18 | Dakikalar | Aynı betik, özel test kullanıcılarıyla |
| 19–22 | Saatler | Betikli yeniden başlatmalar ve ağ arızaları içeren staging job'ı |
| 23–25 | Yarım gün | Zamanlanmış yük testi ve izleme kuralları |
Önce hızlı kontrolleri betiğe dökün ve bunları CI'da ve her broker değişikliğinden sonra çalıştırın; yavaş olanları release kontrol listesinde tutun.
3, 12 ve 14 numaralı kontrolleri tarayıcıda çalıştırın
Bu 25 kontrolü geçen bir broker, ilk günde önemli olan her şeyi kanıtlamış olur: istemciler ona güvenli şekilde ulaşır, yalnızca doğru istemciler içeri girer, mesajlar tasarlandığı gibi davranır ve arızalar kendiliğinden toparlanır. Komutları deponuzda saklayın ve broker, yapılandırması ya da sertifikaları her değiştiğinde yeniden çalıştırın.
Sıkça sorulan sorular
Bir MQTT broker test kontrol listesini çalıştırmak ne kadar sürer?
Bağlantı, güvenlik ve mesajlaşma kontrolleri elle bir saatten kısa, betiğe döküldüğünde ise birkaç saniye sürer. Dayanıklılık ve yük kontrolleri bir staging ortamı gerektirir ve ilk seferde genellikle yarım gün alır.
Canlıya geçmeden önce en önemli MQTT kontrolleri hangileridir?
Geçerli sertifikalı TLS, anonim ve hatalı şifreli girişlerin reddedilmesi, yabancı topic'leri engelleyen ACL'ler, çalışan bir Last Will ve broker yeniden başlatıldıktan sonra istemcilerin yeniden bağlanması. Production'da en çok can yakan hatalar bunlardır.
Bu kontrolleri herkese açık bir test broker'ında çalıştırabilir miyim?
Bağlantı ve mesajlaşma kontrollerini evet. Kimlik doğrulama, ACL, yeniden başlatma ve yük kontrolleri ise kontrolünüzdeki bir broker gerektirir; çünkü paylaşımlı bir sandbox'ın kendi açık yapılandırması vardır ve yük altına sokulmamalıdır.
