監視とアラート

変更しかできないコントロールパネルは、半分の道具にすぎません。もう半分は、何かがおかしくなったとき——できれば障害になる前に——それを知ることです。FrontierStack は、監視対象として登録したすべてを継続的にスイープし、トラブルの最初の兆候を、あなたが選んだチャネルへのメッセージに変えます。本章では、全体を要約する Local Health ボード、警告を発報・配信する Alerts ペイン、それを運ぶメッセージングゲートウェイ、そしてクラウドサービス・プロジェクトツール・電源・ストレージ向けの専用モニタを扱います。

11.1Local Health ボード

Overview ▸ Local Health を開くと、「今、何か壊れているか?」に答える 1 画面が現れます。監視対象のサービス・デバイス・サブシステムはすべて UP または DOWN の行として、領域別（Web・データベースサービス、フリート、サイトと証明書、ディスク、UPS・SNMP デバイス、接続済みクラウドアカウント）にまとまって表示されます。最上部には X up / Y down の形式で 1 行サマリーがあり、すべての行を読まずともフリート全体の状態をひと目で把握できます。

グループは折りたためますが、障害を含むグループは自動的に開きます。各行の履歴ボタンで直近 30 回のチェック、測定済み応答時間のスパークライン、24 時間・7 日・30 日の正確なローリング観測稼働率、最近の状態遷移を確認できます。各稼働率にはカバレッジを併記し、アプリ停止中・一時停止中・対象ネットワーク外の時間を正常と推測しません。フリート全体のイベントは、最初の観測、停止、復旧を最大 1,000 件、31 日間保持し、エンドポイント、認証情報、応答本文は保存しません。

このボードは、AI 管理者が get_server_health ツールで読むのと同じデータです。「何が落ちている?」と尋ねれば、この画面が示す内容をそのまま報告し、修正案を出す前に調査を申し出ます（第 13 章参照）。スイープはおよそ 60 秒ごとに走り、各 DOWN 項目はそれを所有するペインにも紐づけられます。これがサイドバーの行や Dock アイコンに赤いカウントのカプセルが現れる理由です——トラブルが「ある」だけでなく「どこにあるか」が分かります。

11.2Alerts ペイン：監視する対象

Local Health ボードは状態を表示します。Alerts ペイン（Overview ▸ Alerts）は、何がメッセージに値するかを判断して送信します。「重要なサービスを監視して通知する」をオンにすると、スイープがアラートを発報し始めます。監視する対象は次のとおりです。

• サイトとサービスの健全性 — HTTP／ループバックのチェック、TCP ポート、さらに踏み込んだプロトコルプローブ（SMTP／IMAP ログイン、データベースの SELECT 1、LDAP バインド）。待ち受けてはいるが実際は壊れているサービスも検知します。MySQL プローブはさらに接続プール（max_connections に対する使用率と "too many connections" の拒否カウンタ）を読み取り、プールが 90% を超えたときやスイープ間にクライアントが拒否されたときに通知します。各スイープはデータベースヘルスペインの接続ヘルス履歴としてチャート化され、プール使用率の推移に、拒否バーストと停止が赤い線で刻まれます。
• 連携サーバ — 各フリートホストの SSH エンドポイントをスイープごとに到達性チェックします（ログイン試行なしの素の TCP 接続）。完全に停止したサーバは明確な「サーバダウン」アラートを発報し、復帰時には「サーバ復旧」を送ります。これはホストが稼働中に接続を制限しているときだけ出る SSH クールダウン通知とは別物です。
• 証明書とドメイン — フリート全体の TLS 有効期限に加え、レジストラ／DNS／SSL のチェックで、失効する当日の朝ではなく数日前に警告します（第 7 章）。
• ディスクの逼迫 — 後述の Disk Health モニタから、空き容量しきい値を下回ったボリュームを通知します。
• セキュリティの露出 — 新しい開放ポートや想定外のリスナー、VPN トンネルの切断、SSH がネットワークから到達可能な状態での重大な SSH 堅牢化の失敗。
• 決済の失敗と請求 — 接続した有料サービス（OpenAI・Anthropic・Cloudflare・Google Cloud）がクォータ不足・残高不足・認証エラーを返す——カード失効の症状です。
• 接続したクラウドサービス — Stripe・Shopify・Freshdesk・SendGrid などのライブ監視が、設定したしきい値を超えると発報します。

多くのチェックはしきい値ベースなので、「トラブル」の定義はあなたが決められます。証明書が残り N 日になったら、未対応チケットが一定数を超えたら、ディスクが一定割合を超えたら——。余裕を持ったしきい値にすれば、事後検証が事前の知らせに変わります。ペインには「侵入を通知」もあります。新しい fail2ban／CrowdSec のバン、高深刻度の Suricata シグネチャ、注目すべき Wazuh アラート（レベル ≥ 7）が発生時にメッセージされ、既存の履歴は再アラートされません。

SwitchBot デバイス。SwitchBot デバイスをピン留めすると、SwitchBot クラウド経由で監視します。プラグは 2 分ごとに確認し、Wi-Fi 不安定の警告も出します。ロック、センサ、カーテン、ボット、照明、ハブ 2/3 など状態を報告するデバイスは 10 分ごとに確認し、デバイスまたは接続先のハブがオフラインと SwitchBot が返したときにアラートします。カメラとハブミニは状態を報告しないため、オフラインとは表示しません。SwitchBot の 1 日 10,000 回の上限に収まるよう、ピン留めが多いと間隔を自動で延ばします。

11.3メッセージングゲートウェイ

アラートは届いて初めて役に立ちます。Alerts ペインでは複数のゲートウェイを同時に有効化でき、チャネルごとに複数の宛先を指定できるので、相手が既に開いているアプリに確実に届きます。ボットトークンや Webhook URL を貼り付け、テストを送れば稼働します。AI 管理者は get_messaging_channels で有効なゲートウェイを列挙し、send_notification で送信できます（第 13 章）。

