著者：廣岡 和真
株式会社 日立製作所
日立製作所の廣岡和真と申します。Elastic社のHeartbeatを用いて外部監視を始めるにあたって、特に重要と感じた点を交えつつご紹介させていただきます。
##Heartbeatの概要
###Heartbeatとは
HeartbeatはElastic社が提供する外部監視用ツールです。
Elastic社はデータ分析エンジンであるElasticsearchをはじめ、Elastic Stackとして様々なツールを提供しています。その中にはデータの可視化用ツールであるKibanaや、Beatsと呼ばれるデータ収集・転送パッケージ等があります。
今回ご紹介するHeartbeatはこのBeatsの1つで、主にサービスの稼働状況監視にかかわるデータを収集します。
このHeartbeatをElastic Stackと組み合わせることで様々なサービス監視を実現することができます。
こちらはKibanaによる可視化ページ（ブラウザ画面）です。
Heartbeatによる監視状況はこのようにKibanaを通して確認することができます。
監視の種類
HeartbeatではPingの送受信をベースとして、ICMP・TCP・HTTP経由の3タイプで死活監視をすることができ、基本的には対象のアップダウンや応答時間に関するデータを取得します。
Heartbeatで利用可能な監視を以下、タイプごとにまとめました。
| タイプ (プロトコル) |
監視の内容 | 監視対象 |
|---|---|---|
| ICMP | Ping監視を実行 ：ICMPプロトコルに基づいて対象のアップダウンを識別 |
サーバー |
| TCP | ポート監視を実行 ：サーバー上の特定ポート(およびポートに対応するサービス)の稼働状態が見られる （例）ポート22番→SSHの状況 |
サーバー・サービス |
| HTTP | URL(Web)監視を実行 ：設定したURL等に対して、HTTP(S)経由で稼働状況や応答時間・ステータスコードなどを取得 |
サイト・URL |
(その他、オプションとしてシンセティック監視（合成監視）も設定できます。)
Heartbeatによりサーバー・ホスト装置の稼働状況から、特定のアプリケーションやサイトに絞った稼働状況まで幅広く監視することができます。
中でも、今回はHTTP監視を取り上げてご紹介したいと思います。
##監視環境を構築する
####まえおき：環境について
私が使用した監視用ホストのOSはLinux（CentOS7）です。
また、監視用ホスト内部にインストールしたツールは以下の通りです。なお、全てRPM64bit版を使用しました。
- Elasticsearch 7.15.1 （事前に構築済み）
- Kibana 7.15.1 (事前に構築済み)
- Heartbeat 7.15.1
HTTP監視を設定してみる
ここからはHeartbeat上での実際のHTTP監視設定について、私の体験談を交えつつご紹介したいと思います。
まず初めに、認証のない一般的なサイトを例に、基本的な監視設定をご紹介します。
→①
次に、HTTP認証をHeartbeat上で実行する場合についてご紹介したいと思います。
→②・③
Heartbeatの設定手順では、YAMLファイル（heartbeat.yml）をviコマンドで編集します。
以下ではYAMLファイルの設定内容も参考として載せています。
####① 一般的なサイト
Heartbeatの特徴として、YAMLファイル上に監視したいURL情報を記述するだけで
すぐに監視を始めることができます。
- type: http
urls: ["https://(対象URL)"] ← 監視したいURLはこちらに
schedule: "@every 1m"
id: HTTPmonitoring-1
name: HTTPのWebサーバ（認証無）
YAMLファイルには最低限これだけを設定すればOKです！
scheduleの項目は、監視間隔（pingの送信間隔）の設定です。
上記例では1分ごとに監視を実行します。
id、nameの項目はタグ付けのようなもので、監視対象を識別する際に便利です。
インターネット上のWebサイトなどを監視する場合は、上記設定のみで十分です。
ただ、イントラサイトなど限定されたサイトを監視する場合には、追加設定が必要な場合があります。それが次にご紹介するSSL/TLS(証明書）の設定です。
（設定しない場合、対象はダウン表示されました）
#####SSL/TLS通信の設定
HTTPSをはじめSSL/TLS通信をHeartbeat上で実行するにあたり、下記エラーが出る場合がありました。
"x509: certificate signed by unknown authority"
原因は、SSL通信を保証するルート（CA）証明書が不適切だったことにあります。
その場合は、まず事前に対象サイト用のルート証明書をダウンロードし、監視用ホスト内部に配置する必要があります。
証明書の配置後、下記内容を追加することでようやく該当サイトへのアクセス・監視が可能となりました。
- type: http
(中略)
ssl:
certificate_authorities: ['/etc/heartbeat/(適切なルート証明書).pem']
上記例では Heartbeatディレクトリ配下にルート証明書を配置しています。
なお、Linux環境下では証明書をCER形式→PEM形式に変換することを推奨します。
CER形式の証明書パスで設定したところ、読込時エラーでHeartbeatが停止することがありました。
####② Basic認証が必要なサイト
ここからは認証を要求されるサイトの監視についてご紹介します。
監視を実行するには、Heartbeat上でも認証に関する設定が必要となります。
Basic認証が要求されるサイトを監視する場合は、下記のようにusername・passsword項目を追加します。
- type: http
urls: "https://(対象URL)"
username: "xxxxxxxx" ← ユーザ名
password: "yyyyyyyy" ← パスワード
schedule: "@every 1m"
id: HTTPmonitoring-2
name: HTTPSのWebサーバ（Basic認証）
ssl:
（以下略）
Basic認証の場合はこれで設定完了です。
####③ プロキシ認証を経由するサイト
社内ネットワークなどでは、セキュリティ面からプロキシサーバーを経由しなければならい場合があります。
プロキシ認証を経由するサイトを監視したい場合は、下図3行目のように、プロキシサーバーのURLを追記するだけで十分です。
- type: http
urls: "https://(対象URL)"
proxy_url: 'http://(プロキシサーバーのURL):8080' ←プロキシのURL例
schedule: "@every 1m"
id: HTTPmonitoring-3
name: HTTPSのWebサーバ（プロキシ認証）
ssl:
（以下略）
ただし、プロキシ認証上でユーザ名やパスワードが要求される場合は次のように設定します。
proxy_url: 'http://(ユーザ名):(パスワード)@(プロキシサーバーのURL):8080'
若干Basic認証の時とは設定が異なりました。
このように、username・password項目を追加することで、
ユーザ名・パスワード型の認証が必要なサイトにも監視を適用できました。
####オプション設定
上記③までの設定で、一通りのサイト（URL）は監視が十分可能ですが、Heartbeatではさらに監視環境を細かくセッティングできます。
ここからはオプション設定を2つご紹介したいと思います。
#####オプション①：リダイレクトされるサイトを監視する
リダイレクトが実行されるサイト（URL）をHeartbeat上で監視する場合、少し注意が必要です。
まず、転送前のサイト（URL）に監視設定を適用すると以下のようになります。
- 対象はアップ
- ステータスコードは
302
アップの表示ですが、ステータスコードが302であるため、実はこの状態では転送先のサイト（URL）まで到達できていませんでした。
ポイントとして、リダイレクトする設定を追加することで解決しました。
- type: http
urls: "https://(対象URL)"
max_redirects: 3 ← リダイレクトの設定
schedule: "@every 1m"
id: HTTPmonitoring-4
（以下略）
このmax_redirectsでは、リダイレクト実行回数の上限を設定します。
ただしHeartbeatのデフォルト設定では、このmax_redirectsを特に明記しない限り、
※リダイレクト上限回数（max_redirects）が"０"＝リダイレクトしない設定
となっていたため、当初ステータスコード302が返されてしまいました。
リダイレクトが実行され、ステータスコードも200に変わりました。
上記では"3"（3回まで）と設定していますが、必要な回数分リダイレクトを実行するよう設定すれば、最終的に監視したいサイトまでたどり着き、監視を適用することができます。
#####オプション②：ステータスコードに基づきアップダウン判定を変更してみる
ちなみに、Heartbeatのデフォルト設定上では
ステータスコードが400番台又は500番台の場合のみに対象のダウンを返すことになっています。
今回のような300番台だと、通常は対象がアップしていると識別されます。
そこで下記設定を追加すると、ステータスコード302でもダウンを返すようになりました。
- type: http
（中略）
check.response.status: [200]
レスポンスコードに対して、checkコードによりフィルタをかけました。
上の例では、ステータスコードが200である時のみ対象がアップであると識別しています。
（そのためダウンのステータス表示とともに、エラーメッセージが追加されました。）
その他、HTTPヘッダやボディに対してもフィルタ（check）を付与することができます。
レスポンスに期待値を設定し、合致した場合のみアップと判定される仕様にカスタマイズすることができます。
######まとめ
今回の①→②→③やオプション設定のように、HTTP監視の設定を次第に追加していくことで、HTTP監視の幅を広げることができました。
監視状況を確認する
監視設定を一通り終えてHeartbeatを起動させると、YAMLファイルの情報に基づいてHeartbeatによる監視（データの収集）が開始されます。
収集された監視データはKibanaの画面から確認します。
#####アップタイム監視
基本的な確認方法はKibanaのアップタイム画面です。
アップタイム画面からは、対象のアップダウン状況を一目で確認できます。
この画面では監視対象とそのアップダウン状況が一覧表示されています。
また、監視対象を１つ選択すると、対象ごとの確認もできます。
この画面からは、監視（継続）期間の推移や、一定時間ごとに送受信されたPing数がグラフ形式で確認できます。
また、HTTP監視の場合はアップダウン状態に加えて、ステータスコードやレスポンスボディ・（エラー時のみ）エラーメッセージなどをここから参照することができます。
また、SSL/TLS通信を設定した監視対象上ではTLS（ルート）証明書に関する情報を見ることができます。
- 証明書の有効期限
- 証明書の発行者
- 指紋情報
#####ダッシュボードを適用する
さらに、Kibana上でダッシュボードを作成・適用することで、監視状況を視覚的に確認することができます。
#####フィールド値を参照する
また、Heartbeatにより収集される監視データは、フィールド値としてKibanaから確認することができます。以下はフィールド値の一例です。
- 応答時間（RTT）
HTTP監視の場合は、リクエストやレスポンスヘッダ・ボディ取得のみにかかる応答時間（RTT値）を取得可能 - HTTPレスポンスの詳細データ
- 監視先のIPアドレス（解決可能な場合）
- ハッシュ値(HTTPレスポンスボディやTLS)
このように収集されたデータ（フィールド）が監視対象ごとに一覧表示されます。
Heartbeat上で収集されるフィールド値については、下記公式ページをご参照ください。
[Heartbeatのフィールド一覧][1]
[1]:https://www.elastic.co/guide/en/beats/heartbeat/current/exported-fields.html
（補足）
さらにElasticsearchやKibanaのオプション設定を適用すれば、以下が可能になります。
- 応答時間に閾値を設定し、閾値を超えた場合にアラートを発出させる
- 監視対象のログや内部情報（CPU稼働率など）と組み合わせて、異常の原因を検出
など
##おわりに
今回、Heartbeatを用いて色々な外部監視環境の構築を行いました。
Heartbeatで外部監視を行うメリットは次の2点にあると思います。
- URLやIPアドレス情報があれば、シンプルな設定だけで監視が始められる
- Heartbeatの追加設定やElasticStackとの組み合わせによりカスタマイズの幅を広げられる
みなさんもぜひ、Heartbeatで外部監視を始めてみてはいかがでしょうか。
Elastic社の公式ドキュメントなど
当記事でご紹介した監視の環境設定はごく初歩的なものです。
Elastic社の公式ドキュメント上にはその他構築できる環境や得られるデータなどが掲載されておりますので、ぜひ以下からチェックしてみてください。