Облачная экосистема

Важным критерием обеспечения бесперебойной работы является контроль свободного места. Так, если места не останется, то база данных не сможет записывать данные, с другими компонентами ситуация может быть более плачевная, чем потеря новых данных. В Docker есть настройки лимитов не только для отдельных контейнеров, минимум 10%. Во время создания образа или запуска контейнера может быть выброшена ошибка о том, что заданные пределы превышены. Для изменения настроек по умолчанию нужно указать серверу Dockerd настройки, предварительно его остановив service docker stop (все контейнера будут остановлены) и после возобновив его работу service docker start (работа контейнеров будет возобновлена). Настройки можно задать как параметры /bin/dockerd –storange-opt dm.basesize=50G –stirange-opt

В Container мы имеем авторизацию, контроль наши контейнеров, с возможностью для теста их создавать и видеть графики по процессору и памяти. Для большего потребуется система мониторинга. Систем мониторинга довольно много, например, Zabbix, Graphite, Prometheus, Nagios, InfluxData, OkMeter, DataDog, Bosum, Sensu и другие, из которых наиболее популярны Zabbix и Prometheus (промисиус). Первый, традиционно применяется, так как является лидирующим средством деплоя, который полюбился админам за простоту использования (достаточно только иметь SSH доступ к серверу), низкоуровненность, позволяющий работать не только с серверами, но и другим железом, таким как роутеры. Второй же является противоположностью первого: он заточен исключительно на сбор метрик и мониторинг, ориентирован как готовое решение, а не фреймворк и полюбился программистам, по принципу поставил, выбрал метрики и получил графики. Ключевой особенностью между Zabbix и Prometheus заключается не в предпочтениях одних детально настраивать под себя и других затрачивать намного меньше времени, а в сфере применения. Zabbix ориентирован на настройку работы с конкретным железом, которым может быть что угодно, и часто весьма экзотическим в корпоративной среде, и для этой сущности пишется сбор метрик вручную, вручную настраивается график. Для динамически меняющуюся среды облачных решений, даже если это просто контейнера Docker, и тем более, если это Kubernetes, в которой постоянно создаются огромное количество сущностей, а сами сущности в отрыве от общей среды не имеют особого интереса он не подходит, для этого в Prometheus встроен Service Discovery и для Kubernetes поддерживается навигация через название области видимости (namespace), балансера (service) и группы контейнеров (POD), которую можно настроить в Grafana виде таблиц. В Kubernetes, по данным The News Stack 2017 Kubernetes UserиExperience, используется в 63% случаев, в остальных более редкие облачные средства мониторинга.

Метрики бывают системные (например, CRU, RAM, ROM) и прикладные (метрики сервисов и приложений). Системные метрики – метрики ядра, которые используются Kubernetes для масштабирования и тому подобного и метрики non-core, который не используются Kubernetes. Приведу пример связок сбора метрик:

* cAdvisor + Heapster + InfluxDB

* cAdvisor + collectd + Heapster

* cAdvisor + Prometheus

* snapd + Heapster

* snapd + SNAP cluster-level agent

* Sysdig

На рынке много систем мониторинга и сервисов. Мы рассмотрим именно OpenSource, которые можно установить в свой кластер. Их разделить можно по модели получения метрик: на тех, которые забирают логи опрашивая, и на тех, кто ожидает, что в них отравят метрики. Вторые более просты, как по структуре, так и по использования в малых масштабах. Примером может быть InfluxDB, представляющий из себя базу данных, в которую можно писать. Минусом подобного решения является сложность масштабирования как по поддержки, так и по нагрузке. Если все сервисы будут одновременно писать, то они могут перегрузить систему мониторинга тем более, что её сложно масштабировать, так эндпойтн прописан в каждом сервисе. Представителем первой группы, исповедующей pull-модель взаимодействия, является Prometheus. Он также представляет из себя базу данных с демоном, который опрашивает сервисы на основе их регистраций в файле конфигураций и стягивает метки в определённом формате, например:

