A Deep Dive into Kubernetes Metrics — Part 2

第二章 USEメソッドとnode exporter メトリクス

TL;DR

この第二章はkubernetesメトリクスについてのmulti-partシリーズです。ここではnode_exporterがレポートしたときのnode メトリクスについてより詳しい話をしようと思います。まず初めに簡単にどれが重要なメトリクスなのかを見極める方法をお教えしましょう。それから、core node メトリクス（核になるnode メトリクス）について調べていきましょう。core node metricsとは、CUP,メモリー、使用率の観点から見たネットワークとディスク、サーチュレーション、エラーのことです。
もし、この章で分からないことがあれば、第０章イントロダクションにもう一度戻って、そちらを読んでからまたこの章に戻ってきてください。

node_exporter

前回の説明では、The node_exporterというPrometheusプロジェクトについてお話しました。node_exporterから訳約1000個のユニークな連続性を持ったものが排出されるのですが、どのメトリクスに注目をすべきか判断がつかないときがあります。システム上で重要なメトリクスはどれか？場合によれば判断がとても難しいときがあります。

Quick Detour — Simplifying Abstractions

分散システムのデバッグを成功させるには、多くのドメインを深く理解する必要があります。単純な抽象化は、エンドゲームではありません、しかし、彼らはあなたのトラブルシューティングの努力を開始する場所です。

では、メトリクス周辺のアブストラクションのメソッドをいくつか見ていきましょう。そうすることで、node metricだけではなく、すべてのKubernetes metricsがきちんと体系立てて理解できるようになります。これらのアブストラクションは、４つのゴールデンシグナル、USEメソッド、REDメソッドです。

The Four Golden Signals

Googleが用意してくれた４つのゴールデンシグナルのノーションがあるSREハンドブックは本当にすばらしいんです。

モニタリングにおける４つのゴールデンシグナルは、レイテンシー、トラフィック、エラー、サーチュレーションです。自分のユーザーフェイシングシステムの４つのメトリクスを測定することができるのであれば、この以下の４つに注目するようにしてください。

Latency（レイテンシ） — リスエストをサービスするのにかかる時間

Traffic（トラフィック） — システムにどれくらいのデマンドが置かれているのかの測定

Errors（エラー） — 失敗するリクエストの確率

Saturation（サーチュレーション） — サービスがどれくらいいっぱいになっているか

私が初めて、システム内のメトリクスへこのゴールデンシグナルをアプライした時、どのようにシステム内のアプリケーションや個々のノードにアプライされるのか、またいくつかのタームに戸惑いました。CPUのトラフィックやレイテンシーとは一体何なのでしょうか。Kafka topicのサーチュレーションとは？アプリケーションのサーチュレーションを明確にするために、アプリケーションが使う、基本的なリソースのサーチュレーションを説明する必要があります。その基本的なリソースとは何でしょうか。リソースをモニタリングするってどうやるのか？ その答えはUSEメソッドにあります。

USEメソッド

システム内でリソースを参照した時のエラーやサーチュレーション、使用率に関しての見方についてはブレンダン・グレッグ氏がとても分かりやすく解説してくれています。

グレッグ氏が示した定義

Resource（リソース）：全てのフィジカルサーバーの機能的コンポーネント（CPU,ディスク、バズなど）

Utilization（ユーティライゼーション）：リソースがサービス動作中でずっと動作し続けているときの平均時間

Saturation（サーチュレーション）：リソースがサービスできない余分な作業を行う度合い (キューに入れられることが多い)

Errors（エラー）：エラー発生数

Unixシステムのコンテクストの中のエラーやサーチュレーション、またユーティライゼーションを示しているのはこのメトリクスだと提示してくれています。参考にしてください。

この記事の後半では、Kubernete nodeをより分かりやすくするためのUSEメソッドについて説明します。

USEメソッドはリソースや実際ハードに制限がかかっているフィジカルなものにターゲットをむけています。リソースじょうで動作しているソフトウェアはまるで未完成の絵のようです。そして、そこにREDメソッドが入ってきます。

REDメソッド

トム・ウィルキーが作り上げたREDメソッドとは

Rate（レート）：１秒ごとのリクエストの数

Errors（エラー） ： 失敗したリクエストの数

Duration（デュレイション）：リクエストに費やした時間

一見、REDメソッドはUSEメソッドと４つのゴールデンシグナルにとても似ているように見えます。では、USEとREDはどのようにして使い分けるでしょうか？

“The USE method is for resources and the RED method is for my services”
— Tom Wilkie

なるほど！kubernetes システムの中のメトリクスに簡素化したアブストラクションをアプライする基準枠が分かりましたね！今から、私がお伝えするいくつかのメトリクスのシステム内のリソースについての説明です。その他にもリソースを使ったアプリケーションのメトリクスの説明もします。

