Abstract: In a datacenter setting, a summary of differences and similarities between two or more states of the same or similar systems are predicted. Initially, a Long Short-Term Memory (LSTM) neural network is trained with to predict a summary describing the state change between at least two states of the datacenter. Given a set of training data (at least two datacenter states that are annotated with a state change description), the LSTM neural network learns which similarities and differences between the datacenter states correspond to the annotations. Accordingly, given a set of test data comprising at least two states of a datacenter represented by context graphs that indicate a plurality of relationships among a plurality of nodes corresponding to components of a datacenter, the LSTM neural network is able to determine a state change description that summarizes the differences and similarities between the at least two states of the datacenter.

Abstract: In a datacenter setting, annotations or descriptions of relevant parts or subgraphs corresponding to components in the datacenter are predicted. Given a set of training data (library of subgraphs seen in the past labeled with a textual description explaining why were they considered relevant enough to be placed in the historical database), the recurrent neural network (RNN) learns how to combine the different textual annotations coming from each relevant region into a single annotation that describes the whole system. Accordingly, given a set of input or test data (datacenter state modeled a context graph that is not annotated), the system determines which regions of the input graph are more relevant, and for each of these regions, the RNN predicts an annotation even in a previously unseen or different datacenter infrastructure.

Abstract: Provided is a computer system that includes a processor and a memory coupled to the processor, the memory including computer readable program code embodied therein that, when executed by the processor, causes the processor to generate a catalog that identifies a plurality of tasks that a plurality of network resources are available to perform, the network resources including Internet-of-things devices and human network resources and to generate, in response to receiving a request to perform a complex project, a solution path that includes an ordered list corresponding to selected ones of the plurality of tasks that are capable of aggregately performing the complex project, wherein the selected ones of the plurality of tasks define the solution path in an edge graph that include the plurality of tasks represented as edges therein.

Abstract: As a network increases in size and complexity, it becomes increasingly difficult to monitor and record relationships between components in the network. The lack of knowledge regarding component relationships can make it difficult to adequately and timely perform analysis of network issues or conditions. As a result, automated generation of a context graph that displays relationships among both hardware and software components in a network can help keep pace with a growing network and improve network analysis. The context graph may be generated based, for example, on event data (alternately referred to as event indications) generated by network components and/or event monitoring agents and network topology information. Additionally, the context graph may be augmented to display inter-component relationships based on multi-event correlations. The context graph can be used to assist in troubleshooting network issues or performing root cause analysis.

Abstract: A first event notification is received. The first event notification is associated with a first event. Criteria is determined based, at least in part, on the first event notification. A first component is identified based, at least in part, on the criteria a component graph. An operational status associated with the first component is determined. It is determined not to generate a second event notification based, at least in part, on the operational status.

Abstract: A process model can be modified to be more precise by unrolling loops of the process model and evaluating or using the process model with the loops unrolled. After determining loops in a process model, sequential forward path executions of each loop identified in an input process model are counted within each trace of an event log. For each loop, a greatest common divisor (gcd) of the sequential forward path execution counts is determined. An intermediate process model is then created with the loops unrolled according to the respective gcd(s). The event log is then (re)played with the intermediate process model to identify traversed elements of the process model. Elements of the intermediate process model that were not traversed are removed to yield a more precise process model.

Abstract: A thing-sourcing project request including requirements for a thing-sourcing task that requires data input by a thing-sourcing device is received from a requestor device. A determination is made if real-time data is needed in order to complete the thing-sourcing task. In response to determining that real-time data is not needed, a determination is made if a similar thing-sourcing task has been previously completed. If not, the method determines if the thing-sourcing task can be completed using pre-existing data. If so, a data archive is searched for relevant pre-existing data that can be used to complete the thing-sourcing task. The thing-sourcing task is completed using the relevant pre-existing data, and a response to the thing-sourcing project request is transmitted to the requestor device.

