「サーバーのパフォーマンスが劣化していたのに気づかなかった」——本番障害の事後分析でよく聞くフレーズです。OpenClawを使えば、パフォーマンスメトリクスの収集から異常検知、Slack通知、定期レポート生成までを完全自動化できます。
OpenClawのcronジョブ・webhook連携・マルチチャネル通知機能を組み合わせることで、24時間365日のパフォーマンスモニタリングを人手をかけずに実現できます。この記事では、OpenClawシリーズ第45弾として、パフォーマンスモニタリングの自動化手法を実践的に解説します。
この記事を3秒でまとめると
- OpenClawのcronジョブでサーバー・API・データベースのメトリクスを定期自動収集
- 閾値ベースの異常検知とAI分析を組み合わせた高精度なアラート設定
- Slack・Discord・メールへの多段階通知と自動レポート生成で運用工数を大幅削減
なぜOpenClawでパフォーマンスモニタリングなのか
従来のモニタリングツールの課題
DatadogやNew Relicなどの既存モニタリングツールは強力ですが、SES現場では以下の課題があります。
| 課題 | 影響 |
|---|---|
| 高額なライセンス費用 | 月数十万円のコスト |
| 設定の複雑さ | 導入に数週間 |
| アラート疲れ | 重要でない通知が多すぎる |
| カスタマイズの限界 | 案件固有のメトリクスに対応しづらい |
OpenClawの優位性
1. コスト効率 OpenClawはOSSベースで動作するため、追加のモニタリングツール費用が不要です。既存のPrometheus・Grafana・CloudWatchと連携しながら、AIによるインテリジェントな分析を追加できます。
2. 自然言語でのルール設定 「CPU使用率が80%を超えたらSlackに通知して」のような自然言語でモニタリングルールを設定できます。
3. コンテキストを持った通知 単なるメトリクス値だけでなく、「なぜこの値が異常なのか」「どう対応すべきか」までAIが分析して通知します。
基本セットアップ
メトリクス収集スクリプトの設定
OpenClawのスキル機能を使って、メトリクス収集スクリプトを設定します。
// skills/performance-monitor/collect-metrics.mjs
import { exec } from 'child_process';
import { promisify } from 'util';
const execAsync = promisify(exec);
export async function collectServerMetrics() {
const metrics = {};
// CPU使用率
const { stdout: cpuOut } = await execAsync(
"top -l 1 -n 0 | grep 'CPU usage' | awk '{print $3}' | tr -d '%'"
);
metrics.cpu_usage = parseFloat(cpuOut.trim());
// メモリ使用率
const { stdout: memOut } = await execAsync(
"vm_stat | awk '/Pages active/ {print $3}' | tr -d '.'"
);
metrics.memory_active_pages = parseInt(memOut.trim());
// ディスク使用率
const { stdout: diskOut } = await execAsync(
"df -h / | tail -1 | awk '{print $5}' | tr -d '%'"
);
metrics.disk_usage = parseFloat(diskOut.trim());
// ロードアベレージ
const { stdout: loadOut } = await execAsync(
"sysctl -n vm.loadavg | awk '{print $2, $3, $4}'"
);
const [load1, load5, load15] = loadOut.trim().split(' ').map(Number);
metrics.load_avg = { '1m': load1, '5m': load5, '15m': load15 };
metrics.timestamp = new Date().toISOString();
return metrics;
}cronジョブの設定
OpenClawのcronジョブで定期的にメトリクスを収集します。
# openclaw.json のcron設定例
{
"cron": [
{
"name": "performance-metrics-5min",
"schedule": "*/5 * * * *",
"prompt": "サーバーメトリクスを収集し、memory/metrics/にタイムスタンプ付きで保存してください。前回の値と比較して異常がないか確認し、CPU>80%, メモリ>85%, ディスク>90%の場合はSlackに警告を送信してください。",
"channel": "slack"
},
{
"name": "api-health-check",
"schedule": "*/2 * * * *",
"prompt": "本番APIのヘルスチェックを実行してください。レスポンスタイム>500ms or ステータスコード!=200 の場合、即座にSlackで通知してください。",
"channel": "slack"
}
]
}cronジョブ設定ガイドで、スケジューリングの詳細を解説しています。
APIレスポンスタイムの監視
エンドポイント別の監視設定
# OpenClawへの指示
"以下のAPIエンドポイントのレスポンスタイムを5分ごとに計測してください:
- GET /api/v1/users (認証必要)
- GET /api/v1/products (公開)
- POST /api/v1/orders (認証必要)
各エンドポイントについて:
1. レスポンスタイム（ms）
2. ステータスコード
3. レスポンスボディサイズ（bytes）
を記録してください。
閾値:
- P50 > 200ms → 情報ログ
- P95 > 500ms → 警告通知
- P99 > 1000ms → 緊急通知
- エラー率 > 1% → 緊急通知"レスポンスタイム記録の実装
// skills/performance-monitor/api-check.mjs
async function checkEndpoint(url, options = {}) {
const start = performance.now();
try {
const response = await fetch(url, {
...options,
signal: AbortSignal.timeout(10000),
});
const elapsed = performance.now() - start;
const body = await response.text();
return {
url,
status: response.status,
responseTime: Math.round(elapsed),
bodySize: new TextEncoder().encode(body).length,
timestamp: new Date().toISOString(),
ok: response.ok,
};
} catch (error) {
const elapsed = performance.now() - start;
return {
url,
status: 0,
responseTime: Math.round(elapsed),
error: error.message,
timestamp: new Date().toISOString(),
ok: false,
};
}
}
データベースパフォーマンス監視
スロークエリの検出と分析
# OpenClawへの指示
"PostgreSQLのスロークエリログを分析してください。
以下の観点でレポートを作成:
1. 過去1時間で実行時間が100msを超えたクエリTOP10
2. 各クエリの実行計画（EXPLAIN ANALYZE）
3. インデックス追加で改善可能なクエリの特定
4. 改善のためのインデックスDDLを生成
結果はSlackの#dev-alertsチャネルに送信してください。"コネクションプール監視
# OpenClawへの指示
"データベースのコネクションプール状態を監視してください:
- 現在のアクティブ接続数
- アイドル接続数
- 接続待ちキューの長さ
- 接続のmean age
以下の場合にアラート:
- アクティブ接続がプールサイズの80%超過
- 接続待ちキュー > 0 が5分以上継続
- 接続のmean age > 30分（リーク疑い）"異常検知とアラートの設計
多段階アラートの設定
効果的なアラートは、重要度に応じた多段階通知が鍵です。
## アラートレベル設計
### Level 1: INFO（記録のみ）
- CPU使用率 60-80%
- メモリ使用率 60-85%
- レスポンスタイムP50 > 100ms
→ メトリクスログに記録、日次レポートに含める
### Level 2: WARNING（Slack通知）
- CPU使用率 80-90%
- メモリ使用率 85-95%
- レスポンスタイムP95 > 500ms
- エラー率 > 0.5%
→ Slack #monitoring チャネルに通知
### Level 3: CRITICAL（即座通知 + 自動対応）
- CPU使用率 > 90% が5分以上
- メモリ使用率 > 95%
- レスポンスタイムP99 > 2000ms
- エラー率 > 5%
- ヘルスチェック失敗3回連続
→ Slack DM + メール + 自動スケールアウト検討通知AIによるインテリジェント分析
OpenClawの強みは、単なる閾値ベースのアラートではなく、AI分析による文脈のある通知です。
# OpenClawへの指示
"メトリクス異常を検知した場合、以下の分析を自動実行してください:
1. 過去24時間のトレンドと比較して、異常の深刻度を判定
2. 同時に発生している他の異常との相関を分析
3. 過去に類似の異常が発生した際の原因と対応を検索
4. 推奨アクションを具体的に提示
通知フォーマット:
🚨 [レベル] メトリクス名
📊 現在値: xxx（通常: yyy、乖離: zzz%）
📈 トレンド: 過去1時間で○%上昇
🔗 関連異常: （あれば記載）
💡 推奨アクション: （具体的な手順）
📝 過去の類似事例: （あれば記載）"アラート設定ガイドで、通知設計の詳細を解説しています。
自動レポート生成
日次パフォーマンスレポート
OpenClawのcronジョブで日次レポートを自動生成し、Slackに送信します。
# cronジョブのprompt
"昨日のパフォーマンスメトリクスを集計し、日次レポートを作成してSlack #monitoring に送信してください。
レポート構成:
1. サマリー（3行以内）
- 全体的な健全性スコア（A/B/C/D/F）
- 主要な異常イベント数
- 前日比較
2. インフラメトリクス
- CPU使用率（平均/最大/P95）
- メモリ使用率（平均/最大）
- ディスク使用率と増加ペース
3. APIパフォーマンス
- レスポンスタイム（P50/P95/P99）
- エラー率
- リクエスト数
4. データベース
- スロークエリ数
- コネクション使用率
- 最も重いクエリTOP3
5. アクション必要項目
- 対応が必要な項目のリスト
- 優先度と担当者案"週次トレンドレポート
# 週次cronジョブ（毎週月曜9:00）
"過去7日間のパフォーマンストレンドを分析し、週次レポートを作成してください。
分析観点:
1. 曜日・時間帯別のトラフィックパターン
2. パフォーマンス劣化のトレンド（前週比）
3. リソース使用量の増加予測
4. キャパシティプランニングの提案
5. 来週のリスク予測
結果をSlack #team-report とメールで送信してください。"SES現場での実践パターン
パターン1: Webアプリケーションの監視
# OpenClawへの指示
"以下のWebアプリケーションの監視を設定してください:
- フロントエンド: Next.js（Vercel）
- バックエンド: Express.js（AWS ECS）
- データベース: PostgreSQL（RDS）
- キャッシュ: Redis（ElastiCache）
監視項目:
1. Core Web Vitals（LCP, FID, CLS）の定期チェック
2. APIレスポンスタイムとエラー率
3. DB接続数とスロークエリ
4. キャッシュヒット率
5. CDNのキャッシュ効率"パターン2: マイクロサービス環境の監視
# OpenClawへの指示
"Kubernetes上のマイクロサービス環境を監視してください:
- Pod のCPU/メモリ使用率
- Pod の再起動回数
- サービス間のレイテンシ
- Ingressのエラー率
- PersistentVolume の使用率
Prometheus メトリクスを取得し、Grafanaダッシュボードへのリンクと合わせて通知してください。"パターン3: バッチ処理の監視
# OpenClawへの指示
"日次バッチ処理のパフォーマンスを監視してください:
- 処理開始時刻と終了時刻
- 処理件数と所要時間
- エラー件数とエラー率
- リソース使用量のピーク値
バッチ処理が想定時間を超過した場合、または失敗した場合に即座に通知してください。
前回実行との比較データも含めてください。"ワークフロー自動化ガイドで、自動化の基本パターンを解説しています。
メトリクスの可視化
Slack上でのインライングラフ
OpenClawは、Slackメッセージ内にテキストベースのグラフを表示できます。
📊 API レスポンスタイム (過去24時間)
P50: ▇▇▇▇▇▇ 120ms
P95: ▇▇▇▇▇▇▇▇▇▇▇ 340ms
P99: ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 780ms
時間帯別分布:
00:00 ▇▇ 45ms
06:00 ▇▇▇ 65ms
09:00 ▇▇▇▇▇▇▇▇ 180ms ← ピーク
12:00 ▇▇▇▇▇▇ 130ms
18:00 ▇▇▇▇▇▇▇ 160ms
21:00 ▇▇▇ 70ms長期トレンドの保存
# OpenClawへの指示
"メトリクスデータをmemory/metrics/ディレクトリに以下の構成で保存してください:
- metrics-hourly-YYYY-MM-DD.json: 時間別集計
- metrics-daily-YYYY-MM.json: 日別集計
- metrics-summary-YYYY.json: 月別サマリー
3ヶ月以上前の時間別データは自動的にアーカイブ（日別に集約）してください。"トラブルシューティングの自動化
障害時の自動診断
# OpenClawへの指示
"アラートが発生した場合、以下の自動診断を実行してください:
1. 直近のデプロイ履歴を確認（デプロイ起因か判定）
2. 関連サービスのヘルスチェック
3. ログの異常パターン検索
4. リソース使用量の急変チェック
5. 外部サービス（AWS, GCP）のステータスページ確認
診断結果を構造化してSlackに投稿し、
推奨される対応アクションを優先度付きで提示してください。"ランブックの自動実行
よくある障害パターンには、自動対応（ランブック実行）を設定します。
## 自動対応ルール
### CPU高負荷 > 90%（5分以上継続）
1. プロセスのCPU使用率TOP5を特定
2. 直近のデプロイとの関連を確認
3. 自動対応: なし（通知のみ）
### メモリ使用率 > 95%
1. メモリ使用量TOP5プロセスを特定
2. キャッシュの肥大化を確認
3. 自動対応: キャッシュクリア実行（設定された場合）
### ディスク使用率 > 90%
1. 大きいファイルTOP10を特定
2. ログローテーション状態を確認
3. 自動対応: 古いログファイルの圧縮・アーカイブ
### APIエラー率 > 5%
1. エラーレスポンスのパターン分析
2. 直近のデプロイ・設定変更を確認
3. 外部依存サービスのステータス確認
4. 自動対応: なし（通知のみ、ロールバック判断は人間）インシデント対応ガイドで、障害対応の自動化を詳しく解説しています。
ベストプラクティス
1. アラート疲れを防ぐ
- 同一アラートの連続送信を抑制（スヌーズ機能）
- 相関のあるアラートをグループ化
- 営業時間外はCriticalのみ通知
- 週次でアラートルールを見直し
2. メトリクスの選定
重要なのは「測れるもの全て」ではなく「ビジネスインパクトに直結するもの」です。
必須メトリクス（RED Method）:
- Rate（リクエスト数）
- Errors（エラー数）
- Duration（レスポンスタイム）
追加メトリクス（USE Method）:
- Utilization（使用率）
- Saturation（飽和度）
- Errors（エラー数）
3. モニタリングの段階的導入
Phase 1（1週目）: ヘルスチェックとアップタイム監視 Phase 2（2週目）: レスポンスタイムとエラー率 Phase 3（3-4週目）: リソース使用率とキャパシティ Phase 4（5週目以降）: AI分析と自動対応
まとめ：OpenClawで24時間365日のモニタリングを実現
OpenClawを使ったパフォーマンスモニタリング自動化により、運用監視の工数を月40時間以上削減しながら、障害検知速度を大幅に向上できます。
導入ステップ:
- まずヘルスチェックとレスポンスタイム監視から開始
- 閾値ベースのアラートを設定し、通知チャネルを整備
- AI分析による異常検知で、アラートの精度を向上
- 日次・週次レポートの自動生成で報告工数を削減
- ランブックの整備で、障害対応の初動を自動化
**パフォーマンスモニタリングができるエンジニアの需要は高まり続けています。**OpenClawで自動化スキルを身につけ、SES市場での競争力を高めましょう。
SES BASEでは、DevOps・SRE領域のSES案件を多数掲載しています。案件を検索するからチェックしてみてください。
