イベントセンターと通知

イベントセンターでは、システム内で発生した事象を記録します。通知ルールでは、どのイベントをどこへ送信するかを決定します。まずイベントが安定して記録されることを確認し、その後で有用な通知だけを少数設定してください。正常なアクセスまで毎回通知して、アラートがノイズに埋もれないようにします。

データ間の関係

オブジェクト	役割
イベント	ログイン、ブロック、更新、状態変化を 1 件ずつ記録した構造化データ
プロバイダー	Webhook、メール、プッシュ通知チャネルの接続設定と認証情報
ルール	イベント種別、集計期間、トリガー数、集約単位、クールダウンに基づいて通知するかを決定する設定
通知先	ルールが参照するプロバイダーと、そのルール専用の送信先
配信記録	ルールのトリガー後、通知先ごとに生成される送信および再試行の記録

イベントを削除しても、すでに生成された配信記録は削除されません。配信履歴をクリアしても、イベントやルールは削除されません。ルールを削除すると以後の通知だけが停止し、既存のイベントには影響しません。

イベントページ

イベントページで認識するシステムイベントには、次のものがあります。

認証：ログイン成功、ログアウト、ログイン失敗、セッション IP 変更。
セキュリティ：スキャナーをブロック、ゲートウェイのレート制限、ゲートウェイの公開範囲によるブロック、WAF によるブロック。
SSH：SSH ログイン成功、SSH ログイン失敗、SSH IP をブロック。
ネットワーク：DDNS 更新完了、FRP 接続／切断、Cloudflared 接続／切断。
Wake-on-LAN：管理者、ポータル、Blinker、Bemfa からの WOL ブロードキャスト完了。
ターミナル：SSH ターゲット変更、ホスト指紋確認、接続テスト、ローカルターミナルの有効化／無効化、ローカルまたはリモートセッションの作成、終了、Shell の終了、接続喪失。
システム：アプリの更新あり、CPU 使用率アラート／復旧、メモリ使用率アラート／復旧。
ランタイム：コンポーネントの起動、停止、再起動、ヘルスチェック失敗、復旧、異常終了。

イベントのレベルは「情報」「注意」「エラー」「重大」に、ソースシステムは「管理画面」「認証プロキシ」「システム監視」「ランタイム監視」に分かれます。

このページでは、次の操作を行えます。

イベント ID、IP、セッション、認証情報を検索する。
イベント種別、レベル、ソースシステムで絞り込む。
ページ単位で表示し、構造化された詳細を開く。
イベントを 1 件ずつ削除するか、選択したイベントを一括削除する。
すべてのイベントをクリアする。

「イベントをクリア」を実行すると、イベントセンターに保存されているすべてのイベントが削除されます。括弧内の件数は現在の表示に一致する件数を示すだけで、現在の絞り込み結果だけを削除するという意味ではありません。この操作は元に戻せませんが、通知ルールと配信記録は削除されません。

イベントの詳細には、種別に応じて認証情報、認証方式、セッション、IP と地域、失敗回数、ブロック期間、DDNS アドレスの変更、Trace ID、WAF ルール、トンネル PID、WOL の対象と配信元、リソースしきい値などが表示されます。ゲートウェイの公開範囲によるブロックでは、リクエストの Host、パス、メソッドと、グローバル設定または Host 固有の範囲のどちらが適用されたかも記録されます。トラブルシューティング時は詳細をコピーし、リクエストログ、WAF ログ、トンネルログ、デバイスのオンライン状態と照合できます。

ローカルターミナルのイベントには、ターミナルのバックエンド、実行ユーザー、特権ユーザーかどうかが表示され、セッションが実際にどの権限で動作したかを確認できます。ターミナルイベントが監査するのは設定変更とセッションのライフサイクルだけで、管理者が Shell に入力した個々のコマンドは保存しません。コマンド単位の記録が必要な場合は、ホストまたはリモート SSH ターゲット側で別途監査を構成してください。

ページ上部の Trace ID 検索 には、レスポンスヘッダー、ブロックページ、リクエストログ、通知の完全な ID を入力できます。フルチェーントレースは同じリクエストの WAF、システムイベント、通知トリガーと配信を関連付けます。古いイベントや収集が無効な場合は一部だけ表示されます。

ナビゲーションパネル同期の失敗／復旧と、リモート端末の SSH シャットダウンも記録されるため、固定のイベント種類数には依存しないでください。認証・セキュリティイベントは IP 地域キャッシュを共有し、未キャッシュのアドレスは先に保存して非同期で補完され、通知も利用可能な補完フィールドを使います。

コアサービスの状態と診断

