HULFT10 for Container Servicesの運用監視のためにCloudWatchのダッシュボードを作成してみた

## はじめに

最近の記事でもお察しの通り、いわゆるコンテナ版HULFTについて一通り整理しています。今回は、HULFT10 for Container Servicesの「運用監視」について整理します。

HULFT10 for Container ServicesはAWS上のサービスであるため、運用監視もAWSサービス（CloudWatch）を活用します。

## Amazon CloudWatchとは
Amazon CloudWatchはAWS、オンプレミス、および他のクラウド上のリソースとアプリケーションを観察及び監視するサービスです。
<table>
 <thead>
  <th>役割</th><th>仕組み</th>
 </thead>

 <tr>
  <td align="left">
 アプリケーションの監視<br>
 ・パフォーマンスの変化に対応<br>
 ・リソースの使用を最適化<br>
 ・運用状況に関する洞察
  </td>
  <td align="left">
 基本的にはメトリクスで作られる。<br>
 メトリクスをリポジトリに置き、これらの<br>
 メトリクスを基に統計取得します。
  </td>
 </tr>
</table>

CloudWatchの仕組みを図で示すと下記のようになります。

![001_CloudWatchイメージ.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/cd4fb740-93d4-69f9-6db5-fb21e6322348.png)



## HULFT10 for Container Servicesの監視対象
まず運用監視にあたって、HULFT10 for Container Servicesのログについて整理したのがこちら。3か所に各種ログが保持されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/e0aad6b4-3b3d-5bfb-c5e4-10b00d9a018a.png)

#### ①HULFT10 for Container Services管理画面で確認できるログ
HULFT配信履歴や集信履歴。転送エラーが発生したときに利用者がはじめに確認するログです。エラー概要について確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/cbd92092-4a21-b7c0-f185-4cfcb618f424.png)

#### ②CloudWatchで確認できるログ
HULFT10 for Container Servicesに関連するAWSサービスのログをCloudWatchのロググループから確認できます。CloudWatchで収集されたログはダッシュボードで可視化できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/19c329f1-06e4-7293-475b-1f07a6b5f969.png)

### ③S3バケット内に保持されるログ
下記の通り、2つのバケットにそれぞれログが保存されます。

| バケット名 | 内容 |
|:-----------|:------------|
|s3-accesslog-hulft-xxxxxxx|S3のサーバアクセスログ|
|s3-hulft-xxxxxxx|Amazon Application Load Balancer アクセスログ|
|s3-hulft-xxxxxxx|Amazon Network Load Balancer アクセスログ|
|s3-hulft-xxxxxxx|VPCフローログ|

※バケット名は、機能Update等により変更になる可能性があります。

これら大きく3か所に配置されるログを利用して、HULFT10 for Container Servicesの運用監視を実施します。


## AWSのコンテナ監視とは
AWSサービスや各種リソースの監視方法としては、2通りあります。
* Container Insights の有効化
* CloudWatchダッシュボードの作成

HULFT10 for Container ServicesはAWS ECSサービスが基盤です。

### Container Insightsの有効化
AWSでは、「Container Insights」というコンテナ稼働リソースの監視に特化した機能が用意されています。

:::note info
**「Container Insights」有効化のPoint①**
コンテナアプリケーションとマイクロサービスのメトリクスやログを収集、集計してくれる
:::
:::note
**「Container Insights」有効化のPoint②**
Amazon ECSのタスクやサービスライフサイクルイベントをContainer Insightsコンソールで確認できる
:::


Container Insightsの有効化は 「**AWS CLI**」で実施します。
コマンドは下記の通り。
![002_投入コマンド.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/dfffbc07-6e11-1bf2-3045-4da46ba43344.png)

