機材保守について
構築編は、一段堕落したので構築したADS-B環境の運用保守について書いて行こうと思います。
現時点としては、正常に動作しており、さらに解決しないといけない課題も出てきましたが、
季節的な問題ということで詳細は最後に書いています。
物理破損が無いか確認
目視確認と防水ボックスをあけて、雨漏りなどがしていないかをチェックする。
雨漏りなどで、ボックス内水が確認された場合は、シリコンコーキングなどを適切に実施し
防水性を担保する。
OSアップデート(定期的に実施する)
sudo apt update
sudo apt list –upgradable
sudo apt upgrade
| Hit:2 http://security.debian.org/debian-security bullseye-security InRelease Hit:3 http://deb.debian.org/debian bullseye InRelease Hit:4 http://deb.debian.org/debian bullseye-updates InRelease Hit:5 https://repo-feed.flightradar24.com flightradar24 InRelease Hit:6 https://apt.rb24.com bullseye InRelease Hit:7 http://archive.raspberrypi.org/debian bullseye InRelease Hit:1 https://www.flightaware.com/adsb/piaware/files/packages bullseye InRelease Reading package lists… Done Building dependency tree… Done Reading state information… Done All packages are up to date. |
上記の様にアップデートが無い状態で運用する方がベストである。
データが正常にFeedされているか確認
feed状況を確認出来るコンソールにログインし状況を確認する。
Nginx等でリバプロ構成の場合は、ドメインつけて外部からSSL等で安全にACCESSできる。
その場合でも、いちおうのダイジェスト認証を設定しておく方が安全性は高い。
http://ラズパイのIPアドレス:8754 でブラウザーで確認出来ると思う。
リバプロ入れると、外部からドメインでAccess出来る様になる。
総合監視について
だいたい、この位を見ておけばとりあえず状況がつかめると思います。
監視項目を左上から右へと解説をして行きます。
| 項目 | チェック観点 | 備考 |
| ローカルクロック | ラズパイは、バッテリーを搭載していない為、時刻が維持できないので現在の時刻と差分が無いかをチェックする | |
| CPU使用率 | 処理性能に過不足は無いかを確認する | ラズパイのシリーズが低く、スペックが低いとCPU使用率は高くなる傾向にある。 あまり高いならシリーズを最新の5にあげるもしくはコア数及びメモリ容量の大きい物へreplace対策が必要。 |
| Disk Write Rate | SDカード書込レートを表示 | ラズパイは、SDカード駆動になっているので、書込数には上限がある為、いちおう状況把握の為トラッキングしている。 |
| ADS-B SkyAware レスポンスタイム | SkyAware 管理画面のresponseタイムを計測している。 | あまり遅いと、process再起動する等の対応が必要。 |
| Performance Graphs レスポンスタイム | graphs1090のresponse時間を測定している。 | あまり遅いと、process再起動する等の対応が必要。 |
| ネットワークトラフィック | インとアウト側を計測している | あまり高いと、チェックする必要あり |
| CPU idle Time | アイドリングしている％を測定している | 余力の有無として、上記の計測結果だと92．97％の余力ありなので全く問題無し |
| CPU System Time | CPUがシステムに使っている使用率を％で測定している。 | OSに関わる所の処理の割合を把握する。ここが高いとOS周りの設定を見直す必要あり |
| CPU User Time | OS以外の処理に使って居る使用率を％で測定している。 | ここで言うと、FeedしているprogramやSDRからデータを抽出しているような処理の合計が表示されている。 総使用率ーシステム使用率＝ユーザ使用率になる。 ここが高いと、どこかのprogramがハングアップしているかもしれないので、要調査が必要となる。 |
| ADS-B flightradar24 Feed レスポンスタイム | Feed状態を確認する為画面のresponse時間を計測している。 | ここが遅いと、OS再起動やprocess再起動なども検討する。 |
| ADS-B flightradar24 Feed レスポンスコード 200 正常 | Feed状態を確認する為画面のresponseコードを測定している。 | 200ならば正常、それ以外ならサービス提供出来ていないので要確認が必要になる。 |
| Performance Graphs レスポンスコード 200 正常 | 受信状況をグラフにするツール画面のresponseコードを測定している。 | 200ならば正常、それ以外ならサービス提供出来ていないので要確認が必要になる。 |
| process数 | 実行しているprocess数をカウントしている。 | 時限バッチ処理などで、一時的にprocess数が増える時間帯があるが、インターバルがきまっているので、それ以外の時間帯でスパイクが立つようであれば、要確認が必要な案件となる。 【ps -ef | grep “piaware.pid” | grep -v grep | wc -l】 |
| CPU loadAverage | CPUのloadAverageを測定している。 | 1分・5分・15分の平均値をPlotしている。これが右肩上がりに増えるようであれば、要確認が必要となる。 |
| flight pi Feed process 監視 | Feedしているprogramが動いているか、process確認をしている。 | 1なら正常でprocessが生きている状況を示す。0ならprocessがダウンしているので、要確認が必要である。 【ps -ef | grep fr24feed | grep -v grep | wc -l】 |
| 受信している飛行気の数 | 電波を出している飛行機の受信している数を測定している。 | 表示の場合なら、58機の飛行データを受信している状況を示す。これが、日中なのに、1～10とか少ないと、アンテナやSDRチューナーの確認などを行う必要がある。 【cat /run/dump1090-fa/aircraft.json | grep hex | wc -l】 ※悪天候などで、飛行機が欠航している場合もあるので、そこはflightradar24とかにAccessして確認する。 https://www.flightradar24.com/35.63,140.38/11 |
| flightradar Tracked AC Send数 | 受信しているトラッキングデータをflightradar24側へ送っている数 | |
| mlat msg/s received count | MLATで受信しているメッセージ数をカウントしている。 | サンプルに貼り付けた資料を見る限り、秒間1082のメッセージを受信している事が分かる。 【sudo cat /var/log/piaware.log | grep Receiver | grep -v status | tail -1 | awk ‘{ print $8 }’】 |
| USB Device Check | ラズパイに接続しているSDRチューナーが見えなくなることがあるので、先日監視を追加した所です。 | OK Dv:1 デバイスが接続されて見ている状態を示す Rt OK Dv:1 デバイスを見失ったが、再接続コマンドが正常終了して、見える用に復帰した場合 Rt NG Dv:0 デバイスを見失っなって、再接続コマンドも実行したが、結局見失ったままの状態となる。これになると、全ての受信が停止しており、人の手によってRecovery処理を施すしかないので、要確認を実施する。 【lsusb | grep RTL2832U】のリターンコードをシェルで監査している |
| ADB-S Feed System Access失敗 (0:正常 / それ以外異常) | Web監視を実施している | グラフがあがらないすなわち0が正常、ダウンしている時は1になり、グラフがあがる。 |
| メモリ使用量 | メモリの使用量を測定している | ある程度残メモリが残っている事を確認しておく必要あり |
| IO Wait | ラズベリーパイはSDカードで動いているので、書込が遅くて書込待ちができる場合がある。その状況を取得している。 | あまりSDカードを攻撃しないように、この辺りの指標を見つつLogをRAMディスクに移動させたり等を検討する。 |
| flightradar24 Feed process 監視 | flightradar24にFeedしているprogramが動いているか、process確認をしている。 | 1が正常で0が無可動となっているため、要確認が必要である。 |
| 受信している飛行機の数 | 受信している数をグラフ化しているだけ | |
| flightradar Tracked AC Send数 | 受信しているトラッキングデータをflightradar24側へ送っている数をグラフ化したものとなる。 | |
| mlat msg/s received count | MLATクライアントで受信している数をカウントしている | |
| Swap 残量 | メモリ不足等でスワップ領域を使った場合、こちらのグラフが減っていく。 | ソフトウェア的に対応もしくは、設定などで対応出来ない場合は、ラズベリーパイのRAM容量の多いモデルに変更する等の検討も必要になる。 |
| ストレージ残量 | SDカードの使用量とトータル容量を監視している。 | 容量不足になった場合は、SDカードのdumpを取って、それ以上のSDカードにリストアして、容量拡張して増設を行う必要あり。 |
| Zabbix Agent 監視 | ZabbixAgentからの疎通確認を行っている。 | 1は正常 / 0は異常 |
| 防水ボックス内温度 | 防水ボックス内の温度を測定しているので、その温度を表示している。 | USB温度計を取り付けて、pythonにてデータ取得を行って、ZabbixAgent経由で引き上げている。 【TEMPerGold_V3.5 27.12C】 |
| ADS-B 防水ボックス内 温度 | 上記項目をグラフ化して表示したもの | 温度が高すぎる場合は、対応する必要があります。 |
| NICダウンリンク検出用（0の時はネットワーク断） | ネットワークの疎通が途切れてる時間を計測している。 | 頻繁にとぎれるようであれば確認が必要 |
| UP time | システムが起動している総時間をグラフ化している | |
| fr24feed Version | fr24feed Versionを計測している。 | fr24feedは、自動バージョンアップをしかけているので、勝手にどんどんバージョンがあがっていくのでいちおう、現在どのバージョンで動いているのか確認している。 |
| ラズベリーパイ温度 | ラズベリーパイのシステム温度を計測している。 | 60度を超えない限り大丈夫だが、出来るだけ低い温度で使用したほうが故障するまでに期間を延長出来る。 |
| ADS-B ラズベリーパイ4B 温度 | 上記をグラフ化している。 |
普段は、この監視画面を見るだけで、ほぼほぼ状況がつかめるので問題ないと思います。
SDカードが書込上限を迎えそうになると、何かと不安定になるので、その時点で読み出しができる状態のまま停止させて、バックアップを取得して、そのままを新しいSDカードに書き戻せばリフレッシュ回復いたします。あとは、M.2 SSD化する方法もラズベリーパイ5ならあります。
長期間の稼働を想定するなら、絶対そちらがいいと思います。
SDR受信機が見えなくなる障害について
ラズベリーパイの電源事情によって、USBポートを多用した場合、一時的に電源提供電量を超えた場合、
不安定になって電流をたくさん食べているデバイスを強制リジェクトしている状況が発生している。
今までは、防水ボックス以外に設置していた際下記構成であった
USB Port0 : USB温度計
USB Port1 : クーリングファン
USB Port2 : SDR受信機
ところが、防水ボックスに組み込んだ際、上記構成＋ボックス内の温度を管理するコントロールユニットとFAN(5V)＋動作確認用LEDを取り付けてあるので、その消費電力が微妙らしく、SDR受信機をディスコネクトさせているようだ。
USB Port0 : USB温度計
USB Port1 : クーリングファン
USB Port2 : SDR受信機
USB Port3 : ボックス内FANコントローラー 5Vファン LED（赤:常時点灯） LED（青:動作中点灯）
| Bus 002 Device 001: ID 1111:1111 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 1111:1111 PCsensor TEMPerGold Bus 001 Device 003: ID 1111:1111 Realtek Semiconductor Corp. RTL2832U DVB-T Bus 001 Device 002: ID 1111:1111 VIA Labs, Inc. Hub Bus 001 Device 001: ID 1111:1111 Linux Foundation 2.0 root hub |
OSからはケースファンと温度管理用コントロールユニットは見えてないけど、それらがUSBポートに電源供給オンリーとして接続されています。
全てUSB電源で動くように、5V定格の物を接続はしていますが、右下のFANを駆動した際のリレーがONになる瞬間少し起動電流がUSBの電圧を不安定にしているものと思われます。部屋の中で稼働していた時は特に問題なかったのですが、外に設置してからその事象がではじめたので、その影響かもしれません。LANケーブルで電源を送っている関係で、このボックス内にコンセントがなく、これについての対応はデバイスリセット自動化で実装しています。
動作設定について
| 動作設定 | 作動温度 | 動作 |
| 1 | 30度以上 | FAN駆動開始 （実際はディレイで32度にならないと動作しない） |
| 2 | 30度以下 | FAN駆動停止 （実際はディレイで28度にならないと停止しない） |
今は、気温が下がってしまって、FANは日中・夜間も含めて動くタイミングが無いので、なんとも検証出来なくなってます。現在、FANが駆動していない為か、デバイスディスコネクトは発生して折らずです。
温度設定については、ラズベリーパイは60度を超えない限り、ヒートセーブモードに入らないそうなので、もう少し高めに設定しても大丈夫そうですが、基本はFAN寿命を考慮すると、あまり回さず、必要な時に回すの良い感じの閾値で設定をしていますが、場合により設定変更をする事もあります。
この辺りは、FANが停止－＞起動してボックス内の温度を自動で下げていることが見て取れます。
こういう時、廃熱口に手を当てると、かなり暖かい風を感じれますので、基本的には上手く想定通り動いているものと思われます。
USB単体の消費電力確認方法
ADS-B@ads-b:/script/com $ lsusb -v 2>/dev/null | grep -e ‘MaxPower’ -e ‘Bus [0-9]’
Bus 002 Device 001: ID 1111:1111 Linux Foundation 3.0 root hub
-> MaxPower 0mA
Bus 001 Device 004: ID 1111:1111 PCsensor TEMPerGold
-> MaxPower 100mA
Bus 001 Device 003: ID 1111:1111 Realtek Semiconductor Corp. RTL2832U DVB-T
-> MaxPower 500mA
Bus 001 Device 002: ID 1111:1111 VIA Labs, Inc. Hub
-> MaxPower 100mA
Bus 001 Device 001: ID 1111:1111 Linux Foundation 2.0 root hub
-> MaxPower 0mA
ラズベリーパイ4だと、USB端子に接続したデバイスの合計の供給電力は1.2Aまで と指定されています。
| Bus | デバイス名 | 機器名 | 最大宣言消費電力 |
| 001 | Device 001 | Foundation 2.0 root hub | 0mA |
| 001 | Device 002 | VIA Labs, Inc. Hub | 100mA |
| 001 | Device 003 | RTL2832U DVB-T | 500mA |
| 001 | Device 004 | TEMPerGold | 100mA |
| 001 | Device 005(下記で説明) | ケースFAN(OS認識外) | 200mA |
| 001 | Device 006(下記で説明) | ボックスFANコントロールユニット(OS認識外) | 200mA + 40mA + 300mA? |
| 002 | Device 001 | Foundation 3.0 root hub | 0mA |
| Max:1440mA → 240mA 超過 |
この時点で最大700mAを消費する可能性があることが分かります。
ラズベリーパイ4は、1.2Aが最大供給量だと考えると、のこり500mAでファンコントロールユニットとFANとケースFANとLED最大2つを稼働させないといけないことになります。
定格電圧:5V DC、電流:0.2A を消費しますので、残り300mA
LEDが1つ20mAで2つ最大点灯するので、40mA 残り260mAでケースファンも上記の電流とすると
残り60mAとなって、コントロールユニットが60mAで動作するとは思えずおそらくオーバーしてますね。推定で240mA程度オーバーしているタイミングがあって、そこで、SDRがディスコネクトして見えない事象となっていると結論づけました。
おそらく自動復帰型のヒューズが入っているそうなので、それが一時的に飛んで見えなくなっている気がします。
解決方法
PoEからUSB電源を取って、ファンコントロールユニットとFANに流すか、何らかの方法を検討しないといけないですね。ボックス内に蓄電池を設置して、ソーラーパネルを設置して、そちらからケースファンを給電する方法も検討出来そうです。夜間だけフルで回っても持つバッテリーさえ格納出来れば、日中ソーラーでその蓄電池を充電さえ出来れば解決も出来そうですね。
色々検討も出来そうなのですが、いったん、デバイス初期化して再認識させる監視プログラムを1分おきに流して乗り切ろうと思ってます。といっても、これで再認識出来るかは！？ちょっと事象が再発していないので分からないです。コントロールユニットの設定を低くして、ファンを強制起動かけて実験する方法もあるかもしれません。時間があったらやってみたいと思います。
総括
どうでしたでしょうか？
これは、数年動かした状態を維持することになると思いますので、保守メンテも必須になってきます。
構築したから放置してると、いつか動かない状態も発生しますので、保守しながら長くロングランで稼働させれると良いですね。
次回は、SDカードのバックアップ方法や、実際にリストアして動きなどを書いていければと思います。
お楽しみに待っておいてください。また、ラズベリーパイ5にreplaceも検討しています。