Рубрика «logstash»

Для своих ETL (Extract, Transform, Loading) процессов, на этапах E и T, то есть извлечение и преобразование данных мы используем Apache Storm, и, так как большинство ошибок, связанных с инвалидацией сырых данных, происходит именно на этом этапе, — появилось желание централизованно логировать всё это, используя ELK стэк (Elasticsearch, Logstash, Kibana).

Каким же было моё удивление, что нигде не то, что на русском языке, но даже в оригинальных туториалах не было описана работа с логами в формате log4j2, который является дефолтом в мире Java-приложений.

Исправляя это упущение — под катом туториал по настройке централизованного сбора любых log4j2 логов на основе:

  • ELK внутри Docker
  • Настройка log4j для работы с Logstash
  • Настройка Logstash для правильной индексации логов
  • Немного бонусов, в виде краткой настройки Storm и интеграции Elasticsearch с Grafana

image
Читать полностью »

Ещё одна система логирования, теперь на ElasticSearch, Logstash, Kibana и Prometheus - 1

Всем разработчикам известна ситуация, когда приложение заглючило и пользователь не может сделать то, что ему нужно. Причины разные: пользователь ввёл неправильные данные, у него медленный интернет и многое другое. Без системы логирования разобрать эти ошибки сложно, а порой невозможно. С другой стороны, система логирования — хороший индикатор проблемных мест в работе системы. Я расскажу, как построить систему логирования в своём проекте (да, ещё раз). В статье расскажу об Elasticsearch + Logstash + Kibana и Prometheus и как их заинтегрировать со своим приложением.

Читать полностью »

Введение

В Badoo несколько десятков «самописных» демонов. Большинство из них написаны на Си, остался один на С++ и пять или шесть на Go. Они работают примерно на сотне серверов в четырех дата-центрах.

В Badoo проверка работоспособности и обнаружение проблем с демонами лежат на плечах отдела мониторинга. Коллеги с помощью Zabbix и скриптов проверяют, запущен ли сервис, отвечает ли он на запросы, а также следят за версиями. Кроме того, в отделе анализируется статистика демонов и скриптов, работающих с ними, на предмет аномалий, резких скачков и т.п.

Сбор и анализ логов демонов в Badoo - 1

Однако у нас до недавнего времени не было очень важной части — сбора и анализа логов, которые каждый демон пишет локально в файлы на сервере. Зачастую именно эта информация помогает на самом раннем этапе поймать проблему или постфактум понять причины отказа.

Мы построили такую систему и спешим поделиться подробностями. Наверняка у кого-то из вас будет стоять похожая задача, и прочтение данной статьи убережет от ошибок, которые мы успели совершить.
Читать полностью »

Вы можете сказать, что “иногда бывает нужно...” Но на самом деле, вы хотите всегда видеть, что у вас в логах, через графический интерфейс. Это позволяет:

  • Облегчить жизнь разработчикам и сисадминам, время которых просто жалко и дорого тратить на написание grep-конвейеров и парсеров под каждый отдельный случай.
  • Предоставить доступ к информации, содержащейся в логах, умеренно-продвинутым пользователям — менеджерам и техподдержке.
  • И видеть динамику и тенденции появления залогированых событий (например, ошибок).

Так что сегодня вновь поговорим о стэке ELK (Elasticsearch+Logstash+Kibana).
Но на этот раз — в условиях json-логов!

Такой use case обещает наполнить вашу жизнь совершенно новыми красками и заставит испытать полную гамму чувств.

Kibana-мать или Зачем вам вообще нужны логи? - 1

Читать полностью »

В один прекрасный момент для одного из проектов появилась необходимость в хранении, обработке и визуализации большого количества логов. Необходимо было индексировать около 10-20 тысяч запросов в секунду с пиками до сотни тысяч, что, как оказалось, является нетривиальной задачей. Для решения этой проблемы мы решили использовать уже знакомый многим ELK- стек. Единственным вопросом было — «а потянет ли он». Как оказалось, потянет, но не сразу.
Читать полностью »

Задача по централизованой обработке логов достаточно просто формулируется и возникает, когда требуется отслеживать работу большого количества серверов. Думаю, не стоит упоминать о том, что из логов можно получать массу информации о жизнедеятельности и самочувствии систем. О том, что писать и читать логи столь же важно как и уметь писать программы.

