Skip to main content
Lisez les données de métriques avec l’API publique (V2). Récupérez une série temporelle pour des graphiques, une liste agrégée pour des tableaux, ou découvrez quelles métriques et tags possède un site. Tous les points de terminaison s’authentifient avec votre jeton d’API personnel et sont limités à un seul site_id.

​
Migrer depuis les métriques GraphQL

La lecture des métriques via l’API GraphQL est obsolète. Si votre intégration lit des données de métriques via GraphQL, utilisez cette comparaison pour la migrer vers le point de terminaison des séries temporelles de l’API REST (V2).

​
Interroger une série temporelle

Ce point de terminaison renvoie une ou plusieurs séries de points de données sur une plage temporelle. Utilisez-le pour dessiner des graphiques.

​
Corps de la requête

Chaque entrée select demande un champ de métrique. Fournissez un name de métrique, un objet tags, et un field (voir champs). Les valeurs de tags peuvent utiliser * comme caractère générique. Vous pouvez aussi fournir une aggregation (voir agrégations) et une valeur fill. Les valeurs de fill sont ZERO (par défaut), PREVIOUS et NONE. Les intégrations existantes peuvent aussi utiliser le champ optionnel draw_null_as_zero. Si vous envoyez les deux champs, fill est prioritaire. Utilisez des valeurs en majuscules pour field et aggregation. Le point de terminaison des séries temporelles ne prend pas en charge group_by.

​
Réponse

Renvoie un Timeseries avec la resolution, from, to interrogées et un tableau series. Chaque série possède un id, le name de la métrique, ses tags, le field qu’elle représente, min et max sur la plage, et un tableau data de points. Chaque point a un timestamp et une value numérique. Contrairement à l’API GraphQL de métriques, ce point de terminaison ne nécessite pas de requête séparée pour les clés de métriques. Utilisez le tableau series pour voir quelles combinaisons de tags et de champs ont renvoyé des données. Si une requête risque d’atteindre les limites de traitement, n’utilisez pas series.length comme nombre total de clés de métriques correspondantes.

​
Interroger une liste

Ce point de terminaison renvoie des valeurs de métriques agrégées regroupées en lignes. Utilisez-le pour créer des tableaux.

​
Corps de la requête

Un ListSelector est comme un sélecteur de séries temporelles, avec un id supplémentaire qui nomme la valeur du sélecteur dans l’objet data de chaque ligne. Les entrées group_by sont Name (regrouper par nom de métrique) ou Tag (regrouper par valeur de tag). Utilisez des valeurs en majuscules pour field et aggregation. Les valeurs de group_by, sensibles à la casse, sont Name et Tag. Si un sélecteur utilise * pour un tag dans tags, ajoutez ce même tag à group_by sous la forme {"Tag": "tag_name"}, sinon la requête échoue.

​
Réponse

Renvoie une List avec la resolution, from, to interrogées et un tableau rows. Chaque ligne a un id, un objet group des valeurs de tags qui la définissent, et un objet data de valeurs agrégées indexées par id de sélecteur (par exemple, { "mean": 42.5 }).

​
Paginer une liste

Ajoutez un objet pagination au corps de la requête pour lire la liste page par page :
  • per_page : combien de lignes renvoyer par page.
  • order : ASC ou DESC. Les lignes sont triées par leur id.
  • cursor : { "id": null } pour la première page.
Pour obtenir la page suivante, envoyez la même requête avec cursor.id défini sur l’id de la dernière ligne. Répétez jusqu’à ce qu’une page renvoie moins de lignes que per_page. Cette page est la dernière. Une réponse paginée a la même forme que toute autre réponse de liste.
La pagination a des limites. Une requête qui les dépasse renvoie une réponse 400 dont le champ error nomme le problème :
  • per_page accepte des valeurs de 1 à 1 000. Toute autre valeur renvoie pagination_invalid_per_page.
  • Une requête paginée lit jusqu’à 100 000 clés de métrique ou lignes sur l’ensemble de ses pages. Au-delà de cette limite, elle renvoie pagination_key_limit_exceeded au lieu d’un résultat partiel. Réduisez les filtres de tags ou la plage temporelle et renvoyez la requête.
  • Pour les métriques personnalisées, chaque tag utilisant un caractère générique * doit aussi apparaître dans group_by. Le name de la métrique ne peut pas contenir de caractère générique. Sinon, la requête renvoie pagination_requires_deterministic_grouping.
  • Les métriques d’événement event_duration et event_metric, ainsi que la métrique d’erreur d’incident incident_error_count, ne peuvent pas encore être paginées. Elles renvoient pagination_unsupported_for_selector. Interrogez-les dans une requête séparée, sans pagination.

​
Lister les noms de métriques

Renvoie chaque nom de métrique disponible pour un site.
Renvoie un tableau de chaînes.