尚、「--cluster」で指定するクラスターは、HULFT10 for Container Servicesの場合、下記の通り確認します。
（参考記事）[HULFT10 for Container Services環境構築してみた](https://qiita.com/sugimon/items/e589e654f7bb38825550)

　①*CloudFormation Template2* の実行スタックのリソースの **ECSSummary1**
　②*ECSSummary1* のリソースで **ECS1**
　③*ECS1* のリソースの **EcsCluster** の物理IDの値
![003_クラスター特定.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/c2c544e3-6260-2720-7f6b-fc7714a09ed4.png)


 「**AWS CLI**」でコマンド実行が正常にされると、Container Insightsが有効になります。また、「**ECSコンソール**」で有効化されたことを確認できます。
![004_ecsコンソール.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/1e7a83d1-7122-13c3-d6b4-7220b1f11c7a.png)
対象クラスターのCloudWatchモニタリングが「☑Container Insights」になります。
![005_ContainerInsight有効.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/23d58ef4-6ffd-5e67-f44b-ee306548d2ee.png)

また、CloudWatchのContainer Insights-「コンテナマップ」でコンテナの状態を確認することも可能になります。
![006_コンテナマップ.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/d54bd4e9-d680-f875-f383-84d0235be8e6.png)


### CloudWatchダッシュボードの作成
CloudWatchではダッシュボードを作成し、各種AWSリソースに対する関する設定を行い、任意で監視内容を可視化することができます。

今回は、HULFT10 for Container Services の運用に関連するメトリクスとログをモニタリングできるようにしてみます。

#### CloudWatchコンソール（ウィジットの追加）
ダッシュボード名を指定し、空のダッシュボードを作成します。
![007_ダッシュボード新規作成1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/b8d34090-7290-26ea-5112-7d9e7a6602c0.png)

ダッシュボード右上の[+]を押下し、ウィジェット（グラフ等）が追加できます。

HULFT10で使用している、ウィジェットを作成してみます。

ECSのメトリクス「CPUUtilization（ECSのCPU使用率のグラフを表示）」があるので、そのメトリクスのグラフをダッシュボードに追加します。
![008_ウィジェット追加１.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/9a07070a-b675-06de-3bb5-c1399ac7dbb9.png)
設定内容は下記の通り。
・データソースタイプ「CloudWatch」
・ウィジェットの設定
　　▽データ型：「メトリクス」
　　▽ウィジェットのタイプ：「線（折れ線グラフ）」

メトリクスグラフの追加で、グラフ化するメトリクスを選択します。

![009_メトリクス選択.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/c96c231e-0d3b-fc17-77d1-f1ccf403c1db.png)

「ECS」-「ClusterName,ServiceName」を選択し、メトリクス名が「CPUUtilization」のメトリクスを２つチェックします。

:::note warn
HULFT10 for Container Servicesは2つのコンテナサービスで構成されるため、メトリクスは2つチェックする必要があります。
（管理コンテナ：Controlサービス、転送コンテナ：transferサービス）
:::

ウィジェットの作成でダッシュボードに下記のようなグラフが追加されます。
これで、ECSのCPU使用率（サービス毎）のウィジェットが作成されました。
![010_グラフ.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/60a65252-9638-137d-3aef-f0b427d6d728.png)

:::note
監視目的に合うメトリクスとそのメトリクスを視覚化するのに適したグラフを選択しウィジェットを追加することで、使いやすいダッシュボードが好きにカスタマイズできます！
:::

#### CloudWatchコンソール（ログの表示）
CloudWatchのロググループで確認できるログは、簡単にダッシュボードに表示できます。
ログの出力内容にもよりますが、監視ポイントとしたいログを他のログに埋もれないように、監視条件にあったログだけをダッシュボードに表示します。

ログのインサイト画面を表示します。CloudWatchコンソールで「ログ」-「ログのインサイト」に移動します。

![011_ログインサイト1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/0dcd7247-7609-70f7-a770-6ebaac1ed1a0.png)

下記の通り、対象の「ロググループ」と「表示条件」を設定します。
　　・ロググループ　：　HULFT10のcontrolのログ
　　・条件　　　　　：　ログレベルがERROR

 ロググループは選択するだけでOKです。条件の設定は、ログの書式を確認し、クエリを編集する必要があります。
 
::: note 
 「メッセージの書式確認」は、「デフォルトで表示されているクエリを実行する」ことで、同じ画面内で確認できるようになります。
:::


![012_ログ書式確認.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/df4f3265-1bf6-d27e-b5c1-4eb8de8df11c.png)
下記の通り設定して、クエリ「実行」を押下。
　　・クエリ編集　　　：　3行目 limit 1000 ⇒　limit 10

Logs(10）の出力結果の1行目の▶をクリックし、@message を確認します。
![013_ログ書式結果.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/83389215-0023-b099-7ea5-7fb4e8acba85.png)

 ログの書式がわかったら、抽出条件に合うようにクエリを編集します。
 今回は@message内のログレベル（[INFO]となっている箇所）が[ERROR]のログを抽出する必要があるので、下記のようなクエリにします。
 ![014_ログクエリ.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/347ec5cb-a04d-ca39-c1eb-c1c640ac435e.png)
2行目と3行目にログレベルがERRORという条件のために追加したクエリです。
画像では見えていませんが、5行目にlimitの記載があります。
![015_ログクエリ詳細.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/021c6d55-71ea-f51f-3639-3301f7624417.png)
　parseで@messageの内容を3つの情報に分解して、それぞれloggingxxxxのように名前付け
　filterでloggingTypeがERRORのデータだけを抽出

 クエリの編集後に、クエリの実行を行なって問題がなければ、ダッシュボードに追加を押下します。
 ![017_ダッシュボードに追加.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/0c6ad89a-fa40-4658-08fc-79ff5c457c0d.png)

 「ダッシュボードに追加」の画面で、作成したダッシュボードを選択し、「ダッシュボードに追加」を押下します。

 ![016_ダッシュボード１.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/60caf0d7-fea3-21d5-7a5f-29e3b06d3e1a.png)

ダッシュボードにログを出力することができました。

これまでの手順の通り、EFSのストレージ容量やECSのCPUクレジット数など追加して、下記のようなダッシュボードが作成できました。
![018_ダッシュボード.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/a7e7ad0a-5151-3ff6-6c27-99f2ca367fbd.png)

## 最後に
いかがでしたでしょうか。コンテナ運用監視についてどんなことができるか確認してみました。AWS CloudWatchはまだまだ機能がありますので、もっと色々と使ってみたいと思います。またそれは別記事でご紹介できたらと思います！

このブログでは、今後も様々なTopics記事や接続検証等、皆さんの参考になるような記事を投稿していきたいと思います！
ここまで読んでいただきありがとうございました。それでは、また！:raised_hand: