General overview

The 42ITy™ project promotes the global development, distribution and adoption of the 42ITy™ platform as a next generation Data Center Service Optimization enablement platform.

The goal is to serve developers, users and the entire data center ecosystem by providing a set of shared resources to grow the adoption of 42ITy™ as the only open source, next generation Data Center Service Optimization enablement platform.

The initial 42ITy™ platform is a result of more than 5 years of R&D effort by Eaton Corporation provided to the community. While Eaton continues to be a key contributor to 42ITy™, the community is already growing. Please read the Contributor guide to find out how you can contribute.

The 42ITy™ platform allows to connect together various software components to:

  • gather and store monitoring data from devices,

  • process these data to produce trends and metrics,

  • provide interaction to users, through a web user interface,

  • provide interaction to developers and 3rd party software, through a REST API.

Typical integrations, which serves as reference implementations, are Eaton Intelligent Power Manager 2 and Eaton Intelligent Power Controller:

Eaton Intelligent Power Controller

Current features and capabilities

  • Power device monitoring & metrics (rack PDUs, UPSs, ATSs,…)

  • Environmental monitoring & metrics (temp., humidity, dew point,…)

  • Historic & real time data

  • Composite & Datacenter or IT room level metrics

  • Open (REST API) communication interface

  • Micro-services & plug-in architecture

  • Simplified asset management

Future availability

  • Builds (images & packages) provided for both ARM and x86 platforms

  • Easy & Intuitive standards based UI (AngularJS, Bootstrap)

Future features and capabilities

  • Scale solution to large data center & distributed enterprise monitoring

    • 100s to 1000s of racks

  • Expanded 3rd party monitoring ecosystem

    • More 3rd party power device support

    • Genset monitoring

    • CRAC monitoring

    • 3rd party sensors

  • More depending on the 42ITy™ Community and partners feedback and requests.

Technical overview

Architecture

The 42ITy™ software platform is a Service Oriented Architecture (SOA), made of a collection of software packages. These package provide agents (micro services) which communicate through a MOM (Message-oriented middleware), built around the ZeroMQ technology stack.

The software is divided in a set of independent components, called agent.

42ITy SW architecture

Because we expect an arbitrary number of agents to be connected together, 42ITy™ uses a central message broker called Malamute.

Malamute is built using the same ZeroMQ stack, so integrates with the code easily. The purpose of malamute is to abstract from maintaining peer-to-peer connections and to allow easy 1:N communication patterns without need to change the agent side.

At the moment there are three main patterns supported by Malamute broker:

  • PUB / SUB, Publish and Subscribe: there are agents publishing messages with some topic, where others can subscribe to them. Broker then ensures all messages are delivered to the right destination. Communication is asynchronous - each PUB call is queued immediately and sending does not block the code.

  • REQ / REP, Request and Reply: this is a directed 1:1 communication, usable for requesting some information from known place (persistence layer). It is synchronous, so blocking calling code until there is a result (or timeout).

  • Service: service is a dedicated agent, which can run in more instances spawned by broker on demand. This is suitable for long running tasks. This is not used in 42ITy™ currently.

MQ protocol overview

42ITy™ protocol consists of several layers:

  • Internet layer - raw libzmq/czmq sockets: this ensures messages are serialized, deserialized, working with sockets and abstracts the underlying OS layers (unix sockets, tcp sockets, …).

  • Transport layer - Malamute: this does ensures correct addressing, matching subscribers with published messages and services.

  • Application layer - fty-proto: this provides a minimal set of messages to encode and decode the main types of data flowing in the system.

Refer to the project fty-proto for more information.

Dataflow overview

This chapter will be completed later.

Agent overview

Agents communicate through buses maintained by ZeroMQ library. Buses can use several backend technologies, most notably unix and classic TCP/IP sockets. So agents can be placed on the same machine or on arbitrary number of other machines (currently out of scope). Because basic messaging using zeromq messages (zmsg) is error prone with a lot of code duplication, 42ITy™ project uses serialization library called zproto. It defines a model of message in declarative XML language and code is generated using a template language called gsl.

Generated code does provide nice C API for manipulating with messages as well as a way how to encode/decode it to/from zmsg. Thus such generated representations can be easily sent through zeromq channels.

Actor model

Agents are built on top of the actor model. That means that each agent maintains its own state internally and communicate with the rest of the system by sending messages. The communication is asynchronous and agents are single threaded with the main loop. For cases where the single main loop is not enough due to performance reasons, agent can distribute workload to others using SERVICE pattern. However this is not used in current version of 42ITy™.

How to create a new agent

There are various ways to create a new 42ITy agent:

  • create from scratch: This is the hardest way, creating a zproject project.xml file. There are guides and tutorials which explains this, and are otherwise needed to further complete your agent.

  • fork one of the github example project, which provides instructions and serves as a reference on how to create a new 42ITy™:

REST API communication interface

42ITy™ also exposes its data through a REST API.

Complete documentation using RAML is available:

How to create a new REST API mountpoint

42ITy uses Tntnet webserver, which provides simple mechanisms to create new REST servlets.

There are tutorials, but you may also look at fty-rest and other fty-rest-* components as references.

