* CRI-O OpanSource проект, с самого начала нацеленный на полную поддержку стандартов CRI (Container Runtime Interface), github.com/opencontainers/runtime-spec/">Runtime Specification и github.com/opencontainers/image-spec">Image Specification как общего интерфейса взаимодействия системы оркестровки с контейнерами. Наряду c Docker, добавлена поддержка CRI-O 1.0 в Kubernetes (речь пойдёт дальше) с версии 1.7 в 2007, а также в MiniKube и Kubic. Имеет реализацию CLI (Common Line Interface) в проекте Pandom, практически полностью повторяющий команды Docker, но без оркестровки (Docker Swarm), который по умолчанию является инструментом в Linux Fedora.
* CRI (Kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-Kubernetes/">Container Runtime Interface) среда для запуска контейнеров, универсально предоставляющие примитивы (Executor, Supervisor, Metadata, Content, Snapshot, Events и Metrics) для работы с Linux контейнерами (пространствами процессов, групп и т.д.).
** CNI (Container Networking Interface) работа с сетью.
Portainer
Простейшим вариантом мониторинга будет Portainer:
essh@kubernetes-master:~/microKubernetes$ cat << EOF > docker-compose.monitoring.yml
version: '2'
>
services:
portainer:
image: portainer/portainer
command: -H unix:///var/run/Docker.sock
restart: always
ports:
9000:9000
volumes:
/var/run/Docker.sock:/var/run/Docker.sock
./portainer_data:/data
>
EOF
essh@kubernetes-master:~/microKubernetes$ docker-compose -f docker-compose.monitoring.yml up -d
Мониторинг с помощью Prometheus
Мониторинг поддержка непрерывности работы, отслеживание текущей ситуации (выявление, локализация и отправка об инциденте, например, в SaaS PagerDuty), прогнозирование возможных ситуаций, визуализация, построение моделей нормально работы IAOps (Artificial Intelligence For It Operations, https://www.gartner.com/en/information-technology/glossary/aiops-artificial-intelligence-operations).
Мониторинг содержит следующие этапы:
* выявление инцидента;
* уведомление о инциденте;
* локализация;
* решение.
Мониторинг можно классифицировать по уровню на следующие типы:
* инфраструктурный (операционная система, сервера, Kubernetes, СУБД), ;
* прикладной (логи приложений, трейсы, события приложений), ;
* бизнес-процессов (точки в транзакциях, трейсы транзакциях).
Мониторинг можно классифицировать по принципу:
* распределённый (трейсы), ;
* синтетический (доступность), ;
* IAOps (прогнозирование, аномалии).
Мониторинг делится на две части по степени анализа на системы логирования и системы расследования инцидентов. Примером логирования
служит ELK стек, а расследования инцидентов Sentry (SaaS). Для микро-сервисов добавляется ещё и система трассировки
запросов, такие как Jeger или Zipkin. Система логирования просто пишет все логи, которые доступны.
Система расследования инцидентов пишет гораздо больше информации, но пишет её только в случае ошибок в приложении, например,
параметры окружения, версии установленных пакетов, стек трейс и так далее, что позволяет при просмотре получить максимальную информацию
по ошибке, а не собрать её по кусочкам с сервера и GIT репозитория. Но набор и формат информации зависит от окружения, поэтому
системе инцидентов нужно иметь интеграцию с различными языковыми платформами, а ещё лучше с конкретными фреймворками. Так Sentry
отравляет переменные окружения, участок кода и указание в каком месте произошла ошибка, параметры программного и платформенного
окружения, вызовы методов.
Мониторинг по экосистеме можно разделить на:
* Встроенный в облако Cloud: Azure Monitoring, Amazon CloudWatch, Google Cloud Monitoring
* Предоставляющийся как сервис с поддержкой различных интеграций SaaS: DataDog, NewRelic
* CloudNative: Prometheus
* Для выделенных серверов OnPremis: Zabbix
Zabbix разработан в 1998 год и выведен в OpenSource под лицензией в GPL в 2001. Для того времени, традиционный интерфейс:
без какого-либо дизайна, с большим числом вкладок, селекторов и тому подобного. Так как он разрабатывался для
собственных нужд, то он содержит конкретные решения. Ориентирован он
на мониторинг устройств и их компонентов, таких как диски, сеть, принтеры, роутеры и тому подобного. Для
взаимодействия можно использовать:
Агенты устанавливаются на сервера, собирают множество метрик и отравляют Zabbix серверу
HTTP Zabbix делает запросы по http, например, принтеров
SNMP сетевой протокол для взаимодействия с сетевых устройств
IPMI протокол для взаимодействия с серверными устройствами, такими, как роутеры
В 2019 году Gratner представил рейтинг систем мониторинга в своём квадрате:
** Dynatrace;
** Cisco (AppDynamics);
** New Relic;
** Broadcom (CA Technologies);
** Riverbed и Microsoft;
** IBM;
** Oracle;
** SolarWinds;
** Micro Focus;
** ManageEngine и Tingyun.
** Dynatrace;
** Cisco (AppDynamics);
** New Relic;
** Broadcom (CA Technologies);
** Riverbed и Microsoft;
** IBM;
** Oracle;
** SolarWinds;
** Micro Focus;
** ManageEngine и Tingyun.
Не вошли в квадрат:
** Correlsense;
** Datadog;
** Elastic;
** Honeycomb;
** Instant;
** Jennifer Soft;
** Light Step;
** Nastel Technologies;
** SignalFx;
** Splunk;
** Sysdig.
Когда мы запускаем приложение в Docker контейнере, весь стандартный вывод (то, что выводится в консоли) запущенной программы (процесса) помещается в буфер. Этот буфер мы можем просмотреть программой docker logs name_container. Если мы следуем идеологии Docker "один процесс один контейнер" мы можем просматривать логи отдельной программы. Для просмотра логов удобно пользоваться командами less и tail. Первая программа позволяет удобно прокручивать лога стрелками клавиатуры, искать нужное с на основе совпадений и по шаблону регулярных выражений, на подобие текстового редактора vi. Вторая программа выводит нужно нам количество
Важным критерием обеспечения бесперебойной работы является контроль свободного места. Так, если места не останется, то база данных не сможет записывать данные, с другими компонентами ситуация может быть более плачевная, чем потеря новых данных. В 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. Он также представляет из себя базу данных с демоном, который опрашивает сервисы на основе их регистраций в файле конфигураций и стягивает метки в определённом формате, например: