127.0.0.1 より localhost のほうが書きやすいし良さそう、と思って localhost と書いているとしばしばハマります。

というかなんとなく localhost = 127.0.0.1 と考えがちではないでしょうか? そんなことはないので気をつけましょう。

最近のシステムなら /etc/hosts を確認すると少なくとも2つの localhost エントリを見ることができるでしょう。

127.0.0.1       localhost
::1             localhost 

上は IPv4、下は IPv6 です。localhost はどちらのアドレスにも解決しうるホスト名となっています。

どういうときにハマるか

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

正しい方法

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

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

次善の策

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

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

localhost に限らない

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

  1. トップ
  2. tech
  3. localhost と書くと IPv6 対応したときに死ぬことがある

RTX1200 から直接 prometheus 形式でメトリクスを取得できる Lua スクリプトを書いた。

prometheus + grafana のセットアップ (Ubuntu 16.04.4 LTS) | tech - 氾濫原 自宅 raspberrypi への prometheus セットアップとリモートの prometheus との連携 | tech - 氾濫原 とやってきて、自宅内のメトリクスを grafana で表示できるようにしたので、自宅のルーターの RTX1200 のメトリクスをとるようにした。

RTX1200 はユーザー Lua を実行できる環境があり、そこそこ高級なことができる。TCP サーバは簡単に立てられる。HTTP サーバはないが、不特定多数のリクエストを受けるものでもないので、自力で簡単なものを実装した。

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
  1. トップ
  2. tech
  3. RTX1200 prometheus exporter Lua スクリプト

メトリクスの可視化をもうちょっとやりたくて prometheus と grafana をセットアップした。監視は mackerel でやってるのでやらない。

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
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

*リバースプロキシ
  1. トップ
  2. tech
  3. prometheus + grafana のセットアップ (Ubuntu 16.04.4 LTS)


Public VPS 上の Ubuntu に prometheus と grafana をセットアップしたので、自宅のネットワークのメトリクスもとって、そちらで表示したい。

自宅は IPv4 は NAT 内、IPv6 はグローバルだが IPv4 + NAT 程度のアクセス制限をかけていて、あまりそこをいじりたくないので、なんとかして自宅側から外への接続ですませたい。

prometheus は pull 型なのでこういった環境でのメトリクス収集がやっかい。いくつか方法がある

pushgateway を使う。prometheus 公式で提供されている short live batch 用のゲートウェイ。POST すると pushgateway 側で値を保持してくれて、prometheus からの pull に答える。使うのが簡単なので最初はこれでやっていたが、prometheus 的にはこういうやりかたはよくないっぽい。

検討した結果以下のような形にする

  • 自宅内にも prometheus サーバを立てる
  • Public VPS 側からは federate で連携する

自宅セグメント内のメトリクスをひとまとめにしてから、連携させる。こうすることで、各 exporter のアクセスコントロールなどはやりやすくなる。ただ、結局この方法も /federate を pull する形になるので、そこはなんとかする (後述)

自宅 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 のアドレスを指定する。リバースプロキシしているので、そのホストを指定する。

prometheus.yml

federate に関係するところを抜きだすと以下のように。raspberrypi となっているところは client 側で送っているホスト名になる。PushProx はこの文字列でプロキシすべき先を区別している。

# 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'

また自宅側の prometheus.yml には external_labels を指定しておく。これは federate のときに固定でラベルを追加する設定。

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

これで 127.0.0.1 のような指定をして instance 名がかぶっていても自宅のものと区別がつく。

PushProx の罠

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

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

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

  1. トップ
  2. tech
  3. 自宅 raspberrypi への prometheus セットアップとリモートの prometheus との連携