cpu_usage: 2

cpu_usage{app: myapp} : 2

Prometheus – зрелый продукт, он разработан в 2012, а в 2016 включён в составе консорта CNCF (Cloud Native Computing Foundation). Prometheus состоит из:

* TSDB (Time Series Satabase) базы данных, которая больше напоминает очередь хранения метрик, с заданным периодом накопления, например, недели, позволяющая обрабатывать сотни тысяч метрик в секунду. Данная база локальна для Prometheus, не поддерживает горизонтального масштабирование, в случае с Prometheus оно достигается с помощью поднятием нескольких его инстансев и шардированием их. Prometheus поддерживает агрегацию данных, что полезно для снижения объёма накопленных данных, а также архивирование базы данных из памяти на диск.

* Service Discovery поддерживать Kubernetes в коробке через публичное API через опрашивание POD, отфильтрованных в соответствии с конфигом по 9121 порту TPC.

* Grafana (отдельный продукт, по умолчанию добавляемый) – универсальное UI с дашбордами и графиками, поддерживающее Prometheus через PromQL.

Для отдачи метрик можно воспользоваться готовыми решениями или разработать свои. Для подавляющего большинства системных метрик существуют exporter, а для прикладных, часто приходится отдавать свои метрики. Экспортёры бывают общие и специализированные. Например, NodeExporter предоставляет большинство метрик, в том числе и по процессам, но их два, а специализированный на них – больше. Если запустить Prometheus без экспортёров, то он выдаст почти тысячу метрик, но это метрики самого Prometheus, и там не будет приставок в них node_*. Чтобы появились эти метрики, нужно включить NodeExporter и прописать в конфигурации Prometheus URL к нему, для сбора предоставляемых им метрикам. Для NodeExporter это может быть localhost или адрес ноды и порт 9256. Обычно, экспортёры специализируются на метриках конкретных продуктов, например:

** node_exporter – метрики нод (CRU, Memory, Network);

** snmp_exporter – метрики протокола SNMP;

** mysqld_exporter – метрики базы данных MySQL;

** consul_exporter – метрики базы данных Consul;

** graphite_exporter – метрики базы данных Graphite;

** memcached_exporter – метрики базы данных Memcached;

** haproxy_exporter – метрики балансировщика HAProxy;

** CAdvisor – метрики контейнеров;

** process-exporter – детальные метрики процессов ;

** metrics-server – CRU, Memory, File-descriptors, Disks;

** cAdvisor – a Docker daemon metrics – containers monitoring;

** kube-state-metrics – deployments, PODs, nodes.

Prometheus поддерживает удалённую запись данных (https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_write), например в распределённое хранилище TSDB для Prometheus – Weave Works Cortex, используя настройку в конфигурации, что позволяет анализировать данные с нескольких Prometheus:

remote_write:

– url: "http://localhost:9000/receive"

Рассмотрим его работу на готовом инстансе. Я возьму для этого www.katacoda.com/courses/istio/deploy-istio-on-kubernetes и пройду его. Наш Prometheus располагается на стандартном для него порту 9090:

controlplane $ kubectl -n istio-system get svc prometheus

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

prometheus ClusterIP 10.99.70.170 < none> 9090/TCP 6m59s

Чтобы открыть его UI, я перейду на WEB-вкладку и изменю в адресе 80 на 9090: https://2886795314-9090-ollie08.environments.katacoda.com/graph. В строке ввода нужно вводить желаемую метрику на языке PromQL (Prometheus query language), также как и InfluxQL для InfluxDB и SQL для TimescaleDB. Для примера я введу «CRU», и он мне отобразит список его содержащий. Под строкой содержатся две вкладки: вкладка с графиком и вкладка для отображения в табличном виде. Я буду смотреть на табличное представление. Я выбрал machine_cru_cores и нажал Execute. Распространённые метрики, обычно имеют схожие названия, например, machine_cru_cores и node_cru_cores. Сами метрики состоят из названия, тегов в скобочках и значения метрики, в таком же виде их и нужно запрашивать, в таком же виде они и отображаются в таблице.

