第707回では、シンプルな監視ツールであるUptime Kumaを紹介しました。ですがそれから4年が経過しました。Kumaのバージョンは2系に進化し、様々な仕様変更や機能強化がなされています。今回はバージョン2系の最新版（本記事執筆時点で2.1.1）を使い、シンプルな家庭内監視システムを構築してみましょう。

なお名前であるKumaは日本語です。ドキュメントには以下のように記載されています。

Kuma (クマ/熊) means bear 🐻 in Japanese. A little bear is watching your website.🐻 🐻 🐻

バージョン1系からのマイグレーション

以前の記事を参考に、Kumaのバージョン1系を運用している方もいるかもしれません。Dockerで運用している場合であれば、イメージのタグを2系へ更新し、コンテナを再起動するだけでマイグレーション可能です。

ですがバージョン1系と最新の2系の間には、いくつかの重大な変更が含まれています。廃止された機能もありますし、ホストの構成によってはマイグレーションできないパターンもあるようです。また従来はバックエンドデータベースにSQLite3しか使えませんでしたが、現在ではMariaDBが使えるようになっています。しかしSQLite3からMariaDBへの自動的なマイグレーションはサポートされていません。サードパーティ製ツールを使った手動マイグレーションは可能ですが、これはこれで面倒でしょう。家庭内の監視程度に、そこまで手間をかけるのかという問題もあります。Kumaは非常にシンプルで、設定すべき項目も少ないのが特徴です。そのため過去のデータを捨ててもよく、再設定が面倒でない程度の規模であれば、新規構築し直すほうが楽でしょう。

もしもマイグレーションを行う場合は、移行ガイドを熟読し、既存データをバックアップした上で行ってください。

Uptime Kuma(v2)を起動する

それではKumaを起動しましょう。今回もDockerを使って運用しますので、あらかじめDockerをインストールしておいてください。Dockerに渡すパラメータ一式をYAMLで管理できたほうが便利なので、今回はComposeも使えるようにします。Ubuntuのリポジトリから「docker.io」「⁠docker-compose-v2」パッケージをインストールしても構いませんし、Docker公式の手順でも構いません。

ホームディレクトリに「kuma」ディレクトリを作り、この中で運用しましょう。

$ mkdir ~/kuma && cd ~/kuma

compose.yamlを以下の内容で作成します。

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2.1.1
    restart: unless-stopped
    volumes:
      - ./data:/app/data
      - /var/run/docker.sock:/var/run/docker.sock
    ports:
      - "3001:3001"

Kumaの主なイメージタグは以下の通りです。

使用するイメージの選定基準としては、おおむね以下のようになるでしょう。

• 2系の最新を自動的に追従してほしい人 → 2
• 勝手にバージョンを上げてほしくない人 → 2.x.x
• Kumaの最新を追いたい人 → next
• 内蔵のMariaDBや、Browser Engine監視タイプは不要という人 → 各種Slim版

公式としては、「⁠2」ないし「2-slim」の利用が推奨されています。ただし筆者は意図しないトラブルを避けるという意味から、コンテナのバージョンを確実に固定したいため、今回は「2.1.1」を指定しています[1]。ちなみにSlim版のイメージにMariaDBは含まれていませんが、ネットワークを介して外部のMariaDBサーバーに接続はできます。MariaDBコンテナをComposeで別立てしたいような場合も、Slim版を利用するとよいでしょう。

Rootless Docker向けに、「⁠-rootless」というサフィックスのついたタグも存在します。ただしRootless環境では、一部の機能が想定通りに動かない可能性もあるため注意してください。他にもベータ版である「beta」や、2系のナイトリー版である「nightly2」というタグも用意されています。詳しくはドキュメントを参照してください。

上記のcompose.yamlでは、ホストのDockerソケットをコンテナ内にマウントしています。これは同一ホスト上で稼動しているコンテナを監視するためです。もしこのホストのコンテナを監視する必要がないのでしたら、「⁠/var/run/docker.sock:/var/run/docker.sock」の行は削除して構いません。

compose.yamlが用意できたら、Kumaを起動しましょう。

$ sudo docker compose up -d

Kumaの初期設定

コンテナを起動したら、「⁠http://ホストのIPアドレス:3001」にブラウザからアクセスしてください。以下の初期設定画面が表示されます。まずは言語とデータベースを設定しましょう。

この記事を読んでいる方であれば、言語は「日本語」でよいでしょう。データベースは組込みのMariaDB、外部のMariaDB/MySQL、組込みのSQLite3の3つから選択できます。本記事では「Embedded MariaDB」を選択したことを前提に解説します。もちろん「MariaDB/MySQL」を選択し、別のデータベースサーバーに接続したり、従来通り組込みのSQLite3を使っても構いません。ちなみに前述の通り、Slim版のイメージにはMariaDBが組込まれていません。そのためSlim版を使っている場合は、選択肢は外部のMariaDB/MySQLかSQLite3の二択となります。

