GitHub EnterpriseをAWSで使おう – SNMPモニタリングとCloudWatch Metricsを利用したメトリクスの収集/可視化

はじめに

こんにちは、中山です。

GitHub Enterprise(以下GHE) on AWSシリーズの第9弾です。今回はSNMPモニタリングを利用したGHEのメトリクス収集とCloudWatch Metricsでそのデータを可視化する方法ついてご紹介します。GHE上でSNMPモニタリングを有効化し、Collectdを設定した同じVPC上のEC2インスタンスからその値を収集、最終的にCloudWatch Metricsに表示させます。SNMPのデータ収集にはSNMPプラグインを、CloudWatch Metricsへのデータ送信にはCloudWatchプラグインをそれぞれ利用します。

CollectdからCloudWatch Metricsへデータを送信するプラグインはAWSが公式に提供しているものです。弊社の下記エントリで詳細に解説しているので合わせて参照いただくと理解が深まるかと思います。

• collectdのCloudWatchプラグインを試してみた
• collectdのCloudWatchプラグインでデフォルト以外の様々なデータをカスタムメトリクスで送る方法

今回動作検証した主要なソフトウェア/OSのバージョンは以下の通りです。バージョンによって設定方法が変更される可能性があります。その点ご了承ください。

• GHE: 2.8.4
• Amazon Linux: 2016.09.1 (HVM), SSD Volume Type - ami-9be6f38c
• Collectd: 5.4.1
• collectd-snmp: 5.4.1
• cloudwatch-collectd: 1.0

構成

今回は以下のような構成を作成します。

やってみる

今回もGHE自体やVPCなどのネットワーク周りのリソースについては、GitHub社が提供しているCloudFormationテンプレートですでに構築済みとして進めさせていただきます。設定方法については以下のエントリを参照してください。

• GitHub EnterpriseをAWSで使おう – インストール編

また、EC2インスタンス自体の構築についても下記エントリを参照いただくとして割愛させていただきます。

• GitHub EnterpriseをAWSで使おう - Amazon Kinesis Firehoseを利用したログのアーカイブ

ただし、今回はEC2インスタンスからCloudWatch Metricsへデータをputさせる必要があるため、関連付けるIAM Roleに最低限以下の権限を付与してください。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloudwatch:PutMetricData"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}

1. SNMPモニタリングの有効化

まずはGHE上でSNMPモニタリングを有効化しましょう。といっても設定方法は非常に簡単です。以下のようにマネジメントコンソールからボタンをポチポチするだけで完了します。

今回はコミュニティ名として test という文字列を設定していますが、この文字列はパスワードとしても機能しています。実際に利用する際はより複雑な文字列にしてください。

また、注意点としてGHEのSNMP情報にアクセスできるネットワーク範囲を制限した方がよいです。執筆時点(2016/12/25)ではSNMPの設定でネットワークアドレスを制限することはできないようです。この設定ではGHEのパブリックIPアドレス/FQDNが分かればアクセスできてしまいます(もちろんコミュニティ名も必要)。例えば関連付けるセキュリティグループのインバウンド設定でUDP:161をVPC内のみに制限することで、不要な情報がVPC外に漏れないようにしましょう。

2. Collectdの設定

続いてEC2インスタンス上でCollectdのインストールとセットアップをします。

# SSHログイン
$ ssh -i path/to/key ec2-user@<_YOUR_EC2_PUBLIC_IP_>
<snip>
# Collectdのインストール
[ec2-user@ip-172-31-21-198 etc]$ sudo yum install collectd -y
<snip>

この時点でCollectdのログファイル出力先を変更しておきましょう。デフォルトで /var/log/messages に出力してしまうので他のログと混ざってしまいデバッグしにくいためです。以下のように /var/log/collectd.log に出力させます。

# 設定ファイルの修正
[ec2-user@ip-172-31-21-198 ~]$ sudo sh -c 'cat <<EOT >> /etc/collectd.conf
> LoadPlugin logfile
> <Plugin logfile>
>   LogLevel info
>   File "/var/log/collectd.log"
>   Timestamp true
>   PrintSeverity false
> </Plugin>
> EOT
> '
# 設定ファイルの文法確認(問題なければ標準出力に何も表示しない)
[ec2-user@ip-172-31-21-198 ~]$ sudo collectd -t
# Collectdの起動
[ec2-user@ip-172-31-21-198 ~]$ sudo service collectd start
Starting collectd:                                         [  OK  ]
# ログの確認
[ec2-user@ip-172-31-21-198 ~]$ cat /var/log/collectd.log
[2016-12-25 08:20:39] Initialization complete, entering read-loop.

3. CloudWatchプラグインの設定

今度はCloudWatchプラグインのインストールとセットアップを行います。このプラグインはGitHub上のリポジトリからCloneさせるのでGitコマンドをインストールしておきます。

# Gitコマンドのインストール
[ec2-user@ip-172-31-21-198 etc]$ sudo yum install git -y
<snip>
# リポジトリのClone
[ec2-user@ip-172-31-21-198 ~]$ git clone https://github.com/awslabs/collectd-cloudwatch.git ~/collectd-cloudwatch
<snip>

インストールにはセットアップ用スクリプトを用意してくれているのでそれを実行します。実行後インタラクティブに設定してくれるのでお手軽です。基本的にはデフォルト設定でよいのですが1つ注意点があります。今回メトリクスの収集対象はEC2インスタンスではなくGHEです。2つ目の「Choose hostname for published metrics」という質問でCloudWatch Metricsに表示させるHost名の設定をするのですが、デフォルトではEC2インスタンスのインスタンスIDになってしまいます。紛らわしいので ghe-01 などGHEと分かる文字列に変更しておきましょう。ちなみにですが、後ほど説明する設定ファイルでも指定可能です。

[ec2-user@ip-172-31-21-198 ~]$ sudo ~/collectd-cloudwatch/src/setup.py
Installing dependencies ... OK
Installing python dependencies ... OK
Downloading plugin ... OK
Extracting plugin ... OK
Moving to collectd plugins directory ... OK
Copying CloudWatch plugin include file ... OK

Choose AWS region for published metrics:
  1. Automatic [ap-northeast-1]
  2. Custom
Enter choice [1]:

Choose hostname for published metrics:
  1. EC2 instance id [i-0e83adfe50c6c9335]
  2. Custom
Enter choice [1]: 2
Enter hostname [ip-172-31-21-198]: ghe-01

Choose authentication method:
  1. IAM Role [ghe-ec2-role]
  2. IAM User
Enter choice [1]:

Choose how to install CloudWatch plugin in collectd:
  1. Do not modify existing collectd configuration
  2. Add plugin to the existing configuration
Enter choice [2]:
Plugin configuration written successfully.
Stopping collectd process ... OK
Starting collectd process ... OK

インストールが完了すると /var/log/collectd.log に以下のような出力が表示されているはずです。

[2016-12-25 09:34:53] [AmazonCloudWatchPlugin][cloudwatch_writer] Initialization finished successfully.

また、 /etc/collectd.conf の末尾に Include "/etc/collectd-cloudwatch.conf" というディレクティブが追記されます。中身は以下の通りです。

LoadPlugin python

<Plugin python>
    ModulePath "/opt/collectd-plugins/"
    LogTraces true
    Interactive false
    Import "cloudwatch_writer"
</Plugin>

CloudWatchプラグインは以下3つの設定ファイルから構成されます。設置ディレクトリはデフォルトで /opt/collectd-plugins/cloudwatch/config です。

• plugin.conf
  • プラグインの動作を変更させる設定ファイル
  • 先程設定したホスト名も変更可能
• blocked_metrics
  • CloudWatch Metricsに送信させないメトリクス
  • Collectdの設定ファイルをパースして送信可能なメトリクスを生成している模様
  • ここに表示されているメトリクスが下の設定ファイルに記述可能
• whitelist.conf
  • ここに記述したメトリクスがCloudWatch Metricsに送信される(デフォルトでは空)
  • PythonのREモジュールで正規表現でも記述可能

4. SNMPプラグインの設定

最後の設定です。SNMPプラグインのインストールとセットアップをしていきます。導入時点ではそもそもEC2インスタンスからGHEに対してMIBが取得できるのか、あるいはどういったOIDが参照できるのかを確認したい場合があると思います。 net-snmp-utils パッケージに snmpget や snmpwalk コマンドなどのデバッグに有用なツールが入っているので事前にインストールしておくと便利です。

# インストール
[ec2-user@ip-172-31-21-198 ~]$ sudo yum install net-snmp-utils -y
<snip>
# EC2インスタンスからアクセス可能か確認
[ec2-user@ip-172-31-21-198 ~]$ snmpget -v 2c -c test -O e 172.31.22.231 hrSystemDate.0
HOST-RESOURCES-MIB::hrSystemDate.0 = STRING: 2016-12-25,7:7:5.0,+0:0
# 取得可能なOIDの確認
[ec2-user@ip-172-31-21-198 ~]$ snmpwalk -v 2c -c test -O e 172.31.22.231
SNMPv2-MIB::sysDescr.0 = STRING: Linux ****************************** 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
<snip>

少し話が逸れましたが以下のコマンドでプラグインをインストールします。

