継続は力なり

タイトル通り定期的な更新を心掛けるブログです。

AWS CLI で振り返る AWS 障害時の各種ステータス確認方法

タダです.

先日, AWS で大規模なネットワーク障害が発生して様々な部分で影響が出ていたと各種メディアで報じられていました.

aws.amazon.com

8/28追記

2019年8月28日(日本時間)更新 で記事が更新されました.更新された箇所を引用します.影響箇所として新たに EC2 の障害が発生した Availability Zone の RDS, Redshift, ElastiCache, WorkSpaces, 予期せぬ影響として ALB の記載が追加されました.個別の問題は AWS より個々の利用者に共有するとのことです.

今回のイベントは、東京リージョンの1つのアベイラビリティゾーン(AZ)の一部に影響を与えました。この影響は当該 AZ の Amazon EC2 および Amazon EBS のリソースに対するものですが、基盤としている EC2 インスタンスが影響を受けた場合には、当該 AZ の他のサービス(RDS、 Redshift、 ElastiCache および Workspaces 等)にも影響がありました。お客様と今回のイベントの調査をさらに進めたところ、 個別のケースのいくつかで、複数のアベイラビリティゾーンで稼働していたお客様のアプリケーションにも、予期せぬ影響(例えば、 Application Load Balancer を AWS Web Application Firewall やスティッキーセッションと組み合わせてご利用しているお客様の一部で、想定されるより高い割合でリクエストが Internal Server Error を返す)があったことを AWS では確認しております。AWS では、個別の問題についての詳細な情報を、影響を受けたお客様に直接、共有を行う予定です。

aws.amazon.com

以下,本事象のサマリーです.

原因

東京リージョンの単一の Availability Zone(データセンター群) の一部(apne1-az4)でオーバーヒートが発生したが,空調設備の管理システムの障害により冷却装置が作動しなかったことが原因のようです.

影響

影響として次の部分に出ていました.

  • 該当 Availability Zone(apne1-az4)の EC2 インスタンス及び EBS ボリュームのパフォーマンスの劣化, RDS の使用不可やマルチ Availability Zone でのフェイルオーバーに伴う一時的な通信断が発生
    • EC2 RunInstances APIのエラー率の上昇が発生し,その他の EC2 API や Auto Scaling グループからのインスタンスの新規起動も阻害
  • EC2 の障害が発生した Availability Zone の RDS, Redshift, ElastiCache, WorkSpaces, 予期せぬ影響だがALB への影響

参考

piyolog.hatenadiary.jp

僕の会社でも本障害を受けて報告資料を公表しています.

今回,たまたま遭遇したのですがマネジメントコンソールの画面の表示が崩れたり表示ができない時間帯があり,状況確認が難かったです.その時に AWS CLI を使ってステータスの状況を確認していました.当時を振り返って,他にも利用できるコマンドもあると思い調べたのでブログにまとめていきます.

Availability Zone のステータス確認

今回の障害の原因となった Availabity Zone のステータスを確認するコマンドは describe-availabity-zonesです.障害が発生した「apne1-az4」はコマンド実行結果のZoneIdからステータスを確認可能です.

docs.aws.amazon.com

コマンド実行例

$ aws ec2 describe-availability-zones --output table                                     
-------------------------------------------------------------------
|                    DescribeAvailabilityZones                    |
+-----------------------------------------------------------------+
||                       AvailabilityZones                       ||
|+-----------------+------------+------------+-------------------+|
||   RegionName    |   State    |  ZoneId    |     ZoneName      ||
|+-----------------+------------+------------+-------------------+|
||  ap-northeast-1 |  available |  apne1-az4 |  ap-northeast-1a  ||
|+-----------------+------------+------------+-------------------+|
||                       AvailabilityZones                       ||
|+-----------------+------------+------------+-------------------+|
||   RegionName    |   State    |  ZoneId    |     ZoneName      ||
|+-----------------+------------+------------+-------------------+|
||  ap-northeast-1 |  available |  apne1-az1 |  ap-northeast-1c  ||
|+-----------------+------------+------------+-------------------+|
||                       AvailabilityZones                       ||
|+-----------------+------------+------------+-------------------+|
||   RegionName    |   State    |  ZoneId    |     ZoneName      ||
|+-----------------+------------+------------+-------------------+|
||  ap-northeast-1 |  available |  apne1-az2 |  ap-northeast-1d  ||
|+-----------------+------------+------------+-------------------+|

