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.

Why a new stack?

At Canonical, we have been referring to LMA as a system of machine charms currently in use to monitor Canonical and customer systems.

COS draws a lot of learning from years of operational experience with LMA, but it is also different enough that we felt we needed to make a distinction from the previous iteration.

Design goals

There are several design goals we want to accomplish with COS:

  • Provide a set of high-quality observability charmed operators that are designed to work well on their own, and better together.

  • Make COS run on Kubernetes, with specific focus on MicroK8s, to achieve a very “appliance-like” user experience.

  • Ensure a consistent, cohesive experience: all alerts go through Alertmanager, Grafana can plot all telemetry, etc.

  • Provide a highly-integrated observability stack with the simplest possible deployment experience.

  • Take the toil out of setting up monitoring of your Juju workloads: monitoring your Juju applications should be as simple as establishing a couple of relations with the COS charms.

  • Showcase the declarative power of the Juju model: for example, if some can be modelled as relation, rather that a configuration, it should be. Also, relations must be semantically meaningful: by looking at juju status --relations, you should intuitively understand what comes out of two charms relating with one another.

Further reading

The “What is observability?” page provides an overview of the relation between observability and monitoring. An overview of the Canonical offerings related to observability and monitoring can be found on the Observability page. COS will join those pages when it goes GA :slight_smile:

We have been keeping a sort of “development blog” as a series of blog posts about model-driven observability. Keep in mind that not everything that COS can do is already showcased in one of those blog entries, and we will provide proper documentation for COS both here and on the pages of the charms on

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!


Level Path Navlink
0 Introduction
1 overview Overview
0 Editions
1 editions/lite Lite
1 editions/ha High-Availability
0 Installation
1 install/microk8s COS Lite on MicroK8s
0 Concepts
1 juju-topology Juju topology


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

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.


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:


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