Near real-time messaging service for data center infrastructure monitoring data

In some examples, a method includes receiving, by a data center infrastructure monitoring system, a registration request that indicates a method of a subscription application programming interface and specifies one or more event subjects of events describing a system operation of a data center; storing, by the data center infrastructure monitoring system to a data-topic map, respective mappings for the one or more event subjects to a topic of a cloud-based publication platform; monitoring, by a data center infrastructure monitoring system, a plurality of physical infrastructure assets that enable system operation within the data center to obtain an event that describes one of the event subjects; and publishing, by the data center infrastructure monitoring system, the event to the topic.

TECHNICAL FIELD

The disclosure relates to data centers and, more specifically, to monitoring data center infrastructure.

BACKGROUND

A network services exchange provider or co-location provider (a “provider”) may deploy a data center in which multiple customers of the provider locate network, server, and storage gear and interconnect to a variety of telecommunications and other network service provider(s) with a minimum of cost and complexity. Data centers may be shared by multiple tenants locating networking, computing, and storage equipment within the data centers.

A data center may include a storage volume storing numerous electronic devices that produce heat, including network, server, and storage gear, as well as power distribution units for distributing power to devices within the facility, for example. The data center may also include cooling units to supply a cool air stream into the storage volume.

SUMMARY

In general, techniques are described for a near real-time messaging service that provides access to data center event data, including machine data feeds, via dynamically configurable subscription topics. For example, a network services exchange provider or co-location provider (“provider”) may deploy a data center and a data center monitoring system that produces event data, including machine data, associated with data center infrastructure assets. The event data may include, for example, alarm data; alert data; tagpoints describing properties of infrastructure assets such as HVAC (heating ventilation and air conditioning) units, computer room air conditioning units, power supplies, generators, power distribution units, and switchgears; power consumption data points; and environmental sensor data points.

A computing system executes a messaging service that applies real-time processing to the events and publishes the processed events to custom topics of a publication platform to enable application programming interface (API) consumers to receive event data in near real-time. For example, API consumers may register for custom topics using an API that receives registration requests for access to events. The messaging service processes each registration request to authorize the requesting consumer, creates a custom topic for the requesting customer, and returns a description of custom topic to the customer for accessing the event data. In addition, the messaging service generates or modifies, in a data structure, respective entries for requested events that map the subjects of events to the relevant topics used for publishing the event data. To make the event data accessible, the messaging service uses the entries of the data structure to map new data from the events to the one or more relevant topics and publish the new event data to the identified, relevant topics. In this way, the data center infrastructure monitoring and messaging service described herein may enable customers, developers, Internet of Things (IoT) or other devices, and management systems to consume, in near real-time, event data including machine data feeds generated by one or more data center monitoring systems for globally distributed data centers having a large scale of infrastructure components that may be located in multiple regions and metropolitan areas. Such techniques may enable integration with customer dashboards and provide near real-time actionable information to API consumer and data center operators.

In some examples, a method includes receiving, by a data center infrastructure monitoring system, a registration request that indicates a method of a subscription application programming interface and specifies one or more event subjects of events describing a system operation of a data center; storing, by the data center infrastructure monitoring system to a data-topic map, respective mappings for the one or more event subjects to a topic of a cloud-based publication platform; monitoring, by a data center infrastructure monitoring system, a plurality of physical infrastructure assets that enable system operation within the data center to obtain an event that describes one of the event subjects; and publishing, by the data center infrastructure monitoring system, the event to the topic.

In some examples, a computer-readable storage medium comprising instructions that when executed cause one or more processors of a data center infrastructure monitoring system to receive a registration request that indicates a method of a subscription application programming interface and specifies one or more event subjects of events describing a system operation of a data center; store, to a data-topic map, respective mappings for the one or more event subjects to a topic of a cloud-based publication platform; monitor a plurality of physical infrastructure assets that enable system operation within the data center to obtain an event that describes one of the event subjects; and publish the event to the topic.

In some examples, a computing system includes one or more processors and memory, the one or more processors and memory configured for: receiving a registration request that indicates a method of a subscription application programming interface and specifies one or more event subjects of events describing a system operation of a data center; storing, to a data-topic map, respective mappings for the one or more event subjects to a topic of a cloud-based publication platform; monitoring a plurality of physical infrastructure assets that enable system operation within the data center to obtain an event that describes one of the event subjects; and publishing the event to the topic.

The details of one or more examples of the techniques are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the techniques will be apparent from the description and drawings, and from the claims.

Like reference characters denote like elements throughout the figures and text.

DETAILED DESCRIPTION

FIG. 1is a block diagram illustrating an example system10for a data center infrastructure monitoring system, in accordance with techniques described herein. In the example ofFIG. 1, system10includes multiple data centers12(also referred to herein as “co-location facilities” or “international business exchanges (IBX1-IBX-N)”), with each of the data centers12being located at one or more geographically distributed locations. For example, the data center infrastructure monitoring system10may include multiple data centers12located within a single region (e.g., country, continent) of regions A-N, or may include multiple data centers12located within multiple regions A-N.

Each of the multiple data centers12located within a given region A-N include multiple physical infrastructure assets14that enable operation of a physical building and IT systems located within the data center12. For example, the assets14may include physical structure related to power systems and cooling systems associated with controlling the environment within the data center12, such as temperature sensors, HVAC (heating ventilation and air conditioning) units, CRAC (computer room air conditioning) units, uninterruptible power supplies (UPSs), generators, PDUs (power distribution units), AHUs (air handling units), switchgears, chillers and power units, for example. In some examples, assets14may include devices related to security, lighting, electrical, structural integrity, occupancy, or energy credits, for example. Each of the assets14are communicatively coupled to a corresponding one of data center infrastructure monitoring (DCIM) edge systems16A-16N (“DCIM edge systems16”) via a connection18. For example, each of the data centers12may communicate data associated with the assets14with the corresponding DCIM edge system16via one or more of a metro Ethernet network, the Internet, a mobile backhaul network, or a Multiprotocol Label Switching (MPLS) access network (not shown).

As shown inFIG. 1, respective DCIM edge systems16are located on different geographically distributed regions A-N. In some examples, a given region may have multiple DCIM edge systems16for multiple data centers12on the region, such as in different metropolitan areas, or multiple data centers in a metropolitan area. DCIM edge systems16may each be located within geographically distributed colocation facility provider facilities (not shown and hereinafter, “colocation facilities”), e.g., colocation data centers, each associated with (e.g., owned and/or operated by) a single colocation facility provider. The colocation service provider is a single entity, business, operator, service provider, or the like. In some examples, the colocation service provider operates an internet exchange, Ethernet exchange, and/or a cloud exchange, such as described in U.S. application Ser. No. 15/099,407, entitled CLOUD-BASED SERVICES EXCHANGE, filed Apr. 14, 2016, the entire contents of which are incorporated by reference herein.

The distributed colocation facilities in which the DCIM edge systems16are located may be connected by Wide Area Network (WAN). In this way, each of the DCIM edge systems16are connected to a data platform20within an operations/monitoring center22located within one of regions A-N, including being located within one of regions A-N having one or more data centers12co-located therein. Data associated with assets14from multiple data centers12is therefore received by the operation/monitoring center of a central DCIM system22, and the data is then stored in a central platform for subsequent analysis and distribution by an operations monitoring infrastructure24. In some examples, the data may be offered as part of a product offering 26, and/or utilized by one or more of the data centers12to monitor and control infrastructure and optimize ongoing operation of the one or more data centers12, as described below in detail.

In some examples, DCIM edge systems16and DCIM system22may include components that function well offline without using a network to back them up, such as by using local storage for buffering messages that need to go across the network. In some examples, DCIM edge systems16and DCIM system22may employ a data platform to support real time data streaming, data-in-transit to data-at-rest, which is reliable and robust to prevent data loss. In some examples, DCIM edge systems16and DCIM system22may include granular independent components designed to do one thing well.

DCIM system22may use a set of collaborating services (e.g., micro-services) organized around business capabilities. In some examples, DCIM edge systems16use infrastructure modeling (e.g., JSON-based) to standardize across machines and devices. DCIM edge systems16and DCIM system22may distribute and parallelize the processing of data from assets14across machines over the network.

Security features may be built in to system10. For example, in some examples DCIM edge systems16and DCIM system22may include end-to-end trust points and countermeasures for each component in the ecosystem of system10. In some examples, system10defines API contracts first using Domain Driven Design and exposes everything as a respective service. In some examples, DCIM edge systems16and DCIM system22may rely on container-based cloud native application development. In some examples, DCIM edge systems16and DCIM system22may use lightweight and platform-agnostic communication between the components and with each other using smart end points and light weight protocols. System10provides automation and continuous delivery and deployment to enable developers for seamless deployment and maintenance of assets14in system10. Additional example description of a DCIM system is found in U.S. patent application Ser. No. 15/404,015, filed Nov. 11, 2017, and entitled, “Architecture for Data Center Infrastructure Monitoring,” the entire contents of which is incorporated by reference herein.

FIG. 2is a block diagram illustrating example reference architecture for a data center infrastructure monitoring system23, in accordance with techniques described herein. The DCIM system23ofFIG. 2may correspond to DCIM system22and DCIM edge systems16ofFIG. 1, for example. In the example ofFIG. 2, the assets14included in the data centers12may include such data center infrastructure assets as temperature centers, power units, chillers, power usage and power switching, for example. The global DCIM system10includes a DCIM system22that gathers information related to the layer of assets14from multiple data centers12, and stores the information within a data repository30. The global information in data repository30is used to gather and create analytics for customers, business development and operations, using real time end to end data collection, operational analytics, predictive analytics, data processing and services. In some examples, data monetization and what-if analysis utilizing data science algorithms may be performed using the global information. An enterprise system32is included to enable data centers12to notify DCIM system22when specific assets are non-operational, i.e., “offline”, or experiencing operational disturbances. Enterprise system32may store data relating to one or more of customer master assets, trouble tickets, and infrastructure, for example.

