こんにちは。技術開発室の與島です。

弊社で開発しているNagios NRPEの代替プロダクト happo-agentのバージョン2.0.0で、AWSのAmazon EC2 Auto Scaling(以降Auto Scalingと記す)環境での動作をサポートしました。

GitHub - heartbeatsjp/happo-agent

監視にNagiosを使っている弊社では、監視対象サーバが動的に入れ替わるAuto Scalingをどのように監視するかが課題になっていました。 これまでは担当エンジニアが監視の仕組みを独自実装することで対応していましたが、様々なお客様のシステムを運用している弊社のようなケースでは、ある環境で利用した仕組みを他の環境に横展開することが難しく、都度実装のコストがかかっている状況でした。

今回のアップデートにより、監視エージェントにhappo-agentを利用している環境であればAuto Scalingのインスタンスの入れ替わり、増減などに追従して監視が行えるようになります。

happo-agent

はじめにhappo-agentについて改めて紹介します。

happo-agentはHTTPS(HTTP) + JSONの通信インターフェースをもつ監視エージェントです。

チェックの実行にはPOST /monitorAPIを利用できます。 このAPIでは、チェックプラグインとプラグインオプションをJSONデータとして送ると、その実行結果を返します。

また、POST /monitor用のクライアントプログラムとして、NagiosプラグインのGitHub - heartbeatsjp/check_happoをOSSとして公開しています。 監視エージェントとしてhappo-agentを利用する場合、Nagiosのサービス定義(監視項目)におけるcheck_commandにはcheck_happoを使います。

check_happoを利用したチェックは次のように行うことができます。

$ check_happo monitor --host 192.0.2.1 --plugin_name "check_procs" --plugin_option "-w 100 -c 200"
PROCS OK: 75 processes

また、各APIは踏み台サーバ経由でアクセスすることもできます。POST /proxyがそれを提供するAPIです。

check_happoでは--proxyオプションを指定することで、踏み台サーバ経由でのチェックが実行できます。 192.0.2.1:6777 → 198.51.100.1 という経路で、チェックを行う場合は次のようになります。

$ check_happo monitor --host 198.51.100.1 --proxy 192.0.2.1 --plugin_name "check_procs" --plugin_option "-w 100 -c 200"
PROCS OK: 75 processes

happo-agentについては以下のブログでも紹介していますので、よろしければご覧ください。

Auto Scalingの監視の仕組み

Nagiosとhappo-agentのAuto Scalingサポート機能を利用して、次のような方法でAuto Scalingの監視を実現することができます。

  1. NagiosにAuto Scalingで最大スケールする台数分のホスト定義をあらかじめ作成しておく
  2. Nagiosのホスト定義に実際に起動しているAuto Scalingのインスタンスを割り当てる
    • 踏み台サーバのhappo-agentが「Nagiosのホスト定義 - Auto Scalingのインスタンス」を紐づけたデータを保存する
  3. 踏み台サーバはPOST /proxyで受けたリクエストの転送先がAuto Scalingのインスタンスだった場合は、自身が持つインスタンス情報を参照して実際のインスタンスにリクエストを転送する

この方式では監視踏み台サーバが必須になります。

  1. NagiosにAuto Scalingで最大スケールする台数分のホスト定義をあらかじめ作成しておく

については、Nagios本体の設定のはなしなので詳細は割愛します。

  1. Nagiosのホスト定義に実際に起動しているAuto Scalingのインスタンスを割り当てる
    • 踏み台サーバのhappo-agentが「Nagiosのホスト定義 - Auto Scalingのインスタンス」を紐づけたデータを保存する
  2. 踏み台サーバはPOST /proxyで受けたリクエストの転送先がAuto Scalingのインスタンスだった場合は、自身が持つインスタンス情報を参照して実際のインスタンスにリクエストを転送する

については、これを行うための機能をhappo-agentが持っています。詳しく解説します。

踏み台サーバのhappo-agentが持つインスタンス情報

  1. Nagiosのホスト定義に実際に起動しているAuto Scalingのインスタンスを割り当てる
    • 踏み台サーバのhappo-agentが「Nagiosのホスト定義 - Auto Scalingのインスタンス」を紐づけたデータを保存する

インスタンス一覧を返すAPI GET /autoscaling で踏み台サーバのhappo-agentに保存されているデータが確認できます。

2台のインスタンスが起動しているAuto Scalingグループの場合は次のようなレスポンスになります。

{
  "autoscaling": [
    {
      "autoscaling_group_name": "hb-autoscaling",
      "instances": [
        {
          "alias": "hb-autoscaling-web-01",
          "instance_data": {
            "ip": "192.0.2.1",
            "instance_id": "i-aaaaaa",
            "metric_config": {
              "Metrics": null
            }
          }
        },
        {
          "alias": "hb-autoscaling-web-02",
          "instance_data": {
            "ip": "192.0.2.1",
            "instance_id": "i-bbbbbb",
            "metric_config": {
              "Metrics": null
            }
          }
        }
      ]
    }
  ]
}

Auto Scalingグループ(autoscaling_group_name)とAuto Scalingに紐づくインスタンス(instances)の情報がレスポンスとして返ってきています。

この場合、Auto Scalingグループ名は「hb-autoscaling」です。 「hb-autoscaling-web-01」、「hb-autoscaling-web-02」はそれぞれNagiosのホスト定義を表しており、happo-agentのなかではaliasと呼んでいます(以降の解説でもaliasと記す)。また、各インスタンスのIPアドレス、インスタンスID、メトリック収集コマンド(metric_config)をデータとして持っていることがわかります。