EC2 インスタンスのステータス確認

EC2 インスタンスのステータス確認を行うコマンドはdescribe-instance-statusになります.--filters オプションで Availability Zone や インスタンスのステータスをを指定して状況を確認することが可能です.

docs.aws.amazon.com

コマンド例

$ aws ec2 describe-instance-status --filters Name=availability-zone,Values=ap-northeast-1a Name=instance-status.status,Values=impaired --output table
-------------------------------------------------------------------------
|                        DescribeInstanceStatus                         |
+-----------------------------------------------------------------------+
||                          InstanceStatuses                           ||
|+-------------------------------+-------------------------------------+|
||  AvailabilityZone             |  ap-northeast-1a                    ||
||  InstanceId                   |  i-xxxx                ||
|+-------------------------------+-------------------------------------+|
|||                              Events                               |||
||+------------------+------------------------------------------------+||
|||  Code            |  instance-stop                                 |||
|||  Description     |  The instance is running on degraded hardware  |||
|||  InstanceEventId |  instance-event-xxxxxxx              |||
|||  NotBefore       |  2019-xx-xxTxx:xx:xx.xxxZ                   |||
||+------------------+------------------------------------------------+||
|||                           InstanceState                           |||
||+---------------------------+---------------------------------------+||
|||  Code                     |  xx                                  |||
|||  Name                     |  running                              |||
||+---------------------------+---------------------------------------+||
|||                          InstanceStatus                           |||
||+-----------------------------+-------------------------------------+||
|||  Status                     |  impaired                           |||
||+-----------------------------+-------------------------------------+||
||||                             Details                             ||||
|||+-----------------------+-----------------------------------------+|||
||||  ImpairedSince        |  2019-xx-xxTxx:xx:xx.xxxZ                 ||||
||||  Name                 |  reachability                           ||||
||||  Status               |  failed                                 ||||
|||+-----------------------+-----------------------------------------+|||
|||                           SystemStatus                            |||
||+-----------------------------+-------------------------------------+||
|||  Status                     |  impaired                           |||
||+-----------------------------+-------------------------------------+||
||||                             Details                             ||||
|||+-----------------------+-----------------------------------------+|||
||||  ImpairedSince        |  2019-xx-xxTxx:xx:xx.xxxZ               ||||
||||  Name                 |  reachability                           ||||
||||  Status               |  failed                                 ||||
|||+-----------------------+-----------------------------------------+|||

EBS ボリュームのステータス確認

EBS ボリュームでも障害が発生していましたので, EBS ボリュームのステータス確認を行うコマンドとしてdescribe-volumesがあります.--filters オプションで Availability Zone を絞れるので問題発生した Availability Zone を指定して状況を確認することが可能です.

docs.aws.amazon.com

コマンド例

$ aws ec2 describe-volumes --filters Name=availability-zone,Values=ap-northeast-1a --output table
---------------------------------------------------------
---------------------------------------------------------
|                    DescribeVolumes                    |
+-------------------------------------------------------+
||                       Volumes                       ||
|+---------------------+-------------------------------+|
||  AvailabilityZone   |  ap-northeast-1a              ||
||  CreateTime         |  2019-xx-xxTxx:xx:xx.xxxZ     ||
||  Encrypted          |  False                        ||
||  Iops               |  100                          ||
||  Size               |  8                            ||
||  SnapshotId         |  snap-xxxx       ||
||  State              |  in-use                       ||
||  VolumeId           |  vol-xxxx        ||
||  VolumeType         |  gp2                          ||
|+---------------------+-------------------------------+|
|||                    Attachments                    |||
||+----------------------+----------------------------+||
|||  AttachTime          |  2019-xx-xxTxx:xx:xx.xxxZ  |||
|||  DeleteOnTermination |  True                      |||
|||  Device              |  /dev/xvda                 |||
|||  InstanceId          |  i-xxxx       |||
|||  State               |  attached                  |||
|||  VolumeId            |  vol-xxxx     |||
||+----------------------+----------------------------+||

