Service ▸ Base de données

Vue d’ensemble — ce que fait cet écran

Service ▸ Base de données (/service/database) est un écran de supervision en direct qui se connecte directement aux collecteurs de base de données enregistrés (access=database) afin d’échantillonner des métriques de charge et d’analyser la structure du schéma. Chaque base de données est rendue sous forme d’une carte, et chaque carte expose deux axes de charge d’un coup d’œil.

La supervision des bases de données s’articule autour de deux axes de charge :

À cela s’ajoutent l’analyse du schéma (taille totale · plus grosses bases · plus grosses tables · répartition des moteurs), les scores d’efficacité (taux de succès du cache du buffer pool · utilisation des index) et un bloc de gestion mémoire InnoDB (vidage des pages sales · checkpoint).

Cet écran n’installe aucun agent sur la base cible. L’application InfraGuard se connecte simplement au MySQL/MariaDB distant avec les identifiants enregistrés et exécute des requêtes SHOW GLOBAL STATUS / information_schema.

Quand l’utiliser

• Une base de données est devenue lente d’un coup : déterminer immédiatement si les connexions ont saturé, si la concurrence a explosé ou si les requêtes lentes se sont multipliées.
• Avant et après un réglage du pool de connexions : observer dans le temps la saturation de threads_connected / max_connections.
• Planification de capacité : voir quels schémas ou tables consomment le plus de disque, et la répartition des moteurs.
• Diagnostic de la pression de vidage InnoDB : savoir si les pages sales circulent sainement sous le seuil, et jusqu’où l’âge du checkpoint a progressé par rapport à la capacité du redo.
• Revue de l’efficacité du cache et des index : lire le taux de succès du buffer pool et l’utilisation des index comme éléments de réglage.

Disposition

Indicateurs du haut

En-tête de carte

• Libellé de l’hôte (host_alias du collecteur → config.host → hôte env de cred_ref, dans cet ordre).
• Pilote (mysql/mariadb), nom de la base, durée de fonctionnement, badge d’état.

① Charge de concurrence

• Jauge annulaire de saturation des connexions = threads_connected / max_connections.
• Running (threads_running) — threads qui consomment réellement du CPU.
• Waiting (accumulation) (waiting) — requêtes dont le temps de traitement dépasse le seuil (2 s par défaut). Selon le privilège PROCESS, ce décompte porte sur tout le serveur ou uniquement la connexion courante (la portée est affichée sur la carte).

② Débit et inefficacité

• Sparkline QPS = Δquestions / Δt (60 derniers échantillons réussis).
• Taux de requêtes lentes = Δslow_queries / Δt, ainsi que le total des requêtes lentes (slow_queries).

Pied de carte — efficacité · verrous

Chaque libellé de métrique (cache · index · lock · checkpoint) porte un popover pédagogique qui explique les causes et les remèdes (par exemple augmenter innodb_buffer_pool_size, utiliser des index couvrants, éviter les verrous d’intervalle).

Analyse du schéma (repliable)

Repliée par défaut, elle s’ouvre avec [Déplier]. Agrégée depuis information_schema.tables, elle affiche la taille totale · le nombre de tables · le nombre de schémas · les 8 plus gros schémas par taille · les 14 plus grosses tables par taille · la répartition des moteurs.

L’analyse du schéma est par nature une requête lente côté serveur (mesurée à ~3,5 s), elle est donc contournée par un cache long de 30 minutes. L’ordonnanceur (infr:collect-db) préchauffe le cache, si bien que les requêtes web le trouvent toujours. Quand le cache est vide, la section est brièvement masquée puis apparaît au sondage suivant.

Gestion mémoire InnoDB (vidage des pages sales)

• Série temporelle des pages sales plus une superposition de « valeur adéquate » (seuil) — MAX (innodb_max_dirty_pages_pct) et LWM (innodb_max_dirty_pages_pct_lwm) convertis en nombres de pages absolus (non pas des constantes arbitraires, mais le point où InnoDB commence réellement à vider de manière agressive).
• Âge du checkpoint (Log sequence number − Last checkpoint at) en pourcentage de la capacité du redo.
• Taille du buffer pool et son rapport à la RAM du serveur (le mem_mb de l’instance OS jointe par alias).

Agencement des cartes

La grille de cartes prend en charge le réordonnancement par glisser-déposer (SortableJS · ordre conservé dans localStorage) avec une disposition en maçonnerie par row-span. L’écran se rafraîchit par sondage toutes les 30 secondes.

Mode d’emploi

1. Enregistrez d’abord un collecteur access=database dans Administration ▸ Collecteurs. Saisissez host/port/database/username plus le mot de passe (stocké chiffré par Crypt sur le collecteur), ou définissez cred_ref = env:PREFIX pour réutiliser un jeu d’identifiants existant du fichier .env.
2. Ouvrez /service/database ; les bases enregistrées apparaissent sous forme de cartes. À l’entrée, si le dernier échantillon date de plus de 60 secondes, un échantillon unique immédiat (ensureFresh) est prélevé.
3. Repérez la base problématique grâce au badge d’état de l’en-tête, puis affinez la cause selon les deux axes de charge (concurrence / débit).
4. Dépliez l’analyse du schéma pour inspecter les plus gros schémas et tables (la maçonnerie se réagence automatiquement au changement de hauteur).
5. Faites glisser les cartes pour remonter en haut les bases qui vous intéressent (l’ordre est enregistré dans le navigateur).

Réutiliser des identifiants via cred_ref

Avec cred_ref = env:PREFIX, les clés suivantes sont lues depuis .env, de sorte qu’aucun secret n’est stocké en base :

Par exemple : env:STATS_DB → serveur blue, env:STATS_GLORY_DB → serveur glory.

