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! Больше никогда не буду отвлекать Вас по таким пустякам!
Внедряем!
Сначала определимся с терминами:
-
E - Elasticsearch - большое нереляционное и быстрое хранилище, которое, к тому-же, отлично скейлится
-
L - Logstash - прожорливый апп с кучей возможностей для парсинга неструктурированного лога
-
K - Kibana - веб лицо для Elasticsearch
-
Stack - Stack
Пререквизиты
Еластиксерч лучше сразу поднимать в кластере, от 3 нод и больше. В зависимости от того, какой объем данных планируется писать/читать, добавляем по вкусу мем для хипа джавы. Для того, чтобы не тупило - мема нужно, конечно же, побольше. При огромных объемах данных объемах еластик чаще всего упирается в IOPS, соответственно хорошо бы положить его куда-то на SSD. Реплики/шарды можно оставить по дефолту, еластик сам пересчитает ноды в кластере и заалокейтит данные используя свои внутренние бест-пректис.
> Кстати, Еластик - это Apache Lucene внутри. По сути, еластиксерч - это такой большой и удобный враппер над деревянной, но супер производительной люценой.
> Кстати, есть еще один враппер - Apache Solr, он наверное производительнее Еластиксерча (но этого никто доказать не может, как и обратное), но удобнее чуть-чуть больше, чем сама Люцена. Короче Соляра не ахти, но из нее можно выдавить мощи больше, чем из Еластика. Вангую появление SLK
В Logstash заваливаются сами логи, он их процессит внутри согласно правилам которые Вы опишете, и индексирует в хранилку, в Elasticsearch. Соответственно ему нужен CPU для парсинга, и немного мема чтобы держать в памяти то, что уже распарсилось но еще не успело залезть в Еластик.
Через Kibana все будут взаимодействовать с хранилкой логов. Кибана любит открывать 100500 соединений в кластер Еластиксерча, рекомендую поставить эти продукты поближе.
Filebeat опа, внезапность, будет стоять на каждой виртуалке и отправлять нам логи.
> Кстати, Файлбит - это новый Logstash forwarder.
Сетап
Ничего сложного, довольно тривиальный процесс.
Как оно работает
- На каждой виртуалке стоит Filebeat, у которого в конфиге написано за какими лог файлами ему следить. Как только он детектит изменения - сразу построчно отправляет это в Logstash.
- Logstash получает себе в input строку, которую ему отправил Filebeat. Прогоняет его через все фильтра, определяет что с ним делать и отправляет в нужный output, в нужный индекс Еластика.
- Еластик получает лог, индексирует его, делая доступным для поиска, и цепляет поле timestamp - получается time-series табличка.
- Дев заходит на Кибану, вводит в строке поиска что ему там нужно найти, и находит. Или не находит.
> Кстати, цеплять рендомный 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