machine_cpu_cores{beta_kubernetes_io_arch="amd64",beta_kubernetes_io_os="linux",instance="controlplane",job="kubernetes-cadvisor",kubernetes_io_arch="amd64",kubernetes_io_hostname="controlplane",kubernetes_io_os="linux"} 2

machine_cpu_cores{beta_kubernetes_io_arch="amd64",beta_kubernetes_io_os="linux",instance="node01",job="kubernetes-cadvisor",kubernetes_io_arch="amd64",kubernetes_io_hostname="node01",kubernetes_io_os="linux"} 2

Если в сети MEMORY – то можно выбрать machine_memory_bytes – размер оперативной памяти на машине (сервере или виртуальной):

machine_memory_bytes{beta_kubernetes_io_arch="amd64",beta_kubernetes_io_os="linux",instance="controlplane",job="kubernetes-cadvisor",kubernetes_io_arch="amd64",kubernetes_io_hostname="controlplane",kubernetes_io_os="linux"} 2096992256

machine_memory_bytes{beta_kubernetes_io_arch="amd64",beta_kubernetes_io_os="linux",instance="node01",job="kubernetes-cadvisor",kubernetes_io_arch="amd64",kubernetes_io_hostname="node01",kubernetes_io_os="linux"} 4092948480

Но в байтах ненаглядно, поэтому воспользуемся PromQL для перевода в Gb: machine_memory_bytes / 1000 / 1000 / 1000

{beta_kubernetes_io_arch="amd64",beta_kubernetes_io_os="linux",instance="controlplane",job="kubernetes-cadvisor",kubernetes_io_arch="amd64",kubernetes_io_hostname="controlplane",kubernetes_io_os="linux"} 2.096992256

{beta_kubernetes_io_arch="amd64",beta_kubernetes_io_os="linux",instance="node01",job="kubernetes-cadvisor",kubernetes_io_arch="amd64",kubernetes_io_hostname="node01",kubernetes_io_os="linux"} 4.09294848

Введём для memory_bytes для поиска container_memory_usage_bytes – использованной памяти. Список содержит все контейнера и текущее потребление ими памяти, я приведу только три:

container_memory_usage_bytes{beta_kubernetes_io_arch="amd64",beta_kubernetes_io_os="linux",container="POD",container_name="POD",id="/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-pod0e619e5dc53ed9efcef63f5fe1d7ee71.slice/docker-b6549e892baa8687e4e98a106024b5c31a4af077d7c5544af03a3c72ec8997e0.scope",image="k8s.gcr.io/pause:3.1",instance="controlplane",job="kubernetes-cadvisor",kubernetes_io_arch="amd64",kubernetes_io_hostname="controlplane",kubernetes_io_os="linux",name="k8s_POD_etcd-controlplane_kube-system_0e619e5dc53ed9efcef63f5fe1d7ee71_0",namespace="kube-system",pod="etcd-controlplane",pod_name="etcd-controlplane"} 45056

container_memory_usage_bytes{beta_kubernetes_io_arch="amd64",beta_kubernetes_io_os="linux",container="POD",container_name="POD",id="/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-pod5a815a40_f2de_11ea_88d2_0242ac110032.slice/docker-76711789af076c8f2331d8212dad4c044d263c5cc3fa333347921bd6de7950a4.scope",image="k8s.gcr.io/pause:3.1",instance="controlplane",job="kubernetes-cadvisor",kubernetes_io_arch="amd64",kubernetes_io_hostname="controlplane",kubernetes_io_os="linux",name="k8s_POD_kube-proxy-nhzhn_kube-system_5a815a40-f2de-11ea-88d2-0242ac110032_0",namespace="kube-system",pod="kube-proxy-nhzhn",pod_name="kube-proxy-nhzhn"} 45056

