Interpréter correctement les données de monitoring : CPU, RAM, Load et I/O

Je montre comment interpréter le monitoring pour que le CPU, la RAM, la charge et les E/S fournissent rapidement des indications pertinentes. Je détecte ainsi rapidement les goulots d'étranglement, j'identifie correctement les pics et je prends des mesures directes pour Performance et de la disponibilité.

Points centraux

• Noyaux du CPU correctement prendre en compte : Toujours mettre en relation l'utilisation et la charge avec le nombre de noyaux.
• RAM et swap lire : L'augmentation de la consommation et l'activité de swap mettent en garde contre les ralentissements.
• Charge moyenne peuvent indiquer un problème : Une charge élevée avec IOwait indique des goulots d'étranglement au niveau de la mémoire ou des disques.
• Métriques d'E/S vérifier : %util, await et IOPS indiquent la saturation et les files d'attente.
• Bases utiliser les données : cibler et affiner les tendances, les seuils et les alarmes.

Classer correctement l'utilisation du CPU

J'évalue les CPU-En effet, 75 % sur 4 cœurs ne signifie pas la même chose que 75 % sur 32 cœurs. Si la charge se maintient plus longtemps au-dessus de 80 %, je prévois soit des optimisations dans le code, soit des capacités supplémentaires. En plus de la charge totale par noyau, je vérifie les moyennes de charge sur 1, 5 et 15 minutes afin de séparer les courtes pointes des charges permanentes. Avec top/htop, je détecte immédiatement les points chauds et j'utilise pidstat pour isoler les processus individuels avec des temps de CPU remarquables. Si des valeurs élevées persistantes indiquent des requêtes inefficaces, je me concentre sur les index de la base de données, la mise en cache et l'utilisation de la mémoire tampon. Profilage.

Métriques	Zone saine	signal d'alarme	Prochaine étape
Utilisation du CPU	moins de 80 %	plus de 85 % persistant	Trouver les hotspots, optimiser le code/les requêtes, ajouter des noyaux si nécessaire
Charge moyenne	sous le nombre de noyaux	sur les noyaux (5/15 min.)	Vérifier la liste des processus, clarifier IOwait, réduire les files d'attente

En outre, je distingue utilisateur-, système-, irq/softirq- et voler-temps de fonctionnement. Si system ou softirq augmente nettement, le travail du noyau ou des pilotes (réseau/stockage) consomme la cadence. Si steal croît sur des machines virtuelles, je suis en concurrence avec des voisins sur le même hôte ; je clarifie alors une Noisy-Neighbor-ou déplacer des charges de travail. Les parts Nice indiquent que les tâches sont délibérément peu prioritaires. L'accumulation de Commutateurs contextuels ou si l'entrée de la file d'attente d'exécution augmente dans vmstat, je vérifie la contention de verrouillage, les pools de threads trop petits ou un parallélisme trop important.

• Contrôle rapide du CPU : clarifier utilisateur vs système, vérifier le steal (cloud !), identifier les hotspots pro-core.
• Thermique et fréquence : l'étranglement se manifeste par des températures élevées et une baisse de la fréquence d'horloge - inclure le refroidissement et les réglages de puissance.
• L'hyper-threading : Je planifie la charge de travail de manière conservatrice, car les threads logiques ne remplacent pas les cœurs complets.

Comprendre la RAM, le cache et le swap

Je fais la distinction entre les RAM, Cache/tampon et mémoire libre, car Linux utilise activement la mémoire libre comme cache. Cela devient problématique lorsque les applications remplissent constamment la mémoire vive et que la permutation commence. Une activité d'échange régulière ralentit le système, car les accès au disque dur dur durent nettement plus longtemps que ceux à la RAM. Si l'utilisation de la mémoire augmente continuellement pendant des heures, je vérifie s'il y a des fuites de mémoire et j'observe les Page Faults comme signal de pression. Si nécessaire, j'augmente la RAM, j'optimise le Garbage Collection ou je réduis l'empreinte de chaque disque. Services.

