Accès aux tableaux de bord de surveillance

1. Naviguez vers votre déploiement MongoDB dans la console IBM Cloud.
2. Cliquez sur Surveillance dans le menu de gauche.
3. Cliquez sur Lancer la surveillance pour ouvrir le tableau de bord Sysdig.

Principaux indicateurs à suivre :

• Mesures de la plate-forme :

  • Utilisation du processeur- objectif : < 75 % en continu
  • Utilisation des disques- objectif : < 80%
  • IOPS disque- surveiller la saturation
  • Débit du réseau- identifier les contraintes de bande passante

• MongoDB-specific métriques :

  • Opérations par seconde- suivre les modèles de charge de travail
  • Connexions actives- contrôle des limites du plan
  • Délai de réplication- cible : < 1 seconde
  • Temps d'exécution des requ êtes - identifier les requêtes lentes
  • Taux de réussite du cache- objectif : > 95%

Configuration des alertes

Créer des alertes pour les seuils critiques :

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

Création de tableaux de bord personnalisés

1. Dans Sysdig, cliquez sur Tableaux de bord > Créer un tableau de bord.
2. Ajouter des panneaux pour les indicateurs clés.
3. Utilisez des filtres pour vous concentrer sur le déploiement de votre site MongoDB.
4. Enregistrez et partagez avec votre équipe.

Exemple de présentation du tableau de bord

• Ligne 1: Utilisation de l'unité centrale, de la mémoire et du disque
• Ligne 2: Opérations par seconde, connexions actives
• Ligne 3: décalage de la réplication, performance des requêtes
• Ligne 4: statistiques de la mémoire cache, contention des verrous

Analyse historique

• Utiliser le sélecteur d'intervalle de temps pour les données historiques
• Comparer les mesures actuelles avec les mesures de référence
• Identifier les tendances et les modèles
• Établir une corrélation entre les événements et les changements de performance

Actions recommandées :

• Mettre en place des alertes avant que des problèmes ne surviennent.
• Examiner quotidiennement les tableaux de bord.
• Établir des mesures de référence.
• Documenter les schémas normaux par rapport aux schémas anormaux.
• Utiliser des indicateurs pour la planification des capacités.

Accès Activity Tracker

1. Naviguez vers Observability > Activity Tracker dans la console IBM Cloud.
2. Sélectionnez votre région.
3. Filtrez les événements en fonction de votre instance MongoDB.

Événements clés à surveiller :

• Changements de configuration :

  • Opérations de mise à l'échelle (CPU, mémoire, disque)
  • Modifications de la configuration de la sauvegarde
  • Mises à jour de la configuration du réseau
  • Modifications de l'accès des utilisateurs

• Événements ayant un impact sur les performances

  • Redémarrage de la base de données
  • Événements de basculement
  • Opérations de maintenance
  • Création et suppression d'index

Corrélation entre les événements et les problèmes de performance

1. Notez l'heure de la dégradation des performances.
2. Consultez le site Activity Tracker pour connaître les événements qui se déroulent à cette période.
3. Recherchez les changements de configuration ou les actions administratives.
4. Corrélation avec les mesures de surveillance.

Exemple d'analyse d'événement

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

Piste d'audit pour la conformité

• Suivi des modifications apportées par les personnes concernées et de leur date d'intervention
• Maintenir la conformité avec les politiques de sécurité
• Examiner les schémas d'accès
• Identifier les modifications non autorisées

Actions recommandées :

• Examinez régulièrement les journaux de Activity Tracker.
• Créer des alertes en cas d'événements critiques.
• Documenter les procédures de gestion des changements.
• Établir une corrélation entre les événements et les mesures de performance.
• A utiliser pour l'analyse post-incident.

Mise à l'échelle verticale (calcul et mémoire)

Augmenter les ressources de l'unité centrale et de la mémoire pour faire face à une charge de travail accrue.

• Utilisation de la console IBM Cloud:

  1. Naviguez vers votre déploiement MongoDB.
  2. Cliquez sur Ressources dans le menu de gauche.
  3. Ajustez les curseurs Mémoire et CPU.
  4. Examiner l'impact des coûts.
  5. Cliquez sur Echelle.

• Utilisation du CLI IBM Cloud:

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

Considérations

• Brève interruption de la connexion pendant la mise à l'échelle.
• Prévoyez un temps d'arrêt de 5 à 10 minutes.
• Réduire la taille de l'entreprise de manière proactive avant qu'elle ne soit saturée.
• Contrôler les paramètres après la mise à l'échelle.

Mise à l'échelle horizontale (membres de l'ensemble de répliques)

Ajouter des membres à l'ensemble de répliques pour l'échelonnement de la lecture et la haute disponibilité.

• Utilisation de la console IBM Cloud:

  1. Naviguer vers Ressources.
  2. Ajuster le curseur des membres.
  3. Configuration de l'examen.
  4. Cliquez sur Echelle.

