Prometheus2とGrafana6によるシステム監視 FreeBSDのメモリとCPU温度

前々回、PrometheusとGrafanaとNode Exporterのインストールを行った。前回は、既存のGrafanaのNode Exporter用テンプレートを貰ってきて使ったが、Linuxホストの監視用特化なのでFreeBSDのホストではメモリや温度の情報が表示されなかった。
そこで、今回はテンプレートはそのままで、Prometheus側の設定でFreeBSDの情報をLinuxの情報互換にして表示する。
初歩の初歩なので、すでにPrometheus, Grafanaを使いこなしている人にとっては見るところが無いかも。

CPU温度を取れるようにする

FreeBSDではCPUの温度はカーネルの温度関係のモジュールを使えるようにしていないと機能しないかもしれない。まぁ、システム監視をするなら間違いなく有効にしているだろうけど。

手動でカーネルモジュールを読み込んで温度を確認する方法

# kldload coretemp    #←カーネルモジュール読み込み CPUがAMD系ならkldload amdtemp
# sysctl dev.cpu | grep temperature  #←CPU温度表示
dev.cpu.3.temperature: 42.0C    #以下、CPUのコア(仮想含む)の数だけ温度が表示される。
dev.cpu.2.temperature: 42.0C
dev.cpu.1.temperature: 41.0C
dev.cpu.0.temperature: 41.0C
/boot/loader.conf (システム起動時に自動的に読み込む設定を追加)
1
2
coretemp_load="YES"  #Intel系CPU用
amdtemp_load="YES"  #AMD系CPU用

Node Exporterの情報確認

Node Exporterの情報はプル(Pull)なので、送られてくるのではなく取りに行く。つまり「http://Node Exporterホスト:9100/metrics」にアクセスしたらそのホストのNode Exporterの情報を取ることができる。
FreeBSDのホストのNode Exporterの情報を見るとメモリと温度は以下のようなの。つまり、Grafanaで見ると表示はされていないが、それらしいものは出力はされている。ただし、Linuxと比べると取得できる項目はだいぶ少ないっぽい。

メモリ
# HELP node_memory_active_bytes Recently used by userland
# TYPE node_memory_active_bytes gauge
node_memory_active_bytes 1.083392e+07
# HELP node_memory_buffer_bytes Disk IO Cache entries for non ZFS filesystems, only usable by kernel
# TYPE node_memory_buffer_bytes gauge
node_memory_buffer_bytes 1.16641792e+08
# HELP node_memory_cache_bytes Almost free, backed by swap or files, available for re-allocation
# TYPE node_memory_cache_bytes gauge
node_memory_cache_bytes 0
# HELP node_memory_free_bytes Unallocated, available for allocation
# TYPE node_memory_free_bytes gauge
node_memory_free_bytes 1.2384256e+08
# HELP node_memory_inactive_bytes Not recently used by userland
# TYPE node_memory_inactive_bytes gauge
node_memory_inactive_bytes 7.29227264e+08
# HELP node_memory_size_bytes Total physical memory size
# TYPE node_memory_size_bytes gauge
node_memory_size_bytes 1.949618176e+09
# HELP node_memory_swap_in_bytes_total Bytes paged in from swap devices
# TYPE node_memory_swap_in_bytes_total counter
node_memory_swap_in_bytes_total 0
# HELP node_memory_swap_out_bytes_total Bytes paged out to swap devices
# TYPE node_memory_swap_out_bytes_total counter
node_memory_swap_out_bytes_total 0
# HELP node_memory_swap_size_bytes Total swap memory size
# TYPE node_memory_swap_size_bytes gauge
node_memory_swap_size_bytes 0
# HELP node_memory_swap_used_bytes Currently allocated swap
# TYPE node_memory_swap_used_bytes gauge
node_memory_swap_used_bytes 0
# HELP node_memory_wired_bytes Locked in memory by kernel, mlock, etc
# TYPE node_memory_wired_bytes gauge
node_memory_wired_bytes 1.085915136e+09

CPU温度
# HELP node_cpu_temperature_celsius CPU temperature
# TYPE node_cpu_temperature_celsius gauge
node_cpu_temperature_celsius{cpu="0"} 40.9
node_cpu_temperature_celsius{cpu="1"} 40.9
node_cpu_temperature_celsius{cpu="2"} 41.9
node_cpu_temperature_celsius{cpu="3"} 41.9

