1. Qu’est-ce qu’un service ? #
Le niveau logique des requêtes.
Définition #
Pour Dynatrace, un service est un point d'entrée qui reçoit des requêtes : une application web, une API, un consommateur de messages, une base de données vue depuis l'application. Il se situe au-dessus des processus : un même process group peut exposer plusieurs services, et un service peut tourner dans de nombreuses instances.
Les services sont reliés par les traces distribuées (PurePaths) et apparaissent dans la topologie Smartscape : c'est ce qui permet à Davis de suivre la propagation d'un problème.
2. Les types détectés automatiquement #
Selon la technologie.
Les principaux types #
| Type | Ce qui le crée | Exemples |
|---|---|---|
| Requêtes web | point d’entrée HTTP instrumenté | API REST Spring, ASP.NET Core, Express |
| Services web | services décrits par un contrat (SOAP, WCF) | SOAP, WCF |
| Base de données | appels vers une base depuis l’application | PostgreSQL, Oracle, MongoDB, Redis |
| Messagerie | consommation de messages | Kafka, JMS, RabbitMQ |
| Appels distants | protocoles RPC | gRPC, RMI |
| Services unifiés | traces OpenTelemetry ou données de spans | services instrumentés avec OTel |
| Services externes (opaques) | appels sortants vers un système non supervisé | API d’un partenaire, SaaS |
À savoir : Un cache comme Redis ou une file comme Kafka n'est pas un « type de service » à part : vu depuis l'application, Redis apparaît comme une base de données, et la consommation de messages Kafka comme un service de messagerie. Les conteneurs, eux, sont des entités d'infrastructure, pas des services.
Selon la version : Les services unifiés et la détection de services fondée sur les spans arrivent avec la nouvelle plateforme ; les noms exacts des types peuvent varier selon la version de l'environnement.
3. Services personnalisés et règles #
Quand la détection automatique ne suffit pas.
Services personnalisés #
Un traitement sans point d'entrée standard (batch Java, tâche planifiée, écouteur maison) n'apparaît pas comme un service. Un service personnalisé déclare une méthode d'entrée (classe et méthode) : chaque appel devient alors une requête de service, avec ses temps et ses erreurs.
Règles de détection et de nommage #
Les règles de détection permettent de fusionner des services identiques (même application sur plusieurs ports) ou de les séparer (une application qui sert plusieurs clients). Les règles de nommage remplacent les noms techniques par des noms parlants.
Bonne pratique : Nommez les services d'après le métier et l'environnement (par exemple paiement-api [prod]) : les alertes, les SLO et les tableaux de bord deviennent lisibles par tous.Commandes à connaître #
Sélectionner des services avec un entity selector (API v2, configuration) :
type(SERVICE),serviceType(DATABASE_SERVICE)
type(SERVICE),tag("env:prod"),entityName.startsWith("paiement")
type(SERVICE),fromRelationships.runsOnProcessGroupInstance(type(PROCESS_GROUP_INSTANCE),tag("team:shop"))curl -H "Authorization: Api-Token $DT_TOKEN" \
"$DT_URL/api/v2/entities?entitySelector=type(SERVICE),serviceType(DATABASE_SERVICE)&fields=properties.serviceType"Syntaxe complète : Maîtriser les entity selectors.
