Облачная экосистема
Важным критерием обеспечения бесперебойной работы является контроль свободного места. Так, если места не останется, то база данных не сможет записывать данные, с другими компонентами ситуация может быть более плачевная, чем потеря новых данных. В 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 $_
