Dynamic monitoring

Abstract

In some examples, a controller dynamically configures properties associated with monitoring performed by an agent. The controller stores metadata related to the agent in a repository. The controller receives first sensor data from the agent that does not include the metadata, and retrieves the metadata from the repository using index information in the first sensor data.

Description

[0001] This invention was made with government support under Agreement No. DE-AC52-07NA27344 awarded by the U.S. Department of Energy, National Nuclear Security Administration (DOE / NNSA). The U.S. Government has certain rights in this invention. Background Art

[0002] System management may be performed to control various electronic devices or achieve target operating goals in response to events (e.g., security events such as malware attacks, failures or errors, etc.) System monitoring may be performed to collect data for determining operational characteristics of the computing environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Some embodiments of the disclosure are described with respect to the following figures.

[0004] Figure 1 is a block diagram of an arrangement including a monitoring system manager according to some examples.

[0005] Figure 2 is a block diagram of a monitoring framework according to some examples.

[0006] Figure 3 is a block diagram of a storage medium having machine-readable instructions stored thereon, according to some examples.

[0007] Figure 4 is a block diagram of a system according to some examples.

[0008] Figure 5 is a flow diagram of a process according to some examples.

[0009] Throughout the drawings, the same reference numerals refer to similar, but not necessarily identical, elements. The drawings are not necessarily to scale, and the dimensions of some parts may be exaggerated to more clearly illustrate the examples shown. In addition, the drawings provide examples and / or implementations consistent with the description; however, the description is not limited to the examples and / or implementations provided in the drawings. DETAILED DESCRIPTION

[0010] In the present disclosure, unless the context clearly indicates otherwise, the use of the terms "a / an" or "the" is intended to include the plural forms as well. Similarly, when used in the present disclosure, the terms "includes / including / comprises / comprising", "have / having" specify the presence of stated elements, but do not exclude the presence or addition of other elements.

[0011] A monitoring system for a computing environment may include an agent that performs monitoring data collection. An "agent" may refer to an entity that collects monitoring data of a computing environment. An agent may include one or more devices. A device may refer to a (logical or physical) entity for organizing sensors. A sensor refers to an entity that obtains measurement data (also referred to as "sensor data") related to a computing environment. A sensor may be a hardware sensor or a sensor implemented using machine-readable instructions. Examples of measurement data that a sensor may collect include any one or a combination of the following: resource usage (such as the use of processing resources, communication resources, storage resources, etc.), event information (e.g., information related to anomalies such as data errors, program failures, hardware failures, information indicating attacks by unauthorized entities such as malware or people, temperature exceeding a threshold, resource performance below a threshold, etc.), environmental data (e.g., temperature, pressure, information related to system infrastructure (such as cooling equipment, etc.), etc.), and the like.

[0012] In some examples, the monitoring system may employ a static configuration in which the characteristics of data collection are statically set and / or the agents used to collect sensor data are static. For example, the number of agents may be fixed, or the monitoring system may specify that agents are provided by a specific entity (e.g., a company, an individual, an organization, etc.). The monitoring system may not be able to accept monitoring data from an agent that is not provided by the specified entity.

[0013] Furthermore, different types of agents may employ different sensor data formats, which may cause compatibility issues with monitoring systems.

[0014] According to some embodiments of the present disclosure, a dynamic monitoring system dynamically configures an agent including corresponding sensors for monitoring a computing environment, which may include an electronic device. The computing environment may include a network to which the electronic device is coupled. Examples of networks include local area networks, wide area networks, storage area networks, public networks, and the like. Examples of electronic devices include computers (e.g., desktop computers, notebook computers, server computers, tablet computers, etc.), storage systems, communication nodes, vehicles, vehicle controllers, electrical appliances, and the like. In some examples, the computing environment may also include supporting infrastructure, such as cooling systems, power delivery systems, and the like.

[0015] The computing environment may include a cloud computing environment, a data center, or any other type of environment that includes electronic devices.

[0016] The dynamic monitoring system receives sensor data and metadata separate from the sensor data. "Sensor data" refers to any data collected as part of monitoring a computing environment. Sensor data may include raw measurement data from a sensor or transformed / processed data based on the raw measurement data. Sensor data may also include information about detected events.

[0017] The separation of sensor data from metadata allows metadata to be transmitted once or infrequently, so that sensor data that is transmitted more frequently does not have to include metadata. A message containing sensor data without metadata can have a smaller size than a message containing both sensor data and metadata. In addition, in some examples, sensor data can be formatted according to a specified format according to a grammar that governs the formatting of sensor data transmitted by various agents interacting with the dynamic monitoring system.

