Watch SL’s 3rd webinar in the “Redefining End-to-End Monitoring” series. We will demystify how RTView Enterprise Monitor’s service model integration helps you make sense of the reams of monitoring data across the enterprise by understanding how application and deployment environments are interdependent and how this web of interrelated software and hardware interoperate to ensure optimal application health state. Without this crucial linkage, monitoring systems lack real-world context for the information they collect and present. RTView Enterprise Monitor has a straightforward and elegant way of integrating with existing service models or CMDB implementations to capture that information (or in their absence, create a service model through auto-discovery), and using that information to identify, organize and present monitoring metrics in line with the way customers have allocated their IT assets.
Citation preview
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 1
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 2
E-Commerce App Billing App
Trading App Customer Service App
Complex Multi-tier Architectureshellip
bull Resource pooling and shared services
bull Multiple tiers multiple vendors
bull Exponential Growth In Data Volumes and users
bull 247 operating windows
bull Real-time performance requirements
bull Global distributed data centers operations
Presenter
Presentation Notes
The demands on applications have grown significantly in recent years as organizations expand their customer reach worldwide and are expected to ensure 247 responsiveness for customers and employees alike At the same time the architectures that support those applications have in turn become more complex ndash with a growing number of interdependent middle-tier components deployed across global data centers with specialized often local teams in place to ensure optimal performance and availability for those components Moreover many of these underlying components are often pooled and allocated to applications dynamically Keeping track of which components belong to which applications has become a daunting task and often times organizations fail to understand these environments holistically and how they tie back to the business itself
Part of the problem is that traditional monitoring tools have been focused on the infrastructure silos common in most data centers Hardware databases app servers VMs ndash organizations and teams have grown up around each of these computing silos and for good reason Expertise often requires specialization and IT has become very adept at monitoring each of these specialized silos independently But whatrsquos been missing from the traditional monitoring approach is the ability to see across these silos ndash from 30000 feet ndash to understand the interdependence across them which pieces require which others to ensure application heath what an alert in one silo means when viewed alongside another And how to find the source of a a problem without really understanding how all these pieces work together1313Whatrsquos needed is a way to the hard work of normalizing the data aggregating it correlating across it analyzing it and predicting and taking proactive steps to address problems before they become problems1313Traditional monitoring has imposed a wall over these silos making it impossible to view them as part of an intertwined web of dependencies divorced from the applications that theyrsquore in business to serve
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 4
Redefining End-to-End Monitoring
bull Unifies sources to enable visibility and insight into application health
ndash Integrated application-level view
ndash Real-world context
ndash Drill-down into supporting performance data
ndash Real-time and historical data analysis
E-Commerce App Billing App
Customer Service App Trading App
End
-to-E
nd M
onito
ring
Presenter
Presentation Notes
Whatrsquos required in the face of this increasing complexity is a new kind of monitoring ndash End-to-End Monitoring Not the old definition of end-to-end digging down into the code transactions or logs to see every granular detail But a redefined end to end monitoring one that unifies data sources to promote 360-degree visibility across applications and the IT resources that drive them Real end-to-end monitoring allows for application- and infrastructure-level views with complex access to real-time and historical performance and availability metrics events and trends 1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 5
Silos vs Application-Level Monitoring
bull Applications drive the business bull Application owners require visibility into
healthstate bull Visibility must be configurable by role bull Visibility must span network to application level ndash
through bull Prioritization by application criticality
Presenter
Presentation Notes
The important thing to realize about silos is that they provide an incomplete view of the factors contributing to application healthstate and how to prioritize attention to these factors Itrsquos applications themselves that drive the business not the hardware middleware or other pieces of the puzzle More importantly visibility into holistic application health is something that the business needs not just specialized IT teams Application owners need advance warning if something is wrong and the ability to identify who to call Thus visibility needs to be configurable by role and provide a view from the network level all the way up to the application across all tiers and provide the flexibility to move up or down the stack from any entry point Lastly all teams need a way to prioritize alerts based not only on the severity of the problem but also on how critical the application is to the business
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 6
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 7
Real-world Context Required
bull Thousands of boxes oceans of alerts bull Dynamic pools of virtual resources bull Connect the dots bull Distribute the data
ndash Democritization of healthstate intelligence
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 8
Service Model Integration ndash Maturity Curve
Maturity 1 Notifications
Maturity 2 Event
Management
Maturity 3 End-to-End
Maturity 4 Service
DeskTrouble Ticket
Integration
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 9
Attempts to move away from Silos - Maturity1 Notifications
bull Line of Business just panics with this info so often are not even included bull AppSupportDev eventually ignore these notifications because it is noise bull Operations only use it as indicators to go look at the siloed monitors
Physical Infrastructure
Storage
Middleware
APM
Log files
Email SMS
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
Before we get into the technical aspects of the RTView EM service model I wanted to provide some context to explain the benefits of a service model in the daily workflow of managing application health Most organizations have various roles which have interest in service health The Line of Business has interests in understanding the level of service provided to their customers Operations is the first line support and has expertise on all the components of the hardware and software infrastructure but has limited understanding of application architecture The Application Support and development teams have a deep understanding of the architecture of the app and are called in when Operations identifies issues that require their expertise1313As organizations grow and expand to multiple technologies to support their applications each technology often comes with its own administration and monitoring tools The challenge then becomes how to get the correct information to the right people how to analyze the situation across multiple technologies and ultimately resolve problems before they affect end users1313The first approach is often to just provide Email or SMS notifications from issues discovered in the siloed monitors to the teams Even small organizations can then deal with 1000s of notifications per day when this is initiated This is often not even implemented for the Line of Business because it would just cause panic with no context as to whether any of this information will affect service levels It is however often implemented for the App Support and Dev teams yet usually they end up ignoring this information because it becomes noise where they cannot differentiate when an event is something the Operations teams will handle as part of daily operations or one that will require their expertise1313In practice this model often works like this The Operations teams are the only ones that look at the notifications Over time and with practice they discover which events are interesting The events then point them to which siloed admin and monitoring tools to use for analysis After analysis it they discover the event indicates some action needs to be taken they enter it into their trouble ticket system The trouble ticket system then may work in a completely siloed manner where the workflow necessary to resolve the situation has limited context with the event that initiated the ticket This process is obviously time consuming error prone and requires some deep analysis expertise by the Operators And there is very limited proactive measures available for the App Support or Dev teams They only are brought into the process if Operations manually indicate to them that something must be done
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 10
Attempts to move away from Silos ndash Maturity 2 Event Management
bull Line of Business just panics with this info so often are not even included bull Events are centralized to help manage ownership between teams bull Only events are available so all teams go back to silos for analysis bull No context available to help prioritize events
PhysicalVirt Infrastructure
Storage
Middleware
APM
Log files
Event Management
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
Event Management tools work as an aggregator of alert events provided from multiple sources This allows better management of alerts by various teams These tools provide a way for multiple teams to visually look at lists of alerts filter alerts to find ones of interest and perform actions on the alerts to indicate status such as close suppress or own These teams can then work in a much more coordinated effort to determine who needs to analyze the alert and after analysis determine if a trouble ticket should be raised1313There are some limitations with this mode of operation Event Management tools often only have alert events they do not have access to any of the performance data that raised the event Therefore each team still must go to the siloed systems to do analysis This mode also requires some deep knowledge in order to solve a problem which requires some analysis across technologies It is also very difficult to determine how to prioritize the event or determine which teams need to have access to it because there is no context between the event and the services it impacts or which team cares
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 11
Attempts to move away from Silos ndash Maturity 3 End to End
bull Summary views that make sense to all teams bull Filtered alerts that apply only to the interests of the teams bull All info available in one spot to conduct analysis and raise trouble tickets bull The dynamic service model provides context for prioritization
Physical Infrastructure
Storage
Middleware
APM
Log files
RTView EM Event Management
Cross correlation analysis Dynamic Service Model
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
If you have existing Event Management tools RTView EM can easily integrate with them however many of our customers who donrsquot are benefiting by leaping from Maturity level 0 to Maturity level three by using RTView EM as the Event Management Cross correlation analysis and Dynamic Service Model all in one This drastically changes the work flow and efficiency in proactive care and problem resolution1313Here is how the lives change for each user13Line of Business13They can finally get a view of what is going on that makes sense to them Including views of applications and services that they own and their current and historical health state1313Operations13They finally get out of the mode of having to visit hundreds of siloed admin tools to do analysis All the information is at their finger tips with deep out of the box correlation views of component health state13They can view health state across technologies or by service13They can use the service model criticality to quickly determine the issues of deep impact to the business and prioritize what must be done first1313App Support and Development13They finally get something more than noise and can be proactive13They get top level views of application and service level health state that are applicable to only their apps13They can filter out low level infrastructure based alerts and focus on the ones that might have app impact13They can drill down to the component level health that are supporting their apps to do deep analysis (In most organizations the app teams do not have access to the siloed admin tools so they fly blind without the necessary data)1313And ALL teams benefit from having a central place that all teams can use to manage analysis efforts1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 12
Attempts to move away from Silos ndash Maturity 4 Integration with Service DeskTrouble Ticketing
Physical Infrastructure
Storage
Middleware
APM
Log files
RTView EM Event Management
Cross correlation analysis Dynamic Service Model
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
bull Bi-directional integration with Trouble Ticket systems bull When analysis indicates an event requires action the trouble ticket
can be manually initiated in RTView EM bull RTView EM rules can be created to auto-create trouble tickets bull RTView event management can provide info about the status of the
trouble ticket
Presenter
Presentation Notes
There is another level that some customers do to make the path to resolution even more manageable And that is integration between RTView EM and the Service DeskTrouble ticketing system Often times the Trouble ticket system is a silo of its own When support teams raise a ticket there is no correlation between event management and the state of the tasks that must be completed to resolve the problem1313With this workflow support teams after analysis will raise a trouble ticket correlated with an event in RTView EM They click on the alert and choose ldquoRaise trouble ticketrdquo RTView EM then provides information to the trouble ticket system correlating the alert event ID The Trouble Ticket system then provides state information about that ticket back to RTView EM1313Support teams can then look at a list of events that need analysis see which ones have already been marked for resolution in the trouble ticket system and see when the necessary tasks needed to resolve the issue have been completed1313It is also possible to automate a trouble ticket For example some events users know if they ever happen a trouble ticket should be generated Others might require some analysis and are preferably initiated by the user1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 13
RTView EM Architecture
Display Server
Config Server
Alert Server
Rules Engine
Cache Map
Dev QA Ops
Solution Packages (Distributed Data Servers)
EM Server Layer
EM Metadata
Layer
Data Server Layer
Presenter
Presentation Notes
So now that I have gone over some context about how a Dynamic Service Model can have great value in your support work flow I want to cover a little bit about how that is done in RTView EM13First this look at the EM architecture There are three components that are related to providing the service model benefits to end users13 The Config Server is used as a proxy to gather all inputs to your service model13 The Alert Server is used to get the service model from the Config server create the in-memory Dynamic Service Model and perform the calculations necessary to determine the health state of your model using the collection of all real time alert information it is gathering from multiple sources13 The Display Server is used to provide the role based views which give each user their specialized view into the service model and related alerts13
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 14
Service Model ndash Organizing the Enterprise
bull Associates individual architecture components hierarchically with application services organizations and roles ndash both static and dynamic information
bull Enables identification of service impact for an individual component problem
bull Can be organized along lines of business support models or any way that facilitates end users accessing the information they need
Owner
Area
Group
Service
JPeters
Operations- US
Mortgage Derivatives
Trading amp Operations
Middleware Analytics Inventory
RMorrissey
Workflow Inventory Mgmt Order Mgmt
CI CI CI CI CI CI CI
Presenter
Presentation Notes
The Service Model is used to designate the individuals and groups in your organization that have interest in or are responsible for the health state of your applications services or application infrastructure The top part is more static and changes only during re-orgs the bottom part is more dynamic and changes as new services and supporting CIrsquos are added to your systems A CI stands for a ldquoConfiguration Itemrdquo and indicates an item that is being monitored For example it might be a physical server a virtual server a database an application server or another piece of middleware1313The levels in the tree can flexible for your use case For example a ldquoServicerdquo might be a true service or application but it could also be something more aligned to support team management such as the ldquoWeb Logicrdquo service which captures many Weblogic server clusters1313Associated in the Service Model is the notion of criticality Particular services or CIs can be given a criticality level to help in the prioritization of components that deeply affect a service and services that deeply impact the business1313The main role of the Service Model is to get the information to the correct people and in a form that they can prioritize and act upon131313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 15
Flexibility ndash Multiple Inputs Custom or Off-the-Shelf
bull Integration layer enables aggregation of service model information from multiple sources ndash Asset Management
systems ndash Change Management
systems ndash HelpdeskService Desk
systems ndash Others
bull Auto-discovery bull Service Model editor
RTView Config Server
Helpdesk DB
Asset Mgmt
DB
Provisioning Metadata
Service Model Editor
Presenter
Presentation Notes
Organizations have many varied sources for their service model and RTView EM provides simple integration steps for including those sources of data and joining them together to form a complete model Parts of the model may come from Asset and Change management systems or even from your Service Desk systems RTView EM also has auto discovery features which can detect a new CI and automatically associate it with a Service And finally there is the Service Model editor which is an interface in RTView EM which allows users to configure or modify the service model themselves In many medium size organizations with 20-50 applications to monitor they choose just to manually manage the service model either because they do not have any existing sources of data or because it is a relatively small effort that it doesnrsquot justify an integration with other data sources
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 16
The Dynamic Service Model at Work
bull The Dynamic Service Model is an in-memory real-time model of the health state of your systems
bull Real time alerts and alert severities are used along with the criticality of the component or service to determine the health state of any leaf of the service hierarchy
bull End users each have their specific defined view into the service hierarchy to ensure relevance to individual areas of responsibility
End User
Dynamic Service Model
Real time Alerts Service Hierarchy
Presenter
Presentation Notes
What the in memory service model does
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 17
Cross-Correlation and Click-through
1 High level business service impacted
2 Drill down to view component dependencies
3 Identify individual component issue with historical detail
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 18
Application Service-Centric Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 19
bull Overall health state of a service
bull Current health state of each underlying component
bull Prioritize service alerts by criticality and impact
Drill-down into Tabular Cross-Correlation
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 20
And to the the Component Level
Drill down to individual component to view metric history over a configurable time period
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 21
Advanced Visualizations Services Area History Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 22
Getting the Right Info to the Right People
bull Extremely Flexible bull Provides automatic role-based views of
digestible intelligence bull Helps prioritize issues that impact your
business bull Becomes a key tool in proactive
efficient and collaborative management of your systems Without a Service Model Users see only a sea of
alerts with no prioritization by criticality or role
Presenter
Presentation Notes
Needs work but here is where I will re-state value13Decentralize monitoring and alerting 13The alert management system in a large enterprise could have thousands of active alerts at any one time The overwhelming task of wading through these to find what matters is left up to users often with a home-grown filtering solution Providing (useful) summary reports to management is next to impossible13Multiple application groups each with its own manager and support people 13Each application is dependent on a specific set of underlying infrastructure and middleware components RTView can be configured to maintain a ldquoService Modelrdquo a hierarchical arrangement of all components into applications and groups to which they belong This model can be manually created auto-populated in many cases from application metadata or imported from an external CMDB13Present digestible Monitoring Intelligence 13Every user who logs into RTView is assigned a ldquorolerdquo which can be associated with a list of applications or groups for which that role is responsible All alerts and monitoring metrics are filtered so the user sees only what is relevant to that assigned role This dramatically reduces the amount of time wasted searching through irrelevant data or responding to alerts that someone else should be handling13Automatic creation of summary views 13A business area manager may want to see just a few redambergreen lights showing the health state of the applications in that department When an indicator goes red the right support person can be called Chances are that person has seen the same indicator and has already started investigating by drilling down to the detail data that was propagated up to the summary view This is a vast improvement over the traditional model in which the ldquoall-handsrdquo war-room meetings are called to troubleshoot serious issues1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 23
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
Assume I pass back to you13In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 24
copy 2012 SL Corporation All Rights Reserved
Select RTView Customers
Financial Services
Other
eCommerce Retail
Energy Telecom
500+ RTView
Customers
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 25
For More Information
Visit us at SLcom
Request a WebEx Demo
Start an Evaluation
Watch a Video
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 26
Thank You
Questions
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 2
E-Commerce App Billing App
Trading App Customer Service App
Complex Multi-tier Architectureshellip
bull Resource pooling and shared services
bull Multiple tiers multiple vendors
bull Exponential Growth In Data Volumes and users
bull 247 operating windows
bull Real-time performance requirements
bull Global distributed data centers operations
Presenter
Presentation Notes
The demands on applications have grown significantly in recent years as organizations expand their customer reach worldwide and are expected to ensure 247 responsiveness for customers and employees alike At the same time the architectures that support those applications have in turn become more complex ndash with a growing number of interdependent middle-tier components deployed across global data centers with specialized often local teams in place to ensure optimal performance and availability for those components Moreover many of these underlying components are often pooled and allocated to applications dynamically Keeping track of which components belong to which applications has become a daunting task and often times organizations fail to understand these environments holistically and how they tie back to the business itself
Part of the problem is that traditional monitoring tools have been focused on the infrastructure silos common in most data centers Hardware databases app servers VMs ndash organizations and teams have grown up around each of these computing silos and for good reason Expertise often requires specialization and IT has become very adept at monitoring each of these specialized silos independently But whatrsquos been missing from the traditional monitoring approach is the ability to see across these silos ndash from 30000 feet ndash to understand the interdependence across them which pieces require which others to ensure application heath what an alert in one silo means when viewed alongside another And how to find the source of a a problem without really understanding how all these pieces work together1313Whatrsquos needed is a way to the hard work of normalizing the data aggregating it correlating across it analyzing it and predicting and taking proactive steps to address problems before they become problems1313Traditional monitoring has imposed a wall over these silos making it impossible to view them as part of an intertwined web of dependencies divorced from the applications that theyrsquore in business to serve
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 4
Redefining End-to-End Monitoring
bull Unifies sources to enable visibility and insight into application health
ndash Integrated application-level view
ndash Real-world context
ndash Drill-down into supporting performance data
ndash Real-time and historical data analysis
E-Commerce App Billing App
Customer Service App Trading App
End
-to-E
nd M
onito
ring
Presenter
Presentation Notes
Whatrsquos required in the face of this increasing complexity is a new kind of monitoring ndash End-to-End Monitoring Not the old definition of end-to-end digging down into the code transactions or logs to see every granular detail But a redefined end to end monitoring one that unifies data sources to promote 360-degree visibility across applications and the IT resources that drive them Real end-to-end monitoring allows for application- and infrastructure-level views with complex access to real-time and historical performance and availability metrics events and trends 1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 5
Silos vs Application-Level Monitoring
bull Applications drive the business bull Application owners require visibility into
healthstate bull Visibility must be configurable by role bull Visibility must span network to application level ndash
through bull Prioritization by application criticality
Presenter
Presentation Notes
The important thing to realize about silos is that they provide an incomplete view of the factors contributing to application healthstate and how to prioritize attention to these factors Itrsquos applications themselves that drive the business not the hardware middleware or other pieces of the puzzle More importantly visibility into holistic application health is something that the business needs not just specialized IT teams Application owners need advance warning if something is wrong and the ability to identify who to call Thus visibility needs to be configurable by role and provide a view from the network level all the way up to the application across all tiers and provide the flexibility to move up or down the stack from any entry point Lastly all teams need a way to prioritize alerts based not only on the severity of the problem but also on how critical the application is to the business
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 6
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 7
Real-world Context Required
bull Thousands of boxes oceans of alerts bull Dynamic pools of virtual resources bull Connect the dots bull Distribute the data
ndash Democritization of healthstate intelligence
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 8
Service Model Integration ndash Maturity Curve
Maturity 1 Notifications
Maturity 2 Event
Management
Maturity 3 End-to-End
Maturity 4 Service
DeskTrouble Ticket
Integration
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 9
Attempts to move away from Silos - Maturity1 Notifications
bull Line of Business just panics with this info so often are not even included bull AppSupportDev eventually ignore these notifications because it is noise bull Operations only use it as indicators to go look at the siloed monitors
Physical Infrastructure
Storage
Middleware
APM
Log files
Email SMS
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
Before we get into the technical aspects of the RTView EM service model I wanted to provide some context to explain the benefits of a service model in the daily workflow of managing application health Most organizations have various roles which have interest in service health The Line of Business has interests in understanding the level of service provided to their customers Operations is the first line support and has expertise on all the components of the hardware and software infrastructure but has limited understanding of application architecture The Application Support and development teams have a deep understanding of the architecture of the app and are called in when Operations identifies issues that require their expertise1313As organizations grow and expand to multiple technologies to support their applications each technology often comes with its own administration and monitoring tools The challenge then becomes how to get the correct information to the right people how to analyze the situation across multiple technologies and ultimately resolve problems before they affect end users1313The first approach is often to just provide Email or SMS notifications from issues discovered in the siloed monitors to the teams Even small organizations can then deal with 1000s of notifications per day when this is initiated This is often not even implemented for the Line of Business because it would just cause panic with no context as to whether any of this information will affect service levels It is however often implemented for the App Support and Dev teams yet usually they end up ignoring this information because it becomes noise where they cannot differentiate when an event is something the Operations teams will handle as part of daily operations or one that will require their expertise1313In practice this model often works like this The Operations teams are the only ones that look at the notifications Over time and with practice they discover which events are interesting The events then point them to which siloed admin and monitoring tools to use for analysis After analysis it they discover the event indicates some action needs to be taken they enter it into their trouble ticket system The trouble ticket system then may work in a completely siloed manner where the workflow necessary to resolve the situation has limited context with the event that initiated the ticket This process is obviously time consuming error prone and requires some deep analysis expertise by the Operators And there is very limited proactive measures available for the App Support or Dev teams They only are brought into the process if Operations manually indicate to them that something must be done
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 10
Attempts to move away from Silos ndash Maturity 2 Event Management
bull Line of Business just panics with this info so often are not even included bull Events are centralized to help manage ownership between teams bull Only events are available so all teams go back to silos for analysis bull No context available to help prioritize events
PhysicalVirt Infrastructure
Storage
Middleware
APM
Log files
Event Management
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
Event Management tools work as an aggregator of alert events provided from multiple sources This allows better management of alerts by various teams These tools provide a way for multiple teams to visually look at lists of alerts filter alerts to find ones of interest and perform actions on the alerts to indicate status such as close suppress or own These teams can then work in a much more coordinated effort to determine who needs to analyze the alert and after analysis determine if a trouble ticket should be raised1313There are some limitations with this mode of operation Event Management tools often only have alert events they do not have access to any of the performance data that raised the event Therefore each team still must go to the siloed systems to do analysis This mode also requires some deep knowledge in order to solve a problem which requires some analysis across technologies It is also very difficult to determine how to prioritize the event or determine which teams need to have access to it because there is no context between the event and the services it impacts or which team cares
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 11
Attempts to move away from Silos ndash Maturity 3 End to End
bull Summary views that make sense to all teams bull Filtered alerts that apply only to the interests of the teams bull All info available in one spot to conduct analysis and raise trouble tickets bull The dynamic service model provides context for prioritization
Physical Infrastructure
Storage
Middleware
APM
Log files
RTView EM Event Management
Cross correlation analysis Dynamic Service Model
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
If you have existing Event Management tools RTView EM can easily integrate with them however many of our customers who donrsquot are benefiting by leaping from Maturity level 0 to Maturity level three by using RTView EM as the Event Management Cross correlation analysis and Dynamic Service Model all in one This drastically changes the work flow and efficiency in proactive care and problem resolution1313Here is how the lives change for each user13Line of Business13They can finally get a view of what is going on that makes sense to them Including views of applications and services that they own and their current and historical health state1313Operations13They finally get out of the mode of having to visit hundreds of siloed admin tools to do analysis All the information is at their finger tips with deep out of the box correlation views of component health state13They can view health state across technologies or by service13They can use the service model criticality to quickly determine the issues of deep impact to the business and prioritize what must be done first1313App Support and Development13They finally get something more than noise and can be proactive13They get top level views of application and service level health state that are applicable to only their apps13They can filter out low level infrastructure based alerts and focus on the ones that might have app impact13They can drill down to the component level health that are supporting their apps to do deep analysis (In most organizations the app teams do not have access to the siloed admin tools so they fly blind without the necessary data)1313And ALL teams benefit from having a central place that all teams can use to manage analysis efforts1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 12
Attempts to move away from Silos ndash Maturity 4 Integration with Service DeskTrouble Ticketing
Physical Infrastructure
Storage
Middleware
APM
Log files
RTView EM Event Management
Cross correlation analysis Dynamic Service Model
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
bull Bi-directional integration with Trouble Ticket systems bull When analysis indicates an event requires action the trouble ticket
can be manually initiated in RTView EM bull RTView EM rules can be created to auto-create trouble tickets bull RTView event management can provide info about the status of the
trouble ticket
Presenter
Presentation Notes
There is another level that some customers do to make the path to resolution even more manageable And that is integration between RTView EM and the Service DeskTrouble ticketing system Often times the Trouble ticket system is a silo of its own When support teams raise a ticket there is no correlation between event management and the state of the tasks that must be completed to resolve the problem1313With this workflow support teams after analysis will raise a trouble ticket correlated with an event in RTView EM They click on the alert and choose ldquoRaise trouble ticketrdquo RTView EM then provides information to the trouble ticket system correlating the alert event ID The Trouble Ticket system then provides state information about that ticket back to RTView EM1313Support teams can then look at a list of events that need analysis see which ones have already been marked for resolution in the trouble ticket system and see when the necessary tasks needed to resolve the issue have been completed1313It is also possible to automate a trouble ticket For example some events users know if they ever happen a trouble ticket should be generated Others might require some analysis and are preferably initiated by the user1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 13
RTView EM Architecture
Display Server
Config Server
Alert Server
Rules Engine
Cache Map
Dev QA Ops
Solution Packages (Distributed Data Servers)
EM Server Layer
EM Metadata
Layer
Data Server Layer
Presenter
Presentation Notes
So now that I have gone over some context about how a Dynamic Service Model can have great value in your support work flow I want to cover a little bit about how that is done in RTView EM13First this look at the EM architecture There are three components that are related to providing the service model benefits to end users13 The Config Server is used as a proxy to gather all inputs to your service model13 The Alert Server is used to get the service model from the Config server create the in-memory Dynamic Service Model and perform the calculations necessary to determine the health state of your model using the collection of all real time alert information it is gathering from multiple sources13 The Display Server is used to provide the role based views which give each user their specialized view into the service model and related alerts13
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 14
Service Model ndash Organizing the Enterprise
bull Associates individual architecture components hierarchically with application services organizations and roles ndash both static and dynamic information
bull Enables identification of service impact for an individual component problem
bull Can be organized along lines of business support models or any way that facilitates end users accessing the information they need
Owner
Area
Group
Service
JPeters
Operations- US
Mortgage Derivatives
Trading amp Operations
Middleware Analytics Inventory
RMorrissey
Workflow Inventory Mgmt Order Mgmt
CI CI CI CI CI CI CI
Presenter
Presentation Notes
The Service Model is used to designate the individuals and groups in your organization that have interest in or are responsible for the health state of your applications services or application infrastructure The top part is more static and changes only during re-orgs the bottom part is more dynamic and changes as new services and supporting CIrsquos are added to your systems A CI stands for a ldquoConfiguration Itemrdquo and indicates an item that is being monitored For example it might be a physical server a virtual server a database an application server or another piece of middleware1313The levels in the tree can flexible for your use case For example a ldquoServicerdquo might be a true service or application but it could also be something more aligned to support team management such as the ldquoWeb Logicrdquo service which captures many Weblogic server clusters1313Associated in the Service Model is the notion of criticality Particular services or CIs can be given a criticality level to help in the prioritization of components that deeply affect a service and services that deeply impact the business1313The main role of the Service Model is to get the information to the correct people and in a form that they can prioritize and act upon131313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 15
Flexibility ndash Multiple Inputs Custom or Off-the-Shelf
bull Integration layer enables aggregation of service model information from multiple sources ndash Asset Management
systems ndash Change Management
systems ndash HelpdeskService Desk
systems ndash Others
bull Auto-discovery bull Service Model editor
RTView Config Server
Helpdesk DB
Asset Mgmt
DB
Provisioning Metadata
Service Model Editor
Presenter
Presentation Notes
Organizations have many varied sources for their service model and RTView EM provides simple integration steps for including those sources of data and joining them together to form a complete model Parts of the model may come from Asset and Change management systems or even from your Service Desk systems RTView EM also has auto discovery features which can detect a new CI and automatically associate it with a Service And finally there is the Service Model editor which is an interface in RTView EM which allows users to configure or modify the service model themselves In many medium size organizations with 20-50 applications to monitor they choose just to manually manage the service model either because they do not have any existing sources of data or because it is a relatively small effort that it doesnrsquot justify an integration with other data sources
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 16
The Dynamic Service Model at Work
bull The Dynamic Service Model is an in-memory real-time model of the health state of your systems
bull Real time alerts and alert severities are used along with the criticality of the component or service to determine the health state of any leaf of the service hierarchy
bull End users each have their specific defined view into the service hierarchy to ensure relevance to individual areas of responsibility
End User
Dynamic Service Model
Real time Alerts Service Hierarchy
Presenter
Presentation Notes
What the in memory service model does
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 17
Cross-Correlation and Click-through
1 High level business service impacted
2 Drill down to view component dependencies
3 Identify individual component issue with historical detail
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 18
Application Service-Centric Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 19
bull Overall health state of a service
bull Current health state of each underlying component
bull Prioritize service alerts by criticality and impact
Drill-down into Tabular Cross-Correlation
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 20
And to the the Component Level
Drill down to individual component to view metric history over a configurable time period
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 21
Advanced Visualizations Services Area History Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 22
Getting the Right Info to the Right People
bull Extremely Flexible bull Provides automatic role-based views of
digestible intelligence bull Helps prioritize issues that impact your
business bull Becomes a key tool in proactive
efficient and collaborative management of your systems Without a Service Model Users see only a sea of
alerts with no prioritization by criticality or role
Presenter
Presentation Notes
Needs work but here is where I will re-state value13Decentralize monitoring and alerting 13The alert management system in a large enterprise could have thousands of active alerts at any one time The overwhelming task of wading through these to find what matters is left up to users often with a home-grown filtering solution Providing (useful) summary reports to management is next to impossible13Multiple application groups each with its own manager and support people 13Each application is dependent on a specific set of underlying infrastructure and middleware components RTView can be configured to maintain a ldquoService Modelrdquo a hierarchical arrangement of all components into applications and groups to which they belong This model can be manually created auto-populated in many cases from application metadata or imported from an external CMDB13Present digestible Monitoring Intelligence 13Every user who logs into RTView is assigned a ldquorolerdquo which can be associated with a list of applications or groups for which that role is responsible All alerts and monitoring metrics are filtered so the user sees only what is relevant to that assigned role This dramatically reduces the amount of time wasted searching through irrelevant data or responding to alerts that someone else should be handling13Automatic creation of summary views 13A business area manager may want to see just a few redambergreen lights showing the health state of the applications in that department When an indicator goes red the right support person can be called Chances are that person has seen the same indicator and has already started investigating by drilling down to the detail data that was propagated up to the summary view This is a vast improvement over the traditional model in which the ldquoall-handsrdquo war-room meetings are called to troubleshoot serious issues1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 23
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
Assume I pass back to you13In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 24
copy 2012 SL Corporation All Rights Reserved
Select RTView Customers
Financial Services
Other
eCommerce Retail
Energy Telecom
500+ RTView
Customers
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 25
For More Information
Visit us at SLcom
Request a WebEx Demo
Start an Evaluation
Watch a Video
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 26
Thank You
Questions
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Part of the problem is that traditional monitoring tools have been focused on the infrastructure silos common in most data centers Hardware databases app servers VMs ndash organizations and teams have grown up around each of these computing silos and for good reason Expertise often requires specialization and IT has become very adept at monitoring each of these specialized silos independently But whatrsquos been missing from the traditional monitoring approach is the ability to see across these silos ndash from 30000 feet ndash to understand the interdependence across them which pieces require which others to ensure application heath what an alert in one silo means when viewed alongside another And how to find the source of a a problem without really understanding how all these pieces work together1313Whatrsquos needed is a way to the hard work of normalizing the data aggregating it correlating across it analyzing it and predicting and taking proactive steps to address problems before they become problems1313Traditional monitoring has imposed a wall over these silos making it impossible to view them as part of an intertwined web of dependencies divorced from the applications that theyrsquore in business to serve
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 4
Redefining End-to-End Monitoring
bull Unifies sources to enable visibility and insight into application health
ndash Integrated application-level view
ndash Real-world context
ndash Drill-down into supporting performance data
ndash Real-time and historical data analysis
E-Commerce App Billing App
Customer Service App Trading App
End
-to-E
nd M
onito
ring
Presenter
Presentation Notes
Whatrsquos required in the face of this increasing complexity is a new kind of monitoring ndash End-to-End Monitoring Not the old definition of end-to-end digging down into the code transactions or logs to see every granular detail But a redefined end to end monitoring one that unifies data sources to promote 360-degree visibility across applications and the IT resources that drive them Real end-to-end monitoring allows for application- and infrastructure-level views with complex access to real-time and historical performance and availability metrics events and trends 1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 5
Silos vs Application-Level Monitoring
bull Applications drive the business bull Application owners require visibility into
healthstate bull Visibility must be configurable by role bull Visibility must span network to application level ndash
through bull Prioritization by application criticality
Presenter
Presentation Notes
The important thing to realize about silos is that they provide an incomplete view of the factors contributing to application healthstate and how to prioritize attention to these factors Itrsquos applications themselves that drive the business not the hardware middleware or other pieces of the puzzle More importantly visibility into holistic application health is something that the business needs not just specialized IT teams Application owners need advance warning if something is wrong and the ability to identify who to call Thus visibility needs to be configurable by role and provide a view from the network level all the way up to the application across all tiers and provide the flexibility to move up or down the stack from any entry point Lastly all teams need a way to prioritize alerts based not only on the severity of the problem but also on how critical the application is to the business
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 6
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 7
Real-world Context Required
bull Thousands of boxes oceans of alerts bull Dynamic pools of virtual resources bull Connect the dots bull Distribute the data
ndash Democritization of healthstate intelligence
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 8
Service Model Integration ndash Maturity Curve
Maturity 1 Notifications
Maturity 2 Event
Management
Maturity 3 End-to-End
Maturity 4 Service
DeskTrouble Ticket
Integration
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 9
Attempts to move away from Silos - Maturity1 Notifications
bull Line of Business just panics with this info so often are not even included bull AppSupportDev eventually ignore these notifications because it is noise bull Operations only use it as indicators to go look at the siloed monitors
Physical Infrastructure
Storage
Middleware
APM
Log files
Email SMS
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
Before we get into the technical aspects of the RTView EM service model I wanted to provide some context to explain the benefits of a service model in the daily workflow of managing application health Most organizations have various roles which have interest in service health The Line of Business has interests in understanding the level of service provided to their customers Operations is the first line support and has expertise on all the components of the hardware and software infrastructure but has limited understanding of application architecture The Application Support and development teams have a deep understanding of the architecture of the app and are called in when Operations identifies issues that require their expertise1313As organizations grow and expand to multiple technologies to support their applications each technology often comes with its own administration and monitoring tools The challenge then becomes how to get the correct information to the right people how to analyze the situation across multiple technologies and ultimately resolve problems before they affect end users1313The first approach is often to just provide Email or SMS notifications from issues discovered in the siloed monitors to the teams Even small organizations can then deal with 1000s of notifications per day when this is initiated This is often not even implemented for the Line of Business because it would just cause panic with no context as to whether any of this information will affect service levels It is however often implemented for the App Support and Dev teams yet usually they end up ignoring this information because it becomes noise where they cannot differentiate when an event is something the Operations teams will handle as part of daily operations or one that will require their expertise1313In practice this model often works like this The Operations teams are the only ones that look at the notifications Over time and with practice they discover which events are interesting The events then point them to which siloed admin and monitoring tools to use for analysis After analysis it they discover the event indicates some action needs to be taken they enter it into their trouble ticket system The trouble ticket system then may work in a completely siloed manner where the workflow necessary to resolve the situation has limited context with the event that initiated the ticket This process is obviously time consuming error prone and requires some deep analysis expertise by the Operators And there is very limited proactive measures available for the App Support or Dev teams They only are brought into the process if Operations manually indicate to them that something must be done
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 10
Attempts to move away from Silos ndash Maturity 2 Event Management
bull Line of Business just panics with this info so often are not even included bull Events are centralized to help manage ownership between teams bull Only events are available so all teams go back to silos for analysis bull No context available to help prioritize events
PhysicalVirt Infrastructure
Storage
Middleware
APM
Log files
Event Management
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
Event Management tools work as an aggregator of alert events provided from multiple sources This allows better management of alerts by various teams These tools provide a way for multiple teams to visually look at lists of alerts filter alerts to find ones of interest and perform actions on the alerts to indicate status such as close suppress or own These teams can then work in a much more coordinated effort to determine who needs to analyze the alert and after analysis determine if a trouble ticket should be raised1313There are some limitations with this mode of operation Event Management tools often only have alert events they do not have access to any of the performance data that raised the event Therefore each team still must go to the siloed systems to do analysis This mode also requires some deep knowledge in order to solve a problem which requires some analysis across technologies It is also very difficult to determine how to prioritize the event or determine which teams need to have access to it because there is no context between the event and the services it impacts or which team cares
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 11
Attempts to move away from Silos ndash Maturity 3 End to End
bull Summary views that make sense to all teams bull Filtered alerts that apply only to the interests of the teams bull All info available in one spot to conduct analysis and raise trouble tickets bull The dynamic service model provides context for prioritization
Physical Infrastructure
Storage
Middleware
APM
Log files
RTView EM Event Management
Cross correlation analysis Dynamic Service Model
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
If you have existing Event Management tools RTView EM can easily integrate with them however many of our customers who donrsquot are benefiting by leaping from Maturity level 0 to Maturity level three by using RTView EM as the Event Management Cross correlation analysis and Dynamic Service Model all in one This drastically changes the work flow and efficiency in proactive care and problem resolution1313Here is how the lives change for each user13Line of Business13They can finally get a view of what is going on that makes sense to them Including views of applications and services that they own and their current and historical health state1313Operations13They finally get out of the mode of having to visit hundreds of siloed admin tools to do analysis All the information is at their finger tips with deep out of the box correlation views of component health state13They can view health state across technologies or by service13They can use the service model criticality to quickly determine the issues of deep impact to the business and prioritize what must be done first1313App Support and Development13They finally get something more than noise and can be proactive13They get top level views of application and service level health state that are applicable to only their apps13They can filter out low level infrastructure based alerts and focus on the ones that might have app impact13They can drill down to the component level health that are supporting their apps to do deep analysis (In most organizations the app teams do not have access to the siloed admin tools so they fly blind without the necessary data)1313And ALL teams benefit from having a central place that all teams can use to manage analysis efforts1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 12
Attempts to move away from Silos ndash Maturity 4 Integration with Service DeskTrouble Ticketing
Physical Infrastructure
Storage
Middleware
APM
Log files
RTView EM Event Management
Cross correlation analysis Dynamic Service Model
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
bull Bi-directional integration with Trouble Ticket systems bull When analysis indicates an event requires action the trouble ticket
can be manually initiated in RTView EM bull RTView EM rules can be created to auto-create trouble tickets bull RTView event management can provide info about the status of the
trouble ticket
Presenter
Presentation Notes
There is another level that some customers do to make the path to resolution even more manageable And that is integration between RTView EM and the Service DeskTrouble ticketing system Often times the Trouble ticket system is a silo of its own When support teams raise a ticket there is no correlation between event management and the state of the tasks that must be completed to resolve the problem1313With this workflow support teams after analysis will raise a trouble ticket correlated with an event in RTView EM They click on the alert and choose ldquoRaise trouble ticketrdquo RTView EM then provides information to the trouble ticket system correlating the alert event ID The Trouble Ticket system then provides state information about that ticket back to RTView EM1313Support teams can then look at a list of events that need analysis see which ones have already been marked for resolution in the trouble ticket system and see when the necessary tasks needed to resolve the issue have been completed1313It is also possible to automate a trouble ticket For example some events users know if they ever happen a trouble ticket should be generated Others might require some analysis and are preferably initiated by the user1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 13
RTView EM Architecture
Display Server
Config Server
Alert Server
Rules Engine
Cache Map
Dev QA Ops
Solution Packages (Distributed Data Servers)
EM Server Layer
EM Metadata
Layer
Data Server Layer
Presenter
Presentation Notes
So now that I have gone over some context about how a Dynamic Service Model can have great value in your support work flow I want to cover a little bit about how that is done in RTView EM13First this look at the EM architecture There are three components that are related to providing the service model benefits to end users13 The Config Server is used as a proxy to gather all inputs to your service model13 The Alert Server is used to get the service model from the Config server create the in-memory Dynamic Service Model and perform the calculations necessary to determine the health state of your model using the collection of all real time alert information it is gathering from multiple sources13 The Display Server is used to provide the role based views which give each user their specialized view into the service model and related alerts13
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 14
Service Model ndash Organizing the Enterprise
bull Associates individual architecture components hierarchically with application services organizations and roles ndash both static and dynamic information
bull Enables identification of service impact for an individual component problem
bull Can be organized along lines of business support models or any way that facilitates end users accessing the information they need
Owner
Area
Group
Service
JPeters
Operations- US
Mortgage Derivatives
Trading amp Operations
Middleware Analytics Inventory
RMorrissey
Workflow Inventory Mgmt Order Mgmt
CI CI CI CI CI CI CI
Presenter
Presentation Notes
The Service Model is used to designate the individuals and groups in your organization that have interest in or are responsible for the health state of your applications services or application infrastructure The top part is more static and changes only during re-orgs the bottom part is more dynamic and changes as new services and supporting CIrsquos are added to your systems A CI stands for a ldquoConfiguration Itemrdquo and indicates an item that is being monitored For example it might be a physical server a virtual server a database an application server or another piece of middleware1313The levels in the tree can flexible for your use case For example a ldquoServicerdquo might be a true service or application but it could also be something more aligned to support team management such as the ldquoWeb Logicrdquo service which captures many Weblogic server clusters1313Associated in the Service Model is the notion of criticality Particular services or CIs can be given a criticality level to help in the prioritization of components that deeply affect a service and services that deeply impact the business1313The main role of the Service Model is to get the information to the correct people and in a form that they can prioritize and act upon131313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 15
Flexibility ndash Multiple Inputs Custom or Off-the-Shelf
bull Integration layer enables aggregation of service model information from multiple sources ndash Asset Management
systems ndash Change Management
systems ndash HelpdeskService Desk
systems ndash Others
bull Auto-discovery bull Service Model editor
RTView Config Server
Helpdesk DB
Asset Mgmt
DB
Provisioning Metadata
Service Model Editor
Presenter
Presentation Notes
Organizations have many varied sources for their service model and RTView EM provides simple integration steps for including those sources of data and joining them together to form a complete model Parts of the model may come from Asset and Change management systems or even from your Service Desk systems RTView EM also has auto discovery features which can detect a new CI and automatically associate it with a Service And finally there is the Service Model editor which is an interface in RTView EM which allows users to configure or modify the service model themselves In many medium size organizations with 20-50 applications to monitor they choose just to manually manage the service model either because they do not have any existing sources of data or because it is a relatively small effort that it doesnrsquot justify an integration with other data sources
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 16
The Dynamic Service Model at Work
bull The Dynamic Service Model is an in-memory real-time model of the health state of your systems
bull Real time alerts and alert severities are used along with the criticality of the component or service to determine the health state of any leaf of the service hierarchy
bull End users each have their specific defined view into the service hierarchy to ensure relevance to individual areas of responsibility
End User
Dynamic Service Model
Real time Alerts Service Hierarchy
Presenter
Presentation Notes
What the in memory service model does
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 17
Cross-Correlation and Click-through
1 High level business service impacted
2 Drill down to view component dependencies
3 Identify individual component issue with historical detail
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 18
Application Service-Centric Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 19
bull Overall health state of a service
bull Current health state of each underlying component
bull Prioritize service alerts by criticality and impact
Drill-down into Tabular Cross-Correlation
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 20
And to the the Component Level
Drill down to individual component to view metric history over a configurable time period
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 21
Advanced Visualizations Services Area History Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 22
Getting the Right Info to the Right People
bull Extremely Flexible bull Provides automatic role-based views of
digestible intelligence bull Helps prioritize issues that impact your
business bull Becomes a key tool in proactive
efficient and collaborative management of your systems Without a Service Model Users see only a sea of
alerts with no prioritization by criticality or role
Presenter
Presentation Notes
Needs work but here is where I will re-state value13Decentralize monitoring and alerting 13The alert management system in a large enterprise could have thousands of active alerts at any one time The overwhelming task of wading through these to find what matters is left up to users often with a home-grown filtering solution Providing (useful) summary reports to management is next to impossible13Multiple application groups each with its own manager and support people 13Each application is dependent on a specific set of underlying infrastructure and middleware components RTView can be configured to maintain a ldquoService Modelrdquo a hierarchical arrangement of all components into applications and groups to which they belong This model can be manually created auto-populated in many cases from application metadata or imported from an external CMDB13Present digestible Monitoring Intelligence 13Every user who logs into RTView is assigned a ldquorolerdquo which can be associated with a list of applications or groups for which that role is responsible All alerts and monitoring metrics are filtered so the user sees only what is relevant to that assigned role This dramatically reduces the amount of time wasted searching through irrelevant data or responding to alerts that someone else should be handling13Automatic creation of summary views 13A business area manager may want to see just a few redambergreen lights showing the health state of the applications in that department When an indicator goes red the right support person can be called Chances are that person has seen the same indicator and has already started investigating by drilling down to the detail data that was propagated up to the summary view This is a vast improvement over the traditional model in which the ldquoall-handsrdquo war-room meetings are called to troubleshoot serious issues1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 23
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
Assume I pass back to you13In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 24
copy 2012 SL Corporation All Rights Reserved
Select RTView Customers
Financial Services
Other
eCommerce Retail
Energy Telecom
500+ RTView
Customers
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 25
For More Information
Visit us at SLcom
Request a WebEx Demo
Start an Evaluation
Watch a Video
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 26
Thank You
Questions
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 4
Redefining End-to-End Monitoring
bull Unifies sources to enable visibility and insight into application health
ndash Integrated application-level view
ndash Real-world context
ndash Drill-down into supporting performance data
ndash Real-time and historical data analysis
E-Commerce App Billing App
Customer Service App Trading App
End
-to-E
nd M
onito
ring
Presenter
Presentation Notes
Whatrsquos required in the face of this increasing complexity is a new kind of monitoring ndash End-to-End Monitoring Not the old definition of end-to-end digging down into the code transactions or logs to see every granular detail But a redefined end to end monitoring one that unifies data sources to promote 360-degree visibility across applications and the IT resources that drive them Real end-to-end monitoring allows for application- and infrastructure-level views with complex access to real-time and historical performance and availability metrics events and trends 1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 5
Silos vs Application-Level Monitoring
bull Applications drive the business bull Application owners require visibility into
healthstate bull Visibility must be configurable by role bull Visibility must span network to application level ndash
through bull Prioritization by application criticality
Presenter
Presentation Notes
The important thing to realize about silos is that they provide an incomplete view of the factors contributing to application healthstate and how to prioritize attention to these factors Itrsquos applications themselves that drive the business not the hardware middleware or other pieces of the puzzle More importantly visibility into holistic application health is something that the business needs not just specialized IT teams Application owners need advance warning if something is wrong and the ability to identify who to call Thus visibility needs to be configurable by role and provide a view from the network level all the way up to the application across all tiers and provide the flexibility to move up or down the stack from any entry point Lastly all teams need a way to prioritize alerts based not only on the severity of the problem but also on how critical the application is to the business
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 6
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 7
Real-world Context Required
bull Thousands of boxes oceans of alerts bull Dynamic pools of virtual resources bull Connect the dots bull Distribute the data
ndash Democritization of healthstate intelligence
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 8
Service Model Integration ndash Maturity Curve
Maturity 1 Notifications
Maturity 2 Event
Management
Maturity 3 End-to-End
Maturity 4 Service
DeskTrouble Ticket
Integration
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 9
Attempts to move away from Silos - Maturity1 Notifications
bull Line of Business just panics with this info so often are not even included bull AppSupportDev eventually ignore these notifications because it is noise bull Operations only use it as indicators to go look at the siloed monitors
Physical Infrastructure
Storage
Middleware
APM
Log files
Email SMS
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
Before we get into the technical aspects of the RTView EM service model I wanted to provide some context to explain the benefits of a service model in the daily workflow of managing application health Most organizations have various roles which have interest in service health The Line of Business has interests in understanding the level of service provided to their customers Operations is the first line support and has expertise on all the components of the hardware and software infrastructure but has limited understanding of application architecture The Application Support and development teams have a deep understanding of the architecture of the app and are called in when Operations identifies issues that require their expertise1313As organizations grow and expand to multiple technologies to support their applications each technology often comes with its own administration and monitoring tools The challenge then becomes how to get the correct information to the right people how to analyze the situation across multiple technologies and ultimately resolve problems before they affect end users1313The first approach is often to just provide Email or SMS notifications from issues discovered in the siloed monitors to the teams Even small organizations can then deal with 1000s of notifications per day when this is initiated This is often not even implemented for the Line of Business because it would just cause panic with no context as to whether any of this information will affect service levels It is however often implemented for the App Support and Dev teams yet usually they end up ignoring this information because it becomes noise where they cannot differentiate when an event is something the Operations teams will handle as part of daily operations or one that will require their expertise1313In practice this model often works like this The Operations teams are the only ones that look at the notifications Over time and with practice they discover which events are interesting The events then point them to which siloed admin and monitoring tools to use for analysis After analysis it they discover the event indicates some action needs to be taken they enter it into their trouble ticket system The trouble ticket system then may work in a completely siloed manner where the workflow necessary to resolve the situation has limited context with the event that initiated the ticket This process is obviously time consuming error prone and requires some deep analysis expertise by the Operators And there is very limited proactive measures available for the App Support or Dev teams They only are brought into the process if Operations manually indicate to them that something must be done
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 10
Attempts to move away from Silos ndash Maturity 2 Event Management
bull Line of Business just panics with this info so often are not even included bull Events are centralized to help manage ownership between teams bull Only events are available so all teams go back to silos for analysis bull No context available to help prioritize events
PhysicalVirt Infrastructure
Storage
Middleware
APM
Log files
Event Management
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
Event Management tools work as an aggregator of alert events provided from multiple sources This allows better management of alerts by various teams These tools provide a way for multiple teams to visually look at lists of alerts filter alerts to find ones of interest and perform actions on the alerts to indicate status such as close suppress or own These teams can then work in a much more coordinated effort to determine who needs to analyze the alert and after analysis determine if a trouble ticket should be raised1313There are some limitations with this mode of operation Event Management tools often only have alert events they do not have access to any of the performance data that raised the event Therefore each team still must go to the siloed systems to do analysis This mode also requires some deep knowledge in order to solve a problem which requires some analysis across technologies It is also very difficult to determine how to prioritize the event or determine which teams need to have access to it because there is no context between the event and the services it impacts or which team cares
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 11
Attempts to move away from Silos ndash Maturity 3 End to End
bull Summary views that make sense to all teams bull Filtered alerts that apply only to the interests of the teams bull All info available in one spot to conduct analysis and raise trouble tickets bull The dynamic service model provides context for prioritization
Physical Infrastructure
Storage
Middleware
APM
Log files
RTView EM Event Management
Cross correlation analysis Dynamic Service Model
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
If you have existing Event Management tools RTView EM can easily integrate with them however many of our customers who donrsquot are benefiting by leaping from Maturity level 0 to Maturity level three by using RTView EM as the Event Management Cross correlation analysis and Dynamic Service Model all in one This drastically changes the work flow and efficiency in proactive care and problem resolution1313Here is how the lives change for each user13Line of Business13They can finally get a view of what is going on that makes sense to them Including views of applications and services that they own and their current and historical health state1313Operations13They finally get out of the mode of having to visit hundreds of siloed admin tools to do analysis All the information is at their finger tips with deep out of the box correlation views of component health state13They can view health state across technologies or by service13They can use the service model criticality to quickly determine the issues of deep impact to the business and prioritize what must be done first1313App Support and Development13They finally get something more than noise and can be proactive13They get top level views of application and service level health state that are applicable to only their apps13They can filter out low level infrastructure based alerts and focus on the ones that might have app impact13They can drill down to the component level health that are supporting their apps to do deep analysis (In most organizations the app teams do not have access to the siloed admin tools so they fly blind without the necessary data)1313And ALL teams benefit from having a central place that all teams can use to manage analysis efforts1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 12
Attempts to move away from Silos ndash Maturity 4 Integration with Service DeskTrouble Ticketing
Physical Infrastructure
Storage
Middleware
APM
Log files
RTView EM Event Management
Cross correlation analysis Dynamic Service Model
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
bull Bi-directional integration with Trouble Ticket systems bull When analysis indicates an event requires action the trouble ticket
can be manually initiated in RTView EM bull RTView EM rules can be created to auto-create trouble tickets bull RTView event management can provide info about the status of the
trouble ticket
Presenter
Presentation Notes
There is another level that some customers do to make the path to resolution even more manageable And that is integration between RTView EM and the Service DeskTrouble ticketing system Often times the Trouble ticket system is a silo of its own When support teams raise a ticket there is no correlation between event management and the state of the tasks that must be completed to resolve the problem1313With this workflow support teams after analysis will raise a trouble ticket correlated with an event in RTView EM They click on the alert and choose ldquoRaise trouble ticketrdquo RTView EM then provides information to the trouble ticket system correlating the alert event ID The Trouble Ticket system then provides state information about that ticket back to RTView EM1313Support teams can then look at a list of events that need analysis see which ones have already been marked for resolution in the trouble ticket system and see when the necessary tasks needed to resolve the issue have been completed1313It is also possible to automate a trouble ticket For example some events users know if they ever happen a trouble ticket should be generated Others might require some analysis and are preferably initiated by the user1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 13
RTView EM Architecture
Display Server
Config Server
Alert Server
Rules Engine
Cache Map
Dev QA Ops
Solution Packages (Distributed Data Servers)
EM Server Layer
EM Metadata
Layer
Data Server Layer
Presenter
Presentation Notes
So now that I have gone over some context about how a Dynamic Service Model can have great value in your support work flow I want to cover a little bit about how that is done in RTView EM13First this look at the EM architecture There are three components that are related to providing the service model benefits to end users13 The Config Server is used as a proxy to gather all inputs to your service model13 The Alert Server is used to get the service model from the Config server create the in-memory Dynamic Service Model and perform the calculations necessary to determine the health state of your model using the collection of all real time alert information it is gathering from multiple sources13 The Display Server is used to provide the role based views which give each user their specialized view into the service model and related alerts13
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 14
Service Model ndash Organizing the Enterprise
bull Associates individual architecture components hierarchically with application services organizations and roles ndash both static and dynamic information
bull Enables identification of service impact for an individual component problem
bull Can be organized along lines of business support models or any way that facilitates end users accessing the information they need
Owner
Area
Group
Service
JPeters
Operations- US
Mortgage Derivatives
Trading amp Operations
Middleware Analytics Inventory
RMorrissey
Workflow Inventory Mgmt Order Mgmt
CI CI CI CI CI CI CI
Presenter
Presentation Notes
The Service Model is used to designate the individuals and groups in your organization that have interest in or are responsible for the health state of your applications services or application infrastructure The top part is more static and changes only during re-orgs the bottom part is more dynamic and changes as new services and supporting CIrsquos are added to your systems A CI stands for a ldquoConfiguration Itemrdquo and indicates an item that is being monitored For example it might be a physical server a virtual server a database an application server or another piece of middleware1313The levels in the tree can flexible for your use case For example a ldquoServicerdquo might be a true service or application but it could also be something more aligned to support team management such as the ldquoWeb Logicrdquo service which captures many Weblogic server clusters1313Associated in the Service Model is the notion of criticality Particular services or CIs can be given a criticality level to help in the prioritization of components that deeply affect a service and services that deeply impact the business1313The main role of the Service Model is to get the information to the correct people and in a form that they can prioritize and act upon131313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 15
Flexibility ndash Multiple Inputs Custom or Off-the-Shelf
bull Integration layer enables aggregation of service model information from multiple sources ndash Asset Management
systems ndash Change Management
systems ndash HelpdeskService Desk
systems ndash Others
bull Auto-discovery bull Service Model editor
RTView Config Server
Helpdesk DB
Asset Mgmt
DB
Provisioning Metadata
Service Model Editor
Presenter
Presentation Notes
Organizations have many varied sources for their service model and RTView EM provides simple integration steps for including those sources of data and joining them together to form a complete model Parts of the model may come from Asset and Change management systems or even from your Service Desk systems RTView EM also has auto discovery features which can detect a new CI and automatically associate it with a Service And finally there is the Service Model editor which is an interface in RTView EM which allows users to configure or modify the service model themselves In many medium size organizations with 20-50 applications to monitor they choose just to manually manage the service model either because they do not have any existing sources of data or because it is a relatively small effort that it doesnrsquot justify an integration with other data sources
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 16
The Dynamic Service Model at Work
bull The Dynamic Service Model is an in-memory real-time model of the health state of your systems
bull Real time alerts and alert severities are used along with the criticality of the component or service to determine the health state of any leaf of the service hierarchy
bull End users each have their specific defined view into the service hierarchy to ensure relevance to individual areas of responsibility
End User
Dynamic Service Model
Real time Alerts Service Hierarchy
Presenter
Presentation Notes
What the in memory service model does
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 17
Cross-Correlation and Click-through
1 High level business service impacted
2 Drill down to view component dependencies
3 Identify individual component issue with historical detail
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 18
Application Service-Centric Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 19
bull Overall health state of a service
bull Current health state of each underlying component
bull Prioritize service alerts by criticality and impact
Drill-down into Tabular Cross-Correlation
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 20
And to the the Component Level
Drill down to individual component to view metric history over a configurable time period
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 21
Advanced Visualizations Services Area History Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 22
Getting the Right Info to the Right People
bull Extremely Flexible bull Provides automatic role-based views of
digestible intelligence bull Helps prioritize issues that impact your
business bull Becomes a key tool in proactive
efficient and collaborative management of your systems Without a Service Model Users see only a sea of
alerts with no prioritization by criticality or role
Presenter
Presentation Notes
Needs work but here is where I will re-state value13Decentralize monitoring and alerting 13The alert management system in a large enterprise could have thousands of active alerts at any one time The overwhelming task of wading through these to find what matters is left up to users often with a home-grown filtering solution Providing (useful) summary reports to management is next to impossible13Multiple application groups each with its own manager and support people 13Each application is dependent on a specific set of underlying infrastructure and middleware components RTView can be configured to maintain a ldquoService Modelrdquo a hierarchical arrangement of all components into applications and groups to which they belong This model can be manually created auto-populated in many cases from application metadata or imported from an external CMDB13Present digestible Monitoring Intelligence 13Every user who logs into RTView is assigned a ldquorolerdquo which can be associated with a list of applications or groups for which that role is responsible All alerts and monitoring metrics are filtered so the user sees only what is relevant to that assigned role This dramatically reduces the amount of time wasted searching through irrelevant data or responding to alerts that someone else should be handling13Automatic creation of summary views 13A business area manager may want to see just a few redambergreen lights showing the health state of the applications in that department When an indicator goes red the right support person can be called Chances are that person has seen the same indicator and has already started investigating by drilling down to the detail data that was propagated up to the summary view This is a vast improvement over the traditional model in which the ldquoall-handsrdquo war-room meetings are called to troubleshoot serious issues1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 23
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
Assume I pass back to you13In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 24
copy 2012 SL Corporation All Rights Reserved
Select RTView Customers
Financial Services
Other
eCommerce Retail
Energy Telecom
500+ RTView
Customers
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 25
For More Information
Visit us at SLcom
Request a WebEx Demo
Start an Evaluation
Watch a Video
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 26
Thank You
Questions
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 5
Silos vs Application-Level Monitoring
bull Applications drive the business bull Application owners require visibility into
healthstate bull Visibility must be configurable by role bull Visibility must span network to application level ndash
through bull Prioritization by application criticality
Presenter
Presentation Notes
The important thing to realize about silos is that they provide an incomplete view of the factors contributing to application healthstate and how to prioritize attention to these factors Itrsquos applications themselves that drive the business not the hardware middleware or other pieces of the puzzle More importantly visibility into holistic application health is something that the business needs not just specialized IT teams Application owners need advance warning if something is wrong and the ability to identify who to call Thus visibility needs to be configurable by role and provide a view from the network level all the way up to the application across all tiers and provide the flexibility to move up or down the stack from any entry point Lastly all teams need a way to prioritize alerts based not only on the severity of the problem but also on how critical the application is to the business
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 6
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 7
Real-world Context Required
bull Thousands of boxes oceans of alerts bull Dynamic pools of virtual resources bull Connect the dots bull Distribute the data
ndash Democritization of healthstate intelligence
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 8
Service Model Integration ndash Maturity Curve
Maturity 1 Notifications
Maturity 2 Event
Management
Maturity 3 End-to-End
Maturity 4 Service
DeskTrouble Ticket
Integration
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 9
Attempts to move away from Silos - Maturity1 Notifications
bull Line of Business just panics with this info so often are not even included bull AppSupportDev eventually ignore these notifications because it is noise bull Operations only use it as indicators to go look at the siloed monitors
Physical Infrastructure
Storage
Middleware
APM
Log files
Email SMS
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
Before we get into the technical aspects of the RTView EM service model I wanted to provide some context to explain the benefits of a service model in the daily workflow of managing application health Most organizations have various roles which have interest in service health The Line of Business has interests in understanding the level of service provided to their customers Operations is the first line support and has expertise on all the components of the hardware and software infrastructure but has limited understanding of application architecture The Application Support and development teams have a deep understanding of the architecture of the app and are called in when Operations identifies issues that require their expertise1313As organizations grow and expand to multiple technologies to support their applications each technology often comes with its own administration and monitoring tools The challenge then becomes how to get the correct information to the right people how to analyze the situation across multiple technologies and ultimately resolve problems before they affect end users1313The first approach is often to just provide Email or SMS notifications from issues discovered in the siloed monitors to the teams Even small organizations can then deal with 1000s of notifications per day when this is initiated This is often not even implemented for the Line of Business because it would just cause panic with no context as to whether any of this information will affect service levels It is however often implemented for the App Support and Dev teams yet usually they end up ignoring this information because it becomes noise where they cannot differentiate when an event is something the Operations teams will handle as part of daily operations or one that will require their expertise1313In practice this model often works like this The Operations teams are the only ones that look at the notifications Over time and with practice they discover which events are interesting The events then point them to which siloed admin and monitoring tools to use for analysis After analysis it they discover the event indicates some action needs to be taken they enter it into their trouble ticket system The trouble ticket system then may work in a completely siloed manner where the workflow necessary to resolve the situation has limited context with the event that initiated the ticket This process is obviously time consuming error prone and requires some deep analysis expertise by the Operators And there is very limited proactive measures available for the App Support or Dev teams They only are brought into the process if Operations manually indicate to them that something must be done
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 10
Attempts to move away from Silos ndash Maturity 2 Event Management
bull Line of Business just panics with this info so often are not even included bull Events are centralized to help manage ownership between teams bull Only events are available so all teams go back to silos for analysis bull No context available to help prioritize events
PhysicalVirt Infrastructure
Storage
Middleware
APM
Log files
Event Management
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
Event Management tools work as an aggregator of alert events provided from multiple sources This allows better management of alerts by various teams These tools provide a way for multiple teams to visually look at lists of alerts filter alerts to find ones of interest and perform actions on the alerts to indicate status such as close suppress or own These teams can then work in a much more coordinated effort to determine who needs to analyze the alert and after analysis determine if a trouble ticket should be raised1313There are some limitations with this mode of operation Event Management tools often only have alert events they do not have access to any of the performance data that raised the event Therefore each team still must go to the siloed systems to do analysis This mode also requires some deep knowledge in order to solve a problem which requires some analysis across technologies It is also very difficult to determine how to prioritize the event or determine which teams need to have access to it because there is no context between the event and the services it impacts or which team cares
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 11
Attempts to move away from Silos ndash Maturity 3 End to End
bull Summary views that make sense to all teams bull Filtered alerts that apply only to the interests of the teams bull All info available in one spot to conduct analysis and raise trouble tickets bull The dynamic service model provides context for prioritization
Physical Infrastructure
Storage
Middleware
APM
Log files
RTView EM Event Management
Cross correlation analysis Dynamic Service Model
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
If you have existing Event Management tools RTView EM can easily integrate with them however many of our customers who donrsquot are benefiting by leaping from Maturity level 0 to Maturity level three by using RTView EM as the Event Management Cross correlation analysis and Dynamic Service Model all in one This drastically changes the work flow and efficiency in proactive care and problem resolution1313Here is how the lives change for each user13Line of Business13They can finally get a view of what is going on that makes sense to them Including views of applications and services that they own and their current and historical health state1313Operations13They finally get out of the mode of having to visit hundreds of siloed admin tools to do analysis All the information is at their finger tips with deep out of the box correlation views of component health state13They can view health state across technologies or by service13They can use the service model criticality to quickly determine the issues of deep impact to the business and prioritize what must be done first1313App Support and Development13They finally get something more than noise and can be proactive13They get top level views of application and service level health state that are applicable to only their apps13They can filter out low level infrastructure based alerts and focus on the ones that might have app impact13They can drill down to the component level health that are supporting their apps to do deep analysis (In most organizations the app teams do not have access to the siloed admin tools so they fly blind without the necessary data)1313And ALL teams benefit from having a central place that all teams can use to manage analysis efforts1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 12
Attempts to move away from Silos ndash Maturity 4 Integration with Service DeskTrouble Ticketing
Physical Infrastructure
Storage
Middleware
APM
Log files
RTView EM Event Management
Cross correlation analysis Dynamic Service Model
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
bull Bi-directional integration with Trouble Ticket systems bull When analysis indicates an event requires action the trouble ticket
can be manually initiated in RTView EM bull RTView EM rules can be created to auto-create trouble tickets bull RTView event management can provide info about the status of the
trouble ticket
Presenter
Presentation Notes
There is another level that some customers do to make the path to resolution even more manageable And that is integration between RTView EM and the Service DeskTrouble ticketing system Often times the Trouble ticket system is a silo of its own When support teams raise a ticket there is no correlation between event management and the state of the tasks that must be completed to resolve the problem1313With this workflow support teams after analysis will raise a trouble ticket correlated with an event in RTView EM They click on the alert and choose ldquoRaise trouble ticketrdquo RTView EM then provides information to the trouble ticket system correlating the alert event ID The Trouble Ticket system then provides state information about that ticket back to RTView EM1313Support teams can then look at a list of events that need analysis see which ones have already been marked for resolution in the trouble ticket system and see when the necessary tasks needed to resolve the issue have been completed1313It is also possible to automate a trouble ticket For example some events users know if they ever happen a trouble ticket should be generated Others might require some analysis and are preferably initiated by the user1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 13
RTView EM Architecture
Display Server
Config Server
Alert Server
Rules Engine
Cache Map
Dev QA Ops
Solution Packages (Distributed Data Servers)
EM Server Layer
EM Metadata
Layer
Data Server Layer
Presenter
Presentation Notes
So now that I have gone over some context about how a Dynamic Service Model can have great value in your support work flow I want to cover a little bit about how that is done in RTView EM13First this look at the EM architecture There are three components that are related to providing the service model benefits to end users13 The Config Server is used as a proxy to gather all inputs to your service model13 The Alert Server is used to get the service model from the Config server create the in-memory Dynamic Service Model and perform the calculations necessary to determine the health state of your model using the collection of all real time alert information it is gathering from multiple sources13 The Display Server is used to provide the role based views which give each user their specialized view into the service model and related alerts13
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 14
Service Model ndash Organizing the Enterprise
bull Associates individual architecture components hierarchically with application services organizations and roles ndash both static and dynamic information
bull Enables identification of service impact for an individual component problem
bull Can be organized along lines of business support models or any way that facilitates end users accessing the information they need
Owner
Area
Group
Service
JPeters
Operations- US
Mortgage Derivatives
Trading amp Operations
Middleware Analytics Inventory
RMorrissey
Workflow Inventory Mgmt Order Mgmt
CI CI CI CI CI CI CI
Presenter
Presentation Notes
The Service Model is used to designate the individuals and groups in your organization that have interest in or are responsible for the health state of your applications services or application infrastructure The top part is more static and changes only during re-orgs the bottom part is more dynamic and changes as new services and supporting CIrsquos are added to your systems A CI stands for a ldquoConfiguration Itemrdquo and indicates an item that is being monitored For example it might be a physical server a virtual server a database an application server or another piece of middleware1313The levels in the tree can flexible for your use case For example a ldquoServicerdquo might be a true service or application but it could also be something more aligned to support team management such as the ldquoWeb Logicrdquo service which captures many Weblogic server clusters1313Associated in the Service Model is the notion of criticality Particular services or CIs can be given a criticality level to help in the prioritization of components that deeply affect a service and services that deeply impact the business1313The main role of the Service Model is to get the information to the correct people and in a form that they can prioritize and act upon131313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 15
Flexibility ndash Multiple Inputs Custom or Off-the-Shelf
bull Integration layer enables aggregation of service model information from multiple sources ndash Asset Management
systems ndash Change Management
systems ndash HelpdeskService Desk
systems ndash Others
bull Auto-discovery bull Service Model editor
RTView Config Server
Helpdesk DB
Asset Mgmt
DB
Provisioning Metadata
Service Model Editor
Presenter
Presentation Notes
Organizations have many varied sources for their service model and RTView EM provides simple integration steps for including those sources of data and joining them together to form a complete model Parts of the model may come from Asset and Change management systems or even from your Service Desk systems RTView EM also has auto discovery features which can detect a new CI and automatically associate it with a Service And finally there is the Service Model editor which is an interface in RTView EM which allows users to configure or modify the service model themselves In many medium size organizations with 20-50 applications to monitor they choose just to manually manage the service model either because they do not have any existing sources of data or because it is a relatively small effort that it doesnrsquot justify an integration with other data sources
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 16
The Dynamic Service Model at Work
bull The Dynamic Service Model is an in-memory real-time model of the health state of your systems
bull Real time alerts and alert severities are used along with the criticality of the component or service to determine the health state of any leaf of the service hierarchy
bull End users each have their specific defined view into the service hierarchy to ensure relevance to individual areas of responsibility
End User
Dynamic Service Model
Real time Alerts Service Hierarchy
Presenter
Presentation Notes
What the in memory service model does
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 17
Cross-Correlation and Click-through
1 High level business service impacted
2 Drill down to view component dependencies
3 Identify individual component issue with historical detail
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 18
Application Service-Centric Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 19
bull Overall health state of a service
bull Current health state of each underlying component
bull Prioritize service alerts by criticality and impact
Drill-down into Tabular Cross-Correlation
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 20
And to the the Component Level
Drill down to individual component to view metric history over a configurable time period
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 21
Advanced Visualizations Services Area History Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 22
Getting the Right Info to the Right People
bull Extremely Flexible bull Provides automatic role-based views of
digestible intelligence bull Helps prioritize issues that impact your
business bull Becomes a key tool in proactive
efficient and collaborative management of your systems Without a Service Model Users see only a sea of
alerts with no prioritization by criticality or role
Presenter
Presentation Notes
Needs work but here is where I will re-state value13Decentralize monitoring and alerting 13The alert management system in a large enterprise could have thousands of active alerts at any one time The overwhelming task of wading through these to find what matters is left up to users often with a home-grown filtering solution Providing (useful) summary reports to management is next to impossible13Multiple application groups each with its own manager and support people 13Each application is dependent on a specific set of underlying infrastructure and middleware components RTView can be configured to maintain a ldquoService Modelrdquo a hierarchical arrangement of all components into applications and groups to which they belong This model can be manually created auto-populated in many cases from application metadata or imported from an external CMDB13Present digestible Monitoring Intelligence 13Every user who logs into RTView is assigned a ldquorolerdquo which can be associated with a list of applications or groups for which that role is responsible All alerts and monitoring metrics are filtered so the user sees only what is relevant to that assigned role This dramatically reduces the amount of time wasted searching through irrelevant data or responding to alerts that someone else should be handling13Automatic creation of summary views 13A business area manager may want to see just a few redambergreen lights showing the health state of the applications in that department When an indicator goes red the right support person can be called Chances are that person has seen the same indicator and has already started investigating by drilling down to the detail data that was propagated up to the summary view This is a vast improvement over the traditional model in which the ldquoall-handsrdquo war-room meetings are called to troubleshoot serious issues1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 23
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
Assume I pass back to you13In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 24
copy 2012 SL Corporation All Rights Reserved
Select RTView Customers
Financial Services
Other
eCommerce Retail
Energy Telecom
500+ RTView
Customers
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 25
For More Information
Visit us at SLcom
Request a WebEx Demo
Start an Evaluation
Watch a Video
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 26
Thank You
Questions
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 6
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 7
Real-world Context Required
bull Thousands of boxes oceans of alerts bull Dynamic pools of virtual resources bull Connect the dots bull Distribute the data
ndash Democritization of healthstate intelligence
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 8
Service Model Integration ndash Maturity Curve
Maturity 1 Notifications
Maturity 2 Event
Management
Maturity 3 End-to-End
Maturity 4 Service
DeskTrouble Ticket
Integration
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 9
Attempts to move away from Silos - Maturity1 Notifications
bull Line of Business just panics with this info so often are not even included bull AppSupportDev eventually ignore these notifications because it is noise bull Operations only use it as indicators to go look at the siloed monitors
Physical Infrastructure
Storage
Middleware
APM
Log files
Email SMS
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
Before we get into the technical aspects of the RTView EM service model I wanted to provide some context to explain the benefits of a service model in the daily workflow of managing application health Most organizations have various roles which have interest in service health The Line of Business has interests in understanding the level of service provided to their customers Operations is the first line support and has expertise on all the components of the hardware and software infrastructure but has limited understanding of application architecture The Application Support and development teams have a deep understanding of the architecture of the app and are called in when Operations identifies issues that require their expertise1313As organizations grow and expand to multiple technologies to support their applications each technology often comes with its own administration and monitoring tools The challenge then becomes how to get the correct information to the right people how to analyze the situation across multiple technologies and ultimately resolve problems before they affect end users1313The first approach is often to just provide Email or SMS notifications from issues discovered in the siloed monitors to the teams Even small organizations can then deal with 1000s of notifications per day when this is initiated This is often not even implemented for the Line of Business because it would just cause panic with no context as to whether any of this information will affect service levels It is however often implemented for the App Support and Dev teams yet usually they end up ignoring this information because it becomes noise where they cannot differentiate when an event is something the Operations teams will handle as part of daily operations or one that will require their expertise1313In practice this model often works like this The Operations teams are the only ones that look at the notifications Over time and with practice they discover which events are interesting The events then point them to which siloed admin and monitoring tools to use for analysis After analysis it they discover the event indicates some action needs to be taken they enter it into their trouble ticket system The trouble ticket system then may work in a completely siloed manner where the workflow necessary to resolve the situation has limited context with the event that initiated the ticket This process is obviously time consuming error prone and requires some deep analysis expertise by the Operators And there is very limited proactive measures available for the App Support or Dev teams They only are brought into the process if Operations manually indicate to them that something must be done
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 10
Attempts to move away from Silos ndash Maturity 2 Event Management
bull Line of Business just panics with this info so often are not even included bull Events are centralized to help manage ownership between teams bull Only events are available so all teams go back to silos for analysis bull No context available to help prioritize events
PhysicalVirt Infrastructure
Storage
Middleware
APM
Log files
Event Management
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
Event Management tools work as an aggregator of alert events provided from multiple sources This allows better management of alerts by various teams These tools provide a way for multiple teams to visually look at lists of alerts filter alerts to find ones of interest and perform actions on the alerts to indicate status such as close suppress or own These teams can then work in a much more coordinated effort to determine who needs to analyze the alert and after analysis determine if a trouble ticket should be raised1313There are some limitations with this mode of operation Event Management tools often only have alert events they do not have access to any of the performance data that raised the event Therefore each team still must go to the siloed systems to do analysis This mode also requires some deep knowledge in order to solve a problem which requires some analysis across technologies It is also very difficult to determine how to prioritize the event or determine which teams need to have access to it because there is no context between the event and the services it impacts or which team cares
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 11
Attempts to move away from Silos ndash Maturity 3 End to End
bull Summary views that make sense to all teams bull Filtered alerts that apply only to the interests of the teams bull All info available in one spot to conduct analysis and raise trouble tickets bull The dynamic service model provides context for prioritization
Physical Infrastructure
Storage
Middleware
APM
Log files
RTView EM Event Management
Cross correlation analysis Dynamic Service Model
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
If you have existing Event Management tools RTView EM can easily integrate with them however many of our customers who donrsquot are benefiting by leaping from Maturity level 0 to Maturity level three by using RTView EM as the Event Management Cross correlation analysis and Dynamic Service Model all in one This drastically changes the work flow and efficiency in proactive care and problem resolution1313Here is how the lives change for each user13Line of Business13They can finally get a view of what is going on that makes sense to them Including views of applications and services that they own and their current and historical health state1313Operations13They finally get out of the mode of having to visit hundreds of siloed admin tools to do analysis All the information is at their finger tips with deep out of the box correlation views of component health state13They can view health state across technologies or by service13They can use the service model criticality to quickly determine the issues of deep impact to the business and prioritize what must be done first1313App Support and Development13They finally get something more than noise and can be proactive13They get top level views of application and service level health state that are applicable to only their apps13They can filter out low level infrastructure based alerts and focus on the ones that might have app impact13They can drill down to the component level health that are supporting their apps to do deep analysis (In most organizations the app teams do not have access to the siloed admin tools so they fly blind without the necessary data)1313And ALL teams benefit from having a central place that all teams can use to manage analysis efforts1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 12
Attempts to move away from Silos ndash Maturity 4 Integration with Service DeskTrouble Ticketing
Physical Infrastructure
Storage
Middleware
APM
Log files
RTView EM Event Management
Cross correlation analysis Dynamic Service Model
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
bull Bi-directional integration with Trouble Ticket systems bull When analysis indicates an event requires action the trouble ticket
can be manually initiated in RTView EM bull RTView EM rules can be created to auto-create trouble tickets bull RTView event management can provide info about the status of the
trouble ticket
Presenter
Presentation Notes
There is another level that some customers do to make the path to resolution even more manageable And that is integration between RTView EM and the Service DeskTrouble ticketing system Often times the Trouble ticket system is a silo of its own When support teams raise a ticket there is no correlation between event management and the state of the tasks that must be completed to resolve the problem1313With this workflow support teams after analysis will raise a trouble ticket correlated with an event in RTView EM They click on the alert and choose ldquoRaise trouble ticketrdquo RTView EM then provides information to the trouble ticket system correlating the alert event ID The Trouble Ticket system then provides state information about that ticket back to RTView EM1313Support teams can then look at a list of events that need analysis see which ones have already been marked for resolution in the trouble ticket system and see when the necessary tasks needed to resolve the issue have been completed1313It is also possible to automate a trouble ticket For example some events users know if they ever happen a trouble ticket should be generated Others might require some analysis and are preferably initiated by the user1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 13
RTView EM Architecture
Display Server
Config Server
Alert Server
Rules Engine
Cache Map
Dev QA Ops
Solution Packages (Distributed Data Servers)
EM Server Layer
EM Metadata
Layer
Data Server Layer
Presenter
Presentation Notes
So now that I have gone over some context about how a Dynamic Service Model can have great value in your support work flow I want to cover a little bit about how that is done in RTView EM13First this look at the EM architecture There are three components that are related to providing the service model benefits to end users13 The Config Server is used as a proxy to gather all inputs to your service model13 The Alert Server is used to get the service model from the Config server create the in-memory Dynamic Service Model and perform the calculations necessary to determine the health state of your model using the collection of all real time alert information it is gathering from multiple sources13 The Display Server is used to provide the role based views which give each user their specialized view into the service model and related alerts13
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 14
Service Model ndash Organizing the Enterprise
bull Associates individual architecture components hierarchically with application services organizations and roles ndash both static and dynamic information
bull Enables identification of service impact for an individual component problem
bull Can be organized along lines of business support models or any way that facilitates end users accessing the information they need
Owner
Area
Group
Service
JPeters
Operations- US
Mortgage Derivatives
Trading amp Operations
Middleware Analytics Inventory
RMorrissey
Workflow Inventory Mgmt Order Mgmt
CI CI CI CI CI CI CI
Presenter
Presentation Notes
The Service Model is used to designate the individuals and groups in your organization that have interest in or are responsible for the health state of your applications services or application infrastructure The top part is more static and changes only during re-orgs the bottom part is more dynamic and changes as new services and supporting CIrsquos are added to your systems A CI stands for a ldquoConfiguration Itemrdquo and indicates an item that is being monitored For example it might be a physical server a virtual server a database an application server or another piece of middleware1313The levels in the tree can flexible for your use case For example a ldquoServicerdquo might be a true service or application but it could also be something more aligned to support team management such as the ldquoWeb Logicrdquo service which captures many Weblogic server clusters1313Associated in the Service Model is the notion of criticality Particular services or CIs can be given a criticality level to help in the prioritization of components that deeply affect a service and services that deeply impact the business1313The main role of the Service Model is to get the information to the correct people and in a form that they can prioritize and act upon131313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 15
Flexibility ndash Multiple Inputs Custom or Off-the-Shelf
bull Integration layer enables aggregation of service model information from multiple sources ndash Asset Management
systems ndash Change Management
systems ndash HelpdeskService Desk
systems ndash Others
bull Auto-discovery bull Service Model editor
RTView Config Server
Helpdesk DB
Asset Mgmt
DB
Provisioning Metadata
Service Model Editor
Presenter
Presentation Notes
Organizations have many varied sources for their service model and RTView EM provides simple integration steps for including those sources of data and joining them together to form a complete model Parts of the model may come from Asset and Change management systems or even from your Service Desk systems RTView EM also has auto discovery features which can detect a new CI and automatically associate it with a Service And finally there is the Service Model editor which is an interface in RTView EM which allows users to configure or modify the service model themselves In many medium size organizations with 20-50 applications to monitor they choose just to manually manage the service model either because they do not have any existing sources of data or because it is a relatively small effort that it doesnrsquot justify an integration with other data sources
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 16
The Dynamic Service Model at Work
bull The Dynamic Service Model is an in-memory real-time model of the health state of your systems
bull Real time alerts and alert severities are used along with the criticality of the component or service to determine the health state of any leaf of the service hierarchy
bull End users each have their specific defined view into the service hierarchy to ensure relevance to individual areas of responsibility
End User
Dynamic Service Model
Real time Alerts Service Hierarchy
Presenter
Presentation Notes
What the in memory service model does
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 17
Cross-Correlation and Click-through
1 High level business service impacted
2 Drill down to view component dependencies
3 Identify individual component issue with historical detail
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 18
Application Service-Centric Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 19
bull Overall health state of a service
bull Current health state of each underlying component
bull Prioritize service alerts by criticality and impact
Drill-down into Tabular Cross-Correlation
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 20
And to the the Component Level
Drill down to individual component to view metric history over a configurable time period
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 21
Advanced Visualizations Services Area History Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 22
Getting the Right Info to the Right People
bull Extremely Flexible bull Provides automatic role-based views of
digestible intelligence bull Helps prioritize issues that impact your
business bull Becomes a key tool in proactive
efficient and collaborative management of your systems Without a Service Model Users see only a sea of
alerts with no prioritization by criticality or role
Presenter
Presentation Notes
Needs work but here is where I will re-state value13Decentralize monitoring and alerting 13The alert management system in a large enterprise could have thousands of active alerts at any one time The overwhelming task of wading through these to find what matters is left up to users often with a home-grown filtering solution Providing (useful) summary reports to management is next to impossible13Multiple application groups each with its own manager and support people 13Each application is dependent on a specific set of underlying infrastructure and middleware components RTView can be configured to maintain a ldquoService Modelrdquo a hierarchical arrangement of all components into applications and groups to which they belong This model can be manually created auto-populated in many cases from application metadata or imported from an external CMDB13Present digestible Monitoring Intelligence 13Every user who logs into RTView is assigned a ldquorolerdquo which can be associated with a list of applications or groups for which that role is responsible All alerts and monitoring metrics are filtered so the user sees only what is relevant to that assigned role This dramatically reduces the amount of time wasted searching through irrelevant data or responding to alerts that someone else should be handling13Automatic creation of summary views 13A business area manager may want to see just a few redambergreen lights showing the health state of the applications in that department When an indicator goes red the right support person can be called Chances are that person has seen the same indicator and has already started investigating by drilling down to the detail data that was propagated up to the summary view This is a vast improvement over the traditional model in which the ldquoall-handsrdquo war-room meetings are called to troubleshoot serious issues1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 23
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
Assume I pass back to you13In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 24
copy 2012 SL Corporation All Rights Reserved
Select RTView Customers
Financial Services
Other
eCommerce Retail
Energy Telecom
500+ RTView
Customers
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 25
For More Information
Visit us at SLcom
Request a WebEx Demo
Start an Evaluation
Watch a Video
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 26
Thank You
Questions
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 7
Real-world Context Required
bull Thousands of boxes oceans of alerts bull Dynamic pools of virtual resources bull Connect the dots bull Distribute the data
ndash Democritization of healthstate intelligence
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 8
Service Model Integration ndash Maturity Curve
Maturity 1 Notifications
Maturity 2 Event
Management
Maturity 3 End-to-End
Maturity 4 Service
DeskTrouble Ticket
Integration
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 9
Attempts to move away from Silos - Maturity1 Notifications
bull Line of Business just panics with this info so often are not even included bull AppSupportDev eventually ignore these notifications because it is noise bull Operations only use it as indicators to go look at the siloed monitors
Physical Infrastructure
Storage
Middleware
APM
Log files
Email SMS
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
Before we get into the technical aspects of the RTView EM service model I wanted to provide some context to explain the benefits of a service model in the daily workflow of managing application health Most organizations have various roles which have interest in service health The Line of Business has interests in understanding the level of service provided to their customers Operations is the first line support and has expertise on all the components of the hardware and software infrastructure but has limited understanding of application architecture The Application Support and development teams have a deep understanding of the architecture of the app and are called in when Operations identifies issues that require their expertise1313As organizations grow and expand to multiple technologies to support their applications each technology often comes with its own administration and monitoring tools The challenge then becomes how to get the correct information to the right people how to analyze the situation across multiple technologies and ultimately resolve problems before they affect end users1313The first approach is often to just provide Email or SMS notifications from issues discovered in the siloed monitors to the teams Even small organizations can then deal with 1000s of notifications per day when this is initiated This is often not even implemented for the Line of Business because it would just cause panic with no context as to whether any of this information will affect service levels It is however often implemented for the App Support and Dev teams yet usually they end up ignoring this information because it becomes noise where they cannot differentiate when an event is something the Operations teams will handle as part of daily operations or one that will require their expertise1313In practice this model often works like this The Operations teams are the only ones that look at the notifications Over time and with practice they discover which events are interesting The events then point them to which siloed admin and monitoring tools to use for analysis After analysis it they discover the event indicates some action needs to be taken they enter it into their trouble ticket system The trouble ticket system then may work in a completely siloed manner where the workflow necessary to resolve the situation has limited context with the event that initiated the ticket This process is obviously time consuming error prone and requires some deep analysis expertise by the Operators And there is very limited proactive measures available for the App Support or Dev teams They only are brought into the process if Operations manually indicate to them that something must be done
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 10
Attempts to move away from Silos ndash Maturity 2 Event Management
bull Line of Business just panics with this info so often are not even included bull Events are centralized to help manage ownership between teams bull Only events are available so all teams go back to silos for analysis bull No context available to help prioritize events
PhysicalVirt Infrastructure
Storage
Middleware
APM
Log files
Event Management
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
Event Management tools work as an aggregator of alert events provided from multiple sources This allows better management of alerts by various teams These tools provide a way for multiple teams to visually look at lists of alerts filter alerts to find ones of interest and perform actions on the alerts to indicate status such as close suppress or own These teams can then work in a much more coordinated effort to determine who needs to analyze the alert and after analysis determine if a trouble ticket should be raised1313There are some limitations with this mode of operation Event Management tools often only have alert events they do not have access to any of the performance data that raised the event Therefore each team still must go to the siloed systems to do analysis This mode also requires some deep knowledge in order to solve a problem which requires some analysis across technologies It is also very difficult to determine how to prioritize the event or determine which teams need to have access to it because there is no context between the event and the services it impacts or which team cares
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 11
Attempts to move away from Silos ndash Maturity 3 End to End
bull Summary views that make sense to all teams bull Filtered alerts that apply only to the interests of the teams bull All info available in one spot to conduct analysis and raise trouble tickets bull The dynamic service model provides context for prioritization
Physical Infrastructure
Storage
Middleware
APM
Log files
RTView EM Event Management
Cross correlation analysis Dynamic Service Model
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
If you have existing Event Management tools RTView EM can easily integrate with them however many of our customers who donrsquot are benefiting by leaping from Maturity level 0 to Maturity level three by using RTView EM as the Event Management Cross correlation analysis and Dynamic Service Model all in one This drastically changes the work flow and efficiency in proactive care and problem resolution1313Here is how the lives change for each user13Line of Business13They can finally get a view of what is going on that makes sense to them Including views of applications and services that they own and their current and historical health state1313Operations13They finally get out of the mode of having to visit hundreds of siloed admin tools to do analysis All the information is at their finger tips with deep out of the box correlation views of component health state13They can view health state across technologies or by service13They can use the service model criticality to quickly determine the issues of deep impact to the business and prioritize what must be done first1313App Support and Development13They finally get something more than noise and can be proactive13They get top level views of application and service level health state that are applicable to only their apps13They can filter out low level infrastructure based alerts and focus on the ones that might have app impact13They can drill down to the component level health that are supporting their apps to do deep analysis (In most organizations the app teams do not have access to the siloed admin tools so they fly blind without the necessary data)1313And ALL teams benefit from having a central place that all teams can use to manage analysis efforts1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 12
Attempts to move away from Silos ndash Maturity 4 Integration with Service DeskTrouble Ticketing
Physical Infrastructure
Storage
Middleware
APM
Log files
RTView EM Event Management
Cross correlation analysis Dynamic Service Model
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
bull Bi-directional integration with Trouble Ticket systems bull When analysis indicates an event requires action the trouble ticket
can be manually initiated in RTView EM bull RTView EM rules can be created to auto-create trouble tickets bull RTView event management can provide info about the status of the
trouble ticket
Presenter
Presentation Notes
There is another level that some customers do to make the path to resolution even more manageable And that is integration between RTView EM and the Service DeskTrouble ticketing system Often times the Trouble ticket system is a silo of its own When support teams raise a ticket there is no correlation between event management and the state of the tasks that must be completed to resolve the problem1313With this workflow support teams after analysis will raise a trouble ticket correlated with an event in RTView EM They click on the alert and choose ldquoRaise trouble ticketrdquo RTView EM then provides information to the trouble ticket system correlating the alert event ID The Trouble Ticket system then provides state information about that ticket back to RTView EM1313Support teams can then look at a list of events that need analysis see which ones have already been marked for resolution in the trouble ticket system and see when the necessary tasks needed to resolve the issue have been completed1313It is also possible to automate a trouble ticket For example some events users know if they ever happen a trouble ticket should be generated Others might require some analysis and are preferably initiated by the user1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 13
RTView EM Architecture
Display Server
Config Server
Alert Server
Rules Engine
Cache Map
Dev QA Ops
Solution Packages (Distributed Data Servers)
EM Server Layer
EM Metadata
Layer
Data Server Layer
Presenter
Presentation Notes
So now that I have gone over some context about how a Dynamic Service Model can have great value in your support work flow I want to cover a little bit about how that is done in RTView EM13First this look at the EM architecture There are three components that are related to providing the service model benefits to end users13 The Config Server is used as a proxy to gather all inputs to your service model13 The Alert Server is used to get the service model from the Config server create the in-memory Dynamic Service Model and perform the calculations necessary to determine the health state of your model using the collection of all real time alert information it is gathering from multiple sources13 The Display Server is used to provide the role based views which give each user their specialized view into the service model and related alerts13
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 14
Service Model ndash Organizing the Enterprise
bull Associates individual architecture components hierarchically with application services organizations and roles ndash both static and dynamic information
bull Enables identification of service impact for an individual component problem
bull Can be organized along lines of business support models or any way that facilitates end users accessing the information they need
Owner
Area
Group
Service
JPeters
Operations- US
Mortgage Derivatives
Trading amp Operations
Middleware Analytics Inventory
RMorrissey
Workflow Inventory Mgmt Order Mgmt
CI CI CI CI CI CI CI
Presenter
Presentation Notes
The Service Model is used to designate the individuals and groups in your organization that have interest in or are responsible for the health state of your applications services or application infrastructure The top part is more static and changes only during re-orgs the bottom part is more dynamic and changes as new services and supporting CIrsquos are added to your systems A CI stands for a ldquoConfiguration Itemrdquo and indicates an item that is being monitored For example it might be a physical server a virtual server a database an application server or another piece of middleware1313The levels in the tree can flexible for your use case For example a ldquoServicerdquo might be a true service or application but it could also be something more aligned to support team management such as the ldquoWeb Logicrdquo service which captures many Weblogic server clusters1313Associated in the Service Model is the notion of criticality Particular services or CIs can be given a criticality level to help in the prioritization of components that deeply affect a service and services that deeply impact the business1313The main role of the Service Model is to get the information to the correct people and in a form that they can prioritize and act upon131313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 15
Flexibility ndash Multiple Inputs Custom or Off-the-Shelf
bull Integration layer enables aggregation of service model information from multiple sources ndash Asset Management
systems ndash Change Management
systems ndash HelpdeskService Desk
systems ndash Others
bull Auto-discovery bull Service Model editor
RTView Config Server
Helpdesk DB
Asset Mgmt
DB
Provisioning Metadata
Service Model Editor
Presenter
Presentation Notes
Organizations have many varied sources for their service model and RTView EM provides simple integration steps for including those sources of data and joining them together to form a complete model Parts of the model may come from Asset and Change management systems or even from your Service Desk systems RTView EM also has auto discovery features which can detect a new CI and automatically associate it with a Service And finally there is the Service Model editor which is an interface in RTView EM which allows users to configure or modify the service model themselves In many medium size organizations with 20-50 applications to monitor they choose just to manually manage the service model either because they do not have any existing sources of data or because it is a relatively small effort that it doesnrsquot justify an integration with other data sources
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 16
The Dynamic Service Model at Work
bull The Dynamic Service Model is an in-memory real-time model of the health state of your systems
bull Real time alerts and alert severities are used along with the criticality of the component or service to determine the health state of any leaf of the service hierarchy
bull End users each have their specific defined view into the service hierarchy to ensure relevance to individual areas of responsibility
End User
Dynamic Service Model
Real time Alerts Service Hierarchy
Presenter
Presentation Notes
What the in memory service model does
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 17
Cross-Correlation and Click-through
1 High level business service impacted
2 Drill down to view component dependencies
3 Identify individual component issue with historical detail
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 18
Application Service-Centric Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 19
bull Overall health state of a service
bull Current health state of each underlying component
bull Prioritize service alerts by criticality and impact
Drill-down into Tabular Cross-Correlation
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 20
And to the the Component Level
Drill down to individual component to view metric history over a configurable time period
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 21
Advanced Visualizations Services Area History Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 22
Getting the Right Info to the Right People
bull Extremely Flexible bull Provides automatic role-based views of
digestible intelligence bull Helps prioritize issues that impact your
business bull Becomes a key tool in proactive
efficient and collaborative management of your systems Without a Service Model Users see only a sea of
alerts with no prioritization by criticality or role
Presenter
Presentation Notes
Needs work but here is where I will re-state value13Decentralize monitoring and alerting 13The alert management system in a large enterprise could have thousands of active alerts at any one time The overwhelming task of wading through these to find what matters is left up to users often with a home-grown filtering solution Providing (useful) summary reports to management is next to impossible13Multiple application groups each with its own manager and support people 13Each application is dependent on a specific set of underlying infrastructure and middleware components RTView can be configured to maintain a ldquoService Modelrdquo a hierarchical arrangement of all components into applications and groups to which they belong This model can be manually created auto-populated in many cases from application metadata or imported from an external CMDB13Present digestible Monitoring Intelligence 13Every user who logs into RTView is assigned a ldquorolerdquo which can be associated with a list of applications or groups for which that role is responsible All alerts and monitoring metrics are filtered so the user sees only what is relevant to that assigned role This dramatically reduces the amount of time wasted searching through irrelevant data or responding to alerts that someone else should be handling13Automatic creation of summary views 13A business area manager may want to see just a few redambergreen lights showing the health state of the applications in that department When an indicator goes red the right support person can be called Chances are that person has seen the same indicator and has already started investigating by drilling down to the detail data that was propagated up to the summary view This is a vast improvement over the traditional model in which the ldquoall-handsrdquo war-room meetings are called to troubleshoot serious issues1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 23
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
Assume I pass back to you13In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 24
copy 2012 SL Corporation All Rights Reserved
Select RTView Customers
Financial Services
Other
eCommerce Retail
Energy Telecom
500+ RTView
Customers
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 25
For More Information
Visit us at SLcom
Request a WebEx Demo
Start an Evaluation
Watch a Video
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 26
Thank You
Questions
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 8
Service Model Integration ndash Maturity Curve
Maturity 1 Notifications
Maturity 2 Event
Management
Maturity 3 End-to-End
Maturity 4 Service
DeskTrouble Ticket
Integration
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 9
Attempts to move away from Silos - Maturity1 Notifications
bull Line of Business just panics with this info so often are not even included bull AppSupportDev eventually ignore these notifications because it is noise bull Operations only use it as indicators to go look at the siloed monitors
Physical Infrastructure
Storage
Middleware
APM
Log files
Email SMS
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
Before we get into the technical aspects of the RTView EM service model I wanted to provide some context to explain the benefits of a service model in the daily workflow of managing application health Most organizations have various roles which have interest in service health The Line of Business has interests in understanding the level of service provided to their customers Operations is the first line support and has expertise on all the components of the hardware and software infrastructure but has limited understanding of application architecture The Application Support and development teams have a deep understanding of the architecture of the app and are called in when Operations identifies issues that require their expertise1313As organizations grow and expand to multiple technologies to support their applications each technology often comes with its own administration and monitoring tools The challenge then becomes how to get the correct information to the right people how to analyze the situation across multiple technologies and ultimately resolve problems before they affect end users1313The first approach is often to just provide Email or SMS notifications from issues discovered in the siloed monitors to the teams Even small organizations can then deal with 1000s of notifications per day when this is initiated This is often not even implemented for the Line of Business because it would just cause panic with no context as to whether any of this information will affect service levels It is however often implemented for the App Support and Dev teams yet usually they end up ignoring this information because it becomes noise where they cannot differentiate when an event is something the Operations teams will handle as part of daily operations or one that will require their expertise1313In practice this model often works like this The Operations teams are the only ones that look at the notifications Over time and with practice they discover which events are interesting The events then point them to which siloed admin and monitoring tools to use for analysis After analysis it they discover the event indicates some action needs to be taken they enter it into their trouble ticket system The trouble ticket system then may work in a completely siloed manner where the workflow necessary to resolve the situation has limited context with the event that initiated the ticket This process is obviously time consuming error prone and requires some deep analysis expertise by the Operators And there is very limited proactive measures available for the App Support or Dev teams They only are brought into the process if Operations manually indicate to them that something must be done
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 10
Attempts to move away from Silos ndash Maturity 2 Event Management
bull Line of Business just panics with this info so often are not even included bull Events are centralized to help manage ownership between teams bull Only events are available so all teams go back to silos for analysis bull No context available to help prioritize events
PhysicalVirt Infrastructure
Storage
Middleware
APM
Log files
Event Management
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
Event Management tools work as an aggregator of alert events provided from multiple sources This allows better management of alerts by various teams These tools provide a way for multiple teams to visually look at lists of alerts filter alerts to find ones of interest and perform actions on the alerts to indicate status such as close suppress or own These teams can then work in a much more coordinated effort to determine who needs to analyze the alert and after analysis determine if a trouble ticket should be raised1313There are some limitations with this mode of operation Event Management tools often only have alert events they do not have access to any of the performance data that raised the event Therefore each team still must go to the siloed systems to do analysis This mode also requires some deep knowledge in order to solve a problem which requires some analysis across technologies It is also very difficult to determine how to prioritize the event or determine which teams need to have access to it because there is no context between the event and the services it impacts or which team cares
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 11
Attempts to move away from Silos ndash Maturity 3 End to End
bull Summary views that make sense to all teams bull Filtered alerts that apply only to the interests of the teams bull All info available in one spot to conduct analysis and raise trouble tickets bull The dynamic service model provides context for prioritization
Physical Infrastructure
Storage
Middleware
APM
Log files
RTView EM Event Management
Cross correlation analysis Dynamic Service Model
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
If you have existing Event Management tools RTView EM can easily integrate with them however many of our customers who donrsquot are benefiting by leaping from Maturity level 0 to Maturity level three by using RTView EM as the Event Management Cross correlation analysis and Dynamic Service Model all in one This drastically changes the work flow and efficiency in proactive care and problem resolution1313Here is how the lives change for each user13Line of Business13They can finally get a view of what is going on that makes sense to them Including views of applications and services that they own and their current and historical health state1313Operations13They finally get out of the mode of having to visit hundreds of siloed admin tools to do analysis All the information is at their finger tips with deep out of the box correlation views of component health state13They can view health state across technologies or by service13They can use the service model criticality to quickly determine the issues of deep impact to the business and prioritize what must be done first1313App Support and Development13They finally get something more than noise and can be proactive13They get top level views of application and service level health state that are applicable to only their apps13They can filter out low level infrastructure based alerts and focus on the ones that might have app impact13They can drill down to the component level health that are supporting their apps to do deep analysis (In most organizations the app teams do not have access to the siloed admin tools so they fly blind without the necessary data)1313And ALL teams benefit from having a central place that all teams can use to manage analysis efforts1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 12
Attempts to move away from Silos ndash Maturity 4 Integration with Service DeskTrouble Ticketing
Physical Infrastructure
Storage
Middleware
APM
Log files
RTView EM Event Management
Cross correlation analysis Dynamic Service Model
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
bull Bi-directional integration with Trouble Ticket systems bull When analysis indicates an event requires action the trouble ticket
can be manually initiated in RTView EM bull RTView EM rules can be created to auto-create trouble tickets bull RTView event management can provide info about the status of the
trouble ticket
Presenter
Presentation Notes
There is another level that some customers do to make the path to resolution even more manageable And that is integration between RTView EM and the Service DeskTrouble ticketing system Often times the Trouble ticket system is a silo of its own When support teams raise a ticket there is no correlation between event management and the state of the tasks that must be completed to resolve the problem1313With this workflow support teams after analysis will raise a trouble ticket correlated with an event in RTView EM They click on the alert and choose ldquoRaise trouble ticketrdquo RTView EM then provides information to the trouble ticket system correlating the alert event ID The Trouble Ticket system then provides state information about that ticket back to RTView EM1313Support teams can then look at a list of events that need analysis see which ones have already been marked for resolution in the trouble ticket system and see when the necessary tasks needed to resolve the issue have been completed1313It is also possible to automate a trouble ticket For example some events users know if they ever happen a trouble ticket should be generated Others might require some analysis and are preferably initiated by the user1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 13
RTView EM Architecture
Display Server
Config Server
Alert Server
Rules Engine
Cache Map
Dev QA Ops
Solution Packages (Distributed Data Servers)
EM Server Layer
EM Metadata
Layer
Data Server Layer
Presenter
Presentation Notes
So now that I have gone over some context about how a Dynamic Service Model can have great value in your support work flow I want to cover a little bit about how that is done in RTView EM13First this look at the EM architecture There are three components that are related to providing the service model benefits to end users13 The Config Server is used as a proxy to gather all inputs to your service model13 The Alert Server is used to get the service model from the Config server create the in-memory Dynamic Service Model and perform the calculations necessary to determine the health state of your model using the collection of all real time alert information it is gathering from multiple sources13 The Display Server is used to provide the role based views which give each user their specialized view into the service model and related alerts13
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 14
Service Model ndash Organizing the Enterprise
bull Associates individual architecture components hierarchically with application services organizations and roles ndash both static and dynamic information
bull Enables identification of service impact for an individual component problem
bull Can be organized along lines of business support models or any way that facilitates end users accessing the information they need
Owner
Area
Group
Service
JPeters
Operations- US
Mortgage Derivatives
Trading amp Operations
Middleware Analytics Inventory
RMorrissey
Workflow Inventory Mgmt Order Mgmt
CI CI CI CI CI CI CI
Presenter
Presentation Notes
The Service Model is used to designate the individuals and groups in your organization that have interest in or are responsible for the health state of your applications services or application infrastructure The top part is more static and changes only during re-orgs the bottom part is more dynamic and changes as new services and supporting CIrsquos are added to your systems A CI stands for a ldquoConfiguration Itemrdquo and indicates an item that is being monitored For example it might be a physical server a virtual server a database an application server or another piece of middleware1313The levels in the tree can flexible for your use case For example a ldquoServicerdquo might be a true service or application but it could also be something more aligned to support team management such as the ldquoWeb Logicrdquo service which captures many Weblogic server clusters1313Associated in the Service Model is the notion of criticality Particular services or CIs can be given a criticality level to help in the prioritization of components that deeply affect a service and services that deeply impact the business1313The main role of the Service Model is to get the information to the correct people and in a form that they can prioritize and act upon131313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 15
Flexibility ndash Multiple Inputs Custom or Off-the-Shelf
bull Integration layer enables aggregation of service model information from multiple sources ndash Asset Management
systems ndash Change Management
systems ndash HelpdeskService Desk
systems ndash Others
bull Auto-discovery bull Service Model editor
RTView Config Server
Helpdesk DB
Asset Mgmt
DB
Provisioning Metadata
Service Model Editor
Presenter
Presentation Notes
Organizations have many varied sources for their service model and RTView EM provides simple integration steps for including those sources of data and joining them together to form a complete model Parts of the model may come from Asset and Change management systems or even from your Service Desk systems RTView EM also has auto discovery features which can detect a new CI and automatically associate it with a Service And finally there is the Service Model editor which is an interface in RTView EM which allows users to configure or modify the service model themselves In many medium size organizations with 20-50 applications to monitor they choose just to manually manage the service model either because they do not have any existing sources of data or because it is a relatively small effort that it doesnrsquot justify an integration with other data sources
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 16
The Dynamic Service Model at Work
bull The Dynamic Service Model is an in-memory real-time model of the health state of your systems
bull Real time alerts and alert severities are used along with the criticality of the component or service to determine the health state of any leaf of the service hierarchy
bull End users each have their specific defined view into the service hierarchy to ensure relevance to individual areas of responsibility
End User
Dynamic Service Model
Real time Alerts Service Hierarchy
Presenter
Presentation Notes
What the in memory service model does
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 17
Cross-Correlation and Click-through
1 High level business service impacted
2 Drill down to view component dependencies
3 Identify individual component issue with historical detail
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 18
Application Service-Centric Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 19
bull Overall health state of a service
bull Current health state of each underlying component
bull Prioritize service alerts by criticality and impact
Drill-down into Tabular Cross-Correlation
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 20
And to the the Component Level
Drill down to individual component to view metric history over a configurable time period
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 21
Advanced Visualizations Services Area History Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 22
Getting the Right Info to the Right People
bull Extremely Flexible bull Provides automatic role-based views of
digestible intelligence bull Helps prioritize issues that impact your
business bull Becomes a key tool in proactive
efficient and collaborative management of your systems Without a Service Model Users see only a sea of
alerts with no prioritization by criticality or role
Presenter
Presentation Notes
Needs work but here is where I will re-state value13Decentralize monitoring and alerting 13The alert management system in a large enterprise could have thousands of active alerts at any one time The overwhelming task of wading through these to find what matters is left up to users often with a home-grown filtering solution Providing (useful) summary reports to management is next to impossible13Multiple application groups each with its own manager and support people 13Each application is dependent on a specific set of underlying infrastructure and middleware components RTView can be configured to maintain a ldquoService Modelrdquo a hierarchical arrangement of all components into applications and groups to which they belong This model can be manually created auto-populated in many cases from application metadata or imported from an external CMDB13Present digestible Monitoring Intelligence 13Every user who logs into RTView is assigned a ldquorolerdquo which can be associated with a list of applications or groups for which that role is responsible All alerts and monitoring metrics are filtered so the user sees only what is relevant to that assigned role This dramatically reduces the amount of time wasted searching through irrelevant data or responding to alerts that someone else should be handling13Automatic creation of summary views 13A business area manager may want to see just a few redambergreen lights showing the health state of the applications in that department When an indicator goes red the right support person can be called Chances are that person has seen the same indicator and has already started investigating by drilling down to the detail data that was propagated up to the summary view This is a vast improvement over the traditional model in which the ldquoall-handsrdquo war-room meetings are called to troubleshoot serious issues1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 23
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
Assume I pass back to you13In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 24
copy 2012 SL Corporation All Rights Reserved
Select RTView Customers
Financial Services
Other
eCommerce Retail
Energy Telecom
500+ RTView
Customers
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 25
For More Information
Visit us at SLcom
Request a WebEx Demo
Start an Evaluation
Watch a Video
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 26
Thank You
Questions
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 9
Attempts to move away from Silos - Maturity1 Notifications
bull Line of Business just panics with this info so often are not even included bull AppSupportDev eventually ignore these notifications because it is noise bull Operations only use it as indicators to go look at the siloed monitors
Physical Infrastructure
Storage
Middleware
APM
Log files
Email SMS
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
Before we get into the technical aspects of the RTView EM service model I wanted to provide some context to explain the benefits of a service model in the daily workflow of managing application health Most organizations have various roles which have interest in service health The Line of Business has interests in understanding the level of service provided to their customers Operations is the first line support and has expertise on all the components of the hardware and software infrastructure but has limited understanding of application architecture The Application Support and development teams have a deep understanding of the architecture of the app and are called in when Operations identifies issues that require their expertise1313As organizations grow and expand to multiple technologies to support their applications each technology often comes with its own administration and monitoring tools The challenge then becomes how to get the correct information to the right people how to analyze the situation across multiple technologies and ultimately resolve problems before they affect end users1313The first approach is often to just provide Email or SMS notifications from issues discovered in the siloed monitors to the teams Even small organizations can then deal with 1000s of notifications per day when this is initiated This is often not even implemented for the Line of Business because it would just cause panic with no context as to whether any of this information will affect service levels It is however often implemented for the App Support and Dev teams yet usually they end up ignoring this information because it becomes noise where they cannot differentiate when an event is something the Operations teams will handle as part of daily operations or one that will require their expertise1313In practice this model often works like this The Operations teams are the only ones that look at the notifications Over time and with practice they discover which events are interesting The events then point them to which siloed admin and monitoring tools to use for analysis After analysis it they discover the event indicates some action needs to be taken they enter it into their trouble ticket system The trouble ticket system then may work in a completely siloed manner where the workflow necessary to resolve the situation has limited context with the event that initiated the ticket This process is obviously time consuming error prone and requires some deep analysis expertise by the Operators And there is very limited proactive measures available for the App Support or Dev teams They only are brought into the process if Operations manually indicate to them that something must be done
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 10
Attempts to move away from Silos ndash Maturity 2 Event Management
bull Line of Business just panics with this info so often are not even included bull Events are centralized to help manage ownership between teams bull Only events are available so all teams go back to silos for analysis bull No context available to help prioritize events
PhysicalVirt Infrastructure
Storage
Middleware
APM
Log files
Event Management
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
Event Management tools work as an aggregator of alert events provided from multiple sources This allows better management of alerts by various teams These tools provide a way for multiple teams to visually look at lists of alerts filter alerts to find ones of interest and perform actions on the alerts to indicate status such as close suppress or own These teams can then work in a much more coordinated effort to determine who needs to analyze the alert and after analysis determine if a trouble ticket should be raised1313There are some limitations with this mode of operation Event Management tools often only have alert events they do not have access to any of the performance data that raised the event Therefore each team still must go to the siloed systems to do analysis This mode also requires some deep knowledge in order to solve a problem which requires some analysis across technologies It is also very difficult to determine how to prioritize the event or determine which teams need to have access to it because there is no context between the event and the services it impacts or which team cares
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 11
Attempts to move away from Silos ndash Maturity 3 End to End
bull Summary views that make sense to all teams bull Filtered alerts that apply only to the interests of the teams bull All info available in one spot to conduct analysis and raise trouble tickets bull The dynamic service model provides context for prioritization
Physical Infrastructure
Storage
Middleware
APM
Log files
RTView EM Event Management
Cross correlation analysis Dynamic Service Model
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
If you have existing Event Management tools RTView EM can easily integrate with them however many of our customers who donrsquot are benefiting by leaping from Maturity level 0 to Maturity level three by using RTView EM as the Event Management Cross correlation analysis and Dynamic Service Model all in one This drastically changes the work flow and efficiency in proactive care and problem resolution1313Here is how the lives change for each user13Line of Business13They can finally get a view of what is going on that makes sense to them Including views of applications and services that they own and their current and historical health state1313Operations13They finally get out of the mode of having to visit hundreds of siloed admin tools to do analysis All the information is at their finger tips with deep out of the box correlation views of component health state13They can view health state across technologies or by service13They can use the service model criticality to quickly determine the issues of deep impact to the business and prioritize what must be done first1313App Support and Development13They finally get something more than noise and can be proactive13They get top level views of application and service level health state that are applicable to only their apps13They can filter out low level infrastructure based alerts and focus on the ones that might have app impact13They can drill down to the component level health that are supporting their apps to do deep analysis (In most organizations the app teams do not have access to the siloed admin tools so they fly blind without the necessary data)1313And ALL teams benefit from having a central place that all teams can use to manage analysis efforts1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 12
Attempts to move away from Silos ndash Maturity 4 Integration with Service DeskTrouble Ticketing
Physical Infrastructure
Storage
Middleware
APM
Log files
RTView EM Event Management
Cross correlation analysis Dynamic Service Model
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
bull Bi-directional integration with Trouble Ticket systems bull When analysis indicates an event requires action the trouble ticket
can be manually initiated in RTView EM bull RTView EM rules can be created to auto-create trouble tickets bull RTView event management can provide info about the status of the
trouble ticket
Presenter
Presentation Notes
There is another level that some customers do to make the path to resolution even more manageable And that is integration between RTView EM and the Service DeskTrouble ticketing system Often times the Trouble ticket system is a silo of its own When support teams raise a ticket there is no correlation between event management and the state of the tasks that must be completed to resolve the problem1313With this workflow support teams after analysis will raise a trouble ticket correlated with an event in RTView EM They click on the alert and choose ldquoRaise trouble ticketrdquo RTView EM then provides information to the trouble ticket system correlating the alert event ID The Trouble Ticket system then provides state information about that ticket back to RTView EM1313Support teams can then look at a list of events that need analysis see which ones have already been marked for resolution in the trouble ticket system and see when the necessary tasks needed to resolve the issue have been completed1313It is also possible to automate a trouble ticket For example some events users know if they ever happen a trouble ticket should be generated Others might require some analysis and are preferably initiated by the user1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 13
RTView EM Architecture
Display Server
Config Server
Alert Server
Rules Engine
Cache Map
Dev QA Ops
Solution Packages (Distributed Data Servers)
EM Server Layer
EM Metadata
Layer
Data Server Layer
Presenter
Presentation Notes
So now that I have gone over some context about how a Dynamic Service Model can have great value in your support work flow I want to cover a little bit about how that is done in RTView EM13First this look at the EM architecture There are three components that are related to providing the service model benefits to end users13 The Config Server is used as a proxy to gather all inputs to your service model13 The Alert Server is used to get the service model from the Config server create the in-memory Dynamic Service Model and perform the calculations necessary to determine the health state of your model using the collection of all real time alert information it is gathering from multiple sources13 The Display Server is used to provide the role based views which give each user their specialized view into the service model and related alerts13
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 14
Service Model ndash Organizing the Enterprise
bull Associates individual architecture components hierarchically with application services organizations and roles ndash both static and dynamic information
bull Enables identification of service impact for an individual component problem
bull Can be organized along lines of business support models or any way that facilitates end users accessing the information they need
Owner
Area
Group
Service
JPeters
Operations- US
Mortgage Derivatives
Trading amp Operations
Middleware Analytics Inventory
RMorrissey
Workflow Inventory Mgmt Order Mgmt
CI CI CI CI CI CI CI
Presenter
Presentation Notes
The Service Model is used to designate the individuals and groups in your organization that have interest in or are responsible for the health state of your applications services or application infrastructure The top part is more static and changes only during re-orgs the bottom part is more dynamic and changes as new services and supporting CIrsquos are added to your systems A CI stands for a ldquoConfiguration Itemrdquo and indicates an item that is being monitored For example it might be a physical server a virtual server a database an application server or another piece of middleware1313The levels in the tree can flexible for your use case For example a ldquoServicerdquo might be a true service or application but it could also be something more aligned to support team management such as the ldquoWeb Logicrdquo service which captures many Weblogic server clusters1313Associated in the Service Model is the notion of criticality Particular services or CIs can be given a criticality level to help in the prioritization of components that deeply affect a service and services that deeply impact the business1313The main role of the Service Model is to get the information to the correct people and in a form that they can prioritize and act upon131313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 15
Flexibility ndash Multiple Inputs Custom or Off-the-Shelf
bull Integration layer enables aggregation of service model information from multiple sources ndash Asset Management
systems ndash Change Management
systems ndash HelpdeskService Desk
systems ndash Others
bull Auto-discovery bull Service Model editor
RTView Config Server
Helpdesk DB
Asset Mgmt
DB
Provisioning Metadata
Service Model Editor
Presenter
Presentation Notes
Organizations have many varied sources for their service model and RTView EM provides simple integration steps for including those sources of data and joining them together to form a complete model Parts of the model may come from Asset and Change management systems or even from your Service Desk systems RTView EM also has auto discovery features which can detect a new CI and automatically associate it with a Service And finally there is the Service Model editor which is an interface in RTView EM which allows users to configure or modify the service model themselves In many medium size organizations with 20-50 applications to monitor they choose just to manually manage the service model either because they do not have any existing sources of data or because it is a relatively small effort that it doesnrsquot justify an integration with other data sources
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 16
The Dynamic Service Model at Work
bull The Dynamic Service Model is an in-memory real-time model of the health state of your systems
bull Real time alerts and alert severities are used along with the criticality of the component or service to determine the health state of any leaf of the service hierarchy
bull End users each have their specific defined view into the service hierarchy to ensure relevance to individual areas of responsibility
End User
Dynamic Service Model
Real time Alerts Service Hierarchy
Presenter
Presentation Notes
What the in memory service model does
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 17
Cross-Correlation and Click-through
1 High level business service impacted
2 Drill down to view component dependencies
3 Identify individual component issue with historical detail
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 18
Application Service-Centric Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 19
bull Overall health state of a service
bull Current health state of each underlying component
bull Prioritize service alerts by criticality and impact
Drill-down into Tabular Cross-Correlation
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 20
And to the the Component Level
Drill down to individual component to view metric history over a configurable time period
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 21
Advanced Visualizations Services Area History Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 22
Getting the Right Info to the Right People
bull Extremely Flexible bull Provides automatic role-based views of
digestible intelligence bull Helps prioritize issues that impact your
business bull Becomes a key tool in proactive
efficient and collaborative management of your systems Without a Service Model Users see only a sea of
alerts with no prioritization by criticality or role
Presenter
Presentation Notes
Needs work but here is where I will re-state value13Decentralize monitoring and alerting 13The alert management system in a large enterprise could have thousands of active alerts at any one time The overwhelming task of wading through these to find what matters is left up to users often with a home-grown filtering solution Providing (useful) summary reports to management is next to impossible13Multiple application groups each with its own manager and support people 13Each application is dependent on a specific set of underlying infrastructure and middleware components RTView can be configured to maintain a ldquoService Modelrdquo a hierarchical arrangement of all components into applications and groups to which they belong This model can be manually created auto-populated in many cases from application metadata or imported from an external CMDB13Present digestible Monitoring Intelligence 13Every user who logs into RTView is assigned a ldquorolerdquo which can be associated with a list of applications or groups for which that role is responsible All alerts and monitoring metrics are filtered so the user sees only what is relevant to that assigned role This dramatically reduces the amount of time wasted searching through irrelevant data or responding to alerts that someone else should be handling13Automatic creation of summary views 13A business area manager may want to see just a few redambergreen lights showing the health state of the applications in that department When an indicator goes red the right support person can be called Chances are that person has seen the same indicator and has already started investigating by drilling down to the detail data that was propagated up to the summary view This is a vast improvement over the traditional model in which the ldquoall-handsrdquo war-room meetings are called to troubleshoot serious issues1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 23
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
Assume I pass back to you13In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 24
copy 2012 SL Corporation All Rights Reserved
Select RTView Customers
Financial Services
Other
eCommerce Retail
Energy Telecom
500+ RTView
Customers
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 25
For More Information
Visit us at SLcom
Request a WebEx Demo
Start an Evaluation
Watch a Video
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 26
Thank You
Questions
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 10
Attempts to move away from Silos ndash Maturity 2 Event Management
bull Line of Business just panics with this info so often are not even included bull Events are centralized to help manage ownership between teams bull Only events are available so all teams go back to silos for analysis bull No context available to help prioritize events
PhysicalVirt Infrastructure
Storage
Middleware
APM
Log files
Event Management
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
Event Management tools work as an aggregator of alert events provided from multiple sources This allows better management of alerts by various teams These tools provide a way for multiple teams to visually look at lists of alerts filter alerts to find ones of interest and perform actions on the alerts to indicate status such as close suppress or own These teams can then work in a much more coordinated effort to determine who needs to analyze the alert and after analysis determine if a trouble ticket should be raised1313There are some limitations with this mode of operation Event Management tools often only have alert events they do not have access to any of the performance data that raised the event Therefore each team still must go to the siloed systems to do analysis This mode also requires some deep knowledge in order to solve a problem which requires some analysis across technologies It is also very difficult to determine how to prioritize the event or determine which teams need to have access to it because there is no context between the event and the services it impacts or which team cares
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 11
Attempts to move away from Silos ndash Maturity 3 End to End
bull Summary views that make sense to all teams bull Filtered alerts that apply only to the interests of the teams bull All info available in one spot to conduct analysis and raise trouble tickets bull The dynamic service model provides context for prioritization
Physical Infrastructure
Storage
Middleware
APM
Log files
RTView EM Event Management
Cross correlation analysis Dynamic Service Model
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
If you have existing Event Management tools RTView EM can easily integrate with them however many of our customers who donrsquot are benefiting by leaping from Maturity level 0 to Maturity level three by using RTView EM as the Event Management Cross correlation analysis and Dynamic Service Model all in one This drastically changes the work flow and efficiency in proactive care and problem resolution1313Here is how the lives change for each user13Line of Business13They can finally get a view of what is going on that makes sense to them Including views of applications and services that they own and their current and historical health state1313Operations13They finally get out of the mode of having to visit hundreds of siloed admin tools to do analysis All the information is at their finger tips with deep out of the box correlation views of component health state13They can view health state across technologies or by service13They can use the service model criticality to quickly determine the issues of deep impact to the business and prioritize what must be done first1313App Support and Development13They finally get something more than noise and can be proactive13They get top level views of application and service level health state that are applicable to only their apps13They can filter out low level infrastructure based alerts and focus on the ones that might have app impact13They can drill down to the component level health that are supporting their apps to do deep analysis (In most organizations the app teams do not have access to the siloed admin tools so they fly blind without the necessary data)1313And ALL teams benefit from having a central place that all teams can use to manage analysis efforts1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 12
Attempts to move away from Silos ndash Maturity 4 Integration with Service DeskTrouble Ticketing
Physical Infrastructure
Storage
Middleware
APM
Log files
RTView EM Event Management
Cross correlation analysis Dynamic Service Model
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
bull Bi-directional integration with Trouble Ticket systems bull When analysis indicates an event requires action the trouble ticket
can be manually initiated in RTView EM bull RTView EM rules can be created to auto-create trouble tickets bull RTView event management can provide info about the status of the
trouble ticket
Presenter
Presentation Notes
There is another level that some customers do to make the path to resolution even more manageable And that is integration between RTView EM and the Service DeskTrouble ticketing system Often times the Trouble ticket system is a silo of its own When support teams raise a ticket there is no correlation between event management and the state of the tasks that must be completed to resolve the problem1313With this workflow support teams after analysis will raise a trouble ticket correlated with an event in RTView EM They click on the alert and choose ldquoRaise trouble ticketrdquo RTView EM then provides information to the trouble ticket system correlating the alert event ID The Trouble Ticket system then provides state information about that ticket back to RTView EM1313Support teams can then look at a list of events that need analysis see which ones have already been marked for resolution in the trouble ticket system and see when the necessary tasks needed to resolve the issue have been completed1313It is also possible to automate a trouble ticket For example some events users know if they ever happen a trouble ticket should be generated Others might require some analysis and are preferably initiated by the user1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 13
RTView EM Architecture
Display Server
Config Server
Alert Server
Rules Engine
Cache Map
Dev QA Ops
Solution Packages (Distributed Data Servers)
EM Server Layer
EM Metadata
Layer
Data Server Layer
Presenter
Presentation Notes
So now that I have gone over some context about how a Dynamic Service Model can have great value in your support work flow I want to cover a little bit about how that is done in RTView EM13First this look at the EM architecture There are three components that are related to providing the service model benefits to end users13 The Config Server is used as a proxy to gather all inputs to your service model13 The Alert Server is used to get the service model from the Config server create the in-memory Dynamic Service Model and perform the calculations necessary to determine the health state of your model using the collection of all real time alert information it is gathering from multiple sources13 The Display Server is used to provide the role based views which give each user their specialized view into the service model and related alerts13
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 14
Service Model ndash Organizing the Enterprise
bull Associates individual architecture components hierarchically with application services organizations and roles ndash both static and dynamic information
bull Enables identification of service impact for an individual component problem
bull Can be organized along lines of business support models or any way that facilitates end users accessing the information they need
Owner
Area
Group
Service
JPeters
Operations- US
Mortgage Derivatives
Trading amp Operations
Middleware Analytics Inventory
RMorrissey
Workflow Inventory Mgmt Order Mgmt
CI CI CI CI CI CI CI
Presenter
Presentation Notes
The Service Model is used to designate the individuals and groups in your organization that have interest in or are responsible for the health state of your applications services or application infrastructure The top part is more static and changes only during re-orgs the bottom part is more dynamic and changes as new services and supporting CIrsquos are added to your systems A CI stands for a ldquoConfiguration Itemrdquo and indicates an item that is being monitored For example it might be a physical server a virtual server a database an application server or another piece of middleware1313The levels in the tree can flexible for your use case For example a ldquoServicerdquo might be a true service or application but it could also be something more aligned to support team management such as the ldquoWeb Logicrdquo service which captures many Weblogic server clusters1313Associated in the Service Model is the notion of criticality Particular services or CIs can be given a criticality level to help in the prioritization of components that deeply affect a service and services that deeply impact the business1313The main role of the Service Model is to get the information to the correct people and in a form that they can prioritize and act upon131313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 15
Flexibility ndash Multiple Inputs Custom or Off-the-Shelf
bull Integration layer enables aggregation of service model information from multiple sources ndash Asset Management
systems ndash Change Management
systems ndash HelpdeskService Desk
systems ndash Others
bull Auto-discovery bull Service Model editor
RTView Config Server
Helpdesk DB
Asset Mgmt
DB
Provisioning Metadata
Service Model Editor
Presenter
Presentation Notes
Organizations have many varied sources for their service model and RTView EM provides simple integration steps for including those sources of data and joining them together to form a complete model Parts of the model may come from Asset and Change management systems or even from your Service Desk systems RTView EM also has auto discovery features which can detect a new CI and automatically associate it with a Service And finally there is the Service Model editor which is an interface in RTView EM which allows users to configure or modify the service model themselves In many medium size organizations with 20-50 applications to monitor they choose just to manually manage the service model either because they do not have any existing sources of data or because it is a relatively small effort that it doesnrsquot justify an integration with other data sources
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 16
The Dynamic Service Model at Work
bull The Dynamic Service Model is an in-memory real-time model of the health state of your systems
bull Real time alerts and alert severities are used along with the criticality of the component or service to determine the health state of any leaf of the service hierarchy
bull End users each have their specific defined view into the service hierarchy to ensure relevance to individual areas of responsibility
End User
Dynamic Service Model
Real time Alerts Service Hierarchy
Presenter
Presentation Notes
What the in memory service model does
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 17
Cross-Correlation and Click-through
1 High level business service impacted
2 Drill down to view component dependencies
3 Identify individual component issue with historical detail
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 18
Application Service-Centric Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 19
bull Overall health state of a service
bull Current health state of each underlying component
bull Prioritize service alerts by criticality and impact
Drill-down into Tabular Cross-Correlation
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 20
And to the the Component Level
Drill down to individual component to view metric history over a configurable time period
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 21
Advanced Visualizations Services Area History Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 22
Getting the Right Info to the Right People
bull Extremely Flexible bull Provides automatic role-based views of
digestible intelligence bull Helps prioritize issues that impact your
business bull Becomes a key tool in proactive
efficient and collaborative management of your systems Without a Service Model Users see only a sea of
alerts with no prioritization by criticality or role
Presenter
Presentation Notes
Needs work but here is where I will re-state value13Decentralize monitoring and alerting 13The alert management system in a large enterprise could have thousands of active alerts at any one time The overwhelming task of wading through these to find what matters is left up to users often with a home-grown filtering solution Providing (useful) summary reports to management is next to impossible13Multiple application groups each with its own manager and support people 13Each application is dependent on a specific set of underlying infrastructure and middleware components RTView can be configured to maintain a ldquoService Modelrdquo a hierarchical arrangement of all components into applications and groups to which they belong This model can be manually created auto-populated in many cases from application metadata or imported from an external CMDB13Present digestible Monitoring Intelligence 13Every user who logs into RTView is assigned a ldquorolerdquo which can be associated with a list of applications or groups for which that role is responsible All alerts and monitoring metrics are filtered so the user sees only what is relevant to that assigned role This dramatically reduces the amount of time wasted searching through irrelevant data or responding to alerts that someone else should be handling13Automatic creation of summary views 13A business area manager may want to see just a few redambergreen lights showing the health state of the applications in that department When an indicator goes red the right support person can be called Chances are that person has seen the same indicator and has already started investigating by drilling down to the detail data that was propagated up to the summary view This is a vast improvement over the traditional model in which the ldquoall-handsrdquo war-room meetings are called to troubleshoot serious issues1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 23
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
Assume I pass back to you13In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 24
copy 2012 SL Corporation All Rights Reserved
Select RTView Customers
Financial Services
Other
eCommerce Retail
Energy Telecom
500+ RTView
Customers
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 25
For More Information
Visit us at SLcom
Request a WebEx Demo
Start an Evaluation
Watch a Video
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 26
Thank You
Questions
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 11
Attempts to move away from Silos ndash Maturity 3 End to End
bull Summary views that make sense to all teams bull Filtered alerts that apply only to the interests of the teams bull All info available in one spot to conduct analysis and raise trouble tickets bull The dynamic service model provides context for prioritization
Physical Infrastructure
Storage
Middleware
APM
Log files
RTView EM Event Management
Cross correlation analysis Dynamic Service Model
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
Presenter
Presentation Notes
If you have existing Event Management tools RTView EM can easily integrate with them however many of our customers who donrsquot are benefiting by leaping from Maturity level 0 to Maturity level three by using RTView EM as the Event Management Cross correlation analysis and Dynamic Service Model all in one This drastically changes the work flow and efficiency in proactive care and problem resolution1313Here is how the lives change for each user13Line of Business13They can finally get a view of what is going on that makes sense to them Including views of applications and services that they own and their current and historical health state1313Operations13They finally get out of the mode of having to visit hundreds of siloed admin tools to do analysis All the information is at their finger tips with deep out of the box correlation views of component health state13They can view health state across technologies or by service13They can use the service model criticality to quickly determine the issues of deep impact to the business and prioritize what must be done first1313App Support and Development13They finally get something more than noise and can be proactive13They get top level views of application and service level health state that are applicable to only their apps13They can filter out low level infrastructure based alerts and focus on the ones that might have app impact13They can drill down to the component level health that are supporting their apps to do deep analysis (In most organizations the app teams do not have access to the siloed admin tools so they fly blind without the necessary data)1313And ALL teams benefit from having a central place that all teams can use to manage analysis efforts1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 12
Attempts to move away from Silos ndash Maturity 4 Integration with Service DeskTrouble Ticketing
Physical Infrastructure
Storage
Middleware
APM
Log files
RTView EM Event Management
Cross correlation analysis Dynamic Service Model
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
bull Bi-directional integration with Trouble Ticket systems bull When analysis indicates an event requires action the trouble ticket
can be manually initiated in RTView EM bull RTView EM rules can be created to auto-create trouble tickets bull RTView event management can provide info about the status of the
trouble ticket
Presenter
Presentation Notes
There is another level that some customers do to make the path to resolution even more manageable And that is integration between RTView EM and the Service DeskTrouble ticketing system Often times the Trouble ticket system is a silo of its own When support teams raise a ticket there is no correlation between event management and the state of the tasks that must be completed to resolve the problem1313With this workflow support teams after analysis will raise a trouble ticket correlated with an event in RTView EM They click on the alert and choose ldquoRaise trouble ticketrdquo RTView EM then provides information to the trouble ticket system correlating the alert event ID The Trouble Ticket system then provides state information about that ticket back to RTView EM1313Support teams can then look at a list of events that need analysis see which ones have already been marked for resolution in the trouble ticket system and see when the necessary tasks needed to resolve the issue have been completed1313It is also possible to automate a trouble ticket For example some events users know if they ever happen a trouble ticket should be generated Others might require some analysis and are preferably initiated by the user1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 13
RTView EM Architecture
Display Server
Config Server
Alert Server
Rules Engine
Cache Map
Dev QA Ops
Solution Packages (Distributed Data Servers)
EM Server Layer
EM Metadata
Layer
Data Server Layer
Presenter
Presentation Notes
So now that I have gone over some context about how a Dynamic Service Model can have great value in your support work flow I want to cover a little bit about how that is done in RTView EM13First this look at the EM architecture There are three components that are related to providing the service model benefits to end users13 The Config Server is used as a proxy to gather all inputs to your service model13 The Alert Server is used to get the service model from the Config server create the in-memory Dynamic Service Model and perform the calculations necessary to determine the health state of your model using the collection of all real time alert information it is gathering from multiple sources13 The Display Server is used to provide the role based views which give each user their specialized view into the service model and related alerts13
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 14
Service Model ndash Organizing the Enterprise
bull Associates individual architecture components hierarchically with application services organizations and roles ndash both static and dynamic information
bull Enables identification of service impact for an individual component problem
bull Can be organized along lines of business support models or any way that facilitates end users accessing the information they need
Owner
Area
Group
Service
JPeters
Operations- US
Mortgage Derivatives
Trading amp Operations
Middleware Analytics Inventory
RMorrissey
Workflow Inventory Mgmt Order Mgmt
CI CI CI CI CI CI CI
Presenter
Presentation Notes
The Service Model is used to designate the individuals and groups in your organization that have interest in or are responsible for the health state of your applications services or application infrastructure The top part is more static and changes only during re-orgs the bottom part is more dynamic and changes as new services and supporting CIrsquos are added to your systems A CI stands for a ldquoConfiguration Itemrdquo and indicates an item that is being monitored For example it might be a physical server a virtual server a database an application server or another piece of middleware1313The levels in the tree can flexible for your use case For example a ldquoServicerdquo might be a true service or application but it could also be something more aligned to support team management such as the ldquoWeb Logicrdquo service which captures many Weblogic server clusters1313Associated in the Service Model is the notion of criticality Particular services or CIs can be given a criticality level to help in the prioritization of components that deeply affect a service and services that deeply impact the business1313The main role of the Service Model is to get the information to the correct people and in a form that they can prioritize and act upon131313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 15
Flexibility ndash Multiple Inputs Custom or Off-the-Shelf
bull Integration layer enables aggregation of service model information from multiple sources ndash Asset Management
systems ndash Change Management
systems ndash HelpdeskService Desk
systems ndash Others
bull Auto-discovery bull Service Model editor
RTView Config Server
Helpdesk DB
Asset Mgmt
DB
Provisioning Metadata
Service Model Editor
Presenter
Presentation Notes
Organizations have many varied sources for their service model and RTView EM provides simple integration steps for including those sources of data and joining them together to form a complete model Parts of the model may come from Asset and Change management systems or even from your Service Desk systems RTView EM also has auto discovery features which can detect a new CI and automatically associate it with a Service And finally there is the Service Model editor which is an interface in RTView EM which allows users to configure or modify the service model themselves In many medium size organizations with 20-50 applications to monitor they choose just to manually manage the service model either because they do not have any existing sources of data or because it is a relatively small effort that it doesnrsquot justify an integration with other data sources
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 16
The Dynamic Service Model at Work
bull The Dynamic Service Model is an in-memory real-time model of the health state of your systems
bull Real time alerts and alert severities are used along with the criticality of the component or service to determine the health state of any leaf of the service hierarchy
bull End users each have their specific defined view into the service hierarchy to ensure relevance to individual areas of responsibility
End User
Dynamic Service Model
Real time Alerts Service Hierarchy
Presenter
Presentation Notes
What the in memory service model does
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 17
Cross-Correlation and Click-through
1 High level business service impacted
2 Drill down to view component dependencies
3 Identify individual component issue with historical detail
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 18
Application Service-Centric Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 19
bull Overall health state of a service
bull Current health state of each underlying component
bull Prioritize service alerts by criticality and impact
Drill-down into Tabular Cross-Correlation
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 20
And to the the Component Level
Drill down to individual component to view metric history over a configurable time period
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 21
Advanced Visualizations Services Area History Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 22
Getting the Right Info to the Right People
bull Extremely Flexible bull Provides automatic role-based views of
digestible intelligence bull Helps prioritize issues that impact your
business bull Becomes a key tool in proactive
efficient and collaborative management of your systems Without a Service Model Users see only a sea of
alerts with no prioritization by criticality or role
Presenter
Presentation Notes
Needs work but here is where I will re-state value13Decentralize monitoring and alerting 13The alert management system in a large enterprise could have thousands of active alerts at any one time The overwhelming task of wading through these to find what matters is left up to users often with a home-grown filtering solution Providing (useful) summary reports to management is next to impossible13Multiple application groups each with its own manager and support people 13Each application is dependent on a specific set of underlying infrastructure and middleware components RTView can be configured to maintain a ldquoService Modelrdquo a hierarchical arrangement of all components into applications and groups to which they belong This model can be manually created auto-populated in many cases from application metadata or imported from an external CMDB13Present digestible Monitoring Intelligence 13Every user who logs into RTView is assigned a ldquorolerdquo which can be associated with a list of applications or groups for which that role is responsible All alerts and monitoring metrics are filtered so the user sees only what is relevant to that assigned role This dramatically reduces the amount of time wasted searching through irrelevant data or responding to alerts that someone else should be handling13Automatic creation of summary views 13A business area manager may want to see just a few redambergreen lights showing the health state of the applications in that department When an indicator goes red the right support person can be called Chances are that person has seen the same indicator and has already started investigating by drilling down to the detail data that was propagated up to the summary view This is a vast improvement over the traditional model in which the ldquoall-handsrdquo war-room meetings are called to troubleshoot serious issues1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 23
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
Assume I pass back to you13In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 24
copy 2012 SL Corporation All Rights Reserved
Select RTView Customers
Financial Services
Other
eCommerce Retail
Energy Telecom
500+ RTView
Customers
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 25
For More Information
Visit us at SLcom
Request a WebEx Demo
Start an Evaluation
Watch a Video
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 26
Thank You
Questions
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 12
Attempts to move away from Silos ndash Maturity 4 Integration with Service DeskTrouble Ticketing
Physical Infrastructure
Storage
Middleware
APM
Log files
RTView EM Event Management
Cross correlation analysis Dynamic Service Model
Line of Business
Operations
App Support
Development
ServiceDesk Trouble Ticket
bull Bi-directional integration with Trouble Ticket systems bull When analysis indicates an event requires action the trouble ticket
can be manually initiated in RTView EM bull RTView EM rules can be created to auto-create trouble tickets bull RTView event management can provide info about the status of the
trouble ticket
Presenter
Presentation Notes
There is another level that some customers do to make the path to resolution even more manageable And that is integration between RTView EM and the Service DeskTrouble ticketing system Often times the Trouble ticket system is a silo of its own When support teams raise a ticket there is no correlation between event management and the state of the tasks that must be completed to resolve the problem1313With this workflow support teams after analysis will raise a trouble ticket correlated with an event in RTView EM They click on the alert and choose ldquoRaise trouble ticketrdquo RTView EM then provides information to the trouble ticket system correlating the alert event ID The Trouble Ticket system then provides state information about that ticket back to RTView EM1313Support teams can then look at a list of events that need analysis see which ones have already been marked for resolution in the trouble ticket system and see when the necessary tasks needed to resolve the issue have been completed1313It is also possible to automate a trouble ticket For example some events users know if they ever happen a trouble ticket should be generated Others might require some analysis and are preferably initiated by the user1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 13
RTView EM Architecture
Display Server
Config Server
Alert Server
Rules Engine
Cache Map
Dev QA Ops
Solution Packages (Distributed Data Servers)
EM Server Layer
EM Metadata
Layer
Data Server Layer
Presenter
Presentation Notes
So now that I have gone over some context about how a Dynamic Service Model can have great value in your support work flow I want to cover a little bit about how that is done in RTView EM13First this look at the EM architecture There are three components that are related to providing the service model benefits to end users13 The Config Server is used as a proxy to gather all inputs to your service model13 The Alert Server is used to get the service model from the Config server create the in-memory Dynamic Service Model and perform the calculations necessary to determine the health state of your model using the collection of all real time alert information it is gathering from multiple sources13 The Display Server is used to provide the role based views which give each user their specialized view into the service model and related alerts13
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 14
Service Model ndash Organizing the Enterprise
bull Associates individual architecture components hierarchically with application services organizations and roles ndash both static and dynamic information
bull Enables identification of service impact for an individual component problem
bull Can be organized along lines of business support models or any way that facilitates end users accessing the information they need
Owner
Area
Group
Service
JPeters
Operations- US
Mortgage Derivatives
Trading amp Operations
Middleware Analytics Inventory
RMorrissey
Workflow Inventory Mgmt Order Mgmt
CI CI CI CI CI CI CI
Presenter
Presentation Notes
The Service Model is used to designate the individuals and groups in your organization that have interest in or are responsible for the health state of your applications services or application infrastructure The top part is more static and changes only during re-orgs the bottom part is more dynamic and changes as new services and supporting CIrsquos are added to your systems A CI stands for a ldquoConfiguration Itemrdquo and indicates an item that is being monitored For example it might be a physical server a virtual server a database an application server or another piece of middleware1313The levels in the tree can flexible for your use case For example a ldquoServicerdquo might be a true service or application but it could also be something more aligned to support team management such as the ldquoWeb Logicrdquo service which captures many Weblogic server clusters1313Associated in the Service Model is the notion of criticality Particular services or CIs can be given a criticality level to help in the prioritization of components that deeply affect a service and services that deeply impact the business1313The main role of the Service Model is to get the information to the correct people and in a form that they can prioritize and act upon131313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 15
Flexibility ndash Multiple Inputs Custom or Off-the-Shelf
bull Integration layer enables aggregation of service model information from multiple sources ndash Asset Management
systems ndash Change Management
systems ndash HelpdeskService Desk
systems ndash Others
bull Auto-discovery bull Service Model editor
RTView Config Server
Helpdesk DB
Asset Mgmt
DB
Provisioning Metadata
Service Model Editor
Presenter
Presentation Notes
Organizations have many varied sources for their service model and RTView EM provides simple integration steps for including those sources of data and joining them together to form a complete model Parts of the model may come from Asset and Change management systems or even from your Service Desk systems RTView EM also has auto discovery features which can detect a new CI and automatically associate it with a Service And finally there is the Service Model editor which is an interface in RTView EM which allows users to configure or modify the service model themselves In many medium size organizations with 20-50 applications to monitor they choose just to manually manage the service model either because they do not have any existing sources of data or because it is a relatively small effort that it doesnrsquot justify an integration with other data sources
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 16
The Dynamic Service Model at Work
bull The Dynamic Service Model is an in-memory real-time model of the health state of your systems
bull Real time alerts and alert severities are used along with the criticality of the component or service to determine the health state of any leaf of the service hierarchy
bull End users each have their specific defined view into the service hierarchy to ensure relevance to individual areas of responsibility
End User
Dynamic Service Model
Real time Alerts Service Hierarchy
Presenter
Presentation Notes
What the in memory service model does
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 17
Cross-Correlation and Click-through
1 High level business service impacted
2 Drill down to view component dependencies
3 Identify individual component issue with historical detail
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 18
Application Service-Centric Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 19
bull Overall health state of a service
bull Current health state of each underlying component
bull Prioritize service alerts by criticality and impact
Drill-down into Tabular Cross-Correlation
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 20
And to the the Component Level
Drill down to individual component to view metric history over a configurable time period
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 21
Advanced Visualizations Services Area History Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 22
Getting the Right Info to the Right People
bull Extremely Flexible bull Provides automatic role-based views of
digestible intelligence bull Helps prioritize issues that impact your
business bull Becomes a key tool in proactive
efficient and collaborative management of your systems Without a Service Model Users see only a sea of
alerts with no prioritization by criticality or role
Presenter
Presentation Notes
Needs work but here is where I will re-state value13Decentralize monitoring and alerting 13The alert management system in a large enterprise could have thousands of active alerts at any one time The overwhelming task of wading through these to find what matters is left up to users often with a home-grown filtering solution Providing (useful) summary reports to management is next to impossible13Multiple application groups each with its own manager and support people 13Each application is dependent on a specific set of underlying infrastructure and middleware components RTView can be configured to maintain a ldquoService Modelrdquo a hierarchical arrangement of all components into applications and groups to which they belong This model can be manually created auto-populated in many cases from application metadata or imported from an external CMDB13Present digestible Monitoring Intelligence 13Every user who logs into RTView is assigned a ldquorolerdquo which can be associated with a list of applications or groups for which that role is responsible All alerts and monitoring metrics are filtered so the user sees only what is relevant to that assigned role This dramatically reduces the amount of time wasted searching through irrelevant data or responding to alerts that someone else should be handling13Automatic creation of summary views 13A business area manager may want to see just a few redambergreen lights showing the health state of the applications in that department When an indicator goes red the right support person can be called Chances are that person has seen the same indicator and has already started investigating by drilling down to the detail data that was propagated up to the summary view This is a vast improvement over the traditional model in which the ldquoall-handsrdquo war-room meetings are called to troubleshoot serious issues1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 23
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
Assume I pass back to you13In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 24
copy 2012 SL Corporation All Rights Reserved
Select RTView Customers
Financial Services
Other
eCommerce Retail
Energy Telecom
500+ RTView
Customers
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 25
For More Information
Visit us at SLcom
Request a WebEx Demo
Start an Evaluation
Watch a Video
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 26
Thank You
Questions
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 13
RTView EM Architecture
Display Server
Config Server
Alert Server
Rules Engine
Cache Map
Dev QA Ops
Solution Packages (Distributed Data Servers)
EM Server Layer
EM Metadata
Layer
Data Server Layer
Presenter
Presentation Notes
So now that I have gone over some context about how a Dynamic Service Model can have great value in your support work flow I want to cover a little bit about how that is done in RTView EM13First this look at the EM architecture There are three components that are related to providing the service model benefits to end users13 The Config Server is used as a proxy to gather all inputs to your service model13 The Alert Server is used to get the service model from the Config server create the in-memory Dynamic Service Model and perform the calculations necessary to determine the health state of your model using the collection of all real time alert information it is gathering from multiple sources13 The Display Server is used to provide the role based views which give each user their specialized view into the service model and related alerts13
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 14
Service Model ndash Organizing the Enterprise
bull Associates individual architecture components hierarchically with application services organizations and roles ndash both static and dynamic information
bull Enables identification of service impact for an individual component problem
bull Can be organized along lines of business support models or any way that facilitates end users accessing the information they need
Owner
Area
Group
Service
JPeters
Operations- US
Mortgage Derivatives
Trading amp Operations
Middleware Analytics Inventory
RMorrissey
Workflow Inventory Mgmt Order Mgmt
CI CI CI CI CI CI CI
Presenter
Presentation Notes
The Service Model is used to designate the individuals and groups in your organization that have interest in or are responsible for the health state of your applications services or application infrastructure The top part is more static and changes only during re-orgs the bottom part is more dynamic and changes as new services and supporting CIrsquos are added to your systems A CI stands for a ldquoConfiguration Itemrdquo and indicates an item that is being monitored For example it might be a physical server a virtual server a database an application server or another piece of middleware1313The levels in the tree can flexible for your use case For example a ldquoServicerdquo might be a true service or application but it could also be something more aligned to support team management such as the ldquoWeb Logicrdquo service which captures many Weblogic server clusters1313Associated in the Service Model is the notion of criticality Particular services or CIs can be given a criticality level to help in the prioritization of components that deeply affect a service and services that deeply impact the business1313The main role of the Service Model is to get the information to the correct people and in a form that they can prioritize and act upon131313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 15
Flexibility ndash Multiple Inputs Custom or Off-the-Shelf
bull Integration layer enables aggregation of service model information from multiple sources ndash Asset Management
systems ndash Change Management
systems ndash HelpdeskService Desk
systems ndash Others
bull Auto-discovery bull Service Model editor
RTView Config Server
Helpdesk DB
Asset Mgmt
DB
Provisioning Metadata
Service Model Editor
Presenter
Presentation Notes
Organizations have many varied sources for their service model and RTView EM provides simple integration steps for including those sources of data and joining them together to form a complete model Parts of the model may come from Asset and Change management systems or even from your Service Desk systems RTView EM also has auto discovery features which can detect a new CI and automatically associate it with a Service And finally there is the Service Model editor which is an interface in RTView EM which allows users to configure or modify the service model themselves In many medium size organizations with 20-50 applications to monitor they choose just to manually manage the service model either because they do not have any existing sources of data or because it is a relatively small effort that it doesnrsquot justify an integration with other data sources
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 16
The Dynamic Service Model at Work
bull The Dynamic Service Model is an in-memory real-time model of the health state of your systems
bull Real time alerts and alert severities are used along with the criticality of the component or service to determine the health state of any leaf of the service hierarchy
bull End users each have their specific defined view into the service hierarchy to ensure relevance to individual areas of responsibility
End User
Dynamic Service Model
Real time Alerts Service Hierarchy
Presenter
Presentation Notes
What the in memory service model does
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 17
Cross-Correlation and Click-through
1 High level business service impacted
2 Drill down to view component dependencies
3 Identify individual component issue with historical detail
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 18
Application Service-Centric Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 19
bull Overall health state of a service
bull Current health state of each underlying component
bull Prioritize service alerts by criticality and impact
Drill-down into Tabular Cross-Correlation
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 20
And to the the Component Level
Drill down to individual component to view metric history over a configurable time period
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 21
Advanced Visualizations Services Area History Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 22
Getting the Right Info to the Right People
bull Extremely Flexible bull Provides automatic role-based views of
digestible intelligence bull Helps prioritize issues that impact your
business bull Becomes a key tool in proactive
efficient and collaborative management of your systems Without a Service Model Users see only a sea of
alerts with no prioritization by criticality or role
Presenter
Presentation Notes
Needs work but here is where I will re-state value13Decentralize monitoring and alerting 13The alert management system in a large enterprise could have thousands of active alerts at any one time The overwhelming task of wading through these to find what matters is left up to users often with a home-grown filtering solution Providing (useful) summary reports to management is next to impossible13Multiple application groups each with its own manager and support people 13Each application is dependent on a specific set of underlying infrastructure and middleware components RTView can be configured to maintain a ldquoService Modelrdquo a hierarchical arrangement of all components into applications and groups to which they belong This model can be manually created auto-populated in many cases from application metadata or imported from an external CMDB13Present digestible Monitoring Intelligence 13Every user who logs into RTView is assigned a ldquorolerdquo which can be associated with a list of applications or groups for which that role is responsible All alerts and monitoring metrics are filtered so the user sees only what is relevant to that assigned role This dramatically reduces the amount of time wasted searching through irrelevant data or responding to alerts that someone else should be handling13Automatic creation of summary views 13A business area manager may want to see just a few redambergreen lights showing the health state of the applications in that department When an indicator goes red the right support person can be called Chances are that person has seen the same indicator and has already started investigating by drilling down to the detail data that was propagated up to the summary view This is a vast improvement over the traditional model in which the ldquoall-handsrdquo war-room meetings are called to troubleshoot serious issues1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 23
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
Assume I pass back to you13In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 24
copy 2012 SL Corporation All Rights Reserved
Select RTView Customers
Financial Services
Other
eCommerce Retail
Energy Telecom
500+ RTView
Customers
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 25
For More Information
Visit us at SLcom
Request a WebEx Demo
Start an Evaluation
Watch a Video
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 26
Thank You
Questions
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 14
Service Model ndash Organizing the Enterprise
bull Associates individual architecture components hierarchically with application services organizations and roles ndash both static and dynamic information
bull Enables identification of service impact for an individual component problem
bull Can be organized along lines of business support models or any way that facilitates end users accessing the information they need
Owner
Area
Group
Service
JPeters
Operations- US
Mortgage Derivatives
Trading amp Operations
Middleware Analytics Inventory
RMorrissey
Workflow Inventory Mgmt Order Mgmt
CI CI CI CI CI CI CI
Presenter
Presentation Notes
The Service Model is used to designate the individuals and groups in your organization that have interest in or are responsible for the health state of your applications services or application infrastructure The top part is more static and changes only during re-orgs the bottom part is more dynamic and changes as new services and supporting CIrsquos are added to your systems A CI stands for a ldquoConfiguration Itemrdquo and indicates an item that is being monitored For example it might be a physical server a virtual server a database an application server or another piece of middleware1313The levels in the tree can flexible for your use case For example a ldquoServicerdquo might be a true service or application but it could also be something more aligned to support team management such as the ldquoWeb Logicrdquo service which captures many Weblogic server clusters1313Associated in the Service Model is the notion of criticality Particular services or CIs can be given a criticality level to help in the prioritization of components that deeply affect a service and services that deeply impact the business1313The main role of the Service Model is to get the information to the correct people and in a form that they can prioritize and act upon131313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 15
Flexibility ndash Multiple Inputs Custom or Off-the-Shelf
bull Integration layer enables aggregation of service model information from multiple sources ndash Asset Management
systems ndash Change Management
systems ndash HelpdeskService Desk
systems ndash Others
bull Auto-discovery bull Service Model editor
RTView Config Server
Helpdesk DB
Asset Mgmt
DB
Provisioning Metadata
Service Model Editor
Presenter
Presentation Notes
Organizations have many varied sources for their service model and RTView EM provides simple integration steps for including those sources of data and joining them together to form a complete model Parts of the model may come from Asset and Change management systems or even from your Service Desk systems RTView EM also has auto discovery features which can detect a new CI and automatically associate it with a Service And finally there is the Service Model editor which is an interface in RTView EM which allows users to configure or modify the service model themselves In many medium size organizations with 20-50 applications to monitor they choose just to manually manage the service model either because they do not have any existing sources of data or because it is a relatively small effort that it doesnrsquot justify an integration with other data sources
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 16
The Dynamic Service Model at Work
bull The Dynamic Service Model is an in-memory real-time model of the health state of your systems
bull Real time alerts and alert severities are used along with the criticality of the component or service to determine the health state of any leaf of the service hierarchy
bull End users each have their specific defined view into the service hierarchy to ensure relevance to individual areas of responsibility
End User
Dynamic Service Model
Real time Alerts Service Hierarchy
Presenter
Presentation Notes
What the in memory service model does
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 17
Cross-Correlation and Click-through
1 High level business service impacted
2 Drill down to view component dependencies
3 Identify individual component issue with historical detail
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 18
Application Service-Centric Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 19
bull Overall health state of a service
bull Current health state of each underlying component
bull Prioritize service alerts by criticality and impact
Drill-down into Tabular Cross-Correlation
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 20
And to the the Component Level
Drill down to individual component to view metric history over a configurable time period
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 21
Advanced Visualizations Services Area History Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 22
Getting the Right Info to the Right People
bull Extremely Flexible bull Provides automatic role-based views of
digestible intelligence bull Helps prioritize issues that impact your
business bull Becomes a key tool in proactive
efficient and collaborative management of your systems Without a Service Model Users see only a sea of
alerts with no prioritization by criticality or role
Presenter
Presentation Notes
Needs work but here is where I will re-state value13Decentralize monitoring and alerting 13The alert management system in a large enterprise could have thousands of active alerts at any one time The overwhelming task of wading through these to find what matters is left up to users often with a home-grown filtering solution Providing (useful) summary reports to management is next to impossible13Multiple application groups each with its own manager and support people 13Each application is dependent on a specific set of underlying infrastructure and middleware components RTView can be configured to maintain a ldquoService Modelrdquo a hierarchical arrangement of all components into applications and groups to which they belong This model can be manually created auto-populated in many cases from application metadata or imported from an external CMDB13Present digestible Monitoring Intelligence 13Every user who logs into RTView is assigned a ldquorolerdquo which can be associated with a list of applications or groups for which that role is responsible All alerts and monitoring metrics are filtered so the user sees only what is relevant to that assigned role This dramatically reduces the amount of time wasted searching through irrelevant data or responding to alerts that someone else should be handling13Automatic creation of summary views 13A business area manager may want to see just a few redambergreen lights showing the health state of the applications in that department When an indicator goes red the right support person can be called Chances are that person has seen the same indicator and has already started investigating by drilling down to the detail data that was propagated up to the summary view This is a vast improvement over the traditional model in which the ldquoall-handsrdquo war-room meetings are called to troubleshoot serious issues1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 23
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
Assume I pass back to you13In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 24
copy 2012 SL Corporation All Rights Reserved
Select RTView Customers
Financial Services
Other
eCommerce Retail
Energy Telecom
500+ RTView
Customers
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 25
For More Information
Visit us at SLcom
Request a WebEx Demo
Start an Evaluation
Watch a Video
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 26
Thank You
Questions
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 15
Flexibility ndash Multiple Inputs Custom or Off-the-Shelf
bull Integration layer enables aggregation of service model information from multiple sources ndash Asset Management
systems ndash Change Management
systems ndash HelpdeskService Desk
systems ndash Others
bull Auto-discovery bull Service Model editor
RTView Config Server
Helpdesk DB
Asset Mgmt
DB
Provisioning Metadata
Service Model Editor
Presenter
Presentation Notes
Organizations have many varied sources for their service model and RTView EM provides simple integration steps for including those sources of data and joining them together to form a complete model Parts of the model may come from Asset and Change management systems or even from your Service Desk systems RTView EM also has auto discovery features which can detect a new CI and automatically associate it with a Service And finally there is the Service Model editor which is an interface in RTView EM which allows users to configure or modify the service model themselves In many medium size organizations with 20-50 applications to monitor they choose just to manually manage the service model either because they do not have any existing sources of data or because it is a relatively small effort that it doesnrsquot justify an integration with other data sources
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 16
The Dynamic Service Model at Work
bull The Dynamic Service Model is an in-memory real-time model of the health state of your systems
bull Real time alerts and alert severities are used along with the criticality of the component or service to determine the health state of any leaf of the service hierarchy
bull End users each have their specific defined view into the service hierarchy to ensure relevance to individual areas of responsibility
End User
Dynamic Service Model
Real time Alerts Service Hierarchy
Presenter
Presentation Notes
What the in memory service model does
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 17
Cross-Correlation and Click-through
1 High level business service impacted
2 Drill down to view component dependencies
3 Identify individual component issue with historical detail
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 18
Application Service-Centric Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 19
bull Overall health state of a service
bull Current health state of each underlying component
bull Prioritize service alerts by criticality and impact
Drill-down into Tabular Cross-Correlation
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 20
And to the the Component Level
Drill down to individual component to view metric history over a configurable time period
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 21
Advanced Visualizations Services Area History Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 22
Getting the Right Info to the Right People
bull Extremely Flexible bull Provides automatic role-based views of
digestible intelligence bull Helps prioritize issues that impact your
business bull Becomes a key tool in proactive
efficient and collaborative management of your systems Without a Service Model Users see only a sea of
alerts with no prioritization by criticality or role
Presenter
Presentation Notes
Needs work but here is where I will re-state value13Decentralize monitoring and alerting 13The alert management system in a large enterprise could have thousands of active alerts at any one time The overwhelming task of wading through these to find what matters is left up to users often with a home-grown filtering solution Providing (useful) summary reports to management is next to impossible13Multiple application groups each with its own manager and support people 13Each application is dependent on a specific set of underlying infrastructure and middleware components RTView can be configured to maintain a ldquoService Modelrdquo a hierarchical arrangement of all components into applications and groups to which they belong This model can be manually created auto-populated in many cases from application metadata or imported from an external CMDB13Present digestible Monitoring Intelligence 13Every user who logs into RTView is assigned a ldquorolerdquo which can be associated with a list of applications or groups for which that role is responsible All alerts and monitoring metrics are filtered so the user sees only what is relevant to that assigned role This dramatically reduces the amount of time wasted searching through irrelevant data or responding to alerts that someone else should be handling13Automatic creation of summary views 13A business area manager may want to see just a few redambergreen lights showing the health state of the applications in that department When an indicator goes red the right support person can be called Chances are that person has seen the same indicator and has already started investigating by drilling down to the detail data that was propagated up to the summary view This is a vast improvement over the traditional model in which the ldquoall-handsrdquo war-room meetings are called to troubleshoot serious issues1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 23
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
Assume I pass back to you13In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 24
copy 2012 SL Corporation All Rights Reserved
Select RTView Customers
Financial Services
Other
eCommerce Retail
Energy Telecom
500+ RTView
Customers
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 25
For More Information
Visit us at SLcom
Request a WebEx Demo
Start an Evaluation
Watch a Video
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 26
Thank You
Questions
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 16
The Dynamic Service Model at Work
bull The Dynamic Service Model is an in-memory real-time model of the health state of your systems
bull Real time alerts and alert severities are used along with the criticality of the component or service to determine the health state of any leaf of the service hierarchy
bull End users each have their specific defined view into the service hierarchy to ensure relevance to individual areas of responsibility
End User
Dynamic Service Model
Real time Alerts Service Hierarchy
Presenter
Presentation Notes
What the in memory service model does
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 17
Cross-Correlation and Click-through
1 High level business service impacted
2 Drill down to view component dependencies
3 Identify individual component issue with historical detail
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 18
Application Service-Centric Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 19
bull Overall health state of a service
bull Current health state of each underlying component
bull Prioritize service alerts by criticality and impact
Drill-down into Tabular Cross-Correlation
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 20
And to the the Component Level
Drill down to individual component to view metric history over a configurable time period
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 21
Advanced Visualizations Services Area History Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 22
Getting the Right Info to the Right People
bull Extremely Flexible bull Provides automatic role-based views of
digestible intelligence bull Helps prioritize issues that impact your
business bull Becomes a key tool in proactive
efficient and collaborative management of your systems Without a Service Model Users see only a sea of
alerts with no prioritization by criticality or role
Presenter
Presentation Notes
Needs work but here is where I will re-state value13Decentralize monitoring and alerting 13The alert management system in a large enterprise could have thousands of active alerts at any one time The overwhelming task of wading through these to find what matters is left up to users often with a home-grown filtering solution Providing (useful) summary reports to management is next to impossible13Multiple application groups each with its own manager and support people 13Each application is dependent on a specific set of underlying infrastructure and middleware components RTView can be configured to maintain a ldquoService Modelrdquo a hierarchical arrangement of all components into applications and groups to which they belong This model can be manually created auto-populated in many cases from application metadata or imported from an external CMDB13Present digestible Monitoring Intelligence 13Every user who logs into RTView is assigned a ldquorolerdquo which can be associated with a list of applications or groups for which that role is responsible All alerts and monitoring metrics are filtered so the user sees only what is relevant to that assigned role This dramatically reduces the amount of time wasted searching through irrelevant data or responding to alerts that someone else should be handling13Automatic creation of summary views 13A business area manager may want to see just a few redambergreen lights showing the health state of the applications in that department When an indicator goes red the right support person can be called Chances are that person has seen the same indicator and has already started investigating by drilling down to the detail data that was propagated up to the summary view This is a vast improvement over the traditional model in which the ldquoall-handsrdquo war-room meetings are called to troubleshoot serious issues1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 23
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
Assume I pass back to you13In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 24
copy 2012 SL Corporation All Rights Reserved
Select RTView Customers
Financial Services
Other
eCommerce Retail
Energy Telecom
500+ RTView
Customers
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 25
For More Information
Visit us at SLcom
Request a WebEx Demo
Start an Evaluation
Watch a Video
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 26
Thank You
Questions
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 17
Cross-Correlation and Click-through
1 High level business service impacted
2 Drill down to view component dependencies
3 Identify individual component issue with historical detail
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 18
Application Service-Centric Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 19
bull Overall health state of a service
bull Current health state of each underlying component
bull Prioritize service alerts by criticality and impact
Drill-down into Tabular Cross-Correlation
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 20
And to the the Component Level
Drill down to individual component to view metric history over a configurable time period
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 21
Advanced Visualizations Services Area History Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 22
Getting the Right Info to the Right People
bull Extremely Flexible bull Provides automatic role-based views of
digestible intelligence bull Helps prioritize issues that impact your
business bull Becomes a key tool in proactive
efficient and collaborative management of your systems Without a Service Model Users see only a sea of
alerts with no prioritization by criticality or role
Presenter
Presentation Notes
Needs work but here is where I will re-state value13Decentralize monitoring and alerting 13The alert management system in a large enterprise could have thousands of active alerts at any one time The overwhelming task of wading through these to find what matters is left up to users often with a home-grown filtering solution Providing (useful) summary reports to management is next to impossible13Multiple application groups each with its own manager and support people 13Each application is dependent on a specific set of underlying infrastructure and middleware components RTView can be configured to maintain a ldquoService Modelrdquo a hierarchical arrangement of all components into applications and groups to which they belong This model can be manually created auto-populated in many cases from application metadata or imported from an external CMDB13Present digestible Monitoring Intelligence 13Every user who logs into RTView is assigned a ldquorolerdquo which can be associated with a list of applications or groups for which that role is responsible All alerts and monitoring metrics are filtered so the user sees only what is relevant to that assigned role This dramatically reduces the amount of time wasted searching through irrelevant data or responding to alerts that someone else should be handling13Automatic creation of summary views 13A business area manager may want to see just a few redambergreen lights showing the health state of the applications in that department When an indicator goes red the right support person can be called Chances are that person has seen the same indicator and has already started investigating by drilling down to the detail data that was propagated up to the summary view This is a vast improvement over the traditional model in which the ldquoall-handsrdquo war-room meetings are called to troubleshoot serious issues1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 23
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
Assume I pass back to you13In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 24
copy 2012 SL Corporation All Rights Reserved
Select RTView Customers
Financial Services
Other
eCommerce Retail
Energy Telecom
500+ RTView
Customers
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 25
For More Information
Visit us at SLcom
Request a WebEx Demo
Start an Evaluation
Watch a Video
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 26
Thank You
Questions
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 18
Application Service-Centric Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 19
bull Overall health state of a service
bull Current health state of each underlying component
bull Prioritize service alerts by criticality and impact
Drill-down into Tabular Cross-Correlation
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 20
And to the the Component Level
Drill down to individual component to view metric history over a configurable time period
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 21
Advanced Visualizations Services Area History Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 22
Getting the Right Info to the Right People
bull Extremely Flexible bull Provides automatic role-based views of
digestible intelligence bull Helps prioritize issues that impact your
business bull Becomes a key tool in proactive
efficient and collaborative management of your systems Without a Service Model Users see only a sea of
alerts with no prioritization by criticality or role
Presenter
Presentation Notes
Needs work but here is where I will re-state value13Decentralize monitoring and alerting 13The alert management system in a large enterprise could have thousands of active alerts at any one time The overwhelming task of wading through these to find what matters is left up to users often with a home-grown filtering solution Providing (useful) summary reports to management is next to impossible13Multiple application groups each with its own manager and support people 13Each application is dependent on a specific set of underlying infrastructure and middleware components RTView can be configured to maintain a ldquoService Modelrdquo a hierarchical arrangement of all components into applications and groups to which they belong This model can be manually created auto-populated in many cases from application metadata or imported from an external CMDB13Present digestible Monitoring Intelligence 13Every user who logs into RTView is assigned a ldquorolerdquo which can be associated with a list of applications or groups for which that role is responsible All alerts and monitoring metrics are filtered so the user sees only what is relevant to that assigned role This dramatically reduces the amount of time wasted searching through irrelevant data or responding to alerts that someone else should be handling13Automatic creation of summary views 13A business area manager may want to see just a few redambergreen lights showing the health state of the applications in that department When an indicator goes red the right support person can be called Chances are that person has seen the same indicator and has already started investigating by drilling down to the detail data that was propagated up to the summary view This is a vast improvement over the traditional model in which the ldquoall-handsrdquo war-room meetings are called to troubleshoot serious issues1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 23
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
Assume I pass back to you13In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 24
copy 2012 SL Corporation All Rights Reserved
Select RTView Customers
Financial Services
Other
eCommerce Retail
Energy Telecom
500+ RTView
Customers
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 25
For More Information
Visit us at SLcom
Request a WebEx Demo
Start an Evaluation
Watch a Video
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 26
Thank You
Questions
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 19
bull Overall health state of a service
bull Current health state of each underlying component
bull Prioritize service alerts by criticality and impact
Drill-down into Tabular Cross-Correlation
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 20
And to the the Component Level
Drill down to individual component to view metric history over a configurable time period
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 21
Advanced Visualizations Services Area History Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 22
Getting the Right Info to the Right People
bull Extremely Flexible bull Provides automatic role-based views of
digestible intelligence bull Helps prioritize issues that impact your
business bull Becomes a key tool in proactive
efficient and collaborative management of your systems Without a Service Model Users see only a sea of
alerts with no prioritization by criticality or role
Presenter
Presentation Notes
Needs work but here is where I will re-state value13Decentralize monitoring and alerting 13The alert management system in a large enterprise could have thousands of active alerts at any one time The overwhelming task of wading through these to find what matters is left up to users often with a home-grown filtering solution Providing (useful) summary reports to management is next to impossible13Multiple application groups each with its own manager and support people 13Each application is dependent on a specific set of underlying infrastructure and middleware components RTView can be configured to maintain a ldquoService Modelrdquo a hierarchical arrangement of all components into applications and groups to which they belong This model can be manually created auto-populated in many cases from application metadata or imported from an external CMDB13Present digestible Monitoring Intelligence 13Every user who logs into RTView is assigned a ldquorolerdquo which can be associated with a list of applications or groups for which that role is responsible All alerts and monitoring metrics are filtered so the user sees only what is relevant to that assigned role This dramatically reduces the amount of time wasted searching through irrelevant data or responding to alerts that someone else should be handling13Automatic creation of summary views 13A business area manager may want to see just a few redambergreen lights showing the health state of the applications in that department When an indicator goes red the right support person can be called Chances are that person has seen the same indicator and has already started investigating by drilling down to the detail data that was propagated up to the summary view This is a vast improvement over the traditional model in which the ldquoall-handsrdquo war-room meetings are called to troubleshoot serious issues1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 23
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
Assume I pass back to you13In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 24
copy 2012 SL Corporation All Rights Reserved
Select RTView Customers
Financial Services
Other
eCommerce Retail
Energy Telecom
500+ RTView
Customers
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 25
For More Information
Visit us at SLcom
Request a WebEx Demo
Start an Evaluation
Watch a Video
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 26
Thank You
Questions
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 20
And to the the Component Level
Drill down to individual component to view metric history over a configurable time period
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 21
Advanced Visualizations Services Area History Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 22
Getting the Right Info to the Right People
bull Extremely Flexible bull Provides automatic role-based views of
digestible intelligence bull Helps prioritize issues that impact your
business bull Becomes a key tool in proactive
efficient and collaborative management of your systems Without a Service Model Users see only a sea of
alerts with no prioritization by criticality or role
Presenter
Presentation Notes
Needs work but here is where I will re-state value13Decentralize monitoring and alerting 13The alert management system in a large enterprise could have thousands of active alerts at any one time The overwhelming task of wading through these to find what matters is left up to users often with a home-grown filtering solution Providing (useful) summary reports to management is next to impossible13Multiple application groups each with its own manager and support people 13Each application is dependent on a specific set of underlying infrastructure and middleware components RTView can be configured to maintain a ldquoService Modelrdquo a hierarchical arrangement of all components into applications and groups to which they belong This model can be manually created auto-populated in many cases from application metadata or imported from an external CMDB13Present digestible Monitoring Intelligence 13Every user who logs into RTView is assigned a ldquorolerdquo which can be associated with a list of applications or groups for which that role is responsible All alerts and monitoring metrics are filtered so the user sees only what is relevant to that assigned role This dramatically reduces the amount of time wasted searching through irrelevant data or responding to alerts that someone else should be handling13Automatic creation of summary views 13A business area manager may want to see just a few redambergreen lights showing the health state of the applications in that department When an indicator goes red the right support person can be called Chances are that person has seen the same indicator and has already started investigating by drilling down to the detail data that was propagated up to the summary view This is a vast improvement over the traditional model in which the ldquoall-handsrdquo war-room meetings are called to troubleshoot serious issues1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 23
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
Assume I pass back to you13In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 24
copy 2012 SL Corporation All Rights Reserved
Select RTView Customers
Financial Services
Other
eCommerce Retail
Energy Telecom
500+ RTView
Customers
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 25
For More Information
Visit us at SLcom
Request a WebEx Demo
Start an Evaluation
Watch a Video
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 26
Thank You
Questions
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 21
Advanced Visualizations Services Area History Heatmap
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 22
Getting the Right Info to the Right People
bull Extremely Flexible bull Provides automatic role-based views of
digestible intelligence bull Helps prioritize issues that impact your
business bull Becomes a key tool in proactive
efficient and collaborative management of your systems Without a Service Model Users see only a sea of
alerts with no prioritization by criticality or role
Presenter
Presentation Notes
Needs work but here is where I will re-state value13Decentralize monitoring and alerting 13The alert management system in a large enterprise could have thousands of active alerts at any one time The overwhelming task of wading through these to find what matters is left up to users often with a home-grown filtering solution Providing (useful) summary reports to management is next to impossible13Multiple application groups each with its own manager and support people 13Each application is dependent on a specific set of underlying infrastructure and middleware components RTView can be configured to maintain a ldquoService Modelrdquo a hierarchical arrangement of all components into applications and groups to which they belong This model can be manually created auto-populated in many cases from application metadata or imported from an external CMDB13Present digestible Monitoring Intelligence 13Every user who logs into RTView is assigned a ldquorolerdquo which can be associated with a list of applications or groups for which that role is responsible All alerts and monitoring metrics are filtered so the user sees only what is relevant to that assigned role This dramatically reduces the amount of time wasted searching through irrelevant data or responding to alerts that someone else should be handling13Automatic creation of summary views 13A business area manager may want to see just a few redambergreen lights showing the health state of the applications in that department When an indicator goes red the right support person can be called Chances are that person has seen the same indicator and has already started investigating by drilling down to the detail data that was propagated up to the summary view This is a vast improvement over the traditional model in which the ldquoall-handsrdquo war-room meetings are called to troubleshoot serious issues1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 23
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
Assume I pass back to you13In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 24
copy 2012 SL Corporation All Rights Reserved
Select RTView Customers
Financial Services
Other
eCommerce Retail
Energy Telecom
500+ RTView
Customers
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 25
For More Information
Visit us at SLcom
Request a WebEx Demo
Start an Evaluation
Watch a Video
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 26
Thank You
Questions
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 22
Getting the Right Info to the Right People
bull Extremely Flexible bull Provides automatic role-based views of
digestible intelligence bull Helps prioritize issues that impact your
business bull Becomes a key tool in proactive
efficient and collaborative management of your systems Without a Service Model Users see only a sea of
alerts with no prioritization by criticality or role
Presenter
Presentation Notes
Needs work but here is where I will re-state value13Decentralize monitoring and alerting 13The alert management system in a large enterprise could have thousands of active alerts at any one time The overwhelming task of wading through these to find what matters is left up to users often with a home-grown filtering solution Providing (useful) summary reports to management is next to impossible13Multiple application groups each with its own manager and support people 13Each application is dependent on a specific set of underlying infrastructure and middleware components RTView can be configured to maintain a ldquoService Modelrdquo a hierarchical arrangement of all components into applications and groups to which they belong This model can be manually created auto-populated in many cases from application metadata or imported from an external CMDB13Present digestible Monitoring Intelligence 13Every user who logs into RTView is assigned a ldquorolerdquo which can be associated with a list of applications or groups for which that role is responsible All alerts and monitoring metrics are filtered so the user sees only what is relevant to that assigned role This dramatically reduces the amount of time wasted searching through irrelevant data or responding to alerts that someone else should be handling13Automatic creation of summary views 13A business area manager may want to see just a few redambergreen lights showing the health state of the applications in that department When an indicator goes red the right support person can be called Chances are that person has seen the same indicator and has already started investigating by drilling down to the detail data that was propagated up to the summary view This is a vast improvement over the traditional model in which the ldquoall-handsrdquo war-room meetings are called to troubleshoot serious issues1313
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 23
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
Assume I pass back to you13In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 24
copy 2012 SL Corporation All Rights Reserved
Select RTView Customers
Financial Services
Other
eCommerce Retail
Energy Telecom
500+ RTView
Customers
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 25
For More Information
Visit us at SLcom
Request a WebEx Demo
Start an Evaluation
Watch a Video
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 26
Thank You
Questions
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 23
Real End-to-End Monitoring Requirements Across Tiers Across Vendors Enterprise-wide
bull High-Performance Architecture ndash Distributed cache-based architecture to minimize latency
bull Integrated Dynamic Service Model ndash Auto-generated user-validated
bull Sophisticated cross-correlations and visualizations ndash Both application service-centric and infrastructure-centric
views
ndash Visibility into the data that matter by role criticality severity
Presenter
Presentation Notes
Assume I pass back to you13In order to deliver on the promise of Real End-to-End Monitoring across apps tiers and vendor stacks whatrsquos required are three primary capabilities1313A high-performance data collection and aggregation architecture designed for very low-latency applications ndash leveraging a distributed data model and in-memory caching to capture all the data and efficiently store and process it close to the data source minimizing overhead1313An integrated dynamic service model that relies on multiple sources to collect and validate the relationships between organizations applications and the resources that support them1313And the ability to correlate and visualize complex data sets so as to provide monitoring intelligence tailored by role and look-and-feel so that the right data gets into the right peoplersquos hands that can take appropriate timely action
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 24
copy 2012 SL Corporation All Rights Reserved
Select RTView Customers
Financial Services
Other
eCommerce Retail
Energy Telecom
500+ RTView
Customers
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 25
For More Information
Visit us at SLcom
Request a WebEx Demo
Start an Evaluation
Watch a Video
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 26
Thank You
Questions
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 24
copy 2012 SL Corporation All Rights Reserved
Select RTView Customers
Financial Services
Other
eCommerce Retail
Energy Telecom
500+ RTView
Customers
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 25
For More Information
Visit us at SLcom
Request a WebEx Demo
Start an Evaluation
Watch a Video
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 26
Thank You
Questions
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 25
For More Information
Visit us at SLcom
Request a WebEx Demo
Start an Evaluation
Watch a Video
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 26
Thank You
Questions
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 26
Thank You
Questions
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
copy 2012 SL Corporation All Rights Reserved
copy 2014 SL Corporation All Rights Reserved 27
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor Real-World Context and Application Healthstate ndash Service Model Integration
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
Complex Multi-tier Architectureshellip
Where Traditional Monitoring Failshellip
Redefining End-to-End Monitoring
Silos vs Application-Level Monitoring
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Real-world Context Required
Service Model Integration ndash Maturity Curve
Attempts to move away from Silos - Maturity1Notifications
Attempts to move away from Silos ndash Maturity 2Event Management
Attempts to move away from Silos ndash Maturity 3End to End
Attempts to move away from Silos ndash Maturity 4Integration with Service DeskTrouble Ticketing
RTView EM Architecture
Service Model ndash Organizing the Enterprise
Flexibility ndash Multiple InputsCustom or Off-the-Shelf
The Dynamic Service Model at Work
Cross-Correlation and Click-through
Application Service-Centric Heatmap
Drill-down into Tabular Cross-Correlation
And to the the Component Level
Advanced VisualizationsServices Area History Heatmap
Getting the Right Info to the Right People
Real End-to-End Monitoring RequirementsAcross Tiers Across Vendors Enterprise-wide
Select RTView Customers
For More Information
Thank You
Redefining End-to-End Monitoring with RTViewtradeEnterprise Monitor