container_memory_usage_bytes{beta_kubernetes_io_arch="amd64",beta_kubernetes_io_os="linux",container="POD",container_name="POD",id="/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-pod6473aeea_f2de_11ea_88d2_0242ac110032.slice/docker-24ef0e898e1bb7dec9854b67291171aa9c5715d7683f53bdfc2cef49a19744fe.scope",image="k8s.gcr.io/pause:3.1",instance="node01",job="kubernetes-cadvisor",kubernetes_io_arch="amd64",kubernetes_io_hostname="node01",kubernetes_io_os="linux",name="k8s_POD_kube-proxy-6v49x_kube-system_6473aeea-f2de-11ea-88d2-0242ac110032_0",namespace="kube-system",pod="kube-proxy-6v49x",pod_name="kube-proxy-6v49x"} 835584

Выставим метку, которая содержится в метриках, чтобы отфильтровать один: container_memory_usage_bytes{container_name="prometheus"}

container_MEMORY_usage_bytes{beta_Kubernetes_io_arch="amd64",beta_Kubernetes_io_os="linux",container="prometheus",container_name="prometheus",id="/kubePODs.slice/kubePODs-burstable.slice/kubePODs-burstable-PODeaf4e833_f2de_11ea_88d2_0242ac110032.slice/Docker-b314fb5c4ce8894f872f05bdd524b4b7d6ce5415aeb3fb91d6048441c47584a6.scope",image="sha256:b82ef1f3aa072922c657dd2b2c6b59ec0ac88e69c447998291066e1f67e741d8",instance="node01",JOB="Kubernetes-cadvisor",Kubernetes_io_arch="amd64",Kubernetes_io_hostname="node01",Kubernetes_io_os="linux",name="k8s_prometheus_prometheus-5b77b7d695-knf44_istio-system_eaf4e833-f2de-11ea-88d2-0242ac110032_0",namespace="istio-system",POD="prometheus-5b77b7d695-knf44",POD_name="prometheus-5b77b7d695-knf44"}

283443200

Приведём в Mb: container_memory_usage_bytes {container_name="prometheus"} / 1000 / 1000

{beta_kubernetes_io_arch="amd64",beta_kubernetes_io_os="linux",container="prometheus",container_name="prometheus",id="/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podeaf4e833_f2de_11ea_88d2_0242ac110032.slice/docker-b314fb5c4ce8894f872f05bdd524b4b7d6ce5415aeb3fb91d6048441c47584a6.scope",image="sha256:b82ef1f3aa072922c657dd2b2c6b59ec0ac88e69c447998291066e1f67e741d8",instance="node01",job="kubernetes-cadvisor",kubernetes_io_arch="amd64",kubernetes_io_hostname="node01",kubernetes_io_os="linux",name="k8s_prometheus_prometheus-5b77b7d695-knf44_istio-system_eaf4e833-f2de-11ea-88d2-0242ac110032_0",namespace="istio-system",pod="prometheus-5b77b7d695-knf44",pod_name="prometheus-5b77b7d695-knf44"}

286.18752

Отфильтруем по container_memory_usage_bytes{container_name="prometheus", instance="node01"}

beta_kubernetes_io_arch="amd64",beta_kubernetes_io_os="linux",container="prometheus",container_name="prometheus",id="/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podeaf4e833_f2de_11ea_88d2_0242ac110032.slice/docker-b314fb5c4ce8894f872f05bdd524b4b7d6ce5415aeb3fb91d6048441c47584a6.scope",image="sha256:b82ef1f3aa072922c657dd2b2c6b59ec0ac88e69c447998291066e1f67e741d8",instance="node01",job="kubernetes-cadvisor",kubernetes_io_arch="amd64",kubernetes_io_hostname="node01",kubernetes_io_os="linux",name="k8s_prometheus_prometheus-5b77b7d695-knf44_istio-system_eaf4e833-f2de-11ea-88d2-0242ac110032_0",namespace="istio-system",pod="prometheus-5b77b7d695-knf44",pod_name="prometheus-5b77b7d695-knf44"}

