前回の記事に引き続き、今回も仮想通貨botの開発状況をまとめていきます。
本記事では「暗号通貨のパンプ＆ダンプスキームの検出」に関する論文をベースにbot開発の過程をまとめていきます。
Detecting Crypto Pump-and-Dump Schemes: A Thresholding-Based Approach to Handling Market Noisehttps://t.co/ctCJEV1MBs
— よだか(夜鷹/yodaka) (@yodakablog) March 22, 2025
🔍 デプロイ後の安定性確認 (サーバー監視とログの確認)
次のステップでは、システムの安定性を確保するために、以下のポイントに焦点を当てて確認します。
1. 確認の目的
✅ 長期運用中の安定性確認
✅ 異常やエラーの早期発見と対策
✅ リソース使用状況の監視
✅ Botのパフォーマンス記録
2. 確認チェックリスト
| チェック項目 | 内容 | コマンド / 手順 |
|---|---|---|
| Podの状態 | すべてのPodが正常稼働しているか | kubectl get pods |
| データ収集の安定性 | データ収集のエラーや欠損がないか | kubectl logs <data_collector_pod> |
| P&Dイベント検出精度 | 実際の市場データと比較して検出率を確認 | Grafanaのダッシュボード確認 |
| 取引成功率 | 取引成功率と利益率の確認 | Slack通知 / ログ確認 |
| APIエラーの発生率 | API接続や認証エラーの有無 | kubectl logs <trade_executor_pod> |
| CPU/メモリ使用率 | 使用状況が適正か (70%以下が目標) | kubectl top pods |
| Slack通知 | 通知の正常性を確認 | Slackチャネル確認 |
🔍 2. 確認チェックリストの解説
このセクションでは、デプロイ後のBotが正しく稼働しているかを確認するためのチェックポイントをまとめています。Bot運用においては、「動いているように見えて、実は止まっていた」「一部だけ異常が出ていた」といったことがよくあるため、定期的な状態チェックは不可欠です。
以下に、各チェック項目の目的と確認手順を簡単に説明します。
| チェック項目 | 解説 |
|---|---|
| Podの状態 | Kubernetes上のBotが正常に稼働しているかを確認します。kubectl get podsで、ステータスがRunningになっていればOKです。 |
| データ収集の安定性 | データが欠損なく取得できているか、ログから確認します。データ収集に失敗しているとBotの判断精度が低下します。 |
| P&Dイベント検出精度 | 検出されたPump＆Dumpイベントが実際の市場状況と合致しているか、Grafanaなどで視覚的に確認します。誤検出が多いと損失の原因になります。 |
| 取引成功率 | 実際に発注された取引の成功率と収益性をSlack通知やログから分析します。勝率やリスクリワードの傾向も把握できます。 |
| APIエラーの発生率 | API通信に問題が発生していないか、ログから確認します。特に「接続エラー」「認証失敗」が頻発していると、Botの停止に繋がります。 |
| CPU/メモリ使用率 | リソースの使いすぎによる過負荷を防ぐために、kubectl top podsで使用状況を確認します。目安は70%以下。 |
| Slack通知 | Botが異常を検知した際に、通知が正しくSlackに届いているかをチェックします。通知が届かないと、異常に気づけず対応が遅れるリスクがあります。 |
✅ このチェックリストは、日々の運用を安定させるための“お守り”のような存在です。
Botのパフォーマンスを最大限に引き出すためにも、手を抜かず、定期的に確認する習慣をつけましょう。
3. リアルタイム監視コマンド
✅ Podの状態確認
kubectl get pods
✅ ログのリアルタイム確認
kubectl logs -f <POD_NAME>
✅ CPU/メモリ使用状況の確認
kubectl top pods
📡 3. リアルタイム監視コマンドの解説
Botの本番運用中は、**「今この瞬間に何が起きているのか？」**を素早く把握できることが非常に重要です。
このセクションでは、Botの稼働状況をリアルタイムで確認するための基本コマンドを紹介しています。いずれもKubernetes環境でよく使われるシンプルかつ強力なツールです。
| コマンド | 解説 |
|---|---|
kubectl get pods | 現在稼働中のPodの一覧を表示します。ステータスがRunningであることを確認しましょう。異常がある場合はCrashLoopBackOffやErrorなどの表示になります。 |
kubectl logs -f <POD_NAME> | 特定のPodのログを**リアルタイムで追いかける（フォロー）**コマンドです。Botがどのような処理をしているか、エラーが発生していないかを逐次確認できます。 |
kubectl top pods | 各Podが使用しているCPU・メモリの使用率を確認できます。負荷が高すぎる場合（目安：70%以上）は、リソースの見直しやスケーリングが必要です。 |
✅ この3つのコマンドは、「Botの健康状態を診る体温計・血圧計・心電図」のようなもの。
運用が長時間にわたるほど、リアルタイム監視の重要性は増していきます。
4. エラー発生時の対応フロー
| エラータイプ | 原因 | 対応方法 |
|---|---|---|
| APIエラー | Bybit APIの通信失敗 | APIキーの確認 ➔ 再試行処理を確認 |
| データ欠損 | ネットワーク遅延や接続断 | kubectl restart <data_collector_pod> |
| CPU/メモリ過負荷 | Botの計算量が増加 | kubectl scale deployment crypto-bot --replicas=5 |
| Slack通知エラー | Slack API接続失敗 | Slack Webhook URLの確認 ➔ 再デプロイ |
🛠 4. エラー発生時の対応フロー 解説
Botの運用中には、エラーが発生することを前提に設計しておくことが非常に重要です。
このセクションでは、よくあるエラーのタイプと、その原因、対応手順を一覧化しています。
| エラータイプ | 解説 |
|---|---|
| APIエラー | Bybit APIとの通信がうまくいかない場合に発生します。認証情報のミスや一時的な接続障害が原因です。APIキーを再確認し、リトライ処理が正しく組み込まれているかもチェックしましょう。 |
| データ欠損 | ネットワークの一時切断や遅延によってデータ取得に失敗することがあります。この場合は、該当Podをkubectl restartなどで再起動して再接続を試みます。 |
| CPU/メモリ過負荷 | Botの処理が複雑化すると、使用するリソースが急増することがあります。Kubernetesのreplicasを増やしてPodを分散・スケールすることで負荷を分散させましょう。 |
| Slack通知エラー | 通知がSlackに届かない場合は、Webhook URLの設定ミスやSlack側の制限が考えられます。設定ファイルを再確認し、必要があればBotを再デプロイして再接続します。 |
✅ このように、Bot運用は“エラーとどう付き合うか”がカギ。
単に動くBotではなく、止まらずに自律的に復旧できるBotを目指すことで、より安定した長期運用が実現します。
5. 定期監視の自動化
✅ 監視スクリプト (monitor.py)
以下のスクリプトは、CPU/メモリ監視とエラー検出時のSlack通知を行います。
import subprocess
import requests
import time
from datetime import datetime
# Slack通知設定
SLACK_WEBHOOK_URL = "https://hooks.slack.com/services/YOUR_WEBHOOK_URL"
# Slack通知関数
def send_slack_alert(message):
payload = {"text": f"🚨 {message}"}
requests.post(SLACK_WEBHOOK_URL, json=payload)
# CPU/メモリ使用率監視
def check_resource_usage():
result = subprocess.getoutput("kubectl top pods")
for line in result.split('\n')[1:]:
data = line.split()
pod_name, cpu, mem = data[0], int(data[1].replace('m', '')), int(data[2].replace('Mi', ''))
if cpu > 700 or mem > 1000:
alert_msg = f"{pod_name} のリソース使用率が高すぎます (CPU: {cpu}m, メモリ: {mem}Mi)"
print(alert_msg)
send_slack_alert(alert_msg)
# メイン処理
def monitor_system():
while True:
check_resource_usage()
time.sleep(300) # 5分ごとに確認
if __name__ == "__main__":
monitor_system()
✅ スクリプトの実行
python monitor.py
🔄 定期監視の自動化とは？
Botの運用が安定していても、リソース（CPUやメモリ）の使用状況や急なエラーに気づくのが遅れると、大きな損失につながる可能性があります。
そこで、定期的にリソース状況をチェックし、異常があればSlackに通知する自動監視スクリプトを導入します。
この monitor.py スクリプトでは、以下の流れで処理を行います：
- kubectl top pods コマンドで、現在のPodごとのCPU・メモリ使用率を取得。
- あらかじめ設定したしきい値（例：CPUが700m超え、メモリが1000Mi超え）を超えた場合は、Slackにアラート通知を送信。
- この処理を 5分ごとに繰り返す無限ループにすることで、運用中のBotが高負荷に陥った際にすぐに対応できるようになります。
たとえば、注文処理が重くなってきたときや、データ取得処理が過剰になったときに即座にSlack通知で把握できるので、Botの継続運用を安心して任せられる土台が整います。
📌 Slack通知を活用した運用の可視化と、エラーの早期発見の第一歩として非常に効果的です。まだ導入していない方は、このステップだけでも取り入れると運用の安心感が一気に高まります。
6. データの記録と評価
| データ項目 | 記録方法 | 評価指標 |
|---|---|---|
| 取引結果 | Slack通知 + ログファイル | 取引成功率、利益率 |
| P&D検出結果 | Slack通知 + Grafanaダッシュボード | 検出成功率、誤検出数 |
| リソース使用率 | Prometheus/Grafana | CPU 70%以下、メモリ 70%以下 |
| エラー発生数 | kubectl logs + Slack通知 | APIエラー 5%以下 |
📊 データの記録と評価について
Botのパフォーマンスを安定的に保ち、次の改善へとつなげていくためには、運用中のデータを継続的に記録・評価しておくことが不可欠です。
このセクションでは、どのようなデータを、どんな手段で記録・評価しているかを一覧にしています：
| データ項目 | 記録方法 | 評価指標 |
|---|---|---|
| 取引結果 | Slack通知 + ログファイル | 成功率・利益率などの実績 |
| P&D検出結果 | Slack + Grafanaで可視化 | 正しく検出できているか、誤検出はないか |
| リソース使用率 | Prometheus/Grafana | CPUとメモリの使用率が適正（目安：70%以下）かどうか |
| エラー発生数 | kubectl logs + Slack通知 | APIエラーの頻度が高すぎないか（目標：5%以下） |
✅ ポイントは、Botの行動だけでなく「その環境や背景データ」も記録しておくこと。
これにより、異常が起きたときの原因特定がしやすくなり、定量的な評価を通じてBotの精度を向上させることができます。
7. 今後の対応計画
- ✅ システムの稼働状況確認 (ログ・リソース状況)
- ✅ APIエラーやBot停止などの問題がないか確認
- ✅ 取引の成功率や利益率を確認し、必要に応じた調整
- ✅ 1週間ごとの安定性チェックと最適化
8. 次のステップ
運用が安定した後の対応として、以下を検討するのが良いでしょう。
✅ 運用後の改善提案 (トレードロジックの強化や新機能の追加)
✅ セキュリティ強化 (データバックアップ、APIキーのローテーションなど)
✅ パフォーマンス改善 (アルゴリズムの最適化や計算の高速化)
次のステップとして、改善案に基づいたシステムの強化に取り組みます。
-
-
開発記録#157(2025/3/25)「論文ベースのbot開発フローpart.19 運用後の改善提案と最適化計画」
続きを見る
👇ラジオで話したこと
🎙️【開発記録#156｜デプロイ後の安定性確認とログ監視】
こんにちは、Yodakaです。
今回は、仮想通貨Botの開発ログシリーズ、**part.18「デプロイ後の安定性確認」**をお届けします。
ここまででBotの発注ロジックやSlack通知、常時監視ループなどを組み込んできましたが──
本番稼働が始まったら、次にやるべきことはひとつ。
そう、「きちんと動いているかを確認すること」です。
🔍 運用後のチェックって何を見ればいいの？
今回のテーマは、Botが実際に稼働し始めたあと、
それをどうやって“健やかに育てていくか”に焦点を当てています。
チェックポイントはこんな感じ：
- Botの各コンポーネントが正常に動いているか？
- APIとの通信がうまくいってるか？
- 取引の成功率や検出精度はどうか？
- CPUやメモリを使いすぎていないか？
- エラーや異常をSlack通知で受け取れているか？
一言でまとめるなら、
Botの“体調”を毎日ちゃんと診てあげるってことです。
🛠️ 実際の確認方法も紹介しておきます
Kubernetes上で動かしている場合、
以下のコマンドを日常的に叩くだけでだいぶ違います。
kubectl get pods # Podの生存確認 kubectl logs -f <POD_NAME> # ログをリアルタイム追跡 kubectl top pods # リソース使用率を確認
まるで、体温・脈拍・血圧を測るような感じですね。
特に「ログのリアルタイム確認」はおすすめです。
Botがいま何をしてるか、失敗してないかを即座に把握できます。
🧠 エラーが起きたらどうすれば？
Bot運用って、意外と“故障対応力”がものを言います。
今回まとめた対応フローの一部をご紹介すると──
- APIエラー → APIキーや通信再試行をチェック
- データ欠損 → Podを再起動（
kubectl restart） - リソース過負荷 →
replicasを増やしてスケーリング - Slack通知不達 → Webhook URLを再設定・再デプロイ
いずれも、Botが“止まらないように設計する”ための基本動作です。
🔄 そして、監視は自動化できる
Pythonで簡単なスクリプトを組んでおけば、
CPUやメモリが上限に近づいたときにSlackに通知を飛ばす──
そんな仕組みもすぐ作れます。
実際、私が使っているのは以下のようなコード：
if cpu > 700 or mem > 1000:
send_slack_alert("リソース使用率が高すぎます")
これを5分ごとに回すだけで、Botの健康状態をずっと見守れるようになります。
📊 最後に：Botの記録を“評価”につなげよう
運用データは宝です。
- 成功率、利益率
- 誤検出の数
- リソース使用履歴
- APIエラーの頻度
こうした数値をSlack通知やログ、Grafanaなどに記録しておくと、
後で振り返ったときに「何がよくて、何がダメだったか」が見えてきます。
📌 次の一歩
次回は、この記録と評価をもとにした改善提案と、
Botのセキュリティ強化・パフォーマンス最適化について話していく予定です。
APIキーのローテーション、ロジックの改良、計算の高速化──
どれもBotが「止まらずに勝ち続ける」ために必要なステップです。
というわけで、今回はデプロイ後の安定性確認についてお届けしました。
Botは動き出してからが本番。
だからこそ、「設計」だけでなく「運用の習慣」も武器にしていきましょう。
🎙️おまけコーナーその1「監視スクリプトとSlack通知で運用の安心感を高める」
今回はおまけトークとして、前回紹介した監視スクリプトにまつわる背景や狙い、そして“運用を可視化する”という視点についてお話しします。
Botを本番運用していると、一番怖いのは「気づかないうちに止まっていた」とか、「重たくなって処理が遅延していた」みたいな静かな障害です。
これを避けるために、私は monitor.py というスクリプトを用意して、CPUやメモリの使用率が高くなったらSlackに通知が届くようにしました。
5分おきに自動でPodのリソース使用率を取得し、しきい値（例：CPU 700m以上、メモリ 1000Mi以上）を超えていたらSlackにアラートを飛ばす。それだけの仕組みですが、心理的にめちゃくちゃ安心感が増します。
しかもSlackはスマホで通知も見られるので、家を空けていても「今Botがどういう状態か」が即わかる。
Botって黙って動くものだからこそ、「声を発する仕組み」を持たせることが、実運用においては本当に大事なんですよね。
🎙️おまけコーナーその2「ハッカー視点で見る監視スクリプトの改善点」
さて、ちょっと視点を変えて。
この monitor.py スクリプト、ちゃんと動くしSlackにも通知が飛ぶし、最低限の仕事はしてくれるんですが――
ハッカー視点で見ると、正直まだまだ改善の余地アリです。
たとえば…
✅ 改善ポイント
- 定数が直書き（700m, 1000Miなど）：
→config.tomlや.envに外出ししておけば柔軟性が増す。 - ログ出力がない：
→ 通知だけじゃなく、ローカルにファイル出力もしておけばあとで原因分析しやすい。 - Podリストのパースが脆弱：
→split()で行ごとに割ってるだけなので、列ズレや空行があると落ちる。
→ ここはkubectl get --output=jsonを使ってjson.loads()経由で安全に扱うのが理想。 - 例外処理がない：
→ Slack APIが落ちてるときにrequests.post()が失敗してクラッシュするリスクがある。try-except入れとこう。 - 非同期じゃない：
→ CPU・メモリ・Slack通知すべて同期的にやってるので、スケーラブルとは言いづらい。
→asyncio+aiohttpにすれば、通知の遅延やネットワークの詰まりにも強くなる。
💡リファクタリング例（構造だけ）
import asyncio
import aiohttp
import json
import subprocess
import time
from datetime import datetime
CONFIG = {
"cpu_threshold": 700,
"mem_threshold": 1000,
"slack_url": "https://hooks.slack.com/services/XXXX/YYYY/ZZZZ"
}
async def send_slack_alert(msg):
async with aiohttp.ClientSession() as session:
await session.post(CONFIG["slack_url"], json={"text": msg})
async def check_resource_usage():
result = subprocess.getoutput("kubectl top pods --no-headers")
for line in result.splitlines():
try:
pod, cpu, mem = line.split()[0], int(line.split()[1].replace("m", "")), int(line.split()[2].replace("Mi", ""))
if cpu > CONFIG["cpu_threshold"] or mem > CONFIG["mem_threshold"]:
await send_slack_alert(f"🚨 {pod}: CPU={cpu}m / Mem={mem}Mi 超過")
except Exception as e:
print(f"⚠️ パースエラー: {e}")
async def monitor():
while True:
await check_resource_usage()
await asyncio.sleep(300)
if __name__ == "__main__":
asyncio.run(monitor())
🎙️まとめ
ということで、今回のおまけでは「Slack通知による安心運用」と「ハッカー視点の改善点」についてお届けしました。
Botの運用って、“動かすこと”より“止めないこと”の方がずっと難しい。
だからこそ、通知、監視、そしてリスクを想定したコード設計を、早い段階で組み込んでおくことが大事です。
ではまた、次回の開発記録で。
Yodakaでした。