hsboxで作る“LAN監視システム・アラート” 続編：2ヶ月運用レビューと信頼性向上策

前回の記事（hsboxで作る“LAN監視システム・アラート”）では、hsboxを活用したPING監視によるLAN監視システムの基本構築を紹介しました。cronを使った定期実行、スクリプトによる異常検知、そして通知音のアラート機能を中心に、初心者でも簡単に実装できる方法を説明しました。あれから約2ヶ月運用を続けた結果をレビューし、そこから得られた知見をもとに、システムの強化方向性を提案します。

この続編では、実装の詳細に留まらず、運用信頼度の向上に焦点を当てます。具体的には、ログデータを活用して異常パターンを分析し、利用者に状況を明確に開示する方法、復旧の手間を最小限に抑える仕組み、将来の潜在問題を予測・対処するための情報提供について議論します。hsboxユーザーやLinux初心者をターゲットに、基本的な説明を交えつつ、上級者もイメージしやすい形で進めます。分析では、復旧作業のタイミング（起床時のみ手動、深夜1時～6時はなし）を考慮し、異常の持続性や自然回復パターンを重視。また、平日（特に月・火）の昼間不在を考慮した対応策も提案します。

2ヶ月運用の状況報告: ログデータから見える実態

運用開始から約2ヶ月（8月17日～10月19日頃まで）、hsboxを常時稼働させ、家庭内デバイス（家電）を1分間隔でPING監視しました。監視対象は主にIPアドレス192.168.2.**で、異常時は通知音を鳴らす設定です。hsboxのログ機能（/var/log/hsbox/.log）を基盤に、異常を記録。抽出コマンドはcat /var/log/hsbox/*.log | grep "boxsys" | grep -v DDNSで、DDNS関連を除外して監視ログに絞りました。初期検証時の手動テストログ（”check Network working”）は除外し、本運用の異常に焦点を当てます。

異常発生の全体像

総異常検知回数は約1002回（”Deteced Network Failed.”ログ基準）でした。月別で見ると、8月は51回と比較的安定していましたが、9月は744回と急増、10月は207回です。特に9月29日～30日と10月1日に集中しており、9月30日だけで554回を記録。これは一時的なネットワーク不安定が連続した大規模トラブルを示唆しています。 9月30日（10時～15時頃にピーク）は外出していたため、異常が持続しやすいタイミングでした。

日別発生頻度を表でまとめます（主な日付のみ、0回の日は省略）:

日付	異常回数	補足（時間帯/パターン）
2025-08-17	1	午前中単発
2025-08-22	2	深夜・朝
2025-08-23	7	朝連続
2025-08-24	10	深夜連続
2025-08-25	10	朝・午前連続
2025-08-26	1	午後単発
2025-08-29	1	朝単発
2025-08-30	17	深夜・午後連続
2025-08-31	2	夕方連続
2025-09-09	13	夜連続
2025-09-12	1	深夜単発
2025-09-14	7	夕方・夜連続
2025-09-15	10	朝連続
2025-09-17	1	午後単発
2025-09-18	3	午前連続
2025-09-21	2	朝連続
2025-09-22	16	深夜・夜連続
2025-09-24	11	朝・夜連続
2025-09-27	9	深夜連続
2025-09-28	1	朝単発
2025-09-29	116	深夜連続（最大クラスタ）
2025-09-30	554	朝～夕方大規模連続（平日月曜、不在時ピーク）
2025-10-01	124	深夜～朝連続（火曜、不在時持続）
2025-10-07	1	午後単発
2025-10-08	1	深夜単発
2025-10-10	21	深夜～朝連続
2025-10-11	25	深夜連続
2025-10-12	2	午前連続
2025-10-13	1	深夜単発
2025-10-19	32	深夜～朝連続

時間帯別では、午前1時～6時に多く発生（合計約346回、全体の34%）。これは睡眠中で復旧作業ができないため、異常が持続しやすい時間帯です。次に午前6時～12時（約300回）、午後12時～18時（約250回）、午後18時～24時（約106回）。平日月・火の昼間（12時～18時）は不在が多く、異常検知が連続しやすく、復旧遅延のリスクが高いです。

異常のパターン分析: 連続失敗のクラスタと回復傾向

異常は単発ではなく、短時間に連続する「クラスタ」が目立ちます。1分以内のタイムスタンプ差でクラスタを定義すると、合計約86件。サイズ分布は2回連続が10件、3回が6件、… で、大規模なものは深刻です。最大クラスタは554回（9月30日朝～夕方）、次に124回（10月1日深夜～朝）。

具体的なトラブル例:

9月30日: 午前7時～18時頃に554回の失敗。アラート（”Cast for play SystemAlert on YouTube”）が連続し、YouTube動画再生が複数回試行されました。平日昼間不在のため即時対応できず、持続。原因はLAN内部の不安定（PING失敗だがインターネットは接続可）。起床後（夕方頃）に手動でスイッチングハブ電源オフ20秒後オンで回復。
10月1日: 午前4時～6時に124回の失敗。睡眠中なので復旧なし、自然回復か持続。平日朝の不在パターンと重なり、問題が長引く。
深夜異常（例: 9月29日深夜116回）: 睡眠中で手動介入なし。ログから自然回復を示唆（クラスタ終了後正常化）。

これらのデータから、システムは異常を確実に検知・アラートしましたが、連続失敗時のアラート洪水と不在時の対応遅れが課題。2,3回の検出後復旧したものは、ネットワーク機器の手動再起動で復旧しています。深夜異常は持続的だが手動復旧なしなので、機器の自動回復機能や自動アップデート、外部要因を疑います。利用者視点では、状況の即時把握と不在時対応の仕組みが必要と実感しました。

元記事記載内容と強化方向性

元記事で触れたログ実装や多重実行抑止は、hsboxの基盤機能で容易に解決済みです。hsboxで提供している仕組みを利用することでシェルコマンド1行で、タイムスタンプ付きログで記録され、多重実行はcronの特性とロックファイルで防げます。
今後は運用データから得られた課題をもとに強化を検討します。不在タイミング（平日月・火昼間、深夜）を考慮し、信頼性向上に重点を置きます。

ログ機能の活用と異常処理の強化

hsboxのログ基盤を活用し、異常時に/var/log/lan_alert.logへ出力。スクリプト例（bash）で、連続異常を考慮した閾値設定を追加:

#!/bin/bash
TARGET="192.168.2.***"
LOGFILE="/var/log/lan_alert.log"
if ! ping -c 1 -W 2 $TARGET > /dev/null; then
  echo "$(date '+%Y-%m-%d %H:%M:%S') - Alert: No response from $TARGET" >> $LOGFILE
  # 連続異常チェック（5回超で高度アラート）
  if [ $(tail -n 5 $LOGFILE | grep "Alert" | wc -l) -ge 5 ]; then
    # 不在時対応: スマホ通知で外部把握
    curl -X POST -d "alert=連続LAN異常検知: $TARGET (復旧確認要)" https://your-server/notify
  else
    # 通常アラート: インターネット可ならYouTube、不可ならローカルmp3
    if ping -c 1 8.8.8.8 > /dev/null; then
      python3 /home/hsbox/py/cast3.py --url <system_alert_youtube_url>
    else
      python3 /home/hsbox/py/cast3.py --url <local_system_alert.mp3>
    fi
  fi
fi

この修正で、連続5回異常異常時のみスマホ通知に切り替え、アラート疲労を防ぎます。深夜/不在時の持続異常では、通知で家族やリモート確認を促せます。運用信頼向上のため、ログを定期分析するスクリプトも追加可能。例: 週次レポート生成で、時間帯別リスクを予測（深夜異常多→機器電源安定化推奨）。

復旧の手間削減: 大規模クラスタ時は自動リブートを提案。hsboxからハブ制御（IP電源スイッチ連携）で、手動オフ/オンを自動化。ただし、深夜は避け、起床後実行。将来問題予測: ログパターンから不在時リスクを算出（例: 平日昼間クラスタ多→予備電源設置）。

さらなる活用方法の再検討

未解決問題は解決済みですが、活用を再考。閾値設定で誤検知減、ログ分析で根本原因特定（例: 深夜持続→家電のスリープモード、パッチ自動適用？）。利用者開示のため、Webダッシュボードをhsboxに実装: ログをグラフ化（matplotlibでPNG出力、時間帯別別ヒートマップ）。不在時対応: 通知に復旧ガイド追加（”ハブ電源確認”）。

優先拡張: スマホ連携で状況開示と信頼性向上

実装概要: hsboxからプッシュ通知をスマホへ。初心者向けステップ:

hsboxスクリプトにHTTPリクエスト追加 (Python requests使用)。
スマホアプリで受信（Firebase Cloud Messaging活用）。
コードスニペット例 (Python追加部):

import requests
from datetime import datetime

def send_push(alert_message, timestamp):
  # 不在タイミング考慮
  hour = datetime.now().hour
  if 1 <= hour <= 6 or (datetime.now().weekday() in [0,1] and 12 <= hour <= 18):
    alert_message += " (不在/深夜推定: 後ほど確認要)"
  payload = {'title': 'LAN異常', 'body': alert_message}
  requests.post('https://your-fcm-server/send', json=payload)

# 異常時呼び出し
send_push("連続異常検知: 192.168.2.***", datetime.now())

メリット: 外出/睡眠中もリアルタイム把握、復旧指示（e.g., リモートでハブ再起動）。状況開示で信頼性向上、手間を削減。

まとめ: 信頼性向上の方向性

2ヶ月運用で、hsbox監視システムの有効性を確認しましたが、不在/深夜時の持続異常への対処が鍵でしょう。ログ分析でパターン特定、スマホ連携で開示/復旧の自動化を強化すれば、信頼度が大幅向上するでしょう。読者の皆さん、まずはログ追加から試し、データ蓄積を。質問はコメントへ。

Post Views: 3