RDS インスタンスのステータス確認

RDS インスタンスの使用不可な状態やフェイルオーバーによる一時的な通信断があったため,RDS インスタンスへの接続確認も必要ですが,AWS CLI でステータス確認を行うコマンドとしてdescribe-db-instancesがあります.--queryオプションを使って Availability Zone やステータスを絞って確認可能です.

docs.aws.amazon.com

コマンド例

$ aws rds describe-db-instances --query 'DBInstances[?AvailabilityZone==`ap-northeast-1a`].{Name:DBInstanceIdentifier,Status:DBInstanceStatus}' --output table
---------------------------------------------------------
|                  DescribeDBInstances                  |
+------------------------------------------+------------+
|                   Name                   |  Status    |
+------------------------------------------+------------+
|  xxxx                         |  available |
|  xxxx                         |  available |
|  xxxx                      |  available |
|  xxxx                     |  available |
|  xxxx                     |  available |

まとめ

先日発生した AWS のネットワーク障害で障害点であった Availability Zone, EC2, EBS, RDS のステータスを確認するためのコマンドとコマンド例をまとめました.正解はないと思いますし,もっといい手法があれば教えてください! 今回の障害を機にどこが弱点か,改善するところがないかを再考し,より良いシステムの形に持っていけるようにしていきたいですね.

Effective DevOpsオンライン輪読会第12回開催レポート

タダです.

challenge-every-month の Slack メンバーで 「Effective DevOps」のオンライン輪読会を毎週開催中です.

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps ―4本柱による持続可能な組織文化の育て方

開催概要

方針や輪読会の概要は @kojirock さんがまとめてくださっているので参照ください.

kojirooooocks.hatenablog.com

過去の開催レポート

これまでの開催レポートは以下の通りです.

sadayoshi-tada.hatenablog.com

kojirooooocks.hatenablog.com

kdnakt.hatenablog.com

kdnakt.hatenablog.com

sadayoshi-tada.hatenablog.com

kojirooooocks.hatenablog.com

kdnakt.hatenablog.com

kdnakt.hatenablog.com

sadayoshi-tada.hatenablog.com

kojirooooocks.hatenablog.com

担当章について

今回の範囲は14章の途中の 14.8~14.14 までになります.14章は4つの柱の最後の柱である「スケーリング」の話になります.

資料

資料はこちらです.

所感

  • チーム,組織のスケーリングのためにはエンジニアに長く定着して就業してもらう必要があり,組織は変革し続ける必要ある
    • チームのスケーリングしていくためにはチームを小さく柔軟に,コラボレーションを促進,摩擦や対立をうまく捌く必要もある
      • チーム内部の対立で大事なのはメンバーとの1対1の対話で,チーム外部との対立は組織とチームとのモチベーションの差異をなくすのが大事だと感じた
    • 組織の変革のためには内部だけでなく外部からコーチングできる人を招聘したり,外部にコードを公開していくことで現場での学習も促進する
  • gov.ukは公的な情報サイトで, UX やユーザーのニーズを満たすことを第一にしている
    • また,アフィニティ構築で情報共有のために定期的にブログや OSS コミュニティにコミットしているのは日本の公的機関では聞いたことなかったので感動した

まとめ

第12回目の輪読会で扱った資料と所感を書きました. 読了まであともう少し!

次回

次回は @kdnkt さんの担当です.次回は15,16章になります.

次の輪読本候補

次の輪読本を探している時にカックさんにオススメしてもらった本が気になっています.

pragprog.com

GuardDuty のマルチアカウント管理機能有効化を省力化する

タダです.

先日, GuardDuty のマルチアカウント管理機能を紹介した記事を書きました.マルチアカウントで GuardDuty を運用するなら有効化すべき機能ですが,多数のアカウントを AWS マネジメントコンソールの操作で有効化するのは煩雑なため, CloudFormation と AWS CLI を使って省力化してみます. sadayoshi-tada.hatenablog.com

省力化できる箇所

今回,省力化できる箇所は以下のものと考えました.

  1. メンバーアカウントに対してマスターアカウントからアカウント管理機能の招待を送る処理
  2. メンバーアカウントでマスターアカウントからの招待を受ける処理
  3. GuardDuty の DetectorID を取得する処理