Linuxと比べるとFreeBSDではメトリクス名が違うのが判るはず。LinuxとFreeBSDで明らかに対応しそうな似たメトリクス名があってもそれに値が入っていない場合は別のメトリクスから探さなければならなかったり、複数のメトリクス値から計算する必要があったり。

node exporter 1
Grafanaで使用しているテンプレートから、メモリのグラフ表示のためにの何のメトリクスを使っているかを編集モードで確認する。クエリーの全文を確認する。1つのメトリクスしか使われていないとは限らない。

FreeBSD           ⇔    Linux
メモリ
node_memory_free_bytes   ⇔ node_memory_MemAvailable_bytes
node_memory_inactive_bytes ⇔ node_memory_MemFree_bytes
node_memory_size_bytes   ⇔ node_memory_MemTotal_bytes
スワップ
node_memory_swap_size_bytes ⇔ node_memory_SwapTotal_bytes
node_memory_swap_used_bytes ⇔ node_memory_SwapCached_bytes
node_memory_swap_size_bytes - node_memory_swap_used_bytes(差分) ⇔ node_memory_SwapFree_bytes
CPU温度
node_cpu_temperature_celsius ⇔ node_hwmon_temp_celsius

「がとらぼ」の中の人はFreeBSDではスワップを使わない方針のため、ちょこっと試しただけでテキトーに書いてます。間違っていたらスミマセン。

Prometheusの設定変更

対応を調べたら、メトリクス名の書き換えをPrometheusに設定する。
このときに、ルールを書く設定ファイルを分ける。

メインのPrometheusの設定ファイル
/usr/local/etc/prometheus.yml (追記)
1
2
rule_files:
   - "prometheus_node_exporter.yml"

2行を追加する。すでに別のルールファイルを指定して使っているなら既存のルールファイルの指定行の次の行に上の2行目を指定する。
YAMLファイルは行頭の字下げに意味があるのでむやみに字下げしたり、逆に行頭のスペースを取らないこと。
ファイル名だけを指定したら設定ファイルと同じディレクトリという意味なので/usr/local/etc/prometheus_node_exporter.ymlになる。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
groups:
- name: node_exporter-FreeBSD-metrics  #何か名前をつける
  rules:
  - expr: node_memory_free_bytes                #書き換え元のメトリクス名
    record: node_memory_MemAvailable_bytes    #書き換え後のメトリクス名
  - expr: node_memory_inactive_bytes
    record: node_memory_MemFree_bytes
  - expr: node_memory_size_bytes
    record: node_memory_MemTotal_bytes
  - expr: node_memory_swap_size_bytes
    record: node_memory_SwapTotal_bytes
  - expr: node_memory_swap_used_bytes
    record: node_memory_SwapCached_bytes
  - expr: (node_memory_swap_size_bytes{job="node_exporter"} - node_memory_swap_used_bytes{job="node_exporter"})
    record: node_memory_SwapFree_bytes
  - expr: node_cpu_temperature_celsius
    record: node_hwmon_temp_celsiu

Linuxのnode_memory_SwapFree_bytes (スワップの空き容量)に相当する値はFreeBSDでは取得できないようなので、node_memory_swap_size_bytes (スワップの全容量)とnode_memory_swap_used_bytes (スワップ使用量)の差分を求めて、その値がスワップの空き容量だろうとした。何台かのFreeBSDホストでスワップを使っていたらこのメトリクス名と計算が正しいのか確認できたんだろうけど、空いてた1台に急遽スワップを作って、スワップがほぼほぼ使われない中で「これかな?」で出したので正しいかは判らない。

Grafanaでグラフ表示を確認する

Prometheusを再起動またはリロードする。

# service prometheus restart
または
# service prometheus reload

暫く待ってGrafanaにメモリ、スワップ、CPU温度が表示されればOK.

node exporter 2
前回のテンプレートではCPU温度は 下部で折りたたまれたSystem Detailを展開した最後のグラフ。

このようにメトリクス名を変換、或いは、複数のメトリクスから計算した値を渡すようにすることで、Linuxとは違う名前のメトリクスで出力されるシステムでも簡単に表示できるようになる。今回の場合はテンプレートを弄っていないので当然Linuxホストはそのまま正常に表示できる。

関連記事:

Orange Pi Zero PlusでADS-B受信

