Accesso ai cruscotti di monitoraggio

1. Passare alla distribuzione MongoDB nella console IBM Cloud.
2. Fare clic su Monitoraggio nella navigazione a sinistra.
3. Fare clic su Avvia monitoraggio per aprire il dashboard Sysdig.

Metriche chiave da monitorare:

• Metriche della piattaforma:

  • Utilizzo della CPU- obiettivo: < 75% sostenuto
  • Utilizzo del disco- obiettivo: < 80%
  • IOPS del disco: monitorare la saturazione
  • Throughput di rete: identificare i vincoli di larghezza di banda

• MongoDB-specific metriche:

  • Operazioni al secondo: tracciare i modelli di carico di lavoro
  • Connessioni attive: monitorare i limiti del piano
  • Ritardo di replica- target: < 1 secondo
  • Tempo di esecuzione delle query: identificare le query lente
  • Rapporto di successo della cache- obiettivo: > 95%

Impostazione degli avvisi

Creare avvisi per soglie critiche:

Alert: High CPU Usage
Condition: CPU > 80% for 10 minutes
Action: Notify operations team

Alert: Replication Lag
Condition: Replication lag > 5 seconds
Action: Page on-call engineer

Alert: Disk Space
Condition: Disk usage > 85%
Action: Trigger scaling workflow

Creazione di cruscotti personalizzati

1. In Sysdig, fare clic su Cruscotti > Crea cruscotto.
2. Aggiungere pannelli per le metriche chiave.
3. Utilizzate i filtri per concentrarvi sulla distribuzione di MongoDB.
4. Salvate e condividete con il vostro team.

Esempio di layout del cruscotto

• Riga 1: utilizzo di CPU, memoria e disco
• Riga 2: Operazioni al secondo, connessioni attive
• Riga 3: ritardo di replica, prestazioni delle query
• Riga 4: Statistiche della cache, contesa del blocco

Analisi storica

• Utilizzare il selettore dell'intervallo di tempo per i dati storici
• Confrontare le metriche attuali con quelle di riferimento
• Identificare tendenze e modelli
• Correlare gli eventi con le modifiche delle prestazioni

Azioni consigliate:

• Impostate gli avvisi prima che si verifichino i problemi.
• Esaminare quotidianamente i cruscotti.
• Stabilire le metriche di riferimento.
• Documentare i modelli normali rispetto a quelli anormali.
• Utilizzare le metriche per la pianificazione della capacità.

Accesso Activity Tracker

1. Andare su Osservabilità > Activity Tracker nella console IBM Cloud.
2. Selezionare la propria regione.
3. Filtrare gli eventi in base all'istanza di MongoDB.

Eventi chiave da monitorare:

• Modifiche alla configurazione:

  • Operazioni di scalatura (CPU, memoria, disco)
  • Modifiche alla configurazione di backup
  • Aggiornamenti della configurazione di rete
  • Modifiche all'accesso degli utenti

• Eventi che incidono sulle prestazioni

  • Riavvio del database
  • Eventi di failover
  • Operazioni di manutenzione
  • Creazione e cancellazione di indici

Correlazione tra eventi e problemi di prestazioni

1. Si noti l'ora in cui si è verificato il degrado delle prestazioni.
2. Cercate su Activity Tracker gli eventi che si svolgono in quel periodo.
3. Cercare modifiche alla configurazione o azioni amministrative.
4. Correlazione con le metriche di monitoraggio.

Esempio di analisi degli eventi

Event: Database scaled from 2GB to 4GB RAM
Time: 2024-01-15 14:30:00 UTC
Impact: Temporary connection disruption (30 seconds)
Result: Improved performance after scaling

Traccia di controllo per la conformità

• Tracciare chi ha apportato le modifiche e quando
• Mantenere la conformità alle politiche di sicurezza
• Esaminare i modelli di accesso
• Identificare le modifiche non autorizzate