289.890304

А на второй его нет: container_memory_usage_bytes{container_name="prometheus", instance="node02"}

no data

Есть и агрегатные функции sum(container_memory_usage_bytes) / 1000 / 1000 / 1000

{} 22.812798976

max(container_memory_usage_bytes) / 1000 / 1000 / 1000

{} 3.6422983679999996

min(container_memory_usage_bytes) / 1000 / 1000 / 1000

{} 0

Можно и сгруппировать по меткам instance: max(container_memory_usage_bytes) by (instance) / 1000 / 1000 / 1000

{instance="controlplane"} 1.641836544

{instance="node01"} 3.6622745599999997

Можно производить действия с однотипными метками и отфильтровывать: container_memory_mapped_file / container_memory_usage_bytes * 100 > 80

{beta_kubernetes_io_arch="amd64",beta_kubernetes_io_os="linux",container="POD",container_name="POD",id="/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pode45f10af1ae684722cbd74cb11807900.slice/docker-5cb2f2083fbc467b8b394b27b69686d309f951450bcb910d509572aea9922806.scope",image="k8s.gcr.io/pause:3.1",instance="controlplane",job="kubernetes-cadvisor",kubernetes_io_arch="amd64",kubernetes_io_hostname="controlplane",kubernetes_io_os="linux",name="k8s_POD_kube-controller-manager-controlplane_kube-system_e45f10af1ae684722cbd74cb11807900_0",namespace="kube-system",pod="kube-controller-manager-controlplane",pod_name="kube-controller-manager-controlplane"}

80.52631578947368

Посмотреть на метрики файловой системы можно с помощью container_fs_limit_bytes, который выдаёт большой список – приведу несколько из него:

container_fs_limit_bytes{beta_kubernetes_io_arch="amd64",beta_kubernetes_io_os="linux",container="POD",container_name="POD",device="/dev/vda1",id="/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-pod0e619e5dc53ed9efcef63f5fe1d7ee71.slice/docker-b6549e892baa8687e4e98a106024b5c31a4af077d7c5544af03a3c72ec8997e0.scope",image="k8s.gcr.io/pause:3.1",instance="controlplane",job="kubernetes-cadvisor",kubernetes_io_arch="amd64",kubernetes_io_hostname="controlplane",kubernetes_io_os="linux",name="k8s_POD_etcd-controlplane_kube-system_0e619e5dc53ed9efcef63f5fe1d7ee71_0",namespace="kube-system",pod="etcd-controlplane",pod_name="etcd-controlplane"}

253741748224

container_fs_limit_bytes{beta_kubernetes_io_arch="amd64",beta_kubernetes_io_os="linux",container="POD",container_name="POD",device="/dev/vda1",id="/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-pod5a815a40_f2de_11ea_88d2_0242ac110032.slice/docker-76711789af076c8f2331d8212dad4c044d263c5cc3fa333347921bd6de7950a4.scope",image="k8s.gcr.io/pause:3.1",instance="controlplane",job="kubernetes-cadvisor",kubernetes_io_arch="amd64",kubernetes_io_hostname="controlplane",kubernetes_io_os="linux",name="k8s_POD_kube-proxy-nhzhn_kube-system_5a815a40-f2de-11ea-88d2-0242ac110032_0",namespace="kube-system",pod="kube-proxy-nhzhn",pod_name="kube-proxy-nhzhn"}

253741748224

В нём присутствую метрики оперативной памяти через его устройство: "container_fs_limit_bytes{device="tmpfs"} / 1000 / 1000 / 1000"