11.16.1オンコールの呼び出し（PagerDuty・Opsgenie・緊急 ntfy）

上記のメッセージゲートウェイは送りっぱなしのテキストです。ページングチャンネルは質的に異なり、ステートフルです。監視項目がダウンすると、FrontierStack はその項目にキー付けされたインシデントをトリガします——PagerDuty（Events API v2 のルーティングキー）または Opsgenie（GenieKey）がエスカレーションポリシーを実行し、誰かが応答するまでオンコール担当者にプッシュ・SMS・電話をかけ続けます。項目が復旧すると、FrontierStack は同じインシデントを自動的にリゾルブします。インシデントは項目ごとにキー付けされるため、フラッピングするサービスは 1 つのインシデントを更新するだけで当番を何度も呼び出さず、すでに終わった障害で誰も起こされません。オンコールサービスがない場合は、ntfy ゲートウェイのダウン時にページトグルで「ダウン」アラートを ntfy の最高優先度で送信できます——より大きく繰り返し鳴り、多くのスマホのサイレント設定を突破します（復旧とレポートは通常優先度のまま）。各ページングチャンネルのテストページを送信ボタンは実際のインシデントを発生させ、約 10 秒後に自動リゾルブして、エスカレーション経路全体を端から端まで検証します。

11.16.2ほかの人にも知らせる：連絡先・プリセット・エスカレーション

上記のチャネルが届くのはあなただけです。実際の障害では、メールで知りたい上長、もう一人のサポート担当、現地に向かう技術者など、ほかの人にも連絡が必要なことがよくあります。アラート ▸ 連絡先とエスカレーションは、これを 3 つの要素で扱います。

たとえばプリセット「上長にメール、現地技術者を呼び出す」は、上長にメールを送り、技術者には SMS と、アラートを読み上げる電話をかけます。「まず技術者、30 分で直らなければ上長」はエスカレーションです。上長へのステップは、30 分後も項目がダウンしたままで、誰も確認済みを押していない場合にだけ実行されます。待機中のエスカレーションはこのセクションとアラートパレット（確認）に表示され、項目が復旧すると自動的に取り消されます。故障を知らされた人には復旧も知らされます。良い知らせで電話が鳴ることはなく、代わりに SMS で届きます。新規プリセット ▸ テンプレートからを選ぶと、用意されたプリセットを使えます。まだいない役割には空の連絡先が追加されます。テストは遅延を無視し、TEST と明記してすべてのステップを直ちに送ります。ピン留めしたカメラやルータなどのオフライン時のアラートにはほかに誰がこのアラートを受け取るか…ボタンがあり、あなた以外の通知先を表示し、その機器のルールを入力した状態でこのセクションを開きます。あとはプリセットを選ぶだけです。

連絡先には、設定済みのゲートウェイがあなたの宛先の代わりに相手の宛先で使われます。上長へのメールにはあなたの SMTP アカウントを、SMS と電話には Twilio の番号を使います。Twilio の番号は音声通話に対応している必要があります。これらのゲートウェイは、あなた自身のアラートではオフのままでも構いません。各メッセージには相手の役割、ロケーション、プリセットの指示が書かれるので、受け取った人は理由がわかります。宛先の未入力やゲートウェイの未設定は、配信エラーに「SMS → Alex（現地技術者）」のように表示されます。ネットワークの失敗は 2 分おきに 2 回再試行してから報告されます。

IFTTT。メッセージングチャネルで IFTTT（Webhooks）をオンにすると、アラートごとに IFTTT のアプレットを起動します。value1 がタイトル、value2 がメッセージ、value3 はダウンのアラートなら critical、それ以外は info です。ダウンのアラートに別のイベント名を付ければ、照明の点滅など、復旧より目立つ動作を起こせます。連絡先に本人の Webhooks キーを登録すれば、プリセットのステップでその人のアカウントのアプレットを起動できます。IFTTT の Webhooks サービスには IFTTT Pro プランが必要です。

トークンと Webhook は macOS キーチェーンに保存され、Mac の外には出ません。スケジュール配信の AI 評価レポートも送れます。AI 管理者がライブの監視健全性から（読み取り専用の診断を実行して）サマリーを作成し、日次・週次でメール送信、あるいは有効なすべてのチャネルへプッシュします。重大項目が 2 件以上同時に DOWN のときは、任意でより詳しいレポートも送れます。

11.4配信エラーとその直し方

アラートが黙って送信失敗するモニタは無価値です。FrontierStack はすべての送信を検証します。ゲートウェイが失敗すると、Alerts ペインの配信エラーセクションに、平易な日本語の修正ガイドと、その下に生のエラー、そして設定の誤ったチャネルの設定へ直接スクロールする Fix ボタンとともに記録されます。サイドバーの Alerts 行と Dock アイコンに赤いバッジが現れて確実に気づけるようになり、クリアするまで残ります。AI 管理者は get_alert_errors で同じ一覧を読むので、「なぜアラートが届かない?」と尋ねるだけで済みます。

よくある原因は地味で、すぐ直せます。

11.5オンホストの Service Watchdog とデータベースの健全性

ここまでのモニタはMac上で動作します。重要なサーバには、そのマシン自身に常駐するWatchdogも必要です。そうすればMacがスリープ・オフラインでも動き続けます。FrontierStackのService Watchdogはホストモニタとともに配備され（第8章）、短い間隔でサービスを確認し、失敗すれば再起動し、最後の手段として許可した場合だけマシンを再起動します。各ウォッチのチェック種別は、プロセス、HTTP／TCPプローブ、または専用のMySQL／PostgreSQLチェックです。

11.16.3ピン留めサーバの復旧エスカレーション

