AWSCloudWatchでSpringBootアプリケーションメトリックを収集する

こんにちは！私の名前はArtemAreshkoです。LuxoftのFin-TechプロジェクトのリードJava開発者です。今日は、メトリック、Spring Boot、Amazonクラウドについて説明します。

はじめに...

産業開発には、アプリケーションがどのように機能するかについての知識が必要です。この論文は公理としてとらえるべきです。この知識は、アプリケーションによって生成されるメトリックです。メトリックは、純粋に技術的（たとえば、消費されたRAMの量）またはビジネス（たとえば、完了した注文）のいずれかです。



メトリックのカット自体は、現時点では必ずしも興味深く、示唆的であるとは限りません。これらのメトリックの収集、保存、および表示について、基本的な質問が発生します。



メトリックの必要性とその処理方法の状況は、サービスアプローチが使用され、ユーザーの観点から1つのアプリケーションが複数の相互作用するサービスの操作によってサポートされる場合、より深刻になります。それにクラウド展開を追加し、唐辛子を刈り取ります。

どんな内容ですか

私が参加しているプロジェクトは、サービスを使用してAWS（Amazon Web Services）にデプロイしているだけです。ほとんどのサービスは、Java 8以降、Spring Boot、およびDockerを使用して構築されています。Luxoft IT Sreda＃7での講演とこの記事は、プロジェクトのニーズと目的から生まれました。



私の目標は、Spring Bootを使用してアプリケーションメトリックを収集し、それらをAWSCloudWatchにエクスポートすることの実際的な側面を確認することです。これは、実際には、説明、ニュアンスの分析、および可能なレーキを含むステップバイステップガイドになります。



実際の問題を解決することについて話すとき、それを既存の環境と比較するためにその症状を理解することが重要です。私たちが話していることを1対1で適用することは可能ですか、それとも適応が必要な場合は、さらに調査を行うことは可能ですか。



現在のコンテキストが何で構成されているかを見てみましょう。

1. 当然のことながら、私たちのアプリケーションまたはサービスはSpringBootに基づいています。Mavenビルダーとして、Java 8+
2. Docker。ただし、その使用は重要ではありません。dockerで実行されているアプリケーションでは、すべてが機能することが重要です。
3. AWS EC2は、アプリケーションが実行されるインフラストラクチャです。中核となるのは、AWS内の仮想マシンです。
4. AWS CloudWatchは、AW​​Sインフラストラクチャダッシュボードである監視システムです。

春のブーツ

SpringBootとその機能に移りましょう。兵器庫で最初で最も重要なのはアクチュエーターです。このモジュールを使用すると、実行中のアプリケーションの内部を調べて、その動作をある程度カスタマイズできます。例えば：

• Health check:
• , , runtime.
• ,
• , , : , , GC.
• ...

多くのSpringコンポーネントと同様に、Actuatorはコンストラクターに似ており、カスタマイズ、拡張、および微調整が可能です。ここから勉強を始めることができます。



セット全体の中で、現在、メトリックに関心があります。特にアクチュエータとメトリクスは拡張可能であるだけでなく、事前に構成されているため、すぐに使用できるメトリクスのカテゴリは数十にすぎません。もちろん、独自のメトリックを登録することもできます。 Webモジュールがプロジェクトに接続されている場合は、に連絡してメトリックを取得できますendpoint /metrics。



メトリックの収集と配信は、Pivotalの製品であるマイクロメーターライブラリを介して実装されます（現在はVMwareの一部です）、Springを開発しているのと同じものです。micrometerは、Javaアプリケーションメトリックをエクスポートするためのベンダーに依存しないファサードとして販売されています。



アクチュエータを接続するには、次のスターターが必要です。

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

春の雲

次に、SpringCloudのモジュールが必要spring-cloud-starter-awsです。



Spring Cloudファミリーの各モジュールには独自のバージョンがあり、モジュールの特定のバージョンではなく、モジュールspring-cloud-dependenciesの互換性のあるバージョンが収集される特定のバージョン（リリーストレイン）のBOMを使用するのが正しいでしょう。これを書いている時点では、これはHoxton.RELEASEです。



AWSを操作するためのおいしい自動構成に加えて、一時spring-cloud-starter-aws的な依存関係として、を提供しaws-java-sdkます。



