監視とアラート

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

11.1Local Health ボード

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

このボードは、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）が発生時にメッセージされ、既存の履歴は再アラートされません。

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

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

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

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

トークンと 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チェックです。

データベースのハートビートは、プロセス／ポート確認が見逃す故障を捉えます。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.11.2保守のためにチェックを一時停止する

意図的にサービスを停止している最中に、再起動してくれるウォッチドッグはまさに邪魔です。保護をオフにして — そして自分で戻し忘れないことに頼る — のではなく、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 に表示できます。

同じパターンがプロジェクト管理ツールにトークンログインのライブペインを与えます。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 デバイス

電源は、停電するまで忘れられがちな故障モードです。FrontierStack は UPS を 3 通りで検出します——macOS の電源ソース（pmset -g ps）、NUT デーモン（upsc）、apcupsd（apcaccess）——そして充電・残時間・負荷・入力を Power Control の UPS セクションに表示します。アラートをオンにすれば、ユニットがバッテリー駆動になったとき、設定した低充電しきい値に達したとき、コントローラとの通信を失ったときに呼び出されます。UPS をピン留めすれば Local Health と Places マップに残せます。NUT や apcupsd が無ければワンクリックボタンでインストールできます。スキャンはこれらのデーモンの応答を待つため、実行中は Stop ボタンが表示されます。NUT サーバが固まっている場合は待ち続けずに停止でき、取得済みの読み取り値は保持され、自動更新は Refresh を押すまで一時停止します。

SNMP を話すその他のもの——マネージドスイッチ、プリンタ、ネットワーク UPS、NAS——には、デバイス詳細ペインの SNMP / OIDs セクションが直接問い合わせます。組み込みのテンプレート（System、Host Resources、Interfaces、Printer RFC 3805、UPS RFC 1628、Synology、QNAP、APC PowerNet）を選んで Query を押せばラベルと値の読み出しが得られ、単一のカスタム OID を手動で取得することもできます。OID をウォッチすることも可能です。比較としきい値（より大きい、等しい、含む、または単に「変化したら通知」）を設定すると、FrontierStack がポーリングし、条件が満たされるとアラートを発報します。net-snmp を使い、ワンクリックでインストールできます。

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

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

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

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