Node Metrics and the USE Method

はい！ちょっと寄り道をしましたが、また本来のテーマに戻りましょう。今までの説明でどのメトリクスに注意を払うべきか分かりましたね。でもそれはリソース？それともアプリケーション？クラスターの中のノードにはリソースがあります。Kubernetesのクラスターの中にある一番重要なノードが提供するリソースはCPU,メモリー、ネットワーク、ディスクです。それでは、それらのノードにUSEメソッドをアプライしてみましょう。

CPU Utilization, Saturation, and Errors

node_exporter metric node_cpuは10個全てのCPUモードのための、それぞれのコアにかかる全部のCPUにかかった時間を記録します。そのCPUモードとはuser, system, nice, idle, iowait, guest, guest_nice, steal, soft_irq、irqです。もう少し詳しくお話しましょう。

Kuberneteクラスターの中のホストによるユーティライゼーションのCPU量を計算するため、idle, iowait, guest, guest_niceを除いたすべてのモードの合計を出します。

PromQLは以下のようになります。

sum(rate(
         node_cpu{mode!=”idle”,
                  mode!=”iowait”,
                  mode!~”^(?:guest.*)$”
                  }[5m])) BY (instance)

このクエリについて

・PromQLでは、同じラベル上に多様なモディフィアが存在する時、そのモディフィアはまとめてANDされます。

・全てのnode_CPUの連続体はCPU秒数を意味し、計測器として機能します。だから、rate0を使用し、１秒ごとの時間を計測する必要があります。

・各nodeが使用しているコアの数量の最終結果が表示されます。

サーチュレーションのためにnode_exporterが表示してくれるメトリクスはUnixロードの平均値です。ロードの平均値は実装しているプロセスの数と実装待ちのプロセスの数です。念のためもう一度言いますが、ブレンダン・グレッグ氏がlinux load averagesについて詳しく書いた論文がありますので、ぜひ参考にしてください。

node_load1, node_load5 and node_load15 は1, 5 と 15 min ロードアベレージを意味しています。このメトリクスは、標準のもので、既に自分用に平均化されています。自動で動作するメトリクスのように、どのくらいのCPUがnodeに存在するかを知るのは、あまり重要なことではありません。ロードアベレージが１０って良いんですか？悪いんですか？ それは一概には言えません。クラスターの中にあるCPUの数でロードアベレージを割ってみると、システムのCPUサーチュレーションのたいだいの値が求められます。

node_exporterは直接node CPUのカウントをエクスポートしません。でももし上に記したCPUの中のどれか一つでもカウントしたら、nodeによるCPUのカウントができます。

count(node_cpu{mode="system"}) by (node)

パーセントで表されたnode上のCPU数による node_load1metricをノーマライズできますね。

sum(node_load1) by (node) / count(node_cpu{mode="system"}) by (node) * 100

Memory Utilization, Saturation and Errors

メモリーユーティライゼーションとサーチュレーションはnodeの物理 メモリ の量が分かる時にはそれを推測するのはいくらか簡単なように見えます。

念のためもう一度言いますが、これは決して簡単に理解できることではありません。node_exporterは一緒に動作する43のnode_memory_* metricsを表示してくれるんです！

Linuxシステム上の使用可能なメモリーの量は報告された“フリー”のメモリーメトリクスではありません。Unixシステムはコード（バッファ）をシェアしたり、ディスクページをキャッシュするアプリケーションによって使われていないメモリーにとても依存しています。

だから使用可能なメモリーの1つの基準は

sum(node_memory_MemFree + node_memory_Cached + node_memory_Buffers)

となります。

最新のLinux Kernel(3.14以降)はより優れたメモリーメトリクスをエクスポートします。

node_memory_MemAvailable.そしてそれをnodeの使用可能なトータルメモリで割ると使用可能なメモリのパーセンテージの値が算出されます。１から引いてnode memory utilizationを割り出します。

1 - sum(node_memory_MemAvailable) by (node) 
/ sum(node_memory_MemTotal) by (node)

では、次にノードメモリサーチュレーションについてです。何度も言いますが、これはとても難しい内容なのでしっかり読んでください。Unixシステムには“バーチャルメモリ”の制限はありません、というのが理論的な話ですよね。もしメモリーシステムに多くのデマンドがある場合、オペレーションシステムは最近使われていない“page to disk”メモリページになります。これを”going swap”と呼んでいます。これは避けたいですよね。

Nodeがどれくらいのページングをしているのかを見ておくことで、メモリーサーチュレーションの測定ができます。 node_exporter metrics node_vmstat_pgpgin と node_vmstat_pgpgoutは自分のパソコンのnodeのパージングアクティビティ量を表示します。これは、メモリページングが linux 共有ページキャッシュに依存するあらゆるデータ多用のための通常のアクティビティであるため、この目的のための不完全なメトリックです。

