Als Einführung ...
Die industrielle Nutzung erfordert Kenntnisse darüber, wie eine Anwendung lebt. Diese These sollte als Axiom verstanden werden. Dieses Wissen sind die von der Anwendung erzeugten Metriken. Metriken können entweder rein technisch (z. B. die Menge des verbrauchten Arbeitsspeichers) oder geschäftlich (z. B. abgeschlossene Bestellungen) sein.
An sich ist ein Schnitt von Metriken im Moment nicht immer interessant und bezeichnend. Grundlegende Fragen zum Sammeln, Speichern und Anzeigen dieser Metriken stellen sich.
Die Situation mit dem Bedarf an Metriken und der Art und Weise, wie sie verarbeitet werden, verschärft sich, wenn ein Dienstansatz verwendet wird und eine Anwendung aus Sicht des Benutzers durch den Betrieb mehrerer interagierender Dienste unterstützt wird. Fügen Sie dem Cloud-Einsatz hinzu und ernten Sie die Paprika .
Worum geht es
Das Projekt, an dem ich teilnehme, verwendet nur Dienste und wird für AWS (Amazon Web Services) bereitgestellt. Die meisten Dienste werden mit Java 8+, Spring Boot und Docker erstellt. Der Vortrag bei Luxoft IT Sreda # 7 und dieser Artikel sind aus den Bedürfnissen und Zielen des Projekts hervorgegangen.
Mein Ziel ist es, die praktische Seite des Sammelns von Anwendungsmetriken mithilfe von Spring Boot und des Exportierens in AWS CloudWatch zu untersuchen . Dies wird in der Tat eine Schritt-für-Schritt-Anleitung mit Erklärungen, Analysen von Nuancen und möglichen Rechen sein.
Wenn wir über die Lösung eines praktischen Problems sprechen, ist es wichtig, seine Symptome zu verstehen, um es mit der vorhandenen Umgebung zu vergleichen. Ist es möglich, das, worüber wir sprechen, eins zu eins anzuwenden, oder wenn Anpassung erforderlich ist, mehr Forschung.
Werfen wir einen Blick darauf, woraus unser aktueller Kontext besteht:
- Unsere Anwendung oder unser Service basiert selbstverständlich auf Spring Boot. Als Maven Builder Java 8+
- Docker. Die Verwendung ist jedoch nicht kritisch. Es ist wichtig, dass für eine Anwendung, die im Docker ausgeführt wird, auch alles funktioniert
- AWS EC2 ist unsere Infrastruktur, in der die Anwendung ausgeführt wird. Im Kern handelt es sich um eine virtuelle Maschine innerhalb von AWS.
- AWS CloudWatch ist ein Überwachungssystem, bei dem es sich um ein AWS-Infrastruktur-Dashboard handelt.
Frühlingsstiefel
Kommen wir zu SpringBoot und seinen Funktionen, die uns helfen können. Das erste und wichtigste im Arsenal ist Actuator . Mit diesem Modul können Sie einen Blick in eine laufende Anwendung werfen und deren Verhalten bis zu einem gewissen Grad anpassen. Zum Beispiel:
- Health check:
- , , runtime.
- ,
- , , : , , GC.
- ...
Wie viele Federkomponenten ähnelt Actuator einem Konstruktor und kann angepasst, erweitert und optimiert werden. Von hier aus können Sie mit dem Lernen beginnen .
Von der gesamten Menge sind wir derzeit an Metriken interessiert. Insbesondere Aktor und Metriken sind nicht nur erweiterbar, sondern auch vorkonfiguriert, sodass nur ein paar Dutzend Kategorien von Metriken sofort verfügbar sind. Natürlich können Sie Ihre eigenen Metriken registrieren. Wenn das Webmodul im Projekt verbunden ist, können die Metriken durch Kontaktaufnahme abgerufen werden
endpoint /metrics.
Die Erfassung und Bereitstellung von Metriken erfolgt über die Mikrometer- Bibliothek , die ein Produkt von Pivotal ist(jetzt Teil von VMware), derselbe, der Spring entwickelt. Mikrometer wird als herstellerunabhängige Fassade für den Export von Java-Anwendungsmetriken vermarktet.
Der Aktuator benötigt zum Anschließen den folgenden Anlasser:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>Frühlingswolke
Als nächstes benötigen wir nämlich ein Modul aus Spring Cloud
spring-cloud-starter-aws.
Jedes Modul aus der Spring Cloud-Familie verfügt über eine eigene Versionierung. Es ist korrekt, nicht eine bestimmte Version des Moduls zu verwenden, sondern die Stückliste einer
spring-cloud-dependenciesbestimmten Version (Release Train), in der kompatible Versionen der Module erfasst werden. Zum Zeitpunkt des Schreibens ist dies Hoxton.RELEASE.
Zusätzlich zu leckeren Autokonfigurationen für die Arbeit mit AWS
spring-cloud-starter-awsals transitive Abhängigkeit gibt es aws-java-sdk.
Geben Sie im Abschnitt dependencyManagement ein
<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>Und je nach:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-aws</artifactId>
</dependency>Mikrometer-Registrierung
Wir haben jetzt ein Mikrometer im Federantrieb und
aws-java-sdk. Das Mikrometer weiß nicht, wie Daten in AWS CloudWatch exportiert werden sollen. Dies erfordert eine entsprechende Implementierung von MeterRegestry, einer Mikrometer-Abstraktion zum Sammeln von Metriken. Der Standardwert ist SimpleMeterRegistry, in dem Daten im Speicher gespeichert werden. Die erforderliche Implementierung ist zusammen mit verbunden micrometer-registry-cloudwatch. Zum Zeitpunkt dieses Schreibens ist die aktuelle Version 1.3.5.
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-registry-cloudwatch</artifactId>
<version>1.3.5</version>
</dependency>Die endgültige pom.xml sieht in unserem Fall folgendermaßen aus: github.com/MrArtemAA/blog-demos/blob/master/export-metrics-to-cloudwatch/pom.xml
app.properties
Fahren wir mit dem Einrichten von Anwendungseigenschaften fort, die in unserem Fall eine wichtige Rolle spielen:
1
management.metrics.export.cloudwatch.namespace.: Sie müssen den Namespace angeben, unter dem die Metriken in CloudWatch gespeichert werden. weil In der Metrik selbst gibt es keine Informationen darüber, aus welcher Instanz der Anwendung die Daten stammen. Der Namespace bestimmt lediglich die Metriken einer bestimmten Instanz. Wenn Sie andernfalls einen Namespace für mehrere Instanzen definieren, werden die Metrikdaten gemischt und es ist nicht klar, woher sie stammen.
2
management.metrics.export.cloudwatch.batch-size.: Es ist erforderlich, den Wert der Batch-Size-Eigenschaft explizit auf 20 zu setzen. Was ist dieser Parameter und warum genau 20? Metriken werden asynchron in Stapeln von jeweils 20 (dies ist das AWS-Limit) an Amazon CloudWatch-Clients gesendet.
3
cloud.aws.stack.auto=false.: Die automatische Erkennung des AWS CloudFormation-Stacks muss deaktiviert werdenschon seit Der Standardwert ist = true. Diese Eigenschaft ist dafür verantwortlich, ob die Anwendung versucht, den Stapelnamen automatisch abzurufen, um die Anwendung für die Cloud-Umgebung zu konfigurieren (im Infrastruktur-als-Code-Paradigma). Bei der Bereitstellung auf EC2 wie auf einer normalen virtuellen Maschine sind diese Informationen nicht verfügbar.
Es ist wichtig zu verstehen, dass alle Informationen, die das AWS SDK ohne zusätzliche Konfiguration selbstständig abrufen möchte , aus den EC2-Metadaten stammen . Um diese Informationen zu erhalten, gibt es einen speziellen Service-Endpunkt, an dem der Anruf getätigt wird.
Nachbesprechung
Chargengröße
Kehren wir zur Eigenschaft zurück
management.metrics.export.cloudwatch.batch-sizeund müssen sie auf 20 setzen. Es scheint, dass dies alles auf der Ebene der entsprechenden Bibliotheken möglich ist, die mit AWS arbeiten. In der Tat micrometer-registry-cloudwatchgibt es eine Schnittstelle mit einer CloudWatchConfig defaultMethode, die den Wert korrekt überprüft und eine Ausnahme auslöst, wenn sie 20 überschreitet. Wenn Sie jedoch nachsehen org.springframework.cloud.aws.autoconfigure.metrics.CloudWatchExportAutoConfiguration, werden wir feststellen, dass die Konfiguration mit durchgeführt wirdorg.springframework.cloud.aws.autoconfigure.metrics.CloudWatchPropertiesConfigAdapter:
@Bean
@ConditionalOnMissingBean
public CloudWatchConfig cloudWatchConfig(CloudWatchProperties cloudWatchProperties) {
return new CloudWatchPropertiesConfigAdapter(cloudWatchProperties);
}Der Adapter überschreibt wiederum
batchSize()als
@Override
public int batchSize() {
return get(CloudWatchProperties::getBatchSize, CloudWatchConfig.super::batchSize);
}Das heißt, wenn eine
CloudWatchPropertiesEigenschaft definiert ist, wird sie von dort übernommen. Es enthält nur nicht die erforderlichen Überprüfungen. Wenn die Eigenschaft nicht explizit festgelegt ist, lautet der Standardwert 10000.
Anfragen an AWS
Eine Anwendung (ein Dienst) kann nicht nur Anfragen an Amazon-Dienste stellen. Sie müssen Anmeldeinformationen enthalten. Zu diesem Zweck verfügt das AWS SDK über eine Anbieterkette für Anmeldeinformationen , die empfohlen wird. Zu diesen Anbietern gehört das Instanzprofil, das Daten basierend auf EC2-Metadaten empfangen kann. Damit dies funktioniert, müssen Sie sicherstellen, dass eine Rolle an EC2 gebunden ist .
Die Rolle muss Berechtigungen erteilen, um Anforderungen an CloudWatch zu stellen und EC2 zur Verfügung zu stehen. Die Rolle kann sowohl beim Erstellen einer neuen EC2-Instanz angegeben als auch an eine vorhandene angehängt werden. Die Rolle wird im laufenden Betrieb angewendet.
Metriken deaktivieren
In einer lokalen Build- oder Testumgebung kann das Exportieren von Metriken zu viel des Guten sein. Durch Festlegen der Eigenschaft
management.metrics.export.cloudwatch.enabled=falsekönnen Sie den Export von Metriken nach CloudWatch deaktivieren, während die Erfassung von Metriken durchgeführt wird. Wenn Sie ein Webmodul angeschlossen haben, sind endpoint /metricsdiese weiterhin verfügbar.
Mikrometer sammelt und liefert eine Vielzahl von Metriken. Wenn einige von ihnen nicht benötigt werden, können Sie sie deaktivieren. Sie können sowohl einzeln als auch nach ganzen Kategorien deaktivieren. So deaktiviert die Eigenschaft beispielsweise alle Metriken, deren ID mit beginnt . Bitte beachten Sie: Deaktivierte Metriken werden überhaupt nicht erfasst.
management.metrics.enable.some.metric=falsesome.metric
Alle AWS ausführen
Eine weitere Überraschung erwartet Sie, wenn Sie versuchen, die Anwendung mit den minimal erforderlichen Einstellungen für alle AWS auszuführen. Für die Arbeit die erforderlichen Daten der Region, in der die Anwendung ausgeführt wird. Wie wir bereits wissen, wird das AWS SDK versuchen, aus den Metadaten zu gelangen, die nicht vorhanden sind. Daher geben wir die gewünschte Region explizit durch die Eigenschaft an
cloud.aws.region.static=us-east-2. Wie im Fall des Namens des Stapels (der Eigenschaft cloud.aws.stack.auto) gibt es eine Eigenschaft, die standardmäßig cloud.aws.region.autogleich trueist. Aber es hilft uns nicht, den Wert einfach auf false zu setzen, da Der Wert der Region wird benötigt.
Wie wir uns erinnern, erfordern Anforderungen an AWS Anmeldeinformationen. Wenn Sie also Metriken an CloudWatch senden (oder andere Anforderungen an AWS stellen müssen), müssen Sie die Parameter für die Anmeldeinformationen explizit angebenüber beispielsweise Anwendungseigenschaften oder Umgebungsvariablen.
Das Durchlaufen von Anwendungseigenschaften sieht folgendermaßen aus:
cloud.aws.credentials.access-key=YOUR_ACCESS_KEY
cloud.aws.credentials.secret-key=YOUR_SECRET_KEY
Ergebnis
Wie Sie vielleicht bemerkt haben, ist es nicht so schwierig, das gesamte Schema zum Laufen zu bringen und Metriken von der Anwendung auf CloudWatch zu übertragen: Es waren 3 Abhängigkeiten und 3 Eigenschaften erforderlich .
Das Wichtigste liegt im Detail. Bibliotheken (Frameworks) wie Spring und AWS SDK versuchen, das Leben zu vereinfachen und die gesamte Arbeit für uns so weit wie möglich zu erledigen. Gleichzeitig kann jeder Schritt zur Seite zum Auftreten einer Stapelverfolgung führen und versucht zu verstehen, warum die Metriken nirgendwo hingehen und warum die Anwendung überhaupt nicht startet und wie man es repariert. Ich hoffe, dass ein Abschnitt mit einer Aufschlüsselung der Nuancen und einer Beschreibung einiger Details zur Funktionsweise von EC2- und CloudWatch-Diensten Ihnen das Verständnis der Vorgänge erleichtert.
Wenn wir über die Verwendung von CloudWatch selbst sprechen, ist dies meiner Meinung nach eine ziemlich natürliche Wahl, wenn Sie die AWS-Infrastruktur verwenden.
Metriken sind die Augen und Ohren unserer Anwendung. Dies negiert jedoch nicht die Tatsache, dass Sie verstehen müssen, wie Metriken erfasst, gezählt und angezeigt werden. Welche Art von Daten sehen Sie in Ihren Diagrammen? Dieses Problem wird besonders akut sein, wenn Anomalien auftreten und Vorfälle analysiert werden. Wenn wir über die Mikrometerbibliothek sprechen, lohnt es sich, auf die Dokumentation zu verweisen . Dort wird beispielsweise ausführlich auf die Zählertypen (Meter) eingegangen.
Links
Der Erfahrungsaustausch ermöglicht es uns, verschiedene Ansätze, Werkzeuge und Technologien schnell zu beherrschen und voranzukommen. Daher kann ich die nützlichsten Materialien zu diesem Thema nicht ignorieren, auf die im Artikel nicht verwiesen wurde:
Spring Boot: Metriken mit Mikrometer und AWS CloudWatch
Spring Cloud. Verwenden von Amazon Web Services. Spring Boot-Autokonfiguration
Spring in Action 5, Craig Walls, Manning
Beliebt bei Amazon Web Services Das
fertige Projekt finden Sie auf GitHub .