ピン留めサーバのService Watchdogパネルでは、通常のオンホスト復旧の後に2段階を追加できます。FrontierStackから再起動を許可すると、新しい「Recovery exhausted」イベントの後、指定時間を待ってMacが確認付きの再起動を1回送ります。Power Controlで制御可能なコンセントを関連付けると、サーバが指定時間まったく応答しない場合だけ、その次に電源サイクルを実行できます。再起動要求後は90秒待ってから判定を始め、電源断の判定時間は最低5分です。

電源サイクルはSSHログイン失敗だけでは実行されません。Mac側のネットワークが正常で、SSH、モニタ報告、ping、ARP、一般的なサービスポートのすべてが応答しない必要があります。1つでも生存信号が戻れば、そのインシデントは終了します。電源サイクルは1回だけです。有効化前の古いイベントは処理済みになり、watchdog_reboot_suppressedは再実行されないため、ヘルパのブートループ防止をアプリが迂回することはありません。

11.16.4Macを閉じている間も監視する

ハングしたサーバ自身のヘルパは、そのサーバのスマートプラグを操作できない可能性があります。Recovery observerで別の登録済みサーバを選ぶと、最終段階をそのマシンのヘルパへ委任できます。ObserverはFrontierStackを閉じても、対象のプライベートIPに対してpingと複数のTCPポートを確認し続けます。電源を切る前にプライベート電源コントローラの状態応答を確認し、ブートループ防止記録を保存してから、指定時間だけ電源を切って戻します。対象の復帰を確認するまでは2回目を実行せず、30分のクールダウンはObserverの再起動後も残ります。

データベースのハートビートは、プロセス／ポート確認が見逃す故障を捉えます。MySQLハートビートはパスワードなしでSELECT 1を要求します。成功または「access denied」ならMySQLが応答中、接続拒否、タイムアウト、接続上限到達なら異常です。MySQLパスワードは保存せず、テーブルも読み取りません。空のプローブ名はrootではないfs_watchdogになり、このアカウントは実在しなくても構いません。PostgreSQLハートビートはユーザ名やパスワードなしでpg_isreadyを使います。エラーログの早期警告をオンにすると、データベース自身のエラーログも追尾して破損の兆候を重大イベントとして通知します。これらはサーバ上で動くため、MacがオフでもntfyやWebhookで自律的に通知できます。

チェック専用アカウントを作るには、your_databaseと例のパスワードを置き換えます。

CREATE USER 'frontierstack_health'@'localhost' IDENTIFIED BY 'use-a-unique-random-password';
GRANT SELECT ON `your_database`.* TO 'frontierstack_health'@'localhost';

このログインをDatabase Healthに保存します。手動チェックと検証済みバックアップが両方成功するまで自動修復はオフにしてください。完全なバックアップや修復に追加権限が必要な場合は、MySQLが示したスキーマ単位の権限だけを追加し、*.*は使いません。別のマシンから接続するモニタでは、localhostをその1つの正確なプライベートアドレスに置き換えます。

ピン留めサーバのサービス行では、定期テーブルスキャンまたはサーバ自己修復が有効な間、緑のDBチェッカー：オンを表示します。対象はあるがどちらも動いていない場合は一時停止、MySQLスキャンを選択していてもパスワードがない場合は緑ではなくオレンジのログインが必要を表示します。Database Healthは低頻度でテーブルを検査し、ハートビートは停止を素早く検出してサーバ上でMySQLを再起動するため、両方は補完関係です。

データベースが停止ではなく遅い・詰まっているときは、Database Healthペインの各対象にある「Why slow/stuck?」ボタンがその場で答えます。サーバのライブ活動（MySQLはSHOW FULL PROCESSLIST、PostgreSQLはpg_stat_activity）を読み、実行中クエリを形状ごとにまとめます。リモート対象はSSH経由で調べるため、データベースのポートを公開する必要はありません。

11.16.5保守のためにチェックを一時停止する

意図的にサービスを停止している最中に、再起動してくれるウォッチドッグはまさに邪魔です。保護をオフにして — そして自分で戻し忘れないことに頼る — のではなく、Guardian ヘッダーの 「Pause Checks…」、または各サービス行の一時停止ボタンを使います。15 分から 1 日までの範囲を選べます。

一時停止中、Guardian は対象のヘルスチェックも再起動も行わないため、作業と衝突しません。何も無効化されず、設定も失われません。Keep Alive、Auto Recover、しきい値、間隔はそのまま保持され、時間が過ぎれば自動的に再開します。「Resume Now」を押せば即座に再開できます。一時停止がその期間を超えて残ることはなく、アプリを終了して再度開いても同じです。

11.6ケーススタディ：High Sierra Server.app の serviceproxy ハング

High Sierra 上の macOS Server（Server.app）を今も動かしている古い Mac には、よく知られた故障があります。Web フロントプロキシ——実際のバックエンドの手前でポート 80／443 を握る launchd ジョブ com.apple.serviceproxy——が、ときどきハングするのです。TCP 接続は受け付け続けるのに一切応答しなくなるため、背後のすべてのウェブサイトが停止する一方、プロセスチェックはどれも正常に見えます。Apple からの修正はありません。このスタックはサポート終了です。Service Watchdog はまさにこのケースを念頭に作られています。

ウォッチの設定方法。サーバのペインでサービス名 serviceproxy のウォッチドッグ項目を追加し、——ここが重要ですが——プロセスチェックではなく、ターゲット http://127.0.0.1/ の HTTP チェックを設定します。本当の故障（接続は受けるが応答しない）を見抜けるのは HTTP プローブだけです。失敗すると、ウォッチドッグは launchctl kickstart で復旧します——管理者が手で打つ修復コマンドそのものです。HTTP ステータスが 500 未満なら生存と見なされ（プロキシが 403／404 を返しても応答している証拠です）、各プローブは 6 秒でタイムアウトするため、ハングしたプロキシはタイムアウトでチェックに失敗します。プロキシ背後のバックエンドも同様に server-httpd として監視できます。