A data center gateway34integrates with customer portal35and customer application programming interfaces (APIs)31to enable role based access control for users of cross-functional nature, such as operations, sales and customer roles, along with access governance and perimeter access controls for each system. Data center gateway34may provide resource APIs, composite APIs, and/or coarse grain data access, for example. The global information is used by the DCIM operations monitoring infrastructure24to develop certain features and mobile applications used by operation engineers and sales and marketing, including micro-services architecture driven feature based development of applications. The DCIM system22may provide authorization, access controls, audit trails, notification services, system health checks and integration.

In this way, information15, such as notifications, alerts, and history associated with particular asset events, along with general asset data is received from multiple data centers12(IBX1-IBXX) and is collected within data repository30. Data repository30processes the data in real-time, near real time and/or in batches. The resulting processed multi-data center asset data is received by DCIM operations monitoring infrastructure24, which transfers specific features25associated with the assets for internal operations27(e.g., internal to the co-location facility provider that operates data centers12), including sales and marketing personnel and operations engineers, for example. In some examples, DCIM operations monitoring infrastructure24presents the data via mobile applications. In addition, the resulting asset data is received by customer developers29via customer APIs31, and/or by specific customers33via customer portals35or mobile applications37. The resulting data (e.g., coarse grain data) may also be accessed by data scientists and operations engineers39via an analytics workbench41.

FIG. 3is block diagram illustrating an example data center infrastructure monitoring system400architecture, in accordance with techniques described herein. The DCIM system400ofFIG. 3may correspond to DCIM system22and DCIM edge systems16ofFIG. 1, and DCIM system23ofFIG. 2, for example. In some examples, DCIM edge systems16receive data generated by assets14via one or more meters, control systems, and/or BMSs. In some examples, assets14may be “smart” devices, i.e., physical objects that contain embedded technology configured to provide some degree of computing intelligence. These smart devices may communicate and sense or interact with their internal states or the external environment.

In the example ofFIG. 3, the DCIM edge systems16may include a DCIM collector38for collecting asset tag points and data interfacing, along with branch circuit monitoring (BCM) and power usage effectiveness (PUE) monitoring. In some examples, DCIM collectors38may each include interfaces for various protocols by which DCIM collectors38receive data from BMS, control systems, and meters, such as Open Platform Communications Data Access (OPC DA), Building Automation and Control Networks (BACNet), Modbus, Modbus over Ethernet (Modbus/E), eXtensible Markup Language (XML)/Simple Object Access Protocol (SOAP), and Simple Network Management Protocol (SNMP), for example.

Data platform20includes an infrastructure object mart40that is a data store for storing asset models and infra objects, described below, that receives asset data from multiple data centers12via associated DCIM edge systems16and drives processing of how data comes into the DCIM system22, how the data is processed once within the DCIM system22, and how the data is presented by the DCIM system22via a user interface or visualization tools. In this way, the DCIM system22performs common infra asset modeling for various assets14in the data centers12, including alerts and notification configuration for tag points. DCIM system22includes data lifecycle management for real time online data storage, a data historian storing data history, real time alerts and notifications, and integration with a source system of record of the co-location facility provider that operates data centers12. Data platform also includes a historian43for storing raw data, and a real time online data store45for storing real time data and asset rules. An enterprise IT system48interacts with the data platform20and may be utilized to make the data meaningful.

DCIM system22includes DCIM tools47, such as a global data center (IBX) monitoring system (GIMS)42for data center health monitoring, reporting and dashboards, and infrastructure asset usage analysis, and a visualization analytical tool49for presenting and reviewing asset data information. In addition, DCIM tools47may include an infrastructure asset configurator44(“infra asset configurator”) that transfers information to and receives data information from infrastructure object mart40and performs common infrastructure asset modeling for various devices in the data centers12, along with alerts and notification configurations for tag points. Asset data is transmitted from data platform20to DCIM tools47via data center gateway34. Product applications46in DCIM system22include application programming interfaces such as customer APIs51and customer portals53, along with product analytics55for cross selling and upselling of data, which receive data from the data platform20via data center gateway34.

FIG. 4is a block diagram illustrating an example logical architecture61of a data center infrastructure monitoring system, in accordance with techniques described herein. DCIM logical architecture61ofFIG. 4may correspond to DCIM system22and DCIM edge systems16ofFIG. 1, for example. The DCIM logical architecture61may offer such functionality as event producing, collection, transformation, long-term storage, presentation, and action. In the example ofFIG. 4, the DCIM logical architecture61includes an infra asset configurator44used by a DCIM edge system16A to classify and manage a plurality of assets14for which DCIM edge16receives information. The DCIM logical architecture also includes a data platform59and an API platform63for providing data to customer applications65and internal applications67.

In the example ofFIG. 4, infra asset configurator44includes a template engine50for applying a template to data received from data centers12, as described below, a rules engine52associated with the format of the templates, along with core services68, described below inFIG. 6. Each DCIM edge system16includes an asset manager synchronizer54, an edge publisher56, a protocol manager58and an asset parser60, for receiving asset data associated with assets14of the data center12via a control system71and a building management system (BMS)73. Information related to data assets14is transferred to an associated DCIM edge16via control system71and BMS73. A data broker75of data platform59receives the data assets via publisher56of DCIM edge16and processes the data using one or more of speed layer processing77and batch layer processing79techniques (described in further detail with respect toFIG. 8). API platform63(described in further detail with respect toFIGS. 10 and 11) includes an orchestrator81and underlying data service (micro-services)83for providing API endpoints for transmitting the asset data to customer applications65, such as customer APIs85, customer portals87and product analytics89, and internal tools67, such as global IBX monitoring system91and operational analytics93.

FIG. 5is a block diagram illustrating an example normalization process of an infrastructure asset configurator (e.g., infra asset configurator44ofFIGS. 4 and 6) in a data center infrastructure monitoring system, in accordance with techniques described herein. A single data center12may typically include many assets14(e.g., approximately three hundred assets). Due to the large number of assets14that may be associated with each data center12, challenges may arise in being able to compare and contrast data associated with the multitude of assets14across data centers12. For example, in order to benefit from operational efficiencies, best practices are compared across the assets. The best practices could include, for example, practices related to how the asset was set up, how the asset is being configured, how the asset is being used, what hash points and readings are set up, and other any other relevant measurements and/or units associated with the asset. In accordance with the techniques of this disclosure, the DCIM includes an infrastructure asset configurator44that provides an asset normalization process, asset modeling options, and a roll-out approach for asset definition, normalization, and standardization. Infrastructure asset configurator44follows a normalization process that may include infrastructure asset configurator44defining templates, infrastructure asset configurator44defining infra assets (i.e., infrastructure asset data that logically represents physical infrastructure assets), and infrastructure asset configurator44associating the infra asset within an infra asset hierarchy.

Infrastructure asset configurator44initially sets up an asset model that includes an asset definition of each asset type so that assets can be categorized by being associated to a template. For example, if an asset is a generator, the asset is associated with a generator template. In this way levels of abstraction are provided for asset readings. For example, if there is a power distribution unit from which an output distribution reading may be generated and read, such as output voltage, it would be necessary that the reading generated from one data center at one location be identified in the same way as the output distribution from another data center at a different location, so that if the two are to be compared, they have the same tag name configuration to identify them. In other words, the infrastructure asset configurator provides a normalization process that includes asset configurations for defining asset models, for defining how to populate the asset models and what metadata is required to be able to normalize all of the infrastructure assets and asset points. Asset points are readings that the asset14is set up to record. For example, zone-temperature may be an asset point if a temperature sensor is available for an asset14. In some cases, on average, there may be approximately 100 tag points per asset14. Tag points are associated with units of measure since the quantity that the tag points are reading is intended to be associated with a unit of measure. The DCIM system may include a recording unit of measure, or quantity, to determine data compression rules.

In one example, the DCIM system22obtains the data for populating the templates from operation administrators associated with each data center who input data onto a spreadsheet for which protocol detail for each of the assets is part of the spreadsheet, and is then kept as a control list and is loaded into the data platform20. The template definition includes the asset type information, and also includes all of the readings or points, and all alarms that have been associated with those points. Infrastructure asset configurator44may push the templates to other data centers to complete tags/asset type information using common protocols including the same tag names to enable cross comparison. In this way, infrastructure asset configurator44brings all assets to a common level of description for comparison using common protocols. The association is not a single data point association, but rather, infrastructure asset configurator44may map multiple points to points indicated in the template. Points that are unique only to a specific asset, such as to a single specific generator for example, may not be mapped by infrastructure asset configurator44, so that only common points across all of the data centers are included in the template. In this way, when a new asset is generated in the DCIM system, the asset configurator44may automatically detect what template should be applied for the new asset based on the tag points included with the new asset, and on the mapping between tag points and the template. Assets may have as many as 60 points, and at a high level examples of the asset classifications may be electrical, mechanical, fire and smoke, along with other such infrastructure classifications, for example.

In this way, in the example ofFIG. 5, during the normalization process, the infrastructure asset configurator44defines templates for all infrastructure assets during template definition to create standard asset templates, standard points, and standard alarms, along with standard asset attribute types. In some examples, the standards templates may be defined by the co-location facility provider operating data centers12. During infrastructure asset definition, the infrastructure asset configurator44creates a DCIM infrastructure asset from the template, adds or removes tag points from an asset, adds or removes alarms for tag points, and adds details of protocols associated with assets. In some examples, an asset model includes pre-defined alarm definitions, e.g., based on the type of asset. During infrastructure asset hierarchy, the infrastructure asset configurator44associates connected infrastructure assets, models electrical and mechanical hierarchy, models resiliency hierarchy, and associates location based hierarchy. As a result of the described normalization process, the DCIM system provides a platform to compare and contrast data associated with assets. By providing the template with a defined set of asset tag points, the DCIM system is able to map tag points at an asset level to tag points of a template. For example, for an asset such as a generator, it may be the case that there are one or more generators from one location that have 15 tag points, for example, and one or more generators at another location that have 10 tag points. The DCIM system identifies a common set of tag points that, although the tag points may have been named differently at the two locations, the tag points are meant to have the same purpose, and maps the identified common tag points back to a standard nomenclature defined within the template itself. The resulting mapping may then be then stored.

