Pour maintenir une instance Lindorm en bon état de fonctionnement, suivez les bonnes métriques avant que des problèmes n'apparaissent. Ce guide explique ce que mesure chaque métrique, quelles valeurs indiquent un dysfonctionnement et les actions à entreprendre lorsqu'un seuil est dépassé.
Trouver la métrique adaptée à votre situation
La plupart des administrateurs arrivent ici avec un symptôme précis, plutôt qu'avec le nom d'une métrique. Utilisez ce tableau pour accéder directement à la section pertinente.
| Si vous observez... | Vérifiez |
|---|---|
| Une augmentation du temps de réponse (RT) en lecture ou en écriture | CPU et charge, Charge du cluster |
| Des délais d'expiration (timeouts) ou des rejets d'écriture | Requêtes d'écriture, Charge du cluster |
| Un bridage des E/S réseau ou disque | Réseau et disque |
| Un stockage saturé ou des écritures bloquées | Stockage du cluster |
| Des erreurs de mémoire insuffisante ou des événements Full GC | Charge du cluster |
| Des analyses lentes ou un RT d'analyse élevé | Requêtes de lecture |
Métriques système
CPU et charge
Éléments à surveiller : utilisation du CPU, taux d'inactivité du CPU, utilisation WIO du CPU et charge moyenne.
L'utilisation du CPU se décompose en CPU utilization User(%) (processus en espace utilisateur) et CPU utilization System(%) (processus en espace noyau).
Seuil d'alerte
Utilisez CPU idle rate(%) comme métrique d'alerte principale plutôt que l'utilisation globale du CPU. L'impact d'une utilisation élevée du CPU varie selon la charge de travail :
Les charges de travail en ligne (sensibles à la latence) peuvent subir une dégradation lorsque l'utilisation du CPU dépasse 40 %.
Les charges de travail par lots hors ligne peuvent tolérer une utilisation du CPU de 100 % sans problème.
Définissez le seuil d'alerte en fonction du point auquel votre charge de travail spécifique commence à rencontrer de la latence, plutôt que de vous fier à une valeur fixe.
Lorsque les ressources CPU sont insuffisantes, mettez à l'échelle ou mettez à niveau l'instance. Consultez également Modifier la configuration d'une instance.
Diagnostic des goulots d'étranglement CPU vs disque
Deux métriques permettent de distinguer la pression exercée sur le CPU de celle exercée sur le disque :
CPU WIO usage(%): Pourcentage de temps pendant lequel le CPU attend les opérations d'E/S. Une valeur élevée indique un goulot d'étranglement en lecture/écriture sur le disque.
Average load per minute(load1): Reflète l'utilisation combinée du CPU et du disque.
Analysez ces deux indicateurs conjointement. Une valeur de charge acceptable est approximativement égale au nombre de cœurs CPU ; pour une machine à 8 cœurs, une charge supérieure à 8 signifie que les tâches s'accumulent dans la file d'attente et que la machine fonctionne dans un état sous-optimal. Si l'utilisation du CPU est faible mais que la charge est élevée, le goulot d'étranglement provient des E/S disque.
Lorsque la charge CPU ou l'utilisation WIO est trop élevée, mettez à l'échelle ou mettez à niveau l'instance.
Réseau et disque
Éléments à surveiller : trafic réseau, débit de lecture/écriture sur disque et IOPS.
Maintenez toutes les valeurs en dessous des seuils de bridage des instances Elastic Compute Service (ECS) sous-jacentes et des disques cloud. Les disques ECS non locaux possèdent une limite de bande passante combinée en lecture/écriture ; le dépassement de cette limite déclenche un bridage qui affecte les opérations métier.
Seuils de bridage
Les limites de bande passante réseau ECS varient selon le type d'instance. Consultez Présentation des familles d'instances. Pour les limites de disque, reportez-vous à Performances du stockage par blocs.
Associez votre type de stockage Lindorm aux paramètres de performance ECS appropriés :
| Type de stockage Lindorm | Paramètres de performance ECS à consulter |
|---|---|
| Stockage performant | SSD |
| Stockage standard | ESSD |
| Disque local | Disque local |
Pour toute question concernant les limites réseau et disque, contactez le support technique Lindorm (ID DingTalk : s0s3eg3).
Stockage du cluster
Éléments à surveiller : Storage (hot storage) water level(%) et Cold storage water level(%).
| Seuil | Niveau | Action |
|---|---|---|
| 75 %–80 % | Seuil d'alerte | Mettre rapidement à l'échelle l'instance |
| 95 % | Seuil critique | Le système bloque automatiquement toutes les opérations d'écriture |
Configurez des alertes entre 75 % et 80 % afin de disposer d'une marge de manœuvre suffisante avant que le système n'atteigne le seuil de blocage des écritures à 95 %. Lorsque le stockage atteint le niveau d'alerte, augmentez immédiatement la capacité pour éviter une interruption des écritures.
Métriques LindormTable
Charge du cluster
Utilisation de la mémoire
Métrique : LindormTable compute node memory usage ratio(%)
Il s'agit du rapport entre la mémoire heap actuellement utilisée par LindormTable et la taille totale allouée. La taille de la heap fluctue naturellement ; les pics de courte durée sont gérés par le garbage collection (GC). Une utilisation élevée et soutenue constitue le véritable sujet de préoccupation.
Règle d'alerte : Déclenchez l'alerte lorsque ce ratio dépasse 85 %–90 % pendant 30 à 60 minutes consécutives.
Lorsque l'utilisation de la heap reste constamment élevée, mettez à niveau les spécifications des nœuds LindormTable pour augmenter la mémoire disponible. Consultez Modifier la spécification du moteur d'une instance.
Nombre de shards
Métrique : Number of regions of RS (unit)
LindormTable divise les tables en shards de données (Regions) et les répartit sur les nœuds. Chaque shard consomme de la mémoire pour les métadonnées, de sorte qu'un nombre excessif de shards engendre une pression sur la mémoire.
Limites de référence selon la mémoire du nœud :
| Mémoire du nœud | Nombre maximal de shards recommandé |
|---|---|
| 8 Go | < 500 |
| 16 Go | < 1 000 |
| 32 Go | < 2 000 |
| 64 Go | < 3 000 |
| 128 Go | < 5 000 |
Ces valeurs constituent des points de départ. Pour une évaluation plus précise, vérifiez le ratio réel de mémoire : Used memory / Total memory du nœud de calcul LindormTable. Si le nombre de shards est trop élevé, réduisez-le en diminuant le nombre de tables ou en réduisant le nombre de pré-partitions lors de la création des tables.
Mise en file d'attente des requêtes
Métrique : HandlerQueue Length (unit)
Cette métrique indique le nombre de requêtes en attente dans la file d'attente pour obtenir un thread serveur. Toute valeur supérieure à 0 signifie que le serveur ne peut pas traiter les requêtes assez rapidement.
Une HandlerQueue persistamment non nulle indique une insuffisance des ressources CPU. Mettez à niveau la configuration de l'instance pour ajouter de la capacité CPU.
Mise en file d'attente de la compaction
Métrique : Compaction Queue Length (units)
La compaction consolide les fichiers de données au sein des shards. Les charges de travail intensives en écriture génèrent naturellement davantage de tâches de compaction, qui peuvent s'accumuler dans la file d'attente.
Toute mise en file d'attente ne constitue pas nécessairement un problème. Les charges de travail présentant des pics prévisibles (actives le jour, calmes la nuit) peuvent accumuler des tâches de compaction pendant les heures de pointe et vider la file d'attente durant la nuit — ce comportement est sain. De même, une file d'attente qui reste stable à une valeur fixe indique un état d'équilibre et ne nécessite aucune intervention.
Quand intervenir : Si la file d'attente augmente continuellement sans tendance à la baisse, l'instance manque de ressources pour suivre la cadence. Ajoutez des nœuds ou mettez à niveau la configuration CPU.
Les retards de compaction à court terme n'affectent ni les lectures ni les écritures. En revanche, les retards à long terme ont un impact : un plus grand nombre de fichiers de données par shard peut augmenter le temps de réponse en lecture (RT). À terme, un shard peut accumuler suffisamment de fichiers pour déclencher une contre-pression en écriture, entraînant une augmentation du RT en écriture, voire des délais d'expiration (timeouts).
Fichiers par shard
Deux métriques connexes permettent de suivre l'accumulation de fichiers dans les shards :
Average number of files in Region: Des valeurs plus élevées augmentent le RT en lecture. Un nombre excessif de fichiers accroît également la pression sur la mémoire et risque de déclencher un Full GC ou une erreur OOM (Out Of Memory).
Maximum number of files in Region: Lorsque cette valeur dépasse la limite, l'instance applique une contre-pression en écriture, provoquant des délais d'expiration. Consultez Limites des requêtes de données.
Surveillez ces indicateurs conjointement avec Compaction Queue Length ; des comptes de fichiers élevés découlent généralement de retards de compaction soutenus.
Requêtes de lecture
LindormTable expose les métriques de lecture à trois niveaux : par type d'opération (Get, Scan) et en agrégat (Read).
Opérations Get
| Métrique | Ce qu'elle mesure |
|---|---|
| Get requests (pieces/second) | Débit des requêtes ponctuelles (QPS) |
| Get Average RT (ms) | Temps de réponse moyen pour les opérations Get |
| Get P99 RT (ms) | Temps de réponse au 99e percentile pour les opérations Get |
Une requête ponctuelle utilise une clé primaire complète pour récupérer une seule ligne. BatchGet s'exécute de manière sérielle sur un seul serveur ; quel que soit le nombre de lignes récupérées, cela compte comme un seul appel de requête ponctuelle. Cela signifie que Get Average RT reflète la durée de BatchGet, qui est supérieure au RT d'un Get sur une seule ligne lorsque les opérations BatchGet sont fréquentes.
Opérations Scan
| Métrique | Ce qu'elle mesure |
|---|---|
| Scan requests (pieces/second) | Débit des sous-analyses après division côté serveur |
| Scan Average RT (ms) | Temps de réponse moyen par sous-analyse |
| Scan P99 RT (ms) | Temps de réponse au 99e percentile par sous-analyse |
Lindorm divise les analyses de grandes plages en sous-analyses et renvoie les résultats sous forme de flux. Scan requests (pieces/second) compte les sous-analyses par seconde, et non le nombre de requêtes client d'origine. Le temps total pour une analyse complète correspond à la somme des durées de toutes ses sous-analyses.
Métriques de lecture agrégées
| Métrique | Ce qu'elle mesure |
|---|---|
| Read Requests (s/sec) | Débit total de lecture (lignes par seconde, couvrant à la fois Get et Scan) |
| Read Average RT (ms) | Temps moyen pour renvoyer une ligne de données |
| Read traffic | Volume total de données lues |
Ces métriques couvrent à la fois les opérations Get et Scan et mesurent le débit au niveau des lignes. Étant donné qu'une seule opération Get ou Scan peut renvoyer plusieurs lignes, ces indicateurs reflètent le débit de lecture réel plus précisément que le simple comptage des opérations.
Requêtes d'écriture
Débit d'écriture
Métrique : Write traffic (unité : Ko/s)
Il s'agit du volume réel de données écrites dans le stockage sous-jacent de LindormTable. Étant donné que les colonnes des tables larges sont converties en paires clé-valeur lors du stockage, le volume de données stockées est supérieur aux données réellement écrites par le client.
Un débit d'écriture élevé accroît la pression sur la compaction. Utilisez ces recommandations comme point de départ, puis ajustez-les en fonction de Compaction Queue Length, Average number of files in Region et Maximum number of files in Region :
| Cœurs CPU | Débit d'écriture maximal recommandé |
|---|---|
| 4 | < 5 Mo/s |
| 8 | < 10 Mo/s |
| 16 | < 30 Mo/s |
| 32 | < 60 Mo/s |
Si le débit d'écriture dépasse systématiquement ces limites, ajoutez des ressources CPU pour maintenir la compaction à jour.
Pression sur MemStore
Métrique : Number of times exceeding the upper limit of Memstore (times)
LindormTable écrit d'abord les données dans un MemStore (tampon en mémoire), puis les vide sur le disque. Lorsque le trafic d'écriture se concentre sur un petit nombre de shards, les MemStores de ces shards se remplissent plus vite qu'ils ne peuvent être vidés, provoquant une contre-pression en écriture qui réduit le débit.
Toute valeur supérieure à 0 mérite une investigation :
Point chaud d'écriture : Les écritures sont concentrées sur quelques plages de clés primaires. Redéfinissez la clé primaire en utilisant un algorithme de hachage pour répartir les écritures plus uniformément. Consultez Concevoir les clés primaires pour les tables larges Lindorm.
TPS dépassant la capacité de l'instance : Le taux d'écriture total a dépassé ce que l'instance peut gérer. Mettez à l'échelle ou ajoutez des nœuds.