Monitoring a server cluster using Grafana and InfluxDB（Part1)
GrafanaとInfluxDBを使ったサーバークラスターのモニタリング 第一章
今回はGrafanaとInfluxDBを使ったサーバークラスターのモニタリングについての記事です。二回に分けてお送りします。今回は第一回目です。高可用性クラスターアーキテクチャーなどについて説明しています。
毎月60億ものリクエスト。この数はあなたにはものすごい数に思えますか？これは、デベロッパーなら誰でもしっている StackOverflowというとても人気のあるウェブサイトで一か月にくるリクエストの数です。
二つのHAProxyサーバーと９つのウェブサーバーでStackOverflowは構成されていて、高可用性サーバークラスタ（HAサーバークラスタ）として知られている有名なしっかりとしたアーキテクチャーを実装しています。
よりマイナーなスケールでは、このようなアーキテクチャーは多くの企業によって実装されており、ハードウェアに欠陥がある場合においてでさえ、サービスの高可用が確認されています。しかし、サーバーがダウンした場合、そのサーバーを早く元に戻すために効率的にそのことを知らせてくれる方法はないのでしょうか。
今回は、InfluxDB と Telegrafを使った完全なるサーバークラスターのGrafana dashboardモニタリングを構築する方法をご紹介したいと思います。
I — About High-Availability Clusters
ダッシュボードの開発に入る前に、簡単にhigh-availability clusters（高可用性クラスター）について簡単にお話しておきたいと思います。何のために使われ、なぜそれらをモニタリングしなければいけないのか。（エンタープライズアーキテクチャーについてよくご存じの方はこの部分は呼び飛ばしてください）
high-availability clusters（高可用性クラスター）はサービスに永久に可用で冗長性を持たせる方法で設計されたサーバーのグループのことです。
シンプルなウェブアプリケーションを構築しているとします。ローンチでは、以日に何千ものページ閲覧のトラフィックや、トラブルもなくちゃんとしたHTTPサーバーを扱うことのできるロードを取得します。突然、トラフィックが一日に百万まで急増したとします。この場合、基本的なHTTPサーバーはロードを自分ではコントロールできず、リソースの追加が必要になります。
この問題の解決策が HA cluster architecture（高可用性クラスターアーキテクチャー）なのです。
HTTPリクエストが受け入れられた時、そのロードバランサーは、ロードが同じようにクラスターの中でわけられたということを確認する適切なノードへのリクエストをプロキシ（言い換えれば、転送）します。ロードバランサーは異なる種類のテクニックを使って、どのノードを送るのか決めます。しかし、我々のケースでは重みのつかないラウンド・ロビン コンフィグレーションを使います。つまり、リクエストが最初のサーバーに送られ、それから二番目のリクエストが送られるような形です。選択するノードに関して優先順位は付けられません。
それでは、技術的な用語の説明が終わったところで、モニタリングシステムの実装に移ります。
II — Choosing The Right Stack
このプロジェクトのために、スタンダードのカーネル搭載の Xubuntu 18.04を使います。
サーバークラスターのモニタリングのためには正しいツールを選ぶ必要があるのです。リアルタイムでの可視化のためにはGrafana v6.1.1を使用します。
モニタリングをするために、GrafanaのためのデータソースとしてInfluxDB 1.7 を選びました。というのも、これはGrafanaにとってとても信頼性の高いデータソースだからです。InfluxDBのためのメトリックを収集するために、Telegrafを選びました。これは、InfluxDataが作ったplugin-server driven agentです。このチュートリアルでは先ほどご紹介したツールのインストール方法は説明しません。それぞれのドキュメンテーションで分かりやすく解説してくれているからです。
注意：このチュートリアルで使っているものと同じバージョンのツールを使うようにしてください。このようなツールはよく変更されることがあり、この記事で使われたものの機能が変更されている場合もあります。
III — Setting Up A Simple HA Cluster
HAクラスターをモニタリングするのに、シンプルなバージョンンのものをNGINX v1.14.0 と 3 Node HTTP サーバーインスタンスを使って構築します。上の図で見たように、NGINXはノードインスタンスにリクエストをプロキシするロードバランサーとしてコンフィギュアされます。
既に自分のインフラストラクチャーにＨＡクラスターを導入している方は、この部分は呼び飛ばしていただいても結構です。
a — Setting NGINX as a load balancer
ロードバランサーとしてのNGINXのセッティングです。NGINXはポート80上でコンフィギュアされます。デフォルトのコンフィグレーションを走らせ、ポート5000、5001、5002上にあるサービスへリクエストをプロキシします。
サーバーコンフィギュレーションのの/nginx_status 部分に注意してください。これをきちんと入れておくようにしてください。というのも、後でNGINXメトリックスを収集するためにTelegrafが使用するからです。
b — Setting simple Node HTTP instances.
Node HTTPインスタンスの設定についてです。ここでは、Nodeによって可能になるhttp と httpdispatcherライブラリを使って、ネイティブにとてもシンプルなNode HTTPインスタンスを使いました。
// The simplest implementation of a HTTP server.var http = require('http');// Providing middleware capabilitiesvar connect = require('connect');// Used to route HTTP requests in our web server.var HttpDispatcher = require('httpdispatcher');var dispatcher = new HttpDispatcher();var app = connect();// Callback executed on every requestapp.use(function(request, response) {dispatcher.dispatch(request, response);});var server = http.createServer(app);dispatcher.onGet('/', function(request, response) {response.end('The simplest http server one can create');})dispatcher.onError(function(request, response) {response.writeHead(404);response.end('The server could not route your request');})server.listen(process.argv[2], function() {console.log(`Server started on port ${process.argv[2]}`);})
このサーバーには特別なケーパビリティを持ち合わせていませんが、リクエストをプロキシするNGINXのための基本的なウェブサーバーとして使われます。
それらのウェブサーバーの３つのインスタンスをローンチするために、pm2 を使います。これは、Linuxシステム上のNodeインスタンスのためのプロセスマネージャーユーティリティです。
NGINXの準備がこれでできました。次は、実装して３つのインスタンスをローンチしましょう。
Nodeサーバーの他の２つのインスタンスに同じようにするために、３つのNodeのクラスターがアップされて準備できています。
IV — Setting Up Telegraf For Monitoring
それでは、モニタリングのためのTelegrafの設定です。
今HAクラスターは構築され、実装している状態です。次は、自分たちのアーキテクチャーの異なるコンポーネントをバインドするTelegrafを設定をしていきます。
Telegrafは次の異なるためのプラグインを使ってクラスターのモニタリングをします
- NGINX plugin : ロードバランシングサーバー上でのリクエストの数や、待機中/アクティブ、もしくは扱ったリクエストのようなNGINX サーバーを取得するために使われる。
- HTTP_Response : リクエストに関連したHTTP コードやそれぞれのノードのリスポンス時間を定期的に取得するために使われる。このプラグインはノードクラッシュやモニターピークをモニタりイングするためにとても便利なプラグイン。
始める前に、telegrafが以下のコマンドで走っていることを確認してください：sudo systemctl status telegraf
もし自分のサービスがActiveになっていたら次に進みましょう！
コンフィグレーションのためにTelegrafのデフォルトロケーションで実行して( /etc/telegraf )、telegraf.conf ファイルを編集して、以下のアウトプットコンフィグレーションをそれに追加してください。
Telegrafのコンフィグレーションの変更が終わったら、変更を考慮するために、必ずサービスを再起動してください。( sudo systemctl restart telegraf ).
一度Telegrafが走り始めると、実行中のプラグインの名前で呼び出されるメトリックを作成するtelegraf データベースの中のInfluxDB (ポート 8086で実装中)へ定期的にメトリックを送信し始めなければいけません。
そのようなデータベースと測定値がInfluxDB上で生成されない場合、コンフィグレーションでの問題は起きていないか、telegrafサービスが正常に走っているか確認してください。
それでは、別々のツールが走りだしたところで、Grafanaに移る前にファイナルアーキテクチャーを見てみましょう。
Orangesys.ioでは、kuberneteの運用、DevOps、監視のお手伝いをさせていただいています。ぜひ私たちにおまかせください。
