Monitoring and Debugging
This section explains how you can debug WSO2 CEP.
Troubleshooting and debugging guide
WSO2 CEP provides several options to understand the data flow and debug during issues.
If the system is not behaving as you expected then follow the below steps to find the route course of the issue.
Step 1: Assess the Event Flow
This will help you to visually see how the event flows through the system.
You might find some links been broken on the event flow and hence the system will not behave as expected. This should be fixed by inspecting inactive artifacts, if there are any, or by creating appropriate artifacts in order to construct the proper flow.
- Artifacts may have become inactive if there are errors during deployment of execution plans, event receivers or publishers.
- Execution plans can also become inactive when one of their connected event stream’s format is changed.
Step 2: Inspecting statistics
Inspecting events statistics will allow us to find the number of events processed via each of the event flow artifacts. Through this we can find whether the artifact is receiving and outputting events, this can give us hints like whether the artifact is dropping all events or no events have arrived to this artifact for processing.
If events are dropped at the artifact then we have to inspect the artifact in detail (Step 3)
If the events have not even arrived at the artifact then we can use the event flow to identify the artifacts that feed events to the current artifact (Step 1) and then inspect the statistics of those artifacts (Step 2) till we find the artifact causing the root cause.
Step 3: Investigating Artifacts
After identifying an artifact for investigation there are several options that you can try depending on the artifacts type you are investigating.
Investigating Event Receiver
- When we find events are not arrived at the receiver then
- We have to investigate the client system to check whether it's sending to the correct endpoint or
- If the receivers are polling an endpoint check whether it’s configured correctly.
- If events arrive to the event receiver but no events are outputted by it
- Then check the carbon logs or console for possible errors, else
- Check event mapping configuration of the event receiver.
- If events are outputted by event receiver but the data is not in the expected format then
- Enable event tracing to the event receiver and send some sample events to it.
After enabling event tracing, you can go to the monitoring section and see how messages have been received and outputted.
Investigating Event Publisher
When we find events are not arrived at the publisher then we have to follow Step 1 to identity why no events are pushed to publishers.
If events arrive to the event publisher but no events are outputted by it, then
Check the carbon logs or console for possible errors and
Use the event simulator feature to simulate some sample events to see how it behaves for different events.
If events are outputted by event publisher but the data is not in the expected format, then
Enable event tracing on the event publisher and
Send some sample events to it using the event simulator feature
This will help you to find how the incoming message is formatted and sent out. This will be very helpful to reconfigure your event publisher to output the message in the expected format or the proper endpoint.
Investigating Event Processor
When we find events are not arrived on one or more streams to the event processor then we have to follow Step 1 to identify why events have arrived on the stream to the to processor.
If all expected events arrive to the event processor but if some of the expected output events are not outputted, then
Check the carbon logs or console for possible errors. If no errors are reported on the logs or console then
Use the event simulator feature to simulate some sample events to see how it behaves for different input events this will help you to give some hints on logical query errors.
You can also configure logger publisher to suspicious streams to find what events are transmitted by them.
If it does not help you to fix the issue the use Siddhi Try-it to find the root course why the queries are not working as expected.
If all expected events arrive to the event processor and if some of the expected output events are not outputted on expected format, then
Enable event tracing on the event processor to identify if there are any issues in the incoming events, else
Send some sample events to it the event processor using the event simulator feature, this will help you to find why event processor behave in such style.
You can also configure logger publisher to suspicious streams to find what events are transmitted by them.
If it does not help you to fix the issue the use Siddhi Try-it to find the root course why the queries are not working as expected.
With Siddhi Try-it feature you can test the execution plan or query in detail. Here you can define the queries and their expected inputs, and this feature will produce the outputs of the queries at different levels helping you to find the root course of the issue.
Step 4: Simulating Execution Environment
In this step we can simulate the whole execution environment to understand its behaviour on different conditions and to fix issues if they exist. This can be done by constructing a sample dataset or recording the events and replying them.
Collecting/recording events from streams
To collect events from a stream create an RDBMS publisher for that stream and configure it to insert the events in the database by configuring the publisher similar to below.
The configuration for the REDMS publisher is given below.
<?xml version="1.0" encoding="UTF-8"?> <eventPublisher name="BusArrivalDepartureRDBMSPublisher" statistics="disable" trace="disable" xmlns="http://wso2.org/carbon/eventpublisher"> <from streamName="busArrivalDepartureStream" version="1.0.0"/> <mapping customMapping="disable" type="map"/> <to eventAdapterType="rdbms"> <property name="datasource.name">WSO2_GEO_EVENTS_DB</property> <property name="table.name">BusArrivalDepartures</property> <property name="execution.mode">insert</property> </to> </eventPublisher>
Now the RDBMS is collecting events received for that particular stream. Whenever you want to stop collecting data, you can remove the RDBMS publisher.
Replaying events to a Stream
If you want to replay the events collected for further debugging/troubleshooting, you can simply use the EventSimulator and configure it to replay for database. See screenshot below.
After the details are entered correctly and saved, that configuration will be saved and the table is available for replaying data. To resend the collected events, simply click the play button for the DB configuration.
Alternately you can also construct a .csv file with sample events and play that to simulate the event flow.
Available Tools
For more info refer following tools.