Métriques	Zone saine	signal d'alarme	Mesure
Utilisation de la RAM	moins de 80 %	plus de 85 %, augmentation constante	Analyse des fuites, réglage de la mémoire cache, extension de la RAM si nécessaire
Utilisation du swap	moins de 10 %	activité régulière	Réduire les besoins de stockage, ajuster le swappiness, un stockage plus rapide
Page Faults	faible/continue	pics soudains	Agrandir le hotset, renforcer la mise en cache, alléger les requêtes

En outre, j'observe THP (Transparent Huge Pages), la localité NUMA et le tueur d'OOM. Le THP peut déclencher des compactages dans les charges de travail sensibles à la latence ; je teste donc si un ajustement est judicieux. Pour les systèmes NUMA, je fais attention à l'irrégularité des Lieu de stockage par socket de CPU. Si le tueur d'OOM résout des processus, la réserve était épuisée - je vérifie les limites, les fuites et les vm.overcommit-paramètres. Avec zram/zswap, je peux atténuer la pression si les médias sont suffisamment rapides, mais je donne toujours la priorité à la cause (footprint) plutôt qu'à la lutte contre les symptômes.

• Ajuster finement le swappiness : éviter un swapping agressif, mais ne pas évincer le cache de page trop tôt.
• Tirer régulièrement des profils de tas et de GC ; comparer la consommation des pics après les déploiements.
• Définir des limites de mémoire (conteneurs/services) avec headroom pour éviter les hard kills.

Lire clairement le Load Average

Je lis le Charge comme mesure de la demande : il compte les processus en cours d'exécution ou en attente de ressources. Une valeur de 1,0 signifie une pleine utilisation sur un seul cœur, alors que sur 8 cœurs, 1,0 signifie à peine une charge. Si la charge de 5 ou 15 minutes dépasse le nombre de cœurs, je vérifie immédiatement s'il n'y a pas d'IOwait ou de processus bloqués derrière. Si le CPU est libre et que la charge est malgré tout élevée, cela indique souvent des goulots d'étranglement I/O ou un verrouillage. Pour les erreurs d'interprétation typiques, j'utilise l'aperçu dans Interpréter la charge moyenne, pour que je puisse calculer proprement le nombre de noyaux calibrer.

Je remarque que les E/S non interruptibles (D-State) augmentent la charge, même si le CPU ne fait pas grand-chose. C'est pourquoi je corrèle la charge avec vmstat (r/b) et la liste des processus, y compris les états. De brefs pics de charge dans une fenêtre d'une minute sont souvent inoffensifs ; une augmentation dans une fenêtre de 15 minutes signale une saturation structurelle. En règle générale, la file d'attente d'exécution et la charge doivent rester en moyenne inférieures au nombre de noyaux ; j'atténue les dérives temporaires par une mise en mémoire tampon, un backpressure et un Batching.

Rendre les E/S et IOwait visibles

Je considère E/S avec iostat -x : %util montre à quel point un appareil est chargé et await révèle le temps d'attente moyen par requête. Si %util s'approche durablement de 100 % ou si les valeurs await atteignent des dizaines de millisecondes, les accès s'accumulent. Iotop m'aide à identifier les processus individuels avec une charge d'E/S élevée, tandis que vmstat révèle la part d'IOwait avec la colonne wa. Un IOwait élevé avec une CPU modérée indique une saturation du disque ou une latence de stockage. Je résume les détails des causes et des contre-mesures dans Comprendre IOwait pour que je puisse gérer les goulots d'étranglement au bon endroit. dissolution.

Métriques	Signification	Seuil	Mesure
%util	Utilisation des appareils	plus de 90 %	Répartition de la charge, SSD/NVMe plus rapides, réglage de la file d'attente
await	Temps d'attente/requête	croissant/haut	Renforcer le cache, compléter les index, réduire la latence du stockage
IOPS	Opérations/sec.	Saturation visible	Optimisation du débit, batch, asynchrone travaillent

