Informations sur les champs de données que le serveur de l’outil de données peut traiter pour créer un jeu de données.
Les données d’événement utilisées pour créer un jeu de données résident dans des fichiers appelés sources de journal. Les données disponibles dans les sources du journal sont appelées données d’événement, car chaque enregistrement de données représente un enregistrement de transaction ou une instance unique d’un événement associé à un horodatage.
Les données d’événement d’une source de journal sont collectées en temps réel par Sensors. Les données d’événement collectées par Sensors les serveurs HTTP et d’applications sont transmises aux serveurs de l’outil de données, qui convertissent les données en fichiers journaux compressés ( .vsl). Les données d’événement qui résident dans un fichier plat, un fichier XML ou une source de données ODBC sont lues par le serveur de l’outil de données, qui fournit des décodeurs que vous définissez pour extraire un ensemble commun de champs de données de ces différents formats.
Les sections suivantes fournissent des informations sur les champs de données (appelés champs d’enregistrement de données d’événement ou champs d’entrée de journal) qui sont collectés par Sensors ou lus et mis à la disposition du serveur de l’outil de données.
Les noms des champs suivent généralement la convention d'appellation du format de fichier journal étendu W3C. La plupart des champs comportent des préfixes qui indiquent la source des informations contenues dans le champ :
Les fichiers journaux ( .vsl) contiennent les champs de données d’événement collectés à partir des serveurs par Sensors le serveur de l’outil de données et utilisés par celui-ci dans le processus de construction des jeux de données. Le tableau suivant répertorie les champs d’un enregistrement de données d’événement type tel qu’il est enregistré par Sensor:
Champ | Description |
---|---|
c-ip | Adresse IP du client telle qu’elle est incluse dans la requête envoyée au serveur. Exemple : 207.68.146.68 |
cs(cookie) | Cookies envoyés par le client avec la requête. Exemple : v1st=42FDF66DE610CF36; ASPSESSIONIDQCATDAQC=GPIBKEIBFBFIPLOJMKCAAEPM; |
cs(referrer) | Chaîne de référent HTTP envoyée par le client au serveur avec la requête. Exemple : http://www.mysite.net/cgi-bin/websearch?qry |
cs(user-agent) | Chaîne envoyée par le client avec sa requête au serveur qui indique le type d’agent utilisateur du client. Exemple : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2 |
cs-method | Type de méthode de la requête HTTP. Exemple : GET Référence : http://www.w3.org/TR/2000/NOTE-shoplogfileformat-20001115/#field_method |
cs-uri-query | portion de chaîne de requête de l’URI (racine + chaîne de requête = URI). Ce point est précédé d’un point d’interrogation (?) et peut contenir une ou plusieurs paires nom-valeur séparées par des esperluettes (&). Exemple : page=page d’accueil |
cs-uri-stem | Partie racine de l’URI (racine + chaîne de requête = URI). La racine est le chemin réel ou logique vers la ressource demandée sur le serveur. Exemple : /index.asp |
sc(content-type) | Type de contenu de la ressource demandée par le client tel que rapporté par le serveur. Exemples : text/html, image/png, image/gif, vidéo/mpeg |
sc-bytes | Nombre d’octets de données envoyés du serveur au client en réponse à la demande Exemple : 4996 |
sc-status | Code d’état renvoyé au client par le serveur. Exemple : 200 Référence : http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html |
s-dns | Nom de domaine complet ou adresse IP de l’hôte de la ressource demandée. Exemple : www.adobe.com |
x-experience | Liste de tous les noms et groupes d’expériences contrôlés auxquels le client est membre au moment de la demande. Exemple : VSHome_Exp.Group_1,VSRistration_Exp.Group_2 |
x-timestamp | Date et heure (GMT) auxquelles la demande a été reçue par le serveur. Le temps est exprimé sous la forme du nombre de 100 nanosecondes depuis le 1er janvier 1600. Exemple : Le mardi 13 septembre 2005, 127710989320000000 correspond à la valeur de l’horodatage X pour 11:28:52.0000000. |
x-trackingid | Valeur hexadécimale 64 bits de l’identificateur de navigateur unique détecté dans un cookie persistant tel qu’il est défini par un capteur et fourni par le client avec une requête à un serveur. Exemple : 42FDF66DE610CF36 |
Le tableau ci-dessous répertorie des exemples de champs dérivés par le serveur de outils de données des champs d’enregistrement de données d’événement de ligne de base :
Champ | Description |
---|---|
cs(cookie)(name) | Valeur d’une paire nom-valeur donnée dans un cookie. |
cs(referrer-domain) | Nom de domaine ou adresse IP de l’URI de référence HTTP.
Remarque : Ce champ est en lecture seule. |
cs(referrer-host) | Nom d’hôte complet du référent. Exemple : Si cs(referrer) est http://my.domain.com/my/page , cs(referrer-host) est my.domain.com . |
cs(referrer-query)(name) | Valeur d’une chaîne de requête de référent.
Remarque : Vous ne pouvez pas accéder à une valeur de chaîne de requête de référent à l’aide du champ cs(referrer)(name). |
cs-uri | URI complet (racine + chaîne de requête = URI entier). Exemple : /shopping/checkout.html?product1=8Track&product2=casette&product3=cd |
cs-uri-query(name) | Valeur associée au nom donné. S’il existe plusieurs valeurs pour le nom donné, ce champ renvoie la dernière de ces valeurs. Exemples :
|
ctime | x-timestamp exprimé en secondes depuis le 1er janvier 1970. Ce champ est également appelé x-unixtime. |
date | X-timestamp au format AAAA-MM-JJ. |
time | x-timestamp au format HH:MM:SS. |
x-local-timestring | x-timestamp converti en fuseau horaire local spécifié dans le fichier Transformation.cfg pour le jeu de données. Le format est AAAA-MM-JJ HH:MM:SS.mmm.
Remarque : Vous pouvez également définir des conversions temporelles, telles que x-local-timestring, dans le fichier Log Processing.cfg . Pour plus d’informations, voir Fichier de configuration de traitement des journaux . |
x-log-source-id | Identifiant correspondant à la source du journal pour une entrée de journal particulière. Pour que l'identifiant soit enregistré, vous devez le spécifier dans le champ ID source du journal du fichier Log Processing.cfg lors de la définition de Sensor , de fichier journal ou de sources de données ODBC. Pour plus d’informations, voir Fichier de configuration de traitement des journaux . Exemple : de VSensor01. |
x-mask | Modèle de masque des sources de données Sensor (dérivé des noms de fichiers .vsl ). Pour un fichier dont le nom est au format AAAAMMJJ-SENSORID.VSL , x-mask est SENSORID. |
x-timestring | x-timestamp au format AAAA-MM-JJ HH:MM:SS.mmm. |
x-unixtime | Heure UNIX décimale dérivée de l’horodatage X. |
Sensor, lorsqu’il est utilisé sur un serveur, peut collecter des champs de données d’événement à partir de n’importe quel en-tête ou variable de réponse HTTP valide disponible par le biais de l’API du serveur. Pour collecter ces champs de données, vous devez spécifier les champs d’en-tête ou les variables de votre choix dans le fichier txlogd.confde configuration pour Sensor. For more information, see the Data WorkbenchSensorGuide.