それぞれの処理ごとで省力化した箇所とコード例を記載していきます.

1. メンバーアカウントに対してマスターアカウントからアカウント管理機能の招待を送る処理

マスターアカウントがメンバーアカウントのイベントを管理するためには, メンバーアカウントにマスターアカウントに統合するための招待を送る必要があります.なお, AWS では利用可能なリージョン全てで GuardDuty を有効化することが推奨されておりますので本記事では,マスターアカウントの全リージョンからメンバーアカウントに招待通知を出す処理を CloudFormation で省力化するコードを紹介します.

GuardDuty は、サポートされているすべての AWS リージョンで有効にすることが強く推奨されています。このように設定することで、お客様が能動的に使用していないリージョンでも、許可されていないアクティビティや異常なアクティビティに関する検索結果を GuardDuty で生成できます。

docs.aws.amazon.com

CloudFormation テンプレート例

CloudFormation の StackSets 機能を使ってマスターアカウントの全リージョンに対して下記のテンプレートを実行することで指定のメンバーアカウントに対して招待通知を出せます.AWS::GuardDuty::MemberStatus: "Invited"で設定するとメンバーアカウントに招待通知を出す処理まで一気に設定可能ですので,この設定は定義しておくと良いでしょう.

AWSTemplateFormatVersion: 2010-09-09
Description: Send Invitation to GuardDuty Member Account.

Mappings:
  GuardDutyMember:
    us-east-1: 
      DetectorId: xxxx
    us-east-2:
      DetectorId: xxxx
    us-west-1:
      DetectorId: xxxx
    us-west-2:
      DetectorId: xxxx
    ca-central-1:
      DetectorId: xxxx
    eu-central-1:
      DetectorId: xxxx
    eu-west-1:
      DetectorId: xxxx
    eu-west-2:
      DetectorId: xxxx
    eu-west-3:
      DetectorId: xxxx
    ap-northeast-1:
      DetectorId: xxxx
    ap-northeast-2:
      DetectorId: xxxx
    ap-southeast-1: 
      DetectorId: xxxx
    ap-southeast-2: 
      DetectorId: xxxx
    ap-south-1:
      DetectorId: xxxx
    sa-east-1:
      DetectorId: xxxx

Prameter:
  MemberAccountId:
    Description: Type Member Account Number.
    Type: String
  MemberAccountEmail:
    Description: Type Member Account Email.
    Type: String  


Resources:
  Member:
    Type: AWS::GuardDuty::Member
    Properties: 
      Status: "Invited"    
      MemberId: !Ref MemberAccountId
      Email: !Ref MemberAccountEmail
      DetectorId: !FindInMap [GuardDutyMember,!Ref "AWS::Region", DetectorId]
      DisableEmailNotification: True

なお,CloudFormation の StackSets 機能が使えないリージョンでは手動でメンバーアカウントの招待を行う必要があります.多数のアカウントに対して招待を出す場合,CSVファイルに次のようにメンバーアカウントの AWS アカウント番号とメールアドレスを記載したものを読み込ませるとスムーズです。

Account ID,Email
111111111111,user@example.com

CloudFormation ドキュメント

docs.aws.amazon.com

2. メンバーアカウントでマスターアカウントからの招待を受ける処理

マスターアカウントからメンバーアカウントへアカウント統合の招待を出した後は,メンバーアカウントでその招待を承認しなければなりません.その承認処理を CloudFormation で省力化します.マスターアカウントからの招待通知同様に全リージョンで承認処理を行うためのテンプレート例を紹介します.

CloudFormation テンプレート例

このテンプレートもメンバーアカウントで StackSets 機能を使って全リージョンの招待通知を一度に承認する処理を省力化しています.

AWSTemplateFormatVersion: 2010-09-09
Description: Approve Invitation From GuardDuty Master Account.

