Fix jwt-token
This commit is contained in:
@@ -1,83 +1,188 @@
|
||||
# Container Health & Metrics Endpoint Implementation
|
||||
|
||||
## Creative Container Monitoring Solutions
|
||||
## How It Works - Different Approaches Explained
|
||||
|
||||
### 1. Internal Health/Metrics Endpoints
|
||||
### 🎯 **Current Implementation: Multi-Layered Detection**
|
||||
|
||||
Add these endpoints to each container for self-reporting metrics:
|
||||
The system I just implemented uses a **fallback chain** approach - NO agents required! Here's how:
|
||||
|
||||
#### Backend Container (Node.js Example)
|
||||
#### **Method 1: Built-in Health Endpoints (Recommended)**
|
||||
```javascript
|
||||
// Add to your existing Express.js containers
|
||||
const express = require('express');
|
||||
const os = require('os');
|
||||
const fs = require('fs');
|
||||
const app = express();
|
||||
|
||||
// Health & Metrics endpoint
|
||||
// Simple addition to existing code - no agent needed!
|
||||
app.get('/health/metrics', (req, res) => {
|
||||
const memUsage = process.memoryUsage();
|
||||
const cpuUsage = process.cpuUsage();
|
||||
|
||||
res.json({
|
||||
container: process.env.CONTAINER_NAME || 'backend',
|
||||
timestamp: new Date().toISOString(),
|
||||
uptime: process.uptime(),
|
||||
cpu: getCurrentCPU(),
|
||||
memory: {
|
||||
usage: `${Math.round(memUsage.heapUsed / 1024 / 1024)}MB`,
|
||||
total: `${Math.round(memUsage.heapTotal / 1024 / 1024)}MB`,
|
||||
percentage: `${Math.round((memUsage.heapUsed / memUsage.heapTotal) * 100)}%`
|
||||
},
|
||||
cpu: {
|
||||
user: cpuUsage.user,
|
||||
system: cpuUsage.system,
|
||||
load: os.loadavg()[0].toFixed(2) + '%'
|
||||
},
|
||||
network: {
|
||||
connections: getActiveConnections(),
|
||||
requests_per_minute: getRequestRate()
|
||||
},
|
||||
disk: {
|
||||
logs: getDiskUsage('/var/log'),
|
||||
temp: getDiskUsage('/tmp')
|
||||
},
|
||||
health: 'healthy',
|
||||
version: process.env.APP_VERSION || '1.0.0'
|
||||
uptime: process.uptime(),
|
||||
health: 'healthy'
|
||||
});
|
||||
});
|
||||
|
||||
function getActiveConnections() {
|
||||
try {
|
||||
const netstat = require('child_process').execSync('netstat -an | grep ESTABLISHED | wc -l', { encoding: 'utf8' });
|
||||
return parseInt(netstat.trim());
|
||||
} catch (e) {
|
||||
return 'N/A';
|
||||
}
|
||||
}
|
||||
|
||||
function getRequestRate() {
|
||||
// Implement request counter logic
|
||||
return global.requestCounter || 0;
|
||||
}
|
||||
|
||||
function getDiskUsage(path) {
|
||||
try {
|
||||
const stats = fs.statSync(path);
|
||||
return `${Math.round(stats.size / 1024 / 1024)}MB`;
|
||||
} catch (e) {
|
||||
return 'N/A';
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### Frontend Container (Nginx + JS Example)
|
||||
```nginx
|
||||
# Add to nginx.conf
|
||||
location /health/metrics {
|
||||
access_log off;
|
||||
return 200 '{"container":"frontend","status":"healthy","nginx_version":"$nginx_version","connections":"$connections_active","timestamp":"$time_iso8601"}';
|
||||
add_header Content-Type application/json;
|
||||
}
|
||||
**✅ Pros**: Direct from container, accurate, real-time
|
||||
**❌ Cons**: Requires code changes in each container
|
||||
|
||||
#### **Method 2: Docker Stats API (Current Fallback)**
|
||||
```javascript
|
||||
// From management container - queries Docker daemon
|
||||
const { stdout } = await execAsync('docker stats --no-stream --format "table {{.Container}}\\t{{.CPUPerc}}\\t{{.MemUsage}}"');
|
||||
```
|
||||
|
||||
**✅ Pros**: Works with ANY container, no code changes needed
|
||||
**❌ Cons**: Requires Docker daemon access
|
||||
|
||||
#### **Method 3: Docker Compose Status**
|
||||
```javascript
|
||||
// Queries docker-compose for container states
|
||||
const { stdout } = await execAsync('docker-compose ps --format json');
|
||||
```
|
||||
|
||||
**✅ Pros**: Basic status info, works everywhere
|
||||
**❌ Cons**: Limited metrics, just status/health
|
||||
|
||||
---
|
||||
|
||||
## 🤖 **Alternative: Agent-Based Approaches**
|
||||
|
||||
### **Option A: Sidecar Container Pattern**
|
||||
```yaml
|
||||
# docker-compose.yml
|
||||
services:
|
||||
app:
|
||||
image: my-app:latest
|
||||
|
||||
metrics-agent:
|
||||
image: metrics-agent:latest
|
||||
volumes:
|
||||
- /proc:/host/proc:ro
|
||||
- /sys:/host/sys:ro
|
||||
environment:
|
||||
- TARGET_CONTAINER=app
|
||||
```
|
||||
|
||||
**How it works**: Deploy a metrics agent container alongside each service
|
||||
**✅ Pros**: No code changes, detailed system metrics
|
||||
**❌ Cons**: Extra containers, more complex deployment
|
||||
|
||||
### **Option B: In-Container Agent Process**
|
||||
```dockerfile
|
||||
# Add to existing Dockerfile
|
||||
FROM node:18
|
||||
COPY . /app
|
||||
COPY metrics-agent /usr/local/bin/
|
||||
RUN chmod +x /usr/local/bin/metrics-agent
|
||||
|
||||
# Start both app and agent
|
||||
CMD ["sh", "-c", "metrics-agent & npm start"]
|
||||
```
|
||||
|
||||
**How it works**: Runs a metrics collection process inside each container
|
||||
**✅ Pros**: Single container, detailed metrics
|
||||
**❌ Cons**: Modifies container, uses more resources
|
||||
|
||||
### **Option C: External Monitoring Tools**
|
||||
|
||||
#### **Prometheus + Node Exporter**
|
||||
```yaml
|
||||
services:
|
||||
node-exporter:
|
||||
image: prom/node-exporter
|
||||
ports:
|
||||
- "9100:9100"
|
||||
volumes:
|
||||
- /proc:/host/proc:ro
|
||||
- /sys:/host/sys:ro
|
||||
- /:/rootfs:ro
|
||||
```
|
||||
|
||||
#### **cAdvisor (Container Advisor)**
|
||||
```yaml
|
||||
services:
|
||||
cadvisor:
|
||||
image: gcr.io/cadvisor/cadvisor:latest
|
||||
ports:
|
||||
- "8080:8080"
|
||||
volumes:
|
||||
- /:/rootfs:ro
|
||||
- /var/run:/var/run:rw
|
||||
- /sys:/sys:ro
|
||||
- /var/lib/docker/:/var/lib/docker:ro
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🔧 **Recommended Implementation Strategy**
|
||||
|
||||
### **Phase 1: Docker Stats (Current)**
|
||||
- ✅ **Already implemented**
|
||||
- Works immediately with existing containers
|
||||
- No code changes required
|
||||
- Provides CPU, Memory, Network, Disk I/O
|
||||
|
||||
### **Phase 2: Add Health Endpoints**
|
||||
```javascript
|
||||
// Add 3 lines to each container's main file
|
||||
const { createHealthEndpoint } = require('./utils/health-endpoint');
|
||||
createHealthEndpoint(app); // app is your Express instance
|
||||
```
|
||||
|
||||
### **Phase 3: Enhanced Monitoring (Optional)**
|
||||
- Add Prometheus metrics
|
||||
- Implement custom business metrics
|
||||
- Add alerting and dashboards
|
||||
|
||||
---
|
||||
|
||||
## 🎯 **Current System Architecture**
|
||||
|
||||
```
|
||||
Management Container
|
||||
↓
|
||||
1. Try HTTP health endpoints (app containers)
|
||||
↓ (if fails)
|
||||
2. Query Docker daemon (all containers)
|
||||
↓ (if fails)
|
||||
3. Check docker-compose status
|
||||
↓ (if fails)
|
||||
4. Scan system processes
|
||||
```
|
||||
|
||||
**No agents required!** The management container does all the work:
|
||||
|
||||
1. **Health Endpoints**: Makes HTTP calls to containers that support it
|
||||
2. **Docker Stats**: Queries Docker daemon for ALL container metrics
|
||||
3. **Process Detection**: Scans system for running services
|
||||
4. **Smart Fallback**: Always tries to get SOME information
|
||||
|
||||
---
|
||||
|
||||
## 🚀 **Why This Approach is Great**
|
||||
|
||||
### **For Existing Systems**
|
||||
- **Zero downtime**: Works immediately
|
||||
- **No refactoring**: Containers don't need changes
|
||||
- **Comprehensive**: Sees ALL containers (yours + infrastructure)
|
||||
|
||||
### **For Future Development**
|
||||
- **Gradual enhancement**: Add health endpoints when convenient
|
||||
- **Flexible**: Can switch to any monitoring approach later
|
||||
- **Standards compliant**: Uses Docker APIs and HTTP standards
|
||||
|
||||
### **Production Ready**
|
||||
- **Reliable fallbacks**: Always gets some data
|
||||
- **Error handling**: Graceful degradation
|
||||
- **Performance**: Lightweight HTTP calls
|
||||
- **Security**: No privileged containers needed
|
||||
|
||||
### 2. Prometheus-style Metrics Scraping
|
||||
|
||||
```javascript
|
||||
|
||||
61
docs/monitoring-architecture.txt
Normal file
61
docs/monitoring-architecture.txt
Normal file
@@ -0,0 +1,61 @@
|
||||
```
|
||||
Container Monitoring Architecture - No Agents Required!
|
||||
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ Management Container │
|
||||
│ │
|
||||
│ ┌─────────────────────────────────────────────────────────┐ │
|
||||
│ │ Monitoring Controller │ │
|
||||
│ │ │ │
|
||||
│ │ 1. HTTP Health Endpoints ──┐ │ │
|
||||
│ │ 2. Docker Stats API ────────┼──── Fallback Chain │ │
|
||||
│ │ 3. Docker Compose Status ───┤ │ │
|
||||
│ │ 4. Process List Scanning ───┘ │ │
|
||||
│ └─────────────────────────────────────────────────────────┘ │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
│
|
||||
▼
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ Target Containers │
|
||||
├─────────────────┬─────────────────┬─────────────────┬───────────┤
|
||||
│ App Containers│ Infrastructure │ Cache Layer │ Database │
|
||||
│ │ │ │ │
|
||||
│ ┌─────────────┐ │ ┌─────────────┐ │ ┌─────────────┐ │ ┌───────┐ │
|
||||
│ │ Backend │ │ │ Nginx │ │ │ Redis │ │ │ Postgres│
|
||||
│ │ │ │ │ │ │ │ │ │ │ │ │
|
||||
│ │ /health ←───┼─┼─┼─HTTP calls──┼─┼─┼─Basic ping──┼─┼─┼─Port │ │
|
||||
│ │ /metrics │ │ │ /nginx_stat │ │ │ │ │ │ check │ │
|
||||
│ └─────────────┘ │ └─────────────┘ │ └─────────────┘ │ └───────┘ │
|
||||
├─────────────────┼─────────────────┼─────────────────┼───────────┤
|
||||
│ │ │ │ │
|
||||
│ Enhanced Data │ Basic Status │ Connectivity │ Status │
|
||||
│ • CPU usage │ • Up/Down │ • Responsive │ • Running│
|
||||
│ • Memory % │ • Port info │ • Timeout │ • Health │
|
||||
│ • Custom │ • Health │ │ │
|
||||
│ metrics │ check │ │ │
|
||||
└─────────────────┴─────────────────┴─────────────────┴───────────┘
|
||||
│
|
||||
▼
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ Docker Daemon │
|
||||
│ │
|
||||
│ If HTTP calls fail, query Docker directly: │
|
||||
│ • docker stats --no-stream (CPU, Memory, Network, Disk) │
|
||||
│ • docker-compose ps (Status, Health, Ports) │
|
||||
│ • ps aux | grep (Process detection as final fallback) │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
|
||||
Data Flow:
|
||||
1. Management container tries HTTP health endpoints first
|
||||
2. Falls back to Docker daemon APIs if containers don't respond
|
||||
3. Uses docker-compose for basic status if Docker unavailable
|
||||
4. Scans processes as absolute last resort
|
||||
|
||||
Benefits:
|
||||
✅ No agents to install or maintain
|
||||
✅ Works with existing containers immediately
|
||||
✅ Gradual enhancement possible (add health endpoints when convenient)
|
||||
✅ Comprehensive coverage (all containers, not just yours)
|
||||
✅ Multiple fallbacks ensure data is always available
|
||||
✅ Standard HTTP + Docker APIs (no proprietary protocols)
|
||||
```
|
||||
Reference in New Issue
Block a user