Sans aucun doute, l'interface Gravitee fournit des moyens assez visuels et pratiques de visualiser le fonctionnement des passerelles Gravitee. Mais dans tous les cas, il est nécessaire de fournir un accès à ces outils au service de surveillance, aux propriétaires ou aux consommateurs d'API, et en même temps, ils peuvent être en dehors de la boucle fermée dans laquelle se trouve le gestionnaire d'API. Et il est toujours plus pratique d'avoir toutes les informations disponibles sur les différentes API sur un seul écran.
Voyez ce qui se passe sur les passerelles sans entrer dans les spécificités de l'interface utilisateur de Gravitee, et les administrateurs ne perdent pas de temps à créer des utilisateurs et à séparer les rôles et les privilèges au sein de Gravitee.
Habré avait déjà quelques articles dédiés à APIM Gravitee, ici et ici... Par conséquent, dans ma note, j'impliquerai que le lecteur est déjà familiarisé avec le processus d'installation / configuration d'APIM Gravitee et Grafana, je ne considérerai que le processus de configuration de leur intégration.
Pourquoi ne pouvez-vous pas suivre la voie facile?
Par défaut, le référentiel pour les analyses Gravitee est ElasticSearch. Les informations sont regroupées dans quatre indices différents, avec une ventilation quotidienne:
gravitee-request-YYYY.MM.DD - les informations pour chaque requête sont stockées ici (similaire à access.log dans nginx). C'est notre objectif principal;
gravitee-log-YYYY.MM.DD - des informations plus détaillées sur la demande sont déjà stockées ici (à condition que le débogage soit activé, voir la figure ci-dessous). À savoir, les en-têtes de demande et de réponse complets, ainsi que la charge utile. En fonction des paramètres, à la fois l'échange entre le consommateur et la passerelle et / ou la passerelle et le fournisseur d'API peuvent être enregistrés;
Écran d'activation / désactivation de la journalisation avancée
gravitee-monitor-YYYY.MM.DD - nous ne sommes pas intéressés par celui-ci;
gravitee-health-YYYY.MM.DD - celui-ci ne nous intéresse pas.
, : ElasticSearch Grafana , .
, , .. - , . , Grafana, . Gravitee . , MongoDB PostgreSQL, . ( Grafana) - , - .
?
PostgreSQL , ElasticSearch (). , Grafana - PostgreSQL, ElasticSearch .
( ).
, !
: CentOS 7, APIM Gravitee 3.6, PostgreSQL 11, ElasticSearch 7.+
PostgreSQL ElasticSearch. :
multicorn11 pip, :
yum install multicorn11 python3-pip
pip-, python3 ElasticSearch:
pip3 install pg_es_fdw
, PostgreSQL. multicorn :
GRANT USAGE on FOREIGN DATA WRAPPER multicorn TO gatewaytest; GRANT USAGE ON FOREIGN SERVER multicorn_es TO gatewaytest;
CREATE EXTENSION multicorn; CREATE SERVER multicorn_es FOREIGN DATA WRAPPER multicorn OPTIONS (wrapper 'pg_es_fdw.ElasticsearchFDW');
, . logreader:
GRANT USAGE on FOREIGN DATA WRAPPER multicorn TO logreader; GRANT USAGE ON FOREIGN SERVER multicorn_es TO logreader;
, logging, logreader:
CREATE SCHEMA logging AUTHORIZATION logreader;
, :
CREATE TABLE logging.requests ( id varchar(36), "@timestamp" timestamp with time zone, api varchar(36), "api-response-time" int, application varchar(36), custom json, endpoint text, gateway varchar(36), "local-address" varchar(16), method int, path text, plan varchar(36), "proxy-latency" int, "remote-address" varchar(16), "request-content-length" int, "response-content-length" int, "response-time" int, sort text, status int, subscription varchar(36), uri text, query TEXT, score NUMERIC) PARTITION BY RANGE("@timestamp");
, , , - .
, shell- cron:
#!/bin/sh NEWPART=${1:-$(date +'%Y.%m.%d')} OLDPART=$(date --date='14 days ago' +'%Y.%m.%d') curl http://gateway.corp/test psql gateway -U logreader -c "CREATE FOREIGN TABLE logging.\"requests_${NEWPART}\" PARTITION OF logging.requests FOR VALUES FROM ('${NEWPART} 00:00:00') TO ('${NEWPART} 23:59:59') SERVER multicorn_es OPTIONS ( host 'els-host', port '9200', index 'gravitee-request-${NEWPART}', rowid_column 'id', query_column 'query', query_dsl 'false', score_column 'score', sort_column 'sort', refresh 'false', complete_returning 'false', timeout '20', username 'elastic-ro', password 'Sup3rS3cr3tP@ssw0rd');" psql gateway -U gatewaydev -c "drop foreign table logging.\"requests_${OLDPART}\""
:
NEWPART - , , ElasticSearch;
OLDPART - , , 14 ( ES Curator). , - . , , ;
'curl http://gateway.corp/test', , , API. , , . ;
, ;
- .
TABLE logging.requests LIMIT 1;
,
-[ RECORD 1 ]-----------+------------------------------------- id | 55efea8a-9c91-4a61-afea-8a9c917a6133 @timestamp | 2021-05-16 00:00:02.025+03 api | 9db39338-1019-453c-b393-381019f53c72 api-response-time | 0 application | 1 custom | {} endpoint | gateway | 7804bc6c-2b72-497f-84bc-6c2b72897fa9 local-address | 10.15.79.29 method | 3 path | plan | proxy-latency | 2 remote-address | 10.15.79.27 request-content-length | 0 response-content-length | 49 response-time | 2 sort | status | 401 subscription | uri | /test query | score | 1.0
, - Gravitee. , , PostgreSQL, . , : , ; ; , .
, Metadata, Grafana.
:
Grafana:
SELECT
name "",
value ""
FROM
metadata
WHERE
reference_id='${apis}'
APIs () - .
SELECT COUNT(*) AS "" FROM apis;
SELECT COUNT(*) AS "" FROM apis WHERE lifecycle_state='STARTED';
Applications, , applications
API Hits - .
SELECT
date_trunc('minute',"@timestamp") AS time,
apis.name,ee Grafana

COUNT(*)
FROM
logging.requests al
JOIN
apis ON al.api = apis.id
WHERE
query='@timestamp:[$__from TO $__to]'
GROUP BY 1,2
Average response time by API - , .
SELECT
date_trunc('minute',"@timestamp") AS time,
apis.name,
AVG(al."api-response-time")
FROM
logging.requests al
JOIN
apis ON al.api = apis.id
WHERE
query='@timestamp:[$__from TO $__to]'
GROUP BY 1,2
Hits, by gateways, . :
SELECT
date_trunc('minute',"@timestamp") as time,
al."local-address",
COUNT(*)
FROM
logging.requests al
WHERE
query='@timestamp:[$__from TO $__to]'
GROUP BY 1,2
La solution ci-dessus, à mon avis subjectif, n'est en aucun cas inférieure aux outils de visualisation standard d'APIM Gravitee, mais n'est limitée que par l'imagination et les besoins.
Étant donné que Grafana est généralement l'objet central de l'infrastructure de surveillance, les avantages d'une telle solution sont évidents: une couverture plus large, une densité d'informations plus élevée et une personnalisation simple des représentations visuelles.
PS
Dans un proche avenir, un autre article est prévu sur l'intégration de Gravitee avec ActiveDirectory. Le processus est assez simple, mais comme toujours, il y a des nuances.
Les critiques, souhaits et suggestions constructifs sont les bienvenus!