На протяжении тысячелетий человечество окружало огромное количество информации. Нужно было анализировать звуки десятка хищников, желающих вас съесть; эмоции и настроение вашего ближайшего окружения, чтобы случайно не стать добычей соплеменников; запоминать особенности растений, плоды которых вы с радостью бы съели и т.п. В современном мире количество информации увеличилось: сотни телевизионных каналов, различные сайты, youtube-каналы и т.д. А что если информации станет настолько много, что запомнить, а тем более анализировать и использовать ее будет физически невозможно?

Приложения и сервисы, работающие на серверах в штатном режиме, генерируют и хранят какие-то данные пользователей (обычно в базе данных) и пишут логи (log) происходящих событий и ошибок. Объем этих данных  сильно зависит от количества и активности пользователей. Для наших приложений это десятки мегабайт логов и сотни мегабайт  в базе, хотя бывают исключения. Это  немного, тем более для работы с данными  есть специальные программы предназначенные для этого. Т.е. для типичного приложения информации  не так и много, а проблему могут составлять только логи, куда пишутся ошибки (если они есть) и может быть обращения к серверу. И все кажется хорошо и замечательно, если бы не одно но:

«Управлять можно только тем, что можно измерить»,– Питер Друкер.

Этой информации абсолютно недостаточно для того, чтобы сказать, что наше приложение работает! Логи ошибок по умолчанию относятся только к web-серверу, остальные вполне могут быть выключены. Логические ошибки приложения не фиксируются никак. Сам сервер не мониторится, и если внезапно закончится оперативная память и место на диске — мы об этом узнаем в последнюю очередь. Статистика посещений и использования сервиса не собирается. Итог: кошмар для сотрудника отдела эксплуатации.

Но технологии не стоят на месте, и мы можем начать собирать всю эту информацию! Когда происходят логические ошибки, заставляем разработчиков писать логи и включать запись в базы данных. Также устанавливаем модные приложения для сбора метрик с сервера (Zabbix с Zabbix агентом, Prometheus с NodeExporter-ом и т.п.). Представители бизнеса рассказывают нам о статистике, которую хотят получать, а мы самоотверженно засовываем метрики в каждую щель нашего приложения. И вот у нас гигабайты разных логов, тысячи всевозможных метрик, теперь должен наступить рай для эксплуатации… Но почему-то не наступает. А когда мы вспоминаем, что эксплуатировать нужно не 1 сервер, а десятки и сотни — ситуация становится плачевной. Руки опускаются, а желание собирать информацию просто отпадает.

Как же быть? С одной стороны, у нас есть непреодолимое желание собирать много информации, т.к. на основании ее мы можем принимать более правильные решения. С другой стороны, эту информацию надо агрегировать и обрабатывать, что при больших объемах становится трудновыполнимой задачей.

Давайте подходить к этому вопросу системно. Что у нас есть:

• Информация о серверах, на которых работают наши приложения,
• Информация о служебных сервисах (web-сервер, база данных и т.п.),
• Информация о работе приложения,
• Бизнес метрики.

Эта информация представлена в нескольких форматах:

• Логи (текстовые файлы),
• Метрики (зависит от способа сбора и хранения).

Для того чтобы анализировать все эти виды информации, существуют удобные инструменты. Для сбора и анализа логов есть стек ElasticSearch + Logstash, для метрик есть Prometheus + NodeExporter или любые другие аналоги. Они решают две главные задачи:

1. Инструменты построения сложных запросов для обработки данных,
2. Централизованный сбор и хранение данных

Сами по себе ни метрики, ни логи ничего нам не скажут, ведь  посмотреть сотни тысяч записей и проанализировать — невозможно. Для этого применяются специальные средства автоматического анализа. Например, пользователь зашел на сайт и увидел ошибку, она сохранилась в лог. О чем это говорит? Ни о чем. А вот если сделать запрос: “покажи среднее количество ошибок в день за последние полгода” — уже веселее. Мы сможем увидеть “нормальный” уровень количества ошибок для нашего приложения. А также  всплески, связанные с новой версией приложения или ошибками инфраструктуры. Но, минуточку, у нас же десятки серверов и сотни приложений. Получается, нужно заходить на каждый?

Нет. Для этого у нас есть задача централизованного сбора данных, которые предоставляют вышеназванные инструменты. Вместо того чтобы бегать по всем серверам, мы всё храним на одном, предназначенном для этого. Приятный бонус — возможность сжимать данные, благо алгоритмов и инструментов предостаточно. И вот теперь мы можем делать запросы в стиле “покажи среднее количество ошибок в день за последние полгода на всех серверах”. Это выглядит так, будто  мы только увеличиваем количество информации, а работать с ней легче не стало.

На арену выходят инструменты визуализации данных! Например, весьма универсальное решение — Grafana — умеет визуализировать данные из разных источников (для логов есть Kibana, работающая аналогичным образом). Открываем Grafana, подключаем источник данных (например Prometheus), создаем dashboard (страницу с графиками), создаем график. И перед нами прекрасная визуализация сложного запроса, который описали выше. Настроение поднимается, сотрудники эксплуатации залипают у экранов, разглядывая различные варианты представления интересующих их данных, мир начинает играть новыми красками. Спустя какое-то время, наигравшись с графиками, наступает апатия, а работа превращается в рутину:

1. Зашел в Grafana
2. Открыл dashboard по первой метрике
3. Посмотрел
4. Закрыл
5. GOTO 2

И так до бесконечности.

Да, даже это  упростило жизнь. Можно увидеть много интересного, визуализируя данные. Но все равно приходится заходить и смотреть. А серверов и параметров много, и все нужно просматривать. Хоть нанимай отдельного человека для этой работы!

Автоматика и тут может нам помочь. Теперь рассмотрим инструменты оповещений, например Alert Manager. Суть подобных средств заключается в том, чтобы оповещать ключевых сотрудников о том, что происходит с системами. Автоматический наблюдатель, если угодно. Мы знаем признаки того, что что-то пошло не так. Создаем правило, например: “если количество ошибок за последние 10 минут больше среднего количества ошибок в два раза — ПРЕДУПРЕЖДЕНИЕ, а если больше в 3 раза — ТРЕВОГА”. Дальше настраиваем канал связи, т.е. способ, которым нас будут информировать. Например, email или сообщение в Telegram. И все. Заходить в систему мониторинга уже не нужно. В случае приближающихся проблем, мы об этом узнаем через систему оповещения.

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