linux namespacesのファイルと永続化について
ip netnsコマンドを使うと、/var/run/netnsディレクトリにファイルを足してネットワーク名前空間を足してくれたり、
/proc/[pid]/ns以下に、そのプロセスの名前空間に対応するファイルを見せてくれるのは知っていたけれど、そのあたりの扱いをうろ覚えなので少し整理.
以下、namespaces(7)より抜粋。
Bind mounting (see mount(2)) one of the files in this directory to somewhere else in the filesystem keeps the corresponding namespace of the process specified by pid alive even if all processes currently in the namespace terminate.
というわけで、/proc/[pid]/ns/ 以下のファイルをバインドマウントすればいいらしい。
ちなみに、network namespace向けのmanも読んだが、/var/run/netns/ についての記述はなかったので、このディレクトリはkernelの規定というよりは、ipコマンドが使っているだけな気がしている。
ところで、
In Linux 3.7 and earlier, these files were visible as hard links. Since Linux 3.8, they appear as symbolic links. If two processes are in the same namespace, then the device IDs and inode numbers of their /proc/[pid]/ns/xxx symbolic links will be the same; an application can check this using the stat.st_dev and stat.st_ino fields returned by stat(2). The content of this symbolic link is a string containing the namespace type and inode number as in the following example:
らしい。
/proc/[pid]/ns/ のシンボリックリンクを作ればいい...みたいに勘違いていたのはここら辺を混同した気がする。
参考
vagrant-libvirtをネストした時のネットワークアドレス衝突への対処法
vagrant-libvirtを使うと、vagrantでlibvirtをproviderとして使うことことができ、自分でvirshコマンド等をいちいち叩かなくてすごい便利なのですが、
表題の通り、ネストして使おうとするとネットワークアドレスが衝突して2段目のvagrant upに失敗します。
これは、vagrant-libvirtが使う管理用のネットワークのアドレスが、
ソースコード中にベタ書きで192.168.121.0/24にデフォルトで設定されていることが原因です。
解決策1: Vagrantfileで libvirtのデフォルトネットワークを利用する様に変更する。
まず、以下の様にlibvirtのデフォルトのネットワークアドレスを調べます。
$ virsh net-dumpxml | grep "ip address" <ip address='192.168.122.1' netmask='255.255.255.0'>
この値を元に、以下の様にVagrantfileに追記すれば、 仮想マシンがdefaultネットワークを使う様になります
config.vm.provider :libvirt do |libvirt| libvirt.management_network_name='default' libvirt.management_network_address='192.168.122.0/24' end
これでvagrant upをすればOKです。
解決策2: vagrant-libvirtのデフォルトネットワークのアドレスを変更する。
vagrant-libvirtは、デフォルトでvagrant-libvirtというlibvirtのネットワークを定義します。 このネットワークのアドレスを
virsh net-edit --network vagrant-libvirt
等で修正し、(今回は192.168.200.0/24を使う様にxmlを修正)
VM(L2)向けのVagrantfileを以下の様な内容を追加することです。
config.vm.provider :libvirt do |libvirt|
libvirt.management_network_address="192.168.200.0/24"
end
ただ、一度vagrant upをしないとvagrant-libvirtネットワーク自体が生成されてい無いので、この方法は使えず注意が必要です。
余談
なんの加減かわかりませんが、たまにDHCPでアドレスが降ってくるのが遅い場合があります...
参考
UNIXドメインソケットの通信相手（プロセス）を調べる
UNIX ドメインソケットを使っているプロセスの番号とファイルディスクリプタの番号を知りたくなったので、やり方をメモ。
以下のようにlsofコマンドを使う。
$ sudo lsof -U +E +c 15 | grep containerd systemd 1 root 48u unix 0xffff8b1691980400 0t0 106648 /run/systemd/journal/stdout type=STREAM ->INO=104729 10894,containerd,2u 10894,containerd,1u systemd-journal 530 root 21u unix 0xffff8b1691980400 0t0 106648 /run/systemd/journal/stdout type=STREAM ->INO=104729 10894,containerd,2u 10894,containerd,1u containerd 10894 root 1u unix 0xffff8b1691983400 0t0 104729 type=STREAM ->INO=106648 530,systemd-journal,21u 1,systemd,48u containerd 10894 root 2u unix 0xffff8b1691983400 0t0 104729 type=STREAM ->INO=106648 530,systemd-journal,21u 1,systemd,48u containerd 10894 root 6u unix 0xffff8b1695092c00 0t0 105834 /run/containerd/containerd.sock type=STREAM containerd 10894 root 7u unix 0xffff8b1693019400 0t0 106727 /run/containerd/containerd.sock type=STREAM ->INO=106726 11069,dockerd,7u containerd 10894 root 8u unix 0xffff8b1693019c00 0t0 106730 /run/containerd/containerd.sock type=STREAM ->INO=106729 11069,dockerd,8u dockerd 11069 root 7u unix 0xffff8b169301b400 0t0 106726 type=STREAM ->INO=106727 10894,containerd,7u dockerd 11069 root 8u unix 0xffff8b1693018c00 0t0 106729 type=STREAM ->INO=106730 10894,containerd,8u
-Uオプションで、プロトコルをUNIXドメインソケットに限定、
+Eオプションで通信のエンドポイント情報を表示、
+c 15は、コマンド名が省略されるのを防ぐために使用。
調べ不足かも知れないが、lsofのオプションにソケットのパス名は指定できなそうなので、grepで探している。
overlayファイルシステムで複数のlowerdirを使うときの順序
overlay でマウントするときの下位ディレクトリの順番をよく忘れるのでメモ
$ mkdir lower1 lower2 upper work merged $ echo 'lower1' >> lower1/file $ echo 'lower2' >> lower2/file $ sudo mount -t overlay \ -o lowerdir=$PWD/lower1:$PWD/lower2,upperdir=$PWD/upper,workdir=work \ overlay \ $PWD/merged $ cat merged/file lower1
というわけで、一番左側が上位になるらしい。
順番が紛らわしいので
-o upperdir=$PWD/upper,lowerdir=$PWD/lower1:$PWD/lower2
と書いたほうが良い気がする。
Ubuntu18.04 でbcc, bpftraceを動かす
最近流行りのeBPFを研究でつかっている？のですが、せっかくなので使い方のメモを公開しておこうと思います。
OSのセットアップ
タイトルにもあるようにUbuntu18.04を使います。
bpfは最近流行っていることもあり、新しいバージョンのカーネルでないと使えない機能もあります。
せっかくなのでカーネルのバージョンを新しいものに上げておきましょう。
また、ヘッダーも必要なので、合わせてインストールしておきます。
sudo sed -i.bak -e "s%http://archive.ubuntu.com/ubuntu/%http://ftp.iij.ad.jp/pub/linux/ubuntu/archive/%g" /etc/apt/sources.list sudo apt update LATEST_KERNEL_IMAGE=$(apt search linux-image- 2>/dev/null |egrep '^linux-image-[45].*-generic' |cut -d'/' -f1 | tail -n -1) LATEST_KERNEL_HEADER=$(apt search linux-headers- 2>/dev/null |egrep '^linux-headers-[45].*-generic' |cut -d'/' -f1 | tail -n -1) sudo apt install -y $LATEST_KERNEL_HEADER $LATEST_KERNEL_IMAGE sudo reboot
bcc
bccはbpf用のツールチェーンです。
特に、pythonモジュールを使うことで、かんたんにBPFのプログラムを動かすことができます。
Ubuntu 18.04では、aptを使えばbcc自体は入るのですが、
aptで入るbccはライブラリの依存の関係でbpftraceには使えないので、bcc自体も自分でビルドします。
基本的には公式のリポジトリの説明のとおりですが、python3で使いたいので
cmakeの際に-DPYTHON_CMD=python3を足します。
$ cd ~ $ sudo apt-get -y install bison build-essential cmake flex git libedit-dev \ libllvm6.0 llvm-6.0-dev libclang-6.0-dev python zlib1g-dev libelf-dev $ git clone https://github.com/iovisor/bcc.git $ mkdir bcc/build; cd bcc/build $ cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DPYTHON_CMD=python3 $ make -j4 $ sudo make install
これでインストールは完了です。
早速動かしてみましょう。
cd ..
$ sudo python3 examples/hello_world.py
多分これだけだと何も表示されないはずです。
それもそのはず、このpythonのプログラムは以下のようにcloneが呼ばれたらHello, World!を出力する仕様になっています。
code = ''' int kprobe__sys_clone(void *ctx) { bpf_trace_printk("Hello, World!\\n"); return 0; } ''' BPF(text=code).trace_print()
というわけで、別端末等で適当にコマンドを実行してみましょう。
（シェルのbuiltinだとcloneが実行されない場合があるので、注意）
こんな感じで出力されるはずです。
b' bash-1048 [000] .... 2985.061252: 0: Hello, World!' b' bash-1048 [000] .... 2987.416850: 0: Hello, World!'
余談ですが、python3ではなく2系で実行したらb' 'とは表示されませんでした。
python3対応が遅れてるみたいですね（涙）
なお、このブログを書いている時は Vagrantで試しているせいか引っかからなかったですが、
実機で試したときは
# echo 1 > /proc/sys/kernel/sysrq # echo x > /proc/sysrq-trigger
としなければ動きませんでした。
このあたりの問題は FAQにまとめてあるので、 動かなかったら見てみると良いでしょう。
また、もしかすると、ライブラリを認識させるために、sudo ldconfig を実行する必要があるかもしれません。
bccの使い方についての説明は今回は省略します。
bpftrace
Dtrace や SystemTapのようなツールです。
カーネル内部にさくっとフックを仕込んでトレースしたい場合に便利なツールです。
（カーネル内部だけでなく、ユーザー空間にフックを仕込むとう、幅広い使い方ができます。）
$ sudo apt update
$ sudo apt install -y bison cmake flex g++ git libelf-dev zlib1g-dev libfl-dev systemtap-sdt-dev \
llvm-7-dev llvm-7-runtime libclang-7-dev clang-7
$ git clone https://github.com/iovisor/bpftrace
$ mkdir bpftrace/build; cd bpftrace/build;
$ cmake -DCMAKE_BUILD_TYPE=Release ..
$ make -j4
$ sudo make install
さて、実行してみます。
(このプログラムは自分で終了する必要があります。数秒立ったらCtrl+Cで止めましょう。 実際の出力が出るまで少し時間がかかるかもしれません。)
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_* { @[probe] = count(); }'
Attaching 332 probes...
^C
@[tracepoint:syscalls:sys_enter_getsockname]: 1
@[tracepoint:syscalls:sys_enter_prctl]: 1
@[tracepoint:syscalls:sys_enter_adjtimex]: 1
@[tracepoint:syscalls:sys_enter_rename]: 1
@[tracepoint:syscalls:sys_enter_bind]: 1
@[tracepoint:syscalls:sys_enter_clone]: 1
@[tracepoint:syscalls:sys_enter_fchmod]: 1
@[tracepoint:syscalls:sys_enter_kill]: 1
@[tracepoint:syscalls:sys_enter_epoll_create1]: 1
@[tracepoint:syscalls:sys_enter_lseek]: 1
@[tracepoint:syscalls:sys_enter_exit_group]: 1
@[tracepoint:syscalls:sys_enter_rt_sigreturn]: 2
@[tracepoint:syscalls:sys_enter_getdents]: 2
@[tracepoint:syscalls:sys_enter_epoll_ctl]: 2
@[tracepoint:syscalls:sys_enter_socket]: 2
@[tracepoint:syscalls:sys_enter_write]: 3
@[tracepoint:syscalls:sys_enter_newlstat]: 3
@[tracepoint:syscalls:sys_enter_getpid]: 3
@[tracepoint:syscalls:sys_enter_getrandom]: 3
@[tracepoint:syscalls:sys_enter_readlinkat]: 3
@[tracepoint:syscalls:sys_enter_poll]: 4
@[tracepoint:syscalls:sys_enter_select]: 4
@[tracepoint:syscalls:sys_enter_futex]: 5
@[tracepoint:syscalls:sys_enter_munmap]: 5
@[tracepoint:syscalls:sys_enter_sendmsg]: 5
@[tracepoint:syscalls:sys_enter_inotify_add_watch]: 8
@[tracepoint:syscalls:sys_enter_access]: 9
@[tracepoint:syscalls:sys_enter_rt_sigprocmask]: 10
@[tracepoint:syscalls:sys_enter_recvmsg]: 11
@[tracepoint:syscalls:sys_enter_fcntl]: 12
@[tracepoint:syscalls:sys_enter_alarm]: 15
@[tracepoint:syscalls:sys_enter_rt_sigaction]: 20
@[tracepoint:syscalls:sys_enter_newfstat]: 30
@[tracepoint:syscalls:sys_enter_newstat]: 31
@[tracepoint:syscalls:sys_enter_epoll_wait]: 39
@[tracepoint:syscalls:sys_enter_read]: 148
@[tracepoint:syscalls:sys_enter_perf_event_open]: 150
@[tracepoint:syscalls:sys_enter_dup]: 302
@[tracepoint:syscalls:sys_enter_bpf]: 322
@[tracepoint:syscalls:sys_enter_openat]: 347
@[tracepoint:syscalls:sys_enter_ioctl]: 565
@[tracepoint:syscalls:sys_enter_dup2]: 602
@[tracepoint:syscalls:sys_enter_close]: 1029
ちゃんと動きました。
本記事はこれで終わり。
probeにも色々な種類があり、使い方に癖があったりするので、
その気になったらまた記事にするかもしれません。
Linux (Ubuntu 18.04) からUTokyo WiFiに接続する (GUI編+CLI編)
UTokyo WiFiの公式ページの記載だけでは、Ubuntuからうまく接続できなかったので、 またOSをふっ飛ばして再インストールするであろう将来の自分に向けて接続方法のメモ
GUI編
以下のように設定すれば接続できるはず。
| 設定項目 | 設定値 |
|---|---|
| Wi-Fi security | WPA & WPA2 Enterprise |
| Authentication | 保護付きEAP(PEAP) |
| Anonymous identity | 学生証に書かれた10桁の番号@utac.u-tokyo.ac.jp |
| Domain | 空のまま |
| CA証明書 | Security Communication RootCA2 を選択（詳細後述） |
| PEAP version | 自動 |
| Inner authentication | MSCHAPv2 |
| Username | 発行されたid |
| Username | 発行されたパスワード |
なお、Ubuntu 18.04 （Desktop）の場合
/usr/share/ca-certificates/mozilla/Security_Communication_RootCA2.crt
に 必要な証明書がすでに存在するので、それをCA証明書の欄で選択する。
CLI編
NetworkManager（nmcliコマンド）を用いる。 以前Lubuntuを使った際はデフォルトのGUIの設定からは設定できなかったが、このコマンドでは設定可能だったので、汎用性も高そう
$ ip a | grep w # wifiのデバイスのインターフェース名の調査 2: wlo1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 # たいていwifiデバイスのifnameは wから始まる気がする。 # ここではwlo1を使用 $ nmcli connection add type wifi ifname wlo1 con-name UTOKYO_WIFI ssid UTokyo-WiFi $ nmcli con edit id UTOKYO_WIFI # con は connection の短縮。 c１文字でもOK nmcli> set ipv4.method auto nmcli> set 802-1x.eap peap nmcli> set 802-1x.anonymous-identity 10桁の番号@utac.u-tokyo.ac.jp nmcli> set 802-1x.phase2-auth mschapv2 nmcli> set 802-1x.ca-cert /usr/share/ca-certificates/mozilla/Security_Communication_RootCA2.crt nmcli> set 802-1x.identity 発行されたID nmcli> set 802-1x.password 発行されたパスワード nmcli> set wifi-sec.key-mgmt wpa-eap nmcli> save nmcli> activate nmcli> quit
なお、nmcliのコマンドについては以下も知っておくと良さそう。
$ # 設定一覧の表示 $ nmcli connection show $ # 設定の有効化(wifiへの接続) $ nmcli connection up 設定名 # 上記の設定の場合、設定名は UTOKYO_WIFI $ # 設定の非有効化(wifiの切断) $ nmcli connection down 設定名 # 上記の設定の場合、設定名は UTOKYO_WIFI
nmcli con showでみた限り、この設定名(con-name)、たいていはssid名が直接使われていそうな気がするし、そうした方が良かったかも？
この他、nmcliを使用した(wifiの)設定方法は以下を見ると良さそう
access.redhat.com
netplan（追記）
Ubuntu18.04等だとnetplanでも設定できるらしい？ なんとなく、yamlに平文でパスワードを書くのは気が引けるけど、nmcliなら良いかというとそれもわからないし、結局は好みなのかな...？
ネットワークへの接続状況を監視してみる (Prometheus on Docker on ラズパイ)
github pagesを畳んだので、そこにあった記事の転載
現在一人暮らし中なので、自宅の回線はモバイルルーターを契約しているのだが、近頃回線がものすごく遅くなるときがある。 google.comとか1.1.1.1とかにpingを飛ばすとロス率が70%を越したり、レイテンシが500msとかになったりする。今どき地球の裏側の方がちゃんと繋がりそうだなぁなんて思いつつ、いい機会なので死活監視をしてみようと思うので記録。
ところでレイテンシといえば、Latency Numbers Every Programmer Should Knowってページを思い出した。ちなみにこのページによると、CA(カリフォルニア？)とオランダ間でのRTTは150ms程らしい。この手のレイテンシとかのオーダーの話は稀によく耳にするけど、いまいち感覚が身についている気がしない。ちゃんと覚えないとなぁ...
使用するツール
- Prometheus
- Docker / Docker Compose
- RaspberryPi(3B+)
Prometheus
監視ツールというとDatadogとかMackerelとかを聞くことが多い気がするけど、そもそも内側から見たいのでこれらを含めたSaaSは候補から除外、OSSが好きなのと、勢いがありそうだったので？Prometheusを使うことにした。
Docker/ Docker Compose
PrometheusはGolang製の単一バイナリでそのまま動くらしいので使う理由もあまりないけど、単純に趣味
強いて理由を上げるとすれば、そのうちデータベースと連携してデータを保存したりする場合にまとめて管理するのが楽そうかな〰という気分。
RaspberryPi(3B+)
24時間監視しようと思うと、普段遣いのノートPCだと辛いし、消費電力とかもヤバそうなので、ラズパイを使うことに決定。
1. ラズパイの設定
しばらく使ってなかったら、調子が悪くなっていたので、OSをクリーンインストール。
OSをインストール
パスワード設定
SSHを有効化
Dockerのインストール
公式サイトのインストール方法(Get Docker CE for Debian)に従ったらコケたので、下記スクリプトで導入
sh curl -sSL https://get.docker.com | sh
cf. 最近のRaspberry Piイメージ（Raspbian）をインストールするメモ
今回初めて知ったけれど、mDNSという仕組みがあり、それを使えばIPを固定しなくても同じLANでraspberrypi.localという名前でラズパイを参照できるらしい、これまで何度か /etc以下設定ファイルを書き換えたりしてたけど、そんな必要なかったのか〰（便利なので良いけれど）。
2. Prometheusを動かしてみる
まずはPrometheusの概要を学んでみようということで、Qiitaで以下の記事を発見
Prometheusは雑に解釈すると、以下の2種類のプログラムからなるらしい
exporter:
- 監視対象のサーバーで動作するプログラム。
- 監視するリソース毎に準備
- WebAPIの感覚で、情報をテキストベースで公開する
prometheus:
監視サーバーのプログラム
定期的に巡回してexporterから情報を収集する
というわけで、早速試してみる。
を参考にしつつ、Dockerを使いたいのでPrometheusのDockerイメージを落としてくる。
$ docker pull prom/prometheus
$ docker inspect prom/prometheus
~~~前略~~~
"Cmd": [
"--config.file=/etc/prometheus/prometheus.yml",
"--storage.tsdb.path=/prometheus",
"--web.console.libraries=/usr/share/prometheus/console_libraries",
"--web.console.templates=/usr/share/prometheus/consoles"
],
"ArgsEscaped": true,
"Image": "sha256:b452ed1aa226459ac89e04859fa746c0f15861534109fc0c9155596f0244ec22",
"Volumes": {
"/prometheus": {}
},
"WorkingDir": "/prometheus",
"Entrypoint": [
"/bin/prometheus"
],
~~~後略~~~
なんとなくPrometheusの使い方がわかったところで、
Getting Started に従い、prometheus.ymlを作成
$ mkdir -p ~/workspace/prometheus
$ cd ~/workspace/prometheus
$ cat > prometheus.yml <<EOF
global:
scrape_interval: 15s
external_labels:
monitor: 'codelab-monitor'
scrape_configs:
- job_name: 'prometheus'
scrape_interval: 5s
static_configs:
- targets: ['localhost:9090']
EOF
というわけで、さて動かすぞ！と思ったらエラー
$ docker run -p 9090:9090 -v prometheus.yml:/etc/prometheus.yml prom/prometheus standard_init_linux.go:207: exec user process caused "exec format error"
いろいろ試してみたけど、動かない。
多分イメージがx86向けなんだなぁ（動くものしかpullできないと思ってた...)
というわけで、自分でイメージを作って実行してみる
# dockerfile
FROM armhf/alpine AS build-env
RUN apk update && apk add ca-certificates wget &&\
wget https://github.com/prometheus/prometheus/releases/download/v2.9.2/prometheus-2.9.2.linux-armv7.tar.gz &&\
tar -xzf prometheus-2.9.2.linux-armv7.tar.gz
FROM scratch
COPY --from=build-env /prometheus-2.9.2.linux-armv7/* /
ENTRYPOINT ["/prometheus"]
CMD ["--config.file=/prometheus.yml",\
"--storage.tsdb.path=/data",\
"--web.console.libraries=/usr/share/prometheus/console_libraries",\
"--web.console.templates=/usr/share/prometheus/consoles"\
]
$ mkdir build $ cd build $ vim Dockerfile # 上の内容を記述 $ docker build . -t arm-prometheus $ docker run --rm -p 9090:9090 arm-prometheus
raspberrypi.local:9090を開いてみる。
良さそうだ
Exporterを導入する
Prometheusの概要のところでも少し触れたが、Prometheusでは、監視するリソース毎にexporterと呼ばれるプログラムを動かす。
今回はGithubで公開されているczerwonk/ping_exporterを使ってみる。
こちらは本当にconfigなしでも動くので、とりあえず動かしてみる。
$ wget https://github.com/czerwonk/ping_exporter/releases/download/0.44/ping_exporter-0.4.4_linux_arm
$ mv ping_exporter-0.4.4_linux_arm ping_exporter
$ chmod +x ping_exporter
$ ./ping_exporter 1.1.1.1
$ curl localhost:9427/metrics
# HELP ping_loss_percent Packet loss in percent
# TYPE ping_loss_percent gauge
ping_loss_percent{ip="1.1.1.1",ip_version="4",target="1.1.1.1"} 0
# HELP ping_rtt_best_ms Best round trip time in millis
# TYPE ping_rtt_best_ms gauge
ping_rtt_best_ms{ip="1.1.1.1",ip_version="4",target="1.1.1.1"} 88.44157409667969
# HELP ping_rtt_mean_ms Mean round trip time in millis
# TYPE ping_rtt_mean_ms gauge
ping_rtt_mean_ms{ip="1.1.1.1",ip_version="4",target="1.1.1.1"} 188.0380859375
# HELP ping_rtt_ms Round trip time in millis (deprecated)
# TYPE ping_rtt_ms gauge
ping_rtt_ms{ip="1.1.1.1",ip_version="4",target="1.1.1.1",type="best"} 88.44157409667969
ping_rtt_ms{ip="1.1.1.1",ip_version="4",target="1.1.1.1",type="mean"} 188.0380859375
ping_rtt_ms{ip="1.1.1.1",ip_version="4",target="1.1.1.1",type="std_dev"} 84.13036346435547
ping_rtt_ms{ip="1.1.1.1",ip_version="4",target="1.1.1.1",type="worst"} 348.2742004394531
# HELP ping_rtt_std_deviation_ms Standard deviation in millis
# TYPE ping_rtt_std_deviation_ms gauge
ping_rtt_std_deviation_ms{ip="1.1.1.1",ip_version="4",target="1.1.1.1"} 84.13036346435547
# HELP ping_rtt_worst_ms Worst round trip time in millis
# TYPE ping_rtt_worst_ms gauge
ping_rtt_worst_ms{ip="1.1.1.1",ip_version="4",target="1.1.1.1"} 348.2742004394531
良さそうだ。
exporterとprometheusを連携するため、prometheus.ymlを書き換える
global: scrape_interval: 15s external_labels: monitor: 'codelab-monitor' scrape_configs: - job_name: 'prometheus' scrape_interval: 5s static_configs: - targets: ['localhost:9090'] - job_name: 'ping_exporter' scrape_interval: 5s static_configs: - targets: ['172.17.0.1:9427']
さて、ここの172.17.0.1は実際にはlocalhostを指すのだが、詳しい説明は長くなるので省略。
(dockerのネットワークのホストやブリッジ等を調べるとよい) (なお、実行時に、 --network="host"というオプションをつけると、localhostでも接続可能 )
さて、もう一度prometheusを実行してみる。
$ docker run --rm -p 9090:9090 -v prometheus.yml:/prometheus.yml arm-prometheus
raspberrypi.local:9090を開き、ping_rtt_msをクエリとしてグラフを表示させてみると以下のようになった。
うまく表示できた。
しばらくpingのデータだけだと物足りない気もするが、疲れたので今日はおしまい。
しばらくデータを記録してみようとおもう。