イベントセンター → 状態 は 5 秒ごとに更新され、管理サービス、Go ゲートウェイプロセス、ゲートウェイのデータプレーン、認証ブリッジ、ストレージ、設定同期のヘルス状態を表示します。プロセスカードにはバージョン、PID、起動時刻、CPU、メモリ、Go ランタイム情報も表示され、サービスカードにはプローブ遅延と連続失敗の理由が表示されます。依存先によりブロック は、コンポーネント自体は動作可能でも必要な依存コンポーネントが準備できていない状態です。

状態ページでは、次の 3 種類の診断情報を利用できます。

操作	内容と範囲
`診断情報をコピー`	現在のバージョン、プラットフォーム、コンポーネントのヘルス状態、最近のランタイムイベントを JSON でコピー
`ログを表示`	管理サービスまたは Go ゲートウェイの、マスク済みコアランタイムログを最新 200 件表示。リクエスト、WAF、認証の記録は含まない
`診断パッケージをエクスポート`	`diagnostics.json` とサイズ制限付きの管理、ゲートウェイ、スーパーバイザーのログをダウンロード

コア診断ログ全体の上限は 6 MiB です。上限に達するとローテーションまたは低優先度ログの破棄が行われます。状態ページには記録範囲、ディスク使用量、破棄された INFO 件数が表示されます。コンポーネントのログをクリアしても、そのコンポーネントの現在と 1 世代前のコアランタイムログだけが削除され、ランタイムイベント、クラッシュログ、他のコンポーネントログは残ります。

一般的な機密フィールドはマスクされますが、診断パッケージにはバージョン、プラットフォーム、パス、コンポーネント状態、障害時刻が含まれる場合があります。共有前に内容を確認してください。リクエストの詳細は、リクエストログまたは WAF ログから別途エクスポートします。

Rust ランタイム診断

イベントセンター → 状態 → ランタイム診断 で 60 秒の収集を開始 を選ぶと、現在の Rust 管理プロセスのリソース、バックグラウンドタスク、SQLite 操作を毎秒収集します。画面を開くだけでは開始しません。途中で停止して結果を保持でき、画面を閉じてもサーバー側では自動終了まで継続します。

メモリ詳細を収集 は独立したスナップショットで、メモリ回収は行いません。JSON のエクスポートでサンプル、操作統計、メモリ詳細を保存できます。状態画面の診断エクスポートにも現在のレポートを含みます。次の収集で前回分を置き換え、サービス再起動で失われるため、先に保存してください。

CPU は論理コア 1 個の最大負荷を 100% とし、基準のない最初のサンプルはゼロではありません。タスクの経過時間は待機を含み、CPU 時間とは異なります。Linux はより詳細な情報、macOS は主にプロセス CPU と RSS、Windows は主にワーキングセットを提供します。取得不能な項目をゼロと解釈しないでください。他インスタンスや Go ゲートウェイの使用量は含まず、単発の RSS 増加だけでメモリリークとは判断できません。

Go ゲートウェイのメモリ

Go ゲートウェイプロセスカードの右下にあるメモリボタンでは、ガベージコレクションの強度と Go ランタイムのソフトメモリ上限を調整し、即時回収も実行できます。状態カードの Heap、RSS、GC 回数、アクティブリクエスト、接続数は傾向の判断に使えます。ソフト上限は Go ランタイムが管理するメモリを制約するもので、プロセス RSS のハード上限ではありません。

積極的（GOGC 50） は回収頻度を上げ、通常はメモリを抑える代わりに CPU 負荷が増えます。バランス（100） がデフォルト、緩やか（200） はスループットを優先します。カスタム値は 25–500 です。
メモリ上限の自動モードは、実行環境の有効メモリのおよそ 4 分の 1 を 128–512 MiB に制限して使います。有効メモリを取得できない場合は 256 MiB です。
手動上限は 64–4096 MiB で、現在の有効システムメモリの 50% を超えられません。保存値はゲートウェイ起動時、業務トラフィックの受付前に復元されます。
今すぐ回収 は一時的な CPU 増加や停止を起こす可能性があります。調査や回収効果の確認に使い、定期的な最適化操作として繰り返さないでください。

低メモリの NAS やコンテナでは、まず自動上限を維持してください。状態ページで Heap／RSS の圧迫が継続し、トラフィック、詳細監視、異常接続を除外した後にだけ、GOGC を段階的に下げるか手動上限を設定します。変更後は CPU、遅延、ゲートウェイのヘルス状態を同時に確認してください。

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 パスワード、受信者識別子などは機密情報です。公開ログやスクリーンショットに含めないでください。プロバイダーがルールから参照されている場合、バックエンドによって削除が拒否されます。先に該当するルールを変更または削除してください。

Webhook のカスタム内容

Webhook プロバイダーではカスタムヘッダーと標準、JSON、テキストの本文を設定できます。ルールの Webhook 送信先ではプロバイダー設定を継承するか、本文を上書きできます。プレビュー後にテスト送信し、受信側の形式を確認します。

