De berichtenstroom debuggen
Gebruik tools en technieken om de berichtenstroom door exchanges en wachtrijen te debuggen. Volg berichten om hun route te begrijpen en problemen met de levering op te sporen.
De berichtenstroom debuggen is een gratis RabbitMQ-berichten en asynchrone systemen-les op CoddyKit. Dit is les 2 van 4. Je kunt 3 lessen uit dit leerpad gratis volledig lezen — daarna ontgrendelt CoddyKit PRO alle lessen, plus praktische oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject RabbitMQ-berichten en asynchrone systemen. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus RabbitMQ-berichten en asynchrone systemen bevat in totaal 4 lessen.
Waarom de berichtenstroom debuggen?
Wanneer je systemen bouwt met berichtenwachtrijen zoals RabbitMQ, komen berichten niet altijd terecht waar je verwacht. Ze kunnen verloren gaan, niet worden afgeleverd of zich in wachtrijen ophopen.
Inzicht in debuggen van de berichtenstroom is cruciaal. Hiermee kun je de reis van een bericht van producent naar consument volgen en precies vaststellen waar problemen optreden.
Je dashboard voor debugging: de beheerplug-in
De RabbitMQ Management Plugin is je belangrijkste hulpmiddel voor het debuggen van de berichtenstroom. Deze biedt een webinterface waarmee je de status van je broker kunt bekijken.
- Overzicht: Statistieken op hoofdlijnen.
- Verbindingen/kanalen: Bekijk actieve clientverbindingen.
- Exchanges: Bekijk exchangetypen en koppelingen.
- Wachtrijen: Bekijk aantallen berichten en consumenten en haal berichten op of publiceer ze.
Berichten in de interface bekijken en invoegen
Met de beheerplug-in kun je rechtstreeks met je berichtenstroom werken:
- Berichten publiceren: Gebruik op de pagina van een exchange het paneel 'Bericht publiceren' om testberichten te versturen. Zo kun je de logica van de routeringssleutel en koppeling controleren.
- Berichten ophalen: Gebruik op de pagina van een wachtrij het paneel 'Berichten ophalen' om berichten uit de wachtrij op te halen. Zo bevestig je of berichten aankomen en wat hun inhoud en eigenschappen zijn.
De identiteitskaart van een bericht: eigenschappen
Elk bericht in RabbitMQ bevat belangrijke informatie. Let bij het debuggen goed op het volgende:
- Routeringssleutel: De sleutel die exchanges gebruiken om het bericht te routeren.
- Kopteksten: Aangepaste sleutel-waardeparen die voor routering (Headers Exchange) of metagegevens kunnen worden gebruikt.
- Afleveringsmodus: Geeft aan of het bericht persistent is.
Deze eigenschappen bepalen hoe een bericht wordt verwerkt en gerouteerd.
Niet-overeenkomende routeringssleutels
Een veelvoorkomend probleem is dat een bericht de bedoelde wachtrij niet bereikt door een onjuiste routeringssleutel of een ontbrekende koppeling.
Een Direct-exchange die bijvoorbeeld de routeringssleutel 'errors' verwacht, verwijdert berichten die met 'info' zijn verzonden als er geen wachtrij aan 'info' is gekoppeld. Controleer altijd of de routeringssleutel van de producent overeenkomt met de koppelingen van de wachtrij.
Inzichten aan de producentzijde met logboekregistratie
Logboekregistratie toevoegen aan je producenttoepassing is essentieel. Hiermee bevestig je of je toepassing heeft geprobeerd een bericht te verzenden en welke routeringssleutel daarbij is gebruikt.
Voer dit Java-voorbeeld uit. Bekijk de uitvoer in de console.
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.Connection;
import com.rabbitmq.client.ConnectionFactory;
public class DebugProducer {
private final static String QUEUE_NAME = "debug_queue_log";
public static void main(String[] argv) throws Exception {
ConnectionFactory factory = new ConnectionFactory();
factory.setHost("localhost"); // Assumes local RabbitMQ
try (Connection connection = factory.newConnection();
Channel channel = connection.createChannel()) {
channel.queueDeclare(QUEUE_NAME, false, false, false, null);
String message = "Hello, debug world!";
String routingKey = QUEUE_NAME; // Using queue name as routing key
System.out.println(" [Producer] Sending message to queue: " + QUEUE_NAME);
System.out.println(" [Producer] With routing key: '" + routingKey + "'");
channel.basicPublish("", routingKey, null, message.getBytes("UTF-8"));
System.out.println(" [Producer] Sent message: '" + message + "'");
} catch (Exception e) {
System.err.println(" [Producer] Failed to send: " + e.getMessage());
}
}
}Diagnostiek aan de consumentzijde
Logboekregistratie in je consument bevestigt of berichten worden ontvangen en verwerkt. Zo kun je onderscheid maken tussen berichten die de wachtrij niet bereiken en berichten die niet door consumenten worden opgehaald.
Voer deze consument uit en voer daarna de producent uit de vorige scène uit.
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.Connection;
import com.rabbitmq.client.ConnectionFactory;
import com.rabbitmq.client.DeliverCallback;
public class DebugConsumer {
private final static String QUEUE_NAME = "debug_queue_log";
public static void main(String[] argv) throws Exception {
ConnectionFactory factory = new ConnectionFactory();
factory.setHost("localhost"); // Assumes local RabbitMQ
Connection connection = factory.newConnection();
Channel channel = connection.createChannel();
channel.queueDeclare(QUEUE_NAME, false, false, false, null);
System.out.println(" [Consumer] Waiting for messages. To exit press CTRL+C");
DeliverCallback deliverCallback = (consumerTag, delivery) -> {
String message = new String(delivery.getBody(), "UTF-8");
System.out.println(" [Consumer] Received message: '" + message + "'");
// Simulate processing
try {
Thread.sleep(500); // Simulate work
} catch (InterruptedException _e) {
Thread.currentThread().interrupt();
}
channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false); // Manual ack
System.out.println(" [Consumer] Processed & acknowledged: '" + message + "'");
};
channel.basicConsume(QUEUE_NAME, false, deliverCallback, consumerTag -> {});
}
}Achterstanden en knelpunten in wachtrijen
Als berichten zich in een wachtrij ophopen (zichtbaar in de beheerinterface), wijst dit op een knelpunt. Mogelijke oorzaken zijn:
- Geen consumenten: Geen enkele toepassing luistert naar de wachtrij.
- Trage consumenten: Consumenten kunnen berichten niet zo snel verwerken als ze binnenkomen.
- Uitgevallen consument: Consumenten zijn gecrasht of gestopt zonder berichten te bevestigen.
- Vooraf ophalen: Consumenten ontvangen te veel berichten tegelijk, waardoor de verwerking vertraagt.
Berichten naar de DLQ?
Als berichten uit hun verwachte wachtrij lijken te verdwijnen, controleer dan je dead-letterwachtrijen (DLQ's). Berichten worden naar een dead-letterwachtrij gestuurd wanneer:
- Ze worden afgewezen (
basic.rejectofbasic.nack) en niet opnieuw in de wachtrij worden geplaatst. - Ze verlopen door TTL (Time-To-Live).
- De limiet voor de wachtrijlengte wordt overschreden.
Door DLQ's te monitoren, kun je niet-afleverbare berichten opsporen.
Je checklist voor debugging
Volg deze stappen wanneer er een probleem met de berichtenstroom ontstaat:
- 1. Logboeken van de producent: Heeft de producent bevestigd dat het bericht is verzonden?
- 2. Exchange-koppelingen: Is de wachtrij met de juiste routeringssleutel correct aan de exchange gekoppeld?
- 3. Beheerinterface (wachtrij): Hopen berichten zich op in de wachtrij? Gebruik 'Berichten ophalen'.
- 4. Logboeken van de consument: Ontvangt en bevestigt de consument berichten?
- 5. DLQ's: Controleer of berichten in een dead-letterwachtrij zijn terechtgekomen.
- 6. Testen met de interface: Gebruik 'Bericht publiceren' in de beheerinterface om routeringsproblemen te isoleren.
Het pad traceren
Een producent verzendt berichten naar een directe exchange 'logs' met de routeringssleutel 'error'. Een wachtrij met de naam 'error_logs' is aan de exchange 'logs' gekoppeld met de routeringssleutel 'warning'.
Als berichten met de routeringssleutel 'error' niet in de wachtrij 'error_logs' verschijnen, wat is dan de MEEST waarschijnlijke directe oorzaak?
Samenvatting: beheers je berichtenstroom
In deze les heb je essentiële vaardigheden opgedaan voor het debuggen van de berichtenstroom in RabbitMQ.
- Je hebt geleerd de Management Plugin te gebruiken voor inspectie en tests.
- Je hebt gezien hoe belangrijk logboekregistratie bij zowel producenten als consumenten is.
- Je kunt nu veelvoorkomende problemen herkennen, zoals niet-overeenkomende routeringssleutels en achterstanden in wachtrijen.
- Je begrijpt welke rol dead-letterwachtrijen spelen bij het opvangen van niet-afleverbare berichten.
Met deze technieken kun je problemen met berichtaflevering effectief vaststellen en oplossen!
Leer RabbitMQ-berichten en asynchrone systemen met een AI-tutor — gratis
Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.
- Cursussen
- 11
- Lessen
- 44
Veelgestelde vragen
Is de les “De berichtenstroom debuggen” gratis?
Ja — je kunt hier op het web alle 3 lessen van het leerpad RabbitMQ-berichten en asynchrone systemen, waaronder “De berichtenstroom debuggen”, gratis volledig lezen. Daarna ontgrendelt CoddyKit PRO alle lessen, plus interactieve oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. De cursus RabbitMQ-berichten en asynchrone systemen bevat in totaal 4 lessen.
Wat leer ik in “De berichtenstroom debuggen”?
Gebruik tools en technieken om de berichtenstroom door exchanges en wachtrijen te debuggen. Volg berichten om hun route te begrijpen en problemen met de levering op te sporen. Je oefent met RabbitMQ-berichten en asynchrone systemen door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.
Heb ik ervaring nodig om met RabbitMQ-berichten en asynchrone systemen te beginnen?
Ervaring vooraf is niet nodig. RabbitMQ-berichten en asynchrone systemen op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 2 van 4.
Hoe lang duurt de les “De berichtenstroom debuggen”?
De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.
Kan ik code schrijven en uitvoeren in deze les over RabbitMQ-berichten en asynchrone systemen?
Ja. Elke les over RabbitMQ-berichten en asynchrone systemen bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.
Alle lessen in deze cursus
- Veelvoorkomende RabbitMQ-problemen
- De berichtenstroom debuggen
- Best practices voor productiesystemen
- Capaciteitsplanning en loadtesting