Το Επίπεδο που το Toxiproxy Δεν Φτάνει
Το Toxiproxy είναι εξαιρετικό. Το tc netem είναι εξαιρετικό. Οι βιβλιοθήκες chaos μέσω LD_PRELOAD είναι εξαιρετικές. Όλα λειτουργούν στο όριο δικτύου ή λειτουργικού συστήματος — υποκλέπτοντας TCP συνδέσεις, παράδοση πακέτων και κλήσεις συστήματος.
Αυτό που όμως κανένα από αυτά δεν βλέπει: τι συμβαίνει μέσα στο HikariPool σας όταν προσπαθεί να δανειστεί σύνδεση και λήγει το timeout. Τι συμβαίνει μέσα στο ScheduledExecutorService σας όταν έχει κορεστεί. Τι συμβαίνει μέσα στην υλοποίηση SSL του JDK όταν αντιμετωπίζει επανεκπομπή. Τι συμβαίνει μέσα στο thread pool σας όταν οι εργασίες αρχίζουν να συσσωρεύονται ταχύτερα από ό,τι μπορούν να τις διεκπεραιώσουν οι workers.
Αυτά είναι τρόποι αποτυχίας εσωτερικοί του JVM. Δεν εκδηλώνονται ως αποτυχίες δικτύου στο επίπεδο TCP. Εκδηλώνονται ως εξαιρέσεις που εκπέμπονται από κλάσεις JDK — `SQLException`, `RejectedExecutionException`, `SSLHandshakeException`, `TimeoutException` — και ως μοτίβα εξάντλησης πόρων που γίνονται ορατά μόνο όταν οργανώνετε τα σωστά σημεία κλήσης εντός του JVM.
Αυτό το κενό καλύπτει ο JVM chaos agent. Δεν αντικαθιστά το επίπεδο LD_PRELOAD — συνεργάζεται μαζί του. Μαζί, σας δίνουν έγχυση σφαλμάτων τόσο στο όριο λειτουργικού συστήματος όσο και στο εσωτερικό όριο JVM: η πλήρης επιφάνεια αποτυχίας μιας εφαρμογής Java.
62 Σημεία Κλήσης JDK: Η Πλήρης Επιφάνεια
Ο agent ενορχηστρώνει 62 συγκεκριμένα σημεία κλήσης JDK — όχι τυχαία, αλλά αυτά που έχουν σημασία για enterprise backend φορτία εργασίας. Η επιλογή βασίστηκε σε ανάλυση συμβάντων από αποτυχίες κατανεμημένων συστημάτων:
**Threading & Executors** Thread.start(), ThreadPoolExecutor.execute(), ScheduledExecutorService.schedule(), CompletableFuture.runAsync/supplyAsync, λειτουργίες BlockingQueue (put, offer, poll, take), υποβολές ForkJoinPool, κύκλος ζωής virtual thread
**Δίκτυο & I/O** Socket.connect/read/write, SocketChannel.connect/read/write, Selector.select/selectNow, λειτουργίες DatagramChannel, ServerSocket.accept
**DNS & Επίλυση Ονομάτων** InetAddress.getByName/getAllByName — η εσωτερική διαδρομή επίλυσης του JDK πριν κληθεί ο επιλύτης λειτουργικού συστήματος
**JDBC & Πρόσβαση Δεδομένων** DataSource.getConnection (δανεισμός από connection pool), Statement.execute/executeQuery, λειτουργίες PreparedStatement — στο επίπεδο όπου Hikari, DBCP, και c3p0 διέρχονται
**HTTP Clients** HttpURLConnection, HttpClient (JDK 11+) — send, sendAsync
**SSL/TLS** SSLEngine.wrap/unwrap, SSLSocket.startHandshake
**Χρόνος** System.currentTimeMillis(), System.nanoTime() — με εφέ FIXED offset, DRIFT, και FREEZE
**JVM Internals** System.gc(), φόρτωση κλάσης, reflection, σειριοποίηση/αποσειριοποίηση αντικειμένων, ThreadLocal.get/set, αναζητήσεις JNDI, λειτουργίες JMX, φόρτωση εγγενών βιβλιοθηκών, αποσυμπίεση ZIP
// 62 interception targets across the JDK surface
Sealed interface ChaosSelector permits
ThreadSelector, // Thread.start, pool operations
ExecutorSelector, // ThreadPoolExecutor, ForkJoinPool
QueueSelector, // BlockingQueue operations
FutureSelector, // CompletableFuture
SocketSelector, // Socket, ServerSocket
NioSelector, // SocketChannel, Selector
JdbcSelector, // DataSource.getConnection, Statement
HttpSelector, // HttpURLConnection, HttpClient
DnsSelector, // InetAddress resolution
SslSelector, // SSLEngine, SSLSocket
ClockSelector, // System.currentTimeMillis, nanoTime
GcSelector, // System.gc
ClassloadingSelector, // ClassLoader.loadClass
SerializationSelector,// ObjectInputStream, ObjectOutputStream
ThreadLocalSelector, // ThreadLocal.get, set
VirtualThreadSelector;// VirtualThread lifecycleByteBuddy + Bootstrap Bridge: Πώς Λειτουργεί
Η ενορχήστρωση κλάσεων JDK δεν είναι τετριμμένη. Οι κλάσεις JDK φορτώνονται από τον bootstrap classloader — τον ριζικό classloader που δεν έχει γονέα. Ο κώδικας του agent ζει στον agent classloader, τον οποίο ο bootstrap classloader δεν μπορεί να δει με όνομα. Η σωστή γεφύρωση αυτού του κενού απαιτεί προσεκτική χρήση του JVMTI και του Java Memory Model.
**Βήμα 1 — Premain ή agentmain.** Ο agent συνδέεται είτε κατά την εκκίνηση (μέσω `-javaagent:`) είτε δυναμικά κατά τη διάρκεια του τεστ (μέσω του JDK Attach API). Κατά τη δυναμική σύνδεση, το Spring Boot test starter καλεί `VirtualMachine.attach(processId)` και εγχέει το agent jar.
**Βήμα 2 — Έγχυση Bootstrap.** Μια κλάση `BootstrapDispatcher` εξάγεται από το agent jar και γράφεται σε ένα προσωρινό JAR. Αυτό το JAR προσαρτάται στο bootstrap classpath μέσω `Instrumentation.appendToBootstrapClassLoaderSearch()`. Ο bootstrap classloader μπορεί πλέον να δει τον `BootstrapDispatcher`.
**Βήμα 3 — Καλωδίωση MethodHandle.** Δημιουργείται ένας πίνακας `MethodHandle[]` 62 θέσεων, ένα handle ανά στόχο παρεμβολής, που δείχνει στην υλοποίηση του agent classloader. Ο πίνακας και ένα αντικείμενο `delegate` δημοσιεύονται στον `BootstrapDispatcher` ως πεδία `volatile`. Το JMM εγγυάται ότι οποιοδήποτε thread παρατηρεί `delegate != null` βλέπει επίσης τον πλήρως αρχικοποιημένο πίνακα `handles`.
**Βήμα 4 — Inlining bytecode advice.** Ο μηχανισμός `@Advice` του ByteBuddy αντιγράφει τον bytecode της συμβουλής απευθείας μέσα στο σώμα της μεθόδου JDK που ενορχηστρώνεται. Δεν υπάρχει virtual dispatch, δεν υπάρχει κλήση διεπαφής — ο υφασμένος bytecode είναι inline. Μετά τη μεταγλώττιση JIT κατά την εκκίνηση (~10.000 επικλήσεις), ολόκληρη η αλυσίδα αποστολής μεταγλωττίζεται σε native κώδικα.
// Hot path after JIT compilation — effectively just:
public static void connect(Socket socket, SocketAddress endpoint, int timeout) {
Object delegate = BootstrapDispatcher.delegate; // volatile read
if (delegate != null) { // null check — fast path
BootstrapDispatcher.handles[SOCKET_CONNECT] // MethodHandle
.invoke(delegate, socket, endpoint); // → ChaosRuntime
}
originalConnect(socket, endpoint, timeout); // real JDK call
}
// Zero-scenario overhead: one volatile read + one null check + one untaken branch
// Measured: ~60 ns per call in the uncontested case after warm-upΑπομόνωση Συνεδρίας: Κάθε Τεστ Έχει το Δικό του Chaos
Το δυσκολότερο μηχανολογικό πρόβλημα σε έναν chaos agent σε επίπεδο JVM δεν είναι η ενορχήστρωση bytecode — είναι η απομόνωση. Πολλαπλά τεστ JUnit εκτελούνται ταυτόχρονα στο ίδιο JVM. Εάν το τεστ A εγχύει αποτυχίες σύνδεσης JDBC, το τεστ B δεν επιτρέπεται να δει αυτές τις αποτυχίες.
Η λύση είναι το `ChaosSession`, υποστηριζόμενο από `ThreadLocal<UUID>`.
Κάθε μέθοδος τεστ (ή κλάση τεστ, ανάλογα με τον κύκλο ζωής) λαμβάνει ένα μοναδικό session ID. Τα σενάρια chaos μπορούν να καταχωρηθούν είτε ως JVM-scoped (επηρεάζει όλα τα threads) είτε ως session-scoped (επηρεάζει μόνο τα threads που φέρουν το session ID αυτού του τεστ). Το `ThreadLocal` παρέχει τη σύνδεση.
Για εργασίες που υποβάλλονται σε executors, το session ID πρέπει να διαδοθεί από το thread υποβολής στο worker thread. Ο agent ενορχηστρώνει το `ThreadPoolExecutor.execute()` για να τυλίξει τον υποβληθέντα `Runnable` με έναν decorator που καταγράφει το τρέχον session ID και το αποκαθιστά στο worker thread πριν εκτελεστεί η εργασία. Αυτή η διάδοση συμβαίνει διαφανώς — ο κώδικας της εφαρμογής δεν γνωρίζει ότι συμβαίνει.
@ChaosTest // @SpringBootTest composed annotation
class OrderServiceChaosTest {
@Test
void retryLogic_handles_transient_jdbc_failures(ChaosSession session) {
var scenario = ChaosScenario.builder("transient-db")
.selector(ChaosSelector.jdbc(OperationType.JDBC_CONNECTION_ACQUIRE))
.effect(ChaosEffect.reject("chaos: simulated pool timeout"))
.activationPolicy(ActivationPolicy.builder()
.probability(1.0)
.maxApplications(2) // First 2 borrows fail, 3rd succeeds
.build())
.build();
try (var handle = session.activate(scenario)) {
try (var scope = session.bind()) {
// This thread and any executor tasks it submits
// will see the JDBC failures — nothing else will
var result = orderService.placeOrder(testOrder);
assertThat(result.status()).isEqualTo(OrderStatus.CONFIRMED);
}
}
// Chaos cleaned up — next test is unaffected
}
}Spring Boot 3 και 4: Σύνδεση Χωρίς Ρύθμιση
Τα Spring Boot test starters υπάρχουν επειδή η σύνδεση θα πρέπει να είναι αόρατη. Δεν χρειάζεται να κατανοείτε το ByteBuddy, τον bootstrap classloader ή το JVMTI για να εκτελέσετε το πρώτο σας chaos test. Το starter διαχειρίζεται:
- Προγραμματιστική ρύθμιση `jdk.attach.allowAttachSelf=true` πριν επεξεργαστεί αυτή τη σημαία το JVM (χρησιμοποιώντας στατικό αρχικοποιητή στην κλάση αυτόματης ρύθμισης του starter) - Ανίχνευση εάν ο agent είναι ήδη συνδεδεμένος (idempotent — ασφαλές σε παράλληλη εκτέλεση κλάσεων τεστ) - Σύνδεση του agent μέσω `VirtualMachine.attach("0")` (self-attach) εάν δεν υπάρχει ήδη - Καταχώρηση `ChaosControlPlane` και `ChaosSession` ως Spring beans στο test ApplicationContext - Παροχή επίλυσης παραμέτρων JUnit 5 για ορίσματα κατασκευαστή `ChaosSession` και `ChaosControlPlane`
Το runtime starter (για μη-test ανάπτυξη) εκθέτει επίσης το `/actuator/chaos` ως προστατευμένο Actuator endpoint για διαχείριση ζωντανών σεναρίων.
<!-- Spring Boot 3 — add to pom.xml testImplementation -->
<dependency>
<groupId>com.macstab.chaos</groupId>
<artifactId>chaos-agent-spring-boot3-test-starter</artifactId>
<version>${chaos-agent.version}</version>
<scope>test</scope>
</dependency>
<!-- That's it. No -javaagent flag. No JVM args. No beans to define. -->
<!-- Spring Boot 4 -->
<dependency>
<groupId>com.macstab.chaos</groupId>
<artifactId>chaos-agent-spring-boot4-test-starter</artifactId>
<version>${chaos-agent.version}</version>
<scope>test</scope>
</dependency>Ο Αγωγός Ενεργοποίησης Οκτώ Πυλών
Κάθε αξιολόγηση σεναρίου chaos περνά από οκτώ πύλες διαδοχικά. Όλες οι πύλες πρέπει να περάσουν για να ενεργοποιηθεί το αποτέλεσμα. Οι πύλες είναι γρήγορες — αξιολογούνται στο calling thread χωρίς I/O και ελάχιστο κλείδωμα.
**Πύλη 1 — Έλεγχος εκκίνησης.** Έχει ενεργοποιηθεί το σενάριο; (Φτηνή ανάγνωση σημαίας.)
**Πύλη 2 — Αντιστοίχιση session ID.** Εάν είναι session-scoped, φέρει το τρέχον `ThreadLocal` του thread το σωστό UUID; (Ανάγνωση thread-local, χωρίς κλείδωμα.)
**Πύλη 3 — Αντιστοίχιση selector.** Αντιστοιχεί αυτό το σημείο κλήσης με τον selector του σεναρίου; (Σύγκριση enum, O(1).)
**Πύλη 4 — Παράθυρο ενεργοποίησης.** Βρίσκεται ο τρέχων χρόνος εντός του ρυθμισμένου παραθύρου έναρξης/λήξης του σεναρίου; (Δύο συγκρίσεις long.)
**Πύλη 5 — Μέτρηση εκκίνησης.** Έχει αντιστοιχιστεί αυτό το σενάριο τουλάχιστον N φορές πριν αρχίσει να εφαρμόζεται; (Ανάγνωση AtomicLong.)
**Πύλη 6 — Όριο ρυθμού.** Έχει χωρητικότητα ο κάδος token του sliding-window; (Συγχρονισμένο μπλοκ· μη αμφισβητούμενο μονοπάτι ~5 ns.)
**Πύλη 7 — Πιθανότητα.** Τυχαία κλήρωση έναντι ρυθμισμένης πιθανότητας. (SplittableRandom με σπόρο από ID σεναρίου + αριθμό αντιστοιχίσεων — ντετερμινιστικό για αναπαραγωγή αποτυχιών.)
**Πύλη 8 — Μέγιστες εφαρμογές.** Βρόχος CAS σε AtomicLong για επιβολή αυστηρού ορίου. (Βρόχος compareAndSet· σωστό υπό διαμάχη — σε αντίθεση με ένα απλό incrementAndGet που μπορεί να υπερβεί.)
Όλες οι οκτώ πύλες περνούν → εφαρμογή του αποτελέσματος. Οποιαδήποτε πύλη αποτυγχάνει → κλήση στην πραγματική μέθοδο JDK αμετάβλητη.
Stressors Παρασκηνίου: Πέρα από Σφάλματα Διαδρομής Αιτήματος
Εκτός από inline αποτελέσματα στη διαδρομή αιτήματος (καθυστέρηση, απόρριψη, έγχυση εξαιρέσεων), ο agent υποστηρίζει stressors παρασκηνίου — threads δεσμευμένα με κύκλο ζωής που εφαρμόζουν συνεχώς πίεση πόρων ανεξάρτητα από την κίνηση.
Οι stressors προσομοιώνουν τους τρόπους αποτυχίας αργής καύσης που δεν ενεργοποιούνται από συγκεκριμένες λειτουργίες αλλά συσσωρεύονται με τον χρόνο:
**Stressors μνήμης:** Πίεση heap (διατήρηση κομματιών byte[]), πίεση GC (ανακύκλωση κατανομής), πίεση Metaspace (συνθετικοί ορισμοί κλάσης), πίεση άμεσων buffers (off-heap ByteBuffer), πλημμύρα intern strings
**Stressors JVM:** Πίεση code cache (πλημμύρα κλάσεων που παράγει ByteBuddy για thrashing JIT), καθυστέρηση finalizer (πλημμύρα ουράς phantom-reference), πλημμύρα ουράς αναφοράς, καταιγίδες safepoint (περιοδική επαν-μετατροπή για ενεργοποίηση παύσεων stop-the-world)
**Stressors threads:** Διαρροή threads (μόνιμα σταματημένα threads που καταναλώνουν μνήμη thread stack), διαρροή ThreadLocal (εγγραφές σε pooled threads που συσσωρεύονται), έγχυση αδιεξόδου (πραγματικό αδιέξοδο JVM monitor μεταξύ N threads — επαληθευμένο με ThreadMXBean), διαμάχη monitor (background threads που ανταγωνίζονται για κοινή κλειδαριά), keep-alive threads (αποτροπή τερματισμού JVM)
Οι stressors ξεκινούν όταν ενεργοποιείται ένα σενάριο και σταματούν όταν κλείνει. Συνεργάζονται με inline αποτελέσματα: μπορείτε να έχετε ταυτόχρονα απορρίψεις JDBC στη διαδρομή αιτήματος και έναν ενεργό stressor code-cache, δοκιμάζοντας εάν η εφαρμογή σας ανακάμπτει από αποτυχίες σύνδεσης ενώ βρίσκεται ήδη υπό πίεση μεταγλώττισης JIT.
- Πίεση heap: διατήρηση ρυθμιζόμενων MB/s σε κατανομές byte[] για επιβολή πίεσης GC
- Πίεση Metaspace: ορισμός συνθετικών κλάσεων σε απομονωμένο ClassLoader για κατανάλωση permgen/metaspace
- Πίεση code cache: δημιουργία κλάσεων ByteBuddy για κορεσμό του μεταγλωττιστή JIT
- Καταιγίδα safepoint: επιβολή περιοδικής επαν-μετατροπής για ενεργοποίηση παύσεων stop-the-world
- Πραγματικό αδιέξοδο: δύο threads αποκτούν monitors με αντίθετη σειρά — ανιχνεύεται από ThreadMXBean
- Διαρροή threads: μόνιμη παύση threads για εξάντληση μνήμης stack -Xss με τον χρόνο
Παράδειγμα: Επικύρωση Συμπεριφοράς SLA Υπό Εξάντληση JDBC
Ένα συγκεκριμένο σενάριο τεστ που ασκεί τη βασική αξία του agent: απόδειξη ότι η υπηρεσία σας ανταποκρίνεται σωστά σε πληρωμή με στόχο SLA όταν το pool συνδέσεων βάσης δεδομένων βρίσκεται υπό πίεση.
@SpringBootTest
@ChaosTest
class PaymentSLAChaosTest {
@Autowired PaymentService paymentService;
@Test
void payment_meets_sla_under_intermittent_jdbc_pressure(ChaosSession session) {
// Activate 20% JDBC connection failure — simulates pool under load
var jdbcChaos = ChaosScenario.builder("jdbc-pressure")
.selector(ChaosSelector.jdbc(OperationType.JDBC_CONNECTION_ACQUIRE))
.effect(ChaosEffect.delay(Duration.ofMillis(150))) // Not rejection — delay
.activationPolicy(ActivationPolicy.probability(0.20))
.build();
// Also activate a background heap stressor
var heapStressor = ChaosScenario.builder("heap-pressure")
.effect(ChaosEffect.stressor(StressorType.HEAP_PRESSURE)
.retainMbPerSecond(50)
.build())
.build();
try (var h1 = session.activate(jdbcChaos);
var h2 = session.activate(heapStressor)) {
try (var scope = session.bind()) {
long start = System.nanoTime();
var result = paymentService.process(testPayment);
long elapsedMs = (System.nanoTime() - start) / 1_000_000;
assertThat(result.status()).isEqualTo(PaymentStatus.COMPLETED);
assertThat(elapsedMs).isLessThan(500); // SLA: p99 < 500ms
}
}
}
}JMX και Παρατηρησιμότητα
Ο agent εκθέτει ένα JMX MBean στο `com.macstab.chaos.jvm:type=ChaosDiagnostics` που παρέχει ένα ζωντανό στιγμιότυπο όλων των ενεργών σεναρίων — την τρέχουσα κατάστασή τους, αριθμούς αντιστοιχίσεων και αριθμούς εφαρμογών — χωρίς να απαιτούνται αλλαγές κώδικα ή πρόσθετη ρύθμιση.
Αυτό είναι χρήσιμο κατά τον εντοπισμό σφαλμάτων τεστ: εάν ένα chaos test αποτυγχάνει απροσδόκητα, μπορείτε να συνδέσετε JConsole ή VisualVM στο JVM του τεστ και να επιθεωρήσετε ακριβώς ποια σενάρια είναι ενεργά και πόσες φορές εκτελέστηκαν.
Ο δίαυλος παρατηρησιμότητας επιτρέπει τη δημοσίευση chaos events σε εξωτερικά συστήματα μετρικών. Εάν εκτελείτε chaos tests σε κοινό περιβάλλον ολοκλήρωσης και θέλετε να συσχετίσετε chaos events με dashboards Grafana ή κατανεμημένα traces, ο δίαυλος παρέχει το σημείο ολοκλήρωσης.
- JMX MBean: λίστα ενεργών σεναρίων, αριθμοί αντιστοιχίσεων, αριθμοί εφαρμογών, τρέχουσα κατάσταση ανά σενάριο
- In-process snapshot API: δυνατότητα ερωτήματος από κώδικα τεστ για assertions στη συμπεριφορά chaos
- Debug dump: αναπαράσταση κειμένου όλων των σεναρίων και καταστάσεων — χρήσιμο στην έξοδο αποτυχίας τεστ
- Δίαυλος παρατηρησιμότητας: pluggable εκδότης events για ολοκλήρωση μετρικών/ανίχνευσης
Key Takeaways
Ο JVM chaos agent καλύπτει το κενό μεταξύ έγχυσης σφαλμάτων σε επίπεδο υποδομής και πραγματικών εσωτερικών τρόπων αποτυχίας JVM. 62 σημεία κλήσης JDK, απομόνωση συνεδρίας ανά τεστ, αυτόματη σύνδεση Spring Boot 3/4, stressors παρασκηνίου για αποτυχίες αργής καύσης, και μια διαδρομή αποστολής βελτιστοποιημένη για JIT που κοστίζει ~60 ns ανά κλήση στην περίπτωση μηδενικού σεναρίου.
Ο agent συνεργάζεται με τη βιβλιοθήκη LD_PRELOAD C99 για πλήρη κάλυψη σφαλμάτων σε ολόκληρη τη στοίβα: αποτυχίες σε επίπεδο syscall κάτω από το JVM, αποτυχίες σε επίπεδο bytecode μέσα σε αυτό. Και τα δύο ενορχηστρώνονται από το σύστημα annotations του Java testing framework — ένα τεστ, και τα δύο επίπεδα ενεργά, χωρίς επικάλυψη ρύθμισης.
Το chaos engineering ως CI gate είναι έτοιμο. Το μόνο ερώτημα είναι ποιος τρόπος αποτυχίας δεν χειρίζεται ακόμη ο circuit breaker σας.
Engineering Team
Senior Solutions Architects
Χτίζουμε κατανεμημένα συστήματα από πριν το «microservices» γίνει μόδα. Τα σημάδια μας έχουν ιστορίες να διηγηθούν.