クラウドの運用にMackerelを使ってみた(第4回:ネットワーク死活監視設定)

「クラウド導入・運用サービス」のサービス企画担当のとりとりです。
前回は、エージェントをインストールしたホストに対し、プロセスやログ等のOS以上のレイヤ監視設定やURLによる外形監視設定をやりました。
今回は、ネットワーク死活監視設定を行います。ネットワークの死活監視を実装することでネットワークレイヤとの切り分けができるようになります。それでは、実際にやってみましょう。

構成図・やりたいこと

構成図

アプリケーションサーバー(以降、APサーバー)とデータベースサーバー(以降、DBサーバー)がAWS上に各1台ずつある構成とします。各サーバーの初期設定及び、Mackerelエージェントのインストールは完了しているものとします。
前回との構成上の差分は、他システムのサーバーが異なるVPCで稼動しており、VPCピアリングによって接続されています。他システムのサーバーは別会社によって運用されており、詳細な条件はわからない想定とします。

各サーバーのスペック(APサーバー、DBサーバー)※前回と同じ

インスタンス:t2.micro(1vCPU,メモリ:1GiB)
OS:Amazon linux2
ディスクサイズ:8GiB

インストールされているミドルウェア(APサーバー、DBサーバー) ※前回と同じ

APサーバー:Apache v2.4
DBサーバー:PostgreSQL 9.6

やりたいこと

  • システム障害が起きた際に、自システムか他システムかの切り分けを行いたい
  • DBサーバーと連携するシステムのため、DBサーバーとのネットワーク疎通が取れていることが確認したい

上記やりたいことを実現するために、Mackerelの設定を行います。

ping監視設定(チェックプラグインを使用した場合)

前回の繰り返しになりますが、基本監視項目以外を監視するためには2つの方法があります。

  • 公式で配布されている、プラグイン集を利用する
  • スクリプトやプログラムで独自の値を収集して、カスタムメトリックとして投稿する

まずは前者のプラグイン集を利用して行います。

公式チェックプラグインの入手コマンド

yum install mackerel-check-plugins

「check-ping」というプラグインがポート監視に対応しておりますので、エージェントの設定ファイル(mackerel-agent.conf)をテキストエディタで編集します。

エージェントの設定ファイルを編集するコマンド(例)

vi /etc/mackerel-agent/mackerel-agent.conf

設定ファイル最下部に下記のような文章を追記します。

Ping監視する設定(例)

[plugin.checks.check-ping-sample]
command = ["check-ping", "-H", "宛先IPアドレス", "-n", "5", "-w", "2000"]

コマンドの説明

-H:IPアドレス
-n:Ping試行回数
-w:タイムアウトになるまでの待機時間(ms)

追記が終わったら保存し、エージェントを再起動します。

エージェントを再起動するコマンド(例)

systemctl restart mackerel-agent

設定が完了すると、Hostsページの右側に、監視項目が追加されています。

これは前回とほぼ同じ手順で追加することができました。

ping監視設定(カスタムメトリックを使用した場合)

Mackerelにはスクリプトやプログラムで独自の値を収集して、カスタムメトリックとして投稿することができます。公式プラグインに載っていないミドルウェアのメトリクスを収集したい場合などに使うことができます。Ping監視は公式プラグインがありますが、公式プラグインではOK/NGのどちらかしか判定できないので、応答時間をもとにアラートの種類を変えたり、ネットワークの品質判定として応答時間を残しておきたい、という場合にはカスタムメトリックを使います。

カスタムメトリックを投稿する手順は以下のようになります。

  • カスタムメトリックを収集するスクリプトやプログラムを作成
  • エージェントの設定ファイル(mackerel-agent.conf)に先ほど作成したプログラムやスクリプトを実行するコマンドを追加

上記に従って、まずはスクリプトファイルを作成します。

スクリプトファイルを作成するコマンド(例)

sudo vi /etc/mackerel-agent/mackerel-plugin-ping.sh

※今回はエージェントの設定ファイルと同じフォルダに作成しておりますが、必要に応じて読み替えてください。

スクリプトファイル本文

#!/bin/bash
LIST=$*
PREFIX="ping"
TIME=$(date +%s)

for PING in ${LIST:=localhost}; do
  v=$(ping -t 5 -c 2 ${PING} | awk -F '/' '/round-trip|rtt/{print $5; }' | tr -d ms)
  s=$(echo $PING | sed 's#\.#_#g')
  echo ${PREFIX}.${s} ${v:=2000} $TIME
done

参考サイト:https://blog.hiroaki.home.group.jp/2017/09/mackerelping.html別ウィンドウで開きます

スクリプトファイルの作成が終わったら、ファイルのアクセス権限を変更します。

ファイルのアクセス権限を変更するコマンド(例)

sudo chmod 755 /etc/mackerel-agent/mackerel-plugin-ping.sh

※アクセス権はサーバーの設定に合わせて適宜読み替えてください。

次に、エージェントの設定ファイル(mackerel-agent.conf)をテキストエディタで編集します。

エージェントの設定ファイルを編集するコマンド(例)

vi /etc/mackerel-agent/mackerel-agent.conf

設定ファイル最下部に下記のような文章を追記します。

Ping監視する設定(例)

