検索条件

から
検索タグ ソフトウェア::OpenWrt
タグで絞り込み Webサービス(1) Webサービス::Value-Domain(1) ジャンル(9) ジャンル::ガジェット(3) ジャンル::自作PC(1) ジャンル::自宅サーバー(9) ジャンル::買い物(2) ネットワーク(6) ネットワーク::DNS(1) ネットワーク::IPv4(2) ネットワーク::IPv6(2) ネットワーク::OCNバーチャルコネクト(2) 技術(1) 技術::監視(1)
日付で絞り込み 2025年(9) 2026年(4)
全13件 (1/3ページ) 一覧表示に切り替え

2026/07/16(木)R86S U1のNICを交換した

投稿日：

R86S U1のNICについているSFP+ポートの片方が不安定という問題があり、これがずっと悩みの種だった。

しかしR86S U1のNICはOCP2.0のメザニンカードという特殊な規格であり、入手が難しかった。あと最近なんでも高いことや、ここ一年近く財政が悪く資金がショートしていたこともあり、中々購入のタイミングがなかったが、偶然安いのを見つけたので交換を決意した。

購入したもの

ほぼ新品 Mellanox ConnectX-4 CX4421A MCX4421A-ACQN ネットワーク インターフェイス PCIe カード (OCP2.0 用)

ほぼ新品とあるが中古なのは間違いない。

写真を見る限り左右でコネクタが異なるといったこともなく、3,745円でConnectX-3からConnectX-4に上げられて不調もなくなるならアリではないか？と思い、購入することにした。

配送

荷物はいつも通りCainiaoから発送され、国内ではエスポ便という聞いたこともない業者に引き渡された。軽く調べたところ株式会社エスポリアという越境ECのサービス会社がやっているようで、ここ最近のアリエクに増えているらしい。ここ自体は仲介業者で配送はしてないらしい。

そういえば最近中華特有のテカテカしたプチプチ袋減った気がする。

実際の配送はかつてAmazon便で悪名を馳せたTMG、椿本グループだった。久々に見たので、一般消費者向け宅配便事業で生きてたのかお前…となった。

開封の儀

結構ちゃんとした箱に入っていた。

中身。緩衝材が底にあり、本体も一応元袋らしきものに入っていた。いい感じのヒートシンクがついているのが素晴らしい。

賞味期限ラベルみたいなものが貼ってあったが非常に強力なシールで、爪でカリカリすると爪が削れるレベルで剥がせなかったため剥がすのを諦めた。

新旧比較をすると上が今まで使っていたやつで、下が今回新たに買ったやつだ。

裏返したところ。裏面には薄いアクリルフィルムが基板を保護するように付いていた。短絡防止用だろうか？ヒートシンクを支えるプッシュピンも見えた。

ラベルを見る限り2019年6月製とみられ、比較的新しい製品なのも嬉しい。以前使っていたConnectX-3は製造時期不明だがCX342Aは2015年のモデルらしいので、だいぶ古い。

どこで見たか記憶にないがConnectX-3はサポート切れが近いか、切れていることもあるという話も見た気がするのでConnectX-4を入手できたのはよかった。メイン機もサーバー機もNICはConnectX-4なのでお揃いになった。

装着は既存のConnetX-3を外し、カードを刺す場所に元々ついてたチップクーラーを除去して取り付けたら、そのまま何事もなく普通に装着できた。

このクーラーがあるとヒートシンクに干渉するので、外す必要があった。

OpenWrt上でのセットアップ

OpenWrt 24.10.0にはドライバがなかったのでドライバを入れるのをやっていく。

SFP+以外に接続手段のない私の環境ではルーターのSSHに繋ぐ術がなかったので、R86S U1本体にキーボードとモニタを接続して作業した。

# まずはNIC周りの調査ツールを入れる
opkg update
opkg install pciutils ethtool

# ドライバの状態とかが見れる
# Kernel driver in use: igcならドライバがない
lspci -nnk

# ドライバを入れる。kmod-mlx4-coreは後で消した
opkg install kmod-mlx5-core
# JISキーボードだとアンスコが出せないので頑張って探して打った
modprobe mlx5_core

あとはこのまま再起動したら普通に繋がった。

そのまま使うと温度が上がりすぎた

現状片側のSFP+しか使っていないうえ、それも初日なので不具合は何もない。以前使っていたのも最低でも一週間は使ってないと不安定化しなかったので、まだ安定性は不明だ。