「次へ」をクリックすると、データベースの初期化が行われますので、しばらく待ちましょう。続いてAdminアカウントの作成画面に遷移します。

ユーザー名とパスワードを入力して「作成」をクリックしてください。以上でUptime Kumaのセットアップは完了です。非常にシンプルで簡単ですね

コンテナを監視する

それでは実際に監視を設定してみましょう。まずは例として、同一ホスト上で動作しているDockerコンテナを監視してみます。以下のコマンドを実行し、監視対象となるnginxのコンテナを起動しておきましょう。

$ sudo docker run -d --name nginx nginx

KumaでDockerコンテナを監視するには、まずDockerホストを登録します。画面右上のアイコンから「設定」をクリックして設定画面を出したら、「⁠Dockerホスト」をクリックしてください。

KumaにDockerホストを追加します。「⁠モニター表示名」には、そのDockerホストの名前を入力してください。Dockerホストは複数同時に監視できるため、わかりやすい名前をつけるとよいでしょう。今回はKumaコンテナにマウントしたソケットを使い、自分自身が動作しているDockerホストを監視します。そのため「接続タイプ」は「ソケット⁠」⁠、「⁠Dockerデーモン」はコンテナにマウントしたソケットのパス（今回の例では/var/run/docker.sock）を入力します。

「テスト」をクリックして、画面右下に「Connected Successfully」と表示されることを確認したら、「⁠保存」をクリックします。

続いてコンテナを監視対象に追加します。画面左上の「監視の追加」をクリックしてください。「⁠監視タイプ」は「Dockerコンテナー」とします。「⁠表示名」はコンテナを識別するための、わかりやすい名前をつけましょう。「⁠コンテナ名/ID」は、そのコンテナのIDもしくは名前です。先ほどdocker runを実行する際、「⁠--name」オプションで「nginx」という名前をつけたため、今回はこれを指定します。「⁠Dockerホスト」はそのコンテナが動作しているホストを選択します。プルダウンに先ほど追加したDockerホストがリストアップされていますので、それを選択してください。詳しい監視のパラメータはとりあえずデフォルトのままでよいため、ここで「保存」をクリックします。

これでコンテナの起動/停止を監視できるようになりました。メッセージに表示されているように、このコンテナはヘルスチェックを行っておらず、あくまでコンテナが起動していることを監視しているのみですが、それだけであれば非常に簡単なことが理解できるのではないでしょうか。

データベースを監視する

システムの監視には色々な方法があります。例えばPingに応答するか、特定のプロセスが起動しているか、特定のポートを待ち受けているか、などがよくあるパターンです。ですが実際の運用では、システムが確実に動作していることを保証するため、もう少し高レベルな監視をするのが一般的です。Webアプリであれば、APIを実際に叩いてレスポンスを見るなどが典型でしょう。

現在のアプリケーションのキモは、なんといってもデータベースです。そしてデータベースの監視でよくあるのが、実際にデータベースにログインし、監視用のクエリを実行して期待通りの応答が返るかを確認するものです。Kumaは、こうしたPostgreSQL/MySQLの監視にも対応しています。実際に設定してみましょう。今回はLAN内で動作している、別サーバーのMySQLを監視してみます[2]。

あらかじめMySQLに監視用ユーザーとデータベースを作成しておきます。以下のクエリを実行してください。ここでは「kuma」ユーザーを作成し、「⁠kuma」データベースへのアクセス権限を付与しています。データベース内には「kuma」テーブルを作成し、常に1が返るようレコードを追加しています。なおユーザーのパスワードは適宜変更してください。

CREATE DATABASE IF NOT EXISTS kuma CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
CREATE USER IF NOT EXISTS 'kuma'@'%' IDENTIFIED BY 'パスワード';
GRANT SELECT ON kuma.* TO 'kuma'@'%';
FLUSH PRIVILEGES;
USE kuma;
CREATE TABLE IF NOT EXISTS kuma (
    value TINYINT NOT NULL
);
INSERT INTO kuma (value) SELECT 1 WHERE NOT EXISTS (SELECT 1 FROM kuma);

以下のSELECT分を実行すると、見ての通り1が返ってきます。

SELECT value FROM kuma.kuma LIMIT 1;
+-------+
| value |
+-------+
|     1 |
+-------+

MySQL側の準備ができたので、Kumaに監視を追加します。「⁠監視の追加」をクリックしたら、今度は「監視タイプ」を「MySQL/MariaDB」とします。「⁠モニター表示名」は、例によってわかりやすい名前にしておきましょう。

