pm2の「online」を信じていいのか? VPS常駐サービスに『品質チェック』を自作した話

「pm2の『online』を信じていいのか?VPS常駐サービスに『品質チェック』を自作した話」のヘッダー

VPSでBotやアプリを常駐させるようになって気づいたことがあります。

pm2 listを見て「online」と表示されていても、それは「プロセスが落ちていない」ことしか教えてくれない、ということです。

今回は、その気づきをきっかけに、AIと一緒に監視の仕組みを自作してみた話をまとめます。


目次

1. 問題提起:「動いている」は「正常」とは限らない

VPS上でDiscord BotやAPI連携アプリをいくつか常駐させていると、ある日ふと不安になりました。

「これ、本当に全部ちゃんと動いてるんだっけ?」と。

pm2 listを打てば、プロセスの状態は一覧できます。でも表示されるonlineは、

あくまで「プロセスが起動していて落ちていない」という意味でしかありません。

また、一回一回VPSにログインして確認するのも手間になります。

中身の処理が実際に正しく動いているか、外部のAPIとちゃんと通信できているかまでは、これだけでは分からないのです。

用語補足:pm2とは

Node.jsアプリケーションを常駐させるためのプロセス管理ツール。プロセスが落ちたら自動で再起動してくれたり、複数のアプリをまとめて管理できたりする、VPS運用の定番ツールです。


2. なぜ「品質チェック」が必要なのか

自分ひとりで複数の常駐サービスを見ていると、どうしても目視の限界が来ます。

VPSにログインしてpm2 listを確認するのは、思い立った時にしかやりません。つまり、障害が起きてから気づくまでにタイムラグが生まれます。

サービスが増えるほど、この「気づくのが遅れるリスク」は大きくなります。

Discord Botが応答しなくなっていた、ブログが落ちていた。

そういったことに自分から気づくのではなく

異常の方から知らせてくれる仕組みが欲しいと思ったのが、今回のきっかけです。


3. 建築:AIと一緒にシステムを組んでVPSに反映するまで

今回はAI(Claude)に相談しながら、監視の仕組みを一緒に設計・実装してもらいました。

ゼロから自分でコードを書くのではなく、要件を会話で伝えて、コードを書いてもらい、それを自分のVPSに合わせて調整していく、という進め方です。

VPSでのアプリケーションデプロイ手順を示す6ステップのフロー図
VPSへのデプロイから手動確認、pm2登録、障害テストまでの全6ステップをまとめたフロー図です
Tomoya

全体の流れはこうなりました。

STEP
VPSの現状確認

Node.js・npm・pm2のバージョン、既にpm2で動いている既存プロセスの名前を洗い出す

STEP
コードをVPSへ転送

scpコマンドでファイル一式を送る

STEP
設定ファイルの調整

自分の環境(実際のプロセス名やURL)に合わせて設定を書き換える

STEP
まず手動で起動して確認

いきなり常駐化せず、ログを見ながら動作確認

STEP
pm2に登録

問題なければ常駐プロセスとして登録

STEP
わざと障害を起こしてテスト

本当に異常を検知して通知が飛ぶかを確認

用語補足:scpとは

SSH(暗号化された通信)を使って、手元のPCとサーバーの間でファイルをやり取りするコマンドです。「Secure Copy」の略。今回のようにローカルで作ったコードをVPSに送る時によく使います。

設計自体は「設定ファイルを1つ追加するだけで監視対象を増やせる」という方針にしました。

既存の資産(Discord Botやブログ)を壊さず、あとから対象を追加できる作りにしておくと、運用がずっと楽になります。


4. そこで起こった問題点:scpの落とし穴

一番つまずいたのは、実は設計や実装ではなく、ファイルをVPSに送る一番最初のステップでした。

最初、scpコマンドをVPSにログインした状態のターミナルで実行してしまい、うまくいきませんでした。

よく考えれば当たり前で、scpは「手元のPCから送る」コマンドなので、送りたいファイルがある場所(自分のPC)で実行しないといけません。ログイン後の画面で使おうとしていたのは、根本的な勘違いでした。

Tomoya

次にぶつかったのは、こんなエラーです。

port 22: Invalid argument
ssh接続時に「Invalid argument」と出力されscp接続が切断されたエラー画面
ターミナル上でSSH/SCP接続時に発生した「Invalid argument」エラーログです。

これは、ポート指定のオプションを-p(小文字)で書いていたのが原因でした。

SSHでは-pで合っているのですが、scpでは大文字の-Pを使います。

