Canonical Observability Stack

Highly-integrated, low-operations observability stack powered by Juju and Microk8s.

The Canonical Observability Stack gathers, processes, visualizes and alerts on telemetry signals generated by workloads running both within, and outside of, Juju.

By leveraging the topology model of Juju to contextualize the data, and charm relations to automate configuration and integration, it provides a low-ops observability suite based on best-in-class, open-source observability tools.

For Site-Reliability Engineers, Canonical Observability Stack provides a turn-key, out-of-the-box solution for improved day 2 operational insight.

Project and community

The Canonical Observability Stack is a member of the Ubuntu family. It’s an open source project that warmly welcomes community projects, contributions, suggestions, fixes and constructive feedback.

Thinking about using the Canonical Observability Stack for your next project? Get in touch!

Navigation

Navigation
Level Path Navlink
0 overview Overview
0 Tutorials
1 install/microk8s Getting started on MicroK8s
0 Explanation
1 what-is-observability What is observability?
1 editions/lite COS Lite
1 editions/ha COS High-Availability
1 juju-topology Juju topology
1 design-goals Design Goals
1 model-driven-observability-tag Model-Driven Observability

Redirects

Mapping table
Path Location
/topics/canonical-observability-stack/on MicroK8s /topics/canonical-observability-stack/install/microk8s
/topics/canonical-observability-stack/on%20MicroK8s /topics/canonical-observability-stack/install/microk8s
3 Likes

Updated article to reflect the renaming of LMA Light to COS Lite

This is very interesting. Would you consider running a demo in the community workshop on this? @tmihoc @hallback @anvial @mmrezaie @emcp would perhaps also be interested.

A questions is how Nagios comes in here, or if it isn’t? I’d love to know what I should include in my own charms to quickly get support from your stack here. What interfaces/relations I should provide etc.

2 Likes

I definitely think we can arrange a community demo :slight_smile:

About Nagios: Nagios itself is not in the picture. Alerts are generated by Prometheus or Loki. The NRPE checks embedded in current charms are supported through an adaptor charm, the cos-proxy operator, that implements the nrpe-external-master and similar LMA relations, including many of those supported by the Prometheus 2 charm. It runs a Prometheus nrpe-exporter and we will then define rules in Prometheus to raise alerts when checks go bad. The alerts are routed to Alertmanager and, from there, pretty much wherever you want :slight_smile:

In general our goal is very much to provide a smooth transition for charms supporting previous relations, as well as provide more consistent relation interfaces going forward.

1 Like

This is super interesting!

How about you run the show in two weeks?

I would love to learn how to work with this as I can see many scenarios where it will work.

Does it require me to know K8?

We’ll work with the folks that organise the community hours to see which slot works.

In terms of having to know K8s: not really. We are developing COS as an appliance, which you should not have much to fumble with, and the abstractions we are exposing to the Juju admin do not seem leaky. But it would actually be an excellent datapoint to get the opinion of someone on that who is not deeply marinated in Kubernetes the way I am :slight_smile:

4 Likes

Why don’t you let us try it in the community with your guidance?

If we succeed = :grinning:

If we fail = :grinning_face_with_smiling_eyes:

We have not been yet diligent to a sufficient degree in documenting the various moving parts :slight_smile:

But we are developing in the open and are looking forward to feedback, so please by all means do: Deploy Canonical Observability Stack Lite using Charmhub - The Open Operator Collection