Zabbix Proxy導入で躓いたとこ

振り返れば当たり前なんだが気づくのに3時間ぐらいかかったので戒めに書いておく。

なんやかんやあって、30台以上のラズパイを管理しているので監視用にZabbixを導入している。
システム部門でもなく生産技術の人間なので、サーバを新たにたてるわけにもいかず、部門NASとして導入しているSynologyのDS718+でZabbix ServerとZabbix FrontendをDockerで起動させ、DBはIoT用としてシステム部門に用意してもらっているものに間借りさせている。

今までは、用途的に必要があり社内LANに直接つながるものばかりだったので特に問題なかったが、社内LANとはつながらない設備内固有のLAN内に設置するもの(以降Aと呼称)が出てきた。
幸い同一の設備内LANには別用途ですでに社内LANにもつながっている個体(以降Bと呼称)がいるので、そいつにZabbix Proxyを導入することで対処しようとした。

で、単純にBで"sudo apt install zabbix-proxy-sqlite3"としてインストールして"/etc/zabbix/zabbix-proxy.conf"いじって、AのZabbix Agnetの向き先をBとしてリロードしたら以下のエラーメッセージ。

No active checks on server: host [****] not found

Zabbix Proxy側には以下のようなメッセージ。

cannot send list of active checks to [***]: host [***] not found

Zabbix Server側の設定を見直したり、Agent側の設定を変えたりしたけど状況変わらず。
そもデフォルトの設定ではServerとProxy間の設定情報の更新は1時間ごとなので、Sever側の設定を変更しても最長1時間Proxyには影響を与えない。
それにしてもおかしいと思いログを見直したらProxy側に以下のようなメッセージもあるのに気づく。

failed to update local proxy configuration copy: invalid table name "interface_snmp"

ググったら以下が引っかかる。
www.zabbix.com

そういえば、数カ月前にServer側を4.4から5.0LTSにバージョンアップしたなあと思いだすも、以前調べたときはAgentとバージョンが異なってもServer側のほうが上なら問題ないとなっていたから気にしていなかったし、ラズパイ自体もその間にStretchからBusterに上げていたからバージョン不一致は解消されたんではと思っていた。
しかしながらDebian側のリポジトリはBusterでも4.0なのね。
普段使ってるのFedoraだからディストリのバージョンを最新にしたらパッケージ自体もアップストリームのほぼ最新を追随してると無意識に思っちゃったけど、そういえばDebianはそんなことないわ、むしろStable=OLDな世界だったわ。

upstreamからパッケージ持ってきてProxyのバージョンも5.0LTSに上げたら、何の問題もなくServer上でProxyの先のAgentを認識できた。
まあ、設定自体は正しかったし当然ではある。

結論として、Agent自体はServerより古いバージョンでも問題ないけどProxyはServerと同じバージョンじゃないとダメ。

ラズパイ用の電源#2

以下の続き。
masahero.hatenablog.jp


要求仕様を満たすために考えるべきことは、まずどうやって入力消失後30秒間出力を維持するか。
とりあえずぱっと思いつくのは以下の2つ。

それぞれのメリット/デメリットは以下の通り。

  • コンデンサ
    • メリット
      • 充電は特に制御が必要ない
      • 5年程度では劣化を特に気にする必要がない程度には長寿命
    • デメリット
      • 放電時は残容量に従い線形に電圧が低下するので電圧を一定に保つには何らかの制御が必要
      • 容量が少ない
  • 二次電池
    • メリット
      • 放電時の電圧変動が少ない
      • 比較的容量確保が楽
    • デメリット
      • どのタイプの二次電池かにもよるが大抵充電制御が必要
      • 寿命を気にする必要あり


どちらにするか決めるためにも、求めるものを整理していく。

ラズパイシャットダウンの時間確保用なので最終の出力電圧は5V、ラズパイの最新モデル4Bが資料によると最低2.5Aを必要としているようなので最低でも5 \times 2.5 = 13で13Wを30秒間出力できるもの。
13Wを30秒なので、13 \times (30 / 60 / 60) = 0.1083...でだいたい110mWh、ないし13 \times 30=390で390J。

