Simuler les pannes d'applications JVM

Traduction Bêta Non Officielle

Cette page a été traduite par PageTurner AI (bêta). Non approuvée officiellement par le projet. Vous avez trouvé une erreur ? Signaler un problème →

Chaos Mesh simule les défaillances des applications JVM via Byteman. Les types de défaillances pris en charge sont les suivants :

• Lancer des exceptions personnalisées

• Déclencher le garbage collection

• Augmenter la latence des méthodes

• Modifier les valeurs de retour d'une méthode

• Déclencher des pannes en configurant des fichiers Byteman

• Augmenter la pression sur la JVM

Ce document explique comment utiliser Chaos Mesh pour créer des expériences JVM avec ces types de défaillances.

note

Votre noyau Linux doit être en version 4.1 ou ultérieure.

Créer des expériences avec Chaos Dashboard

1. Ouvrez Chaos Dashboard, puis cliquez sur NEW EXPERIMENT pour créer une nouvelle expérience.

   

   create a new experiment

2. Dans la section Choose a Target, sélectionnez JVM FAULT et choisissez un comportement spécifique comme RETURN. Complétez ensuite les configurations détaillées.

   

   JVMChaos experiments

   Pour savoir comment remplir ces configurations, reportez-vous à la [Description des champs] (#field-description).

3. Renseignez les informations de l'expérience, spécifiez son périmètre et sa durée planifiée.

   

   experiment information

4. Soumettez les informations de l'expérience.

Créer des expériences via des fichiers YAML

L'exemple suivant illustre l'utilisation et les effets de JVMChaos en spécifiant les valeurs de retour d'une méthode. Les fichiers YAML mentionnés sont disponibles dans examples/jvm. Le répertoire de travail par défaut est examples/jvm. L'espace de noms par défaut d'installation de Chaos Mesh est chaos-mesh.

Étape 1. Créer l'application cible

Helloworld est une application Java simple utilisée ici comme cible de test. Elle est définie dans example/jvm/app.yaml :

apiVersion: v1
kind: Pod
metadata:
  name: helloworld
  namespace: helloworld
spec:
  containers:
    - name: helloworld
      # source code: https://github.com/WangXiangUSTC/byteman-example/tree/main/example.helloworld
      # this application will print log like this below:
      # 0. Hello World
      # 1. Hello World
      # ...
      image: xiang13225080/helloworld:v1.0
      imagePullPolicy: IfNotPresent

1. Créez l'espace de noms pour l'application cible :

   kubectl create namespace helloworld

2. Déployez le Pod de l'application :

   kubectl apply -f app.yaml

3. Exécutez kubectl -n helloworld get pods. Un pod nommé helloworld doit apparaître dans l'espace de noms helloworld.

   kubectl -n helloworld get pods

   Le résultat est le suivant :

   kubectl get pods -n helloworld
   NAME         READY   STATUS    RESTARTS   AGE
   helloworld   1/1     Running   0          2m

   Lorsque la colonne READY indique 1/1, passez à l'étape suivante.

Étape 2. Observer le comportement avant injection des défaillances

Observez le comportement de l'application helloworld avant l'injection de défaillances, par exemple :

kubectl -n helloworld logs -f helloworld

Le résultat est le suivant :

0. Hello World
1. Hello World
2. Hello World
3. Hello World
4. Hello World
5. Hello World

Vous constatez que helloworld affiche une ligne Hello World chaque seconde, avec un numéro de ligne s'incrémentant séquentiellement.

Étape 3. Injecter JVMChaos et vérifier

1. Le JVMChaos avec une valeur de retour spécifiée se présente comme suit :

   apiVersion: chaos-mesh.org/v1alpha1
   kind: JVMChaos
   metadata:
     name: return
     namespace: helloworld
   spec:
     action: return
     class: Main
     method: getnum
     value: '9999'
     mode: all
     selector:
       namespaces:
         - helloworld

   Ce JVMChaos modifie la valeur de retour de la méthode getnum en 9999, ce qui signifie que le numéro de chaque ligne dans la sortie de helloworld sera fixé à 9999.

2. Injectez le JVMChaos avec la valeur spécifiée :

   kubectl apply -f ./jvm-return-example.yaml

3. Vérifiez le dernier journal de helloworld :

   kubectl -n helloworld logs -f helloworld

   Le journal affiche :

   Rule.execute called for return_0:0
   return execute
   caught ReturnException
   9999. Hello World

Description des champs

Parameter	Type	Description	Default value	Required	Example
action	string	Indicates the specific fault type. The available fault types include latency, return, exception, stress, gc, and ruleData.	None	Yes	return
mode	string	Indicates how to select Pod. The supported modes include one, all, fixed, fixed-percent, and random-max-percent.	None	Yes	one

Les significations des différentes valeurs de action sont les suivantes :

Value	Meaning
latency	Increase method latency
return	Modify return values of a method
exception	Throw custom exceptions
stress	Increase CPU usage of Java process, or cause memory overflow (support heap overflow and stack overflow)
gc	Trigger garbage collection
ruleData	Trigger faults by setting Byteman configuration files

Pour chaque valeur d'action, différents éléments de configuration peuvent être renseignés.

Paramètres pour latency

Parameter	Type	Description	Required
class	string	The name of the Java class	Yes
method	string	The name of the method	Yes
latency	int	The duration of increasing method latency. The unit is millisecond.	Yes
port	int	The port ID attached to the Java process agent. The faults are injected into the Java process through this ID.	No

Paramètres pour return

Parameter	Type	Description	Required
class	string	The name of the Java class	Yes
method	string	The name of the method	Yes
value	string	Specifies the return value of the method. Currently, the item can be numeric and string types. If the item (return value) is string, double quotes are required, like "chaos".	Yes
port	int	The port ID attached to the Java process agent. The faults are injected into the Java process through this ID.	No

Paramètres pour exception

Parameter	Type	Description	Required
class	string	The name of the Java class	Yes
method	string	The name of the method	Yes
exception	string	The thrown custom exception, such as 'java.io.IOException("BOOM")'.	Yes
port	int	The port ID attached to the Java process agent. The faults are injected into the Java process through this ID.	No

Paramètres pour stress

Parameter	Type	Description	Required
cpuCount	int	The number of CPU cores used for increasing CPU stress. You must configure one item between cpu-count and mem-type.	No
memType	string	The type of OOM. Currently, both 'stack' and 'heap' OOM types are supported. You must configure one item between cpu-count and mem-type.	No
port	int	The port ID attached to the Java process agent. The faults are injected into the Java process through this ID.	No

Paramètres pour gc

Parameter	Type	Description	Required
port	int	The port ID attached to the Java process agent. The faults are injected into the Java process through this ID.	No

Paramètres pour ruleData

Parameter	Type	Description	Required
ruleData	string	Specifies the Byteman configuration data	Yes
port	int	The port ID attached to the Java process agent. The faults are injected into the Java process through this ID.	No

Lors de l'écriture du fichier de configuration de règle, prenez en compte le programme Java spécifique et le langage de règles Byteman. Par exemple :

RULE modify return value
CLASS Main
METHOD getnum
AT ENTRY
IF true
DO
    return 9999
ENDRULE

Vous devez échapper les sauts de ligne dans le fichier de configuration avec le caractère de nouvelle ligne "\n", et utiliser le texte échappé comme valeur de "rule-data" comme suit :

\nRULE modify return value\nCLASS Main\nMETHOD getnum\nAT ENTRY\nIF true\nDO return 9999\nENDRULE\n"