SYSTEM AND METHOD FOR STORING AND TRANSFERING CONFIGURATION DATA TO EDGE SERVERS - Patent application

Abstract

Systems and methods are provided for capturing, managing, and distributing configuration data in one or more computing networks. In an example, a flexible configuration definition framework is provided to enable simplified capture, management, and distribution of configuration data to various computing devices in a complex network. Rather than tabular data, the framework allows for representation of configuration settings in a non-relational, text-based data format, enabling easy searching and filtering of configuration data and targeted distribution of data to machines and applications within the network.

Description

[Technical Field]

[0001] [CROSS-REFERENCE TO RELATED APPLICATIONS] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 385,498, filed November 30, 2022, entitled "Systems and Methods for Storing and Transporting Configuration Data to Edge Servers," which is incorporated herein by reference in its entirety. [Background technology]

[0002] Configuration information in complex computing networks can be vast and difficult to define, distribute, and maintain. For example, edge computing is becoming increasingly widespread. In edge computing, an application or service may be run on multiple edge servers, and the edge server closest to a requesting client device may respond to such requests, thereby reducing latency and unnecessary transfer of data across the network. However, a computing network may include thousands of edge servers hosting application instances, and those application instances may need to be coordinated through configuration data. For example, configuration data may define both machine and application behaviors, such as roles, group memberships, timeout settings, and the like. Traditional centralized relational databases and table structures that store such configuration data may be unwieldy in an edge computing environment.

[0003] It is about this general technological environment that aspects of the present disclosure are directed. Summary of the Invention

[0004] This Summary is provided to introduce selected concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0005] In an aspect, the present application describes a system comprising at least one processing circuit and a memory operatively connected to the at least one processing circuit and storing instructions that, when executed by the at least one processing circuit, cause the system to perform a method. In an example, the method may include: storing at least one configuration document comprising a plurality of configuration tags, wherein the at least one configuration document has a non-relational, text-based data format, and, for each configuration tag of the plurality of configuration tags, comprising a configuration tag name and a configuration setting array, the configuration setting array having at least one configuration value and at least one configuration range. In an example, the method may further include determining a first subset of the configuration tags of the at least one configuration document applicable to a first edge node of the network; determining a second subset of the configuration tags of the at least one configuration document applicable to a second edge node of the network; providing at least first configuration tag-value (CTV) pairs of the first subset of configuration tags; and providing at least second CTV pairs of the second subset of configuration tags.

[0006] Other aspects of the present application will become apparent from the following description and claims. [Brief explanation of the drawings]

[0007] Non-limiting and non-exhaustive examples are described with reference to the following figures:

[0008] [Figure 1]FIG. 1 is a block diagram illustrating an exemplary computing system according to aspects of the present application.

[0009] [Figure 2] FIG. 1 is a block diagram illustrating an exemplary configuration system according to aspects of the present application.

[0010] [Figure 3] 1 is a flowchart illustrating an exemplary method according to an aspect of the present application.

[0011] [Figure 4] FIG. 1 is a block diagram illustrating a computing environment in which aspects of the present application may be implemented. DETAILED DESCRIPTION OF THE INVENTION

[0012] In the following detailed description, reference is made to the accompanying drawings that form a part hereof, and in which specific embodiments or examples are shown by way of illustration. These aspects may be combined, other aspects may be utilized, and structural changes may be made without departing from the disclosure. The examples may be implemented as methods, systems, or devices. Thus, the examples may take the form of a hardware implementation, an entirely software implementation, or an implementation combining software and hardware aspects. In addition, all systems described with reference to the figures may include one or more machines or devices operatively connected to cooperate to provide the functionality of the described system. Therefore, the following detailed description is not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims and their equivalents.

[0013] FIG. 1 illustrates a system 100 for capturing, storing, and serving configuration data. In an example, components of system 100 may operate as a content delivery network (CDN), although the present application is not necessarily limited to any particular type of network. In an example, system 100 may include a configuration provisioning system 106. Configuration provisioning system 106 may provide an interface to allow configuration data to be received, edited, and / or deleted (e.g., by one or more administrator systems 108). For example, configuration provisioning system 106 may include an application programming interface (API) that can accept program commands to receive, edit, or delete configuration data stored by configuration provisioning system 106. In another example, the configuration provisioning system may provide or facilitate a user interface (e.g., displayed on one or more administrator systems 108) to receive, edit, and / or delete configuration data, as described further herein. Although only one configuration provisioning system 106 and one administrator system 108 are shown, multiple of each may be implemented.

[0014] System 100 may further comprise one or more intermediate servers 110 and edge nodes 112 and 114. In examples in which system 100 may operate as a CDN, one or more of intermediate servers 110 may comprise a control core, such as non-exclusively described in U.S. Patent Application Publication No. 2019 / 0327140, which is incorporated by reference herein. In examples, edge nodes 112 and 114 are used to provide content and / or services to clients 116. In examples, clients 116 may comprise client devices that access services and / or content at edge nodes 112 and 114. As discussed, system 100 may comprise a CDN in which content and / or computing services are provided to clients via the logically closest edge node (e.g., edge node 112 or 116).

[0015] In a non-exclusive example, a content delivery network (CDN or CD network) efficiently distributes content (e.g., resources) to clients on behalf of one or more content providers (network customers). CDN customers (e.g., content providers) provide their content (e.g., resources) through an origin source (origin server or origin). CDNs may also provide an over-the-top transport mechanism for efficiently transmitting content in the reverse direction, from clients to origin servers. Both end users (clients) and content providers benefit from using a CDN. Using a CDN allows content providers to offload (and thereby reduce) burden from their own servers (e.g., their origin servers). Clients benefit by being able to obtain content more consistently and with less latency.

[0016] Typically, multiple edge nodes in a CDN (e.g., edge nodes 112 and 114) may process or handle any particular client request for content (e.g., one or more resources). In an example, a rendezvous system associates a particular client request with one or more “best” or “optimal” (or “least desirable”) edge nodes to handle that particular request. The “best” or “optimal” edge node (e.g., edge node 112 or 114) may be one that is close to the client 116 (by some measure of network cost) and is not overloaded. Generally, the selected edge node 112 or 114 (i.e., the edge node selected by the rendezvous system for the client request) may serve the requested content to the client 116 or may direct the client 116 to a location where the client 116 can attempt to obtain the requested content. The selected edge node 112 or 114 need not have the requested content at the time the request is made, even if the selected edge node 112 or 114 ultimately serves the requested content to the requesting client. As used herein, each node may comprise one or more computing devices and storage devices, which are generally co-located.

[0017] In an example CDN, one or more intermediate servers 110 acting as a control core may include components dedicated to accepting and managing configuration data. The CDN may have or provide default policies and procedures for the delivery and / or processing of subscriber content. These system defaults may be specified and / or included in one or more system configuration files or objects. In addition, customers of the CDN (e.g., content providers) may customize aspects of the delivery and / or processing of their content by the CDN. The customizations may be specified and / or included in one or more customer configuration files or objects, such as scripts.

[0018] The configuration may be maintained, controlled, and managed, at least in part, through administrator system 108 by a configuration mechanism that may be accessed through a suitable interface, such as a RESTful API. The configuration information may define any number of configuration characteristics for a particular customer, for system 100 as a whole, and / or for particular devices or applications residing on system 100. In a non-exclusive CDN example, this may include how the CDN should handle customer characteristics (e.g., how the CDN should service requests for that customer's resources). This may include alias hostnames, origin servers to fill from them, and any policies associated with content associated with that customer.

[0019] An administrator system 108 may be provided with an interface for administrators to upload, modify, and / or delete configuration data. The configuration data may be used to inform servers in system 100 of their cluster group membership and thus their role in the CDN hierarchy (or other server hierarchy), to control routing of inbound traffic within the CDN, to describe Internet Protocol (IP) addresses belonging to the CDN to external systems, and to control application-specific and / or machine-specific settings such as timeouts to use when reading from sockets, etc.

[0020] The configuration data 118, 120 stored in the intermediate server 110 (e.g., a control core) may further be distributed to the edge nodes 112 and 114. For example, the configuration data 118, 120 may be distributed from the intermediate server 110 to the edge nodes 112 and 114 whenever an update to the configuration data is received at the intermediate server 110. In another example, the configuration data 118, 120 is distributed from the intermediate server 110 to an edge node, such as edge node 112 or 114, periodically or when an edge node (e.g., 112 or 114) requests it. For example, a cache or other component at an edge node may receive a request from application 117a or 117b (or other component, such as an operating system) for the configuration data 118, determine that the configuration data is not stored (or has expired) at the edge node 112, and request the configuration data from the intermediate server 110. In another example, the configuration data 118 may be determined by the edge node 112 from a configuration document (as discussed further below). As discussed below, the configuration data 118, 120 (which may take the form of configuration documents, configuration files, or configuration tag-value (CTV) pairs) may then be stored in a cache associated with the edge node. For example, edge nodes 112 and 114 may each include one or more computing devices, memory, and associated cache storage to store recently requested configuration data 118, 120 on edge nodes 112 and 114 for use by applications, operating systems, or other components, such as applications 117a, 117b, 119.

[0021] In the examples described herein, the configuration data may be provided in a non-relational, text-based data format such as JavaScript Object Notation (JSON), although the application is not limited to a particular non-relational, text-based data format. The JSON format may comprise particular data types, including strings of characters, numbers, arrays, Boolean values, and the like. In examples, the use of a non-relational, text-based data format such as JSON enables the use of a hypertext transfer protocol (HTTP)-based protocol to transfer data between and within elements of the system 100, such as the configuration provisioning system 106, the intermediate server 110, and the edge nodes 112, 114.

[0022] As discussed below, the present system provides an alternative to storing configuration data in a table format with dedicated columns. Rather, a flexible, agnostic framework for storing and transferring configuration data to edge nodes is provided. The present system and method enable modeling of any configuration data that may be needed when operating a distributed system (e.g., having many different applications and devices). In addition, the present system and method provide a mechanism for specifying how metadata can be represented and used in the framework. In examples, this metadata allows relationships between configuration data elements to be defined. For example, JSON tags can be used to define selectors that allow different network elements to obtain different configuration data values. In addition to simple selectors, metadata can be used as the basis for an "SQL-like" query language that can control which components are seen by groups of servers or other computing devices within the network.

[0023] The presently disclosed system and method facilitates easy management and distribution of configuration settings based on various scope parameters. For example, it may be desirable to send an operating system kernel TCP configuration to all network devices in North America connected to a network with a particular autonomous system number (ASN), while a different configuration is sent to all machines in Europe. In another example, a particular configuration setting may be sent to all servers running a domain name server (DNS) application, regardless of location. In another example, a first configuration setting may be sent to all servers running a DNS application in an externally facing generating network, while a second configuration setting may be sent to all servers running a DNS application in an internal network. In another example, a particular server within a network may be targeted for configuration changes based specifically on a server identifier (e.g., MAC address). The present system and method facilitates management and distribution of configuration information to multiple levels of network devices, targeting different levels of the software stack, from the operating system to the kernel application layer.

[0024] In examples, configuration information may be stored in and / or derived from configuration documents in a non-relational, text-based format, such as JSON. A configuration document may represent configuration information in terms of configuration tags defined by configuration tag names and configuration setting arrays. A configuration document may also define values ​​for particular tags based on the configuration setting array, the requesting agent, and other information. A configuration document may be searchable and filterable to define a subset of configuration tags or settings to be included in downstream distribution of the configuration document.

[0025] In an example, one or more of the configuration provisioning system 106, the intermediate server 110, and the edge nodes 112, 114 may comprise part or all of the configuration system 202, as described with reference to FIG. 2. In an example, portions of the configuration system 202 may be distributed across different levels of a network hierarchy, such as the configuration provisioning system 106, the intermediate server 110, and the edge nodes 112, 114. In an example, the configuration system 202 may comprise a configuration extraction tool 204 (including an application programming interface (API) 206), a configuration definition tool 214 (including a configuration specification 217), a configuration filter and distribution system 208, and a configuration data store 210 that stores one or more configuration documents 212. Exemplary operations and functions of the components of the configuration system 202 are described below.

[0026] In examples, configuration definition tool 214 may comprise one or more systems for enabling a user to define configuration tags and store such tags in one or more configuration documents 212 in configuration data store 210. In examples, configuration definition tool 214 may store or have access to configuration specification 217. Configuration specification 217 may be similar to a JSON schema, but configuration specification 217 may allow encoding of additional metadata about configuration tags. In examples, configuration specification 217 lists tags allowed to be defined for a particular configuration document 212. In some examples, configuration definition tool 214 may also include an interface accessible by, for example, administrator system 108, to configure tags according to those allowed by configuration specification 217. In examples, the interface may comprise a graphical user interface, an application programming interface, or otherwise. In examples, configuration definition tool 214 may enforce any rules for configuration tags or configuration documents 212 required by the schema. For example, the configuration definition tool 214 may require that any tag to be stored in the configuration document 212 meet certain minimum requirements or a particular syntax before being accepted and stored.

[0027] One non-exclusive, exemplary configuration specification 217 is described below. In this exemplary configuration specification, each tag has the following properties: (a) description: a textual description of each tag; (b) value: an object that defines the value type and limits the value range; (c) settings: if a tag is found missing from configuration document 212, it is added to configuration document 212 with these default settings; (d) immutable: an optional Boolean property that, when true, makes the tag's settings read-only; in examples, this may typically be combined with the settings property; and (e) required: a list of sets of tag values—any tag with a tag value that matches one of these sets. (f) optional: a list of sets of tag values—any agent with a tag value matching one of these sets can be assigned the setting for this tag (e.g., this property can be used to filter configuration documents 212 or to specify the appearance of a provisioning graphical user interface screen); (g) scope: a scope is an object with two properties: priority and usage—a separate JSON object containing some or all of the following: priority is a list of tags that can be used to limit the scope of a setting. In an example, the order-of-appearance of tags in the priority list can be used to determine which setting applies to an agent if the agent satisfies the scope-tag for more than one setting. The usage property can be a list of strings, each representing a valid scope-tag combination. A non-exclusive example snippet of a configuration specification 217 is shown below. In this non-exclusive example, the allowed specifications for the tag "agent:ip" are defined for a configuration document called "agent_id": { "key": { "type": "int", "name": "agent_id" }, "tags": { "agent:ip": { "description": "Primary IP address of the host.", "required": [{}], "value": { "type": "ip" }, "scope": { "priority": [ "agent_id" ], "usage": [ "agent_id" ] } }, … } }

[0028] Other exemplary configuration specifications 217 are possible and contemplated.

[0029] As discussed, configuration documents 212 may be generated based on tags defined using configuration definition tool 214 (according to configuration specification 217). In other examples, configuration documents 212 may be received from other sources. In examples, configuration documents 212 comprise configuration data stored in a non-relational, text-based format, such as JSON. Non-exclusive exemplary data models for configuration documents 212 are discussed below. In examples, each configuration document 212 comprises multiple configuration tags. Each configuration tag may be defined by a configuration tag name and a configuration setting array.

[0030] In examples, configuration tag names may be expressive and include a domain and a characteristic. The domain, in examples, may comprise the most specific entity (such as an agent, network, or component name) to which all values ​​of a configuration setting apply. In examples, an agent may comprise a specific computing device or a specific Ethernet card of a device. In examples, a characteristic may comprise a description of the characteristic to which a configuration value applies, such as a role, IP address, alarm threshold, etc. Expressive configuration tag names, in examples, may (a) aid in understanding the purpose, use, and scope of the tag and its associated setting array; and (b) aid in the selection (e.g., filtering) of tags or settings relevant to a particular configuration tag consumer (such as an agent).

[0031] In an example, each configuration tag may comprise a JSON object, and each tag object may have a property called "settings" of type array ("settings array"). In an example, each member of the settings array may comprise a separate JSON object, and may include at least one configuration value and at least one configuration range. In an example, a configuration value may be a parameter value of a property (which may be of any type: string, number, Boolean, object, array, or null). A configuration range may define a set of tag-value pairs that limit the set of agents to which the setting applies.

[0032] A non-exclusive example snippet of a configuration document 212 is shown below. In this non-exclusive example, the tag definition "agent:ip" is an example of a tag that may be stored in configuration document 212: { "tags": { "agent:ip": { "settings": [ { "value": "192.0.2.1", "scope": { "agent_id": 9999991 } }, { "value": "192.0.2.2", "scope": { "agent_id": 9999992 } }, { "value": "192.0.2.3", "scope": { "agent_id": 9999993 } }, { "value": "192.0.2.4", "scope": { "agent_id": 9999994 } }, { "value": "192.0.2.5", "scope": { "agent_id": 9999995 } }, { "value": "192.0.2.6", "scope": { "agent_id": 9999996 } }, { "value": "192.0.2.7", "scope": { "agent_id": 999997 } }, { "value": "192.0.2.8", "scope": { "agent_id": 9999998 } } ] }, ... } } } }} }

[0033] In the simple example above, each setting object in the settings array for the agent:ip tag is defined to have a different value for its defined range. In this example, a particular "value" (192.0.2.3) is specifically identified for the defined range (e.g., agent_id equals a particular identifier (9999993)).

[0034] In other non-exclusive examples, the range itself may be indirectly defined by reference to one or more other configuration tag settings and / or ranges. For example, the "agent:itm_network" tag may be defined in the following settings array: "agent:itm_network": { "settings": [ { "value": "prod1", "scope": { "agent_id": 9999991 } }, { "value": "prod1", "scope": { "agent_id": 9999992 } }, { "value": "prod2", "scope": { "agent_id": 9999993 } }, { "value": "prod2", "scope": { "agent_id": 9999994 } } ] },

[0035] Continuing with the above example, the "agent:tg_color" tag may be defined in a settings array that depends on the settings array of the "agent:itm_network" tag and the value of "agent_id". "agent:tg_color": { "settings": [ { "value": "black", "scope": { "agent:itm_network": "prod1" } }, { "value": "black", "scope": { "agent_id": 9999991 } }, { "value": "black", "scope": { "agent_id": 9999993 } }, { "value": "black", "scope": { "agent_id": 9999995 } }, { "value": "white", "scope": { "agent_id": 9999997 } }, { "value": "white", "scope": { "agent_id": 9999999 } }, { "value": "white", "scope": { "agent_id": 9999911 } } ] },

[0036] In the example, some ranges for a particular tag (e.g., tagC) may be defined in terms of the values ​​of multiple other tags (e.g., tagA=1 and tagB=2, then tagC=3, etc.). Additionally, multiple tag ranges may apply to the same agent, and any conflicts may be resolved by setting a priority property for the tag, so that the tag will always resolve to a single value. For example, as discussed, each "range" may include a priority property, which is a list of configuration tags. In the example, the order of tags in the priority list will determine which value is applied to an agent if the agent satisfies a range for more than one setting in the settings array. Furthermore, not all agents will have values ​​applied to all tags. Other example configuration documents 212 are possible and contemplated.

[0037] In an example, referring again to FIG. 2 , configuration extraction tool 204 may include API 206, through which configuration tag consumers (e.g., agents) may request configuration tag-value (CTV) pairs or configuration files. For example, an agent or other configuration tag consumer (e.g., a particular server on edge node 112 or 114, a particular port or Ethernet card thereof, a particular application running thereon, etc.) may query API 206 for applicable values ​​of one or more particular configuration tags. Configuration extraction tool 204 may access applicable configuration documents 212 to determine the correct value of a particular configuration tag based on the settings array for that particular configuration tag and other information passed with the request (e.g., the agent identifier (agent_id) of the requesting agent or the agent about which the configuration tag consumer is querying). Determining the correct value of a tag may be as simple (e.g., based only on the agent_id passed in the request), such as the “agent:ip” tag discussed above. In other examples, determining the correct value may be more complex (e.g., based on the agent_id passed in the request and additional values ​​that must be derived from other tag settings). For example, with respect to the example configuration document 212 discussed above, determining the correct value for the "agent:tg_color" tag may be determined only after determining the correct value for the "agent:itm_network" tag based on the agent_id passed with the configuration file request. Determining the value of other nested, different tags may be used. Once the correct value is determined, the CTV pair may be returned to the requesting configuration tag consumer.

[0038] In an example, the agent may also send a configuration file request through API 206, which may include an agent identifier (e.g., agent_id) value and an indication of a configuration file template that includes tag names for which values ​​are required. The configuration extractor may search the associated configuration documents 212 for the tag names included in the identified configuration file template, substitute correct values ​​for the tag names in the configuration file template, and return a configuration file (e.g., a configuration file template with applicable values ​​substituted for the tag names in the template). In an example, the configuration template may be stored, for example, in configuration data store 210 and accessed by configuration extractor 204, so that a configuration file request need only include an indication of the correct template (rather than passing the complete template with the request). As used herein, providing a configuration file request or an indication (e.g., identifier) ​​of a template to a template would be considered providing an indication of the template. As discussed, determining the correct value to substitute in the configuration file may be simple (e.g., based only on the agent_id passed in the configuration file request), such as the “agent:ip” tag discussed above. In other examples, determining the correct values ​​to populate the configuration file may be more complex (e.g., based on the agent_id passed in the configuration file request and additional values ​​that must be derived from other tag settings). Other nested value determinations for different tags may be used. Once the correct values ​​are determined, the CTV pairs may be returned to the requesting configuration tag consumer in the configuration file. In this manner, a relatively complete configuration file that can be needed / used by the tag consumer may be generated by the configuration extraction tool 204 in response to a configuration file request.

[0039] In an example, the configuration filter and distribution system 208 may include utilities that can filter the configuration documents 212, or information within the configuration documents 212, to only those documents that are applicable to the configuration tag or downstream consumers of the configuration tag. For example, in the hierarchical system of FIG. 1 , the configuration provisioning system 106 may include a configuration data store 210 that includes all configuration documents 212 available to the system 100. The configuration filter of the configuration provisioning system 106 and the configuration filter operating in the distribution system 208 may filter the setting information in the configuration documents 212 before distributing the reduced configuration documents 212 to particular intermediate servers 110. In an example, this may include excluding particular configuration documents 212 from being distributed to the intermediate servers 110 and / or filtering information contained within the distributed particular configuration documents 212. For example, if the system 100 is a CDN, the intermediate server 110 may include multiple control cores that service different edge nodes (e.g., edge nodes 112, 114). The configuration filter and distribution system 208 of the configuration provisioning system 106 may filter the configuration documents 212 to include only those configuration documents 212, or tags or settings within such documents, that have a scope that applies to the agents served by a particular control core. Thus, the configuration provisioning system 106 may provide a different configuration document 212 to a first intermediate server 110 than it serves to a second intermediate server 110 based on the role of each intermediate server 110 in the system 100 and the agents served by the particular intermediate server 110. In an example, this limits the amount of configuration information that needs to be replicated and kept synchronized in the system 100. In an example, each of the intermediate servers 110 includes a configuration data store 210 for storing the configuration documents 212 distributed to that intermediate server 110.

[0040] Similarly, the configuration filter and distribution system 208 operating at the intermediate server 110 may further filter the configuration document 212 based on the needs of downstream nodes, such as the edge nodes 112 and 114. For example, the edge node 112 may include a first set of computing devices (e.g., servers) running a first set of applications 117a and 117b. The edge node 114 may include a second set of computing devices (e.g., servers) running a second set of applications 119. Thus, the intermediate server 110 may provide a different configuration document 212 to the edge node 112 than it provides to the edge node 114. In examples where the (filtered) configuration document 212 is distributed to the edge nodes 112 and 114, the edge nodes 112 and 114 may each include a configuration extractor 204 (as described above). An application or other component needing a configuration value may then query a local instantiation of the configuration extractor 204 (e.g., through the API 206). In other examples, the configuration documents 212 are not distributed to the edge nodes 212, and the edge nodes 112, 114 may query (e.g., through the API 206) the configuration extraction tool 204 running on the intermediate server 110 if the edge nodes 112, 114 do not have valid, cached configuration data (e.g., 118, 120). In examples where the configuration documents 212 are distributed to the edge nodes 112, 114, each of the edge nodes 112, 114 includes a configuration data store 210 for storing the configuration documents 212 distributed to that edge node 112, 114.

[0041] In an example, the filtering and distribution of configuration documents 212 may operate on a push or pull basis. For example, an intermediate server 110 may query the configuration filter and distribution system 208 operating in the configuration provisioning system 106. The query may include an indication of the agents served by the intermediate server 110 or particular tag for which configuration documents 212 are needed. In another example, the configuration provisioning system 106 may determine the relevant configuration documents 212 or tags for a particular intermediate server 110 and push the appropriately filtered configuration documents 212 periodically, as they are updated, or otherwise.

[0042] One non-exclusive example of filtering is shown and discussed below. In this example, the configuration filter and distribution system 208 may read the configuration document 212 from stdin, apply the filter specification (set on the command line), and write the filtered configuration object to stdout: cat CTV.json | CTV -filter CTV_filter_999997.json > CTV_999997.json.

[0043] The enumeration option can also be used to enumerate any selected settings by agent_id, and correspondingly replace all listed restrictions with a single agent_id restriction. The following CTV filter specification can be used to extract only the settings needed by "sampleapp999997." It selects all sampleapp-related component properties of agent 999997, but also includes all agent IP addresses and roles (e.g., so that sampleapp can retrieve load injection reports from all caching servers). In an example, the configuration filter and distribution system 208 can be used to filter the CTV data provided to the agent. It can also be used in a notification script to select a subset of CTV data related to a particular application, but in the example, the CTV resolution will be sufficient. A non-exclusive example follows: { "select": [ { "tag": "agent:ip" }, { "tag": "agent:role" }, { "tag": "agent:*", "agent_id": "999997" }, { "ping_target_alarm:*", "agent_id": "999997" }, { "generate_vlt:*", "agent_id": "999997" }, { "sampleapp_watch:*", "agent_id": "999997" }, { "sampleapp:*", "agent_id": "999997" }, { "m80:*", "agent_id": "999997" }, { "health:*", "agent_id": "999997" } ] }

[0044] 3 is a flowchart illustrating an example method 300 according to an aspect of the present application. In an example, the operations of method 300 may be performed by one or more of the components of configuration system 202. As discussed, the components of configuration system 202 may comprise one or more computing systems, including configuration provisioning system 106, intermediate server 110, and / or edge nodes 112, 114.

[0045] The flow begins at operation 302, where a configuration input interface is provided. In examples, the configuration definition tool 214 may comprise one or more systems for allowing a user to define configuration tags and store such tags in one or more configuration documents 212 in the configuration data store 210. In examples, the configuration definition tool 214 may store or have access to a configuration specification 217. The configuration specification 217 may be similar to a JSON schema, but the configuration specification 217 may allow for encoding additional metadata about the tags. In examples, the configuration specification 217 lists the tags allowed to be defined for a particular configuration document 212. In some examples, the configuration definition tool 214 may also include an interface accessible by, for example, the administrator system 108, to configure the tags according to those allowed by the configuration specification 217. In examples, the interface may comprise a graphical user interface, an application programming interface, or otherwise. In examples, the configuration definition tool 214 may enforce any rules for the configuration tags or configuration documents 212 required by the schema. For example, the configuration definition tool 214 may require that any tag to be stored in the configuration document 212 meet certain minimum requirements or a particular syntax before being accepted and stored.

[0046] Flow continues to operation 304 where a configuration tag is received through a configuration input interface. For example, the configuration tag may be defined using administrator system 108 and configuration definition tool 214, as described above.

[0047] Flow continues to operation 306, where at least one configuration document including a plurality of configuration tags is stored. In an example, the configuration tags are stored in configuration documents 212 in configuration data store 210. As discussed, tags defined through configuration definition tool 214 may be stored in such configuration documents 212. In other examples, configuration documents 212 may be received from one or more other components and stored at operation 306. As discussed, the configuration document comprises a non-relational, text-based data format and, for each configuration tag of the plurality of configuration tags, comprises a configuration tag name and a configuration settings array. In an example, the configuration settings array comprises at least one configuration value and at least one configuration range.

[0048] Flow continues to operation 308, where the first configuration document is sent to a first intermediate server and the second configuration document is sent to a second intermediate server. In example method 300, multiple intermediate servers (e.g., intermediate server 110) are used. In some examples, method 300 may be implemented without intermediate servers, and operation 308 may be omitted. As discussed, operation 308 may include filtering the configuration tags and / or settings included in the configuration document stored in a higher-level system (e.g., configuration provisioning system 106) to include only those tags / settings associated with the particular intermediate server 110. For example, the first configuration document sent to the first intermediate server may differ from the second configuration document sent to the second intermediate server because the configuration tags / settings stored in the configuration provisioning system 106 may first be filtered to include only those associated with the particular intermediate server 110.

[0049] Flow proceeds to operation 310, where a first subset of configuration tags is determined to be applicable to a first edge node. In examples, operation 310 may comprise determining a first set of agents operating at the first edge node and determining that the first subset of configuration tags is applicable to the first set of agents. In examples, this may include receiving a query for configuration tags from the first edge node. In examples, operation 310 may also include reading the first configuration document to determine any configuration ranges satisfied by agents of the first set of agents. In examples, the first set of agents may include a first set of computing machines at the first edge node and / or a first set of applications operating on such first set of computing machines. In examples, determining the first subset may include determining applicability of the configuration tags based on information encoded in the configuration tag names.

[0050] Flow continues to operation 312, where a second configuration tag subset is determined to be applicable to the second edge node. In the example, operation 312 is similar to operation 310, but for the second configuration tag subset applicable to the second edge node.

[0051] Flow proceeds to operation 314, where at least a first CTV pair is provided for the first configuration tag subset. In an example, operation 314 may be performed by configuration extraction tool 204. As discussed, configuration extraction tool 204 may include API 206, through which configuration tag consumers (e.g., agents) may request configuration tag-value (CTV) pairs or configuration files. For example, an agent or other configuration tag consumer (e.g., a particular server on edge node 112 or 114, a particular port or Ethernet card thereof, a particular application running thereon, etc.) may query API 206 for applicable values ​​of one or more particular configuration tags. Configuration extraction tool 204 may access the applicable configuration document 212 to determine the correct value for the configuration tag based on the setting array for the particular configuration tag and other information passed with the request (e.g., the agent identifier (agent_id) of the requesting agent or the agent about which the configuration tag consumer is querying). Once the correct value is determined, the CTV pair may be returned to the requesting configuration tag consumer. In some examples, an agent (or other configuration tag consumer) may also send a configuration file request through API 206, which may include an agent identifier (e.g., agent_id) value and an indication of a configuration file template that includes tag names for which values ​​are required. The configuration extractor may search the associated configuration documents 212 for the tag names included in the identified configuration file template, substitute correct values ​​for the tag names in the configuration file template, and return a configuration file (e.g., a configuration file template with applicable values ​​substituted for the tag names in the template). Once the correct values ​​are determined, the CTV pairs may be returned to the requesting configuration tag consumer in the configuration file. In an example, a first CTV pair may be provided to a first edge node for a first application running on a first device of the edge node, and a different CTV pair may be provided to a first edge node for a second application running on the same device.In some examples, as discussed, determining a correct value for the first configuration tag may include first determining correct values ​​for one or more other configuration tags used to define a configuration tag range for the first configuration tag. In some examples, providing the first CTV pair may include transmitting the first CTV pair from the first intermediate node to the first edge node.

[0052] Flow proceeds to operation 316, where at least a second CTV pair is provided for the second constituent tag subset. In an example, operation 316 may be similar to operation 314, but for the CTV pairs of the second constituent tag subset. In an example, one or more of the operations of method 300 may be repeated for additional constituent tags.

[0053] 4 is a block diagram illustrating the physical components (i.e., hardware) of a computing device 400 with which examples of the present disclosure may be implemented. The computing device components described below may be suitable for a computing device implementing one or more of the system 100, configuration provisioning system 106, administrator system 108, intermediate server 110, edge nodes 112, 114, configuration system 202, or other components of FIGS. 1 and 2. As shown in FIG. 4, the physical components (e.g., hardware) of a computing device are illustrated, and these physical components may be used to implement various aspects of the present disclosure. The elements described above may be implemented via one or more computing devices 400.

[0054] The computing device 400 may include at least one processing unit 410 and a system memory 420. The processing unit 410 may comprise processing circuitry. The system memory 420 may include, but is not limited to, volatile storage (e.g., random access memory), non-volatile storage (e.g., read-only memory), flash memory, or any combination of such memory. The system memory 420 may also include an operating system 430, which controls the operation of the computing device 400, and one or more program modules 440. The program modules 440 may be responsible for collecting or determining event data 450, including endpoint data and / or network data. Several different program modules and data files may be stored in the system memory 420. While executing on the processing unit 410, the program modules 440 may perform the various processes described above.

[0055] Computing device 400 may also have additional features or functionality. For example, computing device 400 may include additional data storage devices (e.g., removable and / or non-removable storage devices), such as magnetic disks, optical disks, or tape. These additional storage devices are labeled removable storage 460 and non-removable storage 470.