推奨タイミング。チェックは 30 秒ごと、3 回連続で失敗したら再起動、再起動は最大 3 回、再起動後の猶予はデフォルト（約 20 秒。古いハードウェアの Apache にも十分）のまま。これで行動前に約 90 秒かけてハングを確認します——1 回の遅い応答や一時的な負荷スパイクでは kickstart せず、本物のハングなら約 2 分でサイトが自動復旧する長さです。サイトが重要なら 15〜20 秒間隔・2 回失敗（確認まで約 40 秒）に詰めても構いません。それ以上詰めても誤再起動が増えるだけです——古いマシンは負荷時に応答へ数秒かかることが普通にあるからです。「回復に失敗したらサーバを再起動」は、完全に無人のマシンでない限りオフのままに。実際には kickstart でハングは解消しますし、この種のマシンでの最終手段の再起動はダウンタイムを増やすだけです（ブートループ防止ガードにより、ウォッチドッグ再起動の間隔は最低 30 分が強制されます）。

なぜプロセスチェックではだめか。serviceproxy という名前のプロセスは存在しません——このジョブは特殊な設定ファイルを持つ httpd として動きます——そのため v1.6.1 より古いモニタは、正常なプロキシを恒久的に「停止中」と誤読し、何度も再起動を繰り返し、再起動へのエスカレーションを許可していれば正常なマシンを定期的に再起動していました。v1.6.1 からモニタは launchd にジョブの実状態を問い合わせるため、プロセスチェックも真実を伝えます。ただし本当のハングを捉えるのは引き続き HTTP チェックです。原因不明の再起動を繰り返す古いサーバがあれば、まずモニタのバージョンを確認してください。なお「なぜ再起動した？」はウォッチドッグ起因の再起動を明示的に帰属させます（v1.6 以降のモニタでは理由付き。それより古いモニタもスタンプを残し、それも報告されます）。

配信についてもう 1 つの保証があります。アラートは決して沈黙しません。メッセージングゲートウェイに加えて、状態変化のアラートはすべて、ゲートウェイとは独立にネイティブの macOS 通知とプッシュも発報します——メールをオフにしすべてのチャネルを無効にしても、サービスの停止は Mac 上であなたに届きます。データベースのリカバリ——mysqlcheck／pg_amcheck の実行や AI ガイド付き再構築——は第 5 章で扱います。

11.7インシデント・オンコール・ステータスページ

すでに正式なインシデント対応を運用しているチーム向けに、FrontierStack はそれを置き換えるのではなく、お使いのツールへ接続します。各ツールはカタログのエントリから開けるライブペインを持ち、読み取り専用の API キーを貼り付けると現在の状態を表示します。

• インシデント管理・オンコール — PagerDuty（オープン／高緊急度のインシデント、オンコール担当、サービス）、Opsgenie（未対応／未確認のアラート、US／EU リージョン切替）、incident.io と Rootly（進行中のインシデント）。
• ステータスページ — Statuspage（未解決インシデントと DOWN のコンポーネント）と Better Stack（モニタの up／down／paused）。

各ペインでキーを設定し（例：PagerDuty ▸ Integrations ▸ API Access Keys）、接続を確認します。これらは同じ監視像に流れ込むので、PagerDuty のオープンインシデントやステータスページの DOWN コンポーネントが、自前の健全性と並んで表示されます。

11.8SaaS ライブ監視とプロジェクト管理ペイン

FrontierStack はインフラだけにとどまりません。設定駆動の SaaS ライブ監視が接続済みクラウドアカウントを見守り、数分ごとに更新します。各サービスには資格情報フォーム、ライブのメトリックタイル、「Alert me」トグル、しきい値があります。アラート対応サービスはメトリックが線を超えると DOWN アラートを発報し、残りは到達性を監視します。ライブ監視には Stripe（要対応の係争、残高）、Shopify と WooCommerce（未処理注文）、Freshdesk と Zammad（オープン／保留／期限超過チケット）、SendGrid・Mailgun・Postmark（バウンスとブロック）、GitHub Copilot（非アクティブシート）、アイデンティティプロバイダの Okta と Microsoft Entra ID が含まれます。サービスをピン留めすれば、アラート設定に関わらず常時 Local Health に表示できます。

専用の GitHub ペインは、アカウントとリポジトリの集計、Actions 関連の作業、PR、レビュー依頼、割り当て Issue、未読通知、残り API リクエスト数、最近更新された 5 リポジトリのリリースアセットダウンロード数を表示します。Anthropic のアカウント／モデル監視と GitHub Copilot のシート利用状況は API 認証情報だけで接続し、クラウド専用サービスに架空のホストやポートを求めません。

AppSignal には専用の読み取り専用ライブ接続があります。アプリケーション ID と個人 API トークンを入力すると、トークンはキーチェーンに保存され、FrontierStack は AppSignal の GraphQL API からオープン中のエラーインシデント、稼働中のアップタイムアラート、最新デプロイ、取得可能な直近 1 時間のエラー／レイテンシ指標を表示します。アラートしきい値はオープンインシデントとアップタイムアラートの合計です。AppSignal は GraphQL URL 内の API トークンを要求するため、FrontierStack は URL を非公開で組み立て、認証済み URL をログへ書きません。より深い調査には MCP Servers の AppSignal プリセットを追加します。バージョン固定の OAuth ブリッジ経由で AppSignal のホスト型 MCP を開き、監視トークンを AI クライアントへコピーしません。書き込み可能なツールを確認するまでは AppSignal のアクセスを読み取り専用にしてください。

