Elastic Stackでシステム監視 Heartbeatを使う準備

Heartbeatは各ホストにインストールする必要がないタイプのbeatsの1つ。他所のホストにpingを飛ばしたりhttpでアクセスして反応を見るというもの。ホストがWindows, Linux, xBSDならMetricbeatやFilebeatを入れて、またはSNMP(または他の監視機能)付きのアプライアンスならそれで情報を取れば良いのだが、「管理機能付きアンマネージド(意味不明)」な安物L2SWや家庭用程度の無線LANのAPやIP電話機などはbeatsをインストールすることも出来ずSNMP等も無いことが多いので死活監視をするとしたらpingや管理画面のウェブにアクセスして反応を見る程度になる。その程度でも機器が多い環境では死活監視できるのはありがたい。

インストール

FreeBSDのportsではHeartbeatはMetricbeatやFilebeatなどと一緒にインストールされるのでそれらを既に使っているならインストール済みの筈。

beatsは初めてというなら一応、以下。
# cd /usr/ports/sysutils/beats
# make install
# sysrc heartbeat_enable=Yes
heartbeat_enable:  -> Yes    #←この表示が出れば/etc/rc.confに追記(or変更)されている

FreeBSDのportsでは各beatsの実行ファイルと簡易版の設定ファイルの雛形だけがインストールされる。
できれば下のファイルも/usr/local/etc/あたりにコピーしておくと便利。Elasticのウェブサイトのドキュメントでは設定の情報を探すのが大変なので。
/usr/ports/sysutils/beats/work/src/github.com/elastic/beats/heartbeat/heartbeat.reference.yml

存在しない場合は
# cd /usr/ports/sysutils/beats
# make extract
# cp ./work/src/github.com/elastic/beats/heartbeat/heartbeat.reference.yml /usr/local/etc/
# cp ./work/src/github.com/elastic/beats/libbeat/_meta/
# make clean

Heartbeatの設定

/usr/local/etc/heartbeat.yml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
#== Configure monitors ==
heartbeat.monitors:
# 監視対象1 IP-Phone #155
- type: icmp
  schedule: '@every 600s'
  hosts: ["192.168.6.155"]

# 監視対象2 LAN#4 Wi-Fi AP#2
- type: http
  urls: ["http://192.168.2.248/admin"]
  schedule: '@every 600s'

# 監視対象3 L2SW-LAN#5
- type: http
  urls: ["http://192.168.0.250"]
  schedule: '@every 300s'

#== Elasticsearch template setting ==
#setup.template.enabled: true
setup.template.name: "heartbeat"        #インデックス名を変更する場合は必要な設定(下の方)
setup.template.pattern: "heartbeat-*"   #インデックス名を変更する場合は必要な設定(下の方)

setup.template.settings:
  index.number_of_shards: 1
  index.codec: best_compression
  #_source.enabled: false

#== Dashboards ==
setup.dashboards.enabled: false
#setup.dashboards.url:

#== Kibana ==
#setup.kibana:
#  host: "127.0.0.1:5601"

#== Outputs ==
#output.logstash:
#  hosts: ["localhost:5044"]

output.elasticsearch:
  enabled: true                         #←この行が無いとelasticsearchに出力されないが簡易版の設定ファイルには書かれて無い
  hosts: ["localhost:9200"]
  ssl.enabled: false                    #SSL無効
  index: "heartbeat-%{+yyyy.MM.dd}"     #インデックス名を変更 初期値はheartbeat-バージョン-日付

  #username: "elastic"
  #password: "changeme"

#== Logging ==
#logging.level: debug
#logging.selectors: ["*"]
#logging.to_syslog: false
#logging.to_files: true
#logging.files:
#  path: /var/log
#  name: heartbeat.log

今回はHeartbeatなので出力するデータにそれほど無駄な内容はない筈。なのでLogstashでデータ加工をする必要はない。そこで、Heartbeatから直接elasticsearchに出力させることにした。
その場合、41行目が大事。

Heartbeat用テンプレートの登録

少なくとも「FreeBSDのportsでインストールしたHeartbeat 6.2.3」では上の設定でHeartbeatを起動するとタイムスタンプが「日時」ではなく「文字列」として認識されるためテンプレートを指定して@timestampの値を強制的に「日時」にする。今回はテンプレートで指定するのはタイムスタンプだけとする。

Elastic Stackでシステム監視 Heartbeat 1
Kibanaで左列のでDev Toolを開き、以下を入力してで実行する。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
PUT /_template/heartbeat
{
"template" : "heartbeat-*",
  "mappings": {
    "doc": {
      "properties": {
        "@timestamp": {
          "type": "date"
        }
      }
    }
  }
}

右列の結果欄に  "acknowledged": true   が表示されること。

同様に  GET heartbeat-2018.04.18/_mapping   などのように"heartbeat-今日の日付"でマッピングを取得し、右列の結果で@timestampのtypeがdateという表示であればOK.
ただし、これはheartbeat起動後。

ここまでやったらHeartbeatを起動する。

# service heartbeat start

Kibanaでインデックスパターンを登録

Elastic Stackでシステム監視 Heartbeat 2
左列のManagementを開き、Index Patternsをクリック。

Elastic Stackでシステム監視 Heartbeat 3
[Create Index Pattern]をクリック。

Elastic Stackでシステム監視 Heartbeat 4
Index patternのテキストボックスに heartbeart-* を入力する。このとき下部にhearbeat-yyyy.MM.ddのインデックスが表示されていること。(無ければ登録できない)
[ Next step] をクリック。

Elastic Stackでシステム監視 Heartbeat 5
Time Filter field nameのプルダウンメニューが表示されていること。ここでプルダウンメニューが表示されていなければタイムスタンプとなるフィールドが存在しないと認識されているのでテンプレートの登録が正しく行われていない筈。
[]をクリックしてリストから @timestamp を選択する。
[Create Index pattern]をクリック。

Elastic Stackでシステム監視 Heartbeat 6
heartbeat-*のインデックスパターンが表示されていることを確認。違うインデックスパターンが表示されているなら上部でheartbeat-*を選択する。
フィールドリストの@timestampの右側に(時計アイコン)が表示されていること。

これでHeartbeatのデータをKibanaで使える状態になった。
Kibanaでの死活状態の可視化は次回。

関連記事:

NginxでBrotliによるコンテンツのデータ圧縮を行う

いまさらだけどBrotliの圧縮機能ををNginxで有効にすることにした。

環境は例によってFreeBSDでNginxやBrotliはportsでインストールすることにする。

Brotliモジュール付きNginx portsの更新/インストール

# cd /usr/ports/www/nginx-devel  #使用中orインストールしたい方のports
または
# cd /usr/ports/www/nginx        #使用中orインストールしたい方のports

Nginxを新規でインストールする場合
# make install

既にportsのNginxを利用している場合
# make config
# portupgrade -f www/nginx-devel  #以下2行のどちらか
# portupgrade -f www/nginx

Nginx portsのmake config
make install (新規)または make config (更新)を実行するとビルドオプションが表示されるので BROTLI にチェックする。(カーソルキーで行を合わせて[Space]など)

更新の場合はmake configの代わりに /var/db/ports/www_nginx-devel/options か /var/db/ports/www_nginx/optionsをエディタで開いて OPTIONS_FILE_UNSET+=BROTLI の行をOPTIONS_FILE_SET+=BROTLI に変更して保存するでも可。

BROTLIを有効にしてビルドすると自動的にarchivers/brotliのportsがインストールされる。

なお、portsでインストールされるNginx用のBrotliモジュールはngx_brotliのようなので設定の詳細はそちらから。

Nginxの設定

/usr/local/etc/nginx/nginx.conf (設定追加)
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
load_module /usr/local/libexec/nginx/ngx_http_brotli_filter_module.so;
load_module /usr/local/libexec/nginx/ngx_http_brotli_static_module.so;

中略

http {

   中略

   gzip                 on;
   gzip_http_version    1.0;
   gzip_static          on;
   gzip_min_length      100;
   gzip_buffers         16 8k;
   gzip_vary            on;
   gzip_comp_level      1;
   gzip_types           application/atom+xml
                        application/javascript
                        application/rss+xml
                        application/x-javascript
                        application/xml
                        application/xml+rss
                        image/svg+xml
                        text/css
                        text/javascript
                        text/plain
                        text/xml;

    brotli              on;
    brotli_comp_level   6;
    brotli_static       on;
    brotli_types        application/atom+xml
                        application/javascript
                        application/rss+xml
                        application/x-javascript
                        application/xml
                        application/xml+rss
                        image/svg+xml
                        text/css
                        text/javascript
                        text/plain
                        text/xml;

    中略

    }

中略

}

Brotliモジュールは自動では使用されない筈なので設定ファイルの最初でロードさせる。

brotliモジュールの設定はgzip圧縮の設定と似た感じ。brotli_staticをオンにした場合は静的なbrotli圧縮ファイルを用意する。これはgzip_staticと同様。
全てのブラウザでbrotli圧縮が使えるわけではないのでgzip圧縮も(これまで有効にしていたなら)有効のままににしておく。

静的コンテンツを圧縮

静的ファイルをBrotliで圧縮する。

/PATH/index.htmlをbrotliで圧縮する実行例
$ /usr/local/bin/brotli /PATH/index.html --force --output=/PATH/index.html.br
または
$ /usr/local/bin/brotli -f /PATH/index.html

圧縮レベル ( -q 値 ) は0〜11で11が最も高い圧縮率。未指定で6。おそらく未指定で良いかと。
-f または --forceオプションで出力ファイルは上書きされる。コンテンツを更新して再圧縮する場合などに有用。
-s または --suffixオプションは初期値が.br なので上の実行例の1つめと2つめは同じ結果となる。(出力ファイル名は「元のファイル名.br」で既に存在する場合は上書き)

ウェブサイトのファイルは殆どの場合に大量に存在する筈なので1つ1つ手作業で圧縮するのは非常に手間。更新したときの再圧縮も面倒でイヤになる筈。指定したディレクトリ内のファイルを一気に(下層も再帰的に)圧縮するスクリプトを用意する。

brotli.sh
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
#!/usr/bin/env bash
if [ $# -ne 1 ]; then
    echo "usage: brotli.sh /Path"
    exit 1
fi

for FILE in $(find $1 -type f  -iname "*.html" -o -iname "*.xml" -iname "*.css" -o -iname "*.js" -o -iname "*.svg" ); do
    echo -n "${FILE}..."
    /usr/local/bin/brotli ${FILE} --force --output=${FILE}.br;
    echo "done."
done

指定されたディレクトリ内のファイルを順番に処理。拡張子が html, xml, css, js, svg のファイルならbrotliで圧縮するというもの。


使い方:
$ brotli.sh /usr/local/www/example
 

圧縮したいディレクトリのPathを引数に指定して実行

Nginxの設定確認と再起動

# service nginx configtest    #設定確認 これは稼働中のNginxに影響しない
Performing sanity check on nginx configuration:
nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful

# service nginx restart
または
# service nginx gracefulstop && service nginx start
または
# service nginx reload

設定確認でtest is successfulになるまではNginxを再起動させない。設定が不完全で下手に再起動させようとするとサービス停止になる。

Brotli圧縮の動作確認

# 圧縮無し
% curl -I https://example.com/index.html
HTTP/2 200
server: nginx
date: Fri, 13 Apr 2018 04:22:00 GMT
content-type: text/html; charset=utf-8
content-length: 12270                             #←コンテンツサイズ
last-modified: Sun, 11 Feb 2018 14:04:55 GMT
vary: Accept-Encoding
etag: "5a804d87-2fee"
expires: Fri, 13 Apr 2018 04:22:00 GMT
cache-control: max-age=0
strict-transport-security: max-age=31536000;
accept-ranges: bytes

# Brotli圧縮
% curl -H "Accept-Encoding: br" -I https://example.com/index.html
HTTP/2 200
server: nginx
date: Fri, 13 Apr 2018 04:19:51 GMT
content-type: text/html; charset=utf-8
content-length: 2673                             #←コンテンツサイズ
last-modified: Sun, 11 Feb 2018 14:04:55 GMT
vary: Accept-Encoding
etag: "5a804d87-a71"
content-encoding: br                             #←Brotli圧縮
expires: Fri, 13 Apr 2018 04:19:51 GMT
cache-control: max-age=0
strict-transport-security: max-age=31536000;

正しく機能していれば圧縮されたコンテンツが取得されるのでコンテンツサイズが小さい筈。

ウェブツールでも確認してみる。

Brotli Test
https://tools.keycdn.com/brotli-testでBrotli Testを実行できる。URL (静的コンテンツ)を入力して[Test]をクリックして薄緑の四角の部分に「Yeah! [入力したURL] suppors Brotli compression.」が表示されればOK.シンプルに「Brotli compression is supported.」になったらしい。

2021年11月17日:
最後のtools.keycdn.comのオンラインツールでの確認画像が失われていたため新しい画像に差し替え。

Up