Configuration de GraphQL
GraphQL est un langage d'interrogation conçu pour les API. Vous pouvez exécuter des requêtes sur un noeud final /graphql unique. GraphiQL utilise un système d'introspection intégré pour exposer des informations via le schéma.
Le noeud final d'API d'analyse GraphQL est disponible uniquement pour les plans de niveau Enterprise.
Prérequis
Vous devez disposer des droits suivants :
- Vous devez disposer du droit Afficheur au niveau d'une instance ou d'une zone.
- Vous devez disposer du droit Lecteur au niveau d'une zone.
Outil GraphiQL
GraphiQL permet d'explorer le schéma et de tester des requêtes pour le noeud final GraphQL.
- Télécharger et installer GraphiQL.
- Ouvrez l'application GraphiQL et entrez les en-têtes HTTP que vous souhaitez autoriser.
- Entrez le noeud final correct dans la zone GraphQl Endpoint. Utilisez
https://api.cis.cloud.ibm.com/v1/<crn>/zones/<zoneid>/graphql.
La fenêtre se compose d'un panneau de requête et d'un panneau de réponse. Vous pouvez définir les variables de requête, qui sont interpolées dans la requête dans le panneau de requête.
Pour générer une requête, procédez comme suit :
- Sélectionnez
POSTdans le menu déroulant Method. - Cliquez sur Edit HTTP Headers.
- Entrez le jeton
X-Auth-User-Tokenou Authorization et définissezapplication/jsonpour Content-Type:. Sauvegardez les données.
Commencez à générer votre requête dans le panneau de requête. Utilisez Document Explorer pour explorer le schéma et la documentation. Document Explorer affiche différentes options disponibles pour des jeux de données, des opérations et des fonctions. Les termes "zone" et "domaine" sont synonymes dans Document Explorer.
Créez le fragment test suivant dans le panneau de requête et observez la réponse dans le panneau de réponse en ajustant la valeur de datetime en fonction de vos besoins ;
query {
viewer {
zones(filter: {zoneTag: "<your domain ID>"}) {
httpRequests1hGroups(limit: 5, filter: { datetime_gt: "2020-08-30T04:00:00Z", datetime_lt: "2020-08-31T06:00:00Z"}) {
sum {
countryMap {
bytes
clientCountryName
}
}
dimensions {
date
datetime
}
}
firewallEventsAdaptiveGroups(limit: 10, filter: { datetime_gt: "2020-08-30T04:00:00Z", datetime_lt: "2020-08-31T06:00:00Z"}) {
count
dimensions {
clientCountryName
clientAsn
datetimeHour
}
}
}
}
}
Principes de base d'une interrogation
GraphQL structure les données sous la forme d'un graphique. Pour obtenir les données dont vous avez besoin, vous pouvez explorer les arêtes du graphique. Voici un exemple de format de requête :
viewer {
zones(filter:...) {
requests(filter:...) {
date, time, bytes,...
}
}
}
Le noeud initial de l'utilisateur qui exécute la requête est viewer. Un afficheur (viewer) peut accéder à un ou plusieurs domaines (zones). Chaque zone contient différents jeux de données, tels que des événements de pare-feu pour
une zone.
Les noeuds représentant des données agrégées incluent le suffixe groups, par exemple firewallEventsAdaptiveGroups. Chaque groupe suit une structure spécifique, comme indiqué dans l'exemple suivant :
type ExampleGroup {
count # No subfields, it is just the group size.
sum {
# fields that support summing (numbers, maps of numbers)
}
avg {
# fields that support averaging (numbers)
}
uniq {
# fields that support uniqueing (numbers, strings, enums, IPs, dates, etc.)
}
}
Cet exemple présente un groupe valide :
httpRequests1mGroups {
sum {
bytes
}
uniq {
uniques # unique IPs
}
dimensions {
datetimeMinute
}
}
Fichiers
Voici une liste d'ensembles de données couramment utilisés et disponibles. Pour plus d'informations sur les ensembles de données, vous pouvez utiliser le mécanisme d'introspectionGraphQL.
| Jeu de données | Node |
|---|---|
| Browser Insights | browserInsightsAdaptiveGroups |
| Firewall Activity Log | firewallEventsAdaptive firewallEventsAdaptiveByTimeGroups |
| Firewall Analytics | firewallEventsAdaptiveGroups |
| Health Check Analytics | healthCheckEvents healthCheckEventsGroups |
| HTTP Requests | httpRequests1mGroups httpRequests1hGroups httpRequests1dGroups httpRequestsAdaptiveGroups |
| Image Resizing Analytics | imageResizingRequests1mGroups |
| Load Balancing Analytics | loadBalancingRequests loadBalancingRequestsGroups |
| SYN Attacks (DoS Analytics) | synAvgPps1mGroups |
| Edge Functions Metrics | workersInvocationsAdaptive |
Erreurs
L'interface de programmation GraphQL Analytics est une interface de programmation RESTful basée sur des requêtes HTTPS et des réponses JSON et renvoie des codes d'état HTTP familiers (par exemple, 404, 500, 504).
Conformément à la spécification GraphQL, une réponse 200 peut contenir une erreur, contrairement à l'approche REST commune.
Toutes les réponses incluent un tableau d'erreurs, qui correspond à la valeur null s'il n'y a pas d'erreurs. Les erreurs non null incluent des entrées message, path et timestamp.
Le code suivant est un exemple de réponse d'erreur :
{
"data": null,
"errors": [
{
"message": "cannot request data older than 2678400s",
"path": [
"viewer",
"zones",
"0",
"firewallEventsAdaptiveGroups"
],
"extensions": {
"timestamp": "2019-12-09T21:27:19.195060142Z"
}
}
]
}
Limites
Les limites de conservation des données d'historique sont définies dans le tableau suivant :
| Nœud de données | Entreprise |
|---|---|
browserInsightsAdaptiveGroups |
30 jours |
firewallEventsAdaptiveByTimeGroups |
30 jours |
firewallEventsAdaptiveGroups |
30 jours |
healthCheckEventsGroups |
90 jours |
healthCheckEvents |
90 jours |
httpRequestsAdaptiveGroups |
30 jours |
httpRequests1dGroups |
365 jours |
httpRequests1hGroups |
90 jours |
httpRequests1mGroups |
7 jours |
loadBalancingRequestsGroups |
30 jours |
loadBalancingRequests |
30 jours |
synAvgPps1mGroups |
7 jours |
Paramètres de requête pour les limites d'un compte
Pour obtenir des informations spécifiques sur les limites d'un noeud de données, utilisez le noeud settings.
| Zone | Description |
|---|---|
enabled |
Renvoie true si le jeu de données (noeud) est disponible pour le plan en cours. |
maxDuration |
Définit la période maximale (en secondes) qui peut être demandée dans une même requête (varie en fonction du noeud de données). |
maxNumberOfFields |
Définit le nombre maximal de zones qui peuvent être demandées dans une même requête (varie en fonction du noeud de données). |
maxPageSize |
Définit le nombre maximal d'enregistrements qui peuvent être demandés dans une même requête (varie en fonction du noeud de données). |
notOlderThan |
Limite l'ancienneté des enregistrements pour lesquels une recherche peut être effectuée (en secondes, varie en fonction du noeud de données et du plan). |
Voici un exemple de requête :
{
viewer {
zones(filter: { zoneTag: $zoneTag }) {
settings {
browserInsightsAdaptiveGroups {
maxDuration
maxNumberOfFields
maxPageSize
enabled
notOlderThan
}
}
}
}
}
La réponse de la requête est la suivante :
{
"data": {
"viewer": {
"zones": [
{
"settings": {
"browserInsightsAdaptiveGroups": {
"enabled": true,
"maxDuration": 2592000,
"maxNumberOfFields": 30,
"maxPageSize": 10000,
"notOlderThan": 2595600
}
}
}
]
}
},
"errors": null
}
Limites de requête
Le volume de données qu'une requête peut renvoyer est limité et des limites sont appliquées au volume de données quotidien par utilisateur. Les limites suivantes s'appliquent en plus des limites de débit générales mises en place par l'API :
- Une requête dont la portée est définie au niveau des zones peut inclure jusqu'à dix zones.
- Les requêtes peuvent demander jusqu'à 30 zones, comme indiqué par
maxNumberOfFieldsdanssettings. - Les réponses peuvent renvoyer jusqu'à 10000 enregistrements. Cette limite est indiquée par
maxPageSizedanssettings.
Les requêtes doivent spécifier explicitement le nombre maximal d'enregistrements à renvoyer à l'aide de l'argument limit.
Tri
Vous pouvez trier l'ordre des éléments du résultat de la requête à l'aide de l'argument orderBy. Par défaut, les résultats sont triés en fonction de la clé primaire du jeu de données (table). Si vous indiquez une autre zone pour
le tri, la clé primaire est incluse dans la clé de tri pour conserver des résultats cohérents lors de la mise en page.
L'ordonnancement dans des structures imbriquées n'est pas pris en charge.
Exemples de tri
Tri de données brutes :
firewallEventsAdaptive (orderBy: [clientCountryName_ASC]) {
clientCountryName
}
Tri de données brutes à l'aide de zones multiples :
firewallEventsAdaptive (orderBy: [clientCountryName_ASC, datetime_DESC]) {
clientCountryName
datetime
}
Tri de groupes par fonction d'agrégation :
httpRequests1hGroups (orderBy: [sum_bytes_DESC]){
sum {
bytes
requests
}
dimensions {
datetime
}
}
Pagination
La mise en page, qui décomposait les résultats de la requête en pièces plus petites, peut être effectuée à l'aide de paramètres limit, orderByet de filtrage. L'API GraphQL Analytics ne prend pas en charge les curseurs
pour la mise en page.
limit(entier) définit le nombre d'enregistrements à renvoyer.orderBy(chaîne) définit l'ordre de tri des données.
Pages de requête sans curseurs
L'exemple suivant suppose que les relations date et clientCountryName sont uniques.
Obtenez les premiers résultats N d'une requête.
Pour limiter les résultats, ajoutez le paramètre limit. Par exemple, demandez les deux premiers enregistrements.
firewallEventsAdaptive (limit: 2, orderBy: [datetime_ASC, clientCountryName_ASC]) {
datetime
clientCountryName
}
La spécification d'un ordre de tri par date renvoie des résultats moins précis que la spécification d'un ordre de tri par date et par pays.
La réponse de la requête est la suivante :
{
"firewallEventsAdaptive" : [
{
"datetime": "2018-11-12T00:00:00Z",
"clientCountryName": "UM"
},
{
"datetime": "2018-11-12T00:00:00Z",
"clientCountryName": "US"
}
]
}
Requête de la page suivante à l'aide d'un filtre
Pour obtenir les résultats N suivants, spécifiez un filtre pour exclure le dernier résultat de la requête précédente. A l'aide de l'exemple précédent, vous pouvez ajouter l'opérateur supérieur à (_gt) à la zone clientCountryName et l'opération supérieur ou égal à à la zone datetime. En définissant un ordre spécifique, vous pouvez obtenir les résultats les plus complets.
firewallEventsAdaptive (limit: 2, orderBy: [datetime_ASC, clientCountryName_ASC], filter: {date_geq: "2018-11-12T00:00:00Z", clientCounterName_gt: "US"}) {
date
clientCountryName
}
La réponse de la requête est la suivante :
{
"firewallEventsAdaptive" : [
{
"datetime": "2018-11-12T00:00:00Z",
"clientCountryName": "UY"
},
{
"datetime": "2018-11-12T00:00:00Z",
"clientCountryName": "UZ"
}
]
}
Requête de la page précédente
Pour obtenir les résultats N précédents, inverses les filtres et l'ordre de tri.
firewallEventsAdaptive (limit: 2, orderBy: [datetime_DESC, clientCountryName_DESC, filter: {date_leq: "2018-11-12T00:00:00Z", clientCountryName_lt: "UY"}]) {
datetime
clientCountryName
}
La réponse de la requête est la suivante :
{
"firewallEventsAdaptive" : [
{
"datetime": "2018-11-12T00:00:00Z",
"clientCountryName": "US"
},
{
"datetime": "2018-11-12T00:00:00Z",
"clientCountryName": "UM"
}
]
}
Filtrage
Les filtres limitent les requêtes à un compte ou à un ensemble de zones spécifique (domaines), les demandes en fonction d'une date ou d'un agent de requête spécifique. Sans filtres, les performances risquent de se détériorer et les résultats peuvent inclure des données inutiles.
Structure
Le filtre GraphQL est représenté par l'objet d'entrée GraphQL.
Des filtres peuvent être utilisés en tant qu'argument pour les ressources suivantes :
- Zones (domaines)
- Tables (jeux de données)
- Comptes
Filtre de zone (domaine)
Le filtre de zone permet la requête de données liées à des zones en fonction d'un ID de zone (domaine) (zoneTag).
zones(filter: {zoneTag: "your domain (zone) ID"}) {
...
}
Le filtre de zone doit respecter la syntaxe suivante :
filter
{ zoneTag: t }
{ zoneTag_gt: t }
{ zoneTag_in: [t, ...] }
Les filtres composés (séparés par une virgule, AND, OR) ne sont pas pris en charge. Les zones sont toujours triées par ordre alphanumérique.
Filtre de table (jeu de données)
Les filtres de table requièrent l'interrogation d'au moins un noeud. L'opérateur AND peut être utilisé pour créer et combiner des filtres à noeuds multiples.
Filtres de compte
Le filtrage au niveau d'un compte est pris en charge et il existe un paramètre de filtre obligatoire. Exemple :
accounts(filter: {accountTag: $accountTag}) {
...
}
Opérateurs
La prise en charge des opérateurs varie en fonction du type et du nom de noeud. Les opérateurs suivants sont pris en charge pour tous les types :
| Opérateur | Comparaison |
|---|---|
gt |
supérieur à |
lt |
inférieur à |
geq |
supérieur ou égal à |
leq |
inférieur à |
neq |
non égal |
in |
in |
Exemples
Exemple général :
{
myQuery(
filter: {
clientCountry: "UK" # all objects having client country equal to "UK"
datetime_gt: "2020-01-01 10:00:00" # all object having datetime greater than "2020-01-01 10:00:00"
}
)
}
Filtrage d'un noeud spécifique :
httpRequests1hGroups(filter: {datetime: "2020-01-01 10:00:00"}) {
...
}
Filtrage de plusieurs zones :
httpRequests1hGroups(filter: {datetime_gt: "2018-01-01 10:00:00", datetime_lt: "2018-01-01 11:00:00"}) {
...
}
Filtrage à l'aide de l'opérateur OR :
httpRequests1hGroups(filter: {
datetime: "2020-01-01 10:00:00",
OR:[{clientCountryName: "US"}, {clientCountryName: "UK"}]) {
...
}