Mappings:
  GuardDutyMaster:
    us-east-1: 
      DetectorId: xxxx
    us-east-2:
      DetectorId: xxxx
    us-west-1:
      DetectorId: xxxx
    us-west-2:
      DetectorId: xxxx
    ca-central-1:
      DetectorId: xxxx
    eu-central-1:
      DetectorId: xxxx
    eu-west-1:
      DetectorId: xxxx
    eu-west-2:
      DetectorId: xxxx
    eu-west-3:
      DetectorId: xxxx
    ap-northeast-1:
      DetectorId: xxxx
    ap-northeast-2:
      DetectorId: xxxx
    ap-southeast-1: 
      DetectorId: xxxx
    ap-southeast-2: 
      DetectorId: xxxx
    ap-south-1:
      DetectorId: xxxx
    sa-east-1:
      DetectorId: xxxx

Parameters:
  MasterAccountNumber:
    Type: String

Resources:
  Master:
    Type: AWS::GuardDuty::Master
    Properties:
      DetectorId: !FindInMap [GuardDutyMaster,!Ref "AWS::Region", DetectorId]
      MasterId: !Ref MasterAccountNumber

CloudFormation ドキュメント

docs.aws.amazon.com

3. GuardDuty の DetectorID を取得する処理

最後に, 1,2 のCloudFormation テンプレートの定義で必ず必要な GuardDuty の DetectorID 取得を AWS CLI で全リージョン分取得する処理を紹介します.マスターアカウントでもメンバーアカウントでも必ず必要なため同様の処理を検討している方の参考になれば嬉しいです.

AWS CLI コード例

以下の2行で取得可能です.最初にリージョンのエンドポイントをソートして取得し,次に GuardDuty の DetectorID をリージョンごとに取得している感じです.

# リージョン全取得して配列に格納(-r をつけるとダブルクオーテーションを削除可能)
declare -a REGIONS=( $(aws ec2 describe-regions | jq -r '.Regions[] | .RegionName' | sort) )

# GuardDutyのDetectorIDをリージョンごとに表示する
for i in ${REGIONS[@]}; do echo "$i = $( aws guardduty list-detectors --region $i | jq -r '.DetectorIds[]')";done

AWS CLI ドキュメント

docs.aws.amazon.com

docs.aws.amazon.com

シェルスクリプト化してこんな感じに一気に取得するなどできます.

f:id:sadayoshi_tada:20190817160352p:plain

まとめ

僕が GuardDuty のマルチアカウント管理機能有効化を省力化するために行った CloudFormation と AWS CLI の意図とコードを紹介しました.他にもいろんな方法があるかと思いますが,僕は次は AWS CDK でも同様のことを実現できないかをトライしてみたいと思います.

AWS CLI のコマンド実行を補助する「aws-shell」の紹介

タダです.

AWS CLI 使っていて予測変換機能やパラメータをドキュメントを都度確認せずとも実行できたら楽だなと思っていたのですが, AWS Labsを漁っていたところ「aws-shell」というツールを見つけましたので今回の記事ではこのツールについて紹介します.なお,このツールは現時点で開発者プレビューのツールとなりますのでその点は注意ください.

The aws-shell is currently in developer preview. We welcome feedback, feature requests, and bug reports. There may be backwards incompatible changes made in order to respond to customer feedback as we continue to iterate on the aws-shell.

aws-shell の概要

aws-shell」は,AWS CLI のコマンド入力をインタラクティブに支援してくれるツールです.

github.com

普段僕は,コマンドを入力するときはドキュメントを確認しつつ入力しています.ただこのツールは画像のように「どんなコマンドがあるか」「どんなパラメータがあるか」をターミナルに表示しながらナビゲート(インタラクティブ)してくれるところが特徴的です.

f:id:sadayoshi_tada:20190809180939p:plain

また,過去の実行したコマンドをナビしてくれたり,パラメータを提案してくれたりもします.便利な機能ですよね.

f:id:sadayoshi_tada:20190809185435p:plain

f:id:sadayoshi_tada:20190809185600p:plain

ツールの導入方法

導入方法は簡単でpip install aws-shellのみで導入できてしまいます.なお,実行環境の Python には以下の制約があるため注意が必要です.また,当然 AWS CLIは導入しておくのはお忘れなく.

The aws-shell works on the same python versions supported by the AWS CLI:

2.6.5 and greater

2.7.x and greater

3.3.x and greater

3.4.x and greater

