En guise d'introduction ...
L'exploitation industrielle nécessite la connaissance du mode de vie d'une application. Cette thèse doit être considérée comme un axiome. Ces connaissances sont les métriques produites par l'application. Les mesures peuvent être purement techniques (par exemple, la quantité de RAM consommée) et commerciales (par exemple, commandes terminées).
En soi, une tranche de métriques n'est pas toujours intéressante et indicative pour le moment. Des questions de base se posent concernant la collecte, le stockage et l'affichage de ces métriques.
La situation avec le besoin de métriques et la façon dont elles sont traitées devient plus aiguë lorsqu'une approche de service est utilisée et qu'une application, du point de vue de l'utilisateur, est prise en charge par le fonctionnement de plusieurs services en interaction. Ajoutez un déploiement cloud à cela et récoltez le piment .
De quoi s'agit-il
Le projet auquel je participe utilise simplement des services et est déployé sur AWS (Amazon Web Services). La plupart des services sont créés à l'aide de Java 8+, Spring Boot et Docker. La conférence à Luxoft IT Sreda # 7 et cet article sont nés des besoins et des objectifs du projet.
Mon objectif est d'examiner l'aspect pratique de la collecte de métriques d'application à l'aide de Spring Boot et de les exporter vers AWS CloudWatch . Ce sera, en fait, un guide étape par étape avec des explications, une analyse des nuances et des râteaux possibles.
Lorsque nous parlons de résoudre un problème pratique, il est important de comprendre ses symptômes afin de le comparer à l'environnement existant. Est-il possible d'appliquer ce dont nous parlons un à un ou si une adaptation est nécessaire, plus de recherche.
Voyons en quoi consiste notre contexte actuel:
- En somme, notre application ou service est basé sur Spring Boot. En tant que constructeur Maven, Java 8+
- Docker. Cependant, son utilisation n'est pas critique. Il est important que pour une application exécutée dans docker, tout fonctionne également
- AWS EC2 est notre infrastructure où l'application s'exécute. À la base, il s'agit d'une machine virtuelle au sein d'AWS.
- AWS CloudWatch est un système de surveillance qui est un tableau de bord d'infrastructure AWS.
Botte de printemps
Passons à SpringBoot et à ses fonctionnalités qui peuvent nous aider. La première et la plus importante chose dans l'arsenal est Actuator . Ce module vous permet de regarder à l'intérieur d'une application en cours d'exécution et, dans une certaine mesure, de personnaliser son comportement. Par exemple:
- Health check:
- , , runtime.
- ,
- , , : , , GC.
- ...
Comme de nombreux composants Spring, Actuator est similaire à un constructeur et peut être personnalisé, étendu et affiné. Vous pouvez commencer à étudier à partir d'ici .
De l'ensemble, nous nous intéressons actuellement aux métriques. L'actionneur et les métriques en particulier sont non seulement extensibles, mais également préconfigurés, il n'y a donc que quelques dizaines de catégories de métriques disponibles prêtes à l'emploi. Bien sûr, vous pouvez enregistrer vos propres métriques. Si le module Web est connecté au projet, les métriques peuvent être obtenues en contactant
endpoint /metrics.
La collecte et la fourniture de mesures sont mises en œuvre via la bibliothèque de micromètres , qui est un produit de Pivotal(maintenant partie de VMware), le même qui développe Spring. micromètre est commercialisé comme une façade indépendante du fournisseur pour l'exportation de métriques d'applications Java.
L'actionneur nécessitera le démarreur suivant pour se connecter:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>Nuage de printemps
Ensuite, nous avons besoin d'un module de Spring Cloud, à savoir
spring-cloud-starter-aws.
Chaque module de la famille Spring Cloud a son propre versionnage et il sera correct d'utiliser non pas une version spécifique du module, mais la nomenclature d'une
spring-cloud-dependenciesversion spécifique (release train), où les versions compatibles des modules sont collectées. Au moment de la rédaction de cet article, il s'agit de Hoxton.RELEASE.
En plus de délicieuses autoconfigurations, pour travailler avec AWS
spring-cloud-starter-aws, en tant que dépendance transitive, ça donne aws-java-sdk.
Dans la section dependencyManagement, mettez
<dependencyManagement>
...
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>Hoxton.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
...
</dependencyManagement>Et en fonction de:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-aws</artifactId>
</dependency>Registre micrométrique
Nous avons maintenant un micromètre dans notre actionneur à ressort et
aws-java-sdk. Prêt à l'emploi, le micromètre ne sait pas comment exporter des données vers AWS CloudWatch, cela nécessite une implémentation appropriée de MeterRegestry, une abstraction micrométrique pour la collecte de métriques. La valeur par défaut est SimpleMeterRegistry, qui stocke les données en mémoire. L'implémentation requise est connectée avec micrometer-registry-cloudwatch. Au moment d'écrire ces lignes, la version actuelle est la 1.3.5.
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-registry-cloudwatch</artifactId>
<version>1.3.5</version>
</dependency>Le pom.xml final, dans notre cas, ressemble à ceci: github.com/MrArtemAA/blog-demos/blob/master/export-metrics-to-cloudwatch/pom.xml
app.properties
Passons à la configuration des propriétés de l'application, qui dans notre cas jouent un rôle important:
1
management.metrics.export.cloudwatch.namespace.: vous devez spécifier l'espace de noms sous lequel les métriques seront enregistrées dans CloudWatch. Parce que dans la métrique elle-même, il n'y a aucune information à partir de quelle instance d'application particulière les données proviennent, l'espace de noms déterminera les métriques d'une instance particulière. Sinon, si vous définissez un espace de noms pour plusieurs instances, les données de métriques seront mélangées et leur provenance n'est pas claire.
2
management.metrics.export.cloudwatch.batch-size.: il est nécessaire de définir explicitement la valeur de la propriété batch-size sur 20. Quel est ce paramètre et pourquoi exactement 20? Les métriques sont envoyées aux clients Amazon CloudWatch de manière asynchrone, par lots de 20 (il s'agit de la limite AWS) à la fois.
3
cloud.aws.stack.auto=false.: besoin de désactiver la détection automatique de la pile AWS CloudFormationpuisque il vaut par défaut = true. Cette propriété est responsable de savoir si l'application essaiera d'obtenir automatiquement le nom de la pile pour configurer l'application pour l'environnement cloud (dans le paradigme infrastructure-as-code). Lors du déploiement sur EC2, comme sur une machine virtuelle classique, ces informations ne sont pas disponibles.
Il est important de comprendre que toutes les informations que le kit AWS SDK essaiera d'obtenir par lui-même sans configuration supplémentaire, il [la bibliothèque] sera extraite des métadonnées EC2 . Pour obtenir ces informations, il existe un point de terminaison de service spécial, où l'appel est effectué.
Compte rendu
taille du lot
Revenons à la propriété
management.metrics.export.cloudwatch.batch-sizeet à la nécessité de la définir égale à 20. Il semblerait que tout cela puisse être fait au niveau des bibliothèques correspondantes travaillant avec AWS. En effet, micrometer-registry-cloudwatchil existe une interface avec une CloudWatchConfig defaultméthode qui vérifie correctement la valeur et lève une exception si elle dépasse 20. Cependant, si vous regardez org.springframework.cloud.aws.autoconfigure.metrics.CloudWatchExportAutoConfiguration, nous verrons que la configuration se fait en utilisantorg.springframework.cloud.aws.autoconfigure.metrics.CloudWatchPropertiesConfigAdapter:
@Bean
@ConditionalOnMissingBean
public CloudWatchConfig cloudWatchConfig(CloudWatchProperties cloudWatchProperties) {
return new CloudWatchPropertiesConfigAdapter(cloudWatchProperties);
}L'adaptateur, à son tour, remplace
batchSize()comme
@Override
public int batchSize() {
return get(CloudWatchProperties::getBatchSize, CloudWatchConfig.super::batchSize);
}Cela signifie que si une
CloudWatchPropertiespropriété est définie, elle en sera extraite. Il ne contient tout simplement pas les vérifications nécessaires, et si la propriété n'est pas explicitement définie, la valeur par défaut sera 10000.
Demandes à AWS
Une application (service) ne peut pas simplement faire des demandes aux services Amazon. Ces [demandes] doivent contenir des informations d'identification. Pour ce faire, le kit AWS SDK dispose d'une chaîne de fournisseurs d'informations d'identification , ce qui est recommandé. Parmi ces fournisseurs, il y a Instance Profile, qui peut recevoir des données basées sur les métadonnées EC2. Pour que cela fonctionne, vous devez vous assurer qu'un rôle est lié à EC2 .
Le rôle doit accorder des autorisations pour faire des demandes à CloudWatch et être disponible pour EC2. Le rôle peut être spécifié à la fois lors de la création d'une nouvelle instance EC2 ou attaché à une instance existante. Le rôle est appliqué à la volée.
Désactiver les métriques
Pour un environnement de construction ou de test local, l'exportation de métriques peut être excessive. La définition de la propriété
management.metrics.export.cloudwatch.enabled=falsevous permet de désactiver l'exportation des métriques vers CloudWatch, tandis que la collecte des métriques sera effectuée et, si vous avez un module Web connecté, endpoint /metricselles seront toujours disponibles.
Micrometer collecte et fournit une grande variété de mesures. Si certains d'entre eux ne sont pas nécessaires, vous pouvez les désactiver. Vous pouvez désactiver à la fois individuellement et par catégories entières. Ainsi, par exemple, la propriété désactivera toutes les métriques dont l'ID commence par . Remarque: les statistiques désactivées ne seront pas du tout collectées.
management.metrics.enable.some.metric=falsesome.metric
Exécuter tout AWS
Une autre surprise vous attend si vous essayez d'exécuter l'application avec les paramètres minimum requis sur tout AWS. Pour le fonctionnement, les données nécessaires de la région où l'application s'exécute. Comme nous le savons déjà, tout ce qui n'est pas explicitement indiqué, le SDK AWS essaiera d'obtenir des métadonnées ... ce qui n'est pas là. Par conséquent, nous indiquons explicitement la région souhaitée via la propriété
cloud.aws.region.static=us-east-2. Comme dans le cas du nom de la pile (propriété cloud.aws.stack.auto), il existe une propriété cloud.aws.region.autoégale truepar défaut. Mais simplement définir la valeur sur false ne nous aidera pas, car la valeur de la région est nécessaire.
De plus, comme nous nous en souvenons, les demandes à AWS nécessitent des informations d'identification, donc si vous devez envoyer des métriques à CloudWatch (ou faire d'autres demandes à AWS), vous devez spécifier explicitement les paramètres pour les informations d'identification.via, par exemple, les propriétés d'application ou les variables d'environnement.
Le passage des propriétés de l'application ressemble à ceci:
cloud.aws.credentials.access-key=YOUR_ACCESS_KEY
cloud.aws.credentials.secret-key=YOUR_SECRET_KEY
Résultat
Comme je pense que vous l'avez peut-être remarqué, faire fonctionner l'ensemble du schéma et transférer les métriques de l'application vers CloudWatch n'est pas si difficile: il a fallu 3 dépendances et 3 propriétés .
Le plus important est dans les détails. Les bibliothèques (frameworks) telles que Spring, AWS SDK essaient de nous simplifier la vie et de faire tout le travail pour nous autant que possible, mais en même temps, tout pas de côté peut conduire à l'apparition d'un stacktrace, tente de comprendre pourquoi les métriques ne vont nulle part, pourquoi l'application ne démarre pas du tout et comment y remédier. Une section avec une ventilation des nuances et une description de certains des détails du fonctionnement des services EC2 et CloudWatch, je l'espère, vous facilitera la compréhension de ce qui se passe.
Si nous parlons d'utiliser CloudWatch lui-même, alors, à mon avis, c'est un choix assez naturel lors de l'utilisation de l'infrastructure AWS.
Les métriques sont les yeux et les oreilles de notre application, mais cela ne nie pas le fait que vous devez comprendre comment les métriques sont collectées, comptées et affichées. Quel type de données verrez-vous sur vos graphiques. Ce problème sera particulièrement aigu en cas d'anomalies et d'analyse des incidents. Si nous parlons de la bibliothèque de micromètres, il convient de se référer à la documentation , là, par exemple, elle est décrite en détail sur les types de compteurs (mètre).
Liens
L'échange d'expériences nous permet de maîtriser rapidement différentes approches, outils, technologies et d'avancer. Par conséquent, je ne peux pas ignorer les matériaux les plus utiles sur le sujet, qui n'ont pas été référencés lors de l'article:
Spring Boot: Metrics With Micrometer et AWS CloudWatch
Spring Cloud. Utilisation d'Amazon Web Services. Configuration automatique de Spring Boot
Spring in Action 5, Craig Walls, Manning
Populaire à propos d'Amazon Web Services Le
projet terminé se trouve sur GitHub .