どういうときにハマるか

例えば同一サーバでリバースプロキシを行ってバックエンドサーバと繋ぎこみを行う場合、フロントのリバースプロキシで localhost:5000 と書くと IPv4 IPv6 どちらでアクセスされるか不定です。バックエンドサーバが IPv4 しか bind していないと IPv6 アドレスが選択されたとき接続不可になります。

正しい方法

すべてのサービスで IPv4 IPv6 ともに接続可能にし、ホスト名でアクセスできるようにすること。

非公開な内部向けサーバとかだと割と IPv4 しか使えないようにしがちではないかと思いますが、ちゃんとやったほうが無難です。

次善の策

ホスト名でひける IP アドレスの種類と実際に受けつけるプロトコルの種類をあわせること。

localhost の替わりに 127.0.0.1 か ::1 を使ってプロトコルを明示すること。

localhost に限らない

実際にところは localhost に限らず、ホスト名でアクセスするときには必ず気をつけるポイントです。DNS で IPv4 IPv6 いずれのアドレスも解決できるようにするなら、そのホスト上で待ち受けるサービスは全てデュアルスタックになっていないと、あらぬところでハマったりします。

Luaスクリプト

https://github.com/cho45/rtx1200_exporter/blob/master/rtx1200_exporter.lua

エンコーディングが sjis なのが注意点。9100 を listen している。IPv6 を listen する方法はないっぽいので、必ず IPv4 でアクセスする必要がある。

出力サンプル

メトリクス名が prometheus のベストプラクティスから外れてるのは、もともと SNMP でとっていた値があるため。

というか SNMP ではとれるけど Lua からは直接とることのできないメトリクスがあるのでちょっと困る。 Lua から自分向けに SNMP 使えばとれると思うが今回やっていない。

# Collecting metrics...
# TYPE yrhCpuUtil5sec gauge
yrhCpuUtil5sec 3
# TYPE yrhCpuUtil1min gauge
yrhCpuUtil1min 2
# TYPE yrhCpuUtil5min gauge
yrhCpuUtil5min 2
# TYPE yrhInboxTemperature gauge
yrhInboxTemperature 46
# TYPE yrhMemoryUtil gauge
yrhMemoryUtil 24
# TYPE ifOutOctets counter
# TYPE ifInOctets counter
ifOutOctets{if="1"} 51255053848
ifInOctets{if="1"} 8057224805
ifOutPkts{if="1"} 43465561
ifInPkts{if="1"} 27396255
ifOutOctets{if="2"} 8411163805
ifInOctets{if="2"} 52401299138
ifOutPkts{if="2"} 25933809
ifInPkts{if="2"} 42718551
ifOutOctets{if="3"} 0
ifInOctets{if="3"} 0
ifOutPkts{if="3"} 0
ifInPkts{if="3"} 0
# TYPE ipSession counter
ipSession{proto="v4"} 59
ipSession{proto="v6"} 35
# TYPE ipChannel counter
ipChannel{proto="v4"} 59
ipChannel{proto="v6"} 35

Lua のデバッグ方法

いまいちベストのデバッグ方法がわからないが、以下のような手順でやった。

以下の upload.sh を保存するたびに実行

#!/bin/sh

PASS=adminpass

cat <<EOF | tftp 192.168.0.1
put rtx1200_exporter.lua /rtx1200_exporter.lua/$PASS
quit
EOF

telnet 繋ぎっぱなしで以下を手動で実行

terminate lua all
lua /rtx1200_exporter.lua
show status lua

prometheus

Ubuntu の prometheus が古いので最新を自分でおく。/usr/local/prometheus にバイナリを置いていく。node_exporter も同様に /usr/local/node_exporter に置く。

 lm /usr/local/{node_exporter*,prometheus*}
lrwxrwxrwx 1 root  root    28  7月 14 22:32 /usr/local/prometheus -> prometheus-2.3.2.linux-amd64/
lrwxrwxrwx 1 root  root    32  7月 14 23:07 /usr/local/node_exporter -> node_exporter-0.16.0.linux-amd64/

/usr/local/node_exporter-0.16.0.linux-amd64:
合計 17M
-rwxr-xr-x  1 cho45 cho45  17M  5月 16 00:53 node_exporter*
-rw-r--r--  1 cho45 cho45  463  5月 16 00:57 NOTICE
-rw-r--r--  1 cho45 cho45  12K  5月 16 00:57 LICENSE
drwxr-xr-x  2 cho45 cho45 4.0K  5月 16 00:58 ./
drwxr-xr-x 14 root  root  4.0K  7月 14 23:07 ../

/usr/local/prometheus-2.3.2.linux-amd64:
合計 111M
-rwxr-xr-x  1 cho45 cho45  68M  7月 12 23:04 prometheus*
-rwxr-xr-x  1 cho45 cho45  43M  7月 12 23:05 promtool*
-rw-r--r--  1 cho45 cho45  926  7月 13 00:04 prometheus.yml
drwxr-xr-x  2 cho45 cho45 4.0K  7月 13 00:04 consoles/
drwxr-xr-x  2 cho45 cho45 4.0K  7月 13 00:04 console_libraries/
-rw-r--r--  1 cho45 cho45 2.8K  7月 13 00:04 NOTICE
-rw-r--r--  1 cho45 cho45  12K  7月 13 00:04 LICENSE
drwxr-xr-x  4 cho45 cho45 4.0K  7月 13 00:05 ./
drwxr-xr-x 14 root  root  4.0K  7月 14 23:07 ../

systemd の設定を置く

/etc/systemd/system/prometheus.service

[Unit]
Description=Prometheus service
After=network.target

[Service]
ExecStart=/usr/local/prometheus/prometheus --config.file=/etc/prometheus/prometheus.yml --log.level=debug --storage.tsdb.path=/var/lib/prometheus
Restart=always

[Install]
WantedBy=multi-user.target

/etc/systemd/system/node_exporter.service

[Unit]
Description=Prometheus node_exporter
After=network.target

[Service]
ExecStart=/usr/local/node_exporter/node_exporter
Restart=always

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl start prometheus
sudo systemctl enable prometheus

sudo systemctl start node_exporter
sudo systemctrl enable node_exporter

grafana

http://docs.grafana.org/installation/debian/ に従ってインストール。Ubuntu のレポジトリのやつはなんかおかしくてアイコンとかが表示されないので使わないほうが無難。

deb https://packagecloud.io/grafana/testing/debian/ stretch main

grafana は初回起動時に admin/admin で入れる。適当にパスワードをかえておくこと。

grafana へのデータソース追加方法はここ
https://prometheus.io/docs/visualization/grafana/

h2o prometheus exporeter

h2o の status に内部アクセスして prometheus 形式にするやつを書いている人がいるので、これを使うとよさそう。
https://gist.github.com/yannick/31d3d8ea6bcc3553dd422aad9d0e4173

リバースプロキシ

prometheus は 9090、grafana は 3000 がデフォルトポート。フロントの http サーバーからリバースプロキシを適当に設定しておく。prometheus は認証もつけておく。grafana は認証機構があるためフロントでは認証をかけない。

自宅 Raspberry Pi への prometheus セットアップ

自力で prometheus と node_exporter を置くところから。prometheus は arm ビルドを公式提供していないので、自分でビルドする。

prometheus のレポジトリの .promu.yml を書きかえ、linux/arm だけ有効にして、promu crossbuild を行う。 .build/linux-armv5 以下に prometheus のバイナリができるので、これを Raspberry Pi 側に scp する。

go get github.com/prometheus/prometheus/cmd/prometheus
cd $GOPATH/src/github.com/prometheus/prometheus
vim .promu.yml
ls  .build/linux-armv5

node_exporter はgithub の releases ページ に arm5 版があるのでそのまま使えば良い。

自宅 Raspberry Pi の prometheus を Public VPS の prometheus と繋ぐ (federate)

Public VPS 側から自宅側の /federate にアクセスして pull する。2つの方法を検討した。

• 自宅側にさらに別のフロントhttpサーバを用意して、アクセス制限・認証をかけつつ /federate をリバースプロキシし、Public VPS 側から直接アクセスさせる。
• Public VPS 側でリクエストを中継するサーバを用意して、自宅側からコネクションを貼りにいく。

1番目の方法は「自宅のIPアドレスを取得する」「アクセス制限・認証をかける」あたりが面倒くさい。DDNS の設定、ネットワーク(ルーター)の設定、アプリケーションレベルの認証設定と影響範囲が広い。

2番目の方法は Prometheus のサイトからリンクがある PushProx で実現できる。自宅側からは外向きにコネクションを貼るだけなので、影響範囲は狭い。ということでこれを使ってみることに。

設定

Public VPS 側では PushProx proxy プロセスを立てる。引数なしで立ち上げると 8080 ポートでプロキシサーバが立ちあがる。

./proxy

認証機能がついていないため、フロントの http サーバでリバースプロキシと適当な認証・アクセス制限をつけておく必要がある。

自宅側には client プロセスを立てる。このとき --proxy-url として、Public VPS 側の proxy のアドレスを指定する。リバースプロキシしているので、そのホストを指定する。

# Public VPS 側 (federate を pull する側)
  - job_name: 'federate'
    scrape_interval: 15s
    honor_labels: true
    metrics_path: '/federate'
    params:
      'match[]':
        - '{job="node"}'

    proxy_url: http://127.0.0.1:8080/
    static_configs:
      - targets:
        - 'raspberrypi:9090'

# 自宅側 (/federate を配信する側)
global:
  external_labels:
    location: home

PushProx の罠

現状の PushProx はかなり微妙な感じ。client 側がタイムアウトして接続を切っても、proxy 側ではそれがずっと残っていて、タイムアウト数ぶんのリクエストを受けきるまでまともに動作しなくなってしまう。

現状では pull するほうの prometheus (Public VPS側) を止めるときは proxy プロセスも止める必要がある。一応これに対応するパッチは書いた。

このへんが微妙なので、ちゃんと IPv6 で直接アクセスできる環境をつくってもいいかもなあと思っている。