​
Obtenir le type et les tags d’une métrique

Renvoie le type d’une métrique et les combinaisons de tags avec lesquelles elle peut être interrogée.
Renvoie un metric_type (GAUGE, COUNTER ou MEASUREMENT) et available_tags, un tableau où chaque entrée est une combinaison valide de clés de tag.

​
Timing des moniteurs de disponibilité

La métrique uptime_monitor_timing est une jauge qui enregistre la durée de chaque phase d’une vérification de disponibilité, en millisecondes. Le tag phase sélectionne la phase : dns, connect, tls, ttfb, download ou total. Pour savoir ce que mesure chaque phase, consultez timing de la requête. Interrogez la métrique avec region, phase, et soit le name, soit l’id du moniteur. phase se comporte différemment dans les deux points de terminaison de requête :
  • Dans une requête de série temporelle, phase accepte le caractère générique * et renvoie une série par phase.
  • Dans une requête de liste, chaque sélecteur doit nommer une phase. Ajoutez un sélecteur par phase souhaitée, et regroupez par region, name ou id, pas par phase.
Une phase que la vérification n’a pas mesurée est omise de la réponse. C’est le cas de tls pour une URL HTTP simple et de download sans vérification du corps. Cette requête de liste renvoie le temps moyen par phase et par région pour un moniteur :

​
Requêtes de métriques à forte cardinalité

Une requête de métrique a une forte cardinalité lorsqu’elle correspond à plus de séries que le point de terminaison ne peut en traiter. AppSignal stocke chaque combinaison de tags unique comme une clé de métrique distincte. Par exemple, chaque combinaison de valeurs queue et worker crée une clé de métrique distincte. Les limites de cette section s’appliquent aux métriques personnalisées et à transaction_duration. Elles s’appliquent aussi à incident_error_count lorsqu’une requête utilise un caractère générique pour incident_digest ou revision. Elles ne s’appliquent pas aux autres métriques dans l’implémentation V2 actuelle. Chaque combinaison de clé de métrique et de champ compte comme une série. Par exemple, demander MEAN et COUNT pour une même clé de métrique compte comme deux séries. Pour les métriques concernées, AppSignal limite le nombre de séries qu’il traite avant de récupérer leurs données :
  • /api/v2/metrics/timeseries traite jusqu’à 100 séries.
  • /api/v2/metrics/list traite jusqu’à 1 000 séries par page. Une requête paginée peut lire jusqu’à 100 000 clés de métrique sur l’ensemble de ses pages. Voir Paginer une liste.
Ces limites protègent la base de données de métriques contre les requêtes qui prendraient trop de temps à s’exécuter. Elles s’appliquent à l’ensemble de la réponse, et non séparément à chaque entrée select. Le champ limit ne peut pas les augmenter. Les graphiques de tableau de bord chargent leurs données depuis /api/v2/metrics/timeseries, la limite de 100 séries s’applique donc aussi aux graphiques. Si une requête correspond à plus de séries que le point de terminaison ne peut en traiter, AppSignal ne renvoie qu’une partie des données. La réponse n’indique pas qu’elle est incomplète, donc les totaux agrégés peuvent être trop bas. Répéter la même requête renvoie le même sous-ensemble, mais le résultat reste incomplet. Pour lire plus de séries à partir d’une requête de liste, paginez-la. Une requête paginée qui correspond à plus de 100 000 clés de métrique renvoie pagination_key_limit_exceeded au lieu d’un résultat partiel. La page Limites montre quelles métriques personnalisées signalent le plus de combinaisons de tags uniques par minute. Lorsque les valeurs de tags changent au fil du temps, une requête sur une plage plus longue peut correspondre à plus de séries que ce que montre la page. Les métriques personnalisées fonctionnent mieux avec des tags ayant un ensemble de valeurs restreint et fixe, comme region, plan ou queue. Si une métrique existante a des tags à forte cardinalité, des filtres de tags exacts peuvent réduire le nombre de séries correspondantes, mais la réponse ne peut pas confirmer qu’elle contient toutes les séries. Consultez Tags de métriques pour des conseils sur le choix des valeurs de tags.

​
Référence

​
Champs

Le field sélectionne quelle mesure récupérer à partir d’une métrique : Pour plus de références sur les types, lisez la documentation de l’API V2 d’AppSignal.

​
Agrégations

L’aggregation combine plusieurs valeurs dans un intervalle temporel : SUM, AVERAGE, MIN, MAX, FIRST ou LAST.

​
Résolutions

resolution accepte MINUTELY, HOURLY ou DAILY. MINUTELY s’applique uniquement lorsque la plage est de 12 heures ou moins et commence dans les 48 dernières heures. En dehors de cette fenêtre, AppSignal utilise HOURLY à la place et l’indique dans le champ resolution de la réponse.