ただソケットが両方とも同じ形に見えるので、以前使っていたものよりは安定するのではないかと考えている。

温度については高くなりがちなようで、R86S U1本体のCPU温度が51度に達することもあった。

以前のNICの温度はデータがなく比較できないのだが、ここまで上がっていることはなかった気がしている。

NIC本体の温度は取得する方法が今のところ分かっていない。mstflintでmstflint -d xxxx -reg_name MTMPとかしたら、提供されていないとか出た気がするがログは取っていない。

参考までに以下の手順でレジスタの値が取れるっぽい。参考：man/mstreg

# 必要なツールのインストール
opkg install lspci mstflint
# MellanoxのデバイスIDの取得
lspci | grep Mellanox | awk '{print $1}'
# レジスタ名一覧
mstflint -d <デバイスID> -show_regs
# レジスタ値の取得
mstflint -d <デバイスID> -reg_name <レジスタ名> -g

関係ないがデータがないのはGrafanaに出しているデータを永続化していないため、tmpが吹き飛ぶと消える状態なので、ここはそのうち何とかしないといけない。

冷却対策

端的に言うとヒートシンクを剥がし、R86S U1に元からついてるクーラーを装着した。

まずはConnectX-4を取り出し、ヒートシンクを外し、グリスを塗りなおす。この時ついでに裏のフィルムも剥がし、熱が溜まらないようにした。

R86S U1に元々ついてたチップクーラー（前述の奴）を持ってきて、付け直した。

ファンレス冷却（ヒートシンク）とファン冷却（クーラー）で同時刻に温度を比べたところ、5度ほど下がるという結果が出たので、かなり効果があった。

新しい奴のヒートシンクの方が目が細かく作りもしっかりしているように見えるが、風のあるなしがそれほどまでに大きいということだろう。

しょぼいヒートシンクと小さいファンの組み合わせなのであまり意味がないだろうと侮っていたが、結果は歴然だった。恐らくこれはケースが小さく通気の余地が少ないこともあり、自然対流には期待できないということの表れなのだろう。

ベンチマーク

以下の構成で速度を計測した結果。そもそもLAN内でパケットがルーターの中を通っているかが謎なのでルーターNIC交換の影響があるかどうかは不明である。

Windows - R86S U1 - MikroTik CRS305-1G-4S+IN - Ubuntu

以前の計測結果はこっち。

Windows → Ubuntu