Abstract: A root cause analysis system utilizes ACs corresponding to component types in a network to construct a diagnosis model. The system generates the ACs based on component models for each component type in the network and may perform offline evaluation of the ACs using determined conditional probabilities and potential state values and cache the results. When an issue is identified at a component, the system uses a relational schema to determine a set of components on which the component depends and creates a diagnosis model for performing root cause analysis. The diagnosis model includes the component type ACs corresponding to each of the components identified in the relational schema. The system populates the diagnosis model with conditional probabilities and observed state values determined from event indications generated by the components. The system outputs a most probable explanation of the issue based on evaluation of the diagnosis model.

Abstract: A first event notification is received. The first event notification is associated with a first event. Criteria is determined based, at least in part, on the first event notification. A first component is identified based, at least in part, on the criteria a component graph. An operational status associated with the first component is determined. It is determined not to generate a second event notification based, at least in part, on the operational status.

Abstract: As a network increases in size and complexity, it becomes increasingly difficult to monitor and record relationships between components in the network. The lack of knowledge regarding component relationships can make it difficult to adequately and timely perform analysis of network issues or conditions. As a result, automated generation of a context graph that displays relationships among both hardware and software components in a network can help keep pace with a growing network and improve network analysis. The context graph may be generated based, for example, on event data (alternately referred to as event indications) generated by network components and/or event monitoring agents and network topology information. Additionally, the context graph may be augmented to display inter-component relationships based on multi-event correlations. The context graph can be used to assist in troubleshooting network issues or performing root cause analysis.

Abstract: As a network increases in size and complexity, it becomes increasingly difficult to monitor and record relationships between components in the network. The lack of knowledge regarding component relationships can make it difficult to adequately and timely perform analysis of network issues or conditions. As a result, automated generation of a context graph that displays relationships among both hardware and software components in a network can help keep pace with a growing network and improve network analysis. The context graph may be generated based, for example, on event data (alternately referred to as event indications) generated by network components and/or event monitoring agents and network topology information. Additionally, the context graph may be augmented to display inter-component relationships based on multi-event correlations. The context graph can be used to assist in troubleshooting network issues or performing root cause analysis.

Abstract: Requirements for a thing-sourcing project that comprises a thing-sourcing task are posted to thing-sourcing participant devices. Electronic requests are received from a first group of the thing-sourcing participant devices, to participate in the task. The electronic request identifies a portion of the task that can be accomplished by the thing-sourcing participant device, but none of the electronic requests indicate that the task can be accomplished entirely by any one of the thing-sourcing participant devices. A second group of the thing-sourcing participant devices is selected from the first group of the thing-sourcing participant devices. The second group of the thing-sourcing participant devices can collectively accomplish the task, even though none of the second group of the thing-sourcing participant devices can accomplish the task individually. Execution of the thing-sourcing project by the second group of the thing-sourcing participant devices is then coordinated.

Abstract: Current behavior can be evaluated to efficiently identify behavioral anomalies with process models of different scopes and/or different degrees of precision. For meaningful behavioral evaluation of an actor (i.e., a user or a device), these multiple process models are constructed with different sets of event logs of a system. A model of a scope of an individual actor and a model of a scope of a group of actors are constructed and used for evaluation. These models of different scope expand “normal” behavior of an actor to include behavior of the group of actors. Although these process models of different scopes likely have different precision, additional models of different precision and/or different scopes can be constructed and used for behavioral evaluation. These different process models allow for behavioral variation within relevant groups of actors.

Abstract: A collaboration pattern is created by crowdsourcing participants by publishing requirements for a crowdsourcing project that includes a crowdsourcing task to the crowdsourcing participants, receiving candidate collaboration patterns for the crowdsourcing task from the crowdsourcing participants, selecting one of the candidate collaboration patterns, and executing the crowdsourcing project using the one of the candidate collaboration patterns. Related methods, systems and computer program products are provided.