Elastic Observability による AWS サービスメトリクスの高速な監視

# Elastic Observability　による　AWS　サービスの統合的な監視
分散型アプリケーションへの移行が本格化しています。その主な理由は、消費者としての「常時接続」の必要性と、ペースの速いビジネスです。このニーズは、グローバルな多様性と迅速な技術革新の能力とともに、より複雑な要件を持つデプロイメントを推進しています。
クラウドは、今日のアプリケーションにとって事実上のデプロイメントの選択肢となりつつあります。多くのクラウド導入企業は、グローバルに多様な地域をカバーする AWS と、より迅速な開発とイノベーションのための無数のサービス、そして運用コストと資本コストの削減のために、アプリケーションのホスティングを AWS 上で行うことを選択します。AWS では、開発チームが Amazon EKS 上の Kubernetes への移行、最新のサーバーレスオプションのテスト、より優れたサービスによる従来の階層型アプリケーションの改良にさらなる価値を見いだしつつあります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/33599/8a39b369-2fdb-077d-85f8-bebd0ed68f3e.png)
Elastic Observability は AWS のサービスに対して30の統合機能を提供しており、今後も追加していく予定です。
そのうちのいくつかは、以前のブログ投稿で紹介されています。
•[Elastic and AWS : Seamlessly ingest logs and metrics into a unified platform with ready-to-use integrations](https://www.elastic.co/jp/blog/elastic-and-aws-seamlessly-ingest-logs-and-metrics-into-a-unified-platform-with-ready-to-use-integrations) 

ElasticにおけるAWSの主要なサービス統合に関する追加ブログ投稿をいくつか紹介します。
•[APM (metrics, traces and logs) for serverless functions on AWS Lambda with Elastic](https://www.elastic.co/jp/blog/observability-apm-aws-lambda-serverless-functions) 
•[Log ingestion from AWS Services into Elastic via serverless forwarder on Lambda](https://www.elastic.co/jp/blog/elastic-and-aws-serverless-application-repository-speed-time-to-actionable-insights-with-frictionless-log-ingestion-from-amazon-s3) 
•[Elastic’s Amazon S3 Storage Lens Integration : Simplify management, control costs, and reduce risk](https://www.elastic.co/jp/blog/new-elastic-and-amazon-s3-storage-lens-integration-simplify-management-control-costs-and-reduce-risk) 
•[Ingest your container logs into Elastic Cloud with AWS FireLens](https://www.elastic.co/jp/blog/elastic-cloud-with-aws-firelens-accelerate-time-to-insight-with-agentless-data-ingestion) 

AWS との統合の全リストは Elastic のオンラインドキュメントでご覧いただけます。
•[Full list of AWS integrations](https://docs.elastic.co/en/integrations/aws) 

Elastic Observability は、AWS とのネイティブな連携に加え、ログだけでなく AWS サービスや AWS のコンピュートサービス（EC2、Lambda、EKS/ECS/Fargate）上で動作するアプリケーションのメトリクスも集約しています。これらのデータはすべて、Elastic の高度な機械学習機能を使って視覚的により直感的に分析することができ、エンドユーザーが影響を受ける前にパフォーマンスの問題を検出し、根本原因を浮上させるのに役立ちます。
Elastic Observability が提供するサービスマップ、トレース、依存関係、ML ベースのメトリクス相関などのアプリケーションパフォーマンスモニタリング（APM）機能の詳細については、こちらをご覧ください。
•[APM correlations in Elastic Observability : Automatically identifying probable causes of slow or failed transactions](https://www.elastic.co/jp/blog/apm-correlations-elastic-observability-root-cause-transactions) 
•[Elastic and AWS : Get the most value from your data sets](https://www.elastic.co/jp/blog/elastic-and-aws-get-the-most-value-from-your-data-sets) 

これらにある通り、Elastic は AWS サービスや　AWS　コンピュートサービス（EC2、Lambda、EKS/ECS/Fargate）上のアプリケーションに対してメトリクスの取り込み、集約、分析を提供します。Elastic　は単なるログではなく、AWS　環境における統一された観測可能なソリューションを提供します。
このブログでは、Elastic Observability　がどのように　AWS　サービス上で動作するシンプルな　AWS　アプリケーションのメトリクスを監視できるかをレビューしていきます。
•	AWS EC2
•	AWS ELB
•	AWS RDS (AuroraDB)
•	AWS NAT Gateways 

AWS Integration をインストールすると、メトリクスが即座に到着し、すぐにメトリクスの確認を開始することができます。

# 前提条件と構成
このブログを見てやってみようと思われる方は、このデモをセットアップするために使用したコンポーネントと詳細を参照してください。
•[Elastic Cloud](http://cloud.elastic.co/) のアカウントとデプロイ済みスタックがあることを確認してください（[こちらの手順を参照](https://www.elastic.co/guide/en/elastic-stack/current/installing-elastic-stack.html)） 。
• AWS から必要なデータを引き出すための権限を持つAWSアカウントを持っていることを確認します。[詳しくはドキュメントをご覧ください](https://docs.elastic.co/en/integrations/aws#aws-permissions)。 
•[AWS の3層アプリ](https://github.com/aws-samples/aws-three-tier-web-architecture-workshop) を使用し、gitの指示通りにインストールしました。
•一般的な [Elastic AWS Integration](https://docs.elastic.co/en/integrations/aws)のインストール方法を説明します。メトリクスを収集したい4つのサービスをカバーしています。[(Full list of services supported by the Elastic AWS Integration)]( https://docs.elastic.co/en/integrations/aws#reference) 
•他のブログでは AWS のアプリケーション監視（メトリクス、ログ、トレース）を扱っているので、ここではアプリケーション監視は取り上げません。その代わり、AWS のサービスをどのように簡単に監視できるかに焦点を当てます。
•メトリクスを見るためには、アプリケーションをロードする必要があります。また、アプリケーションにトラフィックを与えるために、playwright スクリプトを作成しました。

# 3層アプリケーションの概要
Elastic の設定に入る前に、モニタリングしている内容を確認します。[aws-three-tier-web-architecture-workshop]( https://github.com/aws-samples/aws-three-tier-web-architecture-workshop) の手順通りに進めると、以下のようなサービスがデプロイされた状態になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/33599/a8e04cf0-fffc-430a-1c71-bd44c36d340c.png)
デプロイされているリソース一覧:
- 1 VPC、6サブネット
- 2 AZ
- 2 Web サーバー/AZ
- アプリケーションサーバー 2台/AZ
- 1 外部向けアプリケーションロードバランサー
- 1 内部向けアプリケーション・ロード・バランサー
- アプリケーション層へのトラフィックを管理するための NAT ゲートウェイ2台
- 1 インターネットゲートウェイ
- 1 RDS Aurora DB（リードレプリカ付き)

# セットアップ
アプリケーションの取得方法、Elastic での AWS 連携、そして何がインジェストされるのか、順に詳しく解説していきましょう。
## ステップ　0:AWS Three Tier アプリケーションをロードし、クレデンシャルを取得する
[AWS の Three Tier app](https://github.com/aws-samples/aws-three-tier-web-architecture-workshop) に記載されている手順と、git 上のワークショップのリンクに記載されている手順にしたがってください。ワークショップは[こちら]( https://catalog.us-east-1.prod.workshops.aws/workshops/85cd2bb2-7f79-4e96-bdee-8078e469752a/en-US)に記載されています。
アプリをインストールしたら、AWSからクレデンシャルを取得します。これはElasticのAWSインテグレーションに必要です。
クレデンシャルにはいくつかのオプションがあります。
•	アクセスキーを直接使用する
•	一時的なセキュリティ認証情報を使用する
•	共有クレデンシャルファイルを使用する
•	IAM ロールの Amazon リソース名 (ARN) を使用する
必要な[認証](https://docs.elastic.co/en/integrations/aws#aws-credentials) や[権限]( https://docs.elastic.co/en/integrations/aws#aws-permissions) に関する詳細な仕様については、リンク先をご確認ください。
## ステップ　1：Elastic Cloud のアカウントを取得します。
指示に従って、[Elastic Cloud の利用を開始](https://cloud.elastic.co/registration?fromURI=%2Fhome)します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/33599/d3ebccb0-7ab2-3162-1788-823f5e52fbdb.png) 
## ステップ2：Elastic AWS インテグレーションをインストールする
Elastic 上の AWS インテグレーションに移動します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/33599/1fb80706-c170-f8d1-23e2-aa723fb9c988.png)
Add AWS Integration を選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/33599/b5cd9652-5b5d-a5e0-98cc-eb0adf9799ce.png)

ここで資格情報を追加すると、Elastic のポリシーとして保存されます。このポリシーは、次のステップでエージェント用のインストールの一部として使用されます。
ご覧の通り、一般的な Elastic AWS Integration は、30個の　AWS　サービスから相当な量のデータを収集します。この一般的な Elastic AWS Integration をインストールしない場合は、個別の Integration を選択してインストールすることができます。

## ステップ3：AWS 連携による Elastic Agent のインストール
Integration ポリシーを作成したので、Elastic の Management にある Fleet セクションに移動してください。 
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/33599/4ad773b7-dc16-1865-d476-ea5dfcbc855e.png) 
最後のステップで作成したポリシーの名前を選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/33599/585783cb-991b-238b-74db-4d8b02917ee5.png)
“エージェントの追加”ウィンドウの指示のステップ3に従ってください。これには、以下のことが必要になります。
1: EC2 インスタンスを立ち上げる
•	t2.medium 最小
•	Linux - どれを選択してもよい
•	EC2 インスタンスの起動時に Open reservation を許可しておく
2:インスタンスにログインし、Linux コマンドを実行します（以下は例です）:
```c
curl -L -O https://artifacts.elastic.co/downloads/beats/elastic-agent/elastic-agent-8.5.0-linux-x86_64.tar.gz
tar xzvf elastic-agent-8.5.0-linux-x86_64.tar.gz
cd elastic-agent-8.5.0-linux-x86_64
sudo ./elastic-agent install --url=https://37845638732625692c8ee914d88951dd96.fleet.us-central1.gcp.cloud.es.io:443 --enrollment-token=jkhfglkuwyvrquevuytqoeiyri
```

## ステップ4：アプリケーションに対してトラフィックを実行する
アプリケーションの実行はかなり簡単ですが、アプリケーションに負荷を加えない限り、Elastic で監視したり観察したりすることはできません。ここでは、AWS の3層アプリケーションの Web サイトにトラフィックを追加するために、[Playwright](https://playwright.dev/) を使用して実行することもできる簡単なスクリプトを紹介します。
```ts
import { test, expect } from '@playwright/test';
test('homepage for AWS Threetierapp', async ({ page }) => {
  await page.goto('http://web-tier-external-lb-1897463036.us-west-1.elb.amazonaws.com/#/db');

  await page.fill('#transactions > tbody > tr > td:nth-child(2) > input', (Math.random()*100).toString())
  await page.fill('#transactions > tbody > tr > td:nth-child(3) > input', (Math.random()*100).toString())
  await page.waitForTimeout(1000)
  await page.click('#transactions > tbody > tr:nth-child(2) > td:nth-child(1) > input[type=button]')
  await page.waitForTimeout(4000)
});
```
このスクリプトは3つのブラウザを起動しますが、playwright.config.ts ファイルでこの負荷を1つのブラウザに制限することができます。
今回の演習では、Web サイトのテストを行いながら、5分間隔で約5時間、このトラフィックを実行しました。

## ステップ5：AWSダッシュボードに移動する
Elastic Agent が稼働しているので、関連する AWS ダッシュボードにアクセスし、インジェストされているものを確認することができます。
AWS Integration のダッシュボードを検索するには、Elastic の検索バーで検索すれば OK です。
このブログで関連するのは下記の通りです :
•	[Metrics AWS] EC2 概要ダッシュボード
•	[Metrics AWS] ELB 概要ダッシュボード
•	[Metrics AWS] RDS 概要ダッシュボード
•	[Metrics AWS] NAT ゲートウェイダッシュボード
#### Elastic Observability EC2 概要ダッシュボード
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/33599/e9fbbc64-20e9-c42f-cf4f-3bc8b05a5d05.png)
4台の EC2 インスタンス（Web サーバー2台、アプリケーションサーバー2台）にフィルタをかけると、次のようになります。
1: 4つのインスタンスはすべて稼働しており、ステータスチェックに失敗していない。
2: 時間枠内の平均 CPU 使用率を見て、異常はなさそう。
3: データベースに行がロードされるにつれて、ネットワークバイトが流入・流出し、時間と共に集約されるのがわかります。
この演習では、表示可能なメトリクスのごく一部を紹介しましたが、AWS EC2 ではさらに多くのメトリクスが利用可能です。[AWS のドキュメント](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html)に記載されているメトリクスは、特定のインスタンスを絞り込むのに役立つディメンションなど、すべて利用可能です。

#### Elastic Observability ELB 概要ダッシュボード
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/33599/beb2d89c-f52c-48fb-c398-5e7f4386ab63.png) 
ELB ダッシュボードでは、2つのロードバランサー（外部 Web ロードバランサーと内部アプリケーションロードバランサー）をフィルタリングしています。
ダッシュボードでは、アプリケーション ELB に特化したメトリクスを見ることができます。[AWS のドキュメント]( https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) に記載されているアプリケーション ELB 固有のメトリクスの大部分において、グラフを追加することが可能です。
今回の2つのロードバランサーの場合、以下のことがわかります。
1: 両方のホスト（ELB に接続されている EC2 インスタンス）が正常である。
2: Load Balancer Capacity Units（どれだけ使っているか）、リクエスト数ともにトラフィック発生時間帯に予想通り上昇した。
3：4XXと2XXのカウントを表示するように選びました。4XXは、アプリケーションの問題やアプリケーションサーバーとの接続性の問題を特定するのに役立ちます。
#### Elastic Observability RDS の概要ダッシュボード
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/33599/a350d1c7-699a-f9ab-880f-3770a0e8e9e4.png)
RDS に展開されている Aurora DB については、ダッシュボード上で Aurora のプライマリとセカンダリのインスタンスだけをフィルタリングしています。
EC2、ELB と同様に、CloudWatch のほとんどの RDS のメトリクスも、新しいチャートやグラフを作成することが可能です。今回のダッシュボードでは、表示するものを絞りました。
1: 挿入スループット、選択スループット
2: 書き込みレイテンシ
3: CPU 使用率
4: 時間枠内の一般的な接続数
#### Elastic Observability AWS NAT ゲートウェイダッシュボード
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/33599/77291a71-d737-36c1-189d-540b02153c81.png)
アプリケーションサーバーの前にある2つの NAT インスタンスだけを見るようにフィルタリングしました。他のダッシュボードと同様に、他のメトリクスも必要に応じてグラフや/チャートを作成することが可能です。
NAT ダッシュボードでは、次のようなことが確認できます。
1: パケットドロップがないため、NAT ゲートウェイは正常に動作しています。
2: Web サーバーからのアクティブな接続数が予想される。
3: バイトインとバイトアウトのメトリクスはほぼ正常です。
おめでとうございます。これで、あなたのアプリケーションのために、主要な AWS サービスからのメトリクスを監視し始めました。
# 次に AWS で何を監視するのか？
## AWS サービスからログを追加する
メトリクスが監視されるようになったので、今度はロギングを追加することもできるようになりました。ログの取り込みには、いくつかのオプションがあります。
1. Elastic Agent の AWS Integration にログの設定があります。受け取りたいものを確実に ON にすれば OK です。RDS から Aurora Logs をインジェストしてみましょう。Elastic Agent のポリシーで、Collect logs from CloudWatch を ON にするだけです（下記参照）。次に、Fleet の管理 UI からエージェントを更新します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/33599/597a945c-bdd4-bb39-3db8-79cb6bf45afb.png) 
2. [Lambda logs forwarder](https://github.com/elastic/elastic-serverless-forwarder/blob/main/docs/README-AWS.md#deploying-elastic-serverless-forwarder)をインストールすることができます。このオプションは、複数の場所からログを取得します。以下のアーキテクチャ図を参照してください。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/33599/28addc07-d1fb-aaa8-8235-c1bcfba1fe10.png)
このオプションに関する内容は、以下の[ブログ](https://www.elastic.co/jp/blog/elastic-and-aws-serverless-application-repository-speed-time-to-actionable-insights-with-frictionless-log-ingestion-from-amazon-s3)でも紹介されています。 
## Elastic Machine Learning でデータを分析する
メトリックスとログ（またはどちらか一方）をElasticに取り込んだら、Elastic の ML 機能を使ってデータの分析を始めましょう。これらの機能に関して有益なブログや記事はこちらでご覧いただけます。
•[Correlating APM Telemetry to determine root causes in transactions](https://www.elastic.co/jp/blog/apm-correlations-elastic-observability-root-cause-transactions) 
•[Introduction to Elastic Machine Learning](https://www.elastic.co/jp/elasticon/archive/2020/global/machine-learning-and-the-elastic-stack-everywhere-you-need-it) 
また、Elastic の Web サイトには他にもたくさんのビデオや[ブログ](https://www.elastic.co/jp/blog/)があります。

# 結論 : Elastic Observability で AWS のサービスメトリクスをモニタリングするのは簡単！？
Elastic Observability がどのように AWS サービスメトリクスの監視に役立つのか、ご理解いただけたと思いますので、ここでレッスンと学んだことを簡単にまとめておきます。
•	Elastic Observability は AWS サービスメトリクスのインジェストと分析に対応している
•	Elastic Agent 経由で AWS サービスからのインジェストを簡単に設定できる。
•	Elastic Observability には、すぐに使える （OOTB）AWS サービスダッシュボードが複数あり、情報を事前に確認し、ニーズに合わせて変更することができる。
•	30以上の AWS サービスが AWS Integration on Elastic Observability の一部としてサポートされており、さらに多くのサービスが定期的に追加されます。
•	関連ブログでご紹介しているように、Elastic の機械学習機能を使って AWS サービスのメトリクスを分析することができます。
すぐにでも始めてみましょう！ [Elastic Cloud](https://cloud.elastic.co/registration) に登録し、上記で紹介した機能や性能を試してみてください。
[元のブログ](https://www.elastic.co/jp/blog/aws-service-metrics-monitor-observability-easy)

Elastic テクニカルプロダクトマーケティングマネージャー/エバンジェリスト
鈴木章太郎