Abstract: An all-solid-state single-frequency continuous wave laser is provided, which includes a symmetric ring resonant cavity, a first gain crystal and a second gain crystal symmetrically arranged in the symmetric ring resonant cavity, and a gain unit symmetrically arranged between the first gain crystal and the second gain crystal. The gain unit includes at least one gain crystal arranged in sequence. In the gain unit, a third gain crystal nearest to the first gain crystal and a fourth gain crystal nearest to the second gain crystal are symmetrically arranged. Each gain crystal is coupled with a separate pump source. Each gain crystal in the symmetric ring resonant cavity is equipped with a separate pump source, and the imaging system is eliminated in the symmetric ring resonant cavity. On the premise that the pump power is not limited, the laser can achieve stable single-frequency operation in a wide pump range.

Abstract: Techniques for resource monitoring and managed message reordering in a data center are described. In one example, a computing system comprises an ingress engine to receive a message from a network device in a data center comprising a plurality of network devices and the computing system; and in response to receiving the message from a network device in the data center, communicate the message to an appropriate collector application corresponding to the message's protocol type in compliance with at least one requirement for data stored in a message flow communicated from one or more network devices to the computing system.

Abstract: An alarm service can receive an alarm rule as an “intent” that defines a rule in a high level “natural language.” An alarm rule compiler can receive the intent and translate the high level intent into one or more lower level rules that can be programmatically processed by multiple alarm rule execution engines. Devices in a network system can be associated with alarm rule execution engines in a distributed manner. For example, devices in a network can be associated with different instances of an alarm rule execution engine, thus distributing the resource usage for obtaining telemetry data and processing alarms with respect to the devices in a network across multiple alarm rule execution engines.

Abstract: An alarm service can receive an alarm rule as an “intent” that defines a rule in a high level “natural language.” An alarm rule compiler can receive the intent and translate the high level intent into one or more lower level rules that can be programmatically processed by multiple alarm rule execution engines. Devices in a network system can be associated with alarm rule execution engines in a distributed manner. For example, devices in a network can be associated with different instances of an alarm rule execution engine, thus distributing the resource usage for obtaining telemetry data and processing alarms with respect to the devices in a network across multiple alarm rule execution engines.

Abstract: An alarm service can receive an alarm rule as an “intent” that defines a rule in a high level “natural language.” An alarm rule compiler can receive the intent and translate the high level intent into one or more lower level rules that can be programmatically processed by multiple alarm rule execution engines. Devices in a network system can be associated with alarm rule execution engines in a distributed manner. For example, devices in a network can be associated with different instances of an alarm rule execution engine, thus distributing the resource usage for obtaining telemetry data and processing alarms with respect to the devices in a network across multiple alarm rule execution engines.

Abstract: An alarm service can receive an alarm rule as an “intent” that defines a rule in a high level “natural language.” An alarm rule compiler can receive the intent and translate the high level intent into one or more lower level rules that can be programmatically processed by multiple alarm rule execution engines. Devices in a network system can be associated with alarm rule execution engines in a distributed manner. For example, devices in a network can be associated with different instances of an alarm rule execution engine, thus distributing the resource usage for obtaining telemetry data and processing alarms with respect to the devices in a network across multiple alarm rule execution engines.

Abstract: A telemetry service can receive telemetry collection requirements that are expressed as an “intent” that defines how telemetry is to be collected. A telemetry intent compiler can receive the telemetry intent and translate the high level intent into abstract telemetry configuration parameters that provide a generic description of desired telemetry data. The telemetry service can determine, from the telemetry intent, a set of devices from which to collect telemetry data. For each device, the telemetry service can determine capabilities of the device with respect to telemetry data collection. The capabilities may include a telemetry protocol supported by the device. The telemetry service can create a protocol specific device configuration based on the abstract telemetry configuration parameters and the telemetry protocol supported by the device. Devices in a network system that support a particular telemetry protocol can be allocated to instances of a telemetry collector that supports the telemetry protocol.

Abstract: Techniques for resource monitoring and managed message reordering in a data center are described. In one example, a computing system comprises an ingress engine to receive a message from a network device in a data center comprising a plurality of network devices and the computing system; and in response to receiving the message from a network device in the data center, communicate the message to an appropriate collector application corresponding to the message's protocol type in compliance with at least one requirement for data stored in a message flow communicated from one or more network devices to the computing system.