Tomoya

同じような見た目のコマンドなのに、オプションの大文字・小文字が違うという、地味に見落としやすい罠でした。

さらにその後は、こんなエラーにも遭遇しました。

Could not resolve hostname
Permission denied (publickey)

前者は、コマンド例の<IPアドレス>のようなプレースホルダー部分を、そのままコピペしてしまっていたのが原因でした。後者は、普段のSSHログインではエイリアス設定(~/.ssh/config)経由で鍵の場所が自動的に指定されているのに対し、IPアドレスを直接指定するとその設定が適用されず、鍵が見つからなくなっていた、という仕組みの違いに気づいていなかったことが原因でした。

用語補足:公開鍵認証

パスワードの代わりに、手元のPCに保存した「鍵」ファイルを使ってサーバーにログインする仕組み。安全性が高い一方、鍵の場所を正しく指定できていないと、今回のように弾かれてしまいます。

エラーメッセージを1つずつ読みながら、「今度は何が違うんだろう」と切り分けていく作業は、正直かなり地味でした。ただ、原因が分かるたびに「なるほど、そういうことか」と腑に落ちる感覚があり、地味ながらも一番学びが多かった工程だったと思います。


5. 確認:本当に動いているかを試す

コードをVPSに転送し、設定を調整したあとは、いきなり常駐化せずに手動で起動してログを確認しました。

エラーが出ていないこと、想定した監視対象がすべて表示されていることを目視でチェックしてから、pm2に登録します。

PM2のプロセス一覧画面でmonitor-engineなどのオンライン状態とリソース使用量を表示
PM2で管理されているアプリケーションプロセスの一覧と、システムリソースの使用状況です。
Tomoya

そして最後に、一番大事な確認をしました。

わざと監視対象のサービスを止めてみるというテストです。

止めてしばらく待つと、Discordに通知が届きました。

監視BotからのDockerコンテナ異常検知とHTTP 200による復旧通知画面
チャットツール上で監視Botがサービスの異常検知と、その後の正常復旧を通知している画面です。
Tomoya

この通知が来た瞬間、「あ、ちゃんと機能してる」と実感が持てました。

その後、サービスを元に戻すと、今度は復旧の通知も届き、一連の仕組みがきちんと動いていることを確認できました。

用語補足:Webhook(ウェブフック)

あるサービスで何かが起きた時に、別のサービスへ自動で通知を送る仕組み。今回はDiscordのWebhook機能を使い、異常を検知したら自動でメッセージが投稿されるようにしています。


6. まとめ

今回作ったのは、派手な機能ではなく、地味な「監視の目」です。

でも、この目視に頼らない仕組みを持てたことで、VPS上のサービスに対する安心感は大きく変わりました。

振り返ってみると、一番のつまずきポイントは設計でも実装でもなく、ファイル転送というごく基本的な部分でした。

AIと一緒に高度な仕組みを組めても、こういう地味な足元の部分でつまずくのが、非エンジニアが実際に手を動かした時のリアルなところだと思います。

この監視の仕組みは、今後も土台として少しずつ用途を広げていく予定です。まずは、VPS運用の安心感を底上げする一歩として、今回はここまでにしたいと思います。


この記事のQ&A

Q. pm2のonline表示だけでは何が分からないの?

A. プロセスが起動していることしか分かりません。中の処理が正しく動いているか、外部サービスとの通信が成功しているかは別の話です。

Q. scpとsshは何が違うの?

A. sshはサーバーに「ログインする」ためのコマンド、scpはサーバーとの間で「ファイルをやり取りする」ためのコマンドです。似ていますが役割が違います。

Q. なぜ通知先にDiscordを使ったの?

A. 元々Botの通知先として使っていて慣れていたのと、Webhookの設定が手軽だったためです。LINEやSlackなど、他の通知先に変えることも可能です。

VPSを使った24時間稼働システムを作成した記事はこちら

「pm2の『online』を信じていいのか?VPS常駐サービスに『品質チェック』を自作した話」のヘッダー

この記事が気に入ったら
フォローしてね!

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

始めまして。このブログを運営するTomoyaです。
未経験個人開発者。AI×個人開発(Vibe Cording)で学習して参入してくれる人が増えて広がっていくと良いなと思って始めました。

実際に作成→デプロイ(公開)→運営を行ってそれについての問題や疑問を記録していきます。
また行っていく上で内容(セキュリティ・制限など)にもこだわっていきたいなと思っています。

コメント

コメントする


目次