[0018] Figure 1 1 is a block diagram of an example arrangement including a monitoring system manager 102 capable of interacting with an agent 104 that collects sensor data related to various aspects of a computing environment 106. Note that the agent 104 may be deployed as part of the computing environment 106, such as machine-readable instructions and / or as a hardware component that is part of or coupled to the electronic device 105 and / or other devices of the computing environment 106. In other examples, the agent 104 may be separate from the computing environment 106 and may be coupled to the computing environment 106 via a network (e.g., 108).

[0019] Monitoring system manager 102 includes a plurality of computing devices that may communicate with agent 104 via network 108. As used herein, "plurality" of elements may refer to one or more elements.

[0020] In accordance with Figure 1 In the example of , each agent 104 includes multiple devices 110. Device 110 is a logical entity or a physical entity that organizes multiple sensors 112. As an example, a device may include a thermostat that may have multiple sensors. As another example, a device may include a network card with multiple ports, where each port can be connected to a corresponding sensor. As a further example, a device may be a group of sensors.

[0021] In accordance with Figure 1 In the example of , while the device 110 and the sensor 112 are depicted as being part of each respective agent 104 , it should be noted that the device and / or sensor may be external to the agent 104 but communicatively coupled to the agent 104 .

[0022] In other examples, the concept of a device 110 for organizing a plurality of sensors 112 is not employed. In such examples, the sensors 112 may be part of the agent 104 or may be communicatively coupled to the agent 104.

[0023] The monitoring system manager 102 includes a dynamic configuration engine 114. As used herein, an "engine" may refer to a hardware processing circuit, which may include any one or some combination of a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or another hardware processing circuit. Alternatively, an "engine" may refer to a combination of a hardware processing circuit and machine-readable instructions (software and / or firmware) that may be executed on the hardware processing circuit.

[0024] The dynamic configuration engine 114 can dynamically configure a plurality of properties associated with monitoring performed by the plurality of agents 104, such as to meet changing specifications (eg, from a customer or the monitoring framework itself). Such dynamically configured properties are part of the monitoring configuration.

[0025] Examples of properties that can be dynamically configured by the dynamic configuration engine 114 include any one or some combination of the following: the frequency of collecting sensor data, the amount of sensor data to be collected, the specific sensors to be employed (which may include enabling and / or disabling sensors and / or removing or adding new sensors), and the like.

[0026] In some examples, changing the frequency or amount of sensor data collected allows the dynamic configuration engine 114 to adjust the incoming rate of incoming sensor data to meet requirements set, for example, by a customer. Changing the properties of the monitoring performed by the agent 104 can also change the load placed on resources associated with sensor data collection. For example, an increase in the incoming rate of incoming sensor data may result in increased use of storage resources and communication resources. Similarly, having to process larger amounts of incoming sensor data may also result in increased use of processing resources. Processing sensor data may include converting the sensor data into another form, such as a human-readable form, a database format that can be queried, and the like.

[0027] The dynamic configuration performed by the dynamic configuration engine 114 may be for each specific monitoring job to be performed by the monitoring system manager 102. A monitoring job may refer to an operation involving the collection of sensor data for a specific number of electronic devices 105 and / or other devices of the computing environment 106, at a specified time, for a specified number of metrics (e.g., resource usage metrics, etc.), in response to specified event(s), and the like.

[0028] Monitoring jobs may be requested using job requests 116 received by job scheduler 120 from consumers 118. Job scheduler 120 may be implemented using a plurality of computing devices. Job scheduler 120 may be included as part of monitoring system manager 102 and / or may be external to monitoring system manager 102.

[0029] A “consumer” may refer to an electronic device, a program (including machine-readable instructions), or a user. A job request 116 is sent from a consumer 118 to a job scheduler 120 over a network (eg, 108 ) or is received at a user interface of the job scheduler 120 .

[0030] The job request may specify information related to the monitoring job, such as multiple metrics to be monitored, multiple electronic devices and / or other devices to be monitored, a schedule regarding when monitoring is to occur, event(s) to trigger sensor data collection, and the like.

