ELK Stack

Date

ELK Stack

ELK Stack, What?

ELK Stack - комплекс продуктов от проприетарной компании Elastic для агрегации логов. По сути, стек этих продуктов дает возможность красивенько собирать в одно место логи аппа и операционной системы, а потом искать по ним.

Юз кейсы, когда нужно внедрять ELK:

  • всегда

 

Юз кейсы, когда рекомендуется внедрять ELK:

  • когда девы хотят красивенько смотреть логи в браузере

  • когда Вы хотите красивенько смотреть логи в браузере

  • когда у Вас есть необходимость посмотреть что было с аппом в период с 19:45:08 до 19:45:10 и nano на сервере подвисает

 

Анти юз кейсы, когда не нужно внедрять ELK:

  • если Вы сами не понимаете, что нужно и что не нужно собирать 4
  • если лог - это один большой стектрейс

 

Во всех остальных случаях внедрять агрегацию логов однозначно нужно, тем более, что это решает одну самую главную проблему любого Ops/DevOps/Sysadmin:

- Здравствуйте, бородатый сисадмин! Зайдите, пожалуйста, на сервер sheet.prod.it.company, и скопируйте мне одну строку лога за неделю назад, я не знаю какую, но она была примерно 500000 секунд назад, там ещё ошибка была! Спасибо!

- Я DevOps, вот тебе инструмент: зайди на kibana.it.company ищи там что тебе нужно.

- Благодарю Вас, о великий DevOps! Больше никогда не буду отвлекать Вас по таким пустякам!

Внедряем!

Сначала определимся с терминами:

  1. E - Elasticsearch - большое нереляционное и быстрое хранилище, которое, к тому-же, отлично скейлится

  2. L - Logstash - прожорливый апп с кучей возможностей для парсинга неструктурированного лога

  3. K - Kibana - веб лицо для Elasticsearch

  4. Stack - Stack

Пререквизиты

Еластиксерч лучше сразу поднимать в кластере, от 3 нод и больше. В зависимости от того, какой объем данных планируется писать/читать, добавляем по вкусу мем для хипа джавы. Для того, чтобы не тупило - мема нужно, конечно же, побольше. При огромных объемах данных объемах еластик чаще всего упирается в IOPS, соответственно хорошо бы положить его куда-то на SSD. Реплики/шарды можно оставить по дефолту, еластик сам пересчитает ноды в кластере и заалокейтит данные используя свои внутренние бест-пректис.

> Кстати, Еластик - это Apache Lucene внутри. По сути, еластиксерч - это такой большой и удобный враппер над деревянной, но супер производительной люценой.

> Кстати, есть еще один враппер - Apache Solr, он наверное производительнее Еластиксерча (но этого никто доказать не может, как и обратное), но удобнее чуть-чуть больше, чем сама Люцена. Короче Соляра не ахти, но из нее можно выдавить мощи больше, чем из Еластика. Вангую появление SLK

В Logstash заваливаются сами логи, он их процессит внутри согласно правилам которые Вы опишете, и индексирует в хранилку, в Elasticsearch. Соответственно ему нужен CPU для парсинга, и немного мема чтобы держать в памяти то, что уже распарсилось но еще не успело залезть в Еластик.

Через Kibana все будут взаимодействовать с хранилкой логов. Кибана любит открывать 100500 соединений в кластер Еластиксерча, рекомендую поставить эти продукты поближе.

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

> Кстати, Файлбит - это новый Logstash forwarder.

Сетап

Ничего сложного, довольно тривиальный процесс.

Как оно работает

  1. На каждой виртуалке стоит Filebeat, у которого в конфиге написано за какими лог файлами ему следить. Как только он детектит изменения - сразу построчно отправляет это в Logstash.
  2. Logstash получает себе в input строку, которую ему отправил Filebeat. Прогоняет его через все фильтра, определяет что с ним делать и отправляет в нужный output, в нужный индекс Еластика.
  3. Еластик получает лог, индексирует его, делая доступным для поиска, и цепляет поле timestamp - получается time-series табличка.
  4. Дев заходит на Кибану, вводит в строке поиска что ему там нужно найти, и находит. Или не находит.

> Кстати, цеплять рендомный timestamp - это плохо, так как теряется правильная последовательность логов.

Filebeat Интерналс

Он простой. Filebeat на гитхабе - написан на Go, легковесный, работает стабильнее чем старый Logstash forwarder.

Главное в директивах конфига:

filebeat:
  prospectors:
    -
      paths:
        - /opt/tomcat/logs/catalina.out
      input_type: log
      document_type: java
      tail_files: true
      scan_frequency: 1s
      backoff: 1s

output:
  logstash:
    hosts: ["logstash:port"]
    tls:
      certificate_authorities: ["/etc/filebeat/filebeat.crt"]
      insecure: false

logging:
  to_files: true
  files:
    path: /var/log/filebeat
    name: filebeat.log
    rotateeverybytes: 1048576000
  level: info

В конфигах нужно указать путь к лог файлу, дать тип для этого типа логов, и настроить урлу логстеша, куда он будет отсылать. Все.

Logstash Интерналс

Конфиг логстеша делится на 3 части: инпут, фильтр, аутпут. Инпутов у него очень много разных, реально используется beats: 

input {
  beats {
    port => 5044
    ssl => true
    ssl_certificate => "/etc/pki/tls/certs/filebeat.crt"
    ssl_key => "/etc/pki/tls/private/filebeat.key"
  }
  beats {
    port => 5045
    ssl => true
    ssl_certificate => "/etc/pki/tls/certs/filebeat.crt"
    ssl_key => "/etc/pki/tls/private/filebeat.key"
  }
}

На этих портах будет слушать Логстеш. Закрываем его шифрованием, чтобы никто плохой ничего лишнего не прислал.

После того как лог попадёт в инпут, и это будет валидный тип (тот, который слушает логстеш на этом инпуте), он уйдет дальше в фильтр.

Инпутов очень много. Справедливости ради стоит сказать, что пацаны которые не успевают парсить логстешем логи ставят перед ним Rabbit/Redis/Kafka для того, чтобы создавать пул задач на логстеш. Это не очень хорошее решение. 

filter {
  if [message] =~ /^$/ {
    drop {}
  }

  if [type] == "bla" {
    foo {}
  }
}

Первая штука - это грязный хак. Бывает ему залетают пустые логи, и первая директива в фильтрах будет их скипать. Вторая - это проверка на тип, и как результат действие. Фильтров у него очень много, как и инпутов, но ими нужно пользоваться с осторожностью, есть риск закорраптить лог на каком-то этапе.

> Кстати, хоть grok и mutate использовать плохо, потому что grok выносит CPU своими регекспеми, а mutate превращает Logstash в однопоточный костыльный апп, все равно почитать про них нужно.

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

output {
  if [env] == "bla" and [type] == "bla" {
    elasticsearch {
      hosts => ["elasticsearch:port"]
      user => "user"
      password => "password"
      manage_template => false
      index => "uat-svc-%{+YYYY.MM.dd}"
    }
  }
}

Проверяем что за лог, и как результат заруливаем его в правильный индекс. Очень хороший паттерн - мазать индексы по дням - еластику будет намного легче конкретизировать поиск, поднимая в память маленькие индексики, вместо огромного месячного индекса.

До этого этапа я пытался вызвать когнитивный диссонанс:

  • юзать только beats инпут

  • не юзать фильтры

  • не делать пул тасок перед логстешами

 

- Кококо, у меня логи стремные, я не смогу их так красиво распарсить и разложить по полкам! Я cдохну собирать разные строки стектрейса используя multiline, и потом это матчить регекспом, используя grok!

- Да. Поэтому пиши лог в json.

Это очень элегантное решение которое разруливает все вопросы с перформенсом и серчем. Девы должны сразу писать в джейсоне. Не буду останавливаться на этом, это слишком очевидно чтобы объяснять что-то еще.

> Кстати, в json писать умеют все. Начиная с nginx и haproxy, заканчивая log4j, log4net, log4py, etc.

Elasticsearch Интерналс

Он работает даже если его не трогать. Пусть работает. Главное не забывать писать в отдельные индексы: 

    index => "uat-svc-%{+YYYY.MM.dd}"

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

С Еластиком интегрится очень много крутых штук. Например, для понимания того что происходит внутри еластика отлично подходит elasticsearch-kopf, с помощью его можно смотреть стату по всему кластеру: ноды/индексы/шарды/ресурсы/маппинги.

> Кстати, Marvel уже бесплатный

Очень интересно интегрироваться с Grafana, и потом рисовать, например, персентили скорости ответа нжинкса хомяка.

Graylog

Сторит тоже в еластике, но более прожорливый, его форвардер написан на джаве, в общем - говно. На данный момент.

Альтернатива

> Кстати, Уважаемый Сева из Grammarly рассказывал интереснейшую историю про Mozilla Heka, судя по отзывам эта вещь немного бревно, но универсальное. В общем, интересно что получится из этого.

Severity: Important

Резюмируя скажу, что ELK Stack на данный момент единственное продакшн решение для Logs aggregation, которое стабильно работает при любых адекватных и неадекватных нагрузках, отлично скейлится, и дает себя настраивать так, как это нужно конкретно Вам.

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

Не нужно строить перед логстешами точку отказа - менеджер очередей, а юзать максимально большое количество интеграций для гибкости и радоваться, что девы перестали выкачивать по SFTP логи с DBE сервера, и в Grafana на графиках практически в риалтайме рисуются не абстрактные метрики, а реальные значения работы нашего приложения.

Comments

comments powered by Disqus