sorta kinda...

主にAWS関連ですが、これに限らずいろいろ勉強したことや思ったことを書いていきます。

Windows Server のパフォーマンスモニターの情報を CloudWatch に投げる [cloudpack OSAKA blog]

ナスです。

CloudWatch 便利ですね。勝手に CPU とかの情報を取ってきて閾値超えたらアラート上げてくれるので、ちょっとした監視ならこれで十分です。ただ、そんな便利な CloudWatch も万能ではありません。メモリの情報もデフォルトでは取れないので、ちょっと設定してあげる必要があります。

今回は CloudWatch にメモリ情報を投げる手順をご紹介します。メモリに限らず、パフォーマンスモニターで見れる情報ならなんでも CloudWatch に投げられるので、それなりに参考になると思います。

ただ、そのまんまやったらつまづくことがあるので、ハマったポイントを重点的に書いていきます。

 

ドキュメントはこれ

全体的な設定の流れはこのドキュメントの通りです。 docs.aws.amazon.com

 

選んだ方法

Systems Manager Run Command を使いました。選んだ理由は↓です。

  • OS にログインしなくてもいい(設定は全部 AWS コンソールからできる)
  • 複数のインスタンスに対して同時にできる
  • 「CloudWatch のインスタンスを設定する」ページの一番上に書いてあったから(推奨なのかな?と勝手に思った)

 

ハマったポイント 1

IAM ロールを対象の EC2 インスタンスにつけるのですが、どんなポリシーにすればいいのかわかりづらかったです。結局 AmazonEC2RoleforSSM だけアタッチした IAM ロールを EC2 インスタンスにつけただけでよかったです。

 

ハマったポイント 2

AWS.EC2.Windows.CloudWatch.json をダウンロードして編集します。が、このドキュメントの通りにやっただけではうまくいきません。なぜかというと、対象の Windows Server インスタンスで取れない情報を取ろうとするからです。カスタムログとか。

なので、今回は CloudWatch に投げない項目の設定は全部削除しました。必要最低限の設定だけにした JSON が↓です。使用可能メモリ量とページング使用率だけ取る例です。今回は最小限にしましたが、このファイルにはデフォルトでイベントログや任意のログファイルのメッセージを CloudWatch Logs に投げる定義も書かれているので、対象のファイルのパス等を正しく定義してやればメッセージも投げられますよ。

{
    "IsEnabled": true,
    "EngineConfiguration": {
        "PollInterval": "00:00:15",
        "Components": [
            {
                "Id": "PerformanceCounterMemory",
                "FullName": "AWS.EC2.Windows.CloudWatch.PerformanceCounterComponent.PerformanceCounterInputComponent,AWS.EC2.Windows.CloudWatch",
                "Parameters": {
                    "CategoryName": "Memory",
                    "CounterName": "Available MBytes",
                    "InstanceName": "",
                    "MetricName": "Memory",
                    "Unit": "Megabytes",
                    "DimensionName": "InstanceId",
                    "DimensionValue": "{instance_id}"
                }
            },
            {
                "Id": "PerformanceCounterPaging",
                "FullName": "AWS.EC2.Windows.CloudWatch.PerformanceCounterComponent.PerformanceCounterInputComponent,AWS.EC2.Windows.CloudWatch",
                "Parameters": {
                    "CategoryName": "Paging File",
                    "CounterName": "% Usage",
                    "InstanceName": "_Total",
                    "MetricName": "Paging",
                    "Unit": "Megabytes",
                    "DimensionName": "InstanceId",
                    "DimensionValue": "{instance_id}"
                }
            },
            {
                "Id": "CloudWatchLogs",
                "FullName": "AWS.EC2.Windows.CloudWatch.CloudWatchLogsOutput,AWS.EC2.Windows.CloudWatch",
                "Parameters": {
                    "AccessKey": "",
                    "SecretKey": "",
                    "Region": "us-east-1",
                    "LogGroup": "Default-Log-Group",
                    "LogStream": "{instance_id}"
                }
            },
            {
                "Id": "CloudWatch",
                "FullName": "AWS.EC2.Windows.CloudWatch.CloudWatch.CloudWatchOutputComponent,AWS.EC2.Windows.CloudWatch",
                "Parameters":
                {
                    "AccessKey": "",
                    "SecretKey": "",
                    "Region": "ap-northeast-1",
                    "NameSpace": "nasu/test"
                }
            }
        ],
        "Flows": {
            "Flows":
            [
                "(PerformanceCounterMemory,PerformanceCounterPaging),CloudWatch"
            ]
        }
    }
}

 

結果

NameSpace で指定した名前空間が、CloudWatch メトリクスに出てきます。 f:id:nasrinjp1:20170606184223p:plain

中身を見てみると、ちゃんと JSON で定義した項目だけが出てきています。メモリ情報なので、グラフ自体は全く面白くないですね。 f:id:nasrinjp1:20170606184347p:plain

 

いろんな監視システムやサービスがありますが、自前でわざわざ準備&管理するのが面倒なら、こんな感じで CloudWatch を使ってみてはいかがでしょうか。

サブネットグループはグループです! [cloudpack OSAKA blog]

ナスです。

タイトルの通りなんですが、なぜ今まで気がつかなかったのか謎です…

 

RDS と DMS の初期設定で気がつきました