[0031] The job scheduler 120 is used to schedule monitoring jobs for execution. In some cases, the job scheduler 120 may receive multiple job requests from one consumer 118 or from multiple consumers 118. The job requests received by the job scheduler 120 may be stored in a job request queue (e.g., contained in a memory) of the job scheduler 120. The job scheduler 120 may then execute monitoring jobs for the corresponding job requests according to a specified order (e.g., based on the time when the job request is received, the priority of the job request, and / or based on any other factor or combination of factors).

[0032] For monitoring jobs scheduled by the job scheduler, the dynamic configuration engine 114 of the monitoring system manager 102 can dynamically configure a plurality of properties associated with monitoring performed by the agent 104. The dynamic configuration can be performed before any given monitoring job begins and / or can be performed during a given monitoring job.

[0033] In some examples, different events 122 (e.g., time events, abnormal events, or another event) can cause the dynamic configuration engine 114 to change the monitoring configuration of the monitoring job. For example, the dynamic configuration engine 114 can change the monitoring configuration of the monitoring job at different times. As another example, the dynamic configuration engine 114 can change the monitoring configuration of the monitoring job for different degrees of abnormality (e.g., data errors, program failures, hardware failures, attacks, etc.).

[0034] In a further example, the monitoring system manager 102 may trigger a monitoring job that is not requested in any job request from the consumer 118. For example, the monitoring system manager 102 may trigger a monitoring job in response to certain events 122 (e.g., anomalies). For such a monitoring job triggered by an event 122, the dynamic configuration engine 114 may dynamically configure a plurality of properties associated with monitoring performed by the agent 104 in response to the event 122.

[0035] Dynamically changing the monitoring configuration for a first monitoring job may result in changes in the use of resources used in monitoring. For example, increasing the frequency of data collection by a sensor may result in increased data storage, increased data communications, and increased processing workload for the first monitoring job. If multiple monitoring jobs are competing for the same set of resources, the increased resource allocation for the first monitoring job may be offset by changing the monitoring configuration of the second monitoring job and reducing the resource allocation for the second monitoring job.

[0036] In addition to being able to perform dynamic configuration of monitoring jobs, the monitoring framework provided by the monitoring system manager 102 also supports the separation of metadata from sensor data, so that the agent 104 can send sensor data to the monitoring system manager 102 without including the metadata in the message containing the sensor data. "Message" can refer to any data unit used to carry sensor data, such as a packet, frame, etc. There may be a large amount of metadata associated with the sensor data, so that having to include the metadata in the message containing the sensor data will increase the overall size of each message, thereby consuming network bandwidth.

[0037] The metadata of the data collection entities (e.g., agents 104, devices 110, and / or sensors 112) may be transmitted to the monitoring system manager 102 only once or less frequently than the sensor data from the data collection entities. For example, the metadata may be transmitted to the monitoring system manager 102 as part of a registration process (discussed further below).

[0038] The monitoring system manager 102 can store the metadata 128 received by the monitoring system manager 102 in a repository 130. The repository 130 can be implemented using any or some combination of a plurality of storage devices, such as disk-based storage devices, solid-state storage devices, etc. The repository 130 can be part of the monitoring system manager 102 or external thereto.

[0039] In some examples, mapping information 132 may associate different data collection entity identifiers (IDs) 134 with corresponding metadata 128. In some examples, mapping information 132 may take the form of a lookup table having entries that each associate a corresponding ID 134 with a corresponding metadata 128. An identifier may refer to a number, a string (e.g., numbers, letters, etc.) that uniquely identifies a corresponding data collection entity, such as an agent 104, a device 110, and / or a sensor 112. An example of an ID is a universally unique identifier (UUID).

[0040] In some examples, the message carrying sensor data transmitted by the agent 104 to the monitoring system manager 102 may further include a data collection entity ID, which can be used by the monitoring system manager 102 to retrieve the corresponding metadata 128 based on the mapping information 132 that associates the data collection entity ID in the message with the corresponding metadata 128.

[0041] Further, the messages carrying the sensor data have a common format according to a pattern (or patterns) defined by the pattern information 124. Such messages having a common format may be referred to as "standardized messages" that the monitoring system manager 102 may expect to receive from the agents 104. The pattern information 124 may be stored in a repository 126. The repository 126 may be implemented using a plurality of storage devices. The repository 126 is coupled to the network 108 so that entities on the network 108 (including the agents 104 and the monitoring system manager 102) may access the pattern information 124.

[0042] In other examples, pattern information 124 may be stored in a storage device of monitoring system manager 102 , such as in repository 130 .

[0043] In some examples, based on Apache Avro TM , the schema information 124 may be part of a schema registry. TM A data serialization system is provided for transmitting data having a specified format. In other examples, other types of schemas may be used for messages carrying sensor data.