Kuberneteのおかげでクラスターの中で使用されているメモリーの量を制限するその他のツールを使えるようになります。ネームスペースクオータやコンテナリソースリクエストや制限は、もし正常に実装されたら、nodeがswapしないように確実に動いてくれます。そのことに関しては後ほど詳しく述べます。

メモリーエラーに関して言えば、いくつかのハードウェア上ではlinuxとnode_exporterはEDAC,エラー検出 とエラー修正を通してECCメモリー上に報告する機能を持っています。メトリクスは以下のようになります。

node_edac_correctable_errors_total
node_edac_uncorrectable_errors_total
node_edac_csrow_correctable_errors_total
node_edac_csrow_uncorrectable_errors_total

このメトリクスは自分がアクセスしたことのあるパソコンでは利用できません。

Disk Utilization, Saturation, and Errors

ディスクユーティライゼーションとサーチュレーションについて話をするとき、この二つについて考慮する必要があります。ディスクキャパシティーとディスクのスループットの２点についてです。ディスクキャパシティーとはディスクに入るデータ量のことです。言い換えれば、ディスクがどれくらい空かもしくはデータが詰まっているかということです。そしてディスクスループットとは、１秒にどれくらいのデータをディスクに書き込めるかということです。ディスクキャパシティーのサーチュレーションとユーティライゼーションはそんなに難しくありません。単純にパーセンテージで表された利用可能な、もしくはその反対や何パーセンテージフリーのバイト数を計測するものです。

sum(node_filesystem_free{mountpoint="/"}) by (node, mountpoint) / sum(node_filesystem_size{mountpoint="/"}) by (node, mountpoint)

ディスクスループットのユーティライゼーションとサーチュレーションは少し難しくなります。使用しているディスクが回転する磁気ディスク、ソリッドステート、RAID、ネットワークに接続しているもの、ネットワークからブロックされているものの場合は、その他のパラメータにも注意を払わなければいけません。ネットワークを含めてサーチュレーションとなるとkernelに接続不可能な基本的なハードウェアの特徴を知らずして計算するのは至難の業です。

node_exporterは, デバイス、バイト、オペレーション、統合されたオペレーション、時間や読み込みや書き込みの両方のためのセクターや時間ごとにエクスポートします。加えて言えば、現在フライト中のIOオペレーション node_disk_io_nowとIO time node_disk_io_time_ms, io time node_disk_io_weightedもです。

Kernel docs によると

Field 11 — weighted # of milliseconds spent doing I/Os
This field is incremented at each I/O start, I/O completion, I/O
merge, or read of these stats by the number of I/Os in progress
(field 9) times the number of milliseconds spent doing I/O since the
last update of this field. This can provide an easy measure of both
I/O completion time and the backlog that may be accumulating.

となります。

ディスクスループットは本当に難しい内容で、モニターするために選んだメトリクスはクラスターの中のハードウェアによるし、実装しているワークロードのタイプによって変わってきます。

Network Utilization, Saturation and Errors

最後にネットワークのお話です。もう一度言いますが、node_exporterを詳しく知ることで、一体nodeが何をしているのか本当に詳しく理解できるようになります。

自分のワークロードによって変わりますが、あなたはもっとトラフィックの送受信に興味を持つようになるでしょう。それでは今からユーティライゼーションを送受信の合計であると定義します。このクエリはnodeによる全てのネットワークインターフェースの一秒ごとのバイトを表示します。

sum(rate(node_network_receive_bytes[5m])) by (node) + sum(rate(node_network_transmit_bytes[5m])) by (node)

基本的なネットワークキャパシティーへのアクセスがないサーチュレーションは、定義づけするのが難しいです。なので、ネットワークサーチュレーションのためのプロキシとしてのドロップされたパケットを使ったらよいですね。

sum(rate(node_network_receive_drop[5m])) by (node) + sum(rate(node_network_transmit_drop[5m])) by (node)

エラーは node_network_receive_errs とnode_network_transmit_errsと報告されます。

まとめ

Node_exporterプロジェクトはKubernetクラスターの中のnode上のリソースについての豊富な情報にエクスポートします。ユーティライゼーション、サーチュレーション、エラーという観点を通してそれらのリソースを見てみることで、キャパシティーのプランニングやリソースの制限についての研究の糸口になればと思います。cAdvisorによるコンテナメトリクスについての報告を読めば、これらのコアリソース、CPUメモリー、ネットワーク、ディスクについて詳しく書かれています。Orangesys.ioでは、アプリケーションを快適に利用できるように配慮しております。kuberneteクラスターの内部動作を明らかにするお手伝いをぜひ私たちにおまかせください。