Infrastructure asset configurator44may be employed to provide consistent infrastructure asset views across data centers, asset hierarchy navigation across tools, fault information dashboard (e.g., showing resiliency state), the ability to associate assets using a location-based hierarchy, system alarm dashboards, and infra asset master for data collection, and infra asset models used for all DCIM applications tools, customer applications, and APIs. One or more formats may be used for data modelling by infrastructure asset configurator44, such as YANG (Yet Another Next Generation), YAML (Yet Another Markup Language), and JSON (JavaScript Object Notation).

FIG. 6is a block diagram illustrating in further detail an example infrastructure asset configurator44in a data center infrastructure monitoring system, in accordance with techniques described herein. In the example ofFIG. 6, during processing of the asset model, the process begins with data associated with infra asset template details101coming in from data sheets and spreadsheets as extracted files60that are received and loaded as spreadsheets by a data loader62. For example, an infrastructure asset instance points template may be formatted as a spreadsheet that includes fields for general attributes, such as an asset instance name, operation, template matched point, display point name, short point name/reference name, point data collection type, data type, recording unit of measurement, decimal places, default state table, whether a data point is customer visible, etc., along with trending information such as COV (%), collection interval (in minutes), and so forth. An infrastructure assets instances spreadsheet may include fields such as operation, infrastructure asset template, asset instance name, customer visible point, location vector (value of the location vector selected in infra. asset template for this instance of the asset), asset ID, asset number, asset site ID, serial number, description, vendor, manufacturer, common attributes, base data collection information such as protocol and scan frequency (in seconds), and so forth.

A template engine64includes a building step where, based on the data from the template, the asset model is reconstructed and processed, and some configurations are defined as part of the template as a result of the newly received data. For example, if an oil level is less than a certain threshold, an alarm is generated. Template engine64also allows templates to be extended. Business rules engine66includes a notification manager for notifying the data centers of changes in configurations that are part of the templates, updates alert configurations, and may include validation rules associated with the template for the asset model using business rules and checks. The business rules engine66may allow the data to persist or may send the data back for correction when errors are identified. In some examples, data can be persisted using a database such as a NOSQL database.

In some examples, business rules engine66or other component of infra asset configurator44may be configured to automatically identify which particular infrastructure assert the infra asset configurator44has to go into to detect if a configuration information delta has occurred, or upon identifying a delta determine at which infrastructure asset the delta is and where that infrastructure asset is geographically located.

The infrastructure asset configurator44also includes core services68, such as visualization tools, visualization/views including user interface screens to visually show what information has been provided, along with performing audits to record modifications that occurred and identify who performed the modifications. The infrastructure asset configurator44also includes access control70for determining who has access to what assets, i.e., external facing customers or internal operations facing guests. For external facing customers, it may be not desirable to allow exposure of all assets or reading to all customers. Rather, exposed data is confined to only those assets that the customer is associated with, and which data center and which cage the specific customer belongs to, so as not to mix information shared by multiple customers. As a result, the access controls are applied on top of the assets indicating who has what access.

In addition, since access is typically upstream, in some examples the DCIM system22does not control turning on/off of infrastructure, but rather the assets respond to proprietary controls at the data center by local operations teams. In other examples, the DCIM system22may be used by customers or data center operations teams to control or manage infrastructure assets. As one example, customers may use DCIM system22to provision infrastructure assets in a self-serviceable manner. As another example, a customer may have smart locks in the customer's cabinets or cages in the data center, and the customer may use the DCIM system22to lock or unlock the smart locks. Operations users may interface with asset and tag management module103, which may support such functionality as infra assets template management, infra assets elements asset, tag asset rules management, and tag notifications rule management. Asset and tag management module103enables the data asset information within each data center12to be transmitted from template engine64, business rules engine66, and core services68to operational users for creation, review and processing. Asset and tag management module103may have single sign on (SSO) integration, such as with a federation server that provides identity management and single sign-on via a web interface.

In addition, an infra object master105stores data such as templates, elements, alert configuration, notification configuration107, and may receive data center hierarchy information from an enterprise systems gateway109. Infra object master105receives data from the layer of infra asset configurator that supports model service, access control, and infra object configuration.

The infrastructure asset configurator44uses templates for multiple infrastructure assets, such as generators, chillers, HVAC, etc., that are used to generate an infra asset master for DCIM and sources data from various source system records (namely IBX Master). In addition, a user interface is included in infrastructure asset configurator44that is used by global operations engineering to manage asset normalization. The infrastructure asset configurator44includes single sign on and uses APIs for create, read, update and delete (CRUD) operations on asset master data.

In some examples, infra asset configurator44may rely on manual uploads of asset information, and not user interface-based configuration. Asset normalization is performed for manually uploaded asset information using a data attributes (points) library and an infrastructure object template library, for example, while data center (IBX) onboarding includes template instantiation, infra object hierarchy management, scan frequency set-up and data collection enablement.

In some examples, infra asset configurator44may be automated using a user interface enabling a core services and business rule engine to be built, along with generation of standard device name, standard point name, device definition, device hierarchy management and device templatization.

In some examples, an infra asset configurator44may be rolled out in a phased manner, using manual uploads in a first phase and automated UI-based in a second phase.

FIGS. 7A-7Care block diagrams illustrating various example infra assets access patterns by a DCIM edge system16A. In the example ofFIG. 7A, DCIM edge system16A may access only control systems CS1-CS4in a data center (IBX). This may be the case when a building management system (BMS) does not exists or is not connected, or does not have high level interfaces. In the example ofFIG. 7A, DCIM edge system16A interfaces directly with control systems or smart meters using respective protocols such as Open Platform Communications Data Access (OPC DA), Building Automation and Control Networks (BACNet), Modbus, Modbus over Ethernet (Modbus/E), eXtensible Markup Language (XML)/Simple Object Access Protocol (SOAP), and Simple Network Management Protocol (SNMP), for example, which may be known protocols (although this may vary based on some proprietary control systems). In this example, data collection from the control systems may be either Change of Value (COV)/subscription based (data is collected only when there is a change in value) or polling-based.

In the example ofFIG. 7B, DCIM edge system16A may follow a hybrid access model, accessing some control systems directly and accessing some control systems via a BMS73. This may be the case when a BMS exists and can act as mediator, but not all control systems are connected with BMS73. In this example, data collection from BMS73may be polling based, and data collection from Control Systems is either COV/subscription based or polling based, depending on the protocol. In some examples, BMS73can potentially put additional constraints, if BMS capabilities are subpar relative to those of the control systems.

In the example ofFIG. 7C, DCIM edge system16A may access control systems only via the BMS73in a data center (IBX). This may be the case when a BMS73exists and can act as a mediator between DCIM edge system16A and all of the control systems. This approach may leverage a BMS's existing integration with Control systems. In some examples, BMS73can potentially put additional constraints, if BMS73capabilities are subpar relative to those of the control systems. In this example, data collection from BMS73may be polling based.

FIG. 8is a block diagram illustrating an example edge system in a data center infrastructure monitoring system, in accordance with techniques described herein.FIG. 8illustrates a DCIM edge system, such as DCIM edge system16A ofFIG. 4, in further detail. In the example ofFIG. 8, the assets and asset models defined and uploaded within the infrastructure asset configurator44, as described above, are received by an edge manager72of DCIM edge system16A via infra asset manager synchronizer54. A protocol manager74within the edge manager72receives the defined asset models for particular instances, and selects a protocol for that defined asset model. In the example ofFIG. 7, edge manager72also includes a worker manager75, a resource scheduler76and an asset parser78.

In some examples, protocol manager74may automatically discover devices and instruments that come into the network. Executors84are software components that query the BMS or components to get the data from them. Edge manager72may be configured to automatically detect those systems that come into the system in the IBX, and automatically select the right protocol to communicate with those systems, and automatically start collecting data from them. Edge manager72does this all without requiring manual configuration of the systems at the DCIM edge system16(e.g., without requiring manual entry of the IP addresses and/or protocols to use for communicating with the sensors, BMS or control systems in the IBXs). In some examples, the customers may want to install devices themselves, and the customer could submit a list of trusted devices to DCIM edge16A, and then the DCIM edge system could automatically discover the trusted devices.

Infra asset configurator44is where all the asset models are defined, such as by using asset templates, for example. As one example, a template may specify how to connect to an asset such as a generator (what protocol does the generator use to communicate), what are the data points available from the generator. This information is all in the asset model defined by the infra asset configurator44. IBX operations team may upload info into infra asset configurator44, for example.

Infra asset configurator44may create the asset model payload and stream the asset model payload to DCIM edge16A, at local IBX environment. Protocol manager74receives the asset model for that particular asset, and then parses the asset model to identify the protocol to use for communicating with particular assets in the IBX.

Resource scheduler76determines how many executors are needed to process the data from the devices, such as based on the number of devices. Executors84are distributed processing software components. In some examples, in a central cloud compute infrastructure, the executors84may be endpoints driven by microservices. Edge manager72dynamically spins up more executors, and resource scheduler76schedules more executors based on need.

Protocol manager74manages a plurality of different executors84and threads (T1, T2)82, with two threads per executor84in the example ofFIG. 8. Protocol manager74sends a particular part of the payload to an executor84. Executor84looks at the many different tag points and applies some grouping logic to group the tag points. The grouping is based on one or more parameters, such as poll frequency and bucket size, for example. For example, executor84may group the tag points that should be polled at the same time. Threads T1and T282for an executor will then poll the tag points at the IBX12and pull the data for the group of tags at the appropriate poll frequency. A given thread82is associated with a given group of tags, as grouped by executor84. Some protocols send data based on events, and edge manager72subscribes to the protocol to receive event-driven data updates.