J'évalue également les taux d'écriture via Writeback et les dirty pages. Si les taux de dirty_background/dirty_ratio augmentent, le système retarde les flushs - ce qui peut générer des pics de latence. La journalisation et les reconstructions RAID se traduisent par une part élevée de système/wa sans charge applicative correspondante. Je vérifie si les goulots d'étranglement se situent au niveau du système de fichiers (options de montage, profondeur de file d'attente, ordonnanceur) ou du périphérique sous-jacent, et si les réseaux LVM/RAID chargent les différents appareils de manière inégale. En cas de pleine charge, je procède à une mise à l'échelle verticale (support plus rapide) ou horizontale (sharding, réplicas).

• Mesures immédiates à prendre : Renforcer la couche de cache avant la DB, resserrer les index, agrandir le hotset en RAM.
• Lisser le chemin d'écriture : Vérifier les tailles de lots, le commit asynchrone, les intervalles de points de contrôle.
• Vérifier le système de fichiers : inodes libres, fragmentation, définir les options de montage (noatime) en fonction des besoins.

Reconnaître les interactions : Interaction entre CPU, RAM et E/S

Je considère toujours les systèmes de manière globale, car Métriques s'influencent mutuellement. Une charge élevée avec une CPU faible indique souvent des opérations d'E/S bloquantes, tandis qu'une CPU élevée avec une charge constante indique des tâches de calcul intensives. Si la pression de la RAM augmente, les données migrent vers le swap et provoquent soudainement une charge d'E/S et de longs temps d'attente. Inversement, une mise en cache ciblée réduit la charge E/S et diminue ainsi la charge et les pics de CPU. Il en résulte une image claire qui me permet de prendre des mesures à l'endroit le plus efficace. approches.

Évaluer correctement les métriques de réseau

Je classe Réseau-Je vérifie le débit, la latence, les erreurs et les connexions des signaux. Un débit élevé avec une latence stable n'est pas critique ; si des retransmissions, des drops ou des erreurs se produisent, je recherche les goulots d'étranglement au niveau de la carte réseau, du pilote, du commutateur ou de l'application. Avec ss -s, je détecte les listes pleines (ESTAB, SYN-RECV), les inondations de timewait et un backlog épuisé. Sar -n me montre p/s, err/s, drop/s ; ethtool/nstat révèle les erreurs de NIC et les problèmes de déchargement. Je mesure les recherches DNS séparément, car la résolution lente des noms ralentit l'ensemble des requêtes.

• Retransmissions élevées : vérifier la MTU/fragmentation, ajuster les tampons (rmem/wmem) et le déchargement, analyser le chemin de latence.
• Backlog SYN plein : augmenter le backlog, vérifier les limites de taux, Pooling de connexions optimiser.
• Voir les aberrations dans P95/P99 : Nagle/Delayed ACK, négociation TLS, Keep-Alive et réutilisation de sessions.

Prendre en compte la virtualisation et les conteneurs

Dans les VM, j'observe voler, La contention de l'hyperviseur „vole“ visiblement le CPU. Je prévois un espace de tête supplémentaire ou j'isole les charges de travail critiques. Dans les conteneurs, les limites de cgroup sont décisives : cpu.max/cpu.shares contrôlent l'équité, memory.max et les événements oom-kill montrent des limites strictes. Le throttling est reconnaissable dans pidstat/Top comme un temps d'attente élevé, bien qu'il y ait suffisamment de cœurs. Je mesure par conteneur/pod, pas seulement au niveau de l'hôte, et je corrèle les limites, les requêtes et les performances réelles. Utilisez. Node-Pressure (PSI) m'aide à voir rapidement la pression à l'échelle du système.

Tendances, lignes de base et saisonnalité

Je crée pour le CPU, la RAM, le Load et les I/O une Ligne de base par heure de la journée et par jour de la semaine, afin que je puisse distinguer les modèles normaux des vraies anomalies. Les tâches cron répétitives, les sauvegardes ou les tâches analytiques provoquent des pics planifiables que je marque séparément. Pour les valeurs aberrantes, j'utilise les moyennes mobiles et les 95e percentiles pour réduire les faux positifs. Une fois par semaine, j'adapte les seuils lorsque le comportement des utilisateurs change. Pour la visualisation, j'utilise des outils éprouvés. Outils de surveillance, Les médias sont des outils qui permettent de comprendre les tendances et de prendre des décisions. raccourcissent.

