Real-time report generation

Abstract

Methods, systems, and computer programs provide real-time report generation. Based on data collected by the collector computing device, a baseline report is generated for events of the first event type over a period of time. The method receives, from a user, a request to present an updated report with real-time information, the real-time information including events of the first event type during and after the period of time. The method also includes accessing configuration data identifying which event types are enabled for real-time reporting of the user. When the updated report is available in real time to the user, an event update request is sent to the at least one device for unreported events. A new event of the first event type is received, and an updated report is generated by aggregating data from the baseline report and the received new event. Further, the method includes causing the updated report to be presented on a user interface.

Description

Technical Field

[0001] The subject matter disclosed herein relates generally to methods, systems, and machine-readable storage media for generating reports regarding computing system performance. Background Art

[0002] Management platforms for monitoring and managing computer devices often collect data from managed devices in the form of notifications of events that occur at the managed devices, e.g., the device boots up, shuts down, crashes, has a network connection problem, detects an application is installed or launched, has a new user log in, has a configuration change, etc. A typical computing device may report anywhere from one to fifty different types of events or more.

[0003] Typically, the management platform creates reports based on the events received, and the number of daily events can be in the order of hundreds of millions. Therefore, it usually takes a long time to generate reports for all devices and all clients using the management platform. Sometimes, a user may want to obtain status information about a specific device, but the available information only covers events that occurred previously, such as the previous day, because the report was generated in batch mode the previous night. The user wants to obtain real-time information, but it may be difficult to generate this real-time information for a variety of reasons, such as the device has not yet reported all events that occurred during the day, the amount of computing resources to generate the report is large, etc.

[0004] Furthermore, some reports require analysis of multiple types of events, and the combinations of possible events can quickly grow exponentially. Therefore, generating reports for all types of combinations is prohibitively expensive in terms of use of computing resources.

[0005] Therefore, a system that can generate real-time reports on the performance of computer devices would be very useful, especially in platforms with a large number of devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The various drawings depict only example embodiments of the present disclosure and are not to be considered limiting of its scope.

[0007] Figure 1 is a user interface for presenting a performance report according to some example embodiments.

[0008] Figure 2 is an exemplary system architecture for generating endpoint insights, according to some example embodiments.

[0009] Figure 3 A process for generating real-time reports based on real-time collection of event data is shown in accordance with some example embodiments.

[0010] Figure 4 is a flowchart of a method for generating a real-time report according to some example embodiments.

[0011] Figure 5 is a flow diagram of a method for data management in creating real-time reports, according to some example embodiments.

[0012] Figure 6 is a table used to determine which events are configured for prioritized real-time reporting according to some example embodiments.

[0013] Figure 7 is a flow chart of a method for real-time report generation according to some example embodiments.

[0014] Figure 8 is a block diagram illustrating an example of a machine on or by which one or more of the example process embodiments described herein may be implemented or controlled. DETAILED DESCRIPTION

[0015] Example methods, systems, and computer programs relate to real-time report generation. Examples represent possible variations only. Unless otherwise expressly stated, components and functions are optional and may be combined or subdivided, and operations may be sequentially varied or combined or subdivided. In the following description, for the purpose of explanation, numerous specific details are set forth to provide a thorough understanding of the example embodiments. However, it will be apparent to those skilled in the art that the subject matter may be practiced without these specific details.

[0016] In one aspect, the management platform is configured to provide real-time reports including real-time information. To provide real-time reports, a technique is developed for retrieving real-time information from managed devices and then combining information from previously calculated baseline reports with the newly retrieved information from the managed devices.

[0017] In addition, given the large number of possibilities for combining multiple parameters in a report, the system allows the user to configure a predetermined number of event types for generating real-time reports. Thus, each user of the system can select those event types that are more relevant to their operations. By limiting the number of event types, the management platform can reduce the number of possible real-time reports and can plan for a sufficient amount of computing resources required to support all customers.

[0018] Additionally, some event types may affect the results of multiple reports. The management platform can utilize aggregate information calculated for one event in one report and use that information to simplify the generation of other reports utilizing the same event type. The presented embodiments improve data accuracy by obtaining real-time data to perform diagnostics in the system, thereby diagnosing problems faster and improving the performance of the computing environment.