Worker manager75is a lifecycle manager. Worker manager75manages the lifecycle of the executors84. If an executor84crashes, worker manager75brings the executor84back to a safe state. Resource scheduler76interacts with worker manager75.

Executors84then store the data to database(s)90, e.g., via a data hub such as sentinel88. Stored data may include an asset ID, a data value, and a timestamp indicating a time the data was obtained, as an example. From there, database90publishes the data to edge publisher92which in turn sends the data to a data broker94of central hub80.

FIG. 9is a block diagram illustrating an example data center gateway data platform technical architecture110in a data center infrastructure monitoring system, in accordance with techniques described herein. In the example ofFIG. 9, an architecture of data platform59includes a data collection layer112, a distribution layer114, a speed layer116, and a batch layer118located within data platform59, and a service layer120. Data is transmitted from multiple DCIM edge systems16A-16N associated with multiple data centers12of data collection layer112, and received by associated brokers122of data transport broker86within distribution layer114.

Batch layer118includes a big data pipeline, such as Camus, which runs as a job and consumes data from data transport broker86into a distributed file system, for example. Batch layer118may include batch jobs, micro-batch jobs, analytics jobs, raw data, roll-ups, data models, maintenance, and event frames, for example. These may receive data from infra asset master and reference master, and feed into notification engine131and big data mart(s). Data from the big data mart(s) of batch layer118may then go to data mart132and analytical workbench124, for example.

Speed layer116may aggregate, associate, and persist DCIM asset events received from data transport broker86. Speed layer116may parse DCIM asset events, correlate and/or aggregate events, and identify events that warrant alerts. For example, speed layer116may include a rules engine133that applies alert rules and notifies notification engine131when alert-worthy events are detected based on the alert rules. In some examples, rules engine133applies business rules for real-time processing of asset events. For example, a rule may specify that whenever a particular tag point goes beyond a configured threshold, raise an alarm (e.g., a temperature goes above a threshold temperature). A raised alarm may be one example of an asset event. The alert rules may be created in response to receiving the user inputs configuring alerts, and, for example, may be conditional alerts, as described later

In some examples, speed layer116may store a customer-to-device association, and may also have access to a maintenance schedule for a customer. In this example, speed layer116may determine that a device is not sending data, associate the device with the customer, and determine that the maintenance schedule for the customer indicates that the device is planned to be down for maintenance. In this case, speed layer116will not identify the device not sending data as an event warranting an alarm.

Speed layer116may also store or access information defining a hierarchy of assets that indicates how the assets are connected and/or the interdependency between assets. In some examples, a hierarchy of assets may specify a primary asset and a corresponding backup asset. When rules engine133identifies that an asset has triggered a rule, speed layer116can associate the asset with other related assets to identify other assets that may be affected by a raised alarm in an asset. For example, if a primary asset becomes non-operational, speed layer116may determine that a corresponding backup asset will become operational as a result. In some examples a power and electrical hierarchy may indicate whether power and electrical are running on a primary asset or a backup asset. This may be referred to as resiliency status. The speed layer116provides this information back to the data center operations team, e.g., via notification services or dashboard APIs, so the team has an overall idea of how the power chain and mechanical chains are operating.

Notification engine131, described in further detail with respect toFIG. 15, provides notification services based on alerts received from the batch layer and/or speed layer. For example, the alerts may be configured as described herein with respect toFIGS. 30-33. Speed layer116stores indications of asset events to a database135(e.g., Cassandra) and to an analytical layer137(e.g., Hadoop) in the batch layer that may be used for running reports later, etc. The database135provides data to API library and API management124, API service orchestration126, and data as API128of service layer120. The service layer120may display information by a custom dashboard, e.g., using APIs. An example custom dashboard is shown inFIG. 19.

Service layer120, which receives the data from data platform59, includes API library and API management124, API service orchestration126, data as API128, notification services130, such as SMS and SMTP, a data mart132and an analytical workbench134.

FIG. 10is a block diagram illustrating an example application programming interface (API) in a data center infrastructure monitoring system, in accordance with techniques described herein. In the example ofFIG. 10, an example API platform technical architecture140includes orchestrator81for transmitting real time data140, and historical data142, and data with infra asset manager144. Underlying data service83(micro-services) provides API endpoints that can be invoked by customer applications, such as customer APIs85, customer portals87and global IBX management system (GIMS)89. In the example ofFIG. 10, there may be different microservices for each of real-time data140, historical data144, and infra asset manager144, for example.

In some examples, the API platform described herein may be an application platform as described in U.S. application Ser. No. 14/927,451, entitled INTERCONNECTION PLATFORM FOR REAL-TIME CONFIGURATION AND MANAGEMENT OF INTERCONNECTIONS WITHIN A CLOUD-BASED SERVICES EXCHANGE, filed Oct. 29, 2015, the entire contents of which are incorporated by reference herein. Orchestrator81may be an orchestrator/orchestration engine as described in U.S. application Ser. No. 14/927,306, entitled ORCHESTRATION ENGINE FOR REAL-TIME CONFIGURATION AND MANAGEMENT OF INTERCONNECTIONS WITHIN A CLOUD-BASED SERVICES EXCHANGE, filed Oct. 29, 2015, the entire contents of which are incorporated by reference herein.

Customer portals87may utilize various approaches, such as using an existing customer portal container and/or an existing customer portal architecture, for example. In another embodiment, customer portals87may utilize a customer portal/DCIM hybrid design, including DCIM a specific additional container, and replicates skin, navigation and layout, along with URL switching split (mostly leveraging the customer portal team) for a common approach. Such a CP/DCIM hybrid design aligns with a customer portal strategy of feature based development of an uber portal concept. According to another example, customer portals87may utilize an uber portal with customer portal and DCIM design may be utilized that follows uber architecture guidelines, uses feature based application deployment, and uses DCIM as an on-boarding application. According to yet another example, a customer portal with embedded DCIM user experience design (UX) may be utilized that includes features such as static content in the customer portal87, and in which the dynamic part of DCIM is called from the DCIM backend. Customer portal with embedded DCIM UX may invoke DCIM services using a java-script framework, and which invokes DCIM. In this way, customer portals87leverages existing customer portal integrations with an internet protocol (IP) portal for permissions and existing message center for alerts and notifications.

GIMS may be associated with a number of possible operational activities. For example, GIMS89may be associated with operational management of power usage effectiveness (PUE), alerts and assets, along with management of templates, assets, points and access controls. GIMS89may also be associated with real time analytics of historical data trends, asset maintenance, consistent asset view, asset status and fault information. In another example, GIMS may be associated with simulation and prediction of asset hierarchy traversal, one line diagram-what-if analysis, and time based query rules.

FIG. 11is a block diagram illustrating an example data center gateway API platform logical architecture159for a data center gateway, in accordance with one or more aspects of this disclosure. Data platform20corresponds to data platform20ofFIG. 1. Data platform20may include real time online data, historical offline data, infra asset data master, and reference data master. Data as API128, real-time notification services130, and analytics and visualization139are shown inFIG. 11as logically operating on top of data platform20.

Data as API128may include, for example, an API catalog, software development kit (SDK), and service virtualization. Real-time notification services130may include, for example, alarms, notifications (e.g., by SMTP, mail, voice, and/or SMS), and health monitoring. Analytics and visualization139may include, for example, data model, data discovery, and programmatic access. Customer APIs, customer portal, global IBX monitoring, product analytics, and visualization analytics may access data via API gateway and/or visualization analytics gateway, such as via API endpoints for authentication, access control, data security, policy, governance, and monitoring, for example. Monitoring APIs may provide, for example, environmental information such as humidity or temperature data from sensors, alerts from alarms, which customers may access by invoking customer APIs by the API gateway.

For example, a customer may send an API request by a customer API, where the API request invokes a monitoring API endpoint. The request payload may specify the monitoring API endpoint, and may specify particular monitoring information that is requested, such as information from particular sensor(s) for example. API gateway may access data from the data platform to service the API request, and may include the data (e.g., environmental information such as sensor data) in the API response payload.

FIG. 12is a block diagram illustrating an example technical architecture for public application programming interfaces (APIs)160interfacing with a data center infrastructure monitoring system data platform, in accordance with techniques described herein. In the example ofFIG. 12, asset data is received from DCIM data platform20by underlying micro-services83and orchestrator81. In the example ofFIG. 12, DCIM data platform20includes real time online data, historical offline data, data associated with an infra asset data master, and data associated with a reference data master. Orchestrator81provides an orchestration layer that can break down customer API requests into workflows for accessing the underlying micro-services83. In some examples, micro-services83may be provided as part of a full-stack development framework execution environment to facilitate application development for microservice-based application architectures, such as described by U.S. application Ser. No. 14/927,315, entitled MICRO SERVICE-BASED APPLICATION DEVELOPMENT FRAMEWORK, filed Oct. 29, 2015, the entire contents of which are incorporated by reference herein.

A developer platform146and an enterprise API gateway148receive the asset data from orchestrator81, and the resulting managed and authenticated asset data is transmitted to customer developers150. In the example ofFIG. 12, developer platform146includes subscription management, API software development kits (SDKs), an API catalog, and service virtualization. In the example ofFIG. 12, enterprise API gateway148includes authentication (e.g., oAuth2), an API cache, and API policies. In some examples, the technical architecture shown inFIG. 12may leverage a cloud exchange model for customer onboarding using developer platform146of the co-location facility provider. The technical architecture may also leverage the enterprise API gateway148of the co-location facility provider for all DCIM APIs. The technical architecture may also leverage BMS APIs and enhance the API catalog and SDKs. In some examples, the technical architecture ofFIG. 12may use a sandbox approach for APIs. In some examples, the micro-services and orchestrator that are used for customer portal87and/or applications internal to the co-location facility provider may be reused for customer APIs.

