sakuracloud_exporter v0.7.0 − コレクターごとの無効化/fakeモードの追加 など

Prometheusのさくらのクラウド向けExporterであるsakuracloud_exporterのv0.7.0をリリースしました。

github.com

v0.7.0での主な変更/修正点は以下の通りです。

今回の修正はちょっと特殊な状況向けではありますが、ハマれば非常に便利なものだと思います。 順に紹介します。

コレクターごとの有効/無効切り替え

sakuracloud_exporterではさくらのクラウドAPIでリソース一覧を取得〜必要に応じて各リソースごとに詳細取得のためにさらにAPI呼び出し、という処理を行なっています。 このため、さくらのクラウド上に大量のリソースを持つようなケースでは一連のAPI呼び出しに長い時間がかかってしまうことがあります。

そこでこの問題への対応の一環としてコレクターごとに有効/無効を指定できるようになりました。
以下のフラグを用いて各コレクターごとに設定が可能となっています。

  • --no-collector.auto-backup: 自動バックアップ
  • --no-collector.coupon : クーポン
  • --no-collector.database: データベース
  • --no-collector.internet : スイッチ+ルータ
  • --no-collector.load-balancer: ロードバランサ
  • --no-collector.mobile-gateway: モバイルゲートウェイ
  • --no-collector.nfs: NFS
  • --no-collector.proxy-lb: エンハンスドロードバランサ
  • --no-collector.server: サーバ
  • --no-collector.sim: SIM
  • --no-collector.vpc-router: VPCルータ
  • --no-collector.zone: ゾーン情報

デフォルトでは全コレクターが有効となっています。

特定のコレクターだけ無効にするようなケースや、特定のコレクターだけ有効にして複数のexporterを起動するようなケースなどにご利用いただけると思います。

さくらのクラウドAPI呼び出しの代わりにローカルファイルから値を取得する「fakeモード」

このバージョンからGo言語向けさくらのクラウドAPIライブラリ libsacloud v2.0が利用されるようになりました。

libsacloud v2.0では主にテスト用の機能として、さくらのクラウドAPI呼び出しをラップしてダミーの応答を返す「fakeドライバー」という仕組みが導入されました。fakeドライバーはステートフルな処理(リソースの登録〜登録したリソースを後から参照、など)を行うためにステートを保持しています。ステートは保存先をインメモリ or ファイルから選べるようになっています。

このfakeドライバーを利用することでsakuracloud_exporterでサーバがダウンした状況やメンテナンスがスケジュールされた状況などを意図的に作り出すことを容易にするのが今回導入された「fakeモード」です。

fakeモードはibsacloudのfakeドライバーを利用してさくらのクラウドAPI呼び出しの代わりにステートファイルから値を取得してメトリクスを算出するモードです。

fakeモードの有効化

fakeモードの有効化は

  • 起動時のオプション--fake-modeの指定
  • 環境変数FAKE_MODEの指定

の何れかで可能です。

値はステートファイルのパスを指定します。

例えばカレントディレクトリのfake-store.jsonというファイルを利用する場合は以下のように指定します。

$ sakuracloud_exporter --fake-mode fake-store.json

ファイルが存在しない場合は新規作成されます。 (とはいえその状態だと何もリソースが存在しないためあまり意味はないでしょうが)

fakeモードではこのファイルからサーバやディスクといったリソースの情報を読み取ってメトリクスを出力します。

ステートファイルはJSONとなっており、以下のようなものです。

[
    {
        "Availability": "available",
        "CPU": 1,
        "CreatedAt": "2019-08-05T11:35:39.075614+09:00",
        "Description": "desc",
        "ID": "100000000022",
        "InstanceHostInfoURL": "",
        "InstanceHostName": "sac-is1a-svXXX",
        "InstanceStatus": "up",
        "InterfaceDriver": "virtio",
        "Interfaces": [
            {
                "HostName": "",
                "ID": 100000000028,
                "IPAddress": "",
                "MACAddress": "00:00:5e:00:53:01",
                "PacketFilterID": "",
                "PacketFilterName": "",
                "PacketFilterRequiredHostVersion": 0,
                "SubnetBandWidthMbps": 0,
                "SubnetDefaultRoute": "",
                "SubnetNetworkAddress": "",
                "SubnetNetworkMaskLen": 0,
                "SwitchID": 100000000008,
                "SwitchName": "",
                "SwitchScope": "",
                "UpstreamType": "",
                "UserIPAddress": "",
                "UserSubnetDefaultRoute": "",
                "UserSubnetNetworkMaskLen": 0
            }
        ],
        "MemoryMB": 1024,
        "Name": "example",
        "ResourceType": "Server",
        "ServerPlanCommitment": "standard",
        "ServerPlanGeneration": 100,
        "ServerPlanID": 100001001,
        "ServerPlanName": "世代:100 メモリ:001 CPU:001",
        "Tags": [
            "example",
            "server"
        ],
        "ZoneName": "is1a"
    }
]

