JarCasting
JarCasting JarCasting

Cellery Observability Components - Orbit

WSO2 is an open source application development software company focused on providing service-oriented architecture solutions for professional developers.

License

License
GroupId

GroupId

io.cellery.observability
ArtifactId

ArtifactId

io.cellery.observability.orbit
Last Version

Last Version

0.2.2
Release Date

Release Date
Type

Type

pom
Description

Description

Cellery Observability Components - Orbit
WSO2 is an open source application development software company focused on providing service-oriented architecture solutions for professional developers.
Project Organization

Project Organization

WSO2

Download io.cellery.observability.orbit

Filename Size
io.cellery.observability.orbit-0.2.2.pom 1 KB
Browse

How to add to project

<!-- https://jarcasting.com/artifacts/io.cellery.observability/io.cellery.observability.orbit/ -->
<dependency>
    <groupId>io.cellery.observability</groupId>
    <artifactId>io.cellery.observability.orbit</artifactId>
    <version>0.2.2</version>
    <type>pom</type>
</dependency>
// https://jarcasting.com/artifacts/io.cellery.observability/io.cellery.observability.orbit/
implementation 'io.cellery.observability:io.cellery.observability.orbit:0.2.2'
// https://jarcasting.com/artifacts/io.cellery.observability/io.cellery.observability.orbit/
implementation ("io.cellery.observability:io.cellery.observability.orbit:0.2.2")
'io.cellery.observability:io.cellery.observability.orbit:pom:0.2.2'
<dependency org="io.cellery.observability" name="io.cellery.observability.orbit" rev="0.2.2">
  <artifact name="io.cellery.observability.orbit" type="pom" />
</dependency>
@Grapes(
@Grab(group='io.cellery.observability', module='io.cellery.observability.orbit', version='0.2.2')
)
libraryDependencies += "io.cellery.observability" % "io.cellery.observability.orbit" % "0.2.2"
[io.cellery.observability/io.cellery.observability.orbit "0.2.2"]

Dependencies

There are no dependencies for this project. It is a standalone project that does not depend on any other jars.

Project Modules

  • gogoproto-java
  • grpc
  • protobuf

Mesh Observability

Build Status GitHub (pre-)release GitHub (Pre-)Release Date GitHub last commit License

Note: If you just wish to get started with trying out Cellery, you can start your journey at wso2/cellery repository.

Cellery Observability brings along the capability to observe the Instances deployed on Cellery Mesh. This combines the Siddhi Stream Processing Capabilities of WSO2 Stream Processor and observability agents deployed along with the Instances to collect and process metrics and tracing data from the Instances.

High Level Architecture

Cellery Observability Architecture Diagram

The observability data such as telemetry and request traces is collected from all the components that participated in the data flow.

  • Global Gateway
  • Cell Gateway
  • Sidecars (Envoy)
  • Components of Instances (E.g: Microservices)

All collected data will be processed by WSO2 Stream processor, and will be stored in the database to show the historical information. By default, the Cellery Mesh is deployed with MySQL database, and hence the telemetry data is also stored in the same database server.

The Observability Portal can depict the below information. It will show the current status of the mesh, and also the historical view by selecting the preferred time range.

  • Distributed Tracing (Request based latency analysis by each component)
    • Timeline view
    • Sequence diagram view
    • Request flow diagram view
  • Metrics
    • Application Metrics (Success/Failure rate, Request/sec, Response/sec, Response time)
      • Data Plane
        • Instance based metrics
        • Component based metrics
        • Overall Deployment based metrics
    • System Metrics
      • Data Plane & Control Plane
        • CPU, Memory, Disk Consumption.
        • Network Usage
  • Runtime Dependency Model
    • Dependency models of Instances and Components

Repo Structure

The Mesh Observability Code is structured as shown below.

cellery-observability
  ├── components
  │     └── global
  │           ├── core (Core components of Observability)
  │           └── portal (Observability Portal)
  └── docker
        ├── sp (Stream Processor Docker image)
        └── portal (Observability Portal Docker Image)

Contribute to Cellery Mesh Observability

The Cellery Team is pleased to welcome all contributors willing to join with us in our journey.

Build from Source

Prerequisites

To get started with building Cellery Mesh Observability, the following are required.

  • Docker
  • JDK 1.8+
  • Node & NPM
  • Maven
  • GNU Make 4.1+

Steps to Build

This repository’s build is mainly powered by Apache Maven. Also, a proper build can be triggered through Make.

To get started, first clone the repository and run the following command from the root of the project.

make all

This will build all the modules in the repository and docker images using the build artifacts. Afterwards, if you wish to push the docker images to the repository, run the following command.

Note: You need to login to Docker before running this command.

make docker-push

If you wish to customize the build you can add the following Environment Variables.

Environment Variable
DOCKER_REPO The name of the repository of the Docker images
DOCKER_IMAGE_TAG The tag of the Docker images

Issue Management

Cellery Mesh Observability issue management is mainly handled through GitHub Issues. Please feel free to open an issue about any question, bug report or feature request that you have in mind. (If you are unclear about where your issue should belong to, you can create it in Cellery SDK.)

We also welcome any external contributors who are willing to contribute. You can join a conversation in any existing issue and even send PRs to contribute. However, we suggest to start by joining into the conversations and learning about Cellery Mesh Observability as the first step.

Each issue we track has a variety of metadata which you can select with labels:

  • Type: This represents the kind of the reported issues such as Bug, New Feature, Improvement, etc.
  • Priority: This represents the importance of the issue, and it can be scaled from High to Normal.
  • Severity: This represents the impact of the issue in your current system. If the issue is blocking your system, and it’s having an catastrophic effect, then you can mark is ‘Blocker’. The ‘Blocker’ issues are given high priority as well when we are resolving the issues.

Apart from the information provided above, the issue template added to the repository will guide you to describe the issue in detail so that we can analyze and work on the resolution towards it. We would appreciate if you could fill most of the fields as possible when you are creating the issue. We will evaluate issues based on the provided details and labels, and will allocate them to the Milestones.

Versions

Version
0.2.2
0.1.0