Key Concepts

OneOps is a multi-cloud application orchestrator. It lets you design your application in a cloud agnostic way (by abstracting multiple cloud providers) and manages your application’s design, deployments, operations & monitoring. Check out the list of supported cloud providers.

Architecture Overview

OneOps includes a self service portal for users to administer the applications, has a back end automation engine to support complete application life cycle management.

OneOps has a back end loop to monitor resources and can trigger auto-repairs, auto-scales or notifications

System Architecture

The diagram below depicts a detailed system architecture .

Web App aka display

• Self service portal for managing applications, clouds, organization,services.
• Rest based API’s to do almost anything which can be done on UI.

• Can be integrated with sign on from AD

• source

CLI

Command line ruby gem for managing almost all aspects of OneOps.

• source

User DB

User schema to manage users, organization.

Packer/Circuit

Its a ruby based gem which is responsible for loading packs.

• source

CMS API aka adapter

Java based rest api to manage model, assemblies, environment.

• source

Transistor

Transistor is core web application responsible for creating design, deployment plan, comparing whats deployed to whats intended conforming to pack, user changes to configuration on design or Transistor..

• source

DAQ

DAQ provides rest apis to get data collected via collectors. Used for graphing monitor details in UI.

• source

Antenna

Antenna is responsible for persisiting/serving OneOps notifications into Cassandra db and distribute them to the configured Notification Sinks.

• source

Configuration Management Database

• System of records for all assemblies,enviroments,deployments.

• source

Transmitter (Publisher)

This component tracks the CMS changes and post the events on the messaging bus.

• source

Perfdata

We store metrics collected from back end into Cassandra

Elastic Search

Elastic search is used to store notifications generated from OneOps and deployment logs are stored.

Search

All cms,controller events and notifications are fed into elastic search which helps in implementing

• Policy
• Cost

• Deployment/Release histories.

• source

Message Bus

OneOps uses apache active mq as messaging layer for internal internal communication between components.

Sensor

Sensor consumes metrics coming from collector and generate events if thresholds violations are detected and generate Ops events. Esper based CEP to detect monitor thresholds violations

• source

Opamp

Its an OneOps event processor to trigger auto-healing, auto-replace,or generate notifications.

• source

Collector

Its a Logstash collector which collect metrics from managed instances in OneOps.

• source

Controller

Its an activiti based workflow engine responsible for distributing OneOps work orders and action orders.

• source

Inductor

The Inductor consumes WorkOrders or ActionOrders from a queue by zone, executes them and posts a result message back to the controller. It is written in Java and uses a Spring Listener Container and Apache Commons Exec for process execution.

Inductor can be installed via oneops-admin gem.

Workorders

A WorkOrder is a collection of managed objects that are used to add, update or delete a component.

ActionOrders

An ActionOrder is almost identical to a workorder, but instead of an rfcCi, it has only a CI. An ActionOrder is dispatched by the controller to run some action such as: reboot, repair, snapshot, restore, etc.