• Utilisation du CLI IBM Cloud:

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

Avantages

• Répartir la charge de lecture sur les secondaires
• Amélioration de la tolérance aux pannes
• Une meilleure répartition géographique
• Pas de temps d'arrêt pour l'ajout de membres

Mise à l'échelle du stockage

Augmenter l'espace disque et l'IOPS pour de meilleures performances.

• Utilisation de la console IBM Cloud:

  1. Naviguer vers Ressources.
  2. Ajuster le curseur du disque.
  3. Réviser l'allocation d'IOPS.
  4. Cliquez sur Echelle.

• Utilisation du CLI IBM Cloud:

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

Informations importantes :

• Le stockage ne peut être qu'augmenté et non diminué
• L'IOPS s'adapte à la taille du disque
• Pas de temps d'arrêt pour la mise à l'échelle du stockage
• Surveiller les tendances de l'utilisation du disque

Meilleures pratiques de mise à l'échelle

| Augmenter la taille du disque pour augmenter le nombre d'IOPS | Les limites de connexion - Le passage à un niveau supérieur | Ajouter des membres de réplique | Ajouter des membres de réplique | La charge de travail est importante en termes d'écriture

Optimisation des coûts

• Dimensionnez votre déploiement au plus juste.
• Utiliser le suivi pour identifier les besoins réels.
• Réduire l'échelle pendant les périodes de faible trafic (si cela est possible).
• Envisager une capacité réservée aux charges de travail prévisibles.

Automatisation

# 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

Installation de IBM Cloud CLI

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

# Install databases plugin
ibmcloud plugin install cloud-databases

Commandes de diagnostic essentielles

• Obtenir des informations sur le déploiement :

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

• Vérifier l'état du déploiement :

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

• Contrôler les paramètres :

  # 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
  

• Opérations de mise à l'échelle :

  # 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
  

• Opérations de sauvegarde :

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

Utilisation de l'API IBM Cloud

• Authentification :

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

• Obtenir des mesures de déploiement à l'aide de l'API :

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

• Déploiement à grande échelle à l'aide de 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
      }
    }'
  

• Exemple de script de diagnostic :

  #!/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 ==="
  

• Recommandations en matière d'automatisation

  • Planifiez des contrôles de santé réguliers.
  • Intégrer les systèmes de surveillance.
  • Automatiser la mise à l'échelle en fonction de seuils.
  • Créer des alertes pour les mesures critiques.
  • Enregistrer toutes les opérations pour la piste d'audit.

Points d'extrémité privés (recommandé)

Avantages :

• Temps de latence réduit
• Sécurité renforcée
• Pas de frais de sortie de l'internet
• Meilleures performances pour les charges de travail IBM Cloud

Configuration :

1. Naviguez vers Paramètres > Points d'extrémité.
2. Activer le point de terminaison privé.
3. Mettre à jour les chaînes de connexion dans les applications.

Exemple de chaîne de connexion :

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

Nœuds finaux publics

Cas d'utilisation :

• Applications externes
• Développement et test
• Scénarios de nuages hybrides

Considérations de sécurité :

• Utiliser la liste d'autorisation IP.
• Appliquer TLS / SSL.
• Faites une rotation régulière des titres de compétences.

Noeuds finaux de service

IBM Cloud les points d'extrémité des services offrent une connectivité optimisée sur le site IBM Cloud.

Avantages

• Réduction du temps de latence
• Pas de traversée de l'internet public
• Amélioration de la posture de sécurité
• Réduction des coûts de la bande passante

Configuration

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

Considérations relatives au déploiement multizone

Databases for MongoDB peut s'étendre sur plusieurs zones de disponibilité.

Meilleures pratiques

• Déployer des applications dans la même région.
• Utilisez les préférences de lecture pour minimiser la latence.
• Envisager nearest lire les préférences pour les applications multizones.
• Surveiller le délai de réplication entre les zones.

Résolution des problèmes de latence du réseau

• Mesurer la latence de l'application

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

• Vérification à partir de IBM Cloud shell

  # 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 diagnostics de connexion

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

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

Répartition géographique

Pour les applications distribuées à l'échelle mondiale :

Stratégies

• Région unique: Latence la plus faible, un seul point de défaillance
• Multi-région avec répliques de lecture: Mise à l'échelle de la lecture, cohérence à terme
• Réplication interrégionale: Reprise après sinistre, latence plus élevée

Recommandations

• Placer la base de données à proximité de l'utilisateur principal.
• Utiliser le CDN pour le contenu statique.
• Mettre en place un système de mise en cache au niveau de l'application.
• Tenir compte des exigences en matière de résidence des données.

Optimisation de la bande passante

• Utilisez les projections pour limiter le transfert de données.
• Mettre en place une pagination pour les grands ensembles de résultats.
• Compression des données au niveau de l'application.
• Utiliser des opérations groupées pour réduire les allers-retours.

Meilleures pratiques en matière de mise en commun des connexions

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