Unknown macro: {next_previous_links}
Skip to end of metadata
  • Created by Former user, last modified by Former user on Dec 26, 2015
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

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.

event_flow.png

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.
    This will help you to find the incoming and outgoing messages of the event receiver. This will be very much helpful to reconfigure your event receiver to output the expected format or fix your client to send proper input.

After enabling event tracing, you can go to the monitoring section and see how messages have been received and outputted.

tracing.png

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.

  

rdbms_pub.png

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 you should be able to see table entries in the RDBMS (such as MySQL) for received events similar to below. 

mysql_table.png

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.


simulator_db.png

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.

play_screen.png

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.

  • No labels
Unknown macro: {next_previous_links2}