{beta_kubernetes_io_arch="amd64",beta_kubernetes_io_os="linux",device="tmpfs",id="/",instance="controlplane",job="kubernetes-cadvisor",kubernetes_io_arch="amd64",kubernetes_io_hostname="controlplane",kubernetes_io_os="linux"} 0.209702912

{beta_kubernetes_io_arch="amd64",beta_kubernetes_io_os="linux",device="tmpfs",id="/",instance="node01",job="kubernetes-cadvisor",kubernetes_io_arch="amd64",kubernetes_io_hostname="node01",kubernetes_io_os="linux"} 0.409296896

Если мы хотим получить минимальный диск, то нам нужно из списка убрать устройство оперативной памяти: "min(container_fs_limit_bytes{device!="tmpfs"} / 1000 / 1000 / 1000)"

{} 253.74174822400002

Кроме метрик, указывающие само значение метрики, есть метрики счётчики. Их название, обычно, заканчиваются на "_total". Если их посмотреть, то мы увидим возрастающую линию. Чтобы получить значение, нам нужно получить разницу (с помощью функции rate) за период времени (указывается в квадратных скобках), примерно так rate(name_metric_total)[time]. Время, обычно ведётся в секундах или минутах. Для обозначения секунд используются приставка "s", например, 40s, 60s. Для минут – "m", например, 2m, 5m. Важно заметить, что нельзя устанавливать время, меньшее времени опроса exporter, иначе метрика не будет отображаться.

А посмотреть имена метрик, которые смог записать можно по пути /metrics:

controlplane $ curl https://2886795314-9090-ollie08.environments.katacoda.com/metrics 2>/dev/null | head

# HELP go_gc_duration_seconds A summary of the GC invocation durations.

# TYPE go_gc_duration_seconds summary

go_gc_duration_seconds{quantile="0"} 3.536e-05

go_gc_duration_seconds{quantile="0.25"} 7.5348e-05

go_gc_duration_seconds{quantile="0.5"} 0.000163193

go_gc_duration_seconds{quantile="0.75"} 0.001391603

go_gc_duration_seconds{quantile="1"} 0.246707852

go_gc_duration_seconds_sum 0.388611299

go_gc_duration_seconds_count 74

# HELP go_goroutines Number of goroutines that currently exist.

Поднятие связки Prometheus и Graphana

Мы рассмотрели метрики в уже настроенном Prometheus, теперь поднимем Prometheus и настроим его сами:

essh@kubernetes-master:~$ docker run -d –net=host –name prometheus prom/prometheus

09416fc74bf8b54a35609a1954236e686f8f6dfc598f7e05fa12234f287070ab

essh@kubernetes-master:~$ docker ps -f name=prometheus

CONTAINER ID IMAGE NAMES

09416fc74bf8 prom/prometheus prometheus

UI с графиками по отображению метрик:

essh@kubernetes-master:~$ firefox localhost:9090

Добавим метрику go_gc_duration_seconds{quantile="0"} из списка:

essh@kubernetes-master:~$ curl localhost:9090/metrics 2>/dev/null | head -n 4

# HELP go_gc_duration_seconds A summary of the GC invocation durations.

# TYPE go_gc_duration_seconds summary

go_gc_duration_seconds{quantile="0"} 1.0097e-05

go_gc_duration_seconds{quantile="0.25"} 1.7841e-05

Зайдя в UI по адресу localhost:9090 в меню выберем Graph. Добавим в дашборд с графиком: выбираем метрику с помощью списка – insert metrics at cursor. Здесь мы видим те же метрики, что и в списке localhost:9090/metrics, но агрегированные по параметрам, например, просто go_gc_duration_seconds. Мы выбираем метрику go_gc_duration_seconds и покажем её по кнопке Execute. Во вкладке console дашборда видим метрики:

go_gc_duration_seconds{instance="localhost:9090",JOB="prometheus",quantile="0"} 0.000009186 go_gc_duration_seconds{instance="localhost:9090",JOB="prometheus",quantile="0.25"} 0.000012056 go_gc_duration_seconds{instance="localhost:9090",JOB="prometheus",quantile="0.5"} 0.000023256 go_gc_duration_seconds{instance="localhost:9090",JOB="prometheus",quantile="0.75"} 0.000068848 go_gc_duration_seconds{instance="localhost:9090",JOB="prometheus",quantile="1"} 0.00021869

, перейдя во кладку Graph – графическое их представление.

Сейчас Prometheus собирает метрики с текущей ноды: go_*, net_*, process_*, prometheus_*, promhttp_*, scrape_* и up. Для сбора метрик с Docker кажем ему писать его метрики в Prometheus по порту 9323:

eSSH@Kubernetes-master:~$ curl http://localhost:9323/metrics 2>/dev/null | head -n 20

# HELP builder_builds_failed_total Number of failed image builds

# TYPE builder_builds_failed_total counter

builder_builds_failed_total{reason="build_canceled"} 0

builder_builds_failed_total{reason="build_target_not_reachable_error"} 0

builder_builds_failed_total{reason="command_not_supported_error"} 0

builder_builds_failed_total{reason="Dockerfile_empty_error"} 0

builder_builds_failed_total{reason="Dockerfile_syntax_error"} 0

builder_builds_failed_total{reason="error_processing_commands_error"} 0

builder_builds_failed_total{reason="missing_onbuild_arguments_error"} 0

builder_builds_failed_total{reason="unknown_instruction_error"} 0

# HELP builder_builds_triggered_total Number of triggered image builds

# TYPE builder_builds_triggered_total counter

builder_builds_triggered_total 0

# HELP engine_daemon_container_actions_seconds The number of seconds it takes to process each container action

# TYPE engine_daemon_container_actions_seconds histogram

engine_daemon_container_actions_seconds_bucket{action="changes",le="0.005"} 1

engine_daemon_container_actions_seconds_bucket{action="changes",le="0.01"} 1

engine_daemon_container_actions_seconds_bucket{action="changes",le="0.025"} 1

engine_daemon_container_actions_seconds_bucket{action="changes",le="0.05"} 1

engine_daemon_container_actions_seconds_bucket{action="changes",le="0.1"} 1

Чтобы демон докера применил параметры, его нужно перезапустить, что приведёт к падению всех контейнеров, а при старте демона контейнера будут подняты в соответствии с их политикой:

essh@kubernetes-master:~$ sudo chmod a+w /etc/docker/daemon.json

essh@kubernetes-master:~$ echo '{ "metrics-addr" : "127.0.0.1:9323", "experimental" : true }' | jq -M -f /dev/null > /etc/docker/daemon.json

essh@kubernetes-master:~$ cat /etc/docker/daemon.json

{

"metrics-addr": "127.0.0.1:9323",

"experimental": true

}

essh@kubernetes-master:~$ systemctl restart docker

Prometheus только отреагирует метрики на одном сервере от разных источников. Для того, чтобы мы могли собирать метрики с разных нод и видеть агрегированный результат, на каждую ноду нужно поставить агента, собирающего метрики:

essh@kubernetes-master:~$ docker run -d \

–v "/proc:/host/proc" \

–v "/sys:/host/sys" \

–v "/:/rootfs" \

–-net="host" \

–-name=explorer \

quay.io/prometheus/node-exporter:v0.13.0 \

–collector.procfs /host/proc \

–collector.sysfs /host/sys \

–collector.filesystem.ignored-mount-points "^/(sys|proc|dev|host|etc)($|/)"

1faf800c878447e6110f26aa3c61718f5e7276f93023ab4ed5bc1e782bf39d56

и прописать слушать адрес ноды, а пока у нас всё локально, localhost:9100. Теперь сообщим Prometheus слушать агента и докера:

essh@kubernetes-master:~$ mkdir prometheus && cd $_