Paessler PRTG には、セルフホストの PRTG コアと PRTG Hosted Monitor の両方に対応する専用ライブ接続があります。PRTG サービスを開き、HTTPS のベース URL を入力して、Setup ▸ Account Settings ▸ API Keys で Read access のスクリプトキーを作成します。FrontierStack はキーをキーチェーンに保存し、上限付きのセンサー状態テーブルだけを読み、Up・Down・Warning・Paused・その他の合計を表示します。Alert me when this needs attention をオンにすると、Down センサーとプローブ未接続センサーが Alerts に流れます。この連携はアラームを確認済みにしたり、デバイス・センサー・プローブを変更したりしません。PRTG Network Monitor／Enterprise Monitor のコアは Windows 上で動かすため、連携済み Windows サーバと公式インストーラを使うか、Hosted Monitor を利用します。Windows リモートプローブとマルチプラットフォームプローブで、フリートの他の場所まで収集範囲を広げられます。

NinjaOne、Atera、Site24x7 にも、読み取り専用のライブ接続があります。NinjaOne は Monitoring スコープの Client Credentials アプリを使い、デバイス、オフライン端末、アクティブアラート、実行中ジョブを集計します。Atera は Agents と Alerts だけに限定した API キーを使います。Site24x7 はアカウントのリージョンにある Zoho データセンターで読み取りスコープのリフレッシュトークンを交換し、現在のモニタ状態を読み取ります。秘密情報はキーチェーンに保存され、応答サイズには上限があります。これらの接続が端末へパッチを適用したり、ジョブを実行したり、アラートを閉じたり、保守を開始したり、ベンダー設定を変更することはありません。

同じパターンがプロジェクト管理ツールにトークンログインのライブペインを与えます。Jira（オープン／未割当／ブロック／スプリント内の件数）、Linear、monday.com、OpenProject、Plane、Taiga。これらはアラート源というよりダッシュボードですが、チームの作業量を、それを動かすサーバと同じウィンドウに並べます。メール配信には専用の統合 Email Delivery ペインがあり、トランザクションプロバイダのメトリックと SPF／DKIM／DMARC チェックを統合します（第 7 章）。

11.9キュー運用

キュー運用は RabbitMQ、Kafka、NATS／JetStream、Redpanda、AWS SQS、Azure Service Bus、Google Pub/Sub、Celery／Flower、Redis Streams、Apache Pulsar、Apache RocketMQ の読み取り専用ダッシュボードです。ブローカ、名前空間、クラウドアカウントごとにモニタを追加します。プロバイダが公開する範囲で、キューまたはコンシューマグループ名、待機中・処理中・コンシューマ数、遅延、デッドレター数、最古メッセージの経過時間を表示します。メッセージ本文を読んだり保存したりすることはありません。

クライアントポートと管理ポートは分けて扱います。たとえば RabbitMQ クライアントは通常 AMQP の 5672、管理 API は 15672、NATS クライアントは 4222、監視は 8222、Pulsar クライアントは 6650、HTTP 管理 API は 8080 です。監視エンドポイントは非公開にしてください。オンホストの FrontierStack モニタを経由しない場合は TLS と監視専用アカウントを使います。

連携サーバでは導入済みモニタを選ぶと、署名付き接続を通じて、資格情報を受け取らないヘルパから上限付きサマリーを取得します。クラウドプロバイダは通常のローカル CLI プロファイル、またはキーチェーンに保存した権限を絞った資格情報を使います。重大しきい値は Alerts スイープに入り、同じサニタイズ済みサマリーを iPhone／iPad アプリと AI 管理者の読み取り専用 get_server_health ツールから確認できます。このダッシュボードには消去・削除・発行・確認応答・再生の操作はありません。

11.10UPS 監視と SNMP デバイス

Power Control の UPS セクションでバッテリーバックアップを監視します。FrontierStack は USB 接続 UPS を macOS の電源ソースから直接読み取り、NUT を upsc で、APC 製品を apcupsd の apcaccess で照会します。APC、Eaton、CyberPower、Vertiv（Liebert を含む）のほか、macOS または NUT が対応する機種を扱えます。NUT 経由ではシリアル接続やネットワーク UPS も監視できます。

NUT は無料のオープンソースソフトウェアで、サブスクリプションは不要です。状態取得に API キーは必要ないため、NUT サービスペインには API 認証欄やプラン／費用カードを表示しません。審査済み UPS 操作を有効にする場合だけ専用 NUT コマンドログインが必要で、有償サポートやホスト型ダッシュボードは別製品です。

同じペインで切替可能な Raritan／Legrand Xerus PDU も扱えます。プライベート HTTPS アドレス、コンセントに印字された番号、コンセント操作だけに制限した専用アカウントを入力し、パスワードは Keychain に保存します。正確なコンセント状態と対応機種の実測有効電力を読み、オン／オフと Xerus の原子的な cyclePowerState を使うサイクルに対応します。公開アドレス、URL 埋め込み認証情報、リダイレクト、任意 JSON-RPC メソッドは拒否します。オフとサイクルは毎回確認し、AI Harness にも同じ確認ゲートが適用されます。

各行には、その機種が提供する充電率、推定バッテリー残時間、負荷、実電力（W）、入力・出力電圧、バッテリー電圧、周波数、温度を表示します。UPS が実電力を報告する場合はその値を表示します。定格実電力と負荷率だけが得られる場合は、推定 と明記した W 値を表示します。皮相電力（VA）を W として扱うことはありません。

Alerts をオンにし、充電率・残時間・負荷のしきい値を設定します。商用電源喪失、残時間低下、低充電、高負荷、バッテリー要交換、強制シャットダウン、通信喪失は別々に追跡されます。そのため、最初のバッテリー駆動アラートが継続中でも、残時間の低下を追加で通知できます。切断した UPS は Comms lost として表示に残ります。UPS をピン留めすると、総合状態を Local Health と Places マップでも確認できます。必要に応じて NUT と apcupsd をボタンからインストールできます。