[0019] A general aspect includes a method comprising an operation for generating a baseline report for events of a first event type received from at least one device within a predetermined time period based on data collected by a collector computing device. In addition, the method includes an operation for receiving a request from a user to present an updated report with real-time information. The real-time information includes information about events of the first event type during and after the predetermined time period. The method also includes an operation for accessing configuration data identifying which event types are enabled for real-time reporting for the user, and for determining whether the updated report is accessible to the user in real time based on the configuration data. When the updated report is available in real time, an event update request for unreported events of the first event type is sent to at least one device. In addition, the method includes an operation for receiving new events of the first event type in response to the event update request, and for generating an updated report by aggregating data from the baseline report and the received new events of the first event type, the updated report including data that is newer than the baseline report. In addition, the method includes causing the updated report to be presented on a user interface.

[0020] Figure 1 is a user interface (UI) 102 for presenting a performance report according to some example embodiments. As used herein, a report is a statement containing information about a particular scenario including at least one computing device. The information may be based on one or more events occurring in at least one managed device, and the information may also include calculations (e.g., scores) based on data extracted from the events occurring in at least one managed device.

[0021] UI 102 is provided by Microsoft Endpoint Manager (MEM) TM A sample report is generated, but the embodiments described below can be applied to any management platform. MEM is a cloud-based solution designed to address the challenges associated with deploying, managing, and securing devices in the enterprise. This includes servers, PCs, and mobile devices. IT administrators are able to create policies for personal devices used to access the organization's applications and data. MEM includes Microsoft Intune, a tool for mobile device management and mobile application management. Intune is a cloud-based solution that allows administrators to configure and secure iOS, Android, MacOS, and Windows devices, and can be used to manage the deployment of applications in managed devices.

[0022] Intune provides reports on device compliance, device health, and device trends. In addition, users can create customized reports for specific types of data. Report types are categorized into four areas: operational, organizational, historical, and expert.

[0023] Operational reports provide information about the operation of managed devices. Organizational reports provide a broader summary of the overall view of the infrastructure, such as device management status. Historical reports provide patterns and trends over time. In addition, expert reports allow for the creation of customized reports using specific event data.

[0024] Figure 1 The report shown is for boot performance and provides information about boot time, i.e., the amount of time it takes for the device to boot. Area 104 provides a menu for selecting from available reports. In addition, area 106 provides details for the selected report. In this case, a boot score is provided for booting the device. The example shows a score of 76, which is better than the baseline score of 50. Three different metrics are presented: boot performance, application reliability, and work from anywhere. For each metric, a perspective score is provided.

[0025] Furthermore, area 108 provides additional information for configuring the baseline, filters for reporting, and additional insights and recommendations for the user.

[0026] Another sample report may indicate that several managed devices are running slowly because they have hard drives instead of SSDs. The report may provide such insight as a recommendation that productivity will increase by 10% by changing the device from a hard drive to an SSD.

[0027] The management platform provides slice tags that can be configured for each device. Slice tags are identifiers or codes applied to one or more devices to group the devices into a sliceable set (referred to as a slice). Reports are then generated for each slice to obtain performance metrics associated with the devices in the slice.

[0028] Many customers want to get these reports by slice in real time, but the number of slices may be too large for the system to create all reports in a reasonable amount of time. The criteria for computing the subset of devices is an important metric that is directly related to the cost required to compute the metrics and insights for the report. The correlation between the slicing criteria and the computational cost is exponential because the different combinations of slicing criteria grow exponentially. Assuming a maximum of 100 slice tags per device, and if the system were to process all possible combinations of these 100 slice tags, it would result in 2 100 Or 1,267,650,600,228,229,401,496,703,205,376 (approximately one nonillion) slices.

[0029] The problem becomes more complex if the slicing approach is extended to other dimensions, such as OS version, device manufacturer, app version, app author. As the cardinality of possible values ​​increases with more dimensions, the number of slices grows exponentially. To illustrate this exponential growth, let us assume that the system computes slice reports on a dataset with two dimensions like disk type and manufacturer. The cardinality of disk type is two (e.g., SSD and HDD), which will result in a total of 4 (22) slices. Assuming the cardinality of the manufacturer parameter is 10, it will result in 210 combinations or two billion slices. Combining disk type and manufacturer will result in 22·210 or 8 billion slices for each customer. As seen in this example, the computational cost of slice reports is very large, so organizations often choose to compute a collection of these reports in a batch process with a fixed recurring schedule (e.g., once a day, once a week, once a month) based on the expected expenditure.

