こんばんは。
Mastodon インスタンス の1つである「handon.club」では,昨日より外形監視 を始めました。構成は,Prometheus+Grafanaのオンプレ構成です。
今日は,今回構築した「handon.club」における外形監視の例を使って,Mastodon サーバの外形監視方法についてご紹介したいと思います。なお,日本語で設定方法を解説している記事が見つからなかったため,具体的な設定の方法についても触れたいと思います。
外形監視
本投稿でいう外形監視とは,「HTTPレスポンス」に関する統計情報(メトリクス) を指します。一般に外形監視とは,サーバのCPU利用率やディスクI/Oといった内部の情報ではなく,サーバの外部から見える範囲での情報を使った監視のことです。よくあるping 監視もそのうちの1つと考えますが,今回はHTTPレスポンスに限った話をします。
Mastodon インスタンス のhandon.clubにおける外形監視についてですが,特に2つのフロントエンドサーバについて,以下の観点の監視が必要だと考えています。
HTTPレスポンスのステータスコード (200 OKが返ってくるか)
HTTPレスポンス速度
そこで,以下に示すような監視システムを構築することで,要件を満たす外形監視を実現しました。
全体の構成
本章では,今回構築した監視システムの全体概要を説明します。
Prometheus+Grafanaによる監視システム構成
まずはじめに,監視方式として,makarelやdatadogといったクラウド サービスを使うか,それとも自分で監視サーバを構築するかという2択を選択しなくてはなりません。しかし,前者のクラウド サービスを使う場合,当然ながら無料で使える範囲には限りがあります。残念ながら私の要件を満たすためには,有料プランの契約が必要となるようでした。どうせお金を払うならば,ということで,今回は自分で構築する道を選びました。
今回,監視サーバの基幹には,Prometheusというサーバ監視ツールを使いました 。Google におけるサーバ監視のノウハウが生かされているとの噂で,最近人気上昇中のOSS 監視ツールです。pull型(監視対象に定期的にメトリクスを取得にいく方式)が採用されている点が最大の特徴です。
このPrometheusは,監視サーバそのものに加え,監視対象サーバ側で動作させる「exporter」と呼ばれるプログラムから構成されています。pull型の監視ソリューションであるPrometheusは,監視サーバそのものがこのexporterに対してメトリクスを要求することで,必要な情報を集めるしくみになっています。exporterは非常に多くの種類が用意されており,監視したい項目に応じて自由に選ぶことできます。今回はそのexporterの中でも,外形監視を実現するために用意されている「blackbox -exporter」 を使って,外形監視を行いました。
一方Grafanaは,様々な情報をグラフィカルに表示する可視化ツールです。有名なので詳細は割愛します。
事前準備
以下の作業は行われているものとします。
Mastodon サーバを構築済みであること
Prometheus,Grafanaを構築済みで,それらの連携設定が完了していること
実際にMastodon サーバで外形監視を行おうとしている方で,もし上記の作業を実施していない方がいらっしゃいましたら,他の方の書かれた記事を参照してみてください。ググる とたくさん出てきます。
また,今回のサーバ環境は以下の通りです。
Host OS: CentOS 7
Prometheus: 2.6.1
Grafama: 5.4.3
blackbox -exporterは,ICMPおよびHTTPによる外形監視を実現することのできるPrometheus用exporterです。通常のexporterは監視対象サーバで動作させますが,外形監視の性質から考えて,このexporterは監視サーバ本体で動作させるのが一般的 です。動作のイメージを以下に示します。この図では,先ほどの図に比べて,exporter名を正確に記載しています。
システム概略図(exporter名入り)
では,導入手順を説明します。まずはじめに,以下のようにexporterを適当な場所に配置する必要があります。exporterはバイナリが配布されていますので,導入はとっても簡単ですね。
$ cd /usr/local/src/exporter/
$ sudo wget https://github.com/prometheus/blackbox_exporter/releases/download/v0.13.0/blackbox_exporter-0.13.0.linux-amd64.tar.gz
$ sudo tar -zxvf blackbox_exporter-0.13.0.linux-amd64.tar.gz
$ sudo ln -s blackbox_exporter-0.13.0.linux-amd64.tar.gz/ blackbox_exporter
ただし,バージョン,ディストリビューション ,プラットフォームは環境等に合わせて設定してください。
Releases · prometheus/blackbox_exporter · GitHub
さて,一度起動してみましょう。
$ cd /usr/local/src/exporter/blackbox_exporter
$ ./blackbox_exporter
level=info ts=2019-01-28T15:03:15.017239345Z caller=main.go:215 msg="Starting blackbox_exporter" version="(version=0.13.0, branch=HEAD, revision=1cfb7512daa7e100abb32037996c8f805990d813)"
level=info ts=2019-01-28T15:03:15.019513325Z caller=main.go:228 msg="Loaded config file"
level=info ts=2019-01-28T15:03:15.019660332Z caller=main.go:332 msg="Listening on address" address=:9115
正常に起動しているっぽいですね。また,9115ポートで待ち受けていることも分かります。
さて,コマンドで起動することが確認出来たら,Linux にサービスとして登録し,常時動かせるようにしましょう。
$ sudoedit /usr/lib/systemd/system/prometheus-blackbox-exporter.service
[Unit]
Description=Prometheus's client - blackbox exporter
Documentation=https://github.com/prometheus/blackbox_exporter
[Service]
Type=simple
ExecStart=/usr/local/src/exporter/blackbox_exporter/blackbox_exporter --config.file=/usr/local/src/exporter/blackbox_exporter/blackbox.yml
[Install]
WantedBy=multi-user.target
$ sudo systemctl daemon-reload
$ sudo systemctl enable prometheus-blackbox-exporter
$ sudo systemctl start prometheus-blackbox-exporter
$ sudo systemctl status prometheus-blackbox-exporter -l
● prometheus-blackbox-exporter.service - Prometheus's client - blackbox exporter
Loaded: loaded (/usr/lib/systemd/system/prometheus-blackbox-exporter.service; disabled; vendor preset: disabled)
Active: active (running) since 火 2019-01-29 00:03:23 JST; 1min 15s ago
Docs: https://github.com/prometheus/blackbox_exporter
Main PID: 31928 (blackbox_export)
CGroup: /system.slice/prometheus-blackbox-exporter.service
└─31928 /usr/local/src/exporter/blackbox_exporter/blackbox_exporter --config.file=/usr/local/src/exporter/blackbox_exporter/blackbox.yml
ここで注意点です。.service
ファイル中に呪文のように Restart=always
と書く方がいらっしゃいます(自分もそうでした)。しかし,このblackbox -exporterについては, Restart=always
を設定するとうまく動きません。詳細な原因までは追っていませんが,再起動すると「前回の終了から次の起動までの時間が短すぎる」という旨のエラーメッセージが表示されてうまく起動しないようです。
ちなみに,実行時にblackbox.yml
という設定ファイルを指定してますが,この設定ファイルは私はデフォルトのままいじっていません。
これでblackbox -exporter側の設定は完了です。
Prometheus側の設定変更
実際に外形監視を行うURLなどはPrometheus側の設定にて行います。設定は,
blackbox -exporterのドキュメントを参考にしました。具体的には,prometheus.yml
に以下の記述を追加しました。
$ sudoedit /path/to/prometheus.yml
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: 'blackbox'
scrape_timeout: 10s
metrics_path: /probe
params:
module: [http_2xx]
static_configs:
- targets:
- https://handon.club/ # Web Server
- https://handon.club/api/v1/timelines/public # REST API Server
- https://media.handon.club/xxxxxxx # Media Server
labels:
group: 'response'
relabel_configs:
- source_labels: [__address__]
target_label: __param_target
- source_labels: [__param_target]
target_label: instance
- target_label: __address__
replacement: 127.0.0.1:9115
targets
配下に監視対象のURLを記載しているところがポイントです。私は以下の3つを監視対象としました。
<Mastodon -host>
<Mastodon -host>/api /v1/timelines/public
<Mastodon -media-host>/<適当な画像のpath>
この監視対象URLをなぜこのように設定したかについて解説したいとおもいます。まず,1つめの2つめの違いについてです。
1つめはWebページそのものを,2つめはAPI をコールしてTLを取得しています。1つめのMastodon のトップページでは,FederationまたはLocalのTLが表示されているため,1つめと2つめの違いは一見,API を間接的にコールするか直接コールするかの違いしかないように思えます。しかしながら,1つめのトップページについては,HTTPレスポンス上TL表示がすべて完了する前に「200 OK」を返してしまうのです。つまり,HTTPレスポンスを監視するblackbox -exporterでは,1つめのURLだけを監視すると,TL表示に関するレスポンスは監視出来ていないことなります 。例えばTLを格納しているpostgresが落ちている場合も正常と判断してしまうのです。これは問題です。そこで今回は,認証も不要でかつTLを取得出来る,public TLのHTTPレスポンスを監視することにしました。
次に3つめについて,なぜルートではなく,適当な画像のpathを指定しているのか説明します。
handon.clubでは,画像サーバのみ別のサブドメイン (media.handon.club)を使っています。しかし,素直にmedia.handon.clubのルートにアクセスすると,「401 Forbidden」が返ってくる仕様となっており,これでは正常に動作しているかどうか分かりません。そこで,適当な画像のURLを監視対象とすることで,HTTPレスポンスが正常である(=サーバがダウンしていない)ことを監視することにしました。
Grafana側の設定
ここまできたら,あとはGrafanaでかっこいい見た目を設定するだけです。
HTTPレスポンス時間
まずはレスポンス時間(レスポンスタイム)を測定します。メトリクスに以下を入力します。
sum(probe_http_duration_seconds) by (instance)
"sum" について補足します。probe_http_duration_secconds
には,実際には以下に示すようないくつかの要素があります(このスクリーンショット は,GrafanaではなくPrometheusの画面です)。
HTTPレスポンス時間といえば大半はProcessingなのですが,Resolveなどの時間もきちんと記録することが可能で,それぞれ個別に計測されています。すごいですね・・・。しかし,ユーザの体感時間をメトリクスとして記録しておきたかったため,今回の監視対象はProcessingだけではなくResolveも含めた合計値とする ことにしました。そのため,"sum"が付いています。
実際の表示例はこんな感じです。
HTTPステータス
HTTPサーバが落ちていないか(200を返しているか)を監視します。たとえば,成功しているサーバの数を表示するには,メトリクスに以下を入力します。
count(probe_success)
これだけだと芸が無いですね。そこで,今回は3つのサーバを監視していることから,以下の様に設定を変え,Availabilityとして%表示するようにしてみました。
(count(probe_success) / 3.0) * 100
その結果,他の監視項目と併せて,以下の様な良い感じのダッシュ ボードが出来ました。
Grafanaダッシュ ボードの例
完全に余談ですが,Mastodon 自体はStatsDに対応しているので,MastodoサーバにStatsDのexporterを入れることで監視できる項目が大幅に増えます。例えば,sidekiqのキュー状態についてもPrometheusで取得できるようになりました。これが結構良くて,以下3つを横並びで監視することができるようになりました。
node_exporterによるホストのCPU/MEM状態
blackbox -exporterによるHTTPレスポンスタイム
statsd_exporterによるsidekiqのキュー状態
分かっていないこと
以下は,監視したいのですが,やり方が分かっておらず監視できていないメトリクスです。引き続き調査したいと思いますが,もし経験のある方がいらっしゃれば是非教えてください・・・。
Streamingサーバのレスポンス監視
StreamingサーバはTCP コネクションが貼りっぱなしとなるので,レスポンスタイムという概念がない? 何をどうやって監視すべきなのか一度考えたい。
Conohaのオブジェクトストレージの残量
もはや外形監視関係ない。
たぶんexporterを自作してconohaのREST API を叩けばよい。ただし認証周りの実装がよく分からない。。
おわりに
今日は,PrometheusとGrafanaを使って,Mastodon サーバのHTTPレスポンス外形監視を実現する方法をご紹介しました。すでに活用していた他のexporterについても,また時間のあるときに解説記事が書ければいいなと思います。
さて,handon.clubについての話です。このダッシュ ボードは現在,管理者である私しか見ることができません。しかし今回構築したGrafanaでは,REST API によるデータ公開が可能ですので,将来はユーザ全員にステータス監視ページを公開できるよう準備をはじめています。イメージはTwitter みたいな感じですかね。レスポンスタイムも公開出来ればいいかなと思っています。
api.twitterstat.us