バッテリーシャットダウン規則で段階的な処理を実行できます。UPS が指定時間バッテリー運転を続けるか残量しきい値を下回るまで待ち、管理対象サービスと VM サービスを指定順に停止して各停止を確認し、最後に保護対象ホストをシャットダウンします。確認に失敗すればホストを動かしたまま中断し、商用電源が戻れば未実行段階を取り消します。PowerChute Network Shutdown が動くべきホストでは一般的なサービス名を自動検出するか手動で指定でき、停止時に別アラートを出して規則を停止するかフォールバックを続行します。

スキャン中は NUT と apcupsd の応答を待ちます。Stop を押すと待機を中止し、取得済みの値を保持したまま、Refresh を押すまで自動更新を一時停止します。

サーバまたは通常のピン留めデバイスの電源セクションには、2 つの設定ダイアログがあります。電源コントロールを追加…は切替可能な経路用で、SwitchBot Plug、設定済みの Home Assistant、Shelly、Tasmota、プライベート HTTP、Raritan PDU、Anker SOLIX コンセント、コマンド方式 PDU、電源対応 Remote KVM を選びます。ダイアログから SwitchBot、Home Assistant、Anker SOLIX、TP-Link Kasa/Tapo のペインと、Power Control 内で設定するプロバイダを直接開けます。バックアップ電源を追加…は、ピン留めした監視対象 UPS、Mini DC UPS、または管理不能／ダム UPS用です。PDU はコントローラとして扱い、Power Control で物理コンセントごとに印字番号を割り当て、その名前付き・番号付きコンセントをサーバまたはデバイスに選択します。SwitchBot のリモコンやセンサーは候補に表示しません。保護対象の 1 台にスマートプラグとダム UPS の両方を設定できます。スマートプラグとして登録したデバイス自体は電源コントローラなので、そのペインでは別のコントローラを選ばせず、電源セクション全体を表示しません。監視対象 UPS は実際の残量・残時間・警告を提供します。管理不能の選択肢はメーカーとモデルを記録する棚卸し専用で、FrontierStack と AI Harness は架空の値や操作を提供しません。TREEDIX は Raspberry Pi 用 5 V UPS コントローラとして Mini DC UPS に記録できます。

コンセントの到達確認。電源コントロールでコンセントを編集し、このコンセントに到達できないときにアラートをオンにします。FrontierStack はコンセントを 2 分ごとに読み取り専用で確認し、2 回続けて応答がなければアラートを出します。判定は、コンセントが最後に応答したのと同じ物理ネットワーク（ルータのハードウェアアドレスで識別）にこの Mac がいるときだけ行うため、外出先や同じアドレス帯を使う別のネットワークで、プラグが停止したと誤報しません。この Mac から届かないプラグには、Shelly Cloud ペイン（IoT）を使います。Shelly アプリの認証クラウドキーとサーバアドレスを貼り付け、デバイス ID を追加し、ベルをオンにするとオフラインアラートを受け取れます。両方で監視している Shelly は、そのネットワークにいる間はローカルの確認を優先します。

11.16.6デバイスを番号付き PDU コンセントへリンクする

1. Power Control で、使用する PDU の物理ソケットごとにコンセント項目を 1 つ追加します。分かりやすい名前を付け、ソケット横に印字された番号を入力します（例：ラックサーバ · コンセント 4）。
2. ピン留めしたサーバまたはデバイスを開き、電源 → 電源コントロールを追加…を選びます。設定済みコンセントが名前と物理番号で表示されるので、そのデバイスへ給電している正確なコンセントを選びます。
3. 設定済みコンセントがない場合は、Power Control でスマートプラグまたは PDU を追加…を選びます。設定ペインが開き、コントローラのプライベート IP アドレスまたは URL とコンセントを追加できます。空の PDU リンクは作成しません。
4. アドレスを持つ PDU はピン留め済みでも FrontierStack のネイティブなコンセント連携がない場合、コマンド方式 PDU／電源タップから選びます。サーバの電源セクションで、そのデバイスのコンセント番号と審査済み On／Off コマンドを入力します。コマンドは選択メニューではなく、この場所で設定します。
5. UPS は別にバックアップ電源を追加…から選びます。ピン留めした UPS はデバイスのバックアップ電源を表すためここに表示されます。切替可能な PDU コンセントとは別です。

個別のコンセントを識別できる場合、サーバを PDU 全体へリンクしないでください。オフまたはサイクルの前に物理ソケットを確認できるよう、FrontierStack は行ラベルと破壊的操作の確認画面にコンセント番号を表示します。

11.11リモート KVM プラットフォームと電源

Remote KVM ペインでは、PiKVM、JetKVM、TinyPilot、NanoKVM、Raritan Dominion、ATEN、Vertiv Avocent、Lantronix Spider／SpiderDuo、Adder、GL.iNet、AWERAY、汎用 KVM-over-IP を複数登録できます。正確なモデル／ファームウェアを記録してピン留めし、プライベート Web コンソールを開きます。AWERAY は選択した専用アプリを起動します。

電源操作は審査済みの経路を設定した場合だけ表示します。PiKVM は公開ローカル ATX API を使い、破壊的操作の前に ATX が有効でビジーでなく、現在状態が期待どおりか確認します。JetKVM は共有 MQTT 接続と完全一致のベーストピックを使い、ATX は保持済み状態を読んでから短押し／長押しし、DC 拡張は明示的な ON／OFF を使います。コマンドは QoS 1 で非保持です。TinyPilot／NanoKVM の電源ハードウェアや企業向けベンダーの PDU 連携はモデル／ファームウェアで異なるため、明示的なプライベートエンドポイントがない限りコンソール／棚卸し専用です。Dominion に関連付けた Raritan PDU は Power Control の審査済み Xerus 項目を使います。KVM のオフとサイクルはペインでも AI Harness でも毎回確認します。