You may fork the fty-template-rest repository.

42ITy™ software stack

42ITy™ external projects

42ITy™ foundations rely on several major opensource projects, to provide some generic core services, such as data storage, communication with devices, communication between agents, web user interface and REST API, and build added value on top of these.

Malamute

Malamute is the ZeroMQ Enterprise Messaging Broker, providing all the enterprise messaging patterns in one box.

42ITy™ uses Malamute as the broker connecting the different 42ITy™ agents (see internal sub-projects).

MariaDB - MySQL

MariaDB is one of the most popular database servers in the world, made by the original developers of MySQL and guaranteed to stay open source.

42ITy™ uses MariaDB to store the realtime data, gathered from devices, and processed metrics.

NUT - Network UPS Tools

NUT - Network UPS Tools is a project which provides support for a wide range of power devices, such as UPS, PDU and ATS.

42ITy™ uses NUT to gather data from network power devices.

Tntnet

Tntnet is a modular, multithreaded web application server for C++.

42ITy™ uses Tntnet to serve web user interface and REST API.

42ITy™ internal sub-projects

This chapter briefly presents the different sub-projects that forms the 42ITy™ platform. More detailed information can be found on the dedicated pages of these sub-projects.

Each of these sub-projects is available as a repository on 42ITy GitHub page, and provides a README file, with various information on its purpose, its provided services (through STREAMS) and data.

General projects

fty-core

  • Description: fty-core implements the core and central functionalities for 42ITy, by providing DB setup, OS integration and image creation scripts, …

  • Repository: https://github.com/42ity/fty-core

fty-proto

  • Description: fty-proto is the shared implementation of 42ITy™ core protocols, using Malamute and used by the different agents (assets, metrics, alerts).

  • Repository: https://github.com/42ity/fty-proto

fty-shm

Common libraries

fty-common

fty-common-db

fty-common-dto

fty-common-logging

fty-common-messagebus

fty-common-mlm

fty-common-nut

  • Description: fty-common-nut provides a common library to interact with NUT - Network UPS Tools, and interpret its provided data (including mapping between NUT and 42ITy variables).

  • Repository: https://github.com/42ity/fty-common-nut

fty-common-socket

fty-common-translation

fty-common-rest

Miscellaneous

fty-asset

fty-asset-activator

fty-info

fty-mdns-sd

fty-srr

Discovery, configuration and monitoring

fty-discovery

fty-nut

  • Description: fty-nut is an agent that polls power devices (UPS and PDU) using NUT drivers, through NUT server (upsd). It collects current measurements and publishes them. It also collects static inventory data (assets) and publishes them.

  • Repository: https://github.com/42ity/fty-nut

fty-sensor-env

fty-sensor-gpio

Metrics Generation & Processing

fty-metric-compute

fty-metric-ambient-location

fty-metric-tpower

fty-metric-composite

  • Description: fty-metric-composite is an agent that generates composite metrics, that is to say metrics which are computed from several other metrics. Rules are defined as scripts written in Lua.

  • Repository: https://github.com/42ity/fty-metric-composite

fty-kpi-power-uptime

  • Description: fty-kpi-power-uptime computes and publishes KPI (Key Performance Indicator) for data center power uptime, taking into account how long one of the main power sources was offline.

  • Repository: https://github.com/42ity/fty-kpi-power-uptime

fty-warranty

Real time and history data

fty-metric-cache

fty-metric-store

Alerts and notifications

fty-alert-engine

fty-alert-flexible

  • Description: fty-alert-flexible is the agent that evaluates non threshold based rules (status, advanced metrics, …) written in Lua and produces alerts accordingly.

  • Repository: https://github.com/42ity/fty-alert-flexible

fty-alert-list

fty-alert-stats

fty-email

fty-outage

Security

fty-security-wallet

fty-certificate-generator

fty-lib-certificate

REST API

fty-rest

Other REST servlets

The following servlets provide specific mountpoints and services:

Services dependencies

The systemd system and service manager is responsible for controlling how 42ITy™ services are started, stopped and otherwise managed. It uses an event-based and dependencies based approach to optimize how services are managed (started, stopped, reloaded).

The figure bellow illustrates the dependencies relationships for services running on 42ITy™.

42ITy services dependencies

Note
this needs refreshing and completion!

Packaging

Each project provides the necessary files to create binary packages for the main Linux distributions (Debian / Ubuntu, Redhat, Suse, …).

For example, here are fty-example packaging files for Debian

Note that 42ITy main focus being on Debian, the other packages integration may not be as optimal.

It’s beyond the scope of this document to describe how to create such packages. You may refer to the following documents:

As a basic example for fty-example on Debian, you may simply do:

$ cd fty-example
$ ln -s packaging/debian/
$ dpkg-buildpackage -us -uc

Creating a system image

To create a full system using 42ITy, you will need the following:

  • an operating system, including a kernel and bootloader. 42ITy is currently based on Debian GNU/Linux (version 8 or 10),

  • the set of 42ITy projects (agents and libraries), built into binary packages,

  • optionally, your own agents and software.

Basically, you just need to:

Tools like Multistrap or OBS may help you to arrange and automate images production using the above information.