前回までは、アンテナからRTL-SDRチューナーまで20mのアンテナケーブルを通していた。
しかし、高周波で長いアンテナケーブルは大きく減衰するという情報を得ていたので、このアンテナケーブルを短くすることにした。そこで、アンテナ直下(実際にはBPF+LNAを挟んで)チューナーを繋ぎ、そこからUSBケーブルでシングルボードコンピュータに繋ぐことにした。シングルボードコンピュータは先日購入したOrange Pi Zero Plus。そこからLANは有線のネットワークケーブルで。Oragne Pi Zero PlusはArmbian (Debian buster)を入れて、ADS-Bの受信は dump1090-mutabilityを使用することにした。つまり、dump1090-Xで受信してLANにデータを流し、他のPCでその受信したデータを使う(地図にプロットするなど)することにした。dump-1090-Xにもウェブ機能があって地図にプロットして他のPCのブラウザからそれを見るということができるが、今回はOrange Pi Zero Plusが(SBCとしてはまぁまぁでもPCと比べるとかなり)非力なのでプロットは他のPCで行うということにした。それに、パッケージで配布されるdump-1090-Xは内蔵ウェブ機能が殺してあったりするし。

dump1090でADS-B受信 1
購入して開封したばかりのOrange Pi Zero PlusのSoCにヒートシンクとつなげるための銅ブロックを乗せた写真。(このときはまだ付属の無線LANアンテナがつながっている。)

dump1090でADS-B受信 2
左上がアンテナ、青い基板がBPF+LNA、緑色(+黒ヒートシンク)がチューナー、USBでつながっている右の基板がOrange Pi Zero Plus。それから生えている黒い細い線でつながった中央下寄りの金色のやつは無線LANを殺すためのダミーロード。また、Orange Pi Zero Plusから赤黒のコードが伸びているのはBPF+LNAに供給する5V+GND
と、いうことで、前回設置したアンテナの台となる塩ビパイプの中に、ほぼ一式が収まる形となる。
写っていないが、この一式に電力を供給するダイソーの2.1AのUSB ACアダプタも用意している。

dump1090でADS-B受信 3
塩ビパイプに2cm x 2cmの穴をあけた。Orange Pi Zero Plusの基板に付けた銅ブロックがぎりぎり通るサイズに穴を開ける。穴が大きいとガタつく筈なので少し小さく穴をあけて、ヤスリで削って調整した。上の写真では穴がパイプの上に近い側にあいているように写っているが、実際は上下逆。
穴のサイズは銅ブロックとぴったりであっても雨が入ると困るので穴と銅ブロックの境にはホットボンド(グルーガン)をグルリと1周。これで防水だけでなくさらにガッチリ固定できる。

dump1090でADS-B受信 4
設置した。見た目は前回と殆ど変わらない。パイプから頭を出している銅ブロックの上に(側面に)ヒートシンクを熱伝導テープで貼り付けた。このテープは圧力をかけたらその後は外れなくなるので便利。(剥がす時が怖いけど)

Orange Pi Zero Plusでチューナーの認識

Orange Pi Zero Plusにログインし、USBで繋いだRTLチューナーを認識していることを確認する。

$ lsusb
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 003: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 003 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

復調用チップはRTL2832Uの筈なのにRTL2838と認識されているが、これは気にしなくて良いらしい。
つまり、特に何もせずにUSBチューナーを挿すだけで認識されている。Windowsとは大違い。

dump1090-mutabilityのインストール

$ sudo apt update                        #←パッケージ情報を最新にする
$ apt-cache search dump1090    #dump1090-XXXを探す   (検索だけならsudo無しで可)
armbianで提供される標準レポジトリではdump1090-mutabilityだけが表示された。
$ sudo apt install dump1090-mutability

残念ながらdump1090-faは無かったが、dump1090-mutabilityがダメということではない。
とにかく、インストールはこんだけ。あっけない。

テスト起動 インタラクティブ表示+ネット出力

$ dump1090-mutability --interactive --net
もう少し指定するならこんな感じ?
$ dump1090-mutability --net-only --net-bo-port 30007 --net-bi-port 30006
とか
$ dump1090-mutability --net-only --net-bo-port 30007 --net-sbs-port 0 --net-fatsv-port 0 --net-bi-port 30006
テキトーに好みのオプションを付けてやれば良い筈

