InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

System and Method for Remote Server Diagnostics

IP.com Disclosure Number: IPCOM000202467D
Publication Date: 2010-Dec-16
Document File: 2 page(s) / 61K

Publishing Venue

The IP.com Prior Art Database


The general problem solved is delivering remote diagnostics to servers while minimizing the impact on the client's sever resources. Current diagnostic systems are limited by the fact that the data collection and analysis mechanisms are bound together and running in the client's environment.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 2

System and Method for Remote Server Diagnostics

This solution consists of three main parts:
1.A data collection daemon running on the client's server, gathering records from the machines to be monitored and placing them in a database or sending them to the server entity for analysis,

2. A rule-based analytics engine, sitting outside of the client environment, that determines root causes for multi-event failure patterns and predicts potential future failures,

3. A web-based user interface, that the customer logs into in order to see a real-time composite image of the machines for the display of the information.

The Dameon polls the server for error events and raw sensor data (e.g., voltage, temperature, etc.). As changes occur within the customer's environment this data is sent the service provider's cloud. A server in the cloud applies the analytics engine to the data received, This generates a stream of events. These events are then applied to a set of rules which tags each element of the event stream with its root cause. This data is then translated back into a visual interpretation of the data. The server then presents the data in real time through a web interface to the customer. When the user purchases a service contract with service provider, they are given a block of unique loginIDs tied to the customerID. The customer will login with one of the unique "loginIDs" associated with their account. The "uniqueID" can be associated with multiple servers. The loginID has a contract end date field in the same table. This is checked against the current date to verify if the account is till valid. Once validated the customer will then be able to view their server specific information.

In the cloud there sits a Rules database which has a table for common rules that the data from each server in the any client environment is compared against. Then there is a customer specific table which will host the unique rules that are created specifically by the customer. Each time a rule identifies an issue it is logged in a separate table. It pulls the "customerID", "Serial #", "Rule table type", "rule #". This table can be queried and sent to a report to help identify trends across companies and servers. It will also all...