mirror of
https://github.com/taylanbakircioglu/haproxy-openmanager.git
synced 2026-09-11 21:38:55 +00:00
5f5c7f1c75
The release notes inherited from the feature branch described the version it was written against, not the one going out. - `SCHEMA_VERSION` is 11 -> 12, not 10 -> 11, and the upgrade notes now say why: 11 was taken by v1.10.4 while this was in review, and the version gate would have skipped the migration entirely on every existing install. Includes the no-op recovery path for anyone running a pre-release build that recorded 11. - Successful agent polls are not logged by default, with the measured table behind it: 2 424 bytes/row on PostgreSQL 15 against the real schema and all nine indexes, ~9 792 logged calls/day/agent, and what that means at 20, 200 and 500 nodes both ways. The point is not the disk, it is that the row cap holds by DELETING, so without this the configured 7-day/30-day retention quietly becomes a few hours for everything in the table. - Runtime cost stated as measured numbers rather than adjectives: 27.7 us per request, 1.4 us on an excluded path, 18.8 us per row on the writer, 0.096 % of one core at 500 nodes. - REQUEST_LOG_QUEUE_MAX_BYTES documented in .env.template and CONFIG.md, with the reason it exists: the row count alone does not bound memory when max_body_bytes is operator-editable to 256 KB. - The old "raise REQUEST_LOG_QUEUE_MAX if you see drops" advice is corrected - following it could OOM the worker. Lower max_body_bytes or sample_rate first; if you do raise the queue, raise its byte ceiling with it. - Two behaviours that used to be silent are now written down: sink counters are per worker, and clearing the exclude-path list falls back to the shipped defaults rather than logging everything. - The `operator` role's visibility of agent rows is documented, including what it deliberately does NOT extend to (anonymous traffic and the usernames in failed logins). The v1.10.4 through v1.10.14 notes are unchanged and still above this in both files.
337 lines
8.6 KiB
Markdown
337 lines
8.6 KiB
Markdown
# Configuration Guide - HAProxy OpenManager
|
||
|
||
## 📋 Yapılandırma Dosyaları
|
||
|
||
### Dosya Yapısı
|
||
|
||
```
|
||
haproxy-openmanager/
|
||
├── .env.template # ✅ Template (GIT'e commit edilir)
|
||
├── .env # ❌ Gerçek config (GIT'e commit EDİLMEZ)
|
||
├── .gitignore # .env dosyalarını korur
|
||
└── CONFIG.md # Bu dosya
|
||
```
|
||
|
||
## 🎯 Quick Start
|
||
|
||
### 1. Template'den Config Oluşturma
|
||
|
||
```bash
|
||
# Template'i kopyala
|
||
cp .env.template .env
|
||
|
||
# Gerçek değerleri düzenle
|
||
nano .env
|
||
```
|
||
|
||
### 2. Örnek Yapılandırmalar
|
||
|
||
#### Development (Local)
|
||
```bash
|
||
# .env dosyası
|
||
PUBLIC_URL=http://localhost:8000
|
||
MANAGEMENT_BASE_URL=http://localhost:8000
|
||
DEBUG=True
|
||
LOG_LEVEL=DEBUG
|
||
```
|
||
|
||
#### Staging
|
||
```bash
|
||
# .env dosyası veya K8s ConfigMap
|
||
PUBLIC_URL=https://haproxy-staging.example.com
|
||
MANAGEMENT_BASE_URL=https://haproxy-staging.example.com
|
||
DEBUG=False
|
||
LOG_LEVEL=INFO
|
||
```
|
||
|
||
#### Production (OpenShift)
|
||
```bash
|
||
# K8s ConfigMap: k8s/manifests/07-configmaps.yaml
|
||
data:
|
||
PUBLIC_URL: 'https://haproxy-manager.example.com'
|
||
MANAGEMENT_BASE_URL: 'https://haproxy-manager.example.com'
|
||
DEBUG: 'False'
|
||
LOG_LEVEL: 'INFO'
|
||
```
|
||
|
||
## 🔐 Güvenlik
|
||
|
||
### Hassas Bilgiler
|
||
|
||
`.env` dosyası hassas bilgiler içerir:
|
||
- ❌ Database şifreleri
|
||
- ❌ Secret key'ler
|
||
- ❌ API token'ları
|
||
|
||
**Bu yüzden**:
|
||
- ✅ `.env` → `.gitignore`'da (commit edilmez)
|
||
- ✅ `.env.template` → Git'e commit edilir (örnek değerler)
|
||
- ✅ Production'da: Kubernetes Secrets kullan
|
||
|
||
### .gitignore Kontrolü
|
||
|
||
```bash
|
||
# .env dosyalarının ignore edildiğini kontrol et
|
||
grep "^\.env" .gitignore
|
||
|
||
# Çıktı olmalı:
|
||
# .env
|
||
# .env.local
|
||
# .env.development.local
|
||
# .env.test.local
|
||
# .env.production.local
|
||
```
|
||
|
||
## 📚 Environment Variable Detayları
|
||
|
||
### PUBLIC_URL
|
||
|
||
**Ne İşe Yarar**: Agent kurulum script'lerinde kullanılır
|
||
|
||
**Örnekler**:
|
||
```bash
|
||
# Development
|
||
PUBLIC_URL=http://localhost:8000
|
||
|
||
# Production
|
||
PUBLIC_URL=https://haproxy-manager.example.com
|
||
|
||
# OpenShift
|
||
PUBLIC_URL=https://haproxy-manager.example.com
|
||
```
|
||
|
||
**Nasıl Kullanılır**:
|
||
1. Agent Management sayfasından "Generate Install Script"
|
||
2. Script içinde `{{MANAGEMENT_URL}}` bu değerle değiştirilir
|
||
3. Agent bu URL'ye bağlanarak backend'i dinler
|
||
|
||
### REACT_APP_API_URL
|
||
|
||
**Ne İşe Yarar**: Frontend'in backend'e bağlanacağı URL
|
||
|
||
**Özel Durum**:
|
||
```bash
|
||
# Boş bırakılırsa → Auto-detect (production için önerilen)
|
||
REACT_APP_API_URL=
|
||
|
||
# Development için explicit
|
||
REACT_APP_API_URL=http://localhost:8000
|
||
```
|
||
|
||
**Auto-detect Mantığı**:
|
||
```javascript
|
||
// frontend/src/utils/api.js
|
||
if (process.env.REACT_APP_API_URL) {
|
||
return process.env.REACT_APP_API_URL;
|
||
}
|
||
|
||
// Production'da same-origin kullan
|
||
if (window.location) {
|
||
return `${window.location.protocol}//${window.location.hostname}`;
|
||
}
|
||
```
|
||
|
||
### REQUEST_LOG_ENABLED (v1.11.0)
|
||
|
||
**Ne İşe Yarar**: Request/Response Log özelliğinin sert (hard) kill-switch'i. `false` yapıldığında
|
||
loglama middleware'i ASGI zincirine **hiç eklenmez**, yazıcı ve retention görevleri başlatılmaz —
|
||
yani sıfır ek yük, ayar okuması bile yapılmaz. Değişiklik için restart gerekir.
|
||
|
||
**Örnekler**:
|
||
```bash
|
||
# Varsayılan: açık
|
||
REQUEST_LOG_ENABLED=true
|
||
|
||
# Tamamen kapat (ör. çok yüksek trafikli kurulum, veya regülasyon gereği)
|
||
REQUEST_LOG_ENABLED=false
|
||
```
|
||
|
||
**Nasıl Kullanılır**:
|
||
1. Restart gerektirmeden kapatmak isterseniz bunun yerine **Settings → Request Log → Enable request
|
||
log** anahtarını kullanın; o anında etkili olur.
|
||
2. Retention süreleri, gövde (body) yakalama, örnekleme oranı ve hariç tutulan path'ler bu env
|
||
değişkeniyle değil, veritabanındaki `requestlog.*` ayarlarıyla yönetilir — arayüzden düzenlenir.
|
||
3. Disk büyümesi asıl operasyonel konudur: sırasıyla `sample_rate`'i düşürün, `capture_get`'i
|
||
kapatın, `capture_bodies`'i kapatın, sonra `success_retention_days`'i kısaltın.
|
||
|
||
### REQUEST_LOG_QUEUE_MAX / REQUEST_LOG_QUEUE_MAX_BYTES / REQUEST_LOG_BATCH_SIZE / REQUEST_LOG_FLUSH_MS (v1.11.0)
|
||
|
||
**Ne İşe Yarar**: Log satırlarını yazan arka plan görevinin ayarları. Satırlar sınırlı bir kuyruğa
|
||
konur ve toplu (batch) INSERT ile yazılır; böylece istek yolu asla veritabanını beklemez.
|
||
|
||
**Örnekler**:
|
||
```bash
|
||
# Worker başına kuyruk derinliği. Dolduğunda satırlar DÜŞÜRÜLÜR (sayılır ve
|
||
# Request Log sayfasında gösterilir), istek bloklanmaz.
|
||
REQUEST_LOG_QUEUE_MAX=2000
|
||
|
||
# Aynı kuyruğun BAYT tavanı (worker başına). Satır sayısı tek başına belleği
|
||
# sınırlamaz: `max_body_bytes` Settings'ten 256 KB'a kadar ayarlanabilir ve bir
|
||
# satır bunu iki kez taşıyabilir, o tavanda 2000 satırlık kuyruk ~1 GiB tutar.
|
||
# Hangi sınır önce dolarsa kuyruk orada durur.
|
||
REQUEST_LOG_QUEUE_MAX_BYTES=67108864
|
||
|
||
# Tek INSERT'te kaç satır yazılacağı (havuzdan istek başına değil, batch başına
|
||
# bir bağlantı alınır)
|
||
REQUEST_LOG_BATCH_SIZE=100
|
||
|
||
# Yarım dolu bir batch'in en fazla ne kadar bekletileceği (ms)
|
||
REQUEST_LOG_FLUSH_MS=500
|
||
```
|
||
|
||
**Nasıl Kullanılır**:
|
||
1. Request Log sayfasında "rows dropped" uyarısı görüyorsanız önce `requestlog.max_body_bytes`
|
||
veya `sample_rate`'i düşürün. `REQUEST_LOG_QUEUE_MAX`'ı artırmak bu worker'ın tutabileceği
|
||
belleği de artırır; artıracaksanız `REQUEST_LOG_QUEUE_MAX_BYTES`'ı da birlikte artırın.
|
||
2. Bu değerler worker başınadır — `UVICORN_WORKERS` arttıkça toplam bellek de o oranda artar.
|
||
`GET /api/request-logs/stats` içindeki sayaçlar da worker başınadır ve yanıtta öyle
|
||
etiketlenir; 4 worker'da gördüğünüz düşüş sayısı gerçeğin dörtte biridir.
|
||
3. Büyük filolarda tek en etkili ayar `requestlog.capture_agent_success`'tir (varsayılan kapalı).
|
||
Açık olsaydı 200 düğümlük bir filo günde ~2M satır yazar ve 500.000 satır tavanına 6 saatte
|
||
ulaşırdı; yapılandırılmış 7 gün / 30 gün saklama o noktada birkaç saate iner. Başarısız ajan
|
||
çağrıları bu ayardan bağımsız olarak her zaman loglanır.
|
||
|
||
## 🚀 Deployment Senaryoları
|
||
|
||
### Docker Compose
|
||
|
||
```bash
|
||
# 1. .env dosyası oluştur
|
||
cp .env.template .env
|
||
|
||
# 2. Değerleri düzenle
|
||
nano .env
|
||
|
||
# 3. Başlat
|
||
docker-compose up -d
|
||
|
||
# 4. Kontrol et
|
||
docker-compose logs backend | grep "PUBLIC_URL"
|
||
```
|
||
|
||
### Kubernetes/OpenShift
|
||
|
||
```bash
|
||
# 1. ConfigMap'i düzenle
|
||
vim k8s/manifests/07-configmaps.yaml
|
||
|
||
# 2. Apply
|
||
kubectl apply -f k8s/manifests/
|
||
|
||
# 3. Kontrol et
|
||
kubectl get configmap backend-config -n haproxy-manager -o yaml
|
||
```
|
||
|
||
### Manuel (Development)
|
||
|
||
```bash
|
||
# 1. Backend
|
||
cd backend
|
||
cp ../.env.template .env
|
||
export $(cat .env | xargs)
|
||
uvicorn main:app --reload
|
||
|
||
# 2. Frontend (başka terminal)
|
||
cd frontend
|
||
export REACT_APP_API_URL=http://localhost:8000
|
||
npm start
|
||
```
|
||
|
||
## 🔧 Troubleshooting
|
||
|
||
### Agent Script'inde Yanlış URL
|
||
|
||
**Sorun**: Agent script hala eski URL içeriyor
|
||
|
||
**Çözüm**:
|
||
```bash
|
||
# 1. Backend'deki değeri kontrol et
|
||
docker exec haproxy-openmanager-backend env | grep PUBLIC_URL
|
||
|
||
# 2. Container'ı yeniden başlat
|
||
docker-compose restart backend
|
||
|
||
# 3. Yeni script oluştur
|
||
# UI'dan tekrar "Generate Install Script"
|
||
```
|
||
|
||
### Frontend Backend'e Bağlanamıyor
|
||
|
||
**Sorun**: CORS hatası veya connection refused
|
||
|
||
**Çözüm**:
|
||
```bash
|
||
# 1. Frontend config'i kontrol et
|
||
docker exec haproxy-openmanager-frontend env | grep REACT_APP_API_URL
|
||
|
||
# 2. Browser console'da kontrol et
|
||
# [API Config] Base URL: http://localhost:8000
|
||
|
||
# 3. Network sekmesinde request URL'i kontrol et
|
||
```
|
||
|
||
## 📖 En İyi Pratikler
|
||
|
||
### ✅ YAPILMASI GEREKENLER
|
||
|
||
1. **Her ortam için ayrı değerler**
|
||
```
|
||
Dev: PUBLIC_URL=http://localhost:8000
|
||
Staging: PUBLIC_URL=https://staging.example.com
|
||
Prod: PUBLIC_URL=https://prod.example.com
|
||
```
|
||
|
||
2. **Template'i güncelle**
|
||
- Yeni variable eklendiğinde `.env.template`'e ekle
|
||
- Dokümantasyon ile birlikte
|
||
|
||
3. **Secrets kullan (Production)**
|
||
```yaml
|
||
# K8s Secret
|
||
apiVersion: v1
|
||
kind: Secret
|
||
metadata:
|
||
name: backend-secret
|
||
data:
|
||
SECRET_KEY: <base64-encoded>
|
||
```
|
||
|
||
### ❌ YAPILMAMASI GEREKENLER
|
||
|
||
1. **`.env` dosyasını commit etmeyin**
|
||
```bash
|
||
# Yanlış!
|
||
git add .env
|
||
|
||
# Doğru!
|
||
git add .env.template
|
||
```
|
||
|
||
2. **Production secret'larını template'e koymayın**
|
||
```bash
|
||
# .env.template içinde YANLIŞLAR:
|
||
SECRET_KEY=actual-production-secret-12345 ❌
|
||
DATABASE_URL=postgresql://admin:realpass@prod-db ❌
|
||
|
||
# Doğru:
|
||
SECRET_KEY=your-secret-key-change-this-in-production ✅
|
||
DATABASE_URL=postgresql://user:pass@host:5432/db ✅
|
||
```
|
||
|
||
3. **Hardcoded URL kullanmayın**
|
||
```python
|
||
# Yanlış!
|
||
MANAGEMENT_URL = "https://my-server.com" ❌
|
||
|
||
# Doğru!
|
||
MANAGEMENT_URL = os.getenv("PUBLIC_URL") ✅
|
||
```
|
||
|
||
## 🆘 Yardım
|
||
|
||
Sorularınız için:
|
||
- 📘 Bu dosya: `CONFIG.md`
|
||
- 📗 Ana dokümantasyon: `README.md`
|
||
- 📙 Template: `.env.template`
|
||
|