CloudWatchでデモサイトを監視してみた

ホーム
AWS/Azure
CloudWatchでデモサイトを監視してみた

AWS/Azure

2021.12.20

この記事は投稿日から2年以上経過しています。

当記事は、2021年11月5日にリリースされたばかりのLogStare Collecetorv2.1.3にて新しく追加された機能である「CloudWatch監視」で弊社のログ分析基盤デモ環境を監視してみた時の記録です。

初めまして。Outisと申します。まず、自社製品とAWS、CloudWatchについて簡単に説明します。

自社製品「LogStare Collector」について

LogStare Collectorは弊社が開発したNW監視・ログ収集ソフトウェアです。このソフトウェアは主にオンプレミス環境の監視やログ収集を実施するための主要なプロトコルに対応しています。

もちろん、クラウドであっても、プロトコルに対応していれば監視・ログ収集を実施出来ます。

しかしながら、クラウド、特にAWSサービスの監視を考えた時、従来利用されてきたプロトコル(主にSNMP)では監視できないサービスがあります。

それはSNMP監視がどのように実施されているかを踏まえるとよく分かるかと思います。

SNMPとAWSについてざっくりと

SNMPは、監視対象側でSNMPエージェントをインストール・有効化してSNMPマネージャからの取得要求に対してエージェントから応答を返すことで監視を実現しています。

サーバやNW機器ではSNMP設定を有効化すればエージェントも有効化されることになります。これによって、SNMPマネージャからの取得要求に対して応答出来ます。

AWSの場合、EC2であればエージェントのインストール・有効化は可能ですが、RDSやLambdaといったサービスではエージェントのインストールも何もありません。

つまり、SNMPを利用出来ません。それではSNMPで監視できないAWSサービスをどのように監視するのでしょうか。

CloudWatchとは

餅は餅屋という事でAWSには専用の監視サービスが用意されています。それがCloudWatchです。詳細は公式を確認するのが一番です。

Amazon CloudWatch とは

実際にやってみた

AWSサービスの監視にはCloudWatchを利用するに限ります。

そこでLogStare Collectorではaws cliを利用してCloudWatchが収集した各種データを取り込む事でCloudWatch監視を実現しました。

機能のご紹介並びに利用方法含め、弊社のログ分析基盤LogStare Quintのデモ環境がEC2上で構築されているので、それを監視するまでの一連の記録を下記にまとめました。

監視準備①～CloudWatchから必要な情報を取得するための権限を用意する～

今回はオンプレミス環境にあるLogStare CollectorでCloudWatch監視を行います。

まず、CloudWatchから各種データを取得するための権限だけを有したユーザをIAMにて作成します。

なお、オンプレミス環境のLogStare CollectorでCloudWatch監視を実施する場合、AWS非推奨のアクセスキー/シークレットキー方式でアクセスする権限を付与する必要があります。

EC2インスタンス上に構築したLogStare Collectorであれば、必要な権限を備えたIAMロールを割り当てることで対応出来ますので、実際にはEC2インスタンス上から監視することを推奨します。

LogStare CollectorのAMIもありますのでそちらも是非ご利用いただければと思います。

IAMにてCloudWatch監視用のポリシーを作成します。本記事ではポリシー名として「lsc-CloudWatch」と設定しました。

IAMにてCloudWatch監視用のポリシーを作成

サービス「CloudWatch」からアクセスレベル>リストの「ListMetrics」、アクセスレベル>読み取りの「GetMetricStatistics」の2つを選択して次に進みます。

リストの「ListMetrics」、アクセスレベル>読み取りの「GetMetricStatistics」の2つを選択

ポリシーのタグを設定して次に進みます。

ポリシーのタグを設定

ポリシーの名前と説明を入力してポリシーを作成します。

ポリシーの名前と説明を入力

IAMにてCloudWatch監視用のユーザを作成します。本記事ではユーザ名として「lsc-CloudWatch」と設定しています。

IAMにてCloudWatch監視用のユーザを作成

ユーザ名を設定して、AWS 認証情報タイプの選択より「アクセスキー - プログラムによるアクセス」を選択して次に進みます。

「アクセスキー - プログラムによるアクセス」を選択

アクセス許可の設定より「既存のポリシーを直接アタッチ」を選択し先程作成したポリシーを設定して次に進みます。

「既存のポリシーを直接アタッチ」を選択

ユーザのタグを設定して次に進みます。

ユーザのタグを設定して次に

内容を確認して問題なければ「ユーザの作成」を押下します。

「ユーザの作成」を押下

作成されたアクセスキー・シークレットキーをダウンロードします。

作成されたアクセスキー・シークレットキーをダウンロード

監視準備②～aws cliをインストールする～

次に、LogStare Collectorサーバにaws cliをインストールします。インストール方法は別途手順を作成しているので下記を参照してください。

【Linux系OSにaws cliバージョン2をインストールする方法について】
【AmazonLinux2において、aws cliのバージョンを1から2へ変更する方法について】
【WindowsServerにaws cliバージョン2をインストールする方法について】

監視準備③～アクセスキー・シークレットキーの登録～

次に、aws configureを利用してLogStare Collectorサーバでのaws cliセットアップを進めます。

aws configureを実行します。アクセスキーとシークレットキー、標準リージョン、標準出力を設定します。

[root@xyz ~]# aws configure
AWS Access Key ID [None]:
AWS Secret Access Key [None]:
Default region name [None]:
Default output format [None]:

アクセスキー：先程取得した情報を設定します。
シークレットキー：先程取得した情報を設定します。
標準リージョン：監視対象のAWSサービスを利用しているリージョンを設定します。複数ある場合でも一旦は利用頻度の高いリージョンを設定してください。
標準出力：jsonを設定します。

※くどいかと思われますが、オンプレ版では上記方法で権限を付与していますが、あくまでAWS公式では非推奨となっています。実際に当機能を利用される場合、EC2にLogStare Collectorを構築し、IAMロールを付与する方法を採用していただければと思います。

監視準備④～準備完了と思ったら…～

ここまででCloudWatch監視の準備は完了です。

実際にLogStare Collectorで設定して監視を始めますと行きたかったのですが、想定外の事象が発生してしまいました…。

LogStare Collectorはaws cliのコマンドを実行してリソースを取得しているのですが、その際にsudoを併用しています。

そのためsudoersのsecure_pathにawsのパスを追記する必要があります。

which awsにてパスを確認する

[root@xyz ~]# which aws
/usr/local/bin/aws

visudoにてsecure_pathに先程確認したパスを追記する

【変更前】

[root@xyz ~]# visudo
～省略～
# Defaults env_keep += "HOME"
Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin
#Defaults env_keep +="PATH

【変更後】

[root@xyz ~]# visudo
～省略～
# Defaults env_keep += "HOME"
Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin/　　＃追記箇所
#Defaults env_keep +="PATH