Azioni consigliate:

• Esaminare regolarmente i registri di Activity Tracker.
• Impostare gli avvisi per gli eventi critici.
• Documentare le procedure di gestione delle modifiche.
• Correlare gli eventi con le metriche delle prestazioni.
• Utilizzare per l'analisi post-incidente.

Scalabilità verticale (calcolo e memoria)

Scalare le risorse di CPU e memoria per gestire un carico di lavoro maggiore.

• Utilizzando la console IBM Cloud:

  1. Accedere alla distribuzione MongoDB.
  2. Fare clic su Risorse nella navigazione a sinistra.
  3. Regolare i cursori della memoria e della CPU.
  4. Esaminare l'impatto sui costi.
  5. Fare clic su Scala.

• Utilizzo della CLI di IBM Cloud:

  # Scale memory to 8GB and CPU to 4 cores
  ibmcloud cdb deployment-groups-set <deployment-id> member \
    --memory 8192 \
    --cpu-allocation 4
  

Considerazioni

• Breve interruzione della connessione durante la scalatura.
• Prevedere 5-10 minuti di pausa.
• Scalare in modo proattivo prima della saturazione.
• Monitorare le metriche dopo il ridimensionamento.

Scalatura orizzontale (membri del set di replica)

Aggiungere i membri del set di replica per il read scaling e l'alta disponibilità.

• Utilizzando la console IBM Cloud:

  1. Andare su Risorse.
  2. Regolare il cursore Membri.
  3. Configurazione della revisione.
  4. Fare clic su Scala.

• Utilizzo della CLI di IBM Cloud:

  # Add a replica set member
  ibmcloud cdb deployment-groups-set <deployment-id> member \
    --members 4
  

Vantaggi

• Distribuire il carico di lettura sui secondari
• Miglioramento della tolleranza ai guasti
• Migliore distribuzione geografica
• Nessun tempo di inattività per l'aggiunta di membri

Scalabilità dello storage

Aumentare lo spazio su disco e gli IOPS per migliorare le prestazioni.

• Utilizzando la console IBM Cloud:

  1. Andare su Risorse.
  2. Regolare il cursore del disco.
  3. Rivedere l'allocazione degli IOPS.
  4. Fare clic su Scala.

• Utilizzo della CLI di IBM Cloud:

  # Scale disk to 100GB
  ibmcloud cdb deployment-groups-set <deployment-id> member \
    --disk-allocation 102400
  

INFORMAZIONI IMPORTANTI:

• Lo stoccaggio può essere solo aumentato, non diminuito
• Scala IOPS con le dimensioni del disco
• Nessun tempo di inattività per lo scaling dello storage
• Monitoraggio delle tendenze di utilizzo del disco

Migliori pratiche di scalabilità

| Latenza del disco | Aumentare la dimensione del disco per ottenere più IOPS | | Limiti di connessione | Passaggio al livello superiore | Carico di lavoro pesante per la lettura | Aggiunta di membri della replica | | Carico di lavoro pesante per la scrittura | Scala la CPU e la memoria |

Ottimizzazione dei costi

• Dimensionare correttamente l'impiego.
• Utilizzare il monitoraggio per identificare le esigenze reali.
• Ridimensionamento durante i periodi di basso traffico (se supportato).
• Considerate la capacità riservata per i carichi di lavoro prevedibili.

Automazione

# Example: Auto-scale based on CPU threshold
if [ $(ibmcloud cdb deployment-metrics <deployment-id> --metric cpu) -gt 80 ]; then
  ibmcloud cdb deployment-groups-set <deployment-id> member --cpu-allocation 6
fi

Installazione della CLI IBM Cloud

# Install IBM Cloud CLI
curl -fsSL https://clis.cloud.ibm.com/install/linux | sh

# Install databases plugin
ibmcloud plugin install cloud-databases

Comandi diagnostici essenziali

