nudgebee/nudgebee

Nudgebee – オープンソースのSREコ・ピロット

何ができるか

• Kubernetesクラスタと主要3大クラウド（AWS、Azure、GCP）を監視。
• ログ、メトリクス、トレース、クラウドプロバイダーのスキャンから、優先度付きの調査結果リストを生成。
• コスト最適化のシグナル（未使用のワークロード、過大なポッド、古くなったスナップショット、未使用のボリューム）を表示し、適切なサイズ調整の提案を行う。
• LLMを活用してインシデントを自動的にトリアージ：問題の再現、根本原因の特定、修復計画の生成。
• ChatOpsインターフェース（Slack / Teams）を提供。オペレーターは、状態の照会、ランブックの実行、アラートの確認、調査を、オンコール中のチャネルから一括で実行可能。
• ランブックエンジンを提供。繰り返し発生する修正手順をコード化し、チャット、アラート、スケジュールからトリガー可能。
• タイケットシステム（Jira、ServiceNow、PagerDuty、Zenduty）と同期し、Slack、Teams、メールで通知を送信。

構築方法

• バックエンド – テナント、統合、推奨ロジック、RPCゲートウェイを処理するGoサービス群（Gin HTTPフレームワーク）。
• LLMレイヤー – Goベースの llm-server と、RAGサーバー、コード分析ワーカー。セッション状態を保持し、Qdrantから関連するベクトルを取得し、オンデマンドでコード分析を実行。
• ランブック – Temporalワークフローでオーケストレーション。専用の runbook-server がTemporalと通信し、Postgresに状態を保存、RabbitMQで通信。
• データストア – Postgres（コア状態）、Redis（キャッシュ）、RabbitMQ（イベントバス）、Qdrant（RAG用ベクトルストア）、Temporal（ワークフロー・エンジン）。
• コレクタ – Kubernetesクラスタ内に実行されるエージェントと、AWS/Azure/GCP APIをスキャンするクラウドコレクタジョブ。メトリクス、イベント、コストデータを中央バスに送信。
• フロントエンド – GraphQL/RPC経由でバックエンドと通信するNext.js（TypeScript）ダッシュボード（app/）。NextAuthによる認証を処理し、チャットアシスタントUIをホスト。
• デプロイ – Helmチャート（OCIホスティング）として提供。すべての必要インフラをサブチャートとしてバンドル。ローカル開発用にDocker-Compose設定も提供。

開始手順（ローカル開発）

1. Docker（またはPodman）とcompose、Go 1.26+、Node 25+ をインストール。
2. docker compose up -d でPostgres、Redis、RabbitMQ、Qdrant、Temporal、マイグレーションコンテナを起動。
3. バックエンド（api-server/services/.env）とフロントエンド（app/.env）用の例の .env ファイルをコピー。openssl rand -hex 32 で32バイトの暗号鍵を生成し、両方のファイルに同じ鍵を配置。
4. Goバックエンドを実行（make run または go run ./cmd）— http://localhost:8000 でリッスン。
5. フロントエンドの依存関係をインストール（npm install --legacy-peer-deps）し、開発サーバーを起動（npm run dev）。UIは http://localhost:3000 でアクセス可能。
6. 任意のメールアドレスでログインし、ダミーパスワード Test!24#5（開発用認証プロバイダー提供）を使用。

本番環境デプロイ

• oci://ghcr.io/nudgebee/charts/nudgebee からHelmチャートをインストール。
• OpenSSLで一度生成した永続的な NUDGEBEE_ENCRYPTION_KEY を、チャートの nudgebee_secret 値として提供。
• チャートはcomposeスタックと同じインフラコンポーネントをプロビジョニングし、データベースマイグレーションを実行するポストインストールフックを実行。
• ポッドが準備できたら、appサービスのポートフォワードを行い、シークレットから生成された管理者パスワードでログイン。

一般的なワークフロー

1. クラスタまたはクラウドアカウントを接続 → コレクタがリソース、メトリクス、支出の知識グラフを構築。
2. ダッシュボードを確認 – 調査結果は優先度順に並べ替えられ、コスト最適化の推奨が表示される。
3. AIアシスタント（右下のチャット）に「なぜポッド frontend-abc が2CPUを使用しているのですか？」などと質問。LLMは取得したコンテキストを使って説明し、適切なサイズ調整を提案する可能性がある。
4. ランブックを実行 – Runbooks → Library ページから手動で実行するか、ChatOpsコマンドで自動実行。ランブックはTemporalワークフローとして実行され、リレーサーバー経由でクラスタと対話。
5. ループを閉じる – Slack/Teamsに通知、JiraやServiceNowでチケットを作成・更新、インシデントを解決済みとしてマーク。

誰が使うか

• オブザーバビリティ、コスト管理、インシデント対応のための単一のダッシュボードが必要なSRE。
• マルチクラウドワークロードを管理し、AI支援によるトリアージを希望するクラウドネイティブチーム。
• 商業SRE「コ・ピロット」プラットフォームの自己ホスト型代替を求める組織。

ヘルプや貢献の場所

• Discord: https://discord.gg/C5d27ceTEv
• Issues: 提供されたバグ報告および機能リクエストテンプレートを使用。
• 新規参加者向けに good-first-issue ラベルを付与。
• CLA、ブランチモデル、PRガイドラインについては CONTRIBUTING.md を参照。

---

上記のすべての詳細は、リポジトリのREADMEから直接取得。追加機能は推測されていません。