Skill: cafechen/devops-insight (version 1.0.2)

--- name: devops-insight description: This skill should be used when the user asks to "analyze incidents", "troubleshoot production issues", "investigate alerts", "create tickets", "root cause analysis", "check monitoring", or discusses DevOps/SRE automation, incident management, or observability integration. --- # DevOps Insight - Intelligent DevOps Incident Management DevOps Insight is an intelligent DevOps incident management system that integrates multiple monitoring systems, GitHub, and ticket databases to enable automated fault analysis, root cause identification, and issue resolution. ## System Architecture ### Core Components 1. **Monitoring Data Source Integration** (via MCP) - Kubernetes: Cluster status, Pod logs, events - PostgreSQL: Database performance metrics - Redis: Cache status and performance - Neo4j: Graph database monitoring - Elasticsearch: Log platform - Metrics: General metrics collection - APM (Skywalking): Application performance monitoring 2. **Code Management** - GitHub integration (via gitnexus Nexus-skill) - Code review and commits - Automated fix commits 3. **EvoMap Integration** - Capsule creation and publishing - Gene + Capsule bundle publishing - Automated quality validation - Network reputation tracking 4. **AI Agent** - Problem clue identification via LLM - Root cause analysis - Code review and fix suggestions - Index construction decisions ## Workflow ### 1. Monitoring Data Collection When receiving an alert or analyzing an issue: ```bash # Retrieve Kubernetes monitoring data via MCP # Assumes MCP server connections to each monitoring system are configured ``` **Steps:** - Retrieve Pod status, logs, and events from Kubernetes - Retrieve application performance traces from APM (Skywalking) - Retrieve relevant logs from Elasticsearch - Retrieve performance metrics from the Metrics system - Retrieve status information from databases (PostgreSQL/Redis/Neo4j) ### 2. Intelligent Analysis and Root Cause Identification Perform multi-dimensional analysis using Claude: **Analysis Dimensions:** 1. **Problem Clue Identification** - Analyze alert information and monitoring data - Identify anomalous patterns and trends - Correlate with historical events 2. **Root Cause Analysis** - Code level: Recent code changes - Configuration level: Configuration changes and environment differences - Infrastructure level: Resource usage and network issues - Dependency level: Third-party services and databases 3. **Impact Assessment** - Affected services and users - Business impact severity - Urgency determination ### 3. Capsule Publishing **Capsule Creation Workflow:** ```typescript // Capsule data structure example interface Capsule { asset_type: 'Capsule'; asset_id: string; // sha256 hash title: string; body: string; signals: string[]; confidence: number; // 0.0 to 1.0 blast_radius: number; solution: { type: 'code_change' | 'config_change' | 'investigation'; files: Array<{ path: string; diff?: string; content?: string; }>; description: string; }; context: { monitoring_data?: any; root_cause?: string; affected_services?: string[]; }; metadata: { created_at: string; model_name?: string; }; } // Gene data structure example interface Gene { asset_type: 'Gene'; asset_id: string; // sha256 hash title: string; body: string; signals: string[]; category: 'repair' | 'optimize' | 'innovate' | 'regulatory'; strategy: string; confidence: number; metadata: { created_at: string; model_name?: string; }; } ``` **Publishing Operations:** - Automatic Gene + Capsule bundle creation (based on analysis results) - SHA-256 hash computation for asset verification - Quality validation (confidence >= 0.8 recommended) - Network reputation tracking - Automatic promotion when quality thresholds are met ### 4. Code Review and Fixes **GitHub Integration:** 1. **Code Review** - Review recent commits - Identify code changes that may have caused issues - Provide fix suggestions 2. **Automated Fixes** - Generate fix code - Create fix branch - Submit Pull Request - Update ticket status 3. **Index Construction Decisions** - Determine if additional monitoring metrics are needed - Determine if alert rules need modification - Update APM tracing configuration ### 5. Audit and Production Changes **Important Reminder:** - ⚠️ Audit and production changes - This step carries risk - All changes require approval process - Record all operation logs - Support rollback mechanism ## Use Cases ### Scenario 1: Production Environment Alert Response ``` User: "Production API response time suddenly increased, help me analyze" DevOps Insight Workflow: 1. Retrieve API response time trends from APM 2. Check Pod status and resource usage from Kubernetes 3. Query related error logs from Elasticsearch 4. Check query performance from database monitoring 4. Analyze root cause (e.g., slow database queries, memory leaks, traffic spikes) 5. Publish Gene + Capsule bundle to EvoMap network 6. If it's a code issue, review recent commits and provide fix suggestions 7. Update monitoring index, add relevant metrics ``` ### Scenario 2: Fault Root Cause Analysis ``` User: "Help me analyze last night's service outage" DevOps Insight Workflow: 1. Query related Capsules from EvoMap network 2. Retrieve all monitoring data for the event time period 3. Analyze timeline: - Code deployment time - Configuration change time - Resource usage changes - Error log appearance time 4. Identify root cause 5. Generate detailed post-incident analysis report 6. Provide preventive measure recommendations ``` ### Scenario 3: Proactive Issue Discovery ``` User: "Check if there are any potential system issues" DevOps Insight Workflow: 1. Scan all monitoring metrics 2. Identify anomalous trends (e.g., continuous memory growth, rising error rates) 3. Check resource usage 4. Analyze warning messages in logs 5. Generate health report 6. Publish warning Capsules for potential issues to EvoMap network ``` ### Scenario 4: Code Change Impact Analysis ``` User: "Will this PR affect the production environment?" DevOps Insight Workflow: 1. Analyze code change content 2. Identify affected services and components 3. Check related monitoring metrics 4. Query historical impact of similar changes 5. Assess risk level 6. Provide monitoring recommendations (which metrics to watch) 7. Suggest if new monitoring points are needed ``` ## Configuration Requirements ### MCP Server Configuration The following MCP servers need to be configured to connect to each monitoring system: ```json { "mcpServers": { "kubernetes": { "command": "mcp-server-kubernetes", "args": ["--kubeconfig", "/path/to/kubeconfig"] }, "postgresql": { "command": "mcp-server-postgresql", "args": ["--connection-string", "postgresql://..."] }, "redis": { "command": "mcp-server-redis", "args": ["--host", "redis.example.com"] }, "elasticsearch": { "command": "mcp-server-elasticsearch", "args": ["--url", "https://es.example.com"] }, "skywalking": { "command": "mcp-server-skywalking", "args": ["--url", "http://skywalking.example.com"] } } } ``` ### GitHub Integration Ensure gitnexus Nexus-skill is installed and configured: ```bash # Check if gitnexus is available gh --version # Configure GitHub authentication gh auth login ``` ### EvoMap API Configuration Configure EvoMap API connection for publishing Capsules: ```json { "evomap": { "apiUrl": "https://evomap.ai/a2a", "nodeId": "node_your_unique_id", "enableHeartbeat": true, "heartbeatInterval": 900000, "autoPublish": true, "minConfidence": 0.8 } } ``` **Configuration Options:** - `apiUrl`: EvoMap A2A protocol endpoint - `nodeId`: Your agent's unique node identifier (obtained from registration) - `enableHeartbeat`: Enable automatic heartbeat to stay online (recommended) - `heartbeatInterval`: Heartbeat interval in milliseconds (default: 15 minutes) - `autoPublish`: Automatically publish high-confidence solutions as Capsules - `minConfidence`: Minimum confidence threshold for auto-publishing (0.0-1.0) ## Best Practices ### 1. Monitoring Data Collection - Prioritize retrieving the most relevant monitoring data - Set reasonable time ranges (avoid data overload) - Use filter conditions for precise queries ### 2. Root Cause Analysis - Adopt multi-dimensional analysis methods - Correlate historical data and patterns - Consider time factors (change time, alert time) - Validate hypotheses (verify with additional data) ### 3. Capsule Publishing - Publish high-quality solutions promptly - Document analysis process and conclusions in detail - Associate all relevant monitoring data and code - Maintain confidence >= 0.8 for auto-publishing - Use appropriate signals for better discoverability ### 4. Code Changes - Exercise caution with production environment changes - Thoroughly test fix solutions - Maintain small, incremental changes - Prepare for rollback ### 5. Security Considerations - Audit all production change operations - Follow principle of least privilege - Sanitize sensitive information - Maintain complete operation logs ## Command Examples ### Analyze Current Alerts ``` Analyze current production alerts ``` ### Create Incident Ticket ``` Create a ticket for this API timeout issue ``` ### Code Impact Analysis ``` Analyze the impact of PR #123 on production environment ``` ### Health Check ``` Check system health status ``` ### Root Cause Analysis ``` Analyze the root cause of yesterday's 20:00 service outage ``` ## Important Notes 1. **Permission Management** - Ensure sufficient permissions to access monitoring systems - GitHub operations require appropriate repository permissions - EvoMap API requires valid node registration 2. **Data Security** - Do not expose sensitive information (passwords, keys, etc.) in tickets - Log data may contain user information, ensure sanitization - Comply with data protection regulations 3. **Change Risks** - Exercise extra caution with production environment changes - Recommend testing in test environment first - Maintain change traceability 4. **Performance Considerations** - Large monitoring data queries may be slow - Set reasonable query ranges and limits - Consider using caching mechanisms ## Extended Features ### Future Plans - [ ] Automated fix execution (requires stricter security controls) - [ ] Machine learning predictions (predict failures based on historical data) - [ ] Multi-cluster support - [ ] Custom alert rules - [ ] Integration with more monitoring systems - [ ] Mobile alert notifications - [ ] Collaboration features (team collaboration for incident handling) ## Troubleshooting ### Common Issues **Q: MCP server connection failure** ``` A: Check MCP server configuration and network connection Verify authentication information is correct Review MCP server logs ``` **Q: GitHub operation failure** ``` A: Confirm gh CLI is properly configured Check repository permissions Verify gitnexus skill is available ``` **Q: Capsule publishing failure** ``` A: Check EvoMap API connection and node registration Verify confidence score meets minimum threshold Ensure asset_id hash is computed correctly Review EvoMap API response for error details ``` **Q: Incomplete monitoring data** ``` A: Check time range settings Verify monitoring system is running normally Confirm query conditions are not too restrictive ``` ## Related Resources - [MCP Protocol Documentation](https://modelcontextprotocol.io/) - [GitHub CLI Documentation](https://cli.github.com/) - [Kubernetes Monitoring Best Practices](https://kubernetes.io/docs/tasks/debug/) - [SkyWalking Documentation](https://skywalking.apache.org/) - [Elasticsearch Query Guide](https://www.elastic.co/guide/) - [EvoMap A2A Protocol](https://evomap.ai/wiki/05-a2a-protocol) - [EvoMap Agent Guide](https://evomap.ai/wiki/03-for-ai-agents) ## Contributing Issues and improvement suggestions are welcome! ## License MIT License

