イベントセンターと通知
イベントセンターでは、システム内で発生した事象を記録します。通知ルールでは、どのイベントをどこへ送信するかを決定します。まずイベントが安定して記録されることを確認し、その後で有用な通知だけを少数設定してください。正常なアクセスまで毎回通知して、アラートがノイズに埋もれないようにします。
データ間の関係
| オブジェクト | 役割 |
|---|---|
| イベント | ログイン、ブロック、更新、状態変化を 1 件ずつ記録した構造化データ |
| プロバイダー | Webhook、メール、プッシュ通知チャネルの接続設定と認証情報 |
| ルール | イベント種別、集計期間、トリガー数、集約単位、クールダウンに基づいて通知するかを決定する設定 |
| 通知先 | ルールが参照するプロバイダーと、そのルール専用の送信先 |
| 配信記録 | ルールのトリガー後、通知先ごとに生成される送信および再試行の記録 |
イベントを削除しても、すでに生成された配信記録は削除されません。配信履歴をクリアしても、イベントやルールは削除されません。ルールを削除すると以後の通知だけが停止し、既存のイベントには影響しません。
イベントページ
イベントページでは、現在次の 21 種類のシステムイベントを認識します。
- 認証：ログイン成功、ログアウト、ログイン失敗、セッション IP 変更。
- セキュリティ：スキャナーをブロック、ゲートウェイのレート制限、ゲートウェイの公開範囲によるブロック、WAF によるブロック。
- SSH：SSH ログイン成功、SSH ログイン失敗、SSH IP をブロック。
- ネットワーク：DDNS 更新完了、FRP 接続／切断、Cloudflared 接続／切断。
- システム：アプリの更新あり、CPU 使用率アラート／復旧、メモリ使用率アラート／復旧。
イベントのレベルは「情報」「注意」「エラー」「重大」に、ソースシステムは「管理画面」「認証プロキシ」「システム監視」に分かれます。
このページでは、次の操作を行えます。
- イベント ID、IP、セッション、認証情報を検索する。
- イベント種別、レベル、ソースシステムで絞り込む。
- ページ単位で表示し、構造化された詳細を開く。
- イベントを 1 件ずつ削除するか、選択したイベントを一括削除する。
- すべてのイベントをクリアする。
「イベントをクリア」を実行すると、イベントセンターに保存されているすべてのイベントが削除されます。括弧内の件数は現在の表示に一致する件数を示すだけで、現在の絞り込み結果だけを削除するという意味ではありません。この操作は元に戻せませんが、通知ルールと配信記録は削除されません。
イベントの詳細には、種別に応じて認証情報、認証方式、セッション、IP と地域、失敗回数、ブロック期間、DDNS アドレスの変更、Trace ID、WAF ルール、トンネル PID、リソースしきい値などが表示されます。ゲートウェイの公開範囲によるブロックでは、リクエストの Host、パス、メソッドと、グローバル設定または Host 固有の範囲のどちらが適用されたかも記録されます。トラブルシューティング時は詳細をコピーし、リクエストログ、WAF ログ、トンネルログと照合できます。
CPU とメモリの監視
リソース監視は、実行時に必要な機能を利用できるプラットフォームでのみ起動します。現在、Windows 環境ではこの機能を利用できません。Linux 系環境では、システムのリソース情報からホスト全体、または現在のコンテナから見える範囲の CPU 使用率と使用可能メモリを算出し、アラートイベントと復旧イベントを生成します。これはプロセス単位のパフォーマンス分析機能ではないため、負荷の原因となったプロセスまでは特定できません。
現在のデフォルト条件は次のとおりです。
| 指標 | アラートしきい値 | 復旧しきい値 | サンプリング間隔 | 継続時間 |
|---|---|---|---|---|
| CPU | 80% | 60% | 5 秒 | 30 秒 |
| メモリ | 80% | 60% | 5 秒 | 30 秒 |
使用率がアラートしきい値以上の状態で継続した場合にのみ、アラートが生成されます。アラート後も、復旧しきい値まで低下した状態が継続して初めて復旧イベントが生成されます。60%–80% の中間範囲を設けることで、しきい値付近でアラートが繰り返されるのを防ぎます。一時的なスパイクからイベントがすぐに生成されることはなく、最初の CPU サンプルも計算の基準値を確立するためだけに使用されます。
現在の管理画面ではリソースイベントを確認して通知を設定できますが、上記のサンプリング条件やしきい値を変更することはできません。通知ルールの「集計期間」や「トリガー数」をリソース監視のしきい値と混同しないでください。前者は生成済みのイベントをどのように通知するかを決め、後者はイベントがいつ生成されるかを決めます。
Docker では、コンテナの実行環境から見える CPU とメモリの範囲が監視対象になります。デプロイ時にリソース制限を設定している場合は、その制限を踏まえてアラートを判断してください。リソースイベントが生成されない場合は、まず現在のプラットフォームが監視に対応し、イベントシステムが正常に動作していることを確認します。そのうえで、負荷が実際にしきい値を超えた状態で継続しているかを確認してください。
プロバイダーの設定
イベントセンター → 通知 → プロバイダー を開き、最初に送信チャネルを作成してテストします。現在利用できるプロバイダーは次のとおりです。
- Webhook。
- WxPusher。
- ServerChan。
- PushPlus。
- WeCom グループ Bot。
- DingTalk Bot。
- Feishu Bot。
- メール。
- PushDeer。
- HarmonyOSMeoW。
- MagicPush。
- Bark。
- Telegram。
Markdown、操作ボタン、メンション、メッセージ長への対応はチャネルごとに異なります。プロバイダーの追加時に表示されるフィールドと機能を確認してください。
作成時に、名前、種類、有効／無効、接続設定を指定します。一部のチャネルにはデフォルトの通知先もあり、ルール側の対応する通知先フィールドを空欄にすると、プロバイダーのデフォルト値が継承されます。現在、WxPusher の通知を受け取るには公式アプリをインストールしてログインする必要があり、WeChat 内で直接受信することはできません。
保存前にフォームの下書き設定をテストでき、保存後も一覧から再度テストできます。編集時、機密フィールドには「すでに設定されています。変更しない場合は空白のままにしてください」と表示されます。シークレットを維持するために、以前の値を再度貼り付ける必要はありません。
Webhook URL、トークン、SMTP パスワード、受信者識別子などは機密情報です。公開ログやスクリーンショットに含めないでください。プロバイダーがルールから参照されている場合、バックエンドによって削除が拒否されます。先に該当するルールを変更または削除してください。
HarmonyOSMeoW
HarmonyOSMeoW を選択し、次の項目を入力します。
| フィールド | 説明 |
|---|---|
サービス URL | 公式 API ではデフォルトの https://api.chuckfang.com を使用します。セルフホストした互換サービスの場合は、そのルート URL を入力します |
受信者ニックネーム | MeoW アプリで設定したユーザーニックネームです。/ は使用できません。受信者識別子に相当するため、機密情報として管理してください |
タイムアウト秒数 | デフォルトは 5 秒で、1～30 秒の範囲で設定できます |
このチャネルは Markdown 通知と通知操作に対応していますが、メンションには対応していません。保存後は、まずテストメッセージを送信して HarmonyOS デバイスで受信できることを確認し、その後プロバイダーを通知ルールに追加してください。
通知ルールの作成
イベントセンター → 通知 → ルール を開きます。ルールを作成するには、プロバイダーが 1 つ以上必要です。現在、イベント種別ごとに作成できるルールは 1 つだけです。追加画面にはルールが未設定のイベントだけが表示され、複数のイベントを選択して一括作成できます。
一括作成では、次のデフォルトのトリガー条件が使用されます。
| フィールド | 新規作成時のデフォルト値 | 説明 |
|---|---|---|
| 集計期間 | 60 秒 | この期間内に、同じグループのイベントを集計します |
| トリガー数 | 1 回 | この回数に達すると通知を生成します |
| 集約単位 | イベントの推奨設定を使用 | どのイベントを同じグループとして数えるかを決定します |
| クールダウン | 60 秒 | 同じグループでトリガーされた後、重複通知を抑制します |
ルールの作成後、トリガー条件をルールごとに編集できます。集約単位には、グローバル、IP、セッション、対象、ホスト名、プロバイダーがあります。推奨設定の例は次のとおりです。
- ログイン失敗、スキャナー、ゲートウェイのレート制限、WAF、SSH の各イベントは IP で集約する。
- ゲートウェイの公開範囲によるブロックはグローバルで集約する。
- セッション IP 変更はセッションで集約する。
- DDNS 更新はプロバイダーで集約する。
- CPU とメモリのイベントはホスト名で集約する。
- トンネルとアプリ更新は対象で集約する。
- ログイン成功とログアウトはグローバルで集約する。
1 つのルールに複数のプロバイダーを追加できますが、同じプロバイダーを同一ルールへ複数回追加することはできません。一部のプロバイダーでは、ルールの通知先に受信者、トピック、Chat ID、またはその他の通知先フィールドを入力する必要があります。これらのフィールドが影響するのは現在のルールだけです。
最初に推奨するルール
- ログイン失敗：IP で集約し、短い集計期間内に複数回発生した場合に通知する。
- スキャナー、ゲートウェイのレート制限、WAF、SSH ブロック：IP で集約する。
- ゲートウェイの公開範囲によるブロック：デフォルトではグローバルで集約する。トラフィックが多い場合は、同じポリシーによる通知の集中を防ぐため、しきい値を上げるかクールダウンを延長する。
- DDNS：プロバイダーで集約し、失敗結果に注意する。
- FRP と Cloudflared：対象で集約し、トンネルごとに区別する。
- CPU とメモリ：アラートイベントと復旧イベントの両方にルールを設定する。
- アプリ更新：対象で集約し、通知を 1 回送信する。
ログイン成功や SSH ログイン成功などの頻度が高いイベントは、トリガー数を 1 にすると大量の通知が発生する可能性があります。実際のアクセス量に合わせて、集計期間、トリガー数、クールダウンを調整してください。
配信結果の確認
配信履歴 には、トリガー日時、ルール、プロバイダー、状態、メッセージの概要、試行回数が表示されます。状態には「待機中」「送信中」「成功」「失敗（再試行中）」「再試行を中止」「スキップ」があります。
詳細では次の情報を確認できます。
- ルール、プロバイダー、現在の状態。
- 試行回数、トリガー日時、送信時刻、次回再試行。
- 失敗またはスキップした理由。
- 送信時点で固定されたタイトル、概要、本文のスナップショット。
- 機密情報をマスキングしたリクエスト概要と応答概要。
「ルールがトリガーされない」「プロバイダーで受信できない」ときは、次の順序で確認します。
- 最初に、イベント自体が生成されていることを確認します。
- そのイベント種別にルールがあり、ルールと通知先が有効になっていることを確認します。
- 集計期間、トリガー数、集約単位、クールダウンを確認します。
- 配信記録がある場合は、状態、失敗理由、試行回数、次回再試行を確認します。
- プロバイダーへの接続、認証情報、通知先、送信先のレート制限を確認します。
配信履歴をクリアすると、すべての配信記録が削除され、元に戻すことはできません。ただし、イベントや以後のルールのトリガーには影響しません。監査が必要な場合は、先に関連する詳細をコピーしてください。
通知システムは対応を補助するものであり、リクエストログ、WAF ログ、バックアップの代わりにはなりません。