FIG. 13is a block diagram illustrating an example system200in which other IT systems are integrated with the DCIM data platform20, in accordance with one or more aspects of this disclosure. In the example ofFIG. 13, DCIM data platform20includes historical offline data, real time online data, a reference data master204, and enterprise data synchronization master (“enterprise data sync master”)202. In some examples, reference data master204may obtain enterprise systems data via enterprise data sync manager202.

In some examples, DCIM data platform20leverages an Enterprise Systems Gateway109to obtain data for enterprise systems. In some examples, DCIM data platform20obtains cage, cabinet and space drawings from a data management software system of the co-location facility provider. In some examples, DCIM data platform20obtains Electrical Infrastructure Assets information and maintenance information from an enterprise asset management (EAM) software system. DCIM data platform20may write Electrical infrastructure assets run hours back to the EAM software system at Enterprise Systems Gateway109. Enterprise Systems Gateway109may interact with ECO applications for engaging or managing data centers and systems.

FIG. 14is a block diagram illustrating a system300showing an example security configuration for components of a DCIM system, in accordance with one or more aspects of this disclosure. DCIM system302may correspond to DCIM system22ofFIG. 1and/or data platform59ofFIG. 9, for example. As shown in the example ofFIG. 14, DCIM edge data center and associated DCIM edge system16is secured by its own subnet. System300includes various firewalls, which may be data center-level next generation firewalls and security. DCIM edge systems16may use SSL-based communication between DCIM edge systems16and message broker. Secure connection will be enabled between Microservices and database. A data center gateway authenticates external requests via OAuth and generate a unique identifier (UUID). In some examples, the data center gateway may have secured geo-redundancy for database and message broker.

FIG. 15is a block diagram illustrating an example alerts and notification process in a data center infrastructure monitoring system, in accordance with techniques described herein. As shown inFIG. 15, alert-worthy events originate from infrastructure objects (“infra objects”). Alert-worthy events may include, for example, single value based alarms, derived value based alarms, device hierarchy alarms, and maintenance schedule alarms. Single value based alarms may include, for example, out-of-band threshold violations, resiliency status, and redundancy status. Derived value based alarms may include, for example, point calculation driven alarms, e.g., UPS power and sum of PDU power deviate by 5% from a threshold value. Device hierarchy alarms may alert on impacted devices, for example. Maintenance schedule alarms may include alarms/notifications based on planned redundancy and proactive notifications, for example.

In some examples, single value based alarms, device hierarchy alarms, and maintenance schedule alarms may each be configurable by data center operations administrators and/or by customer administrators. In some examples, derived value based alarms may be configurable only by data center operations administrators and not by customer administrators. For example, data center operations administrators or customer administrators may enter configuration data (e.g., via a customer portal or global IBX monitoring system) for creating and defining device alarms and setting alarm threshold values, defining composite alarms, defining hierarchy alarms, and importing maintenance alarms.

As shown inFIG. 15, a DCIM edge system (e.g., any of DCIM edge systems16described herein) intercepts the events originating from the infra objects, logs the events, and forwards the events to the data platform20. Data platform20triggers alerts, such as by applying the configured alarm detection rules. Data platform20qualifies an event as an alert based on the applications of the rules, and logs and forwards the alerts to notification engine (e.g., notification engine131ofFIG. 8). Notification engine131receives the alerts and creates tickets for the alerts (e.g., a ticket for each alert). Notification engine131negotiates the alert recipient and transport mechanism. Notification engine131provides message provisioning, e.g., via email using Simple Mail Transfer Protocol (SMTP) or Short Message Service (SMS).

FIG. 16is a block diagram illustrating an example system for a messaging service that applies real-time processing to data center events and publishes the processed events to custom topics of a publication platform in near real-time, according to techniques described herein. Computing system1000may represent an example of DCIM system22and other DCIM system architectures described in this disclosure. Computing system1000includes an API platform1002, a primary data center infrastructure monitoring platform1006A, and in some examples a backup data center infrastructure monitoring platform1006B for disaster recovery. Computing system1000receives registration requests for access to events (also referred to as “asset events” elsewhere in this disclosure) from API consumers1004, which may include customer applications1004A of customers of the data center provider, customer building management systems1004B for the customers, Internet of Things (IoT) devices1004C, API developers1004D developing applications, and DCIM agent1004E.

One or more of data centers12may include a corresponding DCIM agent1004E. For example, IBX-1may include DCIM agent1004E deployed by the data center provider of data centers12. Unlike physical infrastructure assets14of data centers12that produce infrastructure asset data for monitoring by API consumers1004, DCIM agents2012are examples of API consumers1004. DCIM agent1004E may represent a light-weight component that may be executed by an execution platform located in the corresponding data center12and deployed by the data center provider. Any data center12managed by the data center provider may include at least one corresponding instance of a DCIM agent1004E.

Computing system1000includes an API platform1002that executes one or more applications to route service requests, received via a communication network1012, for subscription API1018. API platform1002may operate as an API gateway (or “service gateway”). That is, API platform1002operates as a single point of entry for the one or more service instances of DCIM platform1006A applications and is responsible for service request routing to the service instances. API platform1002routes service requests, such as registration requests from API consumers1004, received at the API platform1002to target services offered by the one or more service instances of DCIM platform1006A applications. API platform1002may represent (or include) an example implementation for the API gateway ofFIG. 11. API platform1002may represent one or more server computing devices and/or virtualized execution environments executing one or more API platform1002applications and/or services. Although shown as a single element inFIG. 16, API platform1002may execute on a cluster of one or more physical computing devices comprising one or more physical processors and/or virtualized execution environments executing on one or more physical processors.

DCIM platform1006A represents one or more applications each executing as one or more service instances to expose a subscription API1018that includes methods for obtaining existing topics, registering new topics (“registration requests”), deleting topics, and updating topics, for example. In some examples, other methods may alternatively or additionally be used. DCIM platform1006A may receive asset events (or, more simply, “event data” or “events”) from any of the examples of DCIM edge platforms16described elsewhere in this document that process real-time data produced by and for infrastructure assets to generate asset events. DCIM platform1006A may represent an example implementation for data as API128and real-time notification services130ofFIG. 11.

API consumers1004may issue registration requests to the API platform1002that conform to the subscription API1018to invoke the subscription API1018methods, examples of which are described in detail below. That is, a registration request may indicate a method of the subscription API1018, and also specify one or more event subjects of events.

The following is a detailed description of a subscribeGet method for listing events to which a customer or user is currently subscribed. Header parameters:

TABLE 4Header parametersX-AUTH-USER-NAME*user id for the requestX-AUTH-ORG-ID*organization id for the user

An example subscribeGet response status 200 schema:

{// response object containing subscription details with subscription IDpower: [ // power event subscription details{ //object containing the power events the user is registered foraccountNo: stringibx: string}]tagPoints: [ // asset tag point update event subscription details{ // request object used to specify the asset events (tag dataupdate) theuser is registered foraccountNo: stringibx: stringassetType: stringassetClassification: stringassetId: stringtagId: string]alarms: [ // alarms update event subscription details{ //request object used to specify the alarm events the user isregistered foraccountNo: string // customer account numberibx: string // ibx codeassetType: string // asset TypeassetClassification: string // asset classification enumEnum: Electrical, Mechanical, Environmental]alerts: [ // alerts update event subscription details{ // request object used to specify the alert events the user isregistered foraccountNo: string // customer account numberibx: string // ibx codeassetType: string // asset TypeassetClassification: string // asset classification enumEnum: Electrical, Mechanical, Environmental, Power]environmental: [ // environmental update event subscription details{ // request object used to specify the alert events the user isregistered foraccountNo: string // customer account numberibx: string // ibx codelevelTypes: [string // level type enumEnum: ibx, zone, cage, cabinet]]resiliency: [ // resiliency update event subscription details{ // request object used to specify the resiliency events the useris registered foraccountNo: string // customer account numberibx: string // ibx codeassetType: string // asset TypeassetClassification: string // asset classification enumEnum: Electrical, Mechanical]subscriptionID: number // unique request number and subscriptionidentifier config:{ // real-time infra provider information - cloud agnostic -provider: string // pub/sub provider enum to be used forconsuming real-time feedsEnum: “cloud_provider_1”, “cloud_provider_2”, “private”method: string // subscription method enumEnum: PULL, PUSHpushurl: string // push url - mandatory when the method is PUSHerrors: [{ // api error objectcode: string // Error Codemessage: string // error messagemore_info: string // details about the error messagedata:  { // related data if any }]

An example subscribeGet response status 200 schema:

{ // api error objectcode: string // Error Codemessage: string // error messagemore_info: string // details about the error messagedata: { // related data if any }

The following is a detailed description of a subscribePost method for registering a user for a near real-time feed of events. Header parameters:

TABLE 5Header parametersX-AUTH-USER-NAME*user id for the requestX-AUTH-ORG-ID*organization id for the user

An example of a subscribePost body parameters schema for a subscriberPost request:

{// request object containing list of events the user would like tosubscribe/register.power: [ // power event subscription details{ //object containing the power events the user would like tosubscribe toaccountNo: stringibx: string}]tagPoints: [ // asset tag point update event subscription details{ // request object used to specify the asset events (tag dataupdate) the user would like to subscribe to accountNo: stringibx: stringassetType: stringassetClassification: stringassetId: stringtagId: string]alarms: [ // alarms update event subscription details{ //request object used to specify the alarm events the userwould like to subscribe toaccountNo: string // customer account numberibx: string // ibx codeassetType: string // asset TypeassetClassification: string // asset classification enumEnum: Electrical, Mechanical, Environmental]alerts: [ // alerts update event subscription details{ // request object used to specify the alert events the user wouldlike to subscribe toaccountNo: string // customer account numberibx: string // ibx codeassetType: string // asset TypeassetClassification: string // asset classification enumEnum: Electrical, Mechanical, Environmental, Power]environmental: [ // environmental update event subscription details{ // request object used to specify the alert events the user wouldlike to subscribe toaccountNo: string // customer account numberibx: string // ibx codelevelTypes: [string // level type enumEnum: ibx, zone, cage, cabinet]]resiliency: [ // resiliency update event subscription details{ // request object used to specify the resiliency events the userwould like to subscribe toaccountNo: string // customer account numberibx: string // ibx codeassetType: string // asset TypeassetClassification: string // asset classification enumEnum: Electrical, Mechanical]config: [{ // real-time infra provider information - cloud agnostic -provider: string // pub/sub provider enum to be used forconsuming real-time feedsEnum: “cloud_provider_1”, “cloud_provider_2”, “private”method: string // subscription method enumEnum: PULL, PUSHpushurl: string // push url - mandatory when the method is PUSH]

The example subscribePost response status 200 and status 0 schemas are similar to the example subscribeGet status 200 schemas described above.

The following is a detailed description of a subscribeSubscriptionIdDelete method for deleting a subscription. Path parameters:

TABLE 5Path parameterssubscriptionId*unique identifier for the subscription

An example of a subscribeSubscriptionIdDelete schema for a subscribeSubscriptionIdDelete status 0 error response:

The following is a detailed description of a subscribeSubscriptionIdGet method for getting a subscription identified by a subscription identifier. Path parameters:

TABLE 6Path parameterssubscriptionId*unique identifier for the subscription

The example subscribeSubscriptionId response status 200 and status 0 schemas are similar to the example subscribeGet status 200 schemas described above.

The following is a detailed description of a subscribeSubscriptionIdPut method for updating a subscription to add or remove events from a near real-time feed. Path parameters:

TABLE 7Path parameterssubscriptionId*unique identifier for the subscription

TABLE 8Header parametersX-AUTH-USER-NAME*user id for the requestX-AUTH-ORG-ID*organization id for the user

The example subscribeSubscriptionIdPut is similar to the example subscribePost body parameters schema for a subscriberPost described above. The example response status 200 and status 0 schemas are similar to the example subscribePost status 200 schemas described above.

Using subscription API1018, DCIM platform1006A receives from API consumers1004registration requests that each represents a request to register for a topic that provides access to near real-time data1017generated by infrastructure assets of one or more data centers12, here illustrated as International Business Exchanges (IBXes), IBX-1through IBX-XX. A registration request may be an HTTP POST that invokes the subscribePost method one of the above examples from Table 3. Near real-time data1017generated by infrastructure assets of one or more data centers12may include examples of data collected at one or more DCIM edges and provided to a data platform, as described above, with the data platform here being (or including) DCIM platform1006A to provide near real-time access to events that describe operations or conditions of infrastructure assets14of data centers12.

Example event types may describe alarm statuses, alert statuses, tagpoint events that include values of infrastructure asset tagpoints, power events describing power consumption by infrastructure assets of the data centers, environmental data describing readings by environmental sensors, and resiliency information that indicates resiliency (e.g., availability of redundant assets, backup, etc.) for infrastructure assets. For instance, a data center12may generate a series of events that describe power consumption by a cabinet of the data center12. As another example instance, a data center12may generate may generate a series of events that describe the temperatures determined by a temperature sensor (a type of environmental sensor) at a space within the data center12.

Each of the events is associated with identifying information (an “event identifier”) that uniquely identifies the event subject. Example event identifiers and event subjects include a unique alarm identifier for an alarm object, a unique alert identifier for an alert object, a unique tagpoint identifier for a tagpoint of an asset, an identifier for an infrastructure asset associated with power data, space and sensor identifiers associated with environmental data, and an identifier for an infrastructure asset having some resiliency status. Examples of such event identifiers are provided below in the example event object schemas. In some cases, DCIM platform1006A generates events using near real-time data1017generated by data centers12. In some cases, near real-time data1017includes events. In either case, DCIM platform1006A obtains the events using near real-time data1017.

A registration request may specify a customer account, a data center, and a list of event subjects that correspond to near real-time data generated by the specified data center of data centers12. Each event subject is a subject for one or more events that describe the event subject, and each event may correspond to a different event type describing the type of data for the event and the event subject. Example event subjects include alarm objects, alert objects, infrastructure assets, environmental sensors, and properties (“tagpoints”) of infrastructure assets. Registration requests may include event identifiers that uniquely identify the event subject for events for which access is being requested.

The following schema provide example descriptions of example event types for different events obtained and made accessible to API consumers1004by the DCIM platform1006A, according to techniques described in this disclosure:

TABLE 1Event typesEventDescriptionalarm_activeAn alarm is currently activealarm_clearedAn alarm has clearedalert_activeAn alert is currently activealert_acknowledgedAn alert was acknowledgedtagpoint_updatedA new tagpoint data value was updatedpower_updatedA new power consumption datapoint was addedenvironment_updatedA new environmental sensor datapoint was addedresiliency_updatedResiliency information was updated

Data included in an event is referred to as “event data” and may indicate the type of event and include an object describing the event. The alarm_active event indicates that an alarm was activated. The alarm_active event is sent when an alarm is activated. It can be accessed by all user accounts connected to the alarm. The alarm property is an alarm object containing information about the alarm:

The alarm cleared event indicates that an alarm was cleared. The alarm cleared event is sent when an alarm is cleared. It can be accessed by all user accounts connected to the alarm. The alarmId is the unique identifier for the alarm object. The eventTs is the timestamp when the event was created in the system. The following is example event data:

The tagpoint_updated event indicates that there is new data generated for a tagpoint of an infrastructure asset. The tagpoint_updated event is sent when a tagpoint data is updated. It can be accessed by all users who have visibility to the tagpoint. The tagPointData property is a TagPointData object containing latest information about the tagpoint:

The power_updated event indicates that new power consumption data is received or calculated. A power_updated event is accessible to a user who has access to accounts that own the circuits to which the power consumption data is related to. The powerData property is a PowerData object containing the power consumption information:

The environment updated event indicates that new environment data is updated or calculated. An environment updated event is accessible to user accounts that have a cage/cabinet in a location/data center space related to the environment information. The environmentData property is a EnvironmentData object containing the environment information.

The resiliency_updated event indicates that resiliency status for a group of assets is calculated and modified. It is accessible to user accounts that are affected by the asset. The resiliencyData property is a ResiliencyData object containing the resiliency information

Objects included in events describe the subjects of the events, including the updated data points for the subjects of the events. Different types of events have corresponding object types. The following are example schema for event objects included in events.

“TagPointData”: {“type”: “object”,“description”: “Tag Point is a property of the Asset it is linked to.”,“properties”: {“value”: {“type”: “string”,“description”: “Current data value for the tag point”},“tagId”: {“type”: “string”,“description”: “ID for the tagPoint - Unique Identifierfor the Tag Point”},“tagDisplayName”: {“type”: “string”,“description”: “Generic label for the tag point”},“uom”: {“type”: “string”,“description”: “Unit of measure for the data value for thetag point”},“alarmStatus”: {“type”: “string”,“description”: “Indicates whether there are any alarmscurrently active for the tagpoint”},“readingTime”: {“type”: “string”,“format”: “date-time”,“description”: “date time when the tag point value wasread from the device.”}}}

Asset Resiliency is an indicator of whether the functionality of the asset is in doubt irrespective of whether the particular asset is functioning or not. Asset Resiliency is a configurable point based on underlying assets that help determine the system resiliency. For example, a data center12may have power generators—G-1, G-2, G-3, G-1R, G-2R, G-3R. G-1, G-2 and G-3 are capable of serving the demands for the datacenter 12 with 3 redundant generators, G-1R, G-2R, and G-3R.

Scenario 1: G-1 and G-2R are not functioning. Even though the G-1 and G-2R are not functioning, because the rest of the functioning generators are able to serve the demand for the datacenter all of the generators are considered to be resilient.

Scenario 2: If for some reason four of the generators are not functioning, then the generators are no longer considered in resilient state even though none of them may actually be in use.

Resiliency data informs customers regarding changes in asset resiliency to enable them to make operational decisions based on live machine data feeds. An example ResiliencyData object is as follows:

To provide access to the event data, DCIM platform1006A creates topics in one or more cloud-based publication platforms1010A-1010N. DCIM platform1006A may additionally or alternatively create topics in one or more internal publication platforms1030. Cloud-based publication platforms1010and internal publication platforms1030may be referred to herein more generically as “publication platforms.” Cloud-based publication platforms1010and internal publication platform1030each represents an asynchronous messaging system by which publishers create and send messages to topics. Consuming applications (or “subscribers”) create subscriptions to topics in order to receive the messages sent to the topics. In this way, the computing system1000provides a messaging service for API consumers1004to receive DCIM event data in near real-time. API consumers1004may perform one or more actions based on the DCIM event data. Each of cloud-based publication platforms1010and internal publication platform1030represents applications executing on a computing architecture and, more particularly, executing on a public, private, or hybrid cloud computing architecture. Each computing architecture for a cloud-based publication platform1010and an internal publication platform1030includes or one or more physical computing devices comprising one or more physical processors and/or virtualized execution environments executing on one or more physical processors. Example cloud-based publication platforms1010include the Cloud Pub/Sub service of Google Cloud, manufactured by GOOGLE, INC.; Microsoft Service Bus of Microsoft Azure, manufactured by MICROSOFT, INC.; and Simple Queue Service of Amazon Web Services, manufactured by AMAZON, INC. Example of an internal publication platform1030include Apache Kafka, ActiveMQ, IBM MQ, Solace Virtual Message Router, RabbitMQ, Red Hat JBoss MAQ, Anypoint MQ, Aurea CX Messenger, and Oracle Tuxedo Message Queue.

Each cloud-based publication platform1010offers a publish API1016by which DCIM platform1006A registers new topics1060and publishes messages to the topics1060for consuming by topic subscribers. Internal publication platform1030may offer a similar publish API1016by which DCIM1006A registers new topics1060and publishes messages to the topics1060for consuming by topic subscribers. A topic1060is a named resource to which messages are sent and to which a consuming application may subscribe to receive the messages. A topic1060may be identified using a full or partial Uniform Resource Identifier (URI). A subscription is a named resource representing messages from a topic1060and for delivery to a particular subscriber. A topic1060can have multiple subscriptions, but a particular subscription is associated with and receives messages for a single topic. A subscription may operate according to a pull model in which the subscriber requests messages for the topic1060, or according to a push model in which the cloud-based publication platform1010or internal publication platform1030initiates requests to the subscriber to deliver messages for the topic1060. A subscription may be identified using a full or partial URI.

In response to receiving a registration request conforming to subscription API1018, DCIM platform1006A processes the registration request and sends, to selected ones of cloud-based publication platforms1010and internal publication platform1030using the corresponding publish API1016, a topic request to request a new topic for the list of events specified in the registration request and generated by the specified data center12. DCIM platform1006A may publish to multiple platforms. The selected ones of cloud-based publication platform1010and internal publication platform1030create the topic in topics1060and return a description of the topic to the DCIM platform1006A in response to the topic request. The description of the topic may include a subscription identifier usable for creating a subscription to the topic. The subscription identifier may be a full or partial URI, a string, an integer, etc. In some instances, the description of the topic may include subscription details. The subscription details may include data describing a subscription created by the DCIM platform1006A on behalf of the requesting API consumer1004, and usable by the API consumer1004for obtaining near real-time events describing operations of a data center12. In some instances, the registration request may specify the cloud-based publication platform1010and/or internal publication platform1030to be selected and used by the DCIM platform1006A for publishing event data according to the registration request. DCIM platform1006A returns the subscription identifier in a registration response to the API consumer1004that issued the registration request, in response to successful registration of the topic.

DCIM platform1006A also creates mappings from each of the event subjects indicated in the registration requested to the new topic of topics1060, and stores the mappings to data-topic map1040. For example, a registration request may indicate two event subjects, an alarm and a tagpoint, each having a unique event identifier. After receiving the new topic from the selected ones of cloud-based publication platform1010and internal publication platform1030, DCIM platform1006A creates a mapping for each of the event subjects to the topic and stores the two mappings to data-topic map1040. If data-topic map1040includes an existing mapping for an event subject, DCIM platform1006A may add the topic to an existing list of one or more topics for the existing mapping. Thus, each mapping or entry in data-topic map1040is a one-to-many association of an event subject to one or more topics for publishing events relating to the event subject. Data-topic map1040may further include a description of the subscribed events. Data-topic map1040may represent an associative data structure, such as a map, a table, a list of tuples, and a hash map. The event identifier for an event subject may operate as a lookup key to a corresponding entry in data-topic map1040, such entry mapping the event identifier/lookup key to one or more topics1060for the event subject. Data-topic map1040may represent a hash table, with mappings stored to hash buckets and hashes of event identifiers used as the lookup key. Example hash functions include SHA-1 and MD5.

DCIM platform1006A subsequently obtains events using near real-time data1017from data centers12. DCIM platform1006A queries data-topic map1040using the event identifier for each event to quickly determine whether the event subject has a corresponding one or more topics in any of cloud-based publication platforms1010and internal publication platform1030. If so, DCIM platform1006A obtains the one or more topics for the event subject and publishes the event to the topic by sending a publication message, using publish APIs1016, that includes the event data for the event to the resource for the topic. As used herein, “resource” may refer to a resource accessible at a particular URI.

As noted above, API consumers1004receive subscription identifiers in registration responses from DCIM platform1006A, the subscription identifiers being usable for subscribing to corresponding topics1060of cloud-based publication platforms1010and internal publication platform1030. Cloud-based publication platforms1010and internal publication platform1030may provide corresponding subscribe APIs1014for subscribing to topics1060to obtain events published to the topics1060by DCIM platform1006A.

API consumers1004request subscriptions to topics1060by identifying the desired topics1060using subscription identifiers provided by DCIM platform1006A. Using the subscriptions, API consumers1004request messages that include the events published to the topics1060by DCIM platform1006A. In this way, API consumers1004may obtain event data that describes operations and conditions of data centers12and that is published in near real-time by DCIM platform1006A to provide infrastructure asset updates to API consumers1004.

In some examples, computing system1000uses Server-side Events (SSE) for event publication rather than cloud-based publication platforms1010. In such examples, an API consumer1004subscribes to an SSE platform to obtain real-time notifications of events. The SSE platform provides a REST API for fetching event data. When DCIM platform1006A receives a new event, DCIM platform1006A publishes the new event to a topic for the SSE platform and notifies the API consumer1004of the availability of new event. The API consumer1004may then use the REST API to fetch the new event.

Computing system1000may include backup DCIM platform1006B in some examples for disaster recovery. DCIM platform1006B may be similar to DCIM platform1006A but located elsewhere for geographic redundancy. DCIM platform1006A may replicate data-topic map1040to DCIM platform1006B, which may assume and perform event publication in the event of a failure of DCIM platform1006A.

FIG. 17is a block diagram illustrating an example system for a messaging service that applies real-time processing to data center events and publishes the processed events to custom topics of a publication platform in near real-time, according to techniques described herein. Computing system1100includes an API platform1002and a primary data center infrastructure monitoring (DCIM) platform1106. DCIM platform1106illustrates, in detail, an example implementation of primary DCIM platform1006A.

DCIM platform1106includes data streaming platform1118, real-time data stream processor1111, and controller1110. Each of data streaming platform1118, real-time data stream processor1111, and controller1110may represent one or more server computing devices and/or virtualized execution environments executing one or more API platform1002applications and/or services. Although shown as single elements, each of data streaming platform1118, real-time data stream processor1111, and controller1110may execute on a cluster of one or more physical computing devices comprising one or more physical processors and/or virtualized execution environments executing on one or more physical processors.

Data streaming platform1118receives real-time data1124generated by data center12and creates data streams1126. Data streaming platform1118may represent an Apache Kafka instance(s), for example.

Controller1110processes subscription API1018service requests originated by API consumers1004. Controller1110authorizes and processes such service requests to responsively create/modify topics1060and generate/modify entries of data-topic map1040. Controller1110may store data-topic map1040to a memory of a computing device that executes one or more service instances of a controller1110application. In general, controller1110operates as a feed manager to configure real-time or near real-time feeds. Controller1110receives inputs from controlling applications and determines data, alarms, and alerts that should flow to API consumers1004. As described in further detail below, operations of controller1110include receiving input from API consumers1004or control applications for data centers12; obtaining asset map information for mapping data for assets to topics; determining data, alerts, and alarms that should flow to API consumers and updating data-topic mappings; and refreshing a real-time cache for real-time data stream processor1111.

Real-time data stream processor1111obtains data streams1126generated by data streaming platform1118and publishes events from the data streams1126to topics1060cloud-based publication platforms1110based on mappings stored to data-topic map1040. Real-time data stream processor1111may store data streams1126to a persistent database1112. Persistent database1112may represent a Cassandra database instance, for example. Real-time data stream processor1111may represent an Apache Storm instance(s), for example.

In general, real-time data stream processor1111and data streaming platform1118consume data streams and, based on data-topic map1040, publish data to API consumers1004on the configured topics1060(also referred to as “channels”). Data streaming platform1118may push data on a stream platform (e.g., Kafka) topic (not shown) that is of interest to one or more customers. Then real-time data stream processor1111may retrieve the data from the topic, refer to data-topic map1040to determine the customer and topic1060to push the data to, and publish the data to the determined topic(s)1060.

As one example of processing events, DCIM agent1004E obtains, from a publication platform1010or1030, infrastructure asset data in published events1152for a topic1060that conform to cloud protocols for the messaging service of the platform. DCIM agent1004E intelligent translates, using a pre-defined mapping, the infrastructure asset data to formatted infrastructure asset data that is usable with the network management or control protocols with which customer equipment in IBXes12communicate to receive infrastructure asset data. For example, a management protocol server of DCIM agent1004E provides infrastructure asset data to a management protocol client of IBX-XX using a management protocol, e.g., SNMP. The management protocol client may issue a request requesting a certain asset data database value, which may be an OID in SNMP examples. The request may represent an SNMP Get. In response to the request, the management protocol server of DCIM agent1004E issues a response1036that includes the value read from an asset data database managed by DCIM agent1004E. In some cases, the management protocol server may be configured with traps (e.g., SNMP traps) to cause the management protocol server to issue responses1036for the trap values unrequested. Further example details of a DCIM agent are described in U.S. Provisional Patent Application 62/573,034, filed Oct. 16, 2017 and entitled “Data Center Agent for Data Center Infrastructure Monitoring Data Access and Translation,” which is incorporated herein by reference in its entirety.

FIG. 18is a flowchart illustrating an example mode of operation for computing system1100to apply real-time processing to data center events and publish the processed events to custom topics of a publication platform in near real-time, according to techniques described herein. Although described primarily with respect to a system that uses a cloud-based publication platform1010for event publication, the mode operation applies to a computing system that uses an internal publication platform1030. API platform1002receives a registration request1130that indicates a customer of the data center12provider and an event subject for events that describe operations of a data center12and, in some cases more particularly, operations of at least one data center12infrastructure asset (1202). The registration request1130identifies a subscription API1018resource and conforms to subscription API1018. API platform1002routes the registration request1130to a service instance of controller1110for processing. In the example ofFIG. 18, controller1110queries customer database1120to determine whether the customer indicated in the registration request1130is authorized to access events for the event subject (1204). If not (NO branch of1204), controller1110rejects the registration request and returns a registration response that indicates no success (1206). In some examples, step1204may be optional. The registration request may indicate the cloud-based publication platform1010or internal publication platform1030to be used for event publication.

In some examples, if a customer of the data center provider ceases to be a customer or modifies its customer footprint (e.g., amount or types or locations of resources purchased from data center provider), a security overlay manages the change in authorization to provide more (or less) authorization to data for additional (or reduced) data center resources.

If the customer is authorized (YES branch of1204), then controller1110sends a topic request1138to cloud-based publication platform1010A to request a new topic of topics1060for use for publishing DCIM events (1208). Controller1110receives a description of the new topic in a topic response, where the description includes a subscription identifier usable for publishing events and creating a new subscription with cloud-based publication platform1010A (1209). In some examples, controller1110queries customer database1120to determine whether there is an existing subscriber identifier for the customer from a previous registration request. If so, the controller1110may reuse the existing subscriber identifier for the additional event(s) for which access is being requested in the registration request.

Controller1110creates an entry1140in the data-topic map1040that maps an event identifier for the event subject that is the subject of the registration request to the new topic (1210). Controller1110and sends a registration response1135, responsive to registration request1134, that includes the subscription identifier, which the API consumer1004/customer can use to create a subscription with cloud-based publication platform1010A for obtaining events published to the corresponding topic1060. API platform1102may send a registration response1132, responsive to registration request1130, to the requesting API consumer1004. Registration response1132may include the subscription identifier. To subscribe to a topic, API consumers may register using a subscription request1150that includes the subscription identifier and thereafter receive published events1152published by DCIM platform1106to the platform1010A.

Real-time data stream processor1111receives event streams1126including event1142having an event identifier (1214). Real-time data stream processor1111uses the event identifier (or a hash or other representation thereof) as a lookup key to query data-topic map1040to determine whether a matching entry is stored (1216). If no matching entry is found (NO branch of1216), real-time data stream processor1111stores the event data to persistent database1112(1220). If a matching entry is found (YES branch of1216), real-time data stream processor1111publishes, with communication1144, the event1142to the one or more topics mapped in the matching entry, which includes the new topic received in step1209(1218). Real-time data stream processor1111may also store the event data to persistent database1112(1220). The above example mode of operation may be used for publishing events to topics1060of internal publication platform1030in addition to or alternatively to a cloud-based publication platform1010A.

FIG. 19is a block diagram illustrating example features of a real-time partner API catalog for obtaining near real-time events from a DCIM platform1006A that monitors one or more data centers, according to techniques described herein. Platform API is an example conceptual rendering of an API having resources for authentication (/auth), user management (/user), and user accounts (/account).FIG. 19also depicts resources for subscription/registration provided by subscription API1018, as well as real-time events for which the customer may register using subscription API. The near real-time API techniques described herein may enable customers to consume real-time machine data feeds, alerts, and alarms in near real-time, wherein the real-time API is defined in the form of events and objects.

FIG. 20is a block diagram illustrating further details of one example of a computing device that operates in accordance with one or more techniques of the present disclosure.FIG. 20may illustrate a particular example of a server or other computing device500that includes one or more processor(s)502for executing any one or more of infra asset configurator550, DCIM edge module552, data center gateway module554, asset profile recommendations engine556, GIMS module558, API platform module560, controller562, stream processor564, streaming platform566, or any other application described herein. Other examples of computing device500may be used in other instances. Computing device500may be, for example, any of DCIM systems22(FIG. 1), DCIM system23(FIG. 2), DCIM system400(FIG. 3), API platform1002, and components of DCIM platform1106. Although shown inFIG. 20as a stand-alone computing device500for purposes of example, a computing device may be any component or system that includes one or more processors or other suitable computing environment for executing software instructions and, for example, need not necessarily include one or more elements shown inFIG. 20(e.g., communication units506; and in some examples components such as storage device(s)508may not be colocated or in the same chassis as other components).

As shown in the example ofFIG. 20computing device500includes one or more processors502, one or more input devices504, one or more communication units506, one or more output devices512, one or more storage devices508, and user interface (UI) device(s)510. Computing device500, in one example, further includes one or more application(s)522, DCIM system application(s)524, and operating system516that are executable by computing device500. Each of components502,504,506,508,510, and512are coupled (physically, communicatively, and/or operatively) for inter-component communications. In some examples, communication channels514may include a system bus, a network connection, an inter-process communication data structure, or any other method for communicating data. As one example, components502,504,506,508,510, and512may be coupled by one or more communication channels514.

Processors502, in one example, are configured to implement functionality and/or process instructions for execution within computing device500. For example, processors502may be capable of processing instructions stored in storage device508. Examples of processors502may include, any one or more of a microprocessor, a controller, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or equivalent discrete or integrated logic circuitry.

One or more storage devices508may be configured to store information within computing device500during operation. Storage device508, in some examples, is described as a computer-readable storage medium. In some examples, storage device508is a temporary memory, meaning that a primary purpose of storage device508is not long-term storage. Storage device508, in some examples, is described as a volatile memory, meaning that storage device508does not maintain stored contents when the computer is turned off. Examples of volatile memories include random access memories (RAM), dynamic random access memories (DRAM), static random access memories (SRAM), and other forms of volatile memories known in the art. In some examples, storage device508is used to store program instructions for execution by processors502. Storage device508, in one example, is used by software or applications running on computing device500to temporarily store information during program execution.

Storage devices508, in some examples, also include one or more computer-readable storage media. Storage devices508may be configured to store larger amounts of information than volatile memory. Storage devices508may further be configured for long-term storage of information. In some examples, storage devices508include non-volatile storage elements. Examples of such non-volatile storage elements include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories.

Computing device500, in some examples, also includes one or more communication units506. Computing device500, in one example, utilizes communication units506to communicate with external devices via one or more networks, such as one or more wired/wireless/mobile networks. Communication units506may include a network interface card, such as an Ethernet card, an optical transceiver, a radio frequency transceiver, or any other type of device that can send and receive information. Other examples of such network interfaces may include 3G and WiFi radios. In some examples, computing device500uses communication unit506to communicate with an external device.

Computing device500, in one example, also includes one or more user interface devices510. User interface devices510, in some examples, are configured to receive input from a user through tactile, audio, or video feedback. Examples of user interface devices(s)510include a presence-sensitive display, a mouse, a keyboard, a voice responsive system, video camera, microphone or any other type of device for detecting a command from a user. In some examples, a presence-sensitive display includes a touch-sensitive screen.

One or more output devices512may also be included in computing device500. Output device512, in some examples, is configured to provide output to a user using tactile, audio, or video stimuli. Output device512, in one example, includes a presence-sensitive display, a sound card, a video graphics adapter card, or any other type of device for converting a signal into an appropriate form understandable to humans or machines. Additional examples of output device512include a speaker, a cathode ray tube (CRT) monitor, a liquid crystal display (LCD), or any other type of device that can generate intelligible output to a user.

Computing device500may include operating system516. Operating system516, in some examples, controls the operation of components of computing device500. For example, operating system516, in one example, facilitates the communication of one or more applications522and DCIM system application(s)524with processors502, communication unit506, storage device508, input device504, user interface devices510, and output device512.

Application522and DCIM system application(s)524may also include program instructions and/or data that are executable by computing device500. Example DCIM system application(s)524executable by computing device500may include any one or more of infra asset configurator550, DCIM edge module552, data center gateway module554, asset profile recommendations engine556, GIMS module558, API platform module560, controller562, stream processor564, and streaming platform566, each illustrated with dashed lines to indicate that these may or may not be configured for execution by any given example of computing device500. Other DCIM system applications not shown may alternatively or additionally be included, providing other functionality described herein.

In this example, DCIM system applications524include infra asset configurator550, DCIM edge module552, data center gateway module554, asset profile recommendations engine556, GIMS module558, API platform module560, controller562, stream processor564, and streaming platform566. Infra asset configurator550may include instructions for causing computing device500to perform one or more of the operations and actions described in the present disclosure with respect to infra asset configurator44. DCIM edge module552may include instructions for causing computing device500to perform one or more of the operations and actions described in the present disclosure with respect to DCIM edge16. Data center gateway module554may include instructions for causing computing device500to perform one or more of the operations and actions described in the present disclosure with respect to any of data center gateways34,110,140. Asset profile recommendations engine556may include instructions for causing computing device500to perform one or more of the operations and actions described in the present disclosure with respect to asset profile recommendations. For example, when an asset such as a UPS, for example, is introduced into the DCIM system, the asset profile recommendations engine556may automatically identify an asset type based on tag points, and recommend a configuration setup based on how other assets of the same type in other data centers are configured, resulting in the introduced asset being more operationally efficient based on the setup of similar assets in the other data centers. GIMS module558may include instructions for causing computing device500to perform one or more of the operations and actions described in the present disclosure with respect to GIMS42.

API platform module560, controller562, stream processor564, and streaming platform566represent applications executed by computing device500to perform operations described with respect to computing system1000ofFIG. 16and computing system1100ofFIG. 17. More specifically, API platform module560may exchange data with communication unit(s)506and perform operations described with respect to API platform1002. Controller562may exchange data with communication unit(s)506and perform operations described with respect to controller1110. Stream processor564may exchange data with communication unit(s)506and perform operations described with respect to real-time data stream processor1111. Streaming platform566may exchange data with communication unit(s)506and perform operations described with respect to data streaming platform1118.

The techniques described herein may be implemented in hardware, software, firmware, or any combination thereof. Various features described as modules, units or components may be implemented together in an integrated logic device or separately as discrete but interoperable logic devices or other hardware devices. In some cases, various features of electronic circuitry may be implemented as one or more integrated circuit devices, such as an integrated circuit chip or chipset. If implemented in hardware, this disclosure may be directed to an apparatus such as a processor or an integrated circuit device, such as an integrated circuit chip or chipset. Alternatively or additionally, if implemented in software or firmware, the techniques may be realized at least in part by a computer-readable data storage medium comprising instructions that, when executed, cause a processor to perform one or more of the methods described above. For example, the computer-readable data storage medium may store such instructions for execution by a processor. A computer-readable medium may form part of a computer program product, which may include packaging materials. A computer-readable medium may comprise a computer data storage medium such as random access memory (RAM), read-only memory (ROM), non-volatile random access memory (NVRAM), electrically erasable programmable read-only memory (EEPROM), Flash memory, magnetic or optical data storage media, and the like. In some examples, an article of manufacture may comprise one or more computer-readable storage media. In some examples, the computer-readable storage media may comprise non-transitory media. The term “non-transitory” may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in RAM or cache).