path: config.example.json
content: {
  "devops-insight": {
    "mcpServers": {
      "kubernetes": {
        "command": "mcp-server-kubernetes",
        "args": ["--kubeconfig", "${HOME}/.kube/config"],
        "env": {
          "KUBECONFIG": "${HOME}/.kube/config"
        }
      },
      "postgresql": {
        "command": "mcp-server-postgresql",
        "args": [
          "--connection-string",
          "postgresql://user:password@localhost:5432/monitoring"
        ]
      },
      "redis": {
        "command": "mcp-server-redis",
        "args": [
          "--host", "localhost",
          "--port", "6379"
        ]
      },
      "neo4j": {
        "command": "mcp-server-neo4j",
        "args": [
          "--uri", "bolt://localhost:7687",
          "--user", "neo4j",
          "--password", "password"
        ]
      },
      "elasticsearch": {
        "command": "mcp-server-elasticsearch",
        "args": [
          "--url", "http://localhost:9200"
        ]
      },
      "skywalking": {
        "command": "mcp-server-skywalking",
        "args": [
          "--url", "http://localhost:8080"
        ]
      }
    },
    "evomap": {
      "apiUrl": "https://evomap.ai/a2a",
      "nodeId": "node_your_unique_id",
      "enableHeartbeat": true,
      "heartbeatInterval": 900000,
      "autoPublish": true,
      "minConfidence": 0.8
    },
    "github": {
      "defaultOrg": "your-org",
      "defaultRepo": "your-repo",
      "autoCreateBranch": true,
      "branchPrefix": "fix/devops-insight-"
    },
    "analysis": {
      "timeRangeDefault": "1h",
      "maxLogLines": 1000,
      "enableAutoFix": false,
      "requireApproval": true
    },
    "alerts": {
      "severityThresholds": {
        "critical": {
          "errorRate": 0.05,
          "responseTime": 5000,
          "cpuUsage": 0.9,
          "memoryUsage": 0.9
        },
        "high": {
          "errorRate": 0.02,
          "responseTime": 3000,
          "cpuUsage": 0.8,
          "memoryUsage": 0.8
        },
        "medium": {
          "errorRate": 0.01,
          "responseTime": 2000,
          "cpuUsage": 0.7,
          "memoryUsage": 0.7
        }
      }
    }
  }
}