• Ottenere informazioni sulla distribuzione:

  # List all MongoDB deployments
  ibmcloud cdb deployments --type mongodb
  
  # Get specific deployment details
  ibmcloud cdb deployment <deployment-id>
  

• Controllare lo stato di distribuzione:

  # Get deployment status
  ibmcloud cdb deployment-status <deployment-id>
  
  # Get connection strings
  ibmcloud cdb deployment-connections <deployment-id>
  

• Monitoraggio delle metriche:

  # Get CPU metrics
  ibmcloud cdb deployment-metrics <deployment-id> --metric cpu
  
  # Get memory metrics
  ibmcloud cdb deployment-metrics <deployment-id> --metric memory
  
  # Get disk metrics
  ibmcloud cdb deployment-metrics <deployment-id> --metric disk
  

• Operazioni di scalatura:

  # Scale memory
  ibmcloud cdb deployment-groups-set <deployment-id> member \
    --memory 16384
  
  # Scale CPU
  ibmcloud cdb deployment-groups-set <deployment-id> member \
    --cpu-allocation 8
  
  # Scale disk
  ibmcloud cdb deployment-groups-set <deployment-id> member \
    --disk-allocation 204800
  

• Operazioni di backup:

  # List backups
  ibmcloud cdb backups <deployment-id>
  
  # Get backup information
  ibmcloud cdb backup <backup-id>
  

Utilizzo dell'API IBM Cloud

• Autenticazione:

  # Get IAM token
  export IAM_TOKEN=$(ibmcloud iam oauth-tokens --output json | jq -r '.iam_token')
  

• Ottenere le metriche di distribuzione utilizzando l'API:

  # Get metrics
  curl -X GET \
    "https://api.{region}.databases.cloud.ibm.com/v5/deployments/{deployment-id}/metrics" \
    -H "Authorization: ${IAM_TOKEN}"
  

• Scalare la distribuzione utilizzando l'API:

  # Scale resources
  curl -X PATCH \
    "https://api.{region}.databases.cloud.ibm.com/v5/deployments/{deployment-id}/groups/member" \
    -H "Authorization: ${IAM_TOKEN}" \
    -H "Content-Type: application/json" \
    -d '{
      "memory": {
        "allocation_mb": 16384
      },
      "cpu": {
        "allocation_count": 8
      }
    }'
  

• Esempio di script diagnostico:

  #!/bin/bash
  # MongoDB Performance Check Script
  
  DEPLOYMENT_ID="your-deployment-id"
  
  echo "=== MongoDB Performance Diagnostics ==="
  echo ""
  
  # Check CPU
  CPU=$(ibmcloud cdb deployment-metrics $DEPLOYMENT_ID --metric cpu --output json | jq -r '.metrics[0].value')
  echo "CPU Usage: ${CPU}%"
  if [ $(echo "$CPU > 80" | bc) -eq 1 ]; then
    echo "⚠️  WARNING: High CPU usage detected"
  fi
  
  # Check Memory
  MEMORY=$(ibmcloud cdb deployment-metrics $DEPLOYMENT_ID --metric memory --output json | jq -r '.metrics[0].value')
  echo "Memory Usage: ${MEMORY}%"
  if [ $(echo "$MEMORY > 80" | bc) -eq 1 ]; then
    echo "⚠️  WARNING: High memory usage detected"
  fi
  
  # Check Disk
  DISK=$(ibmcloud cdb deployment-metrics $DEPLOYMENT_ID --metric disk --output json | jq -r '.metrics[0].value')
  echo "Disk Usage: ${DISK}%"
  if [ $(echo "$DISK > 80" | bc) -eq 1 ]; then
    echo "⚠️  WARNING: High disk usage detected"
  fi
  
  # Check Status
  STATUS=$(ibmcloud cdb deployment-status $DEPLOYMENT_ID --output json | jq -r '.status')
  echo "Deployment Status: ${STATUS}"
  
  echo ""
  echo "=== Diagnostics Complete ==="
  