Je complète les baselines avec Marqueurs de déploiement et les événements commerciaux (campagnes, sorties) pour évaluer les variations de charge. Je tiens compte de la saisonnalité sur une base quotidienne, hebdomadaire et mensuelle ; je choisis des rollups (1m, 5m, 1h) de manière à ne pas lisser les pics. En cas de fortes variations de charge, j'évalue p95/p99 sur des plages horaires afin que les „longues queues“ restent visibles.

Définir des seuils et des alarmes de manière judicieuse

Je définis les alarmes de manière à ce qu'elles déclenchent une action et pas seulement un volume sonore, car la qualité l'emporte sur la quantité. Quantité. Pour le CPU, j'utilise par exemple >80 % sur cinq minutes, pour la RAM >85 % et pour Load >Core sur 15 minutes. J'active l'alerte IOwait lorsque wa croît dans vmstat au-delà des lignes de base définies. Je combine avertissement et critique afin de pouvoir réagir avant l'escalade. Je relie chaque signal à un runbook qui explique la première étape et le temps de réaction. économise.

Je regroupe les alarmes par cause plutôt que par symptôme : un problème de stockage génère de nombreuses alarmes de suivi (CPU idle, charge élevée, timeouts) - je les déduplique en un Incident. Les alertes multi-conditions (par ex. charge > noyaux ET IOwait augmenté) réduisent le bruit. Les fenêtres de maintenance et les mises en sourdine font partie du processus, tout comme le suivi : je règle les seuils après chaque incident et je documente des critères de sortie clairs par alarme.

Diagnostiquer rapidement les images d'erreur

Je reconnais les fuites de mémoire à l'augmentation lente de la vitesse d'écriture. Utilisation de la mémoire, qui ne revient pas après les déploiements. Les index de base de données manquants se trahissent par une charge d'E/S élevée, des valeurs d'attente croissantes et des requêtes qui restent bloquées dans la liste des processus. Les pics de CPU dus à des boucles ou à des problèmes de regex apparaissent souvent directement après des événements de trafic et persistent jusqu'au redémarrage. Les volumes pleins se manifestent auparavant par une file d'attente d'E/S croissante et un débit décroissant ; les nettoyer à temps permet d'éviter les pannes. Je constate la latence du réseau par des temps de réponse plus longs pour un profil CPU/RAM par ailleurs normal et je corrèle cela avec des métriques sur Réseau-niveau.

Échantillons supplémentaires :
- Steal haut dans les VM : Noisy Neighbor ou hôtes surbookés - isoler ou déplacer la charge de travail.
- Pauses GC: CPU descend, latence élevée, courts plateaux stop-the-world - ajuster les paramètres heap/GC.
- Compaction THP: le temps du système augmente, pics de latence - vérifier le mode THP.
- Pointes de Writeback: await/wa élevé, surtout pour les checkpoints - lisser la stratégie de flux/checkpoint.
- Épuisement du pool: pools de connexions ou de threads pleins, nombreuses requêtes en attente - réajuster la backpressure et les limites.
- Ports éphémères ou Limites FD atteint : les nouvelles connexions échouent - augmenter sysctl/ulimits et activer le reuse.

Planification des capacités et gestion prévisionnelle des coûts

Je planifie les capacités à partir des données de tendance afin de pouvoir cibler les mises à niveau. timing-en fonction des besoins. Si le CPU au 95e percentile croît de 10 % par mois, je calcule le point où les alarmes se déclenchent régulièrement. Pour la RAM, j'évalue la marge de manœuvre restante jusqu'au swap et la manière dont la mise en cache réduit les besoins. Pour les E/S, je calcule la valeur await la plus élevée qui soit encore acceptable et je donne la priorité aux investissements dans des supports plus rapides avant de passer à l'échelle de manière effrénée. C'est ainsi que je maintiens des systèmes fiables et des coûts planifiables, au lieu d'opter à court terme pour un système à haute capacité. Goulots d'étranglement de réagir.