[0044] In some examples, the schema information 124 can be extended or modified to support the changed format of the messages carrying the sensor data to meet the new specifications without losing backward or forward compatibility. The ability to extend or modify the schema information 124 enables a dynamic data model during the life cycle of the monitoring framework, thereby adapting to the changing specifications of the customer for data monitoring.

[0045] Furthermore, any agent 104 from any source may be added to the monitoring framework provided by the monitoring system manager 102. Thus, the monitoring framework does not have to limit data collection to agents from a particular source, but rather any agent from any source may be added to the monitoring framework as long as the agent supports message formatting according to the pattern information 124.

[0046] In some examples, by using standardized messages, agents from different sources can be transparent to the monitoring system manager 102 (in other words, the monitoring system manager 102 does not have to know any specific specifications of the agent 104 and can still receive messages carrying sensor data from the agent 104). In this way, the monitoring system manager 102 can work with newly added agents 104 without having to change the monitoring framework (e.g., the monitoring framework does not have to be changed to support the new format of the newly added agent).

[0047] Figure 2 200 according to some embodiments of the present disclosure. The monitoring framework 200 supports control data provided through a control channel 202, sensor data 204 transmitted by the agent 104 through a message bus 206, and metadata 208 transmitted by the monitoring system manager 102 through the message bus 206.

[0048] As used herein, a "message bus" refers to a communication link having characteristics determined by a protocol, which may be a standardized protocol, an open source protocol, or a proprietary protocol. For example, message bus 206 may be provided by Apache Kafka, an open source platform. TM Using such a message bus 206 , a receiver (eg, a consumer 118 or a monitoring system manager 102 ) can subscribe to data feeds (including sensor data) provided by a producer (eg, an agent 104 ).

[0049] Another messaging-based system that can be used includes RabbitMQ TM , which provides message-oriented middleware to allow the transmission of messages (including sensor data) between the agent 104 and other entities (such as consumers 118 and the monitoring system manager 102).

[0050] In other examples, other types of communication links may be used. TM A subscription-based interface or RabbitMQ TM A message-oriented broker) can be associated with the communication link to allow a recipient (e.g., consumer 118 or monitoring system manager 102) to receive sensor data from agent 104.

[0051] "Control channel" 202 may refer to any interface through which control messages may be sent (eg, from agent 104 to monitoring system manager 102 or vice versa). Control channel 202 enables dynamic configuration of system monitoring by agent 104 and helps reduce the size of monitoring data transmissions.

[0052] For example, the agent 104 may perform a registration (210) with the monitoring system manager 102 over the control channel 202 before sending any sensor data. The registration process allows the agent 104 to identify itself to the monitoring framework and allows the agent 104 to register its device(s) 110 and sensor(s) 112. The registration may provide the monitoring system manager 102 with metadata about the agent 104 (e.g., the type of agent, identifier, description, etc.), metadata about the device(s) 110 to which the agent is connected (e.g., location, identifier, type, etc.), and metadata about the device(s) sensor 112 (e.g., identifier, minimum data collection frequency, maximum data collection frequency, default data collection frequency, valid value ranges for metrics collected by the sensor 112, units of measurement, types of metrics measured, etc.).

[0053] While examples of metadata are given above, it should be noted that in other examples, the agent 104 may provide additional or alternative metadata during registration.

[0054] The metadata may be used by the monitoring system manager 102 to dynamically control the connected agents 104 (e.g., change the collection frequency of the agents 104, specific devices 110, or specific sensors 112, disable or enable sensors 112, perform automated checks on collected sensor data, etc.).

[0055] As part of the registration, the sensor 112 may be associated with corresponding metadata, such as based on the monitoring system manager 102 updating the sensor ID that may be associated with the metadata. Figure 1 Mapping information 132. Through this association, the sensor 112 can send a message with sensor data but without metadata (thereby reducing the message size) that has been provided to the monitoring system manager 102 as part of the agent registration.

[0056] As an example, a message carrying sensor data of the sensor 112 and transmitted by the agent 104 may have the following triple form: {timestamp, sensor ID, and value}, where “value” represents the sensor measurement result of the sensor 112. When the monitoring system manager 102 receives the message, the sensor ID is used to retrieve the corresponding metadata, which the monitoring system manager 102 can then use to control monitoring operations or other tasks.

[0057] In other examples, the messages carrying sensor data may have different forms.