[plugin.metrics.ping]
command = "/etc/mackerel-agent//mackerel-plugin-ping.sh 宛先IPアドレス"

※複数の宛先IPアドレスを指定することも可能です。その場合は宛先IPアドレス間に半角スペースを入れて追記してください

追記が終わったら保存し、エージェントを再起動します。

エージェントを再起動するコマンド(例)

systemctl restart mackerel-agent

設定が完了すると、Hostsページの下部に、新しいグラフが追加されています。

余談ですが、VPCピアリングを行った宛先と、そうでない宛先を指定しています。2インスタンスとも同一アベイラビリティゾーンにあるのですが、VPCピアリングはネットワーク遅延の観点ではそれほど大きな差にならないことがわかります。

SNMP監視設定(おまけ)

ネットワークの監視に、SNMPを使っていることもあるかと思います。
Mackerelの公式プラグインには、「mackerel-plugin-snmp」というプラグインがありますので、SNMPマネージャとして起動しているサーバーにこのプラグインを入れておくと、SNMPの可視化が可能となります。ただし、SNMPトラップによる監視のプラグインは用意されていないので、この場合は別途検討が必要になります。

まとめ・次回予告

ネットワーク死活監視まで完了したことで、インフラの監視は概ね完了しました。多彩なプラグインが用意されているのが非常にありがたく、またプラグインを自分で作ったり公開できることもあって、時代にあったプラットフォームだと感じています。
次回は、AWS/Azureインテグレーション機能を使って、PaaS機能の監視を実装してみたいと思います!お楽しみに!

Amazon Web Services(AWS)は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。
Microsoft Azureは、米国Microsoft Corporationおよびその関連会社の商標です。
Mackerelは、株式会社はてなの商標です。
本コラムに掲載のサービスや登録画面等は2019年10月時点の情報であり、変更となる場合があります。

24時間365日対応可能なクラウド監視・運用代行で、あなたをシステム運用から解放します!

クラウドとオンプレミスでの運用を比較しながら解説!!

クラウドの導入・運用に関する
ご相談、お問い合わせをお待ちしております。

無料ダウンロード

自社のクラウド導入に必要な知識、ポイントを
このに総まとめ!

あなたはクラウド化の
何の情報を知りたいですか?

  • そもそも自社は本当にクラウド化すべき?オンプレとクラウドの違いは?
  • 【AWS・Azure・Google Cloud】
    どれが自社に最もマッチするの?
  • 情シス担当者の負荷を減らしてコストを軽減するクラウド化のポイントは?
  • 自社のクラウド導入を実現するまでの具体的な流れ・検討する順番は?

初めての自社クラウド導入、
わからないことが多く困ってしまいますよね。

NTT東日本では
そんなあなたにクラウド導入に必要な情報を

1冊の冊子にまとめました!

クラウド化のポイントを知らずに導入を進めると、以下のような事になってしまうことも・・・

  • システムインフラの維持にかかるトータルコストがあまり変わらない。。
  • 情シス担当者の負担が減らない。。
  • セキュリティ性・速度など、クラウド期待する効果を十分に享受できない。。
理想的なクラウド環境を実現するためにも、
最低限の4つのポイントを
抑えておきたいところです。
  • そもそも”クラウド化”とは?
    その本質的なメリット・デメリット
  • 自社にとって
    最適なクラウド環境構築のポイント
  • コストを抑えるため
    具体的なコツ
  • 既存環境からスムーズにクラウド化
    実現するためのロードマップ

など、この1冊だけで自社のクラウド化のポイントが簡単に理解できます。
またNTT東日本でクラウド化を実現し
問題を解決した事例や、
導入サポートサービスも掲載しているので、
ぜひダウンロードして読んでみてください。

クラウドのわからない・
面倒でお困りのあなたへ

クラウドのご相談できます!
無料オンライン相談窓口

NTT東日本なら貴社のクラウド導入設計から
ネットワーク環境構築・セキュリティ・運用まで
”ワンストップ支援”が可能です!

NTT東日本が選ばれる5つの理由

  • クラウド導入を
    0からワンストップでサポート可能!
  • 全体最適におけるコスト効率・業務効率の改善
    中立的にご提案
  • クラウド環境に問題がないか、
    第3者目線でチェック
    してもらいたい
  • 安心の24時間・365日の対応・保守
  • NTT東日本が保有する豊富なサービスの組み合わせで
    ”課題解決”と”コスト軽減”を両立

特に以下に当てはまる方はお気軽に
ご相談ください。

  • さまざまな種類やクラウド提供事業者があってどれが自社に適切かわからない
  • オンプレミスのままがよいのか、クラウド移行すべきなのか、迷っている
  • オンプレミスとクラウド移行した際のコスト比較を行いたい
  • AWSとAzure、どちらのクラウドが自社に適切かわからない
  • クラウド環境に問題がないか、第3者目線でチェックしてもらいたい
  • クラウド利用中、ネットワークの速度が遅くて業務に支障がでている

クラウドを熟知するプロが、クラウド導入におけるお客さまのLAN 環境や接続ネットワーク、
クラウドサービスまでトータルにお客さまのお悩みや課題の解決をサポートします。

相談無料!プロが中立的にアドバイスいたします

クラウド・AWS・Azureでお困りの方はお気軽にご相談ください。

ページ上部へ戻る