エディターはイベント別の通知詳細と、イベント種別、リスク、送信元、発生時刻、集計などの共通項目を表示します。{{message.fact_values.login_ip}} や {{message.fact_values.credential_name}} の固定名を使います。名前は言語や並び順で変わらず、値は通知用の書式を保持します。元のイベントデータには event.payload.* を使います。

{{message.fact_values}} はオブジェクト全体を参照します。JSON 文字列が変数 1 個だけなら型を保持し、他の文字と混在する場合は文字列になります。イベントにない項目はプレビューで欠落表示され、単独の JSON 変数では null、文中では空文字列になります。送信は停止しません。

サンプル Context が空ならサーバーのサンプルを使います。サンプル JSON を挿入して対象イベント用に編集すると、標準またはカスタム本文のプレビューとテストに使えます。保存されず、実際の配信には影響しません。再試行は元のメッセージのスナップショットを使い、過去のメッセージには fact_values がない場合があります。

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 とメモリのイベントはホスト名で集約する。
トンネルとアプリ更新は対象で集約する。
Wake-on-LAN 完了は対象で集約してデバイスを区別する。
ログイン成功とログアウトはグローバルで集約する。

1 つのルールに複数のプロバイダーを追加できますが、同じプロバイダーを同一ルールへ複数回追加することはできません。一部のプロバイダーでは、ルールの通知先に受信者、トピック、Chat ID、またはその他の通知先フィールドを入力する必要があります。これらのフィールドが影響するのは現在のルールだけです。

最初に推奨するルール

ログイン失敗：IP で集約し、短い集計期間内に複数回発生した場合に通知する。
スキャナー、ゲートウェイのレート制限、WAF、SSH ブロック：IP で集約する。
ゲートウェイの公開範囲によるブロック：デフォルトではグローバルで集約する。トラフィックが多い場合は、同じポリシーによる通知の集中を防ぐため、しきい値を上げるかクールダウンを延長する。
DDNS：プロバイダーで集約し、失敗結果に注意する。
FRP と Cloudflared：対象で集約し、トンネルごとに区別する。
CPU とメモリ：アラートイベントと復旧イベントの両方にルールを設定する。
アプリ更新：対象で集約し、通知を 1 回送信する。
Wake-on-LAN：対象で集約する。失敗結果はアラートに利用できますが、成功結果もブロードキャストが送信されたことだけを示し、デバイスがオンラインになったことは保証しません。

ログイン成功や SSH ログイン成功などの頻度が高いイベントは、トリガー数を 1 にすると大量の通知が発生する可能性があります。実際のアクセス量に合わせて、集計期間、トリガー数、クールダウンを調整してください。

アプリ更新イベントにリリースノートが含まれる場合、現在更新可能なリリースノートの要約はプレーンテキスト本文と Markdown 本文の両方へ書き込まれます。そのため、構造化された詳細ではなく本文だけを表示する配信チャネルでも受信できます。複数の過去のリリースノートが連結されることはありません。完全な内容や以前の内容は バージョンとアップデート またはプロジェクトの Release 履歴で確認してください。

配信結果の確認

配信履歴 には、トリガー日時、ルール、プロバイダー、状態、メッセージの概要、試行回数が表示されます。状態には「待機中」「送信中」「成功」「失敗（再試行中）」「再試行を中止」「スキップ」があります。

詳細では次の情報を確認できます。

ルール、プロバイダー、現在の状態。
試行回数、トリガー日時、送信時刻、次回再試行。
失敗またはスキップした理由。
送信時点で固定されたタイトル、概要、本文のスナップショット。
機密情報をマスキングしたリクエスト概要と応答概要。

「ルールがトリガーされない」「プロバイダーで受信できない」ときは、次の順序で確認します。

最初に、イベント自体が生成されていることを確認します。
そのイベント種別にルールがあり、ルールと通知先が有効になっていることを確認します。
集計期間、トリガー数、集約単位、クールダウンを確認します。
配信記録がある場合は、状態、失敗理由、試行回数、次回再試行を確認します。
プロバイダーへの接続、認証情報、通知先、送信先のレート制限を確認します。

配信履歴をクリアすると、すべての配信記録が削除され、元に戻すことはできません。ただし、イベントや以後のルールのトリガーには影響しません。監査が必要な場合は、先に関連する詳細をコピーしてください。

通知システムは対応を補助するものであり、リクエストログ、WAF ログ、バックアップの代わりにはなりません。

イベントセンターと通知 ​

データ間の関係 ​

イベントページ ​

コアサービスの状態と診断 ​

Rust ランタイム診断 ​

Go ゲートウェイのメモリ ​

CPU とメモリの監視 ​

プロバイダーの設定 ​

Webhook のカスタム内容 ​

HarmonyOSMeoW ​

通知ルールの作成 ​

最初に推奨するルール ​

配信結果の確認 ​