ドキュメントもよく読まずに、Single-AZ で RDS を構築して DMS で DB データ移行しようとしてました。サブネットグループを作ろうとして、AWS コンソールから 1 つのサブネットだけを選んで作成しようとするとこんなエラーがでました。
f:id:nasrinjp1:20170605231605p:plain

さらに DMS インスタンスを立てようとしてサブネットグループを作ろうとしてこうなりました。 f:id:nasrinjp1:20170605230836p:plain

 

やっぱりガイドには書いてありました

docs.aws.amazon.com

docs.aws.amazon.com

 

Single-AZ で RDS や DMS を使う場合でも、サブネットは 2 つ以上作る必要があるので、気をつけてください!
最初のヒアリングの時に聞けなかったらまたサブネットの調整が必要になるので、自分も相手も二度手間になりますよ!

VPN 等で社内と接続せずに AWS だけで閉じた環境にするんだったら、適当に決めるだけでいいんですけどね。

結局 Elasticsearch ってどんな場面で活躍するの? [cloudpack OSAKA blog]

ナスです。なんか気がついたら 1 ヶ月近くも記事を書いてませんでした。
連休とか他にもイベントがあるとついついサボってしまいますね。

前回まで、Elasticsearch の技術的な内容を書いてきましたが、結局何に使えるの?って声がありましたので、ちょっと考えてみたいと思います。

 

基本的な使い方

よく聞くのがログ分析ですね。Web サーバやその他いろんなシステムのログを Elasticsearch に送って、ログを集計したり分析したり、kibana でダッシュボード的に使うとか、まぁそんな感じです。こうやって書くと、それって必要?とか言われます。実際、私もログ扱うのにそんなに困る?って思ってました。

 

ログの集計とか CloudWatch Logs でいいやんって?

CloudWatch Logs だと各リソースからログを集めて一元的に見れるって思いますよね。

使ってみたらわかりますが、いざという時にログ検索するとイラッとします。時間とかインスタンスでロググループが分かれるので、ログは確かに一箇所に集まってはいるけど、欲しい情報がすぐに出てこないです。なんとかすればできるのかもしれませんが、そこにそんな労力はかけたくないんですね。もっと簡単に目的を達成したいわけです。

そこで Elasticsearch です!

 

設定は簡単!

一旦は CloudWatch Logs にログを集めますが、Elasticsearch service に流すサブスクリプション設定をしてしまえば、あっという間に Elasticsearch にログが転送されます。しかもこちらが定義した通りの構造(フィルタ)で json 形式で。
こうすることで項目ごとに検索したり、ステータスごとに集計してダッシュボードに表示させたりできるので、日々の運用で助かる場面が結構出てきます。

まだ東京リージョンにはきていませんが、Kinesis Firehose を使うと、CloudWatch Logs を経由しなくてもログを Elasticsearch に放り込むことができますよ。
Kinesis Firehoseを使用してApache WebログをAmazon Elasticsearch Serviceに送信する | Amazon Web Services ブログ

 

個人的にはトラブルシューティングに役立つと思ってる

障害発生すると、普通ならある程度リソース情報を調べて、各サーバにログインしてログを見ていくわけですが、Elasticsearch 使っているといちいちサーバに入らなくてもログが見れるのが一番嬉しいと思います。

OS やアプリごとに検索の仕方は変わりますし、いろんな統計情報は監視システムで見たりするのって面倒です。でも Elasticsearch があると、そこだけでログ調査ができますし、うまく構造化できていればアクセス解析的な情報も取れるので、ログとアクセス状況とを見比べるような障害対応の時に使えると思います。

ただし、条件もあります。ログはもれなく格納されている必要があるし、分析しやすいように構造を考えないといけないし、そもそもの前提としてログフォーマットが少なくともアプリレベルで揃っている必要があります。(でないと日付とその他全部、と言う風に入れることになる。それは悲しい。)

銀の弾丸なんてないことはみなさんご承知だと思うので、その辺りはうまく使ってあげる必要が出てきます。

 

類似のものはいくつかある

Elasticsearch と似たようなものが他にもあります。

例えば、Sumo Logic は SaaS で提供されています。Elasticsearch と似ていますが、とりあえずすべてのログを放り込んで、調査する時にパースをかけていくので、絶対に前もって構造を考えないといけない、ということがありません。が、それゆえに、データが溜まりすぎるとパースが遅くなる、と言うデメリットもあるようです。あるようです、といったのは、Sumo Logic は使ったことないからです、すみません…
www.sumologic.com

あとは、Splunk が有名ですかね。こちらは、サーバにインストールして使うものと SaaS 提供と選べます。こっちの方が使い勝手がいいように思います。
www.splunk.com

あとは全く調べたことがないですが、BigQuery とかですかね。
BigQuery - アナリティクス データ ウェアハウス  |  Google Cloud Platform

たぶん他にもたくさん似たようなものがあると思います。

 

それぞれ、メリットデメリットがあるので、使いやすいものを使えばいいと思います。なんとなくこれまで使ってきた感想としては、多少苦労してでもコストを抑えたいのであれば Elasticsearch でいいですし、お金払ってでも楽に運用したいのであれば Sumo Logic や Splunk を使った方がいいですね。

今回紹介したものはクラウドを使ったサービスですが、ログの収集元はどこでも大丈夫です。なので、ちょっと気になった方はぜひ使ってみてください。それでもし「これは使える!」と思ったらぜひスモールスタートでいいので導入して運用してみてください。