[0030] The presented embodiments allow for the creation of real-time sliceable reports that balance computational cost with the number of slice dimensions.

[0031] Figure 2 is an exemplary system architecture for generating endpoint insights according to some example embodiments. The endpoint manager 220 manages operations associated with the management platform, such as collecting events from client devices 204, providing a UI 102 for interacting with the system (e.g., configuring management options, accessing reports, adding custom events, adding custom slices), generating reports, etc. Some embodiments are described with reference to using Windows TM The invention is described with reference to client devices using an operating system, but the same principles can be utilized for any other type of device, such as Apple, Android, Linux, etc.

[0032] During normal operation, the event agent 206 at the client device sends event data to the endpoint manager 220 via the event collector 210 that receives the event. The event collector 210 stores the received events in the event hub (HUB) 212. An example of the event agent 206 is the Intune management extension agent, which is a program installed on a computer device to collect events. Another type of agent is the Client Configuration Manager (CCM) from Microsoft.

[0033] At some point, the events in the event hub 212 are then transmitted to the event database 218 that stores the events of all client devices. The event agent 206 can send events at any time, can buffer events to send multiple events together, can send events immediately after the event occurs, or send events on a scheduled time window. In some embodiments, the event agent 206 sends events after the event occurs or within a predetermined time period. For example, events can be sent in bundles every hour or every night.

[0034] The endpoint analysis module 222 analyzes the event data and generates reports and insights. The endpoint interface server 224 provides the UI 102 to the user 202 for interacting with the management platform. The front-end server 226 can be used to provide management tools that provide the UI 102.

[0035] The real-time event agent 208 in the client device 204 is configured to send events, but the real-time event agent 208 is also configured to receive requests for updates to unreported events. For example, when a real-time report is requested, the endpoint manager 220 sends a request to the real-time event agent 208, and the real-time event agent 208 will check all events queued for transmission and then send all queued events. In this way, the endpoint manager 220 can call the endpoint analysis module 222 to generate a report with the latest data.

[0036] The priority event collector 214 interacts with the real-time event agent 208 to collect events, which are then stored in the priority event hub 216 and ultimately transmitted to the event database 218 .

[0037] Some properties of the collected events include scope tags, OS version, manufacturer, etc. Events can be downloaded via two different channels, where the first channel sends events periodically and is characterized as a slow channel. The second channel is an on-demand channel for collecting real-time events and is called a fast channel.

[0038] When generating real-time reports, endpoint analysis module 222 may access data from event database 218 , event hub 212 , and priority event hub 216 to generate the reports.

[0039] Figure 3A process for generating a real-time report based on real-time collection of event data according to some example embodiments is shown. At operation 401, a user accesses an existing report on UI 102. The report is called a baseline report, and it was previously generated in batch mode. For example, the baseline report is generated using all information for the previous two days. Therefore, the report does not cover events that have occurred since midnight. The user requests on UI 102 to generate a real-time report with the latest data from the managed devices. The endpoint interface server 224 routes the request to the endpoint analysis module 222.

[0040] At operation 402, the endpoint analysis module 222 generates a request to a device associated with a request for a collection of the latest events required for real-time metrics and insights. In some example documents, the request is for all events that have not been reported by the client device 204. In other example embodiments, a time period may be included in the request, and the client device 204 will download all unreported events that fall within the time period. For example, if a baseline report is created for all events before midnight, the request may include a timestamp of the midnight hour so that all events that occur after midnight are reported with a high priority.

[0041] At operation 403, the priority event collector sends a request to the real-time event agent 208 at the client device 204 for real-time upload of the latest event collection. The real-time event agent 208 collects information at the client device and, at operation 404, downloads the requested events to the priority event collector 214. If the client device 204 has no new information related to the request and sends back an acknowledgement, it is notified that there is no new data to report. The downloaded events are stored at the priority event center 216. In some embodiments, at operation 405, the downloaded events are stored in the event database 218.

[0042] At operation 406, the endpoint analysis module 222 reads the high priority real-time event data from the priority event hub 216 or the event database 218 and performs an aggregation of the baseline report previously created using the newly downloaded information. Figure 4 More details are provided on the aggregation process. After the aggregation is performed, at operation 407 , an updated real-time report is presented on the UI 102 .