Auto Scalingのインスタンスへのリクエスト転送

  1. 踏み台サーバはPOST /proxyで受けたリクエストの転送先がAuto Scalingのインスタンスだった場合は、自身が持つインスタンス情報を参照して実際のインスタンスにリクエストを転送する

POST /proxyは踏み台サーバ経由でのリクエストに利用するAPIです。
通常は、

  • 踏み台サーバ
  • プロキシ先のサーバ

は固定のIPアドレスかDNS名になりますが、Auto Scaling環境の場合は「プロキシ先のサーバ」が動的に入れ替わります。
そこでaliasの値を利用します。POST /proxyにリクエストする際の「プロキシ先のサーバ」(check_happoのオプションの場合--host)にaliasの値を指定します。
するとリクエストを受けた踏み台サーバのhappo-agentは、自身が保存しているインスタンス情報を参照してaliasに紐づくインスタンスのIPアドレス宛にリクエストを転送します。

次のようなイメージです。

nagios_happo-agent_auto_scaling.jpg

  • ① Nagiosサーバから踏み台サーバのhappo-agentに「hb-autoscaling-web-01」への監視のリクエスト
  • ② 踏み台サーバのhappo-agentが「hb-autoscaling-web-01」に紐づくインスタンスのIPアドレス(192.0.2.1)を参照
  • ③ 踏み台サーバのhappo-agentから192.0.2.1のインスタンスに監視のリクエスト

また、check_happoで 192.0.2.1:6777 → hb-autoscaling-web-01:6777 という経路でチェックを実行すると次のような結果になります。

$ check_happo monitor --host hb-autoscaling-web-01 --proxy 192.0.2.1 --plugin_name "check_procs" --plugin_option "-w 100 -c 200"
PROCS OK: 76 processes
AutoScaling Group Name: hb-autoscaling
AutoScaling Instance PrivateIP: 172.16.4.146

aliasに紐づくインスタンスがない場合は、踏み台サーバのhappo-agentはリクエストを転送せずに適当なレスポンスを返します。 proxyするリクエストがPOST /monitor APIへのリクエストである場合は、チェックの実行結果がOKであることを表すダミーレスポンスです。 これによりAuto Scalingによるインスタンスの起動数が最大数に満たない場合でも、誤報によるアラートが発生しないようになっています。

$ check_happo monitor --host hb-autoscaling-web-01 --proxy 192.0.2.1 --plugin_name "check_procs" --plugin_option "-w 100 -c 200"
hb-autoscaling-web-01 has not been assigned instance

インスタンスの更新

Auto Scalingの環境下ではインスタンスが動的に入れ替わります。そのため、踏み台サーバのhappo-agentに保存しているインスタンス情報もそれに追従して随時更新する必要があります。

POST /autoscaling/refreshは、上記のhappo-agentが持つインスタンス情報を更新するためのAPIです。 AWSのAPIからインスタンス一覧を取得して、それをNagiosのホスト定義(alias)に割り当てます。

このAPIは冪等性を意識した実装になっており、あるインスタンスを示すaliasは、そのインスタンスがAuto Scalingグループから外れない限りは変わらないようになっています。

インスタンスの登録

POST /autoscaling/instance/registerは、インスタンス情報を登録するためのAPIです。

Auto Scalingで起動したインスタンスが、自身の情報を踏み台サーバのhappo-agentに登録するために利用します。

nagios_happo-agent_auto_scaling_register.jpg

踏み台サーバへのリクエストの実行は、happo-agentをデーモンとして起動したときの初期処理に組み込んでいます。これは以下の設定をすることで有効になります。

インスタンスの登録解除

POST /autoscaling/instance/deregisterは、インスタンス情報の登録を解除するためのAPIです。

Auto Scalingのインスタンスがスケールインするときに、自身の情報を踏み台サーバのhappo-agentから登録解除するために利用します。

nagios_happo-agent_auto_scaling_deregister.jpg

これはインスタンスが停止するときに実行する必要があるため、happo-agentのプログラムではなく、systemdもしくはUpstartでタイミングをコントロールする想定にしています。
happo-agentのリポジトリに設定ファイルがあります。

インスタンスに障害が発生した場合

インスタンスが正常にスケールインするときは自発的に踏み台サーバに登録解除のリクエストを送ることができますが、インスタンスに異常が発生した場合はそれができません。

そのため、happo-agentではAuto Scalingのインスタンスに対する監視のリクエストが失敗した場合にインスタンス情報の更新(POST /autoscaling/refreshAPIと同じもの)を実行するようにしています。なお、ここでいう「監視のリクエストが失敗」というのはHTTPリクエスト自体が失敗した場合を指しています。

通常Auto Scalingのインスタンスに異常が発生すると、ヘルスチェックでそれを検知してインスタンスが自動で削除され、新しいインスタンスが自動で起動します。新しいインスタンスが起動後にインスタンス情報を更新すれば、異常なインスタンスの情報は削除され、新しいインスタンスの情報が登録されます。これにより監視すべきインスタンスに対して監視を継続することができます。

まとめ

Nagiosとhappo-agentを利用したAuto Scalingの監視の仕組みについてご紹介しました。

Nagiosを利用してAuto Scalingを監視する方法としては、他にもNagiosのホスト定義を動的に生成する手法もあります。 しかし、弊社ではNagiosを監視サーバとして利用するだけではなく業務の様々な仕組みと連携している関係上、なるべくNagios本体に手を入れずに済むようにということで、このやり方になりました。

今回は監視についてご紹介しましたが、happo-agentの他の機能(メトリック収集、インベントリ収集)も、それぞれAuto Scaling環境にあわせて動きをするようになっています。ご興味がありましたらREADMEもあわせてご覧いただければと思います。

株式会社ハートビーツのインフラエンジニアから、ちょっとした情報をお届けします。