依存関係管理セクションに、

<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>

そしてに応じて：

<dependency>
   <groupId>org.springframework.cloud</groupId>
   <artifactId>spring-cloud-starter-aws</artifactId>
</dependency>

マイクロメーターレジストリ

これで、SpringActuatorとにマイクロメーターができましたaws-java-sdk。箱から出して、micrometerはデータをAWS CloudWatchにエクスポートできません。これには、メトリックを収集するためのmicrometer抽象化であるMeterRegestryの適切な実装が必要です。デフォルトはSimpleMeterRegistryで、データをメモリに保存します。必要な実装はと一緒に接続されmicrometer-registry-cloudwatchます。この記事の執筆時点では、現在のバージョンは1.3.5です。

<dependency>
   <groupId>io.micrometer</groupId>
   <artifactId>micrometer-registry-cloudwatch</artifactId>
   <version>1.3.5</version>
</dependency>

この場合、最終的なpom.xmlは次のようになります。github.com / MrArtemAA / blog-demos / blob / master / export-metrics-to-cloudwatch / pom.xml

app.properties

アプリケーションプロパティの設定に移りましょう。この場合、重要な役割を果たします



。1 management.metrics.export.cloudwatch.namespace。：メトリックがCloudWatchに保存される名前を指定する必要があります。なぜならメトリック自体には、データがアプリケーションのどのインスタンスから取得されたかについての情報はありません。名前付けは、特定のインスタンスのメトリックを決定するだけです。そうしないと、複数のインスタンスに対して1つの名前空間を定義すると、メトリックデータが混在し、それらがどこから来たのかが明確になりません。







2 management.metrics.export.cloudwatch.batch-size：明示的にこのパラメータ、なぜ正確に20ある何20にバッチサイズのプロパティの値を設定するために必要ですか？メトリックは、一度に20のバッチ（これはAWSの制限です）で、AmazonCloudWatchクライアントに非同期で送信されます。



3 cloud.aws.stack.auto=false：無効にする必要がAWS CloudFormationスタックの自動検出以来 デフォルトは= trueです。このプロパティは、アプリケーションがスタック名を自動的に取得して、クラウド環境用にアプリケーションを構成しようとするかどうかを決定します（infrastructure-as-codeパラダイム）。通常の仮想マシンのようにEC2にデプロイする場合、この情報は利用できません。



AWS SDKが追加の構成なしで独自に取得しようとするすべての情報は、[ライブラリ]がEC2メタデータから取得することを理解することが重要です。この情報を取得するために、呼び出しが行われる特別なサービスエンドポイントがあります。

デブリーフィング

バッチサイズ

プロパティに戻り、management.metrics.export.cloudwatch.batch-size20に設定する必要があります。これはすべて、AWSで動作する対応するライブラリのレベルで実行できるようです。実際、値を正しくチェックし、値が20を超えると例外をスローするメソッドをmicrometer-registry-cloudwatch備えたインターフェイスがありますCloudWatchConfig default。ただし、を見るとorg.springframework.cloud.aws.autoconfigure.metrics.CloudWatchExportAutoConfiguration、次を使用して構成が行われていることがわかります。org.springframework.cloud.aws.autoconfigure.metrics.CloudWatchPropertiesConfigAdapter:

@Bean
@ConditionalOnMissingBean
public CloudWatchConfig cloudWatchConfig(CloudWatchProperties cloudWatchProperties) {
  return new CloudWatchPropertiesConfigAdapter(cloudWatchProperties);
}

アダプターは、順番に、上書きされますbatchSize()ように

@Override
public int batchSize() {
  return get(CloudWatchProperties::getBatchSize, CloudWatchConfig.super::batchSize);
}

これは、CloudWatchPropertiesプロパティが定義されている場合、そこから取得されることを意味します。必要なチェックが含まれておらず、プロパティが明示的に設定されていない場合、デフォルト値は10000になります。

AWSへのリクエスト

アプリケーション（サービス）は、Amazonサービスにリクエストを送信するだけでは不十分です。それらの[リクエスト]には資格情報が含まれている必要があります。これを行うために、AWSSDKには資格プロバイダーチェーンがあります。これをお勧めします。これらのプロバイダーの中には、EC2メタデータに基づいてデータを受信できるインスタンスプロファイルがあります。これを機能させるには、ロールがEC2にバインドされていることを確認する必要があります。