• Raccomandazioni per l'automazione

  • Programmare controlli sanitari regolari.
  • Integrazione con i sistemi di monitoraggio.
  • Automatizzare il ridimensionamento in base alle soglie.
  • Creare avvisi per le metriche critiche.
  • Registra tutte le operazioni per la tracciabilità.

Endpoint privati (consigliati)

Vantaggi:

• Latenza inferiore
• Sicurezza potenziata
• Nessun costo di uscita da internet
• Migliori prestazioni per i carichi di lavoro di IBM Cloud

Configurazione:

1. Spostarsi su Impostazioni > Endpoint.
2. Abilita l'endpoint privato.
3. Aggiornare le stringhe di connessione nelle applicazioni.

Esempio di stringa di connessione:

mongodb://user:pass@host.private.databases.appdomain.cloud:port/database?authSource=admin&replicaSet=replset

Endpoint pubblici

Casi di utilizzo:

• Applicazioni esterne
• Sviluppo e test
• Scenari di cloud ibrido

Considerazioni sulla sicurezza:

• Utilizzare l'elenco dei permessi IP.
• Applicare TLS / SSL.
• Ruotare regolarmente le credenziali.

Endpoint di servizio

IBM Cloud gli endpoint del servizio forniscono una connettività ottimizzata all'interno di IBM Cloud.

Vantaggi

• Latenza ridotta
• Nessun attraversamento di Internet pubblico
• Miglioramento della sicurezza
• Risparmio sui costi della larghezza di banda

Configurazione

# Enable service endpoint
ibmcloud cdb deployment-service-endpoint-enable <deployment-id>

Considerazioni sulla distribuzione multizona

Databases for MongoDB può estendersi su più zone di disponibilità.

Procedure consigliate

• Distribuire le applicazioni nella stessa regione.
• Utilizzare le preferenze di lettura per ridurre al minimo la latenza.
• Considerare la preferenza di lettura di nearest per le applicazioni multizona.
• Monitorare il ritardo di replica tra le zone.

Risoluzione dei problemi di latenza della rete

• Misurare la latenza dell'applicazione

  # Test connection latency
  time mongo "mongodb://host:port/database" --eval "db.runCommand({ping: 1})"
  

• Controllo dalla shell IBM Cloud

  # Ping test (if ICMP allowed)
  ping -c 10 your-mongodb-host.databases.appdomain.cloud
  
  # TCP connection test
  nc -zv your-mongodb-host.databases.appdomain.cloud 27017
  

MongoDB diagnostica delle connessioni

// Check network latency
db.runCommand({ ping: 1 })

// Check connection pool stats
db.serverStatus().connections

Distribuzione geografica

Per le applicazioni distribuite a livello globale:

Strategie

• Singola regione: Latenza più bassa, singolo punto di guasto
• Multiregione con repliche di lettura: Scalabilità in lettura, consistenza finale
• Replica interregionale: Disaster recovery, latenza più elevata

Suggerimenti

• Posizionare il database vicino alla base di utenti principale.
• Utilizzare CDN per i contenuti statici.
• Implementare il caching a livello di applicazione.
• Considerare i requisiti di residenza dei dati.

Ottimizzazione della larghezza di banda

• Utilizzare le proiezioni per limitare il trasferimento dei dati.
• Implementare la paginazione per gli insiemi di risultati di grandi dimensioni.
• Comprimere i dati a livello di applicazione.
• Utilizzare operazioni di massa per ridurre i viaggi di andata e ritorno.

Le migliori pratiche di pooling delle connessioni

// Node.js example
const client = new MongoClient(uri, {
  maxPoolSize: 50,
  minPoolSize: 10,
  maxIdleTimeMS: 30000,
  serverSelectionTimeoutMS: 5000,
  socketTimeoutMS: 45000
});