Ntfy 哪吒監視v1通知設定給餌級チュートリアル

本チュートリアルでは、公式の Ntfy サービス (https://ntfy.sh/) を使用して、哪吒監視の通知機能を設定する方法を案内します。本チュートリアルは、すぐに使える設定を提供することに重点を置いています。

Ntfy はシンプルで強力なプッシュ通知サービスで、以下の利点があります：完全にオープンソースで無料で使用でき、自ホスティングをサポートし、アカウント登録なしで使用でき、複数のプラットフォーム（Android、iOS、Web）をサポートし、設定が簡単で迅速で、エンドツーエンドの暗号化をサポートし、サーバー監視通知の理想的な選択肢です。その軽量な特性とシンプルな API により、特に哪吒監視との統合に適しています。

対照的に、Server 酱の無料版には以下の制限があります：

毎日 5 件のプッシュメッセージのみサポートし、超過分は有料で、自ホスティングをサポートせず、完全にサードパーティサービスに依存しています。メッセージチャネルは単一で、WeChat プッシュのみをサポートします。無料版のメッセージはグループ管理をサポートせず、メッセージの取り消しなどの高度な操作ができず、サービスの可用性は WeChat 公開アカウントプラットフォームに依存しています。

設定説明#

基本情報#

名称: Ntfy
URL: https://ntfy.sh/
リクエスト方式: POST
タイプ: JSON
リクエストヘッダー:
```
{
  "Content-Type": "application/json"
}
```
注意: Ntfy の公式サービスでは Authorization ヘッダーは必要ありません。

リクエストボディ:

{
  "topic": "哪吒監控",
  "title": "サーバー状態 - #SERVER.NAME#",
  "message": "CPU: #SERVER.CPU#% | メモリ: #SERVER.MEM# | ディスク: #SERVER.DISK# | 上り: #SERVER.NETOUTSPEED# | 下り: #SERVER.NETINSPEED# | 負荷: #SERVER.LOAD1#/#SERVER.LOAD5#/#SERVER.LOAD15#",
  "priority": 3,
  "tags": ["warning"]
}

重要: 哪吒監控 を、購読したいトピック名に置き換えてください。安全性を確保するためにランダムな文字列の使用をお勧めします。

使用手順#

ntfy アプリのインストール
- Google Play または F-Droid から ntfy アプリをインストールします（またはウェブ版 https://ntfy.sh/ を使用します）。
- アプリを開き、リクエストボディで設定したトピック名（例: 哪吒監控）を購読します。
- 選択したトピックをメモしておいてください。後の設定で使用します。
哪吒監視パネルに通知設定を追加
- 哪吒監視パネルを開きます。
- 通知設定ページに移動します。
- "通知を追加" をクリックします。
- “設定説明” セクションに従って情報を入力します。
  - URL: https://ntfy.sh/
  - リクエスト方式: POST を選択
  - タイプ: JSON を選択
  - リクエストヘッダー: 上記の JSON 内容をコピー＆ペーストします。
  - リクエストボディ: 上記の JSON 内容をコピー＆ペーストし、必ず topic を Ntfy アプリで購読したトピックに変更してください。
  - TLS 検証: このオプションにチェックを入れます。
通知のテスト
- 設定を保存した後、"テスト" ボタンをクリックしてテスト通知を送信します。
- あなたの携帯電話または Ntfy アプリが通知を受け取ったか確認します。

詳細説明#

URL#

公式の Ntfy サービスを使用する際、URL は固定で https://ntfy.sh/ であり、URL にトピック名を追加する必要はありません。

リクエストヘッダー#

公式の Ntfy サービスでは、Content-Type を application/json に設定するだけで、Authorization は不要です。

リクエストボディ#

topic: これは Ntfy アプリで購読したトピックであり、この値がアプリで購読した名前と一致することを確認してください。通知を受け取るための重要な要素です。
title: 通知のタイトルで、#SERVER.NAME# はサーバーの名前に置き換えられます。
message: 通知の具体的な内容で、サーバーの CPU、メモリ、ディスク、ネットワーク速度、負荷などの情報が含まれます。
priority: 通知の優先度で、3 は中程度の優先度です。
tags: タグで、必要に応じて追加できます。ここでは "warning" を使用しています。

変数説明#

#SERVER.NAME# : サーバー名
#SERVER.CPU# : CPU 使用率
#SERVER.MEM# : メモリ使用状況
#SERVER.DISK# : ディスク使用状況
#SERVER.NETINSPEED# : ネットワーク入出速度
#SERVER.NETOUTSPEED# : ネットワーク出入速度
さらなる変数情報は、哪吒監視の公式ドキュメントを参照してください。 https://nezha.wiki/guide/notifications.html

注意事項#

トピック: Ntfy アプリで購読したトピック名がリクエストボディの topic の値と一致していることを確認してください。
TLS 検証: 通信の安全性を確保するために "TLS 検証" オプションにチェックを入れる必要があります。
テスト: 通知が正常に送信されたかをテストすることは、設定が正しいことを確認するための重要なステップです。

よくある質問#

通知が受信できない：
- Ntfy アプリが正しいトピックを購読しているか確認してください。
- リクエストボディの topic が購読したトピックと一致しているか確認してください。
- "TLS 検証" オプションがチェックされていることを確認してください。
通知形式が間違っている：
- リクエストボディの JSON 形式が正しいか確認してください。
- Content-Type が application/json に設定されているか確認してください。

アラートルール設定 (概要)#

アラートルールの設定方法は以前のドキュメントと同様で、適切なトリガー条件と通知グループを設定することが重要です。
実際のニーズに応じて、CPU、メモリ、ディスク、ネットワーク、オフラインなど、さまざまな監視タイプのアラートルールを設定できます。
詳細な設定手順は、哪吒監視の公式ドキュメントおよび本ドキュメントの前の “アラートルール設定” セクションを参照してください。

上級説明#

自ホスティング Ntfy サーバーのインストール#

準備作業
- サーバーに Docker と Docker Compose がインストールされていることを確認します。
- ドメイン名を用意し、サーバーに解決します（オプションですが推奨）。
- Caddy または Nginx をリバースプロキシとして使用することをお勧めします。
Docker Compose 設定の作成

ディレクトリを作成し、docker-compose.yml を作成します:

mkdir -p /opt/ntfy
cd /opt/ntfy
vim docker-compose.yml

設定ファイルの内容:

version: "3.8"

services:
  ntfy:
    image: binwiederhier/ntfy
    container_name: ntfy
    command:
      - serve
    environment:
      - TZ=Asia/Shanghai
    volumes:
      - ./data:/var/lib/ntfy
      - ./cache:/var/cache/ntfy

    ports:
      - 8080:80

具体的なチュートリアルは公式ドキュメントを参照してください: https://ntfy.sh/docs/self-hosting/docker

Cloudflare Tunnel を使用した内網貫通#

Ntfy サーバーが内網環境にデプロイされている場合は、Cloudflare Tunnel を使用して安全な内網貫通を行うことをお勧めします。これにより：

ポートを開放する必要がない
SSL 証明書を自動的に設定
DDoS 保護を受ける
アクセス制御をサポート

Docker Compose に Cloudflare Tunnel を統合

version: "3.8"

services:
  ntfy:
    image: binwiederhier/ntfy
    container_name: ntfy
    command:
      - serve
    environment:
      - TZ=Asia/Shanghai
    volumes:
      - ./data:/var/lib/ntfy
      - ./cache:/var/cache/ntfy
      - ./config.yml:/etc/ntfy/config.yml
    ports:
      - 8080:80

  cloudflared:
    image: cloudflare/cloudflared
    container_name: cloudflared
    command: tunnel run
    environment:
      - TUNNEL_TOKEN=your-tunnel-token
    restart: unless-stopped

これにより、Cloudflare にドメインがあればいつでもアクセスできるようになります。

リクエストヘッダー#

自ホスティングの Ntfy サービスでは、Content-Type を application/json に設定し、Authorization を設定することをお勧めします。

Authorization トークン設定#

Basic Auth 方法

{
  "Content-Type": "application/json",
  "Authorization": "Basic base64(username:password)"
}

実際の例

アカウントのユーザー名とパスワードが次のような場合：

ユーザー名：monitor
パスワード：ntfy2024

base64 エンコードを生成します：

# Linux/Mac
echo -n "monitor:ntfy2024" | base64
# 出力: bW9uaXRvcjpudGZ5MjAyNA==

# Windows PowerShell
[Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes("monitor:ntfy2024"))
# 出力: bW9uaXRvcjpudGZ5MjAyNA==

完全なリクエストヘッダーの例

{
  "Content-Type": "application/json",
  "Authorization": "Basic bW9uaXRvcjpudGZ5MjAyNA=="
}

注意：

実際のユーザー名とパスワードに置き換えてください
Base64 エンコードは暗号化ではないため、リクエストヘッダーにプレーンテキストのパスワードを使用しないでください
HTTPS を使用して伝送の安全性を確保することをお勧めします

例の設定:

{
  "topic": "哪吒监控",
  "title": "警報 - #SERVER.NAME#",
  "message": "CPU使用率が90%を超えました: #SERVER.CPU#%",
  "priority": 5,
  "tags": ["warning", "cpu"]
}

カスタムメッセージテンプレート

{
  "topic": "哪吒监控",
  "title": "【#SERVER.STATUS#】#SERVER.NAME#",
  "message": "時間: #SERVER.DATE#\n状態: #SERVER.STATUS#\n詳細: CPU=#SERVER.CPU#% MEM=#SERVER.MEM#\n位置: #SERVER.LOCATION#",
  "priority": 3,
  "tags": ["status", "#SERVER.STATUS#"],
  "click": "https://あなたの哪吒監視のアドレス"
}

例の設定:

{
  "topic": "哪吒监控",
  "title": "警報 - #SERVER.NAME#",
  "message": "CPU使用率が90%を超えました: #SERVER.CPU#%",
  "priority": 5,
  "tags": ["warning", "cpu"]
}

オフラインアラート

{
  "topic": "哪吒监控",
  "title": "【オフラインアラート】#SERVER.NAME#",
  "message": "⚠️ サーバーがオフラインです\nホスト名: #SERVER.HOST#\nIP: #SERVER.IP#\nオフライン時間: #DATETIME#",
  "priority": 5,
  "tags": ["alert", "offline"]
}

リソースアラート

{
  "topic": "哪吒监控",
  "title": "【リソースアラート】#SERVER.NAME#",
  "message": "CPU: #SERVER.CPU#% | メモリ: #SERVER.MEM#% | ディスク: #SERVER.DISK#%\n負荷: #SERVER.LOAD1#/#SERVER.LOAD5#/#SERVER.LOAD15#",
  "priority": 4,
  "tags": ["warning", "resource"]
}

トラフィックアラート

{
  "topic": "哪吒监控",
  "title": "【トラフィックアラート】#SERVER.NAME#",
  "message": "月間トラフィックの制限を超えました\n上り: #SERVER.TRANSFEROUT#\n下り: #SERVER.TRANSFERIN#",
  "priority": 3,
  "tags": ["warning", "traffic"]
}

サポートされる変数#

通知メッセージ内で次の変数を使用できます：

変数	説明
#NEZHA#	通知内容
#DATETIME#	イベントが発生した時間
#SERVER.NAME#	サーバー名
#SERVER.IP#	サーバー IP
#SERVER.IPV4#	IPv4 アドレス
#SERVER.IPV6#	IPv6 アドレス
#SERVER.CPU#	CPU 使用率
#SERVER.MEM#	メモリ使用率
#SERVER.SWAP#	スワップ領域使用率
#SERVER.DISK#	ディスク使用率
#SERVER.NETINSPEED#	リアルタイムのアップロード速度
#SERVER.NETOUTSPEED#	リアルタイムのダウンロード速度
#SERVER.TRANSFERIN#	総アップロードトラフィック
#SERVER.TRANSFEROUT#	総ダウンロードトラフィック
#SERVER.LOAD1#	1 分間の負荷
#SERVER.LOAD5#	5 分間の負荷
#SERVER.LOAD15#	15 分間の負荷

通知設定の例#

基本設定項目#

設定項目	説明	例の値
名称	通知方式の名称	ntfy-alert
URL	Ntfy サーバーのアドレス	https://ntfy.sh/
リクエスト方式	固定で POST	POST
リクエストタイプ	固定で JSON	JSON
最大リトライ回数	失敗時のリトライ回数	3
通知間隔（秒）	2 回の通知の最小間隔	300

アラートルール設定#

オフライン監視

[
  {
    "Type": "offline",
    "Duration": 300
  }
]

リソース監視

[
  {
    "Type": "cpu",
    "Max": 90,
    "Duration": 300
  },
  {
    "Type": "memory",
    "Max": 90,
    "Duration": 300
  }
]

月間トラフィック監視

[
  {
    "Type": "transfer_out_cycle",
    "Max": 1099511627776,
    "Cycle_start": "2024-01-01T00:00:00+08:00",
    "Cycle_interval": 1,
    "Cycle_unit": "month",
    "Cover": 1,
    "Ignore": {"1": true, "2": true}
  }
]

ルール説明#

Duration: 持続時間（秒）、この期間中に 30% を超えるとアラートが発生します
Max/Min:
- トラフィック単位：バイト (1KB=1024B)
- CPU / メモリ / ディスク：パーセンテージ (0-100)
Cover:
- 0: すべてのサーバーを監視
- 1: 指定したサーバーのみを監視
Ignore: 指定したサーバー ID の監視ポリシー

アラートと通知の違い#

アラートルール

通知を送信する条件を定義します（どのような場合に通知を送信するか）
閾値、持続時間などの具体的な判断基準を含みます
異なるサーバーに対して異なるルールを設定できます
複数の監視タイプ（CPU、メモリ、ディスクなど）をサポートします

通知設定

メッセージをどのように送信するかを定義します（どの方法で通知を送信するか）
メッセージ形式、受信方法などを含みます
複数の通知方法を設定できます
カスタムメッセージテンプレートをサポートします

ワークフロー#

アラートトリガーフロー

監視データ -> アラートルールにマッチ -> 通知をトリガー

ルールマッチングロジック

監視指標をチェック
閾値を超えたか判断
持続時間を確認
無視する必要があるか検証

通知送信フロー

通知内容を生成
メッセージテンプレートを適用
設定された通知方法で送信

ベストプラクティス#

アラートルール設定

サーバーの性能に基づいて合理的な閾値を設定
過度なアラートを避ける
誤報を避けるために持続時間を合理的に設定
重要なサーバーに対してより厳格なルールを設定

通知設定の推奨

適切な通知間隔を設定
アラートレベルに応じて異なる優先度を使用
明確なメッセージ形式をカスタマイズ
送信失敗に対処するためのリトライメカニズムを設定

監視メンテナンス

定期的にルールの有効性を確認
不合理な閾値を迅速に調整
アラート履歴を分析して設定を最適化
通知方法の可用性を確保