Евгений Штольц - Облачная экосистема

docker run –rm quay.io/thanos/thanos:v0.7.0 –help

docker run -d –net=host –rm \

–v $(pwd)/prometheus0_eu1.yml:/etc/prometheus/prometheus.yml \

–-name prometheus-0-sidecar-eu1 \

–u root \

quay.io/thanos/thanos:v0.7.0 \

sidecar \

–-http-address 0.0.0.0:19090 \

–-grpc-address 0.0.0.0:19190 \

–-reloader.config-file /etc/prometheus/prometheus.yml \

–-prometheus.url http://127.0.0.1:9090

Важной составляющей мониторинга являются уведомления. Уведомления состоят из триггеров срабатывания и провайдера. Триггер срабатывания пишется на PromQL как правило с условием в Prometheus. Когда сработал триггер (условие по метрике), Prometheus сигнализирует провайдеру отправить уведомление. Стандартным провайдером является Alertmanager и он способен отравлять сообщения в различные приёмники, такие как электронная почта и Slack.

, Например, метрика "up", принимающая значения 0 или 1, может быть использована, чтобы отравлять сообщение, если сервер выключен более 1 минуты. Для этого записывается правило:

groups:

– name: example

rules:

– alert: Instance Down

expr: up == 0

for: 1m

Когда метрика более 1 минуты равняется 0, то срабатывает этот триггер и Prometheus отравляет запрос на Alertmanager. В Alertmanager прописано, что делать с этим событием. Мы можем прописать, что при получении события InstanceDown нужно отравлять сообщение на почту. Для этого сконфигурируем Alertmanager это сделать:

global:

smtp_smarthost: 'localhost:25'

smtp_from: 'youraddress@example.org'

route:

receiver: example-email

receivers:

– name: example-email

email_configs:

– to: 'youraddress@example.org'

Сам Alertmanager воспользуется установленным протоколом на этом компьютере. Для того, чтобы он смог это сделать, его нужно установить. Возьмём, к примеру, протокол SMTP (Simple Mail Transfer Protocol). Для проверки, установим консольный почтовый сервер в параллель с Alert Manager – sendmail.

Быстрый и наглядный анализ логов системы

Для быстрого поиска по логам используется OpenSource движок полнотекстового поиска Lucene. На его основе были построены два низкоуровневых продукта: Sold и Elasticsearch, довольно сходных по возможностям, но отличающихся по удобству использования и лицензии. На их построены многие популярные сборки, например, просто набор поставки с ElasticSearch: ELK (Elasticsearch(Apache Lucene), Logstash, Kibana), EFK (Elasticsearch, Fluentd, Kibana), так и продукты, например, GrayLog2. Как GrayLog2, так и сборки (ELK/EFK) активно используются из-за меньшей необходимости настраивать не тестовых стендах, так, например, поставить EFK в кластере Kubernetes можно практически одной командой

helm install efk-stack stable/elastic-stack –set logstash.enabled=false –set fluentd.enabled=true –set fluentd-elastics

Альтернативой, пока не получившей большого рассмотрения являются системы, построенные на рассмотренном ранее Prometheus, например, PLG (Promtail(агент) – Loki(Prometheus) – Grafana).

Сравнение ElasticSearch и Sold (системы сопоставимы):

Elastic:

** Коммерческий с открытым кодом и возможность коммитить (через апрув);

** Поддерживает более сложные запросы, больше аналитики, поддержка из коробки распределенных запросов, более полный REST-full JSON-BASH, чейнинг, машинное обучение, SQL (платный);

*** Full-text search;

*** Real-time index;

*** Мониторинг (платный);

*** Мониторинг через Elastic FQ;

*** Машинное обучение (платно);

*** Простая индексация;

*** Больше типов данных и структур;

** Движок Lucene;

** Parent-child (JOIN);

** Scalable native;

** Документация с 2010;

Solr:

** OpenSource;

** Большая скорость при JOIN;

*** Full-text search;

*** Real-time index;

*** Мониторинг в админке;

*** Машинное обучение через модули;

*** Входные данные: Work, PDF и другие;

*** Необходима схемы для индексации;

*** Данные: вложенные объекты;

** Движок Lucene;

** JSON join;

** Scalable: Solar Cloud (настройка) && ZooKeeper (настройка);

** Документация с 2004.

В нынешнее время всё чаще применяется микро сервисная архитектура, которая позволяет за счёт слабой

связанности между своими компонентами и их простоты упростить их разработку, тестирование и отладку.

Но в целом систему из-за её распределённости становится сложнее анализировать. Для анализа состояния

в целом применяются логи, собираемые в централизованное место и преобразуемые в понятный вид. Также возникает

необходимость в анализе других данных, например, access_log NGINX, для сбора метрик о посещаемости, лога почты,

почтового сервера для выявления попытки подбора пароля и т.д. Примером такого решения возьмём ELK. Под ELK понимается

связка трёх продуктов: Logstash, Elasticsearch и Kubana, первый и последний из который сильно заточены на центральный и

обеспечивают удобство работы. Более обобщённо ELK называют Elastic Stack, так как инструмент подготовки логов Logstash

может быть заменён аналогом, например Fluentd или Rsyslog, а средство визуализации Kibana – на Grafana. Например, хоть и

Kibana предоставляет большие возможности для анализа, Grafana предоставляет отправку уведомлений при возникновениях событий, и

может использоваться совместно с другими продуктами, например, CAdVisor – анализа состояния системы и отдельных контейнеров.

Продукты EKL могут быть установлены самостоятельно, скачаны в виде самодостаточных контейнеров, для которых нужно настроить

связь или в виде одного контейнера.

Для нормальной работы Elasticsearch нужно, чтобы данные приходили в формате JSON. Если данные предавать в

текстовом формате (лог пишется одной строкой, отделяется от предыдущий переносом строки), то он сможет

предоставить только полнотекстовый поиск, так как они будут восприниматься одной строкой. Для передачи

логов в формате JSON имеется два варианта: или настроить исследуемый продукт выдавать в этом формате,

например, для NGINX имеется такая возможность. Но, зачастую это невозможно, так как имеется уже

накопленная база логов, а традиционно они пишутся в текстовом формате. Для таких случаев необходима

пост обработка логов из текстового формата в JSON, которой занимается Logstash. Важно заметить, что если

есть возможность сразу же передавать данные в структурированном виде (JSON, XML и других), то следует это

сделать, так как если сделать детальный парсинг, то любое отклонение одностороннее отклонение от формата

приведёт с неработоспособности, а при поверхностном – теряем ценную информацию. В любом случае парсинг в

этот системе является узким горлышком, хотя может ограниченно масштабироваться до сервиса или лога

файла. К счастью, всё больше и больше продуктов начинают поддерживать структурированные логи, например,

последние версии NGINX поддерживает логи в JSON формате.

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

программ, как Logstash, File bear и Fluentd. Первый из них входит в стандартную поставку Elastic Stack от вендора

и может быть установлен одним образом ELK в Docker – контейнер. Он поддерживает получение данных от файлов, сети и

стандартного потока как на входе, так и на выходе, а главное нативно внутренний протокол Elastic Search.

Logstash мониторит log-файлы на основе даты изменения или получает по сети данные по telnet от распределённой