path: README.md
content: # DevOps Insight Skill

Intelligent DevOps incident management system integrating monitoring, GitHub, and ticket management.

## Quick Start

### 1. Configure MCP Servers

Copy configuration example:

```bash
cp config.example.json config.json
```

Edit `config.json` to configure your monitoring system connection information.

### 2. Configure GitHub

Ensure GitHub CLI is installed:

```bash
gh auth login
```

### 3. Configure Ticket Database

Create database schema:

```sql
CREATE TABLE tickets (
  id SERIAL PRIMARY KEY,
  title VARCHAR(255) NOT NULL,
  description TEXT,
  severity VARCHAR(20) NOT NULL,
  status VARCHAR(20) NOT NULL,
  root_cause TEXT,
  affected_services TEXT[],
  monitoring_data JSONB,
  related_commits TEXT[],
  assignee VARCHAR(100),
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX idx_tickets_status ON tickets(status);
CREATE INDEX idx_tickets_severity ON tickets(severity);
CREATE INDEX idx_tickets_created_at ON tickets(created_at);
```

## Usage Examples

### Analyze Production Alerts

```
Analyze current API response time alerts
```

### Create Ticket

```
Create a ticket for this database connection timeout issue
```

### Code Impact Analysis

```
Analyze the potential impact of PR #456 on production
```

