Привет всем, я Ма Теджун, инженер по эксплуатации и техническому обслуживанию Beichao. Мы, Beichao, только что вошли в систему ELK. Вот краткое изложение предыдущего фактического боевого процесса и поделиться с вами:
1. Предыстория развертывания ELK
Раньше у компании не было единого плана сбора логов
1. Большинство разработчиков имеют доступ к соответствующему серверу, что увеличивает затраты на управление
2. Когда разработчики запрашивают журналы, если команда используется неправильно, это может вызвать такие проблемы, как исчерпание памяти и случайное удаление, что создает множество угроз безопасности для сервера.
3. Существующая статистика лога довольно неудобна в настройке и малоэффективна.
4. Есть избыточные машины для важных дел, а логи распределены по нескольким машинам, что неудобно находить
Если есть схема сбора логов:
1. Разработчики могут быстро находить проблемы без разрешений сервера
2. Журналы можно анализировать с разных сторон и отображать в соответствии с потребностями бизнеса.
3. Логи собираются в режиме реального времени централизованно, и проблемы с запросами не влияют на нормальную работу сервера
2. Технический отбор
Обычно система управления логами требует следующих этапов работы:
1. Сбор логов
2. Агрегация и фильтрация логов
3. Хранение логов
4. Анализ журнала и запрос
Стек технологий ELK (например, Logstash+ ElasticSearch + Kibana) — это широко используемое и зрелое решение с открытым исходным кодом в отрасли. Это универсальное решение может в основном удовлетворить потребности большинства предприятий в системах управления журналами. В качестве схемы сбора логов выбираем ELK, а его архитектура следующая:
Эта архитектура имеет следующие преимущества:
1. Используйте filebeat для сбора логов, чтобы снизить нагрузку на сервер приложений.
2. Средний уровень использует Kafka в качестве очереди сообщений. Предотвращайте потерю данных, а также сглаживайте пики и заполняйте долины.
3. Logstash фильтрует и обрабатывает данные в соответствии с требованиями
4. Два узла данных ES и один главный узел снимают нагрузку
5. Плагин ElastAlert регулярно запрашивает данные в ES, и сигналы тревоги в реальном времени настраиваются в соответствии с пользователем.
6. Простота расширения
3. Возникшие проблемы и решения:
1. Время в логе - это системное время, а не время вывода лога. Это связано с тем, что logstash генерирует временную метку @timestamp точки времени записи по умолчанию при записи в ES, а kibana по умолчанию использует @timestamp в качестве поля фильтра времени.
2. Журнал имеет 8-часовую разницу во времени из-за часового пояса. Эта проблема в основном вызвана тем фактом, что обработка времени каждым компонентом ELK основана на принципе «разделения хранения и отображения данных». форматируется в соответствии с часовым поясом, установленным пользователем при отображении правильного времени. Поэтому, когда logstash пишет в ES, оно сохраняется как время UTC.Поскольку Китай находится в восточно-восьмом округе, оно будет на 8 часов позже, чем время журнала, а кибана считывает время UTC из ES и получает текущий часовой пояс. через браузер, который находится во времени UTC.Он отображается на основе добавления значения смещения часового пояса браузера. Эта проблема возникает, когда logstash неправильно устанавливает часовой пояс.
Вышеупомянутые две проблемы могут быть решены с помощью плагина даты на этапе фильтра logstash.
date {
match => ["timestamp", "dd/MMM/yyyy:HH:mm:ss"]
target => "@timestamp"
timezone => "+08:00"
}
3. Ошибка _dateparsefailure. Это связано с ошибкой сопоставления времени, внимательно проверьте математику плагина даты, чтобы увидеть, соответствует ли он формату времени журнала.
4. Ошибка Grokparsefailure. Это связано с регулярным сбоем сопоставления сообщений журнала, который можно отладить на следующем веб-сайте:grokdebug.herokuapp.com/
5. logstash перезапускает потребление кафки. Logstash по умолчанию интегрирует все файлы конфигурации в один и тот же файл конфигурации.Поскольку наши журналы java разделены на службы dubbo и веб-службы, я помещаю их в топик kafka, когда их собирает filebeat, в результате чего на стороне logstash получается две конфигурации.Два файла использовать одну и ту же тему одновременно, вызывая эту проблему
6. По умолчанию индекс начинается с logstash. ES использует шаблон индекса по умолчанию, чтобы начать с logstash. Если вам нужно настроить его, вам нужно настроить новый шаблон индекса через интерфейс ES.
7. Запрос данных ES выполняется медленно.В начале два узла данных снова являются главными узлами, что приводит к высокой нагрузке на ЦП. Затем отделите главный узел. При этом данные хранятся 15 дней, а горячий индекс 7 дней. Ускорение запросов. Изменить количество осколков и реплик по умолчанию одновременно
8. Слишком большая нагрузка на Logstash.Самый грузоемкий logstash - это grok, поэтому лог nginx изменен на формат json, а некоторые логи фиксированного формата вырезаны с помощью плагина dissect.Это новый плагин в версии 5.x, что может значительно снизить нагрузку на logstash
В-четвертых, эффект после развертывания
1. Оповещение о сбое системы является более своевременным. В прошлом, когда система дала сбой, для обнаружения проблемы необходимо было дождаться оповещения мониторинга URL или базы данных. Эти две детали мониторинга относительно велики, и ошибка часто найдено, когда это очень серьезно. После развертывания мониторинга ElastAlert коды состояния журналов nginx можно отслеживать в режиме реального времени, и будет выдан сигнал тревоги, когда код состояния ошибки достигнет 500 в течение 1 минуты. Своевременное и эффективное обслуживание аварийных сигналов оставляет драгоценное время для устранения неполадок, поэтому проблемы могут быть решены в кратчайшие сроки с минимальным воздействием.
2. Вы можете быстро запросить время отклика каждого интерфейса в режиме реального времени. Оптимизация интерфейсов с медленным откликом для повышения качества обслуживания системы.
3. Ускорение устранения неполадок При обнаружении аномального трафика можно вовремя отфильтровать аномальный IP\UserAgent и добавить брандмауэр для уменьшения инцидентов, связанных с безопасностью системы.
4. Восстановите разрешения на сервере разработчика, чтобы уменьшить вероятность неправильной работы.
5. Создавайте отчеты о качестве каждую неделю и подсчитывайте еженедельные журналы ОШИБОК и ПРЕДУПРЕЖДЕНИЙ для каждого проекта.
6. Каждый проект может быть визуализирован по мере необходимости для реализации визуализации журнала, и более удобно и быстро анализировать текущее состояние каждого проекта.
V. Резюме
1. В процессе развертывания в большей или меньшей степени будут встречаться различные сбои.При устранении неполадок необходимо внимательно наблюдать за логом, найти ключевое слово, вызвавшее сбой, а затем проводить целенаправленное устранение неполадок по ключевому слову. Во-вторых, внимательно изучите файл конфигурации, чтобы понять принцип и контекст каждой конфигурации.
2. Перед реализацией проекта необходимо полностью изучить осуществимость проекта
3. После завершения развертывания его можно настроить в соответствии с реальной ситуацией, чтобы система находилась в наилучшем рабочем состоянии.