容量だけを考えると二次電池ならかなり小さいものでも余裕で確保できるが、小さいものだと出力2.5Aを確保できない。
二次電池から選択する場合は、容量よりも電流量がネックになる。
ちょっと調べてみた限りではリチウムイオンだとかニッケル水素は2.5Aを確保しようと思ったら2.5Ah以上が必要みたい。
電池のデータシートにやたらとCが出てきて、最初電荷の単位クーロンだと思ってて意味不明すぎたんだが、どうも全然別の単位で全容量を1時間で放出しきる電流量が1Cらしい。紛らわしすぎる。
リチウムイオンだとかニッケル水素の電池が1C以上取り出しちゃいけないようなので、30秒間だけのはずが1時間以上持つものが出来上がってしまう。
期待していなかった鉛蓄電池が重いけどこの用途には向いてるみたい*1

コンデンサの場合、大容量を確保しようと思うと電気二重層タイプになる。
しかし電気二重層タイプは耐圧が著しく低いので仮に2Vで充電するとして、かつ出力電圧維持の都合上容量の7割までしか使えないとすると必要な静電容量はQ=\frac{1}{2}CV^2だから\frac{390}{0.3} \times 2 \times \frac{1}{2^2}=650で650F。
650Fを1つで確保はできないので6つぐらいを束ねることを考える*2
となると、束ねたコンデンサ間の電圧に偏りが生じないよう制御する必要が出てくる。
需要はあるみたいで専用にICが出てる*3
ただ、なんといってもでかい。
2.5V/150Fという製品があるが直径35mmの高さ50mmと中々でかいものが6個とバランス制御用ICでかなり実装面積が必要となるし、お値段が1個2000円ぐらいするからラズパイ本体よりも高くなること必須。

*1:BP3-6-T1 www.digikey.jp

*2:6つなのは充電電圧2Vだと直列にしたとき12Vとなって扱いやすいから

*3:www.rohm.co.jp

ラズパイ用の電源#1

仕事でもいつの間にか30台程度のラズパイが私の管理下にある今日この頃。
ラズパイの電源系をなんとかしたい。

仕事で買う場合は社内ネットにつなぐ必要上ICT部門経由でケースやACアダプタとのセット品を購入しているのだが、今のところ5~6台がセット品にもかかわらず電圧不足の警告が出る。
まあ、CPUをフルで使わせることはそうないので出てても問題ないといえばないのだが気になる。

また、ただでさえ長期運用時に信頼度が怪しいMicroSDに対して、工場の現場に配置している都合上電源ぶち切り運用が重なり、1年程度で壊れるものが続出。
まあ、事前に予想できていたことなので、内部ストレージはバッファ扱いで必要なデータはWi-Fiが有効な時に別に立ててあるサーバに吐き出させている。
だから壊れたからといって大きなデータの欠落等が出るわけではないが、壊れてから気付いて新しいMicroSDに入れ替えて元に戻すまで、データが途切れることは確かだし、何より現場から回収して事務所で再セットアップしてまた設置しに行くのが手間。

ということで、ラズパイを安定して運用できるだけの出力があり、電源入力消失時にラズパイ側に伝えラズパイのシャットダウンの間は電力を供給できる電源が欲しい。
既製品があれば購入するが、既製品を探すことと並行して基板設計の勉強がてら自分で設計してみようかとも思う。

設計する場合の仕様は以下の通り。

  • 入力: 単相AC100V 商用電源 3極ねじ式端子台(N/L/E)
  • 出力: 4極ねじ式端子台(V+/GND/SOUT/SGND)
    • 電力
      • 電圧: 5V(+10%,-0%)
      • 電流: 定格3A
    • 信号
      • 電源入力消失伝達用にオープンコレクタ出力を1系統
      • 通常時はクローズで電源入力消失時にオープンとなり、その後30秒間は電力出力を維持
  • 形状: Raspberry Pi Zeroのケースと同程度の大きさ(79x38)

KiCADかDesignSparkPCBで図面を引いてみる。

Python+TkでD&D 3

以前書いたものの原因が分かった。
masahero.hatenablog.jp

ワイド文字列がダメみたい。
"CallWindowProcW"みたいに最後に"W"がつく関数をすべて"A"に置き換えると動作する。

Pythonというかpywin32側の仕様が変わったのだろうか。

Python+TkでD&D 2

以前以下のような記事を書いた。
masahero.hatenablog.jp

時間もたってこのままでは動作しなくなっているようなので修正版を作った。
Python 3.6.9では動作するが、Python 3.7.3では元のウィンドウプロシージャを呼び出す箇所で"Access violation"が発生する。原因調査中。分かる人がいたら教えて。

続きを読む

2018年08月25日のツイート

2018年08月23日のツイート