Monitoring Linux Processes using Prometheus and GrafanaーPart 1
Prometheus とGrafanaを使ってのLinuxプロセスのモニタリングー第一章
Prometheus とGrafanaを使ってのLinuxプロセスのモニタリングをする方法を解説します。記事が長いので3回に分けて投稿致します。今回が第一回目です。今回はUnix Process Monitoring の基本的なことや、Monitoring Architectureの詳しい説明をします。
Linuxのシステムアドミニストレーターエンジニア、DevOpsエンジニア、どちらの人も自分のサービス上でパフォーマンスをトラッキングするのに多くの時間を割いているのは事実ではないだろうか。
何が問題なのか本当の原因が何も分からずにとてもゆっくりと走っているインスタンスがあるときがあります。
topもしくはhtopのような実装中のリモートコマンドからブロックするunresponsive(応答しない)インスタンスがある場合もあります。
自分のサーバー上に妨げとなるような単純な要素があるかもしれませんが、すぐに簡単にその原因を突き止めることはできません。
もし、通常のパフォーマンスや個別のプロセスのトラッキングをよりやりやすくしてくれる完璧なダッシュボードがあればどうでしょうか？
こちらをご覧ください。http://grafana.devconnected.com/d/nZMDMoiZk/grafana-top?orgId=1&refresh=5s
このチュートリアルの目的はLinux sysadminのための完全なモニタリングダッシュボードを作ることです。
このダッシュボードは分散したアーキテクチャーに対するたくさんのインスタンスを完全にカスタマイズでき、スケーラブルな異なるパネルを持つダッシュボードです。
目次
- 今回学ぶ内容
- Unix Process Monitoring の基本
- Monitoring Architectureの詳細
- 異なるツールのインストール
- a –Pushgatewayのインストール
- b — Prometheusのインストール
- c — Grafanaのインストール
- 取得するメトリックへ bash スクリプトを構築する
- Grafanaを伴う素晴らしいダッシュボードの構築
- 1 — Rounded Gaugesの構築
- a — 現在の全体のCPU利用率の取得
- b — 平均的なCPU使用率の取得
- 2 — Horizontal Gaugesの構築
- 3 –Vertical Gaugesの構築
- 4 — Line Graphs（線グラフ）の構築
- おまけ : ad hocフィルターを使ってデータを参照する
- まとめ
今回学ぶ内容
具体的な技術内容をお話する前に、今日学ぶことの全体図を簡単に見てみましょう。
- Unixシステム上の現在のモニタープロセスパフォーマンスの最先端のモニタリング方法を理解する
- 最新バージョンのPrometheus v2.9.2、 Pushgateway v0.8.0 、Grafana v6.2のインストールの方法
- 簡単なPushgateway にメトリックをエクスポートするbashスクリプトの構築
- 「Gauge」や「Bar Gauge」のような最新のパネルを含む完全なGrafanaダッシュボードの構築
- おまけ：個々のプロセスやインスタンスをトラック（追跡）するためのad-hocフィルターの実装
さて、全体的な内容を観たこところで、さっさと次に進みましょう。まず、Unixシステムでは現在どういうものがあるのかをご紹介したいと思います。
Unix Process Monitoring の基本
Unixシステムのプロセスモニタリングと言えば、多くのものを思い浮かべると思います。
一番人気なのが「top」です。
topがあれば、現在のCPU使用率や現在のメモリー使用率、またここのプロセスのようなメトリックなどシステム上の完全な全体的なパフォーマンスメトリックを見ることができます。
このコマンドはsysadminsでは広く使われています。そして、おそらくパフォーマンスのボトルネックがシステム上で検索されたとき一番最初に走るコマンドです（もちろん、アクセスできていればの話ですが）
topコマンドは既にかなり読みやすくなっています。しかしすべてをさらに読みやすくしたコマンドがあります。それがhtopコマンドです。
htopがあると、topとしての同じ機能のセット（CPU、メモリー、アップタイム…）が利用可能ですが、もっとカラフルで優れた方法で表示されます。
Htopを使うと、現在のシステムの使用率を反映するgaugesも見られます。
topとhtop、この二つのコマンドの存在を知っているのにも関わらず、まだ他のモニタープロセスの方法を構築しようとするのはなぜでしょうか？
その主な理由はシステムの可用性にあります。オーバーロードされたシステムの場合、自分のインスタンスへのリモートアクセスや物理的なアクセスがありません。
プロセスモニタリングを外面化することにより、マシンにアクセスすることなく不具合の原因を分析することが可能です。またその他の理由としては、そのプロセスはkernelそれ自身により生成されてそれと同時に全部killされるということが挙げられます。
この場合、topコマンドを走らせることで、自分のシステムでだれがパフォーマンスの問題を起こしているのかを突き止めるのが遅すぎてしまうため、何も情報が得られません。
何がkillされたのかkernelログをくまなく調べる他ありません。
モニタリングダッシュボードを使って、簡単に戻って、どのプロセスが問題を起こしているのかを見ることができます。それでは、なぜこのダッシュボードを構築した方がいいかその理由が分かったところで、それを構築するためにきちんと配置されたアーキテクチャーを見ていきましょう。
Monitoring Architectureの詳細
今から使うアーキテクチャーを見ていく前に、以下のソリューションを使いたいと思っています。
- Resource cheap : つまり、ホスト上のたくさんのリソースを消費しないようにすること；
- Simple to put in place :インスタンスを生成するのに多くの時間が不要なソリューション；
- Scalable : 他のホストをモニターするのであれば、素早く効率的に行えます。
このチュートリアルでは上記のポイントを覚えておいてください。
今日使う詳しいアーキテクチャーはこちらです：
私たちのアーキテクチャーでは4つの異なるコンポーネントを使わなければいけません。
- Pushgateway へメトリックを定期的に送信するためのbash スクリプト;
- Pushgateway: ターゲットとして個別のスクリプトに使用されるメトリックキャッシュ;
- Prometheus:,メトリックの保存のための時系列データベースのインスタンスを生成すること。Prometheusは Pushgateway をターゲットとして取得し保存する目的でスクレ―ピングする
- Grafana: PromQLクエリを通してPrometheusからデータを取得したり、plotするためのダッシュボードモニタリングツール。Prometheusに詳しい方であれば、すでにPrometheusがHTTPインスタンスがエクスポーズしたメトリックをスクラップし、それを保存するということをご存じの方もいると思います。
我々のケースでは、bashスクリプトのライフプランはとても短く、Prometheusに対してHTTPインスタンスを一切エクスポーズしません。これがPushgatewayを使う理由なのです。Pushgatewayは、短命のジョブに対して設計されたもので、スクリプトから受け取ったメトリックをキャッシュし、Prometheusに対してエクスポーズします。
Orangesys.ioでは、kuberneteの運用、DevOps、監視のお手伝いをさせていただいています。ぜひ私たちにおまかせください。
