Passer au contenu principal
Quand un client dit que ses accusés de réception ont cessé d’arriver, la réponse est généralement déjà connue du gateway et simplement pas écrite. smsg.diagnostics décide dans quelle mesure elle l’est.
Réglez-le depuis le panneau de contrôle : Configuration → Gateway → Diagnostics. Pas de SQL, et il prend effet au prochain poll de configuration — pas de redémarrage.

​
Les trois niveaux

problems est le niveau à utiliser. C’est celui qui répond à une question de support sans que personne n’ait à activer quelque chose d’abord — ce qui est tout le problème qu’il existe pour résoudre, parce que le moment où vous avez besoin des preuves est toujours après que la chose s’est produite.

​
Le définir ne change rien tant que vous ne le définissez pas

smsg.diagnostics fournit la valeur par défaut des deux réglages ci-dessous. Il ne les écrase pas. Ainsi un gateway mis à niveau sans niveau défini se comporte exactement comme avant, et un opérateur qui avait déjà réglé message.trace.mode conserve son choix. Le panneau nomme tout réglage qui outrepasse le niveau, parce qu’un niveau qui semble en vigueur alors qu’une clé le supplante silencieusement est le seul état déroutant que cet arrangement peut produire.

​
Ce qu’il ne touche délibérément pas

Aucun niveau ici ne stocke le contenu des messages.smsg.cdr.body conserve le texte des messages des clients. print.msgs journalise les numéros de téléphone, les corps de messages et les mots de passe de bind. Les deux sont des décisions sur la rétention de données client, prises par des opérateurs dans des juridictions qui répondent différemment à cette question — pas des molettes pour régler le niveau de détail souhaité aujourd’hui.Augmenter un niveau de diagnostic pour traquer un accusé ne doit jamais commencer à retenir du contenu de message par effet de bord, donc aucun des deux ne fait partie de smsg.diagnostics. Définissez-les séparément, délibérément, et désactivez-les à nouveau.

​
Ce que problems enregistre

Les événements atterrissent dans cdr_event et apparaissent sur la page d’un message sous Customer exchange : Les adresses de callback sont stockées avec la query string retirée. Une dlr-url transporte couramment une clé d’API, et ces lignes sont largement lisibles, donc l’endpoint est conservé comme schéma, hôte et chemin et rien d’autre. Cela n’a aucun réglage et aucun contournement.

​
Voir ce que leur point de terminaison a répondu

Un code de statut dit que le callback a échoué. Il ne dit pas pourquoi, et la raison se trouve généralement dans le corps renvoyé par le point de terminaison — {"error": "unknown template id"} et une page de connexion en HTML sont deux pannes entièrement différentes qui arrivent toutes deux comme un 500.
Le tableau Échange client sur la page d’un message affiche alors une cellule Réponse sur chaque tentative de callback, qui se déplie sur les 500 premiers caractères de la réponse et un ensemble fixe d’en-têtes : type, longueur et encodage du contenu, retry-after, location et x-request-id.
Livré à off, et c’est délibérément une clé distincte de smsg.cdr.events. Enregistrer qu’un callback a échoué et conserver ce que le serveur d’un client a répondu sont deux décisions différentes, et aucun niveau de diagnostic n’active la seconde à votre place.Rien en dehors de cette liste d’en-têtes n’est conservé : un set-cookie ou un authorization renvoyé par un point de terminaison n’est pas stocké — il n’est jamais copié au départ.
Sans cela, la page affiche non capturé en face de chaque tentative, ce qui est une réponse différente de non disponible : la seconde signifie que le gateway est antérieur à la fonctionnalité et qu’aucun réglage n’y changera rien. Une tentative qui affiche pas de réponse n’a reçu aucune réponse à conserver — la requête a été refusée ou a échoué avant que le point de terminaison ne réponde — et activer la capture n’y aurait rien changé.

​
registered_delivery, et la valeur qui surprend

Un accusé supprimé est presque toujours ceci : 0x02 est celui qui produit « nous recevons certains accusés mais pas d’autres ». L’événement receipt.suppressed affiche l’octet stocké pour qu’il puisse être lu plutôt que deviné.

​
L’augmenter pour un seul message

Envoyez ensuite le message, lisez le log, et remettez-le à problems. verbose journalise chaque échec de routage, réponse de submit et mise en file — le laisser activé représente un vrai volume d’écriture sur un gateway en production.