kakakakakku blog

Weekly Tech Blog : Keep on Learning 👍

Mackerel : check-http コマンドの --status オプションとは?

Mackerel の go-check-pluginscheck-http を使うと,エンドポイントの「チェック監視」を設定できる.なお,単純に外形監視をする場合は,Mackerel の機能で「URL 外形監視」を使える.ただし,ローカルエンドポイントを対象にするなど,check-http を使う場面もあるので,目的次第なところではある.

github.com

mackerel.io

check-http を使う

以下のように check-http コマンドを使うと,監視結果を取得できる.リターンコード 200 の場合は OK となり,リターンコード 404 の場合は WARNING となる.

# 200 の場合(サンプル)
$ check-http --url https://kakakakakku.hatenablog.com
HTTP OK: HTTP/1.1 200 OK - 214805 bytes in 0.295717 second response time

# 404 の場合(サンプル)
$ check-http --url https://kakakakakku.hatenablog.com/xxxxx
HTTP WARNING: HTTP/1.1 404 Not Found - 73031 bytes in 0.417951 second response time

なお,実際に「チェック監視」を行う場合は /etc/mackerel-agent/mackerel-agent.conf に以下(サンプル)を設定すると,Mackerel 管理画面に警告が出る.

[plugin.checks.check-http-kakakakakku-blog-200]
command = ["check-http", "--url", "https://kakakakakku.hatenablog.com/"]

[plugin.checks.check-http-kakakakakku-blog-404]
command = ["check-http", "--url", "https://kakakakakku.hatenablog.com/xxxxx"]

f:id:kakku22:20200203105724p:plain

check-http で使えるオプション

check-http には多くのオプションが実装されている.ヘルプを表示すると以下のようになる.

$ check-http --help
Usage:
  check-http [OPTIONS]

Application Options:
  -u, --url=                                          A URL to connect to
  -s, --status=                                       mapping of HTTP status
      --no-check-certificate                          Do not check certificate
  -i, --source-ip=                                    source IP address
  -H=                                                 HTTP request headers
  -p, --pattern=                                      Expected pattern in the content
      --max-redirects=                                Maximum number of redirects followed (default: 10)
      --connect-to=HOST1:PORT1:HOST2:PORT2            Request to HOST2:PORT2 instead of HOST1:PORT1
  -x, --proxy=[PROTOCOL://][USER:PASS@]HOST[:PORT]    Use the specified proxy. PROTOCOL's default is http, and PORT's
                                                      default is 1080.
      --user=USER[:PASSWORD]                          Basic Authentication user ID and an optional password.

Help Options:
  -h, --help                                          Show this help message

check-http --status とは?

ヘルプを見ただけだと,--status オプションをどう使えば良いのかわからなかった.コメントには「mapping of HTTP status」としか書かれていない.なお,GitHub の README.md を見ると,以下のようなサンプルは載っていた.何やら「特殊な構文」がありそうだとわかる.

check-http -s 404=ok -u http://example.com
check-http -s 200-404=ok -u http://example.com

整理をすると,check-http--status オプションは,Mackerel の「チェック監視」として「特定のリターンコードの監視結果を個別に設定するとき」に使う.例えば「404 を正常 (OK) とする」など.

今回は Go の実装を読みながら --status オプションの動作を整理した.

--status オプションに設定できるフォーマット

--status オプションには,以下の通り,2種類のフォーマットを設定できる.「特定のリターンコード」を設定することもできるし,ハイフンを使って「リターンコードの範囲(以上/以下)」を設定することもできる.

${コード}=${ステータス名}
${コード}-${コード}=${ステータス名}

${コード} には 200404500 など,リターンコードを数値で設定し,${ステータス名} には以下の4種類から固定値を設定する.

  • OK
  • WARNING
  • CRITICAL
  • UNKNOWN

よって,以下のように設定できる.

--status 200=OK
--status 500=WARINNG
--status 200-499=OK
--status 400-599=CRITICAL

さらに --status オプションを複数設定することもできる.

--status 200=OK --status 500=WARINNG
--status 200=OK --status 400-599=CRITICAL

--status オプションのデフォルト値

なお,重要な「デフォルト値」は以下となる.ただし,ドキュメントには書いてなく,Go の実装を読んで確認したため,ドキュメントに書いてもらえると良さそう.正直言って,わかりにくかった.プルリクエストを送ることもできるけど,どに書くべきだろう?

  • < 400 なら OK
  • < 500 なら WARNING
  • それ以外 なら CRITICAL

検証環境

--status オプションの動作確認をするために,Sinatra で雑に API を書いた.指定したリターンコードを返すだけだけど,以下に app.rb の実装を載せておく.200 / 202 / 401 / 404 / 500 / 503 を返す.

require 'sinatra'

get '/200' do
  status 200
end

get '/202' do
  status 202
end

get '/401' do
  status 401
end

get '/404' do
  status 404
end

get '/500' do
  status 500
end

get '/503' do
  status 503
end

実際に curl で実行すると,適切にリターンコードを返せている.

$ curl -s -I http://localhost:4567/200 | grep HTTP
HTTP/1.1 200 OK

$ curl -s -I http://localhost:4567/202 | grep HTTP
HTTP/1.1 202 Accepted

$ curl -s -I http://localhost:4567/401 | grep HTTP
HTTP/1.1 401 Unauthorized

$ curl -s -I http://localhost:4567/404 | grep HTTP
HTTP/1.1 404 Not Found

$ curl -s -I http://localhost:4567/500 | grep HTTP
HTTP/1.1 500 Internal Server Error

$ curl -s -I http://localhost:4567/503 | grep HTTP
HTTP/1.1 503 Service Unavailable

検証

404 はデフォルトでは WARNING だけど,--status 404=OK を設定すると OK になる.

$ check-http --url http://localhost:4567/404
HTTP WARNING: HTTP/1.1 404 Not Found  - 0 bytes in 0.021076 second response time

$ check-http --url http://localhost:4567/404 --status 404=OK
HTTP OK: HTTP/1.1 404 Not Found  - 0 bytes in 0.010714 second response time

401404 もデフォルトでは WARNING だけど,--status 400-499=OK を設定すると OK になる.

$ check-http --url http://localhost:4567/401
HTTP WARNING: HTTP/1.1 401 Unauthorized  - 0 bytes in 0.004647 second response time

$ check-http --url http://localhost:4567/404
HTTP WARNING: HTTP/1.1 404 Not Found  - 0 bytes in 0.021076 second response time

$ check-http --url http://localhost:4567/401 --status 400-499=OK
HTTP OK: HTTP/1.1 401 Unauthorized  - 0 bytes in 0.010508 second response time

$ check-http --url http://localhost:4567/404 --status 400-499=OK
HTTP OK: HTTP/1.1 404 Not Found  - 0 bytes in 0.013790 second response time

404 はデフォルトでは WARNING だけど,--status 400-499=CRITICAL を設定すると CRITICAL になる.

$ check-http --url http://localhost:4567/404
HTTP WARNING: HTTP/1.1 404 Not Found  - 0 bytes in 0.009807 second response time

$ check-http --url http://localhost:4567/404 --status 400-499=CRITICAL
HTTP CRITICAL: HTTP/1.1 404 Not Found  - 0 bytes in 0.006045 second response time

検証(矛盾のある設定をした場合)

最後は個人的に気になって「矛盾のある設定」を検証してみた.具体的には --status 200=OK --status 200-599=CRITICAL--status 200-599=CRITICAL --status 200=OK のように 200 の設定を重複させてみた.OKCRITICAL のどちらになるのだろう?

結論としては「順番通りに優先される」となる.ようするに1個目の --status が優先される.実装を読んでもそうなっている.基本的にこんな設定はしないと思うけど,警告などは出なかった.

$ check-http --url http://localhost:4567/200 --status 200=OK --status 200-599=CRITICAL
HTTP OK: HTTP/1.1 200 OK  - 0 bytes in 0.026561 second response time

$ check-http --url http://localhost:4567/200 --status 200-599=CRITICAL --status 200=OK
HTTP CRITICAL: HTTP/1.1 200 OK  - 0 bytes in 0.007202 second response time

まとめ

  • 最近 Mackerel の check-http を使う機会があった
  • 使えるオプションを確認したところ --status をどう使えば良いのかわからなかった
  • 特定のリターンコードの監視結果を個別に設定するときに使えることがわかった

今年も「Mackerel アンバサダー」として,ブログを軸にアウトプットしていくぞ!