[0056] Examples of the present disclosure may also be implemented in electrical circuits that include discrete electronic elements, packaged or integrated electronic chips containing logic gates, circuits that utilize a microprocessor, or a single chip that includes electronic elements or a microprocessor. For example, examples of the present disclosure may be implemented via a system-on-a-chip (SOC) that may integrate each or many of the components shown in FIG. 4 into a single integrated circuit. Such an SOC device may include one or more processing units, graphics units, communications units, system virtualization units, and various application functions, all of which are integrated (or "burned") onto a chip substrate as a single integrated circuit.

[0057] When operating via a SOC, the functionality described herein may be operated via application-specific logic integrated with other components of computing device 400 in a single integrated circuit (chip). The present disclosure may also be implemented using other technologies capable of performing logical operations such as, for example, AND, OR, and NOT, including, but not limited to, mechanical, optical, fluidic, and quantum technologies.

[0058] Computing device 400 may include one or more communication systems 480 that enable computing device 400 to communicate with other computing devices 495, such as, for example, servers, routers, network devices, clients, computing devices, etc. Examples of communication systems 480 include, but are not limited to, wireless communication, wired communication, cellular communication, radio frequency (RF) transmitter, receiver, and / or transceiver circuitry, Controller Area Network (CAN) bus, universal serial bus (USB), parallel, serial ports, etc.

[0059] Computing device 400 may also have one or more input devices and / or one or more output devices, shown as input / output devices 490. These input / output devices 490 may include keyboards, sound or voice input devices, haptic devices, touch, force, and / or swipe input devices, displays, speakers, etc. The devices listed above are examples, and others may be used.

[0060] As used herein, the term "computer-readable medium" may include non-transitory computer storage media. Computer storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, or program modules.

[0061] System memory 420, removable storage 460, and non-removable storage 470 are all examples of computer storage media (e.g., memory storage). Computer storage media may include RAM, ROM, electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other article that can be used to store information and that can be accessed by computing device 400. Any such computer storage media may be part of computing device 400. Computer storage media is tangible and non-transitory and does not include a carrier wave or other propagated or modulated data signal.

[0062] Communication media may be embodied by computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media. The term "modulated data signal" may be described as a signal that has one or more characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media.

[0063] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the inventive concepts. Also, unless expressly stated otherwise, the embodiments described herein are not mutually exclusive. Aspects of the embodiments described herein may be combined in some implementations.

[0064] With respect to the process in the flow diagram of FIG. 3, it should be understood that the sequence of steps in the process is not fixed, but may be modified, reordered, performed differently, sequentially, in parallel, or simultaneously, or changed into any desired sequence, as would be recognized by one of ordinary skill in the art.

[0065] The embodiments described herein in software may be used to implement and execute the systems and methods disclosed herein using hardware or a combination of software and hardware. While specific devices are described throughout this disclosure as performing particular functions, those skilled in the art will understand that these devices are provided for illustrative purposes and that other devices may be used to perform the functions disclosed herein without departing from the scope of the present disclosure. Additionally, some aspects of the present disclosure are described above with reference to block diagrams and / or operational illustrations of systems and methods according to aspects of the present disclosure. The functions, operations, and / or acts noted in the blocks may occur in different orders than shown in any respective flowcharts. For example, two blocks shown in succession may in fact be performed or executed substantially in parallel or in the reverse order, depending on the functionality and implementation involved.

[0066] This disclosure describes several embodiments of the present technology with reference to the accompanying drawings, which show only some of the possible embodiments. However, other aspects may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of possible embodiments to those skilled in the art. Furthermore, as used in this specification and claims, the phrase "at least one of element A, element B, or element C" is intended to convey any of element A, element B, element C, elements A and B, elements A and C, elements B and C, and elements A, B, and C. Furthermore, those skilled in the art will understand the extent to which terms such as "about" or "substantially" convey information in light of the measurement techniques used herein.

[0067] Although specific embodiments are described herein, the scope of the present technology is not limited to these specific embodiments. Moreover, while different examples and embodiments may be described separately, such embodiments and examples may be combined with each other when implementing the technology described herein. Those skilled in the art will recognize other embodiments or improvements that are within the scope and spirit of the present technology. Therefore, specific structures, operations, or media are disclosed only as exemplary embodiments. The scope of the present technology is defined by the following claims and any equivalents therein.

Claims

1. 1. A system comprising: at least one processing circuit; and a memory operatively connected to the at least one processing circuit and storing instructions that, when executed by the at least one processing circuit, cause the system to perform a method, the method comprising: storing at least one configuration document comprising a plurality of configuration tags, wherein the at least one configuration document has a non-relational, text-based data format, and wherein, for each configuration tag of the plurality of configuration tags, the configuration document comprises a configuration tag name and a configuration settings array, the configuration settings array comprising at least one configuration value and at least one configuration range; determining a first subset of the configuration tags of the at least one configuration document applicable to a first edge node of the network; determining a second subset of the configuration tags of the at least one configuration document applicable to a second edge node of the network; providing at least a first configuration tag-value (CTV) pair of the first subset of the configuration tags; and providing at least a second CTV pair of the second subset of configuration tags; have A system comprising:

2. The method further comprises: providing a configuration input interface in a configuration provisioning system for a network, wherein the configuration input interface requires, for each configuration tag of the plurality of configuration tags, the configuration tag name and the configuration settings array; transmitting, by the configuration provisioning system and based on the at least one configuration document, a first configuration document to a first intermediate server and a second configuration document to a second intermediate server, wherein the first configuration document and the second configuration document are different; Equipped with 2. The system of claim 1, wherein the first intermediate server determines the first subset from the first configuration document and the second intermediate server determines the second subset from the second configuration document.

