Mackerel運用を支える仕組み

Mackerel運用を支える仕組み

ペパボでムームードメインの開発運用を担当している@pyama86です。

このエントリはMackerel Advent Calendar 2015の12月14日のエントリです。昨日は@ariarijpさんによるエントリでした。

はじめに

ペパボでは従来よりサーバ監視の多くがNagiosにより行われていました。しかし昨今では、クラウドとの相性の良さからMackerelによるサーバ管理へと移行しつつあります。このエントリでは細かい管理の紹介については以前筆者がMackerel MeetUp #5で登壇した際の資料に譲り、Mackerelを大規模導入した際に起こりがちな問題を検知する仕組みを紹介します。

  • ロールに属していないホストを検知する
  • 開発、検証環境ホストへのインストールを検知する
  • 退役忘れホストを検知する
  • オーバースペックなホストを検知する

ロールに属していないホストを検知する

Mackerelにおいては御存知の通りロールを軸として様々な監視、管理を行うことが出来ます。ホストをロールに所属させるにはmackerel-agent.confに定義、APIを用いて操作いずれかの作業が必要ですが、その作業の両方を行っていない場合、ロールに所属しないホストが出来てしまいます。そうなってしまった場合に、気づくにはmkrコマンドでmkr hosts | jq -r '.[] | select(.roleFullnames == null)'とするか、WEBUIから探し出すといった作業が必要になります。これを自動で検知すべくペパボでは筆者が開発したmalsh(マルシェ)というコマンドを利用しています。malshは同僚の@ryutaro_mizokamが開発しているmackerel-rbを利用して各APIの実行結果をSlackに通知することができるコマンドです。筆者の使用方法としてはwheneverと組み合わせて下記のような使い方をしています。

%w(
  MACKEREL_APIKEY
  SLACK_WEBHOOK
  SLACK_CHANNEL
  SLACK_USER
).each do |e|
  env e.to_sym, ENV[e]
end
every :day, :at => '1:00pm' do
  command "/path/to/bin/malsh maverick"
end

これだけの定義で毎日13時にSlackに対してロールに所属していないホストを通知することが出来ます。

marveric

ちなみにmaverickの由来はこのコマンドを書いている時に、映画「トップガン」をながら見していて、作品中でのトム・クルーズの役が一匹狼の凄腕パイロットmaverickであったことに由来します。(トム・クルーズ最高!!!!)

開発、検証環境ホストへのインストールを検知する

puppet,chef,itamaeでのインフラ管理が当たり前となった昨今においてはMackerelのインストールにおいてもコード・自動化していることがほとんどだと思います。しかし新たにレシピを書いた際についつい分岐を入れ忘れたりして、開発、検証環境に誤ってMackerelをインストールしてしまうことも少なくないのではないでしょうか?解決策としてmalshではホスト名で検索し、通知することが出来ます。他にもやり方としてはIPアドレスがローカルアドレスであるというような条件付けも可能に思えますが、現状はホスト名による検知で問題なく運用出来ています。

/path/to/bin/malsh search -e local dev -v exclude.local --subject 不要ホスト候補一覧

この定義ではホスト名にlocalもしくはdevを含むかつexclude.localを含まないホストを、不要ホスト候補一覧という件名でSlackに通知しています。

退役忘れホストを検知する

Mackerelのライセンスはホスト単位となっており、出来るだけ費用を抑えるには、無駄なインストールはしない、必要のないホストは退役させるこれに尽きます。ただし、ライセンスの体系は必ずしもインストール数ではありません。以下公式FAQより引用

1時間程度以内の間隔で定期的にアクティブなホスト数をカウントします。
ホストのステータスに関わらず、メトリック投稿APIにアクセスしたユニークなホスト数を計上します。
通常はmackerel-agentの起動数となります。
退役(Retired)状態のホストはアクティブなホストとしてカウントされません。
30日間、もしくはこれまでの利用済み期間の短かい日数の平均を計算し、その値を利用しているホスト数とします(端数切り上げ)。

上記のホストのステータスに関わらず、メトリック投稿APIにアクセスしたユニークなホスト数を計上します。に注目して、malshでは過去5分のロードアベレージの投稿がないにもかかわらず、Mackerelに登録されているホストを検知することが出来ます。

/path/to/bin/malsh retire

本来であればAUTO_RETIREMENT(自動退役)使えばよい話なのですが、AUTO_RETIREMENT自体がリリース時から使えたわけではなく、またsystemd環境での動作がうまくいってなかったこともあり、必ずしも全ホストにAUTO_RETIREMENTを適用できていないケースも多いのではないかと思います。そういった場合にこの通知を行うことによって退役忘れを防ぐことが出来ます。

オーバースペックなホストを検知する

冒頭で申したとおり、Mackerelはクラウドとの相性が非常によく、AWSやOpenStackと合わせて利用しているユーザーも多いのではないでしょうか?いずれにおいてもインスタンスの費用はスペックに応じて高くなる傾向があり、逆に言えばインスタンスのスペックを低くすればコストを抑えられる事になります。malshでは先日リリースされたグラフメトリックデータ取得APIを利用してCPU、Memory過去N日間の最高使用率がXX%を下回っているホストを検知することが出来ます。

/path/to/bin/malsh search -memory 40 -cpu 40 -subject '過去7日間CPUとMemoryの最高使用率が40%以下のホスト一覧'

過去N日間のデフォルトは7日間で、月次バッチなどを考えると1ヶ月(–past_date 30)といった運用も良いのではないかと思います。またCPU、Memory単独でのしきい値指定も可能です。この通知を行うことによって、ついつい安心モードで大きく作ってしまうインスタンスを見直すきっかけを生み出すことが出来ます。

最後に

本エントリではMackerelを使って何かをすることではなく、Mackerelを上手く運用する幾つかの手段について紹介しました。これまでの監視ツールと異なり、監視対象側に設定の多くを持つことから導入の手間が少ない反面、全体的な管理がしにくい部分もあります。その部分はAPIが提供されているので、上手く利用し、足りない部分を自分たちの運用に合わせて実装していけばより良い運用になると考えます。

そしてグラフメトリックデータ取得APIなど、多くの要望をはてな社に送り、順次対応していただけていることから今後も出来ることが広がり、サーバ監視からよりサーバ管理により近づいていくことが期待できるので、ぜひMackerel利用してみてはいかがでしょうか?

明日は@fujiwaraさんです。

facebook
Twitter
コメントは受け付けていません。
Social Share Buttons and Icons powered by Ultimatelysocial