### Health Check

```
Check overall system health status
```

## Architecture

```
┌─────────────────────────────────────────┐
│  Kubernetes, PostgreSQL, Redis, Neo4j   │
│  Elasticsearch, Metrics, Skywalking     │
└────────────────┬────────────────────────┘
                 │ MCP Protocol
                 ▼
┌─────────────────────────────────────────┐
│           DevOps Insight Agent                  │
│  ┌─────────────────────────────────┐   │
│  │  Monitoring Data Collection      │   │
│  └─────────────────────────────────┘   │
│  ┌─────────────────────────────────┐   │
│  │  AI-Powered Root Cause Analysis  │   │
│  └─────────────────────────────────┘   │
│  ┌─────────────────────────────────┐   │
│  │  Ticket Management               │   │
│  └─────────────────────────────────┘   │
│  ┌─────────────────────────────────┐   │
│  │  Code Review & Auto-Fix          │   │
│  └─────────────────────────────────┘   │
└────────────────┬────────────────────────┘
                 │
    ┌────────────┼────────────┐
    ▼            ▼            ▼
┌────────┐  ┌────────┐  ┌──────────┐
│ GitHub │  │ Ticket │  │ Claude   │
│        │  │   DB   │  │ Analysis │
└────────┘  └────────┘  └──────────┘
```

## Workflow

1. **Monitoring Data Collection**: Fetch data from monitoring systems via MCP
2. **Intelligent Analysis**: Use Claude for root cause analysis and issue diagnosis
3. **Ticket Management**: Automatically create, update, and correlate tickets
4. **Code Review**: Analyze related code changes, provide fix suggestions
5. **Auto-Fix**: (Optional) Automatically generate fix code and submit PR

## Configuration Options

See [config.example.json](config.example.json)

Main configuration items:

- `mcpServers`: MCP server configuration
- `ticketDatabase`: Ticket database configuration
- `github`: GitHub integration configuration
- `analysis`: Analysis behavior configuration
- `alerts`: Alert threshold configuration

## Security Considerations

1. Do not commit `config.json` containing sensitive information to version control
2. Use environment variables to store passwords and keys
3. Limit database and API access permissions
4. Enable audit logging for all operations
5. Production environment changes require manual approval

## Troubleshooting

### MCP Connection Issues

```bash
# Test MCP server connection
mcp-client test --server kubernetes
```

### Database Connection Issues

```bash
# Test database connection
psql -h localhost -U tickets_user -d tickets -c "SELECT 1"
```

### GitHub Authentication Issues

```bash
# Check GitHub authentication status
gh auth status
```

## Contributing

Issues and Pull Requests are welcome!

## License

MIT License


path: README.zh.md
content: # DevOps Insight Skill

Intelligent DevOps incident management system integrating monitoring, GitHub, and ticket management.

## Quick Start

### 1. Configure MCP Servers

Copy configuration example:

```bash
cp config.example.json config.json
```

Edit `config.json` to configure your monitoring system connection information.

### 2. Configure GitHub

Ensure GitHub CLI is installed:

```bash
gh auth login
```

### 3. Configure Ticket Database

Create database schema:

