Armadilloフォーラム

yuki.shigefujiさん

お世話になっています、
マルティネです。

> 通信不良やいきなりの電源停止といった不具合が発生しております

確認させてください。
通信不良と電源停止が違う問題の可能性がありますが、同じ問題だと思われてる理由はありますか？
通信不良の場合は何かのログが残ってる可能性が高いです（原因が分からなくても再起動等があれば起動ログが残ります）が、停止の場合はログがない可能性がたかいですので、調査方法も違います。
ハードウェア watchdog がありますので、ソフトウェアの問題で完全に停止することはないと考えています。

> 1. OSハングアップの原因について
>
> OSがハングアップする典型的な原因として、どのような要因が考えられるか？
> ハードウェア起因（SDカード障害、電源不安定、その他）の他に想定すべき要因はあるか？

説明していただいた現象でなんとも言えません。
SD カードの故障でもハングしないはずですので、電源不良か、ファームウェアやドライバの不具合の可能性があります。

> 同日に複数拠点で同一現象が発生することは、どのような要因で起こり得るか？

ハードウェアの場合は、環境による影響も考えれます（雨、高温度など）

ソフトウェアの場合は、例えばメモリリーク等で、一定の日数を起動した後に落ちる可能性もありますので、
そういう問題でアップデートした後に同日に再起動して、同日に問題が発生する可能性があります。

何か共通点が分かれば解析のヒントにもなるかと思います。

> 2. ログ取得・解析の仕組みについて
>
> OSハング時でも記録が残るようなログ取得方法はあるか？

完全にハングしてる場合は syslog にログが残りませんが、再起動したことだけは残りますのでそれを確認してください。
また、ハングや電源不良による停止の次の起動に /var/at-log/atlog に「Sep 12 14:04:58 armadillo NOTICE fsck_atlog: Booting after unclean shutdown」の様なメッセージが追加されるはずですので、新しい情報は少ないですが syslog を読めなくなった場合は「再起動しました」という事実は後でも確認できます。

> 現在シスログの取得間隔を1時間としているが、短縮すべきか？

取得間隔というのは、１時間毎に /var/log/messages ファイルをどこかに転送して保管しているということでしょうか？
アプリケーションのログによりますが、ハングの場合は syslog に残らない可能性が高いので、
syslog にこだわらなくてもいいかと思います。

ドライバーによる不具合の場合はシリアル接続にログが出力されますが、現場等で使いづらいと思いますので netconsole というドライバでリモートサーバーに転送できますが、こういう不具合で完全停止することはないのでまだ不要だと考えています。
(申し訳ないですが netconsole は現状のカーネルで有効化されてなかったので、カーネルのビルドが必要になります。今月のアップデートでモジュール有効化しようと考えています）

ハードウェアやファームウェアの問題の場合にシリアルコンソールですらログが出力されない可能性がありますので、同時に切り分けを勧めた方がいいと思います。

> 3. 調査方法について
>
> OSハングと電源断を切り分けるための具体的な調査手法は？

できれば意図的に再現できる環境を準備すると解析が楽です。
出来なければ、発生する箇所と発生しない環境の違いから探すといいです。
複数の個体で発生しているとのことですが、全く発生してない個体があれば部分的に置き換えることで何か分かると思います。

また、原因が分からなくても共通点から何か心当たりがあれば、修正になりませんが対策を試して原因の確認はできます。
例えば、一定の日数を起動した後にハングすると思ったら毎晩再起動するようにして、発生しなくなったら一つのデータの処理で問題が発生してるのではなく、少しずつリークしている可能性が高くなりますので、それでメモリ消費の詳細の確認等はできます。

> 破損動画以外に、調査の手がかりとなり得るデータはあるか？
> ハング直前のリソース状況を取得できる別の仕組み（監視ツールやハードウェア監視ログ等）はあるか？

ハングの原因によりますが、取得したカメラの生データを一時保存してから処理すればその一次保存したデータで再現する可能性はありますが、
普通のパイプラインでハング発生後のデータを見てもあまり参考にならないと思います。
（ネットワーク経由にデータを取得している場合は switch の port mirroring 機能でデータを複製できますが、これも設定が難しいですね）

> 4. ハードウェア要因について
>
> SDカード使用率が58%程度でも、ハングに影響する可能性はあるか？

SDカードの使用率は関係する可能性は低いと思います。
SDのスピードが遅かったら、データの書き込みが間に合わないなどの可能性がありますが、ランダムに当てるような問題ではなさそうですのでまずは切り分けからです。

> 電源が接続され、緑ランプが点灯していても、電源トラブルが原因となる可能性はあるか？

電圧が一時的に落ちる等でハングしてもランプが点灯のままになりますので、十分ありえます。

> コンセントの抜けかけや電流変動がハングの原因となり得るか？

不安定な接続で電流が不足すれば可能だと考えていますが、複数の場所で発生したとのことですので可能性は低いかと思います。

> 5. 今後の対応について
>
> 今回のように停止理由が特定できないケースで、調査可能性を高めるための推奨対応は？

もうちょっと切り分けてから改めて相談します。

> AIプログラムがコンテナ上で動作している場合、OSハング以外の異常を検出する仕組みはどのように設けるべきか？

これも状況が見えなさすぎて回答できません。
OSはいきてるかどうかは別の監視コンテナを起動するなど、確認できます。

> 御社（アットマーク）に調査を依頼する際、最低限提示すべき情報（ログ種類・取得状況・現象の詳細など）は何か？

このままで調査を続けて、ログは必要になった時に依頼します。
現象の詳細はできるだけ教えていただければ助かります。

まずはこのあたりからお願いします：
① 停止しているか、再起動しているか、再起動もしていないか。
② どの頻度で発生するか、全ての個体で発生しているか。
③ gstreamer を利用している場合は gstreamer のコマンドもあれば手元で確認できるかもしれません（利用しているカメラによります）

よろしくお願いします。