# SNMPプラグインのインストール
[ec2-user@ip-172-31-21-198 ~]$ sudo yum install collectd-snmp -y
<snip>
# プラグイン用設定ファイルが設置されていることを確認
[ec2-user@ip-172-31-21-198 etc]$ cat /etc/collectd.d/snmp.conf
LoadPlugin snmp
#<Plugin snmp>
<snip>

続いて設定ファイルの修正をしていきます。今回は簡易的にmanページにも記載されているGHEのユーザセッション数を取得する設定にしてみます。以下の内容を /etc/collectd.d/snmp.conf に追記してください。

<Plugin snmp>
  <Data "hr_users">
    Type "users"
    Table false
    Instance "sessions"
    Values "HOST-RESOURCES-MIB::hrSystemNumUsers.0"
  </Data>
  <Host "<_YOUR_GHE_FQDN_>">
    Address "<_YOUR_GHE_PRIVATE_IP_>"
    Version 2
    Community "test"
    Collect "hr_users"
    Interval 60
   </Host>
</Plugin>

CollectdのSNMPプラグインは Data 及び Host という2つのブロックで設定します。それぞれの内容については以下の通りです。プラグインの詳細な内容についてはcollectd-snmp(5)を参照してください。

• Data

どういった内容を問い合わせるのかを定義する箇所です。

項目	設定した値	内容
Data	hr_users	各 Data ブロックを分けるための識別子。
Type	users	CollectdのTypesDBで定義されたタイプを指定可能。詳細はtypes.db(5)を参照。実際のファイルは /usr/share/collectd/types.db にある。
Table	false	Values で指定したデータの取得方法をBool値で指定。 false の場合はGETで1つの値のみ取得する。
Instance	sessions	この値がCloudWatch Metricsのメトリック名に利用される。
Values	HOST-RESOURCES-MIB::hrSystemNumUsers.0	取得するOIDを指定。 Table が false の場合はOIDのインデックスを明示的に指定する必要がある。指定可能な値はvariables(5)または snmpwalk コマンドの出力結果を参照。

• Host

Data ブロックで定義された内容をどのホストに対して問い合わせるかなどの設定をする箇所です。

項目	設定した値	内容
Host	GHEのFQDN	Collectdが内部的に利用するホスト名？詳細わからず。。。メトリクス名には利用されてない模様。
Address	GHEのプライベートIPアドレス	Collectdが接続するIPアドレスまたはホスト名。
Version	2	SNMPのバージョン。 2 を指定すると2cとして扱われる。
Community	test	コミュニティ名。
Collect	hr_users	ホストに対してどの Data ブロックの内容を問い合わせるのかを指定。
Interval	60	データを収集するインターバル時間(秒)。

上記設定後、Collectdを再起動すると /opt/collectd-plugins/cloudwatch/config/blocked_metrics に snmp--users-sessions という文字列が追記されます。これがメトリック名として利用されるようです(SNMPプラグインの場合は snmp.<Typeで指定した値>.<Instanceで指定した値> になる模様)。この文字列を /opt/collectd-plugins/cloudwatch/config/whitelist.conf に追記した後に再度Collectdを再起動させてください。しばらくするとログファイルに以下のような出力が表示されると思います( plugin.conf で debug = "True" にしている場合)。

[2016-12-25 11:09:38] [AmazonCloudWatchPlugin][cloudwatch.modules.flusher] [debug] flushing metrics snmp--users-sessions[1]

最後にCloudWatch Metricsを確認してみます。以下のようにユーザセッション数が描画されたら成功です。やりましたね。

まとめ

いかがだったでしょうか。

SNMPモニタリングとCollectd、及びCloudWatch Metricsを利用したGHEのメトリクス収集/可視化についてご紹介しました。GHEのマネジメントコンソールを見ると分かりますが、SNMPモニタリングの有効化は推奨されています。運用していく中で有用なメトリクスが確認できるため基本的に有効化しておくことをオススメします。今回収集したデータの表示にはCloudWatch Metricsを利用しましたが、もちろんZabbixを始めとしたさまざまな監視ツールで表示させることも可能です。それらのツールと比較した場合、CloudWatchはAWS公式サービスということもあり他のAWSサービスとの連携がし易いというところがポイントの1つだと思います。また、以下のエントリにまとめられているようにログデータの保存期間が大幅に延長されるなどの嬉しいアップデートがありました。

• [CloudWatch] メトリックの保持期間が14日→15ヶ月に延長されて、グラフ機能も強化されました

すでに監視ツールを事前で用意している場合は別ですが、そうでないならまずはCloudWatchの導入を検討されてみるとよいのではないでしょうか。

本エントリがみなさんの参考になれば幸いに思います。