AWS CLI の導入のドキュメント

docs.aws.amazon.com

ツール導入後はaws-shellと打てば起動完了です.

$ aws-shell
aws>

aws-shell 利用方法

aws-shell」を導入したら実際に使ってみましょう.AWS CLI との違いはawsコマンドを入力が不要という点です.例えば,S3 関連コマンドを実行したい場合はいきなりs3 lsといった形で実行可能です.あとはツールが補完してくれるコマンドやオプションに沿ってコマンドを入力すればよいのですが,その他のツールの利用方法を以下でまとめます.

profile の切り替え

AWS CLIではコマンド実行時にアカウントや権限を分けたい場合は--profile オプションをつけて実行しますが「aws-shell」では以下のコマンドを使うことで切り替え可能です.

※profile の切り替えは2パターンある
【パターン1】
$ aws-shell --profile <profile名>

【パターン2】
aws> .profile <profile名>

※現状の profile の確認コマンド
aws> .profile
Current shell profile: admin

Liunx コマンドの利用

Linux コマンドを一緒に使いたい場合や Linux コマンド単体で実行したい場合があると思います.基本的には!catのように「!」をコマンドの前につけます.一部のコマンドは.cd(ディレクトリ移動コマンド),.exit/.quit(「aws-shell」終了のコマンド),.edit(エディタ起動コマンド)は定義されたコマンドもあります.なお,パイプやリダイレクト時は「!」は不要のようです.

aws> !ls /tmp/
foo.txt                                    bar.txt
aws> dynamodb list-tables --output text | head -n 1
TABLENAMES     First
aws> dynamodb list-tables --output text > /tmp/foo.txt

コマンド履歴の確認

過去に実行したコマンドを確認したい場合は,~/.aws/shell/historyファイルに格納されています.

aws> !cat ~/.aws/shell/history
# 2019-08-09 17:58:50.770101
+ec2 describe-regions

# 2019-08-09 17:59:00.594925
+s3 ls

aws-shell を終了する

aws-shell」を終了したい場合は.exitまたはF10,CTRL-Dを実行します.

aws> .exit
$

その他のツールオプション

aws-shell」にはツールオプションが用意されていて,現状以下の利用が可能です.

F2 toggles between fuzzy and substring matching

F3 toggles between VI and Emacs key bindings

F4 toggles between single and multi column auto completions

F5 shows and hides the help documentation pane

F9 toggles focus between the cli and documentation pane

F10 or Ctrl-D exits the aws-shell

まとめ

AWS CLI 補助ツールの「aws-shell」の概要,導入方法とツールの利用例を紹介しました.AWS CLI を使うときにドキュメントを都度確認したりすることに煩雑さを感じる方は本ツールを使ってみてはいかがでしょうか? 僕も普段使いでも使っていって改善点などあればフィードバックを行なってよりよくしていくようリクエスト出していきたいと思います!

関連記事

AWS CLI ツールを紹介した他記事もよければ! sadayoshi-tada.hatenablog.com

ALB の監視の統計情報を AWS CLI で取得する

タダです.

ELB を使ったシステムで日々の運用状況の確認や障害が発生した時のトラブルシュートに CloudWatch の監視情報やログを使うことがよくあると思います. GUI から確認をしてもいいのですが,例えば時系列ごとのレポーティングに使う際に AWS CLI(以下,CLI)を使って情報収集した方がよいと感じたので,ALB の監視情報収集の方法と実際に使った監視情報の収集利用例を紹介します.

GUI で監視情報を見る場合

マネジメントコンソールの画面で見る場合,メトリクスを選択してグラフを描画することができますが,各メトリクス値は5分間隔などで点線となっているため,「特定日における1時間毎の ELB で発生した5XX系のエラー数を集計したい」といった要望を実現しようとするときは少々手間がかかります. f:id:sadayoshi_tada:20190804153016p:plain

CLI で監視統計情報を見る場合

それでは, CLI の実行方法を見ていきましょう.

docs.aws.amazon.com

まずは,list-metricsコマンドで ALB のリソース情報を取得します. ALB が大量にある場合は,grep で範囲を絞った方が得策です.コマンド実行結果の Value の値が次の統計情報を取得するget-metric-statisticsコマンドで必要になります(例: "Value": "app/xxxx/xxxxxxxxx" 等).

