Presented by Matt Brasier, C2B2 Principal Consultant, at the Oracle User Group Scotland Conference on the 10th of June 2015 Find out more about C2B2 Oracle SOA Suite servcies here: http://www.c2b2.co.uk/soa

1. 10th June 2014 UKOUG Scotland
Matt Brasier
Monitoring Oracle SOA Suite

2. About me
• Head of Consulting at C2B2
• 14 years WebLogic experience
• 12 in a consultancy role
• Author
– Oracle SOA Suite 11g Performance Tuning
Cookbook

3. About C2B2
• Middleware professional services
– Consultancy
– Support
• Oracle partner
• Oracle SOA Suite 12c upgrade campaign

4. Agenda
• Intro
• Why Monitor?
• How to Monitor?
• What to Monitor?

5. Introduction

6. Oracle SOA Suite
• Evolved rather than designed
– BPMN
– BPEL
– Mediator
– Rules
– Workflow
– BAM/B2B/Event Processor

7. Oracle SOA Suite
• Runs on a stack
– Hardware
– OS
– JVM
– WebLogic
– SOA Suite

8. Monitoring
• Monitoring
– Capturing of metrics
– Visualising of metric trends
• Alerting
– Generating a notification when a condition is met
• Out of bounds metric

9. The Java Monitoring world
• Still developing
• Lots of tools
• Monitoring for deployments of all sizes
• Monitoring frameworks vs Alerting
frameworks
• Java based frameworks vs frameworks that
can monitor java

10. Why Monitor?

11. Five reasons to monitor SOA Suite
• Detect problems early
• Capacity planning
• Resolve problems faster
• Understand your system better
• Save money

12. Detect problems early
• Locate areas of resource contention
• Identify unusual workloads
• Identify failed components or services
• Detect problems in other systems
– Middleware is often the best place to start
• Alerting is key
– Alerts to the right people at the right time

13. Capacity planning
• Detect trends in usage
• Understand how changes in use will affect
capacity
• Increase capacity before it causes a problem
– Hardware and upgrade lead times

14. Resolve problems faster
• Post incident analysis
• What resources were at their limits?
• What was the system doing before it failed?
• What were other systems doing at the time?
• What can we do to alert before failure next
time?

15. Understand your system better
• What does a normal day look like on the
system?
– Resource usage
– Use case load
• Which resources are key to system operation?
• What improvements can you make?

16. Save money
• The bottom line
– Less outages
– Faster resolutions
– Less repeated failures
– Target capacity correctly
– More knowledgeable and better prepared
administrators

17. How to Monitor?

18. Ways to monitor Oracle SOA Suite
• Manual monitoring
• Scripts
• Monitoring tools
• Log scraping tools
• Alerting

19. Manual Monitoring
• Someone sits and looks at a console
– Watching log files
– Reviewing output from basic tools
• jVisualVM
• jstat
• JRMC
• DMS

20. Scripts
• Collect data from manual tools and store it
somewhere using a script
– WLST
– jstat
• Analyse data in tools such as excel when
required

21. Monitoring Tools
• Usually server/agent based
– Install agent on the host to be monitored
• Wide range of tools
– Oracle Enterprise Manager Cloud Control
– Nagios
– ManageEngine
– HP OpenView

22. Monitoring Tools
• Specific vs Generic
– Specific tools often provide more out of the box
– Generic tools often need some configuration
• Auto discovery vs manual configuration
• Where do they store the data?
• How much information do they provide
– OS
– Hardware

23. Log Scraping Tools
• Splunk is the best known example
• Send metrics to a log file
• Log scraping tool reads and parses the
metrics
• Log scraping server integrates metrics
together and displays them

24. Monitoring best practices
• Capture key metrics (see later)
• Don’t alert on everything you capture
• Consider data retention periods
• Be open with access to monitoring data

25. Alerting best practices
• Who is in a position to do something about
the alert
• The people who have to deal with it should
own the alert
– Thresholds
– Enabling/disabling
– Damping

26. Enterprise Monitoring
• Architectural options
– Generic enterprise monitoring tool
– Specialist monitoring tool that sends alerts up
stream
– Multiple monitoring tools
• Network
• Hardware
• OS
• Middleware

27. What to Monitor?

28. What to monitor?
• Hardware
• OS
• JVM
• WebLogic
• SOA Suite
• Log files
* Indicates alert candidate

29. Hardware
• Disk usage*
• Network IO*
• CPU Usage*
• Memory Usage

30. Operating System
• File handles*
• User CPU vs System CPU
• Modification dates on key files*
• Boot time *

31. Java Virtual Machine
• Garbage Collection*
• Memory Usage
– Old
– New
– Perm…
• Threads

32. WebLogic
• Datasource connection pool size*
• JMS Queue/Topic depth*
• JMS Consumer count*
• Stuck threads*
• Work managers

33. SOA Suite
• Composite response times

34. Log Files
• Key exception or error types
– java.io.IOException
– oracle.jdbc.
– java.lang.OutOfMemoryError
– .
– .
– .

35. What Next?

36. What Next?
• Write a monitoring policy
• Review your existing monitoring against it
• Update your monitoring
• Improve your availability
• Resolve issues faster

37. What Next?
• Follow C2B2 on twitter
– @c2b2consulting
• Follow me on twitter
– @mbrasier
• View our SOA Suite resources page
– http://info.c2b2.co.uk/soa-suite-resources

38. Questions?