起動してエラーにならないこと。

問題ないようであれば、自動起動の設定を行う。
パッケージでインストールしたdump1090-mutabilityでは/etc/init.d/dump1090-mutabilityというスクリプトが用意されているようだが、init系のサービス起動はよくわからない。(基本的にFreeBSD派なのでLinuxはよくわかっていない)
なので、systemd用の自動起動の設定を行う。

/lib/systemd/system/dump1090-mutability.service (新規作成)
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
[Unit]
Description=dump1090-mutability
Before=multi-user.target
After=network-online.target
Wants=network-online.target

[Service]
WorkingDirectory=/usr/share/dump1090-mutability/
ExecStart=/usr/bin/dump1090-mutability --interactive --net      #←起動コマンドは好きにして
StandardOutput=null
Restart=on-failure

[Install]
WantedBy=multi-user.target
サービスの有効化 (以後、意図的に無効化するまでずっと有効+自動起動)
# systemctl enable dump1090-mutability
有効化したサービスを手動で起動
# service dump1090-mutability start
サービスを手動で停止
# service dump1090-mutability stop

armbianで提供される標準レポジトリでインストール可能なdump1090-mutabilityは内蔵ウェブサーバ機能が無効になっている。
内蔵ウェブサーバが欲しければ自分でdump1090-XXXを内蔵ウェブサーバ有効でビルドすることになるが、非力なシングルボードコンピュータで動いているdump1090-XXX側でウェブサーバを動かす必要は無いと考える(動かしたくない)。

受信したデータをWindowsで表示

今回はdump1090-mutabilityで受信したデータをLANに流しWindowsでプロットすることにした。
Windows側で使用するのは定番のVirtual Radar Serverで、ダウンロードページからダウンロードして普通に実行してインストールする。
今回はWindows用のVirtual Radar Serverを使ったが、LinuxやMacのOSXもあるのでPCなら大抵はVirtual Radar Serverは使える。

Virtual radar Server 1
WindowsではVirtual Radar Serverをインストールするとスタートメニューの「V」の中にVirtual Radarという項目が出来て、その中のVirtual Raderという飛行機アイコンをクリックしてVirtual Raderアプリを起動する。
メイン画面はこんな感じ。上の画像はすでに稼働中のVirtual Raderなので幾つか表示が入っているけど初起動なら白い罫線部分は真っ白の筈。

Virtual radar Server 2
左上のメニューから「Tools」をクリックする。
ポップアップしたメニューの一番下の「Options」を開く。

Virtual radar Server 3
左列一番上の「Data Sources」が開く筈。違うの表示されたら「Data Sources」をクリックする。
マッププロバイダはGoogle Mapsあたりが無難。Google Mapsをアプリから使うにはAPIキーが必要になるので、ブラウザを開いてGoogleに自分のアカウントでログインしてMAP APIキーを取得する。(方法はググってね)
取得したAPIキーを「Google Maps API key」の欄に貼り付ける。

Virtual radar Server 4
左列の上から2番めの「Receivers」を選択する。
上の画像では既に「Orange Pi Zero Plus」というのが登録されているが、初めて起動なら表示されない筈。
ADS-Bレシーバーを追加する場合は[+]を押す。

Virtual radar Server 5
レシーバーの登録画面
「name」欄に受信機の名前(わかりやすいの)を入力。
「Address」欄には受信機の繋がったホストのIPアドレスを入力。
「Port」欄には30003など、受信機の繋がったホストのDump1090-Xと通信できるポート番号を入力。

2021年8月14日追加 (画像無し):
Optionsの[Receiver]の下に[Receiver Location]という項目がある。ADS-Bの受信機セットのアンテナのある場所の緯度と経度を登録する。その座標が、入力して[OK]して登録できたつもりでも実は正しく登録されていないことがある。この座標が正しく登録できていないと地図上にレシーバ設置位置やその設置位置からの同心円やカバレッジが正しく表示できなくて困ることに。入力して[OK]してVirtual Radarを再起動してから再度[Options]→[Receiver Location]を開いて緯度と経度の両方が正しく登録されていることを確認。これまでの経験だと「経度」が空になっていたことが数度(毎回インストール後の設定時に発生?)。