[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.01   sec  1.07 GBytes  9.13 Gbits/sec
[  5]   1.01-2.01   sec  1.09 GBytes  9.36 Gbits/sec
[  5]   2.01-3.00   sec  1.08 GBytes  9.36 Gbits/sec
[  5]   3.00-4.00   sec  1.09 GBytes  9.36 Gbits/sec
[  5]   4.00-5.01   sec  1.10 GBytes  9.36 Gbits/sec
[  5]   5.01-6.00   sec  1.08 GBytes  9.36 Gbits/sec
[  5]   6.00-7.01   sec  1.10 GBytes  9.36 Gbits/sec
[  5]   7.01-8.01   sec  1.09 GBytes  9.36 Gbits/sec
[  5]   8.01-9.01   sec  1.09 GBytes  9.36 Gbits/sec
[  5]   9.01-10.00  sec  1.08 GBytes  9.36 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  10.9 GBytes  9.34 Gbits/sec                  sender
[  5]   0.00-10.00  sec  10.9 GBytes  9.33 Gbits/sec                  receiver

Ubuntu→Windows

[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  1.08 GBytes  9.30 Gbits/sec    0   1.54 MBytes       
[  5]   1.00-2.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.62 MBytes       
[  5]   2.00-3.00   sec  1.08 GBytes  9.27 Gbits/sec    0   1.70 MBytes       
[  5]   3.00-4.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.78 MBytes       
[  5]   4.00-5.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.78 MBytes       
[  5]   5.00-6.00   sec  1.08 GBytes  9.29 Gbits/sec    0   1.78 MBytes       
[  5]   6.00-7.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.78 MBytes       
[  5]   7.00-8.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.93 MBytes       
[  5]   8.00-9.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.93 MBytes       
[  5]   9.00-10.00  sec  1.08 GBytes  9.28 Gbits/sec    0   1.93 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  10.8 GBytes  9.28 Gbits/sec    0             sender
[  5]   0.00-10.00  sec  10.8 GBytes  9.28 Gbits/sec                  receiver

まとめ

前回と比較すると若干速度が落ちているが、サーバーとして動かしてて帯域を食っている分減っているのかもしれない。

Windows→Ubuntu(上り) Windows→Ubuntu(下り) Ubuntu→Windows(上り) Ubuntu→Windows(下り)
9.34 Gbps 9.33 Gbps 9.28 Gbps 9.28 Gbps

交換前のConnectX-3が改造品だった話

以前使っていたPCB000620は元々SFP+片ポートモデルで、どうやらR86S U1では2ポートに改造していたようだ。

その影響なのか明らかに片方だけソケットの形が異なる。上側のほうが綺麗で、下側は使いこまれているのか、ややぼろ目に見える。

裏面を見ると片方ははんだ付けされているが、片方は差し込んであるだけ。シールも一度剥がしたものを貼り付けているのか、ペラペラしていてすぐに剥がせた。

おそらく上側（PORT 0）のはんだ付けされていた方が本来のソケットで、後から付けたやつ、つまり下側（PORT 1）が差し込んだだけの奴と思われる。

本来のソケットがぼろい方、後付けのが綺麗な方である。

奥の方の作りも異なる。左がPORT 0、右がPORT 1。

R86S U1のNICについているSFP+ポートの片方が不安定だった話で不安定だったのはPORT 1の方なので、改造して無理に取り付けていた方が不具合を発していたのだろう。本来できないことをしているので無理もない。

裏面の形も異なる。

恐らくよくある片ポートの奴にソケットを増設したのだと思う。

ソケットが片ポートしかなくても回路が実装されていることはよくあるので、この回路を流用しているのだと思う。回路もあるし、チップも恐らく同じなので原理的には問題なく動きそうに思える。

R86S U1のSFP+を使い始めたのは2025年の9月17日からだった[1]が、同年12月13日にはリンクアップとリンクダウンが繰り返される事象を確認していて、同年12月25日にSFP+差し込みポートの変更を行ってからは一度も起きていない。

この時の気温が落ちたので金属製のSFP+ソケットの接触不良になったのではないか？と考えていたが、恐らくソケットではなく、基板本体との接触が寒暖差でダメになったのかもしれない。実際、先ほどの写真を見ても基板の穴からピンが出たり出ていなかったりするので、寒暖差でここが僅かに狂った結果、基板と接触不良になり、回路がチャタリングした結果、リンクアップとリンクダウンをミリ秒単位で繰り返す状態が起きていたのかもしれない。

もし、この理屈が正しければ強く押し込んではんだ付けすれば改善しそうではある。

あとがき

NIC交換の時に取り出した時、酷い埃まみれになっていたのでいい加減、冷却面をどうにかしたい気がしている。

普段は上に80mm角ファンを載せて運用しているため、埃の元凶はこれである。一旦はファンフィルターを買ってその場を凌ぎたいところだが、本質的にはちゃんとしたケースに収めてちゃんとしたクーラーをつけるのが最良だと思っている。

R86S U1を冷やそうとした作業の残渣にも書いているが、R86S U1の冷却機構は耐久性があるように見えず、また大して冷やしてもくれない。上にファンを載せて風を入れていると、いつの日か中が埃まみれになってしまうし、このケースはメンテナンス性が良くないので清掃も面倒だ。

理想論としてはこんな感じのケースに組み込めればよいだろう。これならメンテナンスがしやすいし、NICのヒートシンクも元の奴が生かせそうだ。ファンも40mm角ファンだろうから壊れても交換が容易である。

まぁこれは行き過ぎとしても、ラズパイのタワークーラーを載せるとか、そういうのができるとよいなとは思っている。基板むき出しは埃が溜まってショートしそうなので、ケースもあった方がいいだろう。

ただそれをどう実現するかが難しいところで、まず本来的には3D CADでケースやCPUクーラーをモデリングし、CNCで金属を削るという工程が必要だろうが、そんなものはないし、仮に3Dプリンタである程度何とかするにしても、3D CADの使い方を学ぶところからだと気が遠くなる話で、なかなか難しい…。

そもそもノギスで測っても測るたびに数ミリ単位の誤差が出るので、アナログな図面を書くことすら困難だ（多分ノギスの角度が微妙に毎回ズレてる）

こんなことであれば去年アリエクのセールでファンレスのR86SであるR86S-FLN100を買っておけばよかった。今は22.7万もするが、去年は11万くらいで、セールでは9万にまで落ちていて、買いだった。まぁあとからは何とでも言えるし、そもそも9万でも安くないわけで、言ったところで仕方がない。

現実案としては厚紙にボードを固定して外枠をペンで引き、ネジ穴については基板のネジ穴スレスレの何かを差し込んでマーキングすればそれなりに正確なものが取れるだろうから、一度手書きで図面を書き、それを基にアクリル板を加工し、簡単なケースを作るのが一段階目としてはよさそうな気がする。

ただCPUクーラーをどうするかという問題が根深く、ここが難点になると思う…。これはCPUクーラーを作るにはCPUのヒートスプレッダに乗ってくれるヒートシンクを持ったファンと、そのファンと基板のネジ穴を繋ぐ足が必要になるからだ。ヒートシンクと基板のネジ穴がマッチしないとならないので、恐らくこれが一番の難関だろう…。

たぶん厚紙→アクリル板がいければ図面を起こせるので、カスタムアルミケース業者に発注すれば、きちんとしたものも作れると思う。そこまでやるかどうかは未定だが…ｗ

  1. 宅内に10GbE環境を導入してみたの写真のタイムスタンプから推定。 ↩
コメント（0件）

2026/07/10(金)OpenWrtでDHCPを払い出し直す方法

投稿日：

接続端末の追加・変更などでDHCPの変更をしたいときに、既存の払い出し期限を待たずに即座に新しい設定を反映させる方法。

確認環境

Env Ver
OpenWrt 24.10.0 (r28427-6df0e3d02a)
dnsmasq 2.90-r4

やり方

  1. DHCPの設定を必要に応じて変更する

    • LuCIからやってもいいが、ファイルベースでやる場合は/etc/config/dhcpを開いて直すとよい。形式は次のような感じ

      config host
       option name 'hoge'
       list mac '12:23:34:55:56:1A'
       option ip '192.168.12.10'
       option leasetime 'infinite'

config host
       option name 'piyo'
       list mac 'F3:BB:11:22:34:2F'
       option ip '192.168.12.15'
       option leasetime 'infinite'

  2. 接続している機器をすべて切断する

  3. DHCPキャッシュを消して、dnsmasqを再起動する 
    rm /tmp/dhcp.leases
/etc/init.d/dnsmasq restart
  4. 接続している機器を再接続する
コメント（0件）

2026/02/22(日)OpenWrtからValue-Domainに複数サブドメインのDDNSを行うツールを作った

投稿日：

Value-DomainのダイナミックDNSエンドポイントは60秒以内に叩くとエラーが返ってくるので、これを回避するためのDDNSの仕組みを作った話。

やったこと

まず、Value-DomainのDNS APIに対し、既存のaレコードをバルクで差し替えるためのツールとしてvd-ddns_v4.plを作った。

そしてhotplug.dにPPPoEインターフェースのIPが変わったときに、このスクリプトを蹴る処理を書いた。

この記事の前提構成

OpenWrtにIPv4用のPPPoEインターフェースがある。

やったこと

  1. 今回利用するのに必要なPerl周りをセットアップする。ストレージの空きが3.2MBほど必要
  2. value-domain-dns-utilを/root配下とか適当な場所に放り込む
    • opkg install openssh-sftp-serverでSFTPを導入しておくとファイル移動に便利

  3. vi /etc/hotplug.d/iface/40-pppoeとかして、OpenWrtのインターフェースが変化したときのHookを作る

     #!/bin/sh
 # デバイスが存在しなければ終了
 [ -n "$DEVICE" ] || exit 0
 # リンクアップでなければ終了
 [ "$ACTION" = ifup ] || exit 0
 # インターフェース名がPPPoEのものでなければ終了
 [ "$INTERFACE" = wanppp ] || exit 0
 # pppoe-wanpppのIPv4アドレスを取得
 pppoeaddr=$(ip -4 addr show pppoe-wanppp | head -2 | tail -1 | awk '{print $2}')
 # ログに吐く
 logger -t "DDNS - PPPoE IP" $pppoeaddr
 # DDNSもどきを叩く
 /root/vd-dns-util/vd-ddns_v4.pl 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' example.com $pppoeaddr hoge fuga piyo
 # 結果をログに吐きたいが何故か動いていない
 if [ $? -eq 0 ]; then
 logger -t "DDNS - UPDATE SUCCEED"
 else
 logger -t "DDNS - UPDATE FAIL"
 fi

  4. PPPoEインターフェスをRestart

  5. Value-Domainのコンパネで指定したドメインのaレコードが更新されていることを確認

備考

一般的にDNSレコードの浸透時間は更新前に浸透していたTTLに依存し、Value DomainのAPI経由で普段から操作している場合は120秒以下にならないため、最大120秒のダウンタイムが発生するが、理論上は公式のDDNS機能と大差ないはずと思われる。

aレコードのみの対応にしているのは私の環境だとIPv6は変動しないが、v4はそれなりの頻度で変わるためだ。

運用しているMastodonのv4が変わったのに気づかないまま疎通できないインスタンスが出てくることがしばしばあり、手動で対応するのが手間なのと、毎回一日くらい気づくのに遅れるので今回自動化に踏み切った。前々からやり勝ったのだが、中々腰が重く進んでいなかった。

そもそもこの手のものは監視システムで検知できて然るべきなので、おいおい監視システムの構築もしていきたいところだ。

コメント（0件）

2026/02/22(日)OpenWrtにPerlを入れてHTTPSやJSON、自作ライブラリを扱えるようにする

更新日：
投稿日：

確認環境

OpenWrt 24.10.0

やり方

opkg install perl
opkg install perlbase-essential
opkg install perlbase-json-pp
opkg install perlbase-scalar
opkg install perlbase-xsloader
opkg install perlbase-dynaloader
opkg install perlbase-list
opkg install perlbase-bytes
opkg install perlbase-findbin
opkg install perlbase-http-tiny

# OpenWrtにはPerlのSSLモジュールがないので親切な人が作ってくれてるものを使わせていただく
# https://jw2013.github.io/openwrt-packages/
opkg install libustream-mbedtls
wget https://jw2013.github.io/openwrt-packages/public.key
opkg-key add public.key
echo 'src/gz pkgs-by-jw2013 https://jw2013.github.io/openwrt-packages/24.10/x86_64' >> /etc/opkg/customfeeds.conf
opkg update
opkg install perl-net-ssleay
opkg install perl-io-socket-ssl
rm public.key

増加する容量

キビバイトやメビバイトのバイト変換やトータルビバイトはLLMに換算させた欠化を書いているので誤りが混ざっている可能性がある。大まかには合っていると思うが…。

pkg size byte
perl 1.27 MiB 1,331,692
perl-io-socket-ssl 124.00 KiB 126,976
perl-net-ssleay 153.61 KiB 157,297
perlbase-autoloader 3.04 KiB 3,113
perlbase-b 106.07 KiB 108,616
perlbase-base 4.27 KiB 4,372
perlbase-bytes 1.23 KiB 1,260
perlbase-class 3.02 KiB 3,092
perlbase-config 18.55 KiB 18,995
perlbase-cwd 11.31 KiB 11,581
perlbase-dynaloader 4.50 KiB 4,608
perlbase-errno 3.22 KiB 3,297
perlbase-essential 23.79 KiB 24,361
perlbase-fcntl 7.36 KiB 7,537
perlbase-feature 2.68 KiB 2,744
perlbase-file 72.30 KiB 74,035
perlbase-filehandle 1.81 KiB 1,853
perlbase-findbin 1.98 KiB 2,028
perlbase-http-tiny 12.98 KiB 13,292
perlbase-i18n 21.21 KiB 21,719
perlbase-integer 1.12 KiB 1,147
perlbase-io 67.71 KiB 69,335
perlbase-json-pp 11.96 KiB 12,247
perlbase-list 23.14 KiB 23,695
perlbase-locale 10.98 KiB 11,244
perlbase-mime 6.50 KiB 6,656
perlbase-params 4.02 KiB 4,116
perlbase-posix 40.45 KiB 41,421
perlbase-re 285.55 KiB 292,403
perlbase-scalar 1.60 KiB 1,638
perlbase-selectsaver 1.27 KiB 1,300
perlbase-socket 19.49 KiB 19,958
perlbase-symbol 1.94 KiB 1,987
perlbase-tie 18.40 KiB 18,842
perlbase-unicore 779.16 KiB 797,860
perlbase-utf8 1.24 KiB 1,270
perlbase-xsloader 2.54 KiB 2,601
total 3.08 MiB 3,230,188
コメント（0件）

2025/10/14(火)Openwrt本体でメトリクスをグラフで見れるようにした

更新日：
投稿日：

luci-app-statisticsとcollectdを入れて下図のように各メトリクスのグラフを見れるようにした。collectdは、システム情報を定期的に収集し、さまざまな方法で値を格納するメカニズムを提供する小さなデーモンで、luci-app-statisticsはそれをLuCI上に表示するためのものっぽい。

確認環境

Env Ver
OpenWrt 24.10.0

セットアップ

  1. LuCIを開く
  2. System→Software
  3. luci-app-statisticsを入れる
  4. 画面リロード
  5. Statics→Graphからグラフが見れることを確認

この時点で幾つかのプラグインが導入されたが、消したり入れたりして、結果として以下のものを導入した。

Collectdのプラグイン設定

/etc/collectd.confをいじると変更できる。

基本的にはLoadPlugin hogeでhogeプラグインを読み込み、以下の書式で設定するようだ。設定がなければLoadPlugin hogeだけでよい。

<Plugin hoge>
        Foo true
        Bar 1
        Baz "fuga"
</Plugin>

Collectdのプラグイン

collectd-mod-cpu：CPU使用率

collectd-mod-cpu

設定 内容 デフォルト
ValuesPercentage trueであれば、パーセンテージで取れる true
ReportByCpu trueであれば、コアごとに取れる true
ReportByState trueであれば、システム、ユーザー、アイドルなど、状態ごとに取れる true

設定はデフォルトのままで良さそう。

collectd-mod-interface：ネットワーク転送量

collectd-mod-interface

Network→Interfaces→Deviceにあるものが見れる。

br-lanとMAP-E、PPPoEが見たいので以下のようにした。

LoadPlugin interface
<Plugin interface>
        Interface "br-lan"
        Interface "map-wanmap"
        Interface "pppoe-wanppp"
</Plugin>

collectd-mod-load：負荷(Load Average)

uptimeコマンドで出てくる内容と思われる。1を超えていれば過負荷、割っていれば余裕がある。

Wikipediaによると、1ならその時間平均で全てのプロセスが実行され、1.73なら73%のプロセスが実行待ちになったと言う事のようだ。これを1分、5分、15分の平均で出しているとのこと。

設定項目がない。

collectd-mod-memory

メモリの使用量を取れる。

設定 内容 デフォルト
ValuesAbsolute 物理メモリ使用量の絶対数で報告するかどうか（つまりどういうこと？） true
ValuesPercentage メモリ使用量をパーセンテージで報告するかどうか false

設定はデフォルトのままで良さそう。

collectd-mod-thermal

デバイスの温度を取れる。

設定 内容 デフォルト
ForceUseProcfs Linuxインターフェースではなく、procfsから熱源を取得する false
Device 温度を取得するデバイス名
IgnoreSelected trueにするとDeviceで指定したデバイスを集計外にする false

R86S U1の場合、thermal_zone1以外無価値に見えたので、thermal_zone1のみとした。thermal_zone0はマザーボードの温度のようだが、固定値しか出てこない。

LoadPlugin thermal
<Plugin thermal>
        Device "thermal_zone1"
</Plugin>

これだけだと余計なグラフが出てくるため、設定後に余計なグラフデータを削除する。

collectd-mod-uptime

公式にマニュアルはなさそうだが、起動時間を見れる。

LoadPlugin uptime

collectd-mod-rrdtool

collectdが取得したメトリクスを保存したり、メトリクスのグラフを書くのに使われている模様。特に設定せずとも勝手に設定されるため設定を気にする必要性はなさそう。

ログは標準では/tmp/rrd/OpenWrt/に保存されているようなのでストレージの摩耗は気にしなくていい。（/tmp/はオンメモリストレージ）

トラブルシューティング

Thermalタブに壊れて表示されていない画像や、集計対象外のグラフが表示される

上図の青枠のように壊れて表示されていない画像や、集計対象外のものが表示されている場合、/tmp/rrd/OpenWrt/配下にある不要なメトリクスを削除することで非表示にできる。

例えば上図にあるthermal-cooling_device*にはまともにデータが入っていないため、画像が壊れて表示されている。rm -Rf thermal-cooling_device*で消すと出てこなくなる。

上図の状態になると、下図のように不要なグラフが表示されなくなる。

但しcollectd.confで以下のようにデバイスを絞っていないと、再び出てくると思われるので、設定で表示したいものだけに絞ってから消した方がよい。

LoadPlugin thermal
<Plugin thermal>
        Device "thermal_zone1"
</Plugin>

参考

コメント（0件）