Canonical Observability Stack Proxy

  • Canonical Observability
Channel Revision Published Runs on
latest/stable 119 23 Sep 2024
Ubuntu 22.04 Ubuntu 20.04
latest/stable 117 23 Sep 2024
Ubuntu 22.04 Ubuntu 20.04
latest/stable 120 23 Sep 2024
Ubuntu 22.04 Ubuntu 20.04
latest/stable 118 23 Sep 2024
Ubuntu 22.04 Ubuntu 20.04
latest/candidate 119 23 Sep 2024
Ubuntu 22.04 Ubuntu 20.04
latest/candidate 117 23 Sep 2024
Ubuntu 22.04 Ubuntu 20.04
latest/candidate 120 23 Sep 2024
Ubuntu 22.04 Ubuntu 20.04
latest/candidate 118 23 Sep 2024
Ubuntu 22.04 Ubuntu 20.04
latest/beta 119 06 Sep 2024
Ubuntu 22.04 Ubuntu 20.04
latest/beta 117 06 Sep 2024
Ubuntu 22.04 Ubuntu 20.04
latest/beta 120 06 Sep 2024
Ubuntu 22.04 Ubuntu 20.04
latest/beta 118 06 Sep 2024
Ubuntu 22.04 Ubuntu 20.04
latest/edge 120 09 Aug 2024
Ubuntu 22.04 Ubuntu 20.04
latest/edge 119 09 Aug 2024
Ubuntu 22.04 Ubuntu 20.04
latest/edge 118 09 Aug 2024
Ubuntu 22.04 Ubuntu 20.04
latest/edge 117 09 Aug 2024
Ubuntu 22.04 Ubuntu 20.04
1.0/stable 54 16 Feb 2024
Ubuntu 22.04 Ubuntu 20.04
1.0/candidate 54 12 Dec 2023
Ubuntu 22.04 Ubuntu 20.04
1.0/beta 54 12 Dec 2023
Ubuntu 22.04 Ubuntu 20.04
1.0/edge 54 12 Dec 2023
Ubuntu 22.04 Ubuntu 20.04
juju deploy cos-proxy --channel edge
Show information

Platform:

Ubuntu
22.04 20.04

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 improve this document in the forum (guidelines). Last updated 8 months ago.