Je tiens compte des effets de file d'attente : A partir de ~70-80 % de charge, les latences augmentent de manière disproportionnée ; je prévois donc marge pour les pics. Des tailles correctes au lieu d'un surprovisionnement réduisent les coûts : mise à l'échelle par petits niveaux, combinaisons spot/reserved, et désactivation des ressources inutilisées. J'élargis horizontalement lorsque l'absence d'état est assurée ; verticalement lorsque la latence est inférieure aux chemins critiques ou lorsque le sharding serait trop complexe.

Pile d'outils : top, vmstat, iostat, pidstat

Je démarre avec top/htop pour classer les processus par CPU, RAM et État pour trier et voir les valeurs aberrantes. Ensuite, je lis vmstat pour la file d'attente d'exécution (r), les processus bloqués (b), IOwait (wa) et les commutateurs de contexte (cs). Avec iostat -x, j'évalue %util, await, r/s et w/s par périphérique afin de détecter rapidement la saturation. Pidstat m'indique avec précision les temps de CPU, les E/S et les changements de contexte, ce qui est indispensable pour les hôtes partagés. En outre, je rassemble les chiffres clés par agent dans un tableau de bord afin de pouvoir suivre les tendances sur plusieurs jours. comparer avec.

Je complète en fonction des besoins :
- sar pour les données historiques du système (CPU, RAM, réseau, périphériques en bloc).
- ss et les statistiques de Netlink pour les sockets, les backlogs et les retransmissions.
- parfait/Outils basés sur eBPF pour des analyses hotpath profondes sans frais généraux importants.
- strace sélectif en cas de suspicion de syscall, pour rendre les bloqueurs visibles.
- fio en staging, afin de mesurer des profils de stockage réalistes et d'en déduire des valeurs cibles.

Relier les métriques aux logs et aux traces

J'associe Métriques avec des logs et des traces distribuées via des corrélations : ID de requête, balises de service et de version, région et nœud. Je trouve ainsi le passage d'une latence élevée à une requête concrète et lente ou à des dépendances externes erronées. Je marque les déploiements dans le tableau de bord, ce qui me permet d'identifier les régressions en quelques secondes. Je complète les taux d'erreur (Rate) et la saturation (Saturation) par des percentiles de latence, ce qui permet d'obtenir des résultats clairs. SLOs avec des alertes qui reflètent directement l'expérience de l'utilisateur.

Guide pratique pour les 30 prochains jours

Je définis clairement en semaine 1 Bases et je marque les tâches régulières comme les sauvegardes ou les rapports. Au cours de la deuxième semaine, je mets en place des alertes et des runbooks qui décrivent la première intervention par signal. La troisième semaine, j'optimise les principaux pilotes : requêtes lentes, index manquants, sérialisations inutiles ou caches trop petits. Au cours de la quatrième semaine, je vérifie comment la répartition de la charge a évolué et j'adapte les capacités ou les limites en conséquence. Il en résulte un cycle répétitif qui fait passer le monitoring d'une observation réactive à une action orientée vers l'avenir. Impôts fait.

Je teste activement les alarmes (Game Day) : charge artificielle, mémoire limitée, E/S réduites - toujours avec un rollback. J'affine les runbooks avec des points de mesure clairs („si charge > noyaux ET wa élevé, alors ...“). J'effectue des mini-postmortems hebdomadaires, même sans incident, pour assurer les gains d'apprentissage et Bruit de réduire les risques. À la fin des 30 jours, on obtient des tableaux de bord robustes, des seuils propres et une équipe qui sait comment réagir de manière ciblée.

En bref

Je lis Suivi-J'analyse systématiquement les données de charge dans le contexte des cœurs du CPU, de l'utilisation de la mémoire, des moyennes de charge et des indicateurs d'E/S. Un CPU élevé dans le temps, une utilisation croissante de la RAM, une charge sur les noyaux et un IOwait constituent mes principaux candidats à l'alerte. Avec top, vmstat, iostat, pidstat et des tableaux de bord clairs, j'identifie des modèles et je choisis la vis de réglage la plus efficace. Les lignes de base, les seuils judicieux et les runbooks transforment les chiffres en actions concrètes et rapides. Je peux ainsi interpréter la surveillance, éviter les goulets d'étranglement et offrir une expérience utilisateur fiable. sécuriser.