SNMP を話すその他のもの——マネージドスイッチ、プリンタ、ネットワーク UPS、NAS——には、デバイス詳細ペインの SNMP / OIDs セクションが直接問い合わせます。旧来の SNMPv2c または SNMPv3 を選択でき、推奨の v3 プロファイルは SHA 認証と AES 暗号化を使います。パスフレーズは Keychain に保存し、コマンド引数ではなく所有者専用の一時設定ファイルを介して net-snmp に渡します。組み込みのテンプレートを選んで Query を押すか、単一の数値 OID を取得できます。比較としきい値を付けて OID をウォッチすれば、条件成立時にアラートを発報します。

同じ SNMP プロファイルがデバイス検出、ネットワークパス、PoE 監視にも使われます。設定済み SNMPv3 ユーザに書き込み権限があれば PoE 操作もでき、SNMPv2c はスイッチごとの独立した書き込みコミュニティを使います。AI Harness は非機密のプロファイル状態、ピン留めデバイスの数値 OID、PoE 状態を読み取れます。書き込みツールに任意 OID 操作はなく、審査済み PoE オン／オフ／サイクルだけに限定され、変更許可と表示中画面での毎回の手動確認が必要です。

11.12Home Assistant エンティティ監視（ベータ）

すでに Home Assistant で建物を管理している場合、FrontierStack はその情報を監視できます。Home Assistant のサービスペインで URL と長期アクセストークンを入力すると、エンティティモニタセクションが表示されます。HA からエンティティを読み込むを押してエンティティを選び、ルールを設定します。温度・湿度・電力なら数値ルール（より大きい／より小さい）、バイナリセンサの on/off・wet/dry・home/not_home なら文字列ルール（と等しい／と異なる）です。各監視は通常のアラートとなり、いつものスイープで確認されます。

ここは、デバイスとしてピン留めできないセンサにとって適切な置き場所です。サーバルームの床下にある Zigbee 漏水センサ、ラックの Z-Wave ドアセンサ、Bluetooth 温度計——いずれも IP アドレスを持たないため ping できません。Home Assistant はこれらのプロトコルを扱えるため、読み取り値は HA 経由で届きます。Home Assistant 2026.9 の Modbus バス共有アクセスにより、ソーラーインバータ・PDU・電力計にも同じ考え方が広がります。HA がバスをポーリングし、FrontierStack が名前付きの値を読み取るため、1 本のシリアル接続を奪い合うことがありません。

意図的な動作が 2 つあります。unavailable や unknown を返すエンティティは、スキップせずアラートを発報します——沈黙した漏水センサこそ、知る必要があるものだからです。また、この監視は設計上、読み取り専用です。Home Assistant のサービス API を呼ばないため、建物の状態は読めても、照明の操作・解錠・バルブ開閉はできません。操作は電源コントロールに残され、すべて明示的な確認を伴います。

利用不可のデバイス。エンティティを 1 つずつ監視する代わりに、デバイスが利用不可になったらアラートをオンにします。FrontierStack は選択したドメインの全エンティティを 1 分ごとに読み込み、Home Assistant が unavailable（利用不可） とするものをアラートします。unknown（まだ値がない状態）は対象外で、Home Assistant 自体に接続できないときは何もオフラインとして報告しません。アラートまでの猶予（初期値 10 分）で、一時的な途切れや HA の再起動では通知しません。多数のエンティティが同時に落ちた場合（30% 超、または 50 件超）は、数十件ではなく「Home Assistant: N devices unavailable」の 1 件にまとめます。原因は通常 1 つ（HA の再起動、Zigbee/Z-Wave ブリッジの停止、ネットワーク障害）だからです。HA から削除していない使わなくなったデバイスは除外（各行のボタンでも可）に追加してください。

同じ接続がデバイス検出の Home Assistant から読み込む にも使われます。HA が把握しているネットワークデバイスを、HA で付けた名前のまま一覧表示し、個別または一括でワンクリックでピン留めできます。読み込んだデバイスはスキャン結果とまったく同じように扱われ、ヘルスチェック・Places・ライセンス上限が適用され、すでにピン留め済みのものは除外されます。どちらの機能も、Home Assistant 2026.9 のデバイスレジストリ API が安定するまでベータ扱いです。レジストリの詳細（エリア・モデル）の読み込みはその後に対応します。

11.13Zigbee と Z-Wave デバイス

オフラインアラート。Zigbee ペインでデバイスのベルボタン（またはすべてアラート）をクリックすると、メッシュから外れたときにアラートします。Zigbee2MQTT では、Zigbee2MQTT の設定で availability をオンにする必要があります。オフになっていると、FrontierStack は応答のないデバイスと停止したデバイスを区別できないため、ペインにオレンジの注意書きを表示し、推測で通知することはありません。deCONZ ではライトの到達性を使います。監視中のデバイスはペインを閉じていても 1 分ごとにチェックします。

Zigbee ペインは、Z-Wave JS UI が制御する Z-Wave ノードも監視します。Z-Wave JS UI で、Zigbee2MQTT と同じブローカを使う MQTT ゲートウェイを有効にし（Settings ▸ MQTT）、Retain をオンのままにします。次に、ペインの Z-Wave セクションで MQTT 経由の Z-Wave JS UI をオンにし、同じプレフィックス（既定は zwave）を入力します。各ノードは稼働中・起動中・スリープ中・応答なしのいずれかで表示され、ベルを押すと応答なしになったときに通知します。バッテリ駆動ノードのスリープは正常で、稼働扱いです。ゲートウェイがオフライン、未報告、または最後の読み取りから 5 分以上たっている場合、すべてのノードを不明と表示し、通知は出しません。FrontierStack は不明な状態をオフラインとは報告しません。

11.14Music Assistant