ロールは、CloudWatchにリクエストを送信し、EC2で使用できるようにするためのアクセス許可を付与する必要があります。この役割は、新しいEC2インスタンスを作成するとき、または既存のインスタンスにアタッチするときに指定できます。役割はその場で適用されます。

メトリックの無効化

ローカルビルドまたはテスト環境の場合、メトリックのエクスポートはやり過ぎかもしれません。プロパティを設定するmanagement.metrics.export.cloudwatch.enabled=falseと、メトリックの収集が実行されている間、CloudWatchへのメトリックのエクスポートを無効にできます。また、Webモジュールが接続されている場合は、endpoint /metricsそれらを引き続き使用できます。



Micrometerは、さまざまなメトリックを収集して提供します。それらのいくつかが不要な場合は、無効にすることができます。個別に、またはカテゴリ全体で無効にすることができます。したがって、たとえば、プロパティはIDが。で始まるすべてのメトリックを無効にします。注意：無効にされたメトリックはまったく収集されません。management.metrics.enable.some.metric=falsesome.metric

すべてのAWSを実行する

すべてのAWSで必要最小限の設定でアプリケーションを実行しようとすると、もう1つの驚きが待っています。操作のために、アプリケーションが実行されている地域の必要なデータ。すでに知っているように、明示的に述べられていないものは何でも、AWSSDKはメタデータから取得しようとします...そこにはありません。したがって、プロパティを使用して目的の領域を明示的に示しますcloud.aws.region.static=us-east-2。スタックの名前（property cloud.aws.stack.auto）の場合と同様に、デフォルトでcloud.aws.region.auto等しいプロパティがありtrueます。ただし、値をfalseに設定するだけでは、役に立ちません。地域の価値が必要です。



また、覚えているように、AWSへのリクエストには資格情報が必要なため、メトリックをCloudWatchに転送する（またはAWSに他のリクエストを行う）必要がある場合は、資格情報のパラメータを明示的に指定する必要がありますたとえば、アプリケーションのプロパティや環境変数を介して。



アプリケーションプロパティのパススルーは次のようになります。

cloud.aws.credentials.access-key=YOUR_ACCESS_KEY

cloud.aws.credentials.secret-key=YOUR_SECRET_KEY

結果

お気づきかもしれませんが、スキーム全体を機能させ、アプリケーションからCloudWatchにメトリックを転送することは、それほど難しくありません。3つの依存関係と3つのプロパティが必要でした。



最も重要なことは細部にあります。 Spring、AWS SDKなどのライブラリ（フレームワーク）は、作業を楽にし、可能な限りすべての作業を実行しようとしていますが、同時に、少しでも離れると、スタックトレースが表示され、メトリックがどこにも行かない理由、アプリケーションがまったく起動しない理由を理解しようとします。そしてそれを修正する方法。ニュアンスの内訳とEC2およびCloudWatchサービスがどのように機能するかの詳細のいくつかの説明を含むセクションが、何が起こっているのかを理解するのに役立つことを願っています。



CloudWatch自体の使用について話す場合、私の意見では、これはAWSインフラストラクチャを使用する場合のかなり自然な選択です。



メトリックはアプリケーションの目と耳ですが、これは、メトリックがどのように収集、カウント、表示されるかを理解する必要があるという事実を否定するものではありません。チャートにはどのようなデータが表示されますか。この問題は、異常やインシデントの分析が発生した場合に特に深刻になります。マイクロメータライブラリについて説明する場合は、ドキュメントを参照する価値があります。たとえば、メータのタイプ（Meter）について詳細に説明されています。

リンク

経験を交換することで、さまざまなアプローチ、ツール、テクノロジーをすばやく習得し、前進することができます。したがって、このトピックで最も有用な資料を無視することはできません。これらの資料は、記事「



Spring Boot：Metrics WithMicrometer」および「AWSCloudWatchSpringCloud

」では参照されていません。AmazonWebサービスの使用。SpringBootの自動構成

Springin Action 5、Craig Walls、Manning

AmazonWebサービスで人気



完成したプロジェクトはGitHubにあります。

著者：Artem Areshko、リードJava開発者