```sql
CREATE TABLE tickets (
  id SERIAL PRIMARY KEY,
  title VARCHAR(255) NOT NULL,
  description TEXT,
  severity VARCHAR(20) NOT NULL,
  status VARCHAR(20) NOT NULL,
  root_cause TEXT,
  affected_services TEXT[],
  monitoring_data JSONB,
  related_commits TEXT[],
  assignee VARCHAR(100),
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX idx_tickets_status ON tickets(status);
CREATE INDEX idx_tickets_severity ON tickets(severity);
CREATE INDEX idx_tickets_created_at ON tickets(created_at);
```

## Usage Examples

### Analyze Production Alerts

```
Analyze current API response time alerts
```

### Create Ticket

```
Create a ticket for this database connection timeout issue
```

### Code Impact Analysis

```
Analyze the potential impact of PR #456 on production
```

### Health Check

```
Check overall system health status
```

## Architecture

```
┌─────────────────────────────────────────┐
│  Kubernetes, PostgreSQL, Redis, Neo4j   │
│  Elasticsearch, Metrics, Skywalking     │
└────────────────┬────────────────────────┘
                 │ MCP Protocol
                 ▼
┌─────────────────────────────────────────┐
│           DevOps Insight Agent                  │
│  ┌─────────────────────────────────┐   │
│  │  Monitoring Data Collection      │   │
│  └─────────────────────────────────┘   │
│  ┌─────────────────────────────────┐   │
│  │  AI-Powered Root Cause Analysis  │   │
│  └─────────────────────────────────┘   │
│  ┌─────────────────────────────────┐   │
│  │  Ticket Management               │   │
│  └─────────────────────────────────┘   │
│  ┌─────────────────────────────────┐   │
│  │  Code Review & Auto-Fix          │   │
│  └─────────────────────────────────┘   │
└────────────────┬────────────────────────┘
                 │
    ┌────────────┼────────────┐
    ▼            ▼            ▼
┌────────┐  ┌────────┐  ┌──────────┐
│ GitHub │  │ Ticket │  │ Claude   │
│        │  │   DB   │  │ Analysis │
└────────┘  └────────┘  └──────────┘
```

## Workflow

1. **Monitoring Data Collection**: Fetch data from monitoring systems via MCP
2. **Intelligent Analysis**: Use Claude for root cause analysis and issue diagnosis
3. **Ticket Management**: Automatically create, update, and correlate tickets
4. **Code Review**: Analyze related code changes, provide fix suggestions
5. **Auto-Fix**: (Optional) Automatically generate fix code and submit PR

## Configuration Options

See [config.example.json](config.example.json)

Main configuration items:

- `mcpServers`: MCP server configuration
- `ticketDatabase`: Ticket database configuration
- `github`: GitHub integration configuration
- `analysis`: Analysis behavior configuration
- `alerts`: Alert threshold configuration

## Security Considerations

1. Do not commit `config.json` containing sensitive information to version control
2. Use environment variables to store passwords and keys
3. Limit database and API access permissions
4. Enable audit logging for all operations
5. Production environment changes require manual approval

## Troubleshooting

### MCP Connection Issues

```bash
# Test MCP server connection
mcp-client test --server kubernetes
```

### Database Connection Issues

```bash
# Test database connection
psql -h localhost -U tickets_user -d tickets -c "SELECT 1"
```

### GitHub Authentication Issues

```bash
# Check GitHub authentication status
gh auth status
```

## Contributing

Issues and Pull Requests are welcome!

## License

MIT License


path: scripts/health-check.sh
content: #!/bin/bash

# DevOps Insight MCP Server Health Check Script

set -e

# Color definitions
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m' # No Color

echo "DevOps Insight MCP Server Health Check"
echo "================================"

# Check function
check_service() {
    local service_name=$1
    local check_command=$2

    echo -n "Checking $service_name... "
    if eval "$check_command" &> /dev/null; then
        echo -e "${GREEN}✓ OK${NC}"
        return 0
    else
        echo -e "${RED}✗ Failed${NC}"
        return 1
    fi
}

# Check Kubernetes
check_service "Kubernetes" "kubectl cluster-info"

# Check PostgreSQL
check_service "PostgreSQL" "pg_isready -h localhost -p 5432"

# Check Redis
check_service "Redis" "redis-cli ping"

# Check Elasticsearch
check_service "Elasticsearch" "curl -s http://localhost:9200/_cluster/health"

# Check Neo4j
check_service "Neo4j" "curl -s http://localhost:7474"

# Check GitHub CLI
check_service "GitHub CLI" "gh auth status"

echo ""
echo "================================"
echo "Health check complete"


path: scripts/init-database.sh
content: #!/bin/bash

# DevOps Insight Database Initialization Script