ステートファイルの例として、sakuracloud_exporterが利用する各種リソースが登録されているものを以下に用意しています。

sakuracloud_exporter/example-fake-store.json at 0.7.0 · sacloud/sakuracloud_exporter · GitHub

ステートファイルはテキストファイルですのでエディタなどで編集することができるようになっています。

fakeモードの利用例: サーバのメンテナンス情報の登録

ここでは通常だと手動で発生させるのが難しい、サーバのメンテナンス情報の登録をfakeモードで行なってみます。

さくらのクラウドでのメンテナンス情報とは?

さくらのクラウドではサーバが稼働しているホストの不調などでサーバの再起動が必要になる場合があります。 (再起動することで別のホストで稼働させる)

メンテナンスは通常事前に通知され、期限までにユーザーが任意のタイミングでサーバの再起動を行うことが可能となっています。 また、メンテナンス情報はウェブサイト上で公開されているほか、APIからも参照できるようになっています。

これを利用してsakuracloud_exporterではメンテナンス情報を取得するためのメトリクスを提供しており、これらを利用して独自に監視/通知の仕組みを整えることができます。 (詳しくは以下で紹介させていますので参照ください)

medium.com

このメンテナンス情報ですが、当然ながらメンテナンスを任意に発生させるというのは困難です。
たまたまメンテナンス対象のサーバが手元にあればよいですが、そうでない場合がほとんどだと思います。

このためPrometheusでメンテナンス情報を監視/通知する仕組みを用意しても動作確認がすぐには出来ません。 これは困りますよね。

このような場面でfakeモードが役に立ちます。

ということでfakeモードでのexporterの起動〜メンテナンス情報の登録までをやってみます。

fakeモードを有効にしてexporterを起動

まずはfakeモードでexporterを起動してみます。 ステートファイルは先ほど紹介したGitHub上に公開されている例を用います。

# exampleステートファイルをGitHubからダウンロード
$ curl -sLO https://raw.githubusercontent.com/sacloud/sakuracloud_exporter/0.7.0/examples/fake/generate-fake-store-json/example-fake-store.json

# fake-modeオプションを指定してexporterを起動
$ sakuracloud_exporter --fake-mode example-fake-store.json

Prometheusのコンソールからサーバの情報を参照(sakuracloud_server_info)すると2台のサーバが存在することが確認できるはずです。

f:id:febc_yamamoto:20190806094126p:plain

ID: 100000000022と ID: 100000000035の2台ですね。

また、メンテナンス情報は sakuracloud_server_maintenance_infoで確認できます。

f:id:febc_yamamoto:20190806094434p:plain

ID:100000000035にはすでにメンテナンス情報が登録されていますね。 これはメンテナンス確認用として最初から登録されているやつです。 単にメンテナンス情報としてどのようなメトリクスが参照できるか確認したいだけの場合はこちらを利用すればOKです。

今回はメンテナンス情報の登録されていないID: 100000000022の情報を操作してメンテナンス情報を登録してみます。

ステートファイルを操作してメンテナンス情報を登録

次にステートファイルexample-fake-store.jsonをエディタなどで修正してメンテナンス情報を登録します。 JSON内のID: 100000000022のサーバの部分を探し出し、InstanceHostInfoURLというフィールドにhttp://support.sakura.ad.jp/mainte/mainteentry.php?id=26595という値を設定します。

JSONは以下のようになっているはずです。

// 該当部分だけ抜粋
    {
        "ID": "100000000022",
        "InstanceHostInfoURL": "http://support.sakura.ad.jp/mainte/mainteentry.php?id=26595",

ファイルを編集して保存するとexporterにより自動で再読み込みが行われます。 その後(Prometheusによるスクレイピングの後に)Prometheusのコンソールで再度メンテナンス情報を確認するとID: 100000000022のサーバにもメンテナンス情報が登録されたことが確認できます。

f:id:febc_yamamoto:20190806095559p:plain

これでメンテナンス情報を登録することができました。 逆にメンテナンス情報のクリアもできますのでアラートルールの確認などに便利にお使いいただけると思います。

終わりに

sakuracloud_exporter v0.7.0の紹介でした。 徐々に便利になってきてますのでぜひご利用&フィードバックいただけると嬉しいです。

以上です。

入門 Prometheus ―インフラとアプリケーションのパフォーマンスモニタリング

入門 Prometheus ―インフラとアプリケーションのパフォーマンスモニタリング