Virtual radar Server 6
左列の「Web Server」を選択。
飛行している飛行機を正しく認識できた範囲を地図上にプロット(カバレッジ表示)するなら「Internet users can see receiver range Plots」にチェックする。初期値はチェック無し。暫く使った後はまたチェックを外すことになると思うけど。

Virtual radar Server 7
設定したら最初の画面に戻って、ウェブサーバがオンラインになっていることを確認。またはオフ・オンするなど。
オンライン・オンラインの切り替えは、右上のボタンを押す。

Virtual radar Server 8
もう一度メニューから[Tool]s → [Options]を開いて、左列から「Web Site」の下の「Initial Settings」を選択する。
右上にURLが幾つか表示される。メインで使うのは一番上。それをクリックするかリンクをコピーしてブラウザで開く。

Virtual radar Server 9
ブラウザでDesktop Siteを開いて暫く〜1日くらい待つ。
設定でカバレッジをプロットするようにしたので、受信機から飛行中の飛行機が正しく認識されている範囲(Virtual Radar起動から現在)が透過黒色で地図上に表示されている。(上の画像の地図の中央のギザギサの黒っぽいやつ)
この範囲は、完全に認識された飛行機が通った最も遠い場所を示すので、認識が中途半端な飛行機がもっと遠くを通っても範囲は広がらない。逆に言えば、不正確に認識された飛行機はカバレッジのエリアの外をいっぱい飛んでいる。
眺めていたら右下のリストで飛行機の高度がGNDと表示されていてどこかの飛行場にいるらしいのも認識されている様子。上の地図のカバレッジの範囲内には飛行場は無いと思うので、福井・小松・小牧・中部国際、関空・伊丹・神戸のどれかに居る飛行機の筈。つまり結構広い範囲が不正確ながらも受信出来ている様子。東の方はカバレッジでは一宮辺りまでとなっているが、右下のリストに表示される飛行機の登録番号から確認すると木曽山脈に近い中津川あたりの上空を飛行する機からも不完全ながらも信号が届いているよう。

Virtual radar Server 10
地図の全画面表示もできる。日本の本州の形が判るくらいで表示すると、カバレッジ狭いなぁ。アンテナ設置場所からの距離でこの1.5倍くらいは欲しい。できたら大阪湾と伊勢湾の上空にいる飛行機の信号が届いて欲しい。飛行場とか低高度に居るのまで受信したいなんて贅沢は言わないから。

20mのアンテナケーブルを無くすともっと広い範囲(全方位で100km以上程度)を確実に受信できるのかと期待したが、20mのアンテナ線を使った前回と比較して、アンテナ設置場所からの距離で1〜2割程度増えただけでで思ったよりもカバレッジは広がらなかった。しかし、認識される飛行機の数は大幅に増えていて、さらにカバレッジ内外の中途半端認識機の数が凄い。アンテナ設置場所が周囲を山に囲まれているので全方位で100km, 150km、山が無い方向で200km, 300kmというのは無理かと思ったが、アンテナを良くすればチャンスありかもと期待してしまう。
購入した1090MHzのアンテナは6dBiと書かれたシールが貼ってあったが、信じていない。同様のアンテナが2dBi程度なのでそれと同じ程度の筈だと思っている。4千円〜1万円程度の市販アンテナを買うのもアリだろうけど、テキトーに自分で作ることを考えている。アンテナの性能を測定する機械を持っていないので段数の多いコリニアアンテナとかは無理だけど。

あと、アンテナ下の塩ビパイプは密封ケースに近い状態だけど、そこに熱源のRTL-SDRレシーバーとシングルボードコンピュータが入って中がかなり高温になっている模様。シングルボードコンピュータのSoCの熱の幾らかはヒートシンクから外部に放出されている筈だが、RTL-SDRレシーバはパイプ内に熱を吐いたのがそのままパイプ内に留まるし、パイプに当たった太陽の熱もパイプ内を温める。OrangePi Zero Plus内蔵のSoC温度計によると午後の一番暑い時間だと70度を示すほど。Orange Pi Zero Plusとヒートシンクだけを室内で動かしたときは50度を超えることはなかったのでやはり高温。Orange Pi Zero Plusは多少の高温でも大丈夫かもしれないが、RTL-SDRレシーバがそれに近い温度で大丈夫かしら。
今度、自作アンテナに取り替える際にパイプの排熱も少し考えたい。(その頃には気温が下がってるかもだけど)

関連記事:
Up