[0058] like Figure 2 As further shown, the agent 104 may perform a deregistration (212) to the monitoring system manager 102 via the control channel 202. Deregistration may cause the sensor(s) 112, the device(s) 110, or the entire agent 104 to no longer be active in the monitoring framework—that is, the deregistered sensor(s) 112, the device(s) 110, or the agent 104 will no longer transmit sensor data.

[0059] The monitoring system manager 102 may also perform other configuration operations with respect to the agent 104 or the device(s) 110 or sensor(s) 112 to which the agent is connected. For example, the monitoring system manager 102 may activate or deactivate 214 a sensor 112 or multiple sensors 112, such as by sending activation or deactivation messages (multiple). Activating a sensor 112 causes the sensor to be ready to collect data, while deactivating a sensor 112 causes the sensor to no longer be able to collect data.

[0060] As another example, monitoring system manager 102 may start or stop data collection by sensor 112 (e.g., by sending a start message or a stop message) (216). A start message may cause active sensor 112 to start data collection. A stop message may cause active sensor 112 to stop data collection.

[0061] As another example, the monitoring system manager 102 may change the sensor collection behavior (218) (e.g., by changing the frequency at which the sensor(s) 112 collect data, changing the time interval at which the sensor(s) 112 collect data, changing the metric(s) collected, etc.).

[0062] As a further example, monitoring system manager 102 may update a monitoring configuration (218) of agent 104 or device(s) 110 or sensor(s) 112 to which the agent is connected. This may be performed by sending a configuration update message to agent 104. Note that activating or deactivating a sensor (214), starting or stopping sensor collection (216), and changing sensor behavior (218) are examples of configuration updates. Note that rather than listing configuration operations 214, 216, and 218 separately, these configuration operations may be included as part of configuration update 218.

[0063] In some examples, the agent 104 may also initiate a configuration operation (any of 214, 216, 218, and 220) with the monitoring system manager 102. For example, the agent 104 may send its monitoring configuration to the monitoring system manager 102 so that the monitoring system manager 102 can set the monitoring configuration for the agent 104. As another example, the agent 104 may update the monitoring configuration and send the updated monitoring configuration (e.g., a sensor has been activated or deactivated, a sensor has been started or stopped, etc.) to the monitoring system manager 102.

[0064] Agent 104 may store a copy of its configuration data (which may also be stored by monitoring system manager 102). The configuration data may include information that defines the monitoring configuration. If agent 104 were to lose its configuration data for any reason (e.g., due to a failure, malfunction, or data error), agent 104 may request the configuration data from monitoring system manager 102 (220). Similarly, monitoring system manager 102 may request configuration data from agent 104.

