Join Ivan and myself for the webinar on Fuse Service Works and Run Time Governance which is July 24, 2014 at 11am EST. To register click on the link below. For more detail see the below.
Runtime governance consists of the collection, correlation, analysis, and presentation of realtime results based on activity events collected from heterogeneous distributed environments. It gives operations and business owners visibility into the health and behavior of a system to react to a combination of events from different systems.
During the webinar we will cover the following 5 topics:
1. Fuse Service Works Overview
2. Outline of the business problem that RTGov solves
3. Explain how RTGov addresses the problem
4. Describe the main components
- Collectors, integrated and rest
- EPN, how we collect the data
- CEP, fusion, how we can use rules to make use of the data in real time
- UI, the 3 main components
5. Demonstration
- Step through 3 demos which are based around the switchyard order management service
- During this session Ivan will have a process running in back ground that is generating data against a switchyard service
- Ivan will show RTGov and Kibana presenting this data.
- Ivan will use kibana to show which served is “Slow”, data drill down
- Ivan will then create and deploy a RTGov EPN that reacts on the response time by creating “SLA breach” situations.
- Send a “Request” which will result in a SLA Breach which Ivan will show in RTGOv situations UI
- Purpose is to show how we can actively react on data in the runtime
2: Demo Apply runtime policy based on business data
- Via Kibana
- After addressing our SLA problem I move to intpretating the rest of the data in kibana
-The generated data, from previous demo, show a trend of “insufficent funds” errors occurring
- Ivan will create a Preprocessor EPN. The EPNs purpose is to ensure the users has enough fund before been allowed to place a request
- This demos a business policy been applied to a service. Restrict users access services based on business data
3: Demo Pre-emptively identify increase in service load
- The previous example showed load average of 3 request per second.
- Ivan will deploy a EPN that utilises CEP. The rule aggregates requests hitting a service over a 1 second window.
- If it detects the load increase pass 20 requests a seconds a midium situation “Alert” is created
- If it detects the load increasing pass 30 requests a second a Critical situation “Alert” is created
- Purpose is to show how we anticipate any increasing load on our service
- Test will be done via a soapui load test
- potentially Combined with business data. Eg, over 20 requests for product X in the last hour.
Registration link: http://www.redhat.com/about/events-webinars/webinars/20140724-runtime-governance-to-achieve-greater-business-visibility
