MQTT externe

Connectez Kilo IoT Server à votre propre broker MQTT — Mosquitto, AWS IoT Core, HiveMQ — avec authentification TLS et routage des topics.

External MQTT connecte le serveur Kilo IoT à un broker MQTT que vous exploitez déjà. La plateforme établit une connexion sortante vers le broker, s'abonne aux topics pertinents et consomme les messages dans le même pipeline de routage que les données Cloud MQTT. Choisissez cette option lorsque le broker fait déjà partie de votre empreinte d'infrastructure — un cluster Mosquitto sur site, AWS IoT Core, un déploiement HiveMQ d'entreprise ou un broker géré par un fournisseur partagé entre plusieurs sites.

Quand External MQTT est le bon choix

• Un broker existant fait déjà partie des opérations. Les appareils y publient déjà ; plusieurs abonnés (historiens, tableaux de bord, plateformes d'intégration) en consomment déjà. Ajouter la plateforme comme un abonné supplémentaire est opérationnellement plus simple que de rerouter les éditeurs.

• Exigences de conformité ou de résidence des données stipulent que la télémétrie doit transiter par votre propre broker avant d'atteindre les consommateurs SaaS.

• Architectures hybrides où un traitement en périphérie sur site a lieu avant qu'un sous-ensemble de la télémétrie ne soit transféré vers la plateforme.

Pour les déploiements sans broker existant, Cloud MQTT est la voie la moins lourde.

Exigence de joignabilité

Kilo IoT Server se connecte sortant à votre broker, donc le broker doit être joignable depuis Internet public via DDNS, redirection de port ou IP publique dédiée. Un broker accessible uniquement sur un VLAN privé n'est pas joignable depuis le plan de contrôle cloud de la plateforme.

Le schéma de production standard consiste à utiliser une IP publique ou un nom d'hôte DDNS pour le broker, avec des règles de pare-feu contrôlant quelles sources peuvent se connecter.

Pour les déploiements de développement ou pilote, un tunnel d'exposition comme ngrok fonctionne pour des tests de courte durée — mais notez que l'utilisation d'un outil d'exposition ne confirme pas à elle seule que Kilo peut joindre le broker. Après avoir enregistré le connecteur, publiez un message de test et confirmez que les dernières données reçues se mettent à jour sur la page de détail du connecteur. C'est la seule façon de vérifier la joignabilité de bout en bout.

Options d'authentification

Le connecteur prend en charge quatre méthodes d'authentification, sélectionnables à la création :

Méthode	Quand l'utiliser	Champs de configuration
Anonyme	Réservé aux brokers de développement. Ne pas utiliser pour des brokers exposés en production — toute personne sur Internet qui trouve le broker peut publier ou s'abonner.	Aucun
Basique	Authentification par nom d'utilisateur et mot de passe. La configuration la plus courante pour les déploiements de production où TLS protège les identifiants en transit.	Nom d'utilisateur, mot de passe
Certificat	Authentification TLS mutuelle utilisant des certificats client. Niveau d'assurance le plus élevé ; standard pour les déploiements réglementés.	Fichier du certificat de l'AC, fichier du certificat client, fichier de clé privée (téléversés en tant que fichiers ; ne collez pas le contenu PEM)
Jeton JWT	Authentification basée sur un jeton compatible avec les brokers qui valident les JWT (p. ex. AWS IoT Core avec des autoriseurs personnalisés, ou d'autres brokers avec des plugins JWT).	Jeton

Pour la méthode Certificat, les trois fichiers téléversés constituent le côté client d'un échange mTLS ; le broker doit être configuré pour faire confiance à l'autorité de certification et pour valider le certificat client par rapport à celle-ci. La clé privée doit être non chiffrée au moment du téléversement.

Provisionnement du connecteur

1. Accédez à Connecteurs dans la barre latérale.

2. Cliquez sur Ajouter un connecteur.

3. Sélectionner External MQTT depuis le type de connecteur menu déroulant.

4. Renseignez :

   Champ	Obligatoire	Détails
   Nom	Oui	Libellé opérationnel, par ex. Mosquitto de l'usine 3 ou Cluster de brokers Amérique du Nord.
   URL du broker	Oui	URL complète avec schéma et port. Exemples : mqtts://broker.facility.example.com:8883, ssl://broker.example.com:8883.

5. Choisissez la méthode d'authentification et renseignez ses champs.

6. Cliquez sur Ajouter.

Le connecteur apparaît dans le tableau des connecteurs. Cliquez sur la page de détail pour trouver l' Dernières données reçues indicateur.

Étape de vérification

La joignabilité de bout en bout n'est confirmée que par la réception effective d'une publication sur la plateforme. Après avoir enregistré le connecteur :

1. Publiez un message de test sur votre broker sur n'importe quel topic auquel le connecteur est abonné.

2. Ouvrez la page de détail du connecteur dans Kilo.

3. Confirmez Dernières données reçues se met à jour en quelques secondes.

Un test simple en une seule commande depuis un hôte capable d'atteindre le broker :

mosquitto_pub \\
  -h broker.facility.example.com -p 8883 \\
  --cafile /path/to/ca.crt \\
  -u {username} -P {password} \\
  -t "test/connectivity" \\
  -m '{"hello":"world"}'

(Remplacez le schéma/le port et les identifiants par ceux correspondant à la méthode d'authentification de votre broker.)

Si Dernières données reçues ne se met pas à jour après une publication locale réussie, voir Dépannage. Les causes les plus courantes sont des règles de pare-feu entre la sortie de la plateforme et votre broker, des incohérences de liste d'autorisation IP, des sessions de tunnel expirées lors de l'utilisation de ngrok pour les tests, ou une mauvaise configuration TLS côté broker.

Déploiement de référence Mosquitto auto-hébergé

Pour les déploiements qui ont besoin d'une référence rapide pour configurer un broker Mosquitto auto-hébergé à des fins de test ou de pilote, le compose Docker minimal ressemble à ceci :

services:
  mosquitto:
    image: eclipse-mosquitto:2
    container_name: mosquitto
    restart: unless-stopped
    ports:
      - "1883:1883"
    volumes:
      - ./mosquitto/config:/mosquitto/config
      - ./mosquitto/data:/mosquitto/data

mosquitto.conf:

listener 1883
allow_anonymous false
password_file /mosquitto/config/passwd
persistence true
persistence_location /mosquitto/data/
log_dest stdout

Deux remarques opérationnelles :

• log_dest stdout La journalisation sur stdout est préférable à la journalisation dans des fichiers dans les déploiements conteneurisés. Les répertoires de journaux montés en bind échouent souvent sous SELinux/AppArmor ou à cause de divergences de propriété ; le stdout du conteneur est collecté par le pilote de journalisation Docker.

• Conflit sur le port 1883. Sur une infrastructure de développement ou partagée, le port 1883 peut déjà être occupé (par ex. un port-forward kubectl, un autre broker local). ss -tlnp \| grep 1883 identifie le processus qui l'occupe. Reconfigurez le port côté hôte (par ex. "1885:1883") et redirigez plutôt le nouveau port hôte — le port interne du conteneur peut rester 1883 pour les éditeurs du réseau.

Pour la terminaison TLS, un reverse-proxy séparé ou la configuration TLS native de Mosquitto (hors périmètre ici — voir la documentation Mosquitto) est nécessaire avant une exposition publique.

les limites

Les connecteurs External MQTT sont limités à 10 par organisation. Pour les déploiements nécessitant des intégrations de broker supplémentaires au-delà de cette limite, faites appel à l'équipe d'ingénierie de la plateforme lors de la planification du déploiement.