[0065] The metadata 208 sent by the monitoring system manager 102 via the message bus 206 may be stored in the persistent storage device 224 (e.g., stored in a Figure 1 The sensor data 204 sent by the agent 104 via the message bus 206 may also be stored by the monitoring system manager 102 in the persistent storage 224, where it may be retrieved later, such as by the consumer 118. Additionally, the monitoring system manager 102 may forward the sensor data to another entity, such as the consumer 118.

[0066] An example scenario is described below. A consumer 118 may submit an indication that a computing environment 106 ( Figure 1 ) to execute a job request with a monitored frequency. The job scheduler 120 processes the job request and schedules the requested job for execution on the identified resources (eg, one or more computing nodes).

[0067] For example, the job scheduler 120 may notify the monitoring system manager 102 to request a monitoring job where data collection is to occur at a specified frequency (e.g., on a list of computing nodes). The job notification from the job scheduler 120 to the monitoring system manager 102 may further indicate, for example, the selected sensor(s) 112 to be used, the category of sensor(s) 112 (e.g., temperature sensor, power consumption sensor, sensor for tracking processor usage, etc.), the specific sensor(s) indicated, the category (e.g., power readings and energy readings), the metric(s) to be collected, and the like.

[0068] In response, the monitoring system manager 102 may contact the (already running) agent 104 at the computing node(s) in the list to start data monitoring. In addition, the monitoring system manager 102 may start the agent 104 at the computing node(s). The monitoring system manager 102 may provide configuration data for the monitoring job to the contacted and / or started agent 104, wherein the configuration data may identify the sensor(s) 112 to be used for data collection, the frequency of data collection, and the like.

[0069] In some examples, a consumer 118 submitting a job request may specify the generation of a job-specific topic in the monitoring framework. A job-specific topic may refer to a category of data to be collected, such as a topic related to measurements made by a sensor, a topic related to an event, etc. Each job-specific topic may be associated with a corresponding queue for storing the corresponding data.

[0070] After configuration of the agent and applicable devices and / or sensors is successfully completed, the monitoring system manager 102 may notify the job scheduler 120 .

[0071] After the monitoring infrastructure is successfully dynamically set up, the monitoring job is started. If a job-specific topic is used, the agent 104 can write the data of the topic to the corresponding queue. The consumer 118 who submitted the job request can access the collected sensor data (possibly in the corresponding queue).

[0072] In another example scenario, the dynamic change of data collection by the monitoring framework can be based on the detection of a specified event, such as an anomaly. For example, if the performance of the program (expressed as the number of input / output (I / O) transactions per time interval) is less than a specified threshold, information related to the anomaly is provided to the monitoring system manager 102.

[0073] The monitoring system manager 102 retrieves information about the resources on which the program is executed and retrieves a monitoring configuration associated with the anomaly. For example, the monitoring configuration may specify an increased collection frequency for metrics related to the program's I / O transactions.

[0074] The monitoring system manager 102 may send the monitoring configuration to the appropriate agent(s) 104 to collect data related to the anomaly. The agent(s) 104 collect the data, which is then provided to the monitoring system manager 102 and / or the consumer 118. For example, a root cause analysis may be performed on the collected data to identify the root cause of the anomaly.

[0075] In some examples, the dynamic monitoring framework discussed herein can provide some of the following examples. Standardizing framework messages using patterns enables consumers to conveniently interact with the monitoring framework using interfaces. The dynamic monitoring framework can adapt to customer needs without requiring changes to the underlying framework.

[0076] In addition, the resources allocated to the monitoring being performed by the monitoring framework can be adjusted as the monitoring load changes. For example, a relatively small amount of resources may be initially allocated to the monitoring framework, and as the monitoring load increases, additional resources may be assigned.

[0077] Furthermore, agents from a variety of different sources may be dynamically added to or removed from the monitoring framework, as long as the agent supports messages according to the specified pattern(s).

[0078] Dynamic configuration of the monitoring framework can also provide flexibility in the metrics being monitored to support the addition of new services that may be based on certain metrics.

[0079] The separation of sensor data and metadata allows the monitoring framework to more efficiently transmit the large amount of sensor data collected by the agent. Likewise, in some examples, a publish-subscribe communication model (wherein consumers subscribe to sensor data published by the agent) allows for more efficient techniques for transmitting data to consumers. An extensible or modifiable schema allows the message format to change over time to support new devices and / or sensors while still providing backward or forward compatibility.

[0080] Figure 3 is a block diagram of a non-transitory machine-readable or computer-readable storage medium 300 having stored thereon machine-readable instructions that, when executed, cause a controller to perform various tasks. For example, a controller may include Figure 1 Monitoring system manager 102.

[0081] The machine-readable instructions include instructions for dynamically configuring and communicating with an agent (e.g., Figure 1 104) executes a dynamic configuration instruction 302 of the monitoring-related attribute. Dynamically configuring an attribute may refer to dynamically configuring one or more attributes. The dynamic configuration may be for a monitoring job requested by a consumer or for a monitoring job initiated in response to a specified event.

[0082] The machine-readable instructions include metadata storage instructions 304 for storing metadata related to the agent in a repository (e.g., 130). In some examples, the metadata includes information about properties of a sensor that is part of the agent or coupled to the agent. The metadata may also include information about a device and the agent. The properties of the sensor relate to operational characteristics of the sensor (e.g., data collection frequency of the sensor, etc.) or data characteristics of the data collected by the sensor (e.g., a valid value range).

[0083] The machine-readable instructions include sensor data receiving instructions 306 for receiving first sensor data from an agent that does not include metadata. In some examples, the first sensor data is in accordance with a format defined by a grammar that determines the formatting of sensor data from an agent interacting with a controller. Metadata can be received from the agent as part of registration of the agent with the controller.

[0084] The machine-readable instructions include metadata retrieval instructions 308 for retrieving metadata from a repository using index information (e.g., an identifier of a sensor or another data collection entity) in the first sensor data. The retrieved metadata can be used to determine monitoring configurations and other details associated with the sensor data, such as identifiers and locations of corresponding agents 104 and devices 110.

[0085] Figure 4 4 is a block diagram of a system 400 according to some examples. For example, the system 400 may be the monitoring system manager 102. The system 400 includes a hardware processor 402 (or multiple hardware processors). The hardware processor may include a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or another hardware processing circuit.

[0086] System 400 further includes storage media 404 storing machine-readable instructions executable on hardware processor 402 to perform various tasks. Machine-readable instructions executable on a hardware processor may refer to instructions executable on a single hardware processor or instructions executable on multiple hardware processors.

[0087] The machine-readable instructions include metadata receiving instructions 406 for receiving metadata related to the agent from the agent as part of registration performed by the agent. The metadata received by the system 400 can be stored in a repository (e.g., 132) containing mapping information (e.g., 132) that associates sensor identifiers (or identifiers of other data collection entities) with corresponding metadata. Figure 1 130).