Pour voir les requêtes en attente à l’échelle du serveur

Pour agréger waiting à l’échelle du serveur, le compte de supervision doit disposer du privilège PROCESS ; sinon, seules ses propres connexions sont comptées. Un compte de supervision à privilèges minimaux :

CREATE USER 'infra_monitor'@'%' IDENTIFIED BY 'YOUR_DB_PASSWORD';
GRANT PROCESS, SELECT ON *.* TO 'infra_monitor'@'%';
FLUSH PRIVILEGES;

La décision de portée (le compte détient-il PROCESS ?) est figée par compte, elle est donc mise en cache pendant 1 heure. Si vous accordez le privilège plus tard, il prend effet dans l’heure (videz le cache pour un effet immédiat).

Sources de données

Requêtes d’origine (exécutées sur la base distante)

Table de stockage

Les données échantillonnées sont écrites dans la série temporelle infr_db_metric (migration 000681). Les compteurs cumulés (questions/slow_queries/bytes_*) sont également stockés afin que l’échantillon suivant puisse calculer par delta les QPS · le taux de requêtes lentes · les scores d’efficacité.

infr_db_metric
  collector_id  host  sampled_at  uptime_sec
  threads_connected/running/cached  max_connections  conn_pct
  waiting  waiting_scope
  questions  slow_queries  qps  slow_qps
  bytes_received/sent  recv_bps/sent_bps  innodb_row_lock_waits
  ok  message  raw(json: efficiency + InnoDB memory-management derivations)

Aucune fuite de connexion (la leçon du [1040]). Chaque échantillon crée une connexion à l’exécution puis la libère immédiatement par DB::purge dans un bloc finally. Un délai d’expiration PDO (5 s par défaut) évite que les requêtes web et l’ordonnanceur ne restent bloqués sur un hôte distant lent. Si cette discipline est rompue, le max_connections du MySQL partagé est épuisé et même la production est affectée.

Planification de la collecte · conditions

La série temporelle est alimentée par la commande artisan infr:collect-db. Elle s’exécute une fois puis se termine (ce n’est pas un démon) ; l’ordonnanceur l’invoque chaque minute.

# Prendre un échantillon immédiat pour un seul collecteur (contourner la condition)
php artisan infr:collect-db --key=db@blue --force

La politique d’exploitation (Administration ▸ Politique d’exploitation · OpsPolicy) conditionne les exécutions planifiées :

Seuils degraded/down

DbCollectorService::statusOf décide de l’état via OpsPolicy::dbThresholds().

Tout motif présent → degraded ; aucun → up.

Accès

• Cet écran est une console en lecture seule dans le groupe infr.auth — niveau de lecture minimal demo=1.
• Cette page ne comporte aucun point d’écriture. Enregistrez ou modifiez les identifiants des bases cibles dans Administration ▸ Collecteurs (admin=10, contrôle level≥5).
• Modifiez les seuils et le mode de collecte dans Administration ▸ Politique d’exploitation (admin).

Dépannage et FAQ

Une carte affiche « down »

• no_credentials — l’hôte ou le nom d’utilisateur de config est vide, ou les clés env de cred_ref=env:PREFIX sont absentes.
• stale — le dernier échantillon date de plus de 5 minutes. Vérifiez que l’ordonnanceur (infr:collect-db) tourne et, en mode economy, qu’un utilisateur de la console est présent.
• Autre message — la cause de l’échec de connexion (authentification refusée, hôte injoignable, délai dépassé) est affichée telle quelle. Diagnostiquez avec php artisan infr:collect-db --key=<key> --force.

QPS / taux de requêtes lentes / scores d’efficacité affichent « — »

Les valeurs dérivées sont calculées comme un delta par rapport à l’échantillon réussi précédent. Au premier échantillon, après un redémarrage de la base (uptime a diminué → compteur remis à zéro) ou quand un compteur régresse, la valeur n’est pas fiable et reste à null (—). Elle s’affiche normalement à partir du deuxième échantillon.

Les requêtes en attente affichent « uniquement la connexion courante »

Le compte de supervision ne dispose pas du privilège global PROCESS, si bien que seules ses propres connexions sont visibles dans information_schema.processlist. Accordez PROCESS avec le SQL de Pour voir les requêtes en attente à l’échelle du serveur (effet sous une heure, à l’expiration du cache de portée).

La section gestion mémoire / checkpoint est vide

• La gestion mémoire nécessite innodb_buffer_pool_pages_total (masquée pour les anciens échantillons).
• L’âge du checkpoint est analysé depuis SHOW ENGINE INNODB STATUS (→ nécessite PROCESS). Sans le privilège, la ligne de checkpoint et son annotation sont omises proprement.

L’analyse du schéma clignote vide puis apparaît

analysisCached est une consultation uniquement en cache. À la première entrée, le cache est vide et la section est masquée ; une fois que l’ordonnanceur l’a préchauffé, elle apparaît au sondage suivant de 30 secondes. Les échecs ne sont mis en cache que 30 s (les succès, 30 minutes), de sorte qu’une erreur passagère n’est pas figée longtemps.

Voir aussi

• Formation charge et réglage des BD — le contexte des popovers lock · cache · index · checkpoint.
• Collecteurs — enregistrement des collecteurs access=database, secrets, cred_ref.
• Politique d’exploitation — mode de collecte · intervalle · seuils de dégradation.
• Sessions (Redis) — l’écran jumeau qui applique la même méthodologie à Redis.
• Vue d’ensemble des services — là où les cartes de BD sont résumées sur le tableau des services en direct.
• Chaîne du collecteur de BD — commande de collecte et discipline anti-fuite de connexions.