「接続文字列」はデータベースに接続するための文字列で、以下の形式となっています。

mysql://ユーザー名@IPアドレス:ポート番号/データベース名

今回の例であれば、以下のようになります。IPアドレスだけはお使いの環境に合わせて変更してください。

mysql://kuma@IPアドレス:3306/kuma

「パスワード」には、MySQLのユーザー作成時に指定したパスワードを入力してください。「⁠クエリ」は、データベースに対してKumaが実行する具体的なクエリです。今回の例であれば、以下のクエリを設定してください。

SELECT value FROM kuma.kuma LIMIT 1;

最後に「条件を追加」をクリックします。するとクエリを実行した結果と比較する条件を設定できます。今回のクエリは常に1を返すことを想定していますので、「⁠result」「⁠一致」「⁠1」を入力します。つまりクエリを実行した結果が「1」であれば正常、もし値が返ってこなかったり、それ以外の値が返ってきたら異常とみなされるわけです。

最後に「保存」をクリックしてください。これで実際にクエリを実行するデータベース監視の完成です。

Nextcloud Talkを使って通知する

監視において大事なのは、アラートの通知です。通知設定がしっかりできていないと、サーバーのダウンは検出したのに、誰も気づかなかったというオチにもなりかねません。

Kumaは定番のメールやSlackをはじめ、非常に多彩な通知システムと連携できますが、その中にNextcloud Talkがあります。Nextcloudは本連載でも何度か紹介している、ファイル共有、コラボレーションツールです。セルフホストできるDropboxのようなものということで、個人やチームで導入している例も多いのではないでしょうか。筆者も個人的に長年運用しています。

Nextcloud Talkは、Nextcloudに追加できる会話モジュールです。今回はこのNextcloud Talkを使って、Kumaから通知を投げる設定を紹介します。セルフホストできるオープンソースソフトウェアですから、Slackなどが使えないチームにも便利でしょう。

Nextcloud本体とTalkアプリのインストールについては省略し、既にTalkが動作している前提で解説します。NextcloudサーバーにSSHでログインし、以下のコマンドを実行してUptime KumaのBotを追加してください。

$ sudo occ talk:bot:install --feature response --no-setup "Uptime Bot" "40文字〜128文字の任意の文字列" https://NextcloudのURL

以下のコマンドを実行して、BotのIDを確認します。以下の例では「1」です。

$ sudo occ talk:bot:list
+----+------------+-------------+-------------+-------+----------+
| id | name       | description | error_count | state | features |
+----+------------+-------------+-------------+-------+----------+
| 1  | Uptime Bot |             | 0           | 2     | response |
+----+------------+-------------+-------------+-------+----------+

Nextcloud Talk上に、通知用の会話を作成します。そしてメニューから「リンクをコピー」をクリックしてください。以下のようなURLが得られるはずです。

https://nc.example.com/index.php/call/XXXXXXX

このURLの末尾の「XXXX〜」が会話トークンになります。これを控えたら、以下のコマンドを実行してボットを会話に追加してください。

$ sudo occ talk:bot:setup BotのID 会話トークン

これでNextcloud Talk側の設定は完了です。Kuma側に通知設定を追加しましょう。既存の監視設定の「編集」を開き、右側にある「通知設定」をクリックします。

「通知タイプ」は「Nextcloud Talk」を選択します。「⁠モニター表示名」は任意の名前で構いません。「⁠Nextcloud Host」はNextcloudサーバーのURL、「⁠Conversation token」はボットを追加した会話のトークン、「⁠Bot Secret」はボット追加時に指定したシークレット文字列です。「⁠テスト」をクリックして、会話にテストメッセージが投稿されることを確認しておきましょう。最後に「保存」をクリックします。

最後に、監視項目に対して通知を有効化しましょう。監視設定の「編集」を開くと、作成した通知が右側にリストアップされます。各通知チャネルのスイッチをON/OFFすることで、障害発生時にそのチャネルへ通知を投げることができるわけです。作成したNextcloud Talkの通知を有効化しておきましょう。なおスイッチをONにしたら、忘れず「保存」ボタンを押しましょう。

試しに、MySQLサーバーをシャットダウン/再起動してみましょう。以下のようにNextcloud Talkに通知が送信されます。

今回はシンプルな監視ツールであるUptime Kumaの新バージョンを、あらためて紹介しました。バージョン2系ではKumaのよい所であるシンプルさはそのままに、監視対象や対応通知システムが強化され、より便利になっていることがわかります。またNextcloud Talkとの連携により、通知まで含めてセルフホストできるのも強みです。お手軽な監視ツールをお探しの方は、ぜひ試してみてください。