[0088] The machine-readable instructions include monitoring configuration determining instructions 408 for determining a monitoring configuration for the agent based on the metadata. The monitoring configuration specifies properties associated with sensor data collection by the agent.

[0089] The machine-readable instructions include sensor data receiving instructions for receiving sensor data excluding the metadata from the agent, wherein the sensor data is collected according to the monitoring configuration. The sensor data is included in the message excluding the metadata. Therefore, the message size can be reduced.

[0090] Figure 5 is a flow diagram of process 500 according to some examples.

[0091] Process 500 includes a controller (e.g., Figure 1 The monitoring system manager 102 receives (at 502) metadata from an agent. For example, the metadata may be received when the agent registers with the controller.

[0092] The controller determines (at 504) a monitoring configuration related to sensor data collection by sensors associated with the agent. The monitoring configuration may be set dynamically by the controller based on metadata, or the monitoring configuration may be set based on configuration data sent by the agent to the controller.

[0093] The controller receives (at 506) from the agent first sensor data collected according to the monitoring configuration. The first sensor data is included in a first message that does not include metadata.

[0094] The controller updates (at 508) the monitoring configuration. The update of the monitoring configuration may be initiated by the controller or may be requested by the agent.

[0095] The controller receives (at 510) from the agent second sensor data collected according to the updated monitoring configuration. The second sensor data is included in a second message that does not include metadata.

[0096] Storage media (e.g. Figure 3 300 or Figure 4404) may include any one or some combination of the following: semiconductor memory devices, such as dynamic or static random access memory (DRAM or SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory or other types of non-volatile memory devices; magnetic disks, such as fixed floppy disks and removable disks; another magnetic medium, including tape; optical media, such as compact disks (CDs) or digital video disks (DVDs); or another type of storage device. Note that the instructions discussed above may be provided on one computer-readable or machine-readable storage medium, or alternatively, may be provided on multiple computer-readable or machine-readable storage media distributed in a large system with possibly multiple nodes. Such one or more computer-readable or machine-readable storage media are considered to be part of an article (or product). An article or product may refer to any manufactured single component or multiple components. One or more storage media may be located in a machine running machine-readable instructions, or at a remote site, from which machine-readable instructions may be downloaded over a network for execution.

[0097] In the foregoing description, many details are set forth to enable an understanding of the subject matter disclosed herein. However, embodiments may be practiced without some of these details. Other embodiments may include modifications and variations of the details discussed above. The appended claims are intended to cover such modifications and variations.

Claims

1. A non-transitory machine-readable storage medium comprising instructions, which when executed cause a controller to perform the following operations: receiving metadata at the controller from an agent associated with a sensor, wherein the metadata includes an operational characteristic of the sensor; determining a monitoring configuration involving collection of sensor data from the sensor associated with the agent; storing mapping information in a repository, the mapping information relating different index information to different metadata containing operational characteristics of the sensor; receiving, at the controller, first sensor data from the agent, the first sensor data being collected according to the monitoring configuration, wherein the first sensor data is contained in a first message, the first message including first index information and not including the metadata including the operational characteristic of the sensor; retrieving the metadata including the operational characteristics of the sensor from the mapping information using the first index information in the first message; updating the monitoring configuration; receiving, at the controller, second sensor data from the agent, the second sensor data being collected according to the updated monitoring configuration, wherein the second sensor data is included in a second message, the second message including the first index information and not including the metadata including the operational characteristic of the sensor; and The metadata including the operating characteristics of the sensor is retrieved from the mapping information using the first index information in the second message.

2. The non-transitory machine-readable storage medium of claim 1, wherein: When the instructions are executed, the controller performs the following operations: The first sensor data is received according to a format defined by a grammar that governs formatting of sensor data from an agent that interacts with the controller.

3. The non-transitory machine-readable storage medium of claim 1, wherein: When the instructions are executed, the controller performs the following operations: The metadata including operational characteristics of the sensor is received from the agent as part of registration of the agent with the controller.

4. The non-transitory machine-readable storage medium of claim 1, wherein: The operational characteristics of the sensor included in the metadata include the frequency with which the sensor collects data.

5. The non-transitory machine-readable storage medium of claim 1, wherein: The operational characteristics of the sensor included in the metadata include a range of valid values ​​for data collected by the sensor.

6. The non-transitory machine-readable storage medium of claim 1, wherein: When the instructions are executed, the controller performs the following operations: Attributes associated with monitoring performed by the agent are dynamically configured by sending configuration data to the agent to operate according to the monitoring configuration.

7. The non-transitory machine-readable storage medium of claim 6, wherein: The instructions, when executed, cause the controller to dynamically configure properties associated with monitoring performed by the agent in response to a job request specifying a monitoring operation.

8. The non-transitory machine-readable storage medium of claim 1, wherein: The first index information includes an identifier of the sensor, and the different index information in the mapping information includes identifiers of different sensors.

9. The non-transitory machine-readable storage medium of claim 1, wherein: When the instructions are executed, the controller performs the following operations: The monitoring configuration is received from the agent during registration.

10. The non-transitory machine-readable storage medium of claim 1, wherein: When the instructions are executed, the controller performs the following operations: The monitoring configuration is updated by sending a configuration update to the agent.

11. The non-transitory machine-readable storage medium of claim 1, wherein: The first sensor data is received via a communication link associated with an interface for enabling access to the first sensor data in transmission from the agent to the controller.

12. The non-transitory machine-readable storage medium of claim 1, wherein: When the instructions are executed, the controller performs the following operations: A deregistration is performed with respect to the agent to remove the agent or the sensor associated with the agent.

13. The non-transitory machine-readable storage medium of claim 1, wherein: When the instructions are executed, the controller performs the following operations: The metadata is used to dynamically control the agent.

14. A system comprising: processor; as well as a non-transitory storage medium storing instructions executable on the processor to: At the system, receiving metadata from an agent as part of registration performed by the agent, the metadata including operational characteristics of a sensor associated with the agent; storing mapping information in a repository, the mapping information relating different index information to different metadata containing operational characteristics of the sensor; determining a monitoring configuration involving collection of sensor data from the sensor associated with the agent; receiving, at the system, first sensor data from the agent, the first sensor data being collected according to the monitoring configuration, wherein the first sensor data is contained in a first message, the first message including first index information and not including the metadata including the operational characteristic of the sensor; retrieving the metadata including the operational characteristics of the sensor from the mapping information using the first index information in the first message; updating the monitoring configuration; receiving, at the system, second sensor data from the agent, the second sensor data being collected according to the updated monitoring configuration, wherein the second sensor data is included in a second message, the second message including the first index information and not including the metadata including the operational characteristic of the sensor; and The metadata including the operating characteristics of the sensor is retrieved from the mapping information using the first index information in the second message.

15. The system of claim 14, wherein: The sensor data is represented by a grammar according to grammar information stored in a repository.

16. The system of claim 14, wherein: The operational characteristics of the sensor included in the metadata include a frequency of data collection by the sensor or a valid value range of data collected by the sensor.

17. A method comprising: receiving, by a controller, metadata from an agent associated with a sensor, wherein the metadata includes operating characteristics of the sensor; determining, by the controller, a monitoring configuration related to collecting sensor data by the sensor, the sensor being associated with the agent; storing mapping information in a repository, the mapping information relating different index information to different metadata containing operational characteristics of the sensor; receiving, by the controller from the agent, first sensor data collected according to the monitoring configuration, wherein the first sensor data is included in a first message, the first message including first index information and not including the metadata including an operational characteristic of the sensor; retrieving, by the controller, the metadata including the operating characteristics of the sensor from the mapping information using the first index information in the first message; updating, by the controller, the monitoring configuration; receiving, by the controller, from the agent, second sensor data collected according to the updated monitoring configuration, wherein the second sensor data is included in a second message, the second message including the first index information and not including the metadata including the operating characteristics of the sensor; and The metadata including the operating characteristics of the sensor is retrieved from the mapping information by the controller using the first index information in the second message.

18. The method of claim 17, wherein: The operational characteristics of the sensor included in the metadata include the frequency with which the sensor collects data.

Images