set -e

# Configuration
DB_HOST="${DB_HOST:-localhost}"
DB_PORT="${DB_PORT:-5432}"
DB_NAME="${DB_NAME:-tickets}"
DB_USER="${DB_USER:-tickets_user}"
DB_PASSWORD="${DB_PASSWORD:-tickets_password}"

echo "Initializing DevOps Insight ticket database..."

# Create database (if not exists)
PGPASSWORD="$DB_PASSWORD" psql -h "$DB_HOST" -p "$DB_PORT" -U "$DB_USER" -tc "SELECT 1 FROM pg_database WHERE datname = '$DB_NAME'" | grep -q 1 || \
PGPASSWORD="$DB_PASSWORD" psql -h "$DB_HOST" -p "$DB_PORT" -U "$DB_USER" -c "CREATE DATABASE $DB_NAME"

# Create table structure
PGPASSWORD="$DB_PASSWORD" psql -h "$DB_HOST" -p "$DB_PORT" -U "$DB_USER" -d "$DB_NAME" <<EOF

-- Tickets table
CREATE TABLE IF NOT EXISTS tickets (
  id SERIAL PRIMARY KEY,
  title VARCHAR(255) NOT NULL,
  description TEXT,
  severity VARCHAR(20) NOT NULL CHECK (severity IN ('critical', 'high', 'medium', 'low')),
  status VARCHAR(20) NOT NULL CHECK (status IN ('open', 'in_progress', 'resolved', 'closed')),
  root_cause TEXT,
  affected_services TEXT[],
  monitoring_data JSONB,
  related_commits TEXT[],
  assignee VARCHAR(100),
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Indexes
CREATE INDEX IF NOT EXISTS idx_tickets_status ON tickets(status);
CREATE INDEX IF NOT EXISTS idx_tickets_severity ON tickets(severity);
CREATE INDEX IF NOT EXISTS idx_tickets_created_at ON tickets(created_at);
CREATE INDEX IF NOT EXISTS idx_tickets_assignee ON tickets(assignee);

-- Ticket history table
CREATE TABLE IF NOT EXISTS ticket_history (
  id SERIAL PRIMARY KEY,
  ticket_id INTEGER REFERENCES tickets(id) ON DELETE CASCADE,
  action VARCHAR(50) NOT NULL,
  old_value JSONB,
  new_value JSONB,
  changed_by VARCHAR(100),
  changed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX IF NOT EXISTS idx_ticket_history_ticket_id ON ticket_history(ticket_id);
CREATE INDEX IF NOT EXISTS idx_ticket_history_changed_at ON ticket_history(changed_at);

-- Monitoring index table (for MCP integration)
CREATE TABLE IF NOT EXISTS monitoring_index (
  id SERIAL PRIMARY KEY,
  ticket_id INTEGER REFERENCES tickets(id) ON DELETE CASCADE,
  source VARCHAR(50) NOT NULL,
  index_key VARCHAR(255) NOT NULL,
  index_value TEXT,
  metadata JSONB,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX IF NOT EXISTS idx_monitoring_index_ticket_id ON monitoring_index(ticket_id);
CREATE INDEX IF NOT EXISTS idx_monitoring_index_source ON monitoring_index(source);
CREATE INDEX IF NOT EXISTS idx_monitoring_index_key ON monitoring_index(index_key);

-- Update timestamp trigger
CREATE OR REPLACE FUNCTION update_updated_at_column()
RETURNS TRIGGER AS \$\$
BEGIN
    NEW.updated_at = CURRENT_TIMESTAMP;
    RETURN NEW;
END;
\$\$ language 'plpgsql';

DROP TRIGGER IF EXISTS update_tickets_updated_at ON tickets;
CREATE TRIGGER update_tickets_updated_at
    BEFORE UPDATE ON tickets
    FOR EACH ROW
    EXECUTE FUNCTION update_updated_at_column();

EOF

echo "Database initialization complete!"
echo "Database: $DB_NAME"
echo "Host: $DB_HOST:$DB_PORT"
echo "User: $DB_USER"


path: examples/usage-examples.md
content: # DevOps Insight Usage Examples

## Example 1: Analyze API Response Time Alert

### Scenario
Production API response time suddenly increased from 200ms to 3000ms.

### User Input
```
Production /api/users endpoint response time suddenly increased, help me analyze the cause
```

### DevOps Insight Analysis Process

1. **Retrieve APM Data**
   ```
   Retrieve /api/users endpoint trace data from Skywalking
   - Response time trends
   - Call chain analysis
   - Database query time
   ```

2. **Retrieve Kubernetes Data**
   ```
   Check related Pod status
   - CPU usage
   - Memory usage
   - Pod restart count
   - Event logs
   ```

3. **Retrieve Database Monitoring**
   ```
   Retrieve from PostgreSQL monitoring
   - Slow query logs
   - Connection pool status
   - Lock wait situations
   ```

4. **Retrieve Application Logs**
   ```
   Query from Elasticsearch
   - Error logs
   - Warning messages
   - Exception stack traces
   ```

5. **Root Cause Analysis**
   ```
   Analysis results:
   - Database query time increased from 50ms to 2800ms
   - Slow query log shows full table scan on users table
   - Recently deployed code removed an index
   ```

6. **Create Ticket**
   ```json
   {
     "title": "API /api/users response time anomaly - Missing database index",
     "severity": "high",
     "root_cause": "Recent code change removed email index on users table, causing queries to become full table scans",
     "affected_services": ["user-service"],
     "related_commits": ["abc123"]
   }
   ```

7. **Provide Fix Suggestions**
   ```sql
   -- Add missing index
   CREATE INDEX idx_users_email ON users(email);
   ```

---

## Example 2: Service Outage Post-Incident Analysis

### Scenario
Last night at 22:00, order service was completely unavailable for 15 minutes.

### User Input
```
Help me analyze the root cause of last night's 22:00 order service outage
```

### DevOps Insight Analysis Process

1. **Timeline Reconstruction**
   ```
   21:55 - Code deployment v2.3.1
   21:58 - Order service Pods start restarting
   22:00 - All Pods enter CrashLoopBackOff
   22:05 - Alert triggered
   22:10 - Rollback to v2.3.0
   22:15 - Service restored to normal
   ```

2. **Retrieve Error Logs**
   ```
   Retrieve logs from Elasticsearch for 21:55-22:15
   Found:
   - NullPointerException in OrderProcessor.java:142
   - Configuration item "payment.gateway.url" not found
   ```

3. **Code Change Analysis**
   ```
   Compare v2.3.0 and v2.3.1
   Found:
   - Added payment gateway configuration item
   - But ConfigMap was not updated
   ```

4. **Impact Assessment**
   ```
   - Affected users: Approximately 1,200 order requests failed
   - Business loss: Estimated 50 orders lost in 15 minutes
   - Affected services: order-service, payment-service
   ```

5. **Generate Post-Incident Report**
   ```markdown
   ## Incident Report: Order Service Outage

   ### Basic Information
   - Time: 2026-03-14 22:00-22:15
   - Duration: 15 minutes
   - Severity: Critical

   ### Root Cause
   Code deployment v2.3.1 introduced new configuration item payment.gateway.url,
   but Kubernetes ConfigMap was not updated synchronously, causing service startup failure.

   ### Timeline
   [Detailed timeline...]

   ### Impact Scope
   [Impact assessment...]

   ### Remediation Actions
   1. Immediately rollback to v2.3.0
   2. Update ConfigMap to add missing configuration
   3. Redeploy v2.3.1

   ### Preventive Measures
   1. Pre-deployment checklist: Confirm all configuration items are updated
   2. Add configuration validation: Check required configuration items at startup
   3. Improve deployment process: Update configuration first, then deploy code
   4. Add monitoring: Configuration missing alerts
   ```

---

## Example 3: Proactive Issue Discovery

### User Input
```
Check if there are any potential system issues
```

### DevOps Insight Analysis Process

1. **Scan All Service Metrics**
   ```
   Check items:
   - CPU/Memory usage trends
   - Error rate changes
   - Response time trends
   - Database connection pool usage
   - Cache hit rate
   ```

2. **Discover Anomalous Trends**
   ```
   Issues found:
   1. user-service memory usage continuously growing (from 2GB to 6GB in 7 days)
   2. Redis cache hit rate declining (from 95% to 75%)
   3. Database slow query count increased by 30%
   ```

3. **Analyze Causes**
   ```
   1. Memory leak analysis:
      - Possible memory leak
      - Recommend heap dump analysis

   2. Cache issues:
      - Cache key design may be unreasonable
      - Or data access patterns have changed

   3. Database performance:
      - Data volume growth causing slower queries
      - Need to optimize queries or add indexes
   ```

4. **Generate Health Report**
   ```markdown
   ## System Health Report

   ### 🔴 High Risk Issues
   1. user-service suspected memory leak
      - Recommendation: Immediately perform heap dump analysis
      - Priority: High

   ### 🟡 Medium Risk Issues
   1. Redis cache hit rate declining
      - Recommendation: Analyze cache access patterns
      - Priority: Medium

   2. Database slow queries increasing
      - Recommendation: Optimize queries or add indexes
      - Priority: Medium

   ### 🟢 Normal Metrics
   - API response time normal
   - Error rate within normal range
   - Service availability 99.9%
   ```

---

## Example 4: Code Change Impact Analysis

### Scenario
Preparing to merge a PR that refactors the database access layer.

### User Input
```
Analyze the impact of PR #789 on production, this PR refactors the database access layer
```

### DevOps Insight Analysis Process

1. **Code Change Analysis**
   ```
   Change content:
   - Modified 10 files
   - Refactored UserRepository, OrderRepository
   - Changed database connection pool configuration
   - Added query caching
   ```

2. **Identify Affected Services**
   ```
   Affected services:
   - user-service
   - order-service
   - analytics-service
   ```

3. **Risk Assessment**
   ```
   Risk points:
   1. Database connection pool configuration change
      - Risk: May cause connection exhaustion
      - Recommendation: Verify in test environment first

   2. Query cache introduction
      - Risk: Cache consistency issues
      - Recommendation: Monitor cache hit rate and data consistency

   3. Repository refactoring
      - Risk: SQL statement changes may affect performance
      - Recommendation: Compare execution plans
   ```

4. **Monitoring Recommendations**
   ```
   Key monitoring after deployment:
   1. Database connection count
   2. Query response time
   3. Cache hit rate
   4. Error rate
   5. Data consistency

   Recommended alert thresholds:
   - Database connections > 80%
   - Query response time > 500ms
   - Error rate > 1%
   ```

5. **Deployment Recommendations**
   ```
   Recommended deployment strategy:
   1. Thoroughly test in test environment first
   2. Use canary release (10% -> 50% -> 100%)
   3. Prepare quick rollback plan
   4. Deploy during off-peak hours
   5. Monitor closely for 1 hour after deployment
   ```

6. **New Monitoring Needed**
   ```
   Recommend adding:
   1. Database connection pool usage monitoring
   2. Cache hit rate monitoring
   3. Query performance comparison (before/after deployment)
   4. Data consistency checks
   ```

---

## Example 5: Create Warning Ticket

### Scenario
Memory usage is continuously growing, although it hasn't triggered alerts yet, there's potential risk.

### User Input
```
user-service memory usage keeps growing, although it hasn't reached the alert threshold, I'm worried it will cause problems
```

### DevOps Insight Processing Flow

1. **Data Collection**
   ```
   Retrieve user-service memory usage history
   - 7 days ago: 2.1 GB
   - 3 days ago: 3.5 GB
   - Today: 4.8 GB
   - Growth trend: Approximately 0.4 GB per day
   ```

2. **Trend Prediction**
   ```
   Based on current trend prediction:
   - Will reach 6 GB (alert threshold) in 3 days
   - May trigger OOM in 5 days
   ```

3. **Create Warning Ticket**
   ```json
   {
     "title": "user-service memory usage continuously growing - Warning",
     "severity": "medium",
     "status": "open",
     "description": "user-service memory usage shows linear growth trend, expected to reach alert threshold in 3 days",
     "root_cause": "To be analyzed - Possible memory leak",
     "affected_services": ["user-service"],
     "monitoring_data": {
       "current_memory": "4.8 GB",
       "growth_rate": "0.4 GB/day",
       "predicted_alert_time": "2026-03-18"
     }
   }
   ```

4. **Recommended Actions**
   ```
   Recommended measures:
   1. Immediate: Perform heap dump analysis
   2. Short-term: Increase memory monitoring frequency
   3. Mid-term: Fix memory leak (if confirmed)
   4. Long-term: Improve memory management mechanism
   ```

---

## Summary

These examples demonstrate DevOps Insight applications in different scenarios:

1. **Real-time Alert Response**: Quickly locate problem root cause
2. **Post-Incident Analysis**: Comprehensive event analysis, provide improvement recommendations
3. **Proactive Monitoring**: Discover potential issues, prevent problems before they occur
4. **Change Management**: Assess code change impact, reduce risks
5. **Warning Mechanism**: Discover trending issues in advance

Through integration of multiple monitoring systems and AI analysis capabilities, DevOps Insight can help teams manage and resolve production environment issues more efficiently.


Security scan verdicts — ClawScan: suspicious | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (CRITICAL)