Больной обращается к врачу с жалобами на боли в животе.
«Срочно на операцию! - отвечает врач.
— Сейчас мы тебя разрежем, обкопаем и попытаемся зашить, как было.
Когда пользователи жаловались на производительность системы, называя программистов негодяями, мы поднимали журнал событий и смотрели, что пошло не так.
А потом мы перешли на ELK. Теперь мы отслеживаем ошибки в моменте, не замедляя работу сервисов.
В этой статье мы расскажем, как мы адаптируем и используем стек ELK в проектах Java и .
Net и находим ошибки онлайн, не открывая и не используя малоинвазивные методы.
Да, мы разобрались и поняли, что не имеет особого значения, сделало ли это решение Microsoft или Open Source — все можно одинаково настроить под свои нужды.
О каких проектах речь?
Жестко и осторожно: реалии Java
Наш Java-продукт — это федеральная система продажи билетов.Он должен работать бесперебойно, зависания и зависания недопустимы.
И в случае неудачи нужно быстро и точно понять причину, ведь это потеря реальных денег клиента.
Здесь ELK работает как онлайн-мониторинг и инструмент для нашей службы поддержки.
Мы логируем «сырые» данные, чтобы при обращении клиента в техподдержку мы знали, какие данные обсуждаем, какой был ключ шифрования и т. д.
Ретроспективный анализ ошибок в .
Net-проектах Проекты .
Net — это в основном услуги по продажам и поддержке клиентов.
Им пользуются более 20 тысяч человек.
Тоже довольно много, но нагрузки не такие большие, как в Java. Мы протоколируем ошибки и информацию, показывающую динамику бизнес-операций.
Например, сколько пользователей зарегистрировалось на сайте.
И когда мы видим, что регистрации не было два дня, сразу понятно, что там что-то произошло.
Или наоборот – продали миллион билетов и отправили об этом письмо директору, чем порадовали человека.
Как мы работаем с ELK
Ведение журнала: Serilog + ELK
В проектах .Net мы также в основном используем Serilog, поскольку он имеет широкий спектр возможностей потока данных.
Здесь нет смысла использовать Beats или Logstash, так как Serilog умеет логировать структурировано: такой-то пользователь зашёл в систему в такое-то время.
Также можно настроить значения нужных фрагментов информации: API, время и т. д. И когда он начнет писать логи в Elastic, это будет не строка, а свойство объекта, по которому можно искать.
То есть мы обходим Filebeat и Logstash, исключая двойную работу.
Прочный режим
Мы используем режим Serilog, называемый режимом Durable — он гарантирует доставку сообщений, даже если Elastic не работает в течение некоторого времени.Он действует примерно так же, как Filebeat плюс Logstash — сначала складывает всё в файл, потом пытается срочно доставить в Elastic, если это не получается, то Serilog периодически пытается, пока Elastic не поднимется.
Вы можете настроить, как часто он будет связываться с Elastic. Здесь Вы можете прочитать инструкцию по настройке.
Контейнеры для бревен
Пишем много логов по Java-проектам — до 5 ГБ в день.Мы разрезаем эти файлы на кусочки по 5 МБ, чтобы они занимали меньше места и их было легче хранить.
ELK хранится и поднимается в Docker-контейнерах на наших компьютерах — получается виртуальная машина, просто более лёгкая, которую кто-то уже настроил до вас.
На .
NET-проектах логи не такие большие, как на Java-проектах, поэтому там мы разбиваем файлы не по размеру, а по дням.
А потом анализируем логи, выделяя типы ошибок.
Забфикс мониторинг
Каждая запись имеет Trace ID, а браузер измеряет время начала и окончания операции — мы логируем эти данные на сервере, а затем мониторим их через Zabbix.Кибана/ Графана
Мы используем Kibana для ежедневного мониторинга ошибок.В Кибане можно искать по логам.
Мы используем эту функцию на производственных и тестовых серверах.
Ещё у нас есть Grafana — там лучше визуализация, все наши проекты показаны на одном дашборде.
Здесь мы видим все данные.
Все ошибки отмечены красным — это повод залезть в Кибану и посмотреть детали.
Мы видим, где ошибка, ее место в коде, когда она произошла и условия окружающей среды.
У нас есть один идентификатор, который связывает все системы вместе и позволяет отследить полный путь ошибки.
Если ошибка неизвестна, начинаем смотреть внимательнее.
Например, недавно мы выпустили на продажу один бизнес-процесс.
Тестирование на стороне заказчика прошло хорошо, но мы посмотрели логи и увидели, что произошла ошибка.
Мы сразу это исправили, и никто ничего не заметил.
Например, на этом скриншоте показано количество регистраций на одном проекте: 
Анализ ошибок
Ежедневно мы получаем все ошибки от ELK, выявляем среди них новые, классифицируем их и при этом даем человекочитаемое имя.Мы отслеживаем динамику уже классифицированных ошибок, ловим всплески и разбираемся в причинах.
Инженер технической поддержки запускает задачи по устранению причин.
За день нужно анализировать тысячи и десятки тысяч строк в логах, а на Java-проектах и того больше.
Множество ошибок повторяются каждую минуту.
Мы начали, как и многие другие, с визуального сканирования всех логов.
Но мы быстро поняли, что с нашими объемами так жить нельзя.
И настраиваем таблицу Excel с макросами, которые могут брать ежедневные данные из Kibana, выбирать из них ошибки и распределять их по существующим категориям.
В результате Excel формирует отчет, где для каждой ошибки есть информация о том, сколько раз в день возникала эта ошибка.
Новые ошибки мы получаем отдельным списком и можем быстро их сначала проанализировать, чтобы понять, критичны они или нет. Заходим в Кибану, чтобы посмотреть подробную информацию по каждой новой ошибке.
Что позволяет делать файл:
- Получайте необходимые сообщения от Elasticsearch в одну таблицу по нужным проектам за необходимый период. Для этого укажите исходные данные в настройках.
- Присвойте ошибкам «имена».
С помощью регулярных выражений задается шаблон поиска и ему присваивается удобочитаемое обозначение.
Тогда этим именем помечаются все ошибки, соответствующие шаблону в исходной таблице.
- Также назначаются категории ОК и ОШИБКА, указывающие, стоит ли на сообщение обращать внимание или нет. Вы можете фильтровать по этим типам.
OTHER – показывает общее количество сообщений по проекту (не только об ошибках, но и просто информационных).
А номера задач присваиваются в TFS, если они уже созданы.
- Для более удобного анализа построен график с возможностью фильтрации.
Давайте посмотрим на примере одного из проектов, недавние ошибки за последние пару дней:
Что мы видим: 1) ошибки вверху, которым присвоены номера задач, не критичны, ждут решения от разработчиков, им присвоены номера задач от TFS. 2) ошибка «Служба ADMS недоступна» возникала 388 раз за сутки — услуга была недоступна в течение нескольких часов, что мы и увидели, обратившись за разъяснениями в Kibana.
3) появился новый тип ошибки "Не удалось подключиться к.
" - он связан с предыдущим, просто был записан еще в одном месте.
Мы собираемся «расследовать» эти два типа ошибок, чтобы выяснить причины, вероятность их повторения и способы их предотвращения в будущем.
Им будет присвоено общее обозначение, чтобы эти ошибки «свернулись» в одну строку.
Что мы планируем улучшить
Сейчас мы работаем над отдельной системой, которая будет сама по расписанию выбирать все ошибки из Elasticsearch, уведомлять оператора о новых и уведомлять о всплесках ошибок.Он будет работать быстрее, чем файл Excel, который постоянно растет. Эта система позволит построить график с разной дискретностью, а не только по дням.
Оператор по-прежнему будет анализировать новые ошибки, называть их и реагировать на непредвиденные ситуации.
P.S. Теперь, благодаря ЭЛК, врач сам замечает, что пациент болен, может быстро поставить диагноз и вручить полезную таблетку, а операцию оставить для самых крайних случаев.
Теги: #Системное администрирование #мониторинг #Grafana #elasticsearch #elk #kibana #логи #logstash
-
Настольные Игры В Жанре Фэнтези.
19 Oct, 24 -
Перчатка – Устройства Ввода. Датчик Изгиба
19 Oct, 24 -
Квантовые Флуктуации И Их Энергия
19 Oct, 24
