GetHistograms - - Centre de documentation Alibaba Cloud

Description de l'opération

L'hôte (Host) dans la syntaxe de la requête se compose du nom du projet et du point de terminaison de Simple Log Service. Spécifiez le projet dans l'hôte.
La division des sous-intervalles dans la réponse est toujours stable. Si la plage de temps de votre requête reste inchangée, la division des sous-intervalles dans la réponse reste également inchangée.
Lorsque le nombre de journaux impliqués dans une requête change de manière significative, l'API Simple Log Service ne peut pas prédire combien de fois cette opération doit être appelée pour obtenir des résultats complets. Vérifiez la valeur de l'état d'avancement dans la réponse de chaque requête pour déterminer s'il faut appeler à nouveau cette opération afin d'obtenir les résultats complets finaux. Chaque appel répété consomme le même nombre de CU de requête.
La latence entre l'écriture d'un journal dans un Logstore et l'interrogation du journal à l'aide des opérations LogSearch (GetHistograms et GetLogs) varie en fonction du type de journal. Simple Log Service classe les journaux dans les deux types suivants en fonction des horodatages UNIX des journaux :
- Données en temps réel : le point temporel dans le journal se situe dans la plage de (-180 secondes, 900 secondes] par rapport à l'heure actuelle du serveur. Par exemple, si l'heure du journal est UTC 2014-09-25 12:03:00 et que le serveur reçoit le journal à UTC 2014-09-25 12:05:00, le journal est traité comme des données en temps réel. La latence entre l'écriture des données en temps réel et leur interrogation dans l'interface LogSearch est de 3 secondes.
- Données historiques : le point temporel dans le journal se situe dans la plage de [-7 × 86400 secondes, -180 secondes) par rapport à l'heure actuelle du serveur. Par exemple, si l'heure du journal est UTC 2014-09-25 12:00:00 et que le serveur reçoit le journal à UTC 2014-09-25 12:05:00, le journal est traité comme des données historiques. Cela se produit généralement dans les scénarios de remplissage de données. La latence maximale entre l'écriture des données en temps réel et leur interrogation est de 3 secondes. Dans 99,9 % des cas, la requête est effectuée en moins d'une seconde.

Remarque

Simple Log Service calcule la différence entre l'heure du journal (nom du champ : __time__) et l'heure de réception par le serveur (nom du champ : __tag__:__receive_time__). Si la différence se situe dans la plage de (-180 secondes, 900 secondes], le journal correspond à des données en temps réel. Si la différence se situe dans la plage de [-7 × 86400 secondes, -180 secondes), le journal correspond à des données historiques.

Simple Log Service fournit un exemple d'utilisation des requêtes GetHistograms dans le SDK Java. Pour plus d'informations, consultez la section Utiliser GetHistograms pour interroger la distribution des journaux.

Testez maintenant

Testez cette API dans OpenAPI Explorer, sans signature manuelle. Les appels réussis génèrent automatiquement du code SDK correspondant à vos paramètres. Téléchargez-le avec une sécurité intégrée des identifiants pour une utilisation locale. Testez cette API dans OpenAPI Explorer, sans signature manuelle. Les appels réussis génèrent automatiquement du code SDK correspondant à vos paramètres. Téléchargez-le avec une sécurité intégrée des identifiants pour une utilisation locale.

Test

Autorisation RAM

Aucune autorisation n'est requise pour cette opération. En cas de problème, contactez le support technique.

Syntaxe de la requête

GET /logstores/{logstore}/index?type=histogram HTTP/1.1

Paramètres de chemin

Paramètre	Type	Requis	Description	Exemple
logstore	string	Oui	Le nom du Logstore.	test-logstore

Paramètres de requête

Paramètre	Type	Requis	Description	Exemple
project	string	Oui	Le nom du projet.	ali-test-project
from	integer	Oui	L'heure de début du sous-intervalle. Cette valeur est un horodatage UNIX représentant le nombre de secondes écoulées depuis le 1er janvier 1970 à 00:00:00 UTC.	1409529600
to	integer	Oui	L'heure de fin du sous-intervalle. Cette valeur est un horodatage UNIX représentant le nombre de secondes écoulées depuis le 1er janvier 1970 à 00:00:00 UTC.	1409569200
topic	string	Non	Le sujet des journaux.	topic
query	string	Non	L'instruction de requête. Seules les instructions de requête sont prises en charge. Les instructions d'analyse ne sont pas prises en charge. Pour plus d'informations sur la syntaxe de requête, consultez la section Syntaxe de requête.	with_pack_meta

Éléments de réponse

Élément	Type	Description	Exemple
	array
	object
from	integer	L'heure de début du sous-intervalle. Cette valeur est un horodatage UNIX représentant le nombre de secondes écoulées depuis le 1er janvier 1970 à 00:00:00 UTC. L'intervalle de temps suit le principe fermé à gauche et ouvert à droite. L'intervalle inclut l'heure de début mais exclut l'heure de fin. Si les valeurs de from et to sont identiques, l'intervalle est invalide et la fonction renvoie une erreur.	1409529600
to	integer	L'heure de fin du sous-intervalle. Cette valeur est un horodatage UNIX représentant le nombre de secondes écoulées depuis le 1er janvier 1970 à 00:00:00 UTC. L'intervalle de temps suit le principe fermé à gauche et ouvert à droite. L'intervalle inclut l'heure de début mais exclut l'heure de fin. Si les valeurs de from et to sont identiques, l'intervalle est invalide et la fonction renvoie une erreur.	1409569200
count	integer	Le nombre de journaux interrogés dans le sous-intervalle.	2
progress	string	Indique si les résultats de la requête dans le sous-intervalle sont complets. Complete : la requête est terminée et les résultats renvoyés sont complets. Incomplete : la requête est terminée mais les résultats renvoyés sont incomplets. Répétez la requête pour obtenir des résultats complets.	Complete

Exemples

JSON format

[
  {
    "from": 1409529600,
    "to": 1409569200,
    "count": 2,
    "progress": "Complete"
  }
]

Codes d'erreur

Consultez Codes d'erreur pour la liste complète.

Notes de version

Consultez Notes de version pour la liste complète.