Qu'est-ce que l'alimentation XML?

Le flux XML est un flux de données formaté XML qui transporte des informations de surveillance pendant une période demandée pour un périphérique ou une tâche.

Où puis-je obtenir des informations de base sur le processus de demande XML ?
Quelle est la demande de base XML FEED ?

La demande basic XML FEED est une URL spécialement formatée avec un certain nombre de paramètres GET, divisés par le symbole «» que vous demandez par protocole HTTPS.

Le contenu de l’URL de base XML FEED est construit à partir des commandes suivantes :

 [base_service_address]  +  [account_uid]  +  [Site_id]  +  [parameter1]+[parameter2]... 

exemple:

 https://xmlreporter.dotcom-monitor.com/reporting/xml/responses.aspx  ?pid=4229AF4F0FB545AEA75EAF2013E51BB7  &Site=12345  &Type=Overall 

La description des paramètres supplémentaires est disponible dans l’article Using the XML Reporting Service (XRS).

Comment puis-je obtenir un id d'appareil ou un ID de tâche spécifique ?

Ouvrez l’appareil cible dans la liste pour modifier. Dans la barre d’adresse du navigateur, vous verrez quelque chose comme

https://user.dotcom-monitor.com/ClientID/DeviceEdit?pid=dc7f4ff2ca944dekjh1078b96707002& deviceId=63698 & taskId=132834 

L’deviceId=63698 est l’id de l’appareil.
La tâcheId=132834 est l’ID de tâche.

Comment puis-je voir l’identifiant de compte unique (UID de compte) ?

L’UID de compte (alias UID d’intégration) est l’identificateur unique de votre compte pour le flux XML. Vous trouverez l’UID de compte pour le flux XML sous Configurer > les intégrations. Vous pouvez également créer une intégration pour le flux XML en ajoutant une nouvelle intégration avec le type de flux XML.

Pour un compte racine avec départements, si vous devez extraire un rapport sur un service particulier, ajoutez une intégration de flux XML et sélectionnez l’option Autoriser l’accès aux données du service lors de la configuration de l’intégration . Utilisez l’UID de cette intégration de flux XML (avec accès aux données du service) pour extraire des données sur un service particulier conjointement avec l’ID de compte du service (services de compte>) dans les paramètres de demande.

Ok, à quoi ça ressemble dans la pratique ?

Par conséquent, en allant dans Configurer > les intégrations, ajoutez Nouvelle intégration avec le type de flux XML . Copiez un UID de flux XML, par exemple, 123456789456123789456123, puis insérez où Xs pour PID. Et puis aller à Device > Edit. Copiez l’iD de l’appareil, par exemple, 12345, à partir de l’URL, insérez où Xs pour le site :

http://xmlreporter.dotcom-monitor.com/reporting/xml/responses.aspx?pid=XXXXXXXXXXX&Site=XXXXX&Type=Detail&Options=RequestDetails
Quels sont les nouveaux détails XML supplémentaires sur DNS etc.

Le terme que nous utilisons est «Détails XML étendus», ils comprennent tous les enfants sous-jacents arbre de réponse, c’est-à-dire la liste de tous les éléments chargés. Cette option est disponible en ajoutant le paramètre «Options=RequestDetails».

Vous pouvez trouver comment activer les « détails XML étendus » dans l’article Using the XML Reporting Service (XRS).

Comment filtrer la réponse par agent de surveillance ?

Si vous souhaitez que le flux XML affiche les résultats uniquement à partir de certains agents de surveillance, ajoutez le paramètre de chaîne «Location» à l’URL de la demande de la manière suivante :

http://xmlreporter.dotcom-monitor.com/reporting/xml/responses.aspx?pid=XXXXXXXXXXX&Site=XXXXX&Type=Detail &Location=[agent1]&Location=[agent2]...&Location=[agent5] ...

exemple

http://xmlreporter.dotcom-monitor.com/reporting/xml/responses.aspx?pid=4229AF4F0FB545AER75EAF2013EB1BB7&Site=77895&Type=Detail&Location=MN, USA &Location=Amazon-US-East&Location=Frankfurt,Germany&Location=Sydney, AU 

Liste des valeurs des chaînes des agents :

Amérique

  • MN, États-Unis d’Amérique
  • NY, États-Unis d’Amérique
  • CA, États-Unis d’Amérique
  • FL, États-Unis d’Amérique
  • Montréal, Canada
  • CO, États-Unis d’Amérique
  • TX, États-Unis d’Amérique
  • VA, États-Unis d’Amérique
  • Amazone-Etats-Unis-Est
  • Buenos Aires, Argentine
Europe

  • Londres, Royaume-Uni
  • Francfort, Allemagne
  • Amsterdam, Pays-Bas
  • Tel-Aviv, Israël
Asie, Australie, Afrique

  • Hong Kong, Chine
  • Sydney, UA
  • Amazon, Japon
  • Shanghai, Chine
  • Afrique du Sud
Quelles sont les définitions pour les champs de réponses ?

exemple:

<Response> 
<ID>3424533543</ID> 
<Name>Demo request</Name> 
<URL>http://demo.webportal.com/APIv1/json?userid=test;userweight=22;ACT=DASW</URL>
<Monitoring-Date-Time>3/26/2014 12:38:38 PM</Monitoring-Date-Time> 
<Duration>114</Duration>
<DnsTime>0</DnsTime>
<SSLTime>0</SSLTime> 
<ConnectionTime>15</ConnectionTime> 
<RequestTime>0</RequestTime> 
<FirstPacketTime>97</FirstPacketTime> 
<DownloadTime>2</DownloadTime> 
<Status>S</Status> 
<Monitoring-Location>FL, USA</Monitoring-Location> 
</Response>
  • Durée – Temps global pris pour terminer la tâche (Fondamentalement – somme des temps ci-dessous)
  • DnsTime – est le temps nécessaire pour résoudre un nom d’hôte (par exemple www.google.com) dans une adresse IP numérique (par exemple 216.239.59.99).
  • SSLTime – est le temps nécessaire pour terminer le processus de poignée de main SSL.
  • ConnectionTime – est le temps nécessaire pour créer une connexion TCP au serveur Web (ou proxy). Les connexions Keep-Alive sont souvent utilisées pour éviter les frais généraux de connexion répétée au serveur Web.
  • RequestTime – est le temps nécessaire pour envoyer le message de demande HTTP au serveur et dépendra de la quantité de données qui est envoyée au serveur. Par exemple, les longs temps d’envoi résulteront du téléchargement de fichiers à l’aide d’un
  • FirstPacketTime – (Time To First Byte) temps écoulé pour commencer à recevoir des données à partir du serveur Web distant. En d’autres termes, le temps entre la demande et la réponse d’abord byte reçu.
  • DownloadTime – est le temps nécessaire pour lire le message de réponse à partir du serveur. Cette valeur dépendra de la taille du contenu retourné, de la bande passante réseau et de l’utilisation de la compression HTTP. En d’autres termes, le temps entre la réponse d’abord et le dernier octets.