Music Assistant は Home Assistant チームの音楽サーバです。ストリーミングサービスとローカルファイルを 1 つのライブラリにまとめ、AirPlay・Google Cast・Sonos・Squeezebox・Snapcast・DLNA のスピーカで再生します。障害が起きても何もクラッシュしません——ストリーミングのログインが期限切れになる、アップグレードでスピーカ統合が壊れる、スピーカがネットワークから消える——そして音楽が流れないときまで誰も気づきません。Music Assistant のサービスペイン（ホームオートメーション）を開き、サーバの URL（通常はポート 8095）と、Music Assistant ▸ 設定 ▸ プロフィールで作成した長期アクセストークンを入力します。

アラートのスイープごとに 3 点を確認します。サーバが応答しトークンを受け入れること、読み込みに失敗した音楽／プレーヤプロバイダや再サインインが必要なものがないこと、そしてオフライン時にアラートをオンにしたスピーカが利用可能であること。スマートフォンやノートパソコンは一日中出入りするため、スピーカの監視はオプトインです。一覧取得のコマンドしか送らないため、再生の開始・音量の変更・設定の編集は一切できません。

サービススキャンとサービスの検出は、ポート番号だけで推測せず、ポート 8095 の /info の応答から Music Assistant サーバを識別してバージョンを表示します。

11.15ディスク・RAID・SMART の健全性

ドライブは、耳を傾けていれば予兆とともに故障します。Disk Health ペイン（組み込みの監視ツール）は複数の層を組み合わせます。ボリュームの空き容量と Time Machine の状態は常に表示されます。smartmontools をインストールすると（ワンクリックの Install ボタン）、各物理ドライブがディープ SMART 属性——健全性、温度、通電時間、代替済み／保留中セクター、故障予測フラグ——で補強され、ドライブごとに Check ボタンと、生レポート用の Details シートで確認できます。ドライブは SMART 失敗または懸念される属性（代替済み／保留中セクター、故障予測）でアラートを発報し、完全な死亡時だけではありません。

ソフトウェアの AppleRAID セット（ミラー、ストライプ、連結）は、レベル・状態・メンバーごとの状態とともに独自のセクションに表示されます。セットが劣化したりメンバーがオフラインになるとアラートが発報します。Alerts & Thresholds でディスクアラートをオンにすれば、他のすべてのモニタと同様にチャネルへ流れます。

これらのモニタを合わせると、ひと目で見るボード 1 つ、調整するペイン 1 つ、あなたに届くチャネル 1 式が得られます——そして同じ健全性を読み、あなたに代わって同じ通知を送る AI 管理者（第 13 章）があります。フリート全体の CPU・メモリ・GPU メトリックをこの像に流し込むホストモニタは第 8 章で扱います。

11.16サーバアクティビティウィンドウ

1 台を設定するのではなくすべてを同時に見たいときは、Monitors ▸ Server Activity Window（⇧⌘A、またはツールバーのゲージボタン）を開きます。ピン留めしたサーバと、ライブ状態を報告できるピン留めデバイス — ルータ／ファイアウォール、UPS、PoE スイッチ、マイニングリグ、KVM コンソール、スマートプラグ — だけを収めた独立ウィンドウで、アプリのそれ以外は含みません。各タイルは選んだメトリクスをスパークラインと状態ドット付きで表示し、注意が必要ならオレンジや赤になります。

レイアウトがボードの内容を決めます。組み込みは All Servers、Macs、CPU 順のコンパクトな Cluster グリッド、Mining Rigs & GPUs、Network & Power、Everything。コピーをカスタマイズするか自作でき、対象の種類、サーバフィルタ、個別メンバ、メトリクスとその順序、タイルサイズ、グループ化、並び順、サンプリング間隔を選べます。値は FrontierStack モニタがあればそこから、なければ 1 回の SSH 往復で取得し、サンプリングはウィンドウを開いている間だけ動作します。

このウィンドウはキーボードで操作できるよう作られています。矢印キーで選択がボードや一覧を移動し、上下はタイル 1 行分進みます。⌘↑／⌘↓ で先頭・末尾へ、⇧⌘0 でボードに戻り、esc は詳細 → ボード → ウィンドウを閉じる、と一段ずつ戻ります。⌘1〜⌘9 でレイアウトを直接選択、⌥⌘←／⌥⌘→ で順に切り替え、⌘E で編集、⌘⌫ で選択中の対象を隠します。⌘F でフィルタ、⌘R で即時サンプリング、⌥⇥ でタブ移動、⌘T でターミナルウィンドウ、⇧⌘O でメインウィンドウ表示、⇧⌘K で全サーバにコマンド実行、⌃⌘S で一覧の表示切り替え。⌘/ でいつでも一覧を表示できます。

Run on All… はレイアウト内の全サーバでひとつのコマンドを実行します。デバイスにも専用の詳細があります：ルータのゲートウェイと IDS アラート、UPS のバッテリと電圧、PoE スイッチのポート制御、リグのハッシュレートとシェア、KVM のコンソールと電源、プラグの状態とワット。

Proxmox VE クラスタを接続すると、All Servers・Cluster・Everything の各レイアウトにノードごとのタイルが加わり、CPU・メモリ・ディスク・稼働時間のスパークラインと、実行中の VM とコンテナの数が表示されます。詳細にはすべてのゲストが起動・シャットダウン・再起動・停止・リセットの操作付きで並び、ノードのストレージとクラスタのクォーラムが表示され、Boot an ISO… で Boot Media ペインへ移動できます。クラスタの接続方法は第 8 章で扱います。

ウィンドウのタイトルバーには 3 つのコントロールがあります。外観はこのウィンドウだけをダークまたはライトにします（アプリの他の部分はライトのまま監視ボードだけ暗くしたい場合に便利）。アプリに従う → ダーク → ライトの順に切り替わります。タブ配置は、選択したサーバのタブをコンテンツ上部の横並びと、横の縦型リストとで切り替えます。縦型は背の高いウィンドウに向き、すべてのタブを一度に表示できます。キーボードはショートカット一覧を開きます。どちらの切り替えもレイアウトエディタと ⇧⌘D／⇧⌘L から行えます。