3. 3. The system of claim 2, wherein determining the first subset by the first intermediate server comprises determining a first set of agents operating at the first edge node of the network, and determining that the first subset is applicable to the first set of agents.

4. The system of claim 3 , wherein determining the first subset by the first intermediate server comprises receiving at least one query for configuration tags from the first edge node.

5. 4. The system of claim 3, wherein determining the first subset by the first intermediate server comprises searching the first configuration document for any configuration ranges satisfied by agents in the first agent set.

6. 6. The system of claim 5, wherein searching the first configuration document for any configuration ranges satisfied by agents in the first agent set includes determining that a first device set is running on the first edge node and that a first application set is running on the first device set at the first edge node.

7. 7. The system of claim 6, wherein the first agent set includes a first application running on a first device of the first edge node and a second application running on the first device of the first edge node, and wherein providing at least the first configuration tag-value (CTV) pair for the first subset of configuration tags includes providing the first CTV pair to the first application and a third CTV pair to the second application.

8. 8. The system of claim 7, wherein each of the configuration tag names of the plurality of configuration tags includes a domain and a characteristic, and the method further comprises determining that the first CTV pair is associated with the first application based on at least one of the domain or the characteristic of a first configuration tag name.

9. 2. The system of claim 1, wherein the plurality of configuration tags comprises a first configuration tag, the first configuration tag having a first setting array having a first configuration setting and a second configuration setting, the first configuration setting including a first configuration value and a first configuration range, and the second configuration setting including a second configuration value and a second configuration range.

10. the plurality of configuration tags comprises a first configuration tag and a second configuration tag; the first configuration tag has a first configuration tag name, a first configuration tag value, and a first configuration tag range; The second configuration tag has a second configuration tag name, a second configuration tag value, and a second configuration tag range defined based on the first configuration tag. The system of claim 1 .

11. The step of providing the first CTV pair includes: receiving a configuration file request, wherein the configuration file request comprises an indication of a configuration file template and at least one text string having a first configuration tag name; searching the at least one configuration document for the first configuration tag name; replacing the at least one text string in the configuration file template with the at least one configuration value of the first configuration tag name to generate a configuration file; and Returning the configuration file The system of claim 1 , comprising:

12. The system of claim 2 , wherein providing the first CTV pair comprises transmitting the first CTV pair from the first intermediate node to the first edge node.

13. storing at least one configuration document comprising a plurality of configuration tags, wherein the at least one configuration document has a non-relational, text-based data format, and wherein, for each configuration tag of the plurality of configuration tags, the configuration document comprises a configuration tag name and a configuration settings array, the configuration settings array comprising at least one configuration value and at least one configuration range; determining a first subset of the configuration tags of the at least one configuration document applicable to a first edge node of the network; determining a second subset of the configuration tags of the at least one configuration document applicable to a second edge node of the network; providing at least a first configuration tag-value (CTV) pair of the first subset of the configuration tags; and providing at least a second CTV pair of the second subset of configuration tags; A method comprising:

14. providing a configuration input interface in a configuration provisioning system for a network, wherein the configuration input interface requires, for each configuration tag of the plurality of configuration tags, the configuration tag name and the configuration settings array; transmitting, by the configuration provisioning system and based on the at least one configuration document, a first configuration document to a first intermediate server and a second configuration document to a second intermediate server, wherein the first configuration document and the second configuration document are different; Furthermore, 14. The method of claim 13, wherein the first intermediate server determines the first subset from the first configuration document and the second intermediate server determines the second subset from the second configuration document.

15. 15. The method of claim 14, wherein determining the first subset by the first intermediate server comprises determining a first set of agents operating at the first edge node of the network, and determining that the first subset is applicable to the first set of agents.

16. 16. The system of claim 15, wherein determining the first subset by the first intermediate server comprises searching the first configuration document for any configuration ranges satisfied by agents in the first agent set.

17. 17. The method of claim 16, wherein searching the first configuration document for any configuration ranges satisfied by agents in the first agent set comprises determining that a first device set is running on the first edge node and that a first application set is running on the first device set at the first edge node.

18. The step of providing the first CTV pair includes: receiving a configuration file request, wherein the configuration file request comprises an indication of a configuration file template and at least one text string having a first configuration tag name; searching the at least one configuration document for the first configuration tag name; replacing the at least one text string in the configuration file template with the at least one configuration value of the first configuration tag name to generate a configuration file; and Returning the configuration file 14. The method of claim 13, comprising:

19. The method of claim 14 , wherein providing the first CTV pair comprises transmitting the first CTV pair from the first intermediate node to the first edge node.

20. providing a configuration input interface in a configuration provisioning system for a network, wherein the configuration input interface requires a configuration tag name and a configuration setting array for each configuration tag of a plurality of configuration tags; storing at least one configuration document comprising the plurality of configuration tags, wherein the at least one configuration document has a non-relational, text-based data format and, for each configuration tag of the plurality of configuration tags, comprises the configuration tag name and the configuration settings array, the configuration settings array comprising at least one configuration value and at least one configuration range; transmitting, by the configuration provisioning system and based on the at least one configuration document, a first configuration document to a first intermediate server and a second configuration document to a second intermediate server, wherein the first configuration document and the second configuration document are different; determining a first subset of the configuration tags of the at least one configuration document applicable to a first edge node of the network, wherein the first intermediate server determines the first subset from the first configuration document; determining a second subset of the configuration tags of the at least one configuration document applicable to a second edge node of the network, wherein the second intermediate server determines the second subset from the second configuration document; providing at least a first configuration tag-value (CTV) pair for the first subset of the configuration tags; and providing at least a second CTV pair for the second subset of the configuration tags; A method comprising:

Images