Соответственно для реализации такой системы перед администратором ставятся задачи: во-первых, каким образом эти логи собирать, во-вторых, каким образом с ними удобно и централизованно работать. Благодаря достаточно развитой связке ELK (Elasticsearch + Logstash + Kibana), уже не раз описанной на Хабре, у администратора имеются инструменты для удобного поиска и отображения всей присутствующей в логах информации. Поэтому ответ на вторую задачу имеется изначально, и остается лишь решить задачу по сбору логов.

Так как в моем случае требованием к системе было отсутствие клиента на серверах, и то, что логи требовалось вытаскивать с Windows-серверов, то в качестве инструмента сбора был выбран родной для Windows — powershell.
Исходя из этого была составлена следующая модель сбора и отображения информации из логов: логи удаленно собираются с серверов powershell-скриптом, после чего складываются в виде файлов на хранилище, далее средствами ELK (Elasticsearch + Logstash + Kibana) происходит их обработка и отображение.

Пример работы всей связки представлен на изображении:

Централизованый сбор Windows event логов, без установки агента, с последующей визуазизацией средствами ELK - 1
Читать полностью »

Про отлов ядерных MCE (machine check error) и прочей гадости с помощью netconsole я писал недавно. Крайне полезная вещь. Одна проблема: throttling на CPU из-за локального перегрева (длительной нагрузки) фиксируется как MCE. Случается бэкап — и админам приходит страшное сообщение об MCE, которое на практике означает «чуть-чуть перегрелось» и точно не требует внимания к себе в 3 часа ночи.

Смехотворность проблемы ещё тем, что Linux фиксирует MCE после того, как throttling закончился. То есть режим 'normal', но вместо этого оно превращается MCE. Выглядит это так:

CPU0: Core temperature above threshold, cpu clock throttled (total events = 40997)
CPU4: Core temperature above threshold, cpu clock throttled (total events = 40997)
CPU4: Core temperature/speed normal
CPU0: Core temperature/speed normal
mce: [Hardware Error]: Machine check events logged

При этом мы точно хотим реагировать на нормальные MCE. Что делать?

В рамках logstash обработка сообщений предполагается stateless. Видишь сообщение — реагируешь. Внедрять же ради одного типа сообщений более сложную систему — оверкилл.

Казалось бы, есть фильтр (не путать с output) elasticsearch, который позволяет делать запросы. К сожалению, он не умеет делать 'if'ы, то есть remove_tag и add_tag будут отрабатывать вне зависимости от того, удался поиск или нет.

Грустно.
Читать полностью »

Предисловие

Страшная сказочка:

EDAC MC0: 1 CE read ECC error on CPU#0Channel#1_DIMM#0 (channel:1 slot:0)
EXT4-fs error: ext4_wait_block_bitmap:445: Cannot read block bitmap
Out of memory: Kill process 95 (sshd) score 31 or sacrifice child
CMCI storm detected: switching to poll mode
page allocation failure: order:1, mode:0x4020
invalid opcode: 0000 [#1] SMP

Неприятно выглядит, правда? Список может быть очень длинным очень длинный. В этой статье я расскажу как с этим жить и что мы с ним сделали.

Часть из этих сообщений в приерах выше заставит вас погрузиться в бездны современной архитектуры процессоров («CMCI storm», удачи в поиске дороги назад, из дебрей интернетов)… Cтранные вещи в ядре могут нарушать ожидания о том, как работают компьютеры, делая последующую отладку очень затруднённой. Отсутствие знания о том, что случилось может даже оставить с грустным ответом «какая-то неведомая фигня, ребутнули, вроде, прошло».Читать полностью »

Всем привет! Уже как пару месяцев наша компания успешно использует в продакшене связку logstash-elasticsearch-kibana для сбора и обработки достаточно большого объема логов. Заглянув в kibana после перевода часов обнаружилось, что все логи идут с отставанием по времени в 1 час. Под катом хочу поделиться решением проблемы с timezones в связке logstash-elasticsearch-kibana и готовой сборкой logstash с обновленными timezones.
Читать полностью »

Учимся готовить Log4j + Logstash + ElasticSearch + Kibana 3 + Auth (Google OAuth2/BasicAuth/CAS Authentication)

Задача

Настройка удобного средства для обработки и получения логов.

Условия

  1. Лицензия MIT или Apache 2.0
  2. Возможность приема и обработки многострочных сообщений
  3. Простота в настройке и использовании
  4. Возможность работы с логами из Log4j

Решение

Logstash + ElastickSearch + Kibana 3.
Читать полностью »