Canonical Observability Stack Proxy

  • By Canonical Observability
Channel Revision Published Runs on
latest/stable 30 24 Mar 2023
Ubuntu 22.04 Ubuntu 20.04
latest/candidate 46 11 Sep 2023
Ubuntu 22.04 Ubuntu 20.04
latest/beta 46 11 Sep 2023
Ubuntu 22.04 Ubuntu 20.04
latest/edge 46 11 Aug 2023
Ubuntu 22.04 Ubuntu 20.04
1.0/stable 30 24 Mar 2023
Ubuntu 22.04 Ubuntu 20.04
1.0/candidate 46 11 Sep 2023
Ubuntu 22.04 Ubuntu 20.04
1.0/beta 46 11 Sep 2023
Ubuntu 22.04 Ubuntu 20.04
1.0/edge 46 11 Sep 2023
Ubuntu 22.04 Ubuntu 20.04
juju deploy cos-proxy
Show information

Platform:

Ubuntu
22.04 20.04

COS Proxy Operator

Welcome to the Canonical Observability Stack Operator documentation!

This Charmed Operator handles instantiation, scaling, configuration, optimisation, networking, service mesh, observability, and Day 2 operations specific to cos-proxy-operator.

The Canonical Observability Stack (Lite) provides an all-in-one solution for provisioning an observability stack on MicroK8s or any other Kubernetes cloud supported by Juju. The COS Lite stack is designed around the principle of model-driven observability, and Charmed Operators which follow this pattern can automatically infer useful labels for observability.

The goal of the cos-proxy operator is to provide a bridge between Reactive charms which integrated with the Reactive Prometheus, Grafana, and Nagios charms, enabling a zero-configuration migration path to COS Lite.

Once deployed in a Reactive/machine Juju model, cos-proxy transparently ties things together, so you can migrate your environment.

Getting started

Basic deployment

Deploy Canonical Observability Stack (Lite) on a model backed by Kubernetes, then deploy the cos-proxy operator in a reactive/machine model from which you would like to collect observability data.

The cos-proxy operator is designed to work with cross-model relations, so the first step is to establish those:

juju offer cos.prometheus:metrics-endpoint
juju offer cos.grafana:grafana-dashboard

juju consume cos.prometheus
juju consume cos.grafana

Next, deploy the cos-proxy operator in a reactive model:

juju deploy -m reactive cos-proxy-operator --channel=beta

For any charm which may export:

  • Grafana dashboards
  • Prometheus metrics endpoints
  • Prometheus alert rules
  • NRPE jobs

You may relate them to cos-proxy. “Topology” for model-driven observability will be automatically injected into Prometheus labels and Alert rule expressions.

NRPE jobs are checked via nrpe_exporter, which provides a Prometheus-compatible HTTP endpoint which knows how to speak to NRPE.

For example:

❯ juju status -m dash --color --relations
Model  Controller  Cloud/Region       Version  SLA          Timestamp
reactive   overlord    lxdremote/default  2.9.22   unsupported  16:43:14Z

SAAS        Status  Store     URL
grafana     active  overlord  admin/cos.grafana
prometheus  active  overlord  admin/cos.prometheus

App        Version  Status  Scale  Charm      Store       Channel  Rev  OS      Message
cos-proxy           active      1  cos-proxy  local                 14  ubuntu  
memcached           active      1  memcached  charmstore  stable    34  ubuntu  Unit is ready
nagios              active      1  nagios     charmstore  stable    46  ubuntu  ready
nrpe                active      2  nrpe       charmstore  stable    75  ubuntu  Ready (source version/commit cs-nrpe-...)
telegraf            active      1  telegraf   charmstore  stable    44  ubuntu  Monitoring ubuntu/0 (source version/commit 26e531a)
ubuntu     20.04    active      1  ubuntu     charmstore  stable    18  ubuntu  

Unit           Workload  Agent  Machine  Public address  Ports          Message
cos-proxy/14*  active    idle   17       10.159.132.117                 
memcached/0*   active    idle   2        10.159.132.52   11211/tcp      Unit is ready
  nrpe/1       active    idle            10.159.132.52   icmp,5666/tcp  Ready (source version/commit cs-nrpe-...)
nagios/0*      active    idle   1        10.159.132.207  80/tcp         ready
ubuntu/0*      active    idle   0        10.159.132.173                 
  nrpe/0*      active    idle            10.159.132.173  icmp,5666/tcp  Ready (source version/commit cs-nrpe-...)
  telegraf/6*  active    idle            10.159.132.173  9103/tcp       Monitoring ubuntu/0 (source version/commit 26e531a)

Machine  State    DNS             Inst id         Series  AZ  Message
0        started  10.159.132.173  juju-dda879-0   focal       Running
1        started  10.159.132.207  juju-dda879-1   bionic      Running
2        started  10.159.132.52   juju-dda879-2   focal       Running
17       started  10.159.132.117  juju-dda879-17  focal       Running

Relation provider                       Requirer                     Interface              Type         Message
cos-proxy:downstream-prometheus-scrape  prometheus:metrics-endpoint  prometheus_scrape      regular      
memcached:cluster                       memcached:cluster            memcached-replication  peer         
memcached:juju-info                     nrpe:general-info            juju-info              subordinate  
memcached:local-monitors                nrpe:local-monitors          local-monitors         subordinate  
memcached:monitors                      cos-proxy:monitors           monitors               regular      
memcached:nrpe-external-master          nrpe:nrpe-external-master    nrpe-external-master   subordinate  
nrpe:monitors                           cos-proxy:monitors           monitors               regular      
nrpe:monitors                           nagios:monitors              monitors               regular      
ubuntu:juju-info                        nrpe:general-info            juju-info              subordinate  
ubuntu:juju-info                        telegraf:juju-info           juju-info              subordinate  

Note: “system”-level NRPE jobs, such as check_conntrack are exposed on the monitors interface, while “charm”-level jobs specific to the workload are exposed on the local-monitors interface, and may not be provisioned until a nrpe-external-master relation is established.

To accurately pull all NRPE jobs from a charm, all of these relations should be established. This is an identical user experience to the nrpe charm, but it’s documented here for completeness.


Help us improve this documentation

Most of this documentation can be collaboratively discussed and changed on the respective topic in the doc category of the Charmhub forum. See the documentation guidelines if you’d like to contribute.

Last updated 6 months ago. Help improve this document in the forum.