docs.aws.amazon.com

# ALB のリソース情報の取得
aws cloudwatch list-metrics --namespace AWS/ApplicationELB

# コマンド実行結果
~中略~
        {
            "Namespace": "AWS/ApplicationELB",
            "MetricName": "RequestCount",
            "Dimensions": [
                {
                    "Name": "TargetGroup",
                    "Value": "targetgroup/xxxx/xxxxxxxxx"
                },
                {
                    "Name": "LoadBalancer",
                    "Value": "app/xxxx/xxxxxxxxx"
                },
                {
                    "Name": "AvailabilityZone",
                    "Value": "ap-northeast-1a"
                }
            ]
        }
~中略~

次に,get-metric-statisticsコマンドで統計情報を取得します.--dimesionsパラメータにて監視情報を取得するリソース情報を指定する必要があります(Name=LoadBalancer,Value=app/xxxx/xxxxxxxxxの部分).ここでlist-metricsの実行結果の情報が活きてきます.

下記のコマンド例は,8/3の0時から8/4の23:59にかけての1時間毎のUnHealthyHostCountの平均数を出すためのコマンドです.この様に監視の統計情報を取得することが可能です.

aws cloudwatch get-metric-statistics --namespace AWS/ApplicationELB \
--metric-name UnHealthyHostCount --statistics Average  --period 3600 \
--dimensions Name=LoadBalancer,Value=app/xxxx/xxxxxxxxx \
--start-time 2019-08-03T15:00:00Z --end-time 2019-08-04T14:59:59Z

ケース別コマンド実行パターン

上記のコマンドを踏まえ,今回使った ALB の監視情報の収集利用例を紹介します.なお,コマンドのパラメーターは下記のクラスメソッドさんのブログを参考にさせてもらいました.

dev.classmethod.jp

Case1. 特定日におけるリクエストの総数を1時間毎に収集する

例えば,リリースしたてのサービスでキャンペーンやスパイクアクセスが来る時間帯を把握したい時ありますよね? Case1 はその様な用途に使ったコマンド例です.

aws cloudwatch get-metric-statistics --namespace AWS/ApplicationELB \
--metric-name RequestCount --statistics Sum --period 3600 \
--dimensions Name=LoadBalancer,Value=app/xxxx/xxxxxxxx \
--start-time 2019-08-03T15:00:00Z --end-time 2019-08-04T14:59:59Z \
--query "sort_by(Datapoints,&Timestamp)[?Sum>\`0\`][Sum,Timestamp]" --output text

# コマンド実行結果例
100.0 2019-08-03T15:00:00Z
200.0 2019-08-03T16:00:00Z
300.0 2019-08-03T17:00:00Z
~中略~

Case2. 特定日における 5XX系のエラー総数を1時間毎に収集する

そして,エラーの発生時間帯を特定した時のコマンドとして Case2 の様なコマンド例があります.Case1 の--metric-nameHTTPCode_ELB_5XX_Countに変更するだけですね.

aws cloudwatch get-metric-statistics --namespace AWS/ApplicationELB \
--metric-name HTTPCode_ELB_5XX_Count --statistics Sum --period 3600 \
--dimensions Name=LoadBalancer,Value=app/xxxx/xxxxxxxx \
--start-time 2019-08-03T15:00:00Z --end-time 2019-08-04T14:59:59Z \
--query "sort_by(Datapoints,&Timestamp)[?Sum>\`0\`][Sum,Timestamp]" --output text

# コマンド実行結果例
5.0   2019-08-03T15:00:00Z
1000.0    2019-08-04T02:00:00Z
1.0   2019-08-04T09:00:00Z
~中略~

まとめ

CLI を使った ALB の監視統計情報の取得方法と,ケース別の取得例を紹介しました.運用中のシステムになると CloudWatch での状況確認は頻繁になります.GUI でもよいですが,トラブルシュートのレポーティングや日々の運用状況を報告する際には視覚情報と一緒に数値を提供すると信用や説得力が増します.そんな業務に当たった時にはぜひ CLI を使ってみてもらえると良いかと思います.