[0043] Figure 4 is a flowchart of a method 400 for generating a real-time report according to some example embodiments. Although various operations in the flowchart are presented and described sequentially, a person of ordinary skill will appreciate that some or all operations may be performed in a different order, combined or omitted, or performed in parallel.

[0044] Embodiments optimize report generation costs by combining incremental (delta) aggregation with batch aggregation and by dividing the aggregation workload across a small number of jobs.

[0045] The presented solution combines batch processing with real-time reporting based on data aggregation (also called incremental aggregation). Incremental aggregation is the process of combining (e.g., aggregated) newly received information (e.g., incremental data) with previous reports to generate real-time reports that reflect events collected up to the current time. Reportable events are collected from devices on demand when events are needed.

[0046] At operation 401, a request is received for a real-time report containing the latest data collected by a managed device. At operation 402, current event data is retrieved from an event database, which also includes a baseline report that has been requested to be updated with real-time information.

[0047] The real-time report utilizes the baseline data from the baseline report and also uses data downloaded on demand from the managed device to include the latest information.At operation 402, a request is sent to a client device associated with the desired real-time report to upload real-time events that have not yet been downloaded to the management platform.

[0048] At operation 404, real-time events are received from one or more managed client devices and stored in an event database at operation 405. In some example embodiments, events may be stored in a temporary event hub to generate real-time reports before the events are ultimately stored in the event database.

[0049] At operation 406, the baseline report is aggregated with the new event data to generate a real-time report. Aggregation can be performed based on the baseline report data and other intermediate aggregations that may have been performed. Thus, aggregation can build on other previous aggregations.

[0050] When computing aggregate data for reporting, the aggregation work can be partitioned by the customer based on the customer identifier (ID). This partitioning strategy reduces the number of jobs, optimizes disk IO (input / output) operations, and reduces the computational cost for the service.

[0051] The calculated aggregations are stored in memory so that the aggregated data can be reused for other reports. For example, if the requested report is based on boot time events, the aggregated data will generate one or more metrics based on the boot time events (e.g., boot time score, average boot time score). Other reports using the boot time events can then be generated without having to obtain the event data from the database. This reusability can be achieved by normalizing the aggregation pattern to facilitate reuse of several related reports.

[0052] For aggregations that require information from more than one source event and need to be reported in real time, the aggregation is merged with slowly computed batch aggregations to update current metrics and insights. Then, as additional events are received, these metrics are updated so the aggregation remains current.

[0053] In one example, a report is generated for a startup score, and a user wants to update the baseline startup score report with information that is not currently reported. A startup score is assigned to a device based on a startup event based on the amount of time it takes the device to boot up. In this example, the startup score varies between 0-100 for a startup time range between 18 and 120 seconds.

[0054] The device launch score is calculated as the average of all launch events from the past 30 days. The customer launch score is calculated as the average of all devices belonging to that customer.

[0055] Additionally, a startup score for all customers is generated each time a report aggregation runs. Typically, startup events for all of a calling customer's devices from the past 30 days are considered to calculate the startup score. A management platform may manage a large number of devices, and the volume of events considered for the startup score report may be on the order of tens of millions of events. Loading all of these events into memory and calculating the device startup score and the tenant startup score for all customers is computationally very expensive.

[0056] Incremental aggregation simplifies the calculation process by considering new events that arrive in the system after the last aggregation calculation. For example, batch generation has calculated device startup scores and customer startup scores and stored the scores in memory (e.g., event database or another database).

[0057] When the same job runs the next day, instead of looking at all the data again, the job identifies new events that arrived in the system after the previous day's job run and recalculates the launch score. An example embodiment calculates the customer launch score using the following equation:

[0058] CBS t = (CBS t-1 .#CD t-1 + DBC t .#CDNE) / CD t (1)

[0059] In equation (1), CBS t is the customer initiated score at the current time, CBS t-1 is the customer startup score from yesterday (t-1), #CD t-1 is the number of client devices yesterday (t-1), DBC tis the device startup score for new events since yesterday, #CDNE is the number of devices with startup events since yesterday, and CD t Is the total number of current devices.

[0060] Figure 5 is a flow diagram of a method 500 for data management when creating a real-time report, according to some example embodiments. At operation 502, a request for a real-time report is received.

[0061] From operation 502, method 500 flows to operation 504 to request real-time event data. Additionally, at operation 506, a check is made to determine whether report data from a previous run (e.g., a previous batch, a previously aggregated report) is available. If report data is available, method 500 flows to operation 508, and if report data is not available, method 500 flows to operation 510.

[0062] A new report is calculated based on the new event data at operation 510. In addition, if there is data in the event database that has not yet been captured by the report, the data stored in the database is also used to perform calculations for the new report.

[0063] At operation 508, aggregation is performed to calculate a new report based on previous report data (e.g., baseline report) and new event data. It should be noted that there may be some events that are common in multiple reports. The data associated with each event is calculated separately (unless the report requires a combination of event data), and the calculated event metrics can be used for multiple types of reports. In this way, reports that use shared event information can be calculated with fewer computing resources.

[0064] In some example embodiments, the management platform analyzes requests submitted by a user and predicts one or more reports that may be requested. Based on the prediction, the management platform proactively acts to update the predicted reports, even if it requires sending a request for updated event information from the client device. For example, a device has 10 startup events, some crash events, and related application usage or application crash data. A report is called a device timeline, which shows the sequence when the events occur. These sequences of events can be extracted from multiple sources. If the user is investigating a report associated with a crash, the management platform detects that the user will likely select the device timeline report. Therefore, the management platform begins requesting updated information from the associated client devices in preparation for performing data aggregation to generate a real-time report for the device timeline.

[0065] At operation 512, the calculated report is stored in memory, and at operation 514, the report is presented on the UI.

[0066] In some example embodiments, the management platform may be configured to take automatic actions when problems are discovered. For example, if a virtual managed device frequently crashes or has problems running certain applications due to lack of memory, the management platform will automatically increase the amount of memory used for the virtual device. Similarly, if a virtual device runs out of disk space, the management platform will increase the amount of virtual disk storage available to the virtual device.

[0067] Figure 6 is a table for determining which slices are configured for prioritized real-time reporting according to some example embodiments. If all customers had the ability to slice reports by any attribute or combination of attributes, the complexity of the system would be almost unmanageable. This is why in some example embodiments, each customer has the ability to select which slices (e.g., tags) to select for high priority reports, which are reports that include real-time data obtained from managed devices.

[0068] The management platform allows each customer to select which slice is enabled for priority reporting. One method includes creating a table 602 by customer and slice to determine which is the prioritized slice. Each row corresponds to a different customer, and the first column is for the customer ID. The remaining columns are for different slices. The corresponding cell value then indicates whether the slice is prioritized (e.g., 1) or not prioritized (e.g., 0).

[0069] When a user requests a priority report, table 602 is checked to determine whether the slices required for the report are available for on-demand real-time reporting, i.e., high priority events. Those events for the high priority slices that are configured for real-time reporting can then be downloaded on-demand from the client device.

[0070] Other example embodiments may utilize other data structures for configuring slices by customers, such as indexes, hash tables, lists of customer-allowed slices, and the like.

[0071] The solution is designed so that slicing can be performed using any metadata attribute that the management platform can access. An example scenario is "Automated deployment rings based on device health". Each deployment ring for this use case can be thought of as a set of sliced ​​devices, and thus a given application or driver can be automatically deployed to the next large ring based on the health of the devices in the previous deployment ring.

[0072] In some example embodiments, the number of slices allowed per customer may be configurable based on customer accounts, such as monthly revenue, device minutes, etc. By limiting the number of slices available in the system, the management platform is able to limit the amount of computing resources required to generate insights for all available data slices.

[0073] In some example embodiments, a UI is provided to the customer for selecting the slices that can be used for super priority reporting. The customer can add, delete or change the number of configured slices.

[0074] Figure 7 700 is a flow chart of a method 700 for real-time report generation according to some example embodiments. The computer-implemented method 700 is used for troubleshooting and improving computer performance. Although the various operations in the flow chart are presented and described sequentially, a person of ordinary skill will understand that some or all of the operations may be performed in a different order, combined or omitted, or performed in parallel.

[0075] Operation 702 is for generating a baseline report for events of a first event type received from at least one device within a predetermined time period based on data collected by a collector computing device.

[0076] From operation 702, the method 700 flows to operation 704 for receiving a request from a user to present an updated report with real-time information. The real-time information includes information about events of a first event type during and after a predetermined time period. From operation 704, the method 700 flows to operation 706 to access configuration data identifying which event types are enabled for real-time reporting for the user.

[0077] From operation 706 , the method 700 flows to operation 708 , where a determination is made as to whether the updated report is accessible to the user in real time based on the configuration data.

[0078] From operation 708, method 700 flows to operation 710, where an event update request for unreported events of the first event type is sent to at least one device when an updated report is available in real time.

[0079] From operation 710 , the method 700 flows to operation 712 for receiving a new event of the first event type in response to the event update request.

[0080] From operation 712 , the method 700 flows to operation 714 for generating an updated report by aggregating data from the baseline report and the received new events of the first event type, the updated report including newer data than the baseline report.

[0081] From operation 714 , the method 700 flows to operation 716 to present the updated report on the user interface.

[0082] In one example, aggregating data includes calculating current statistics associated with the event type based on previously calculated statistics and information received in new events for the event type.

[0083] In one example, the method 700 also includes changing a configuration of at least one device based on the information in the updated report.

[0084] In one example, method 700 also includes providing an option in the user interface for configuring event types that are enabled for real-time access.

[0085] In one example, the method 700 also includes identifying relevant reports based on the information about the first event type, and updating the relevant reports based on the calculations performed to generate the updated reports.

[0086] In one example, a first agent in at least one device is configured to download events to an endpoint manager, wherein a second agent in at least one device is configured to receive event update requests to provide real-time event data.

[0087] In one example, baseline reports are calculated periodically in batch mode.

[0088] In one example, the user interface includes an option to request real-time information to update the baseline report.

[0089] In one example, configuration data is stored in a table by customer identifier and slice type.

[0090] In one example, a report is a statement containing information about a particular scenario including at least one computing device, the information being based on one or more events occurring at the at least one computing device.

[0091] In view of the above disclosure, various examples are described below. It should be noted that one or more features of the examples taken in isolation or combination should be considered within the disclosure of this application.

[0092] Another general aspect is a system including a memory including instructions and one or more computer processors. The instructions, when executed by the one or more computer processors, cause the one or more computer processors to perform operations, the operations including: generating a baseline report for events of a first event type received from at least one device within a predetermined time period based on data collected by a collector computing device; receiving a request from a user to present an updated report with real-time information, the real-time information including information about events of the first event type during and after the predetermined time period; accessing configuration data identifying which event types are enabled for real-time reporting for the user; determining whether the updated report is accessible to the user in real time based on the configuration data; when the updated report is available in real time, sending an event update request for unreported events of the first event type to at least one device; receiving new events of the first event type in response to the event update request; generating an updated report by aggregating data from the baseline report and the received new events of the first event type, the updated report including data that is newer than the baseline report; and presenting the updated report on a user interface.

[0093] In yet another general aspect, a machine-readable storage medium (e.g., a non-transitory storage medium) includes instructions that, when executed by a machine, cause the machine to perform operations, the operations comprising: generating a baseline report based on data collected by a collector computing device for data of events of a first event type received from at least one device within a predetermined time period; receiving a request from a user to present an updated report with real-time information, the real-time information including information about events of the first event type during and after the predetermined time period; accessing configuration data identifying which event types are enabled for real-time reporting for the user; determining, based on the configuration data, whether the updated report is accessible in real time to the user; when the updated report is available in real time, sending an event update request for unreported events of the first event type to at least one device; receiving new events of the first event type in response to the event update request; generating an updated report by aggregating data from the baseline report and the new events received of the first event type, the updated report including data that is newer than the baseline report; and presenting the updated report on a user interface.

[0094] Figure 8800 is a block diagram showing an example of a machine 800 on which one or more example process embodiments described herein may be implemented or controlled. In alternative embodiments, the machine 800 may operate as a standalone device, or may be connected (e.g., networked) to other machines. In a networked deployment, the machine 800 may operate in the capacity of both a server machine, a client machine, or a server-client network environment. In an example, the machine 800 may act as a peer machine in a peer-to-peer (P2P) (or other distributed) network environment. In addition, although only a single machine 800 is shown, the term "machine" should also be considered to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more methods discussed herein (such as via cloud computing, software as a service (SaaS) or other computer cluster configurations).

[0095] As described herein, examples may include or may be operated by logic, multiple components or mechanisms. A circuit system is a collection of circuits implemented in a tangible entity including hardware (e.g., simple circuits, gates, logic). Circuit system members may be flexible over time and underlying hardware variability. A circuit system includes members that can perform specified operations individually or in combination when in operation. In an example, the hardware of the circuit system may be greatly designed to perform specific operations (e.g., hardwired). In an example, the hardware of the circuit system may include variably connected physical components (e.g., execution units, transistors, simple circuits) that include physically modified (e.g., magnetically, electrically, by the movable placement of unchanged mass particles) to encode instructions for specific operations in a computer-readable medium. When connecting physical components, the underlying electrical properties of the hardware components are changed (e.g., from insulators to conductors, and vice versa). Instructions enable embedded hardware (e.g., execution units or loading mechanisms) to create members of the circuit system in hardware via variable connections to perform parts of specific operations when in operation. Therefore, when the device operates, the computer-readable medium is communicatively coupled to other components of the circuit system. In an example, any physical component may be used in more than one member of more than one circuit system. For example, in operation, an execution unit may be used in a first circuit of a first circuit system at one point in time and reused by a second circuit in the first circuit system or a third circuit in the second circuit system at a different time.

[0096] The machine (e.g., computer system) 800 may include a hardware processor 802 (e.g., a central processing unit (CPU), a hardware processor core, or any combination thereof), a graphics processing unit (GPU) 803, a main memory 804, and a static memory 806, some or all of which may communicate with each other via an interconnect (e.g., a bus) 808. The machine 800 may also include a display device 810, an alphanumeric input device 812 (e.g., a keyboard), and a user interface (UI) navigation device 814 (e.g., a mouse). In an example, the display device 810, the alphanumeric input device 812, and the UI navigation device 814 may be a touch screen display. The machine 800 may additionally include a mass storage device (e.g., a drive unit) 816, a signal generating device 818 (e.g., a speaker), a network interface device 820, and one or more sensors 821, such as a global positioning system (GPS) sensor, a compass, an accelerometer, or another sensor. The machine 800 may include an output controller 828, such as a serial (e.g., universal serial bus (USB)), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC)) connection to communicate with or control one or more peripheral devices (e.g., printer, card reader).

[0097] The mass storage device 816 may include a machine-readable medium 822 on which is stored one or more sets of data structures or instructions 824 (e.g., software) embodying or used by any one or more of the techniques or functionality described herein. The instructions 824 may also reside, completely or at least partially, within the main memory 804, within the static memory 806, within the hardware processor 802, or within the GPU 803 during execution by the machine 800. In an example, one or any combination of the hardware processor 802, the GPU 803, the main memory 804, the static memory 806, or the mass storage device 816 may constitute a machine-readable medium.

[0098] Although the machine-readable medium 822 is shown as a single medium, the term "machine-readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database and / or associated caches and servers) configured to store one or more instructions 824. The term "machine-readable medium" may include any medium capable of storing, encoding, or carrying instructions 824 for execution by the machine 800 and causing the machine 800 to perform any one or more of the techniques of the present disclosure, or any medium capable of storing, encoding, or carrying data structures used by or associated with such instructions 824. Non-limiting machine-readable medium examples may include solid-state memory and optical and magnetic media. In an example, a polymeric machine-readable medium includes a machine-readable medium 822 having a plurality of particles having a constant (e.g., stationary) mass. Therefore, a bus machine-readable medium is not a transient propagating signal. Specific examples of bus machine-readable media may include nonvolatile memory, such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

[0099] The instructions 824 may also be sent or received over the communication network 826 via the network interface device 820 using a transmission medium.

[0100] Throughout this specification, multiple instances can implement components, operations or structures described as single instances. Although the individual operations of one or more methods are shown and described as individual operations, one or more of the individual operations can be performed simultaneously, and there is no need to perform the operations in the order shown. The structure and function presented as individual components in the example configuration can be implemented as a combined structure or component. Similarly, the structure and function presented as a single component can be implemented as an individual component. These and other changes, modifications, additions and improvements fall within the scope of the subject matter of this article.

[0101] The embodiments shown herein are described in sufficient detail to enable those skilled in the art to practice the disclosed teachings. Other embodiments may be used and derived, so that structural and logical substitutions and changes may be made without departing from the scope of the present disclosure. Therefore, the specific embodiments should not be considered restrictive, and the scope of the various embodiments is limited only by the appended claims and the full scope of equivalents to which these claims are entitled.

[0102] In addition, as used in the present disclosure, phrases of the form "at least one of A, B, or C", "at least one of A, B, and C", etc. should be interpreted as selecting at least one from the group including "A, B, and C". Unless explicitly stated otherwise, in the present disclosure, this wording does not mean "at least one" of "at least one of A, B, and at least one of C". As used in the present disclosure, the example "at least one of A, B, or C" will cover any of the following selections: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, and {A, B, C}.

[0103] In addition, multiple instances may be provided as a single instance for the resources, operations, or structures described herein. In addition, the boundaries between various resources, operations, modules, engines, and data stores are arbitrary to some extent, and specific operations are shown in the context of specific illustrative configurations. Other functional allocations are contemplated and may fall within the scope of various embodiments of the present disclosure. Typically, structures and functions presented as separate resources in an example configuration may be implemented as combined structures or resources. Similarly, structures and functions presented as single resources may be implemented as separate resources. These and other changes, modifications, additions, and improvements fall within the scope of the embodiments of the present disclosure represented by the appended claims. Therefore, the specification and drawings are considered to be illustrative rather than restrictive.

Claims

1. A computer-implemented method for troubleshooting and improving computer performance, the method comprising: generating a baseline report for events of a first event type received from at least one device within a predetermined time period based on data collected by the collector computing device; receiving a request from a user to present an updated report having real-time information including information about events of the first event type during and after the predetermined time period; accessing configuration data identifying which event types are enabled for real-time reporting of the user; determining, based on the configuration data, whether the updated report is accessible to the user in real time; sending, to the at least one device, an event update request for unreported events of the first event type when the updated report is available in real time; In response to the event update request, receiving a new event of the first event type; generating the updated report by aggregating data from the baseline report and the received new events of the first event type, the updated report including newer data than the baseline report; as well as The updated report is caused to be presented on a user interface.

2. The method of claim 1, wherein aggregating data comprises: A current statistic associated with an event type is calculated based on previously calculated statistics and information received in the new event for the event type.

3. The method according to claim 1, further comprising: The configuration of at least one device is changed based on the information in the updated report.

4. The method according to claim 1, further comprising: Options are provided in the user interface for configuring event types that are enabled for real-time access.

5. The method according to claim 1, further comprising: identifying relevant reports based on the information about the first event type; as well as The associated report is updated based on calculations performed to generate the updated report.

6. The method of claim 1, wherein a first agent in the at least one device is configured to download events to an endpoint manager, wherein a second agent in the at least one device is configured to receive the event update request to provide real-time event data. The method of claim 1 , wherein the baseline report is calculated periodically in a batch mode.

8. The method of claim 1, wherein the user interface includes an option to request real-time information to update the baseline report.

9. The method of claim 1, wherein the configuration data is stored in a table according to a customer identifier and a slice type.

10. The method of claim 1, wherein the baseline report is a statement containing information about a specific scenario including the at least one device, the information being based on one or more events occurring at the at least one device.

11. A system for troubleshooting and improving computer performance, the system comprising: a memory including instructions; as well as one or more computer processors, wherein the instructions, when executed by the one or more computer processors, cause the system to perform operations comprising: generating a baseline report for events of a first event type received from at least one device within a predetermined time period based on data collected by the collector computing device; receiving a request from a user to present an updated report having real-time information including information about events of the first event type during and after the predetermined time period; accessing configuration data identifying which event types are enabled for real-time reporting of the user; determining, based on the configuration data, whether the updated report is accessible to the user in real time; sending, to the at least one device, an event update request for unreported events of the first event type when the updated report is available in real time; In response to the event update request, receiving a new event of the first event type; generating the updated report by aggregating data from the baseline report and the received new event of the first event type, the updated report including newer data than the baseline report; and The updated report is caused to be presented on a user interface.

12. The system of claim 11, wherein the aggregated data comprises: A current statistic associated with an event type is calculated based on previously calculated statistics and information received in the new event for the event type.

13. The system of claim 11, wherein the instructions further cause the one or more computer processors to perform operations comprising: The configuration of at least one device is changed based on the information in the updated report.

14. A system comprising means for performing the method of any one of claims 1 to 10.

15. At least one machine-readable medium comprising instructions which, when executed by a machine, cause the machine to perform the method of any one of claims 1 to 10.

Images