Mackerelのメトリックについて詳しく見てみた

こんにちは、こんばんは、きだぱんです。

皆さん、監視してますか？
今回はSaasの監視ソリューション、Mackerelについてのブログです。
Mackerelを使用する上で、最初に肝となってくるのがメトリックの値かと思います。CPUやメモリの使用率など、サーバのリソース情報を取得することで、どれだけの負荷がかかっているのか定量的に調査できるため、障害発生時の原因特定や対策を決めるための指標となります。
今回は、Mackerelで扱うことができるメトリックとmackerel-agentの標準機能により投稿されるシステムメトリックに焦点を当てブログを書いていきたいと思います。

それでは、いってみましょう！！

メトリックの種類

Mackerelで扱うことのできるメトリックはホストメトリック、サービスメトリックの大きく２種類あります。

ホストメトリック

• CPU使用率、メモリ使用量といったホストに関するメトリック
• 監査対象となるホストに紐づくメトリック
• ホストメトリックはさらに、システムメトリックとカスタムメトリックに分類される

サービスメトリック

• 特定のサービスに依らないメトリック
• APIから自由にメトリックを投稿できる
• 例えば...
  • サービスに登録された累計ユーザー数の推移
  • WebサイトのPV数の推移
  • ECサイトなどの受注件数や売上金額などビジネスにおけるKPI　など

サービスメトリックに関する投稿は、こちらに詳しく記載されています。

今回は、mackerel-agentの標準機能により投稿されるシステムメトリックについて解説していきます。

システムメトリック

システムメトリックは、ホストにインストールされたmackerel-agentの標準機能により投稿され、loadavg、cpu、memory、disk、interface、filesystemの6種類のグラフが表示されます。

この6種類の値の見方や考え方について見ていきます。

loadavg

loadavgとは、ロードアベレージのことです。ロードアベレージは、実行待ちのプロセスの数とディスクのI/O値のプロセスの数の合計値になります。
mackerel-agent を用いた場合、メトリックの取得元は/proc/loadavgの内容をパースすることで取得します。
また、Linuxコマンドのuptimeやwで確認ができます。

# uptime
 00:45:35 up 19:18,  1 user,  load average: 0.00, 0.01, 0.05
# w
 00:11:27 up 20:16,  1 user,  load average: 0.00, 0.01, 0.05
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
*****   pts/0    **.**.**.**.*     00:45    5.00s  0.00s  0.00s w

システム全体の負荷状況を表すものとして従来より用いられてきたため、この値を見ることは重要そうです。 システムの特性によっては一定の周期で瞬間的に処理が集中して値が増加することもあります。その場合、ロードアベレージが値以上になったから即座に問題視はしないほうがいいでしょう。
値を超えた時の傾向が、グラフ上で徐々に右肩上がりになっていれば、「実際に捌いている処理量」<「捌くべき処理総量」となってしまっているので、この状態を放っておくと、処理待ちプロセスが溜まり、処理が遅れてしまいます。
また、ロードアベレージだけで判断せず、マルチコアを考慮してloadavg/コア数を指標とするほうが、実際の負荷状況を測りやすい場合もあります。
Mackerelではmackerel-agent.confにて、

[plugin.metrics.multicore]
command = "mackerel-plugin-multicore"

と追記することで、確認ができます！

CPU

CPUは、演算処理装置であるCPUの使用率を表しています。
mackerel-agent を用いた場合、メトリックの取得元は/proc/statの内容をパースすることで取得します。 CPUはサーバの役割によって系統が異なるため、ロールごとの設定や閾値を調整する必要があります。
Mackerelでは種類ごとに細分化した使用率を確認できます。特に下記の四つは押さえておいたほうが良いでしょう。

• cpu.user カーネル以外が使用した時間の割合
• cpu.iowait I/O待ちによりアイドル状態であった時間の割合
• cpu.system カーネルが使用した時間の割合
• cpu.idle I/O待ちがなく、かつCPUがアイドル状態であった時間の割合

memory

memoryは、その名の通りメモリの使用状況を表します。
mackerel-agent を用いた場合、メトリックの取得元は、/proc/meminfoの内容をパースすることで取得します。 Mackerel では2018年のメモリ利用率の算出方法が変更以降、used + available = totalという前提に基づいており、usedの他にavailableのみが積み上げ表示されます。これは、近年のLinuxのメモリ利用の内訳が複雑化しており、buffersやcachedが必ずしも開放可能な領域とは限らなくなっているからです。

disk

diskは、ディスクの読み書きに関する、IOPS（1秒あたりのI/Oアクセス）の値です。 メトリックの取得元は、/proc/diskstatsの内容をパースすることで取得し、disk.*.reads.delta、disk.*.writes.deltaの値が描画されます。
ディスクの読み書きはデータベースやストレージ用途のサーバーで顕著に現れるため、その場合は注視すべきメトリクスです。
Linuxではsar、iostat、vmstat -dコマンドなどで確認できます。
また、公式チェックプラグイン集check-diskを利用することで、詳しく見ることができます。

interface

interfaceは、ネットワーク帯域の使用状況です。単位はKB/秒、txは送信、rxは受信です。
/proc/net/devの内容をパースすることで取得します。
クラウド環境ではネットワークの通信料が掛かる場合が殆どなので、その観点での監視を設定しておいたり、注視しておくことで、ベストプラクティスへつながると思います。

filesystem

filesystemは、ディスクサイズとその使用量を表すメトリックです。
dfコマンドの実行結果をパースすることで取得します。 ディレクトリ以下のサイズをチェックする場合はLinux上でduコマンドを使います。
Mackerelでは 将来予測機能としてlinearRegression(),timeLeftForecast()といった線形回帰の関数を利用でき、ファイルシステムの空き容量が枯渇するまでの残り時間を監視できます。

scale(timeLeftForecast(host(host_id, filesystem.drive.used), 3mo, 2000000000000), 1/86400)

例えば上記の式では、指定したホストに対して3ヶ月間の値を用いて線形回帰した値が、2000000000000byte(2TB)に達するまでの秒数が得られます。

ここまでで、システムメトリックについて紹介してきましたが、mackerel-agent のソースコードは以下で公開されていますので、こちらも合わせてご確認ください。

まとめ

Mackerelのシステムメトリックについての見方等を簡単にまとめてみました。
これらを理解した上で障害発生時の原因特定や対策を決めるための道筋として考えていただければと思います。
今回ご紹介したものは、標準機能に過ぎないのでカスタマイズして一つ一つに合った監視をぜひ行ってみて下さい！