В продолжение об своих экспериментах с хранением логов на ELKR пишу некий «мануал» по установке и базовой настройке.
Те статьи, которые ОЧЕНЬ помогли:
Собираем, парсим и отдаём логи с помощью Logstash — матчасть
Собираем и анализируем логи с помощью Lumberjack+Logstash+Elasticsearch+RabbitMQ — хороший пример реального использования
Спасибо авторам!
Итак, мы будем разворачивать следующую архитектуру:
Device => HAProxy => Logstash-Listener => RabbitMQ => Logstash-Filter => Elasticsearch-Balancer => Elasticsearch DATA/MASTER
Я подобное разворачивал на DevStack (что изрядно упростило жизнь), Вашим инструментом может быть что угодно.
Систему в качестве примера возьмём Ubuntu.
На всех нодах настроен NTP.
На нодах с Logstash и Elasticsearch установлен default-jre-headless
Для всех ES нод:
Добавляем репозиторий
Устанавливаем elasticsearch пакет
Далее настраиваем конфиги.
Для Data нод:
Для Master нод:
Для Balancer нод(ы):
CLUSTER_NAME – имя кластера. В большинстве случаев этой настройки достаточно.
NAME – я использовал hostname, но можно любое уникальное имя.
/PATH/TO/DATA/DIR – путь до директории, где будут храниться данные. В моём случае это /usr/share/elasticsearch/data.
Разворачиваем по порядку:
Рекомендую так же проделать следующие действия:
Создать шаблон logstash-template.json
и выполнить на ES-Balancer
Это шаблон по умолчанию для всех индексов. Каждый новый индекс будет создан с 2мя шардами и одной репликой. Это подходит для конфигурации с двумя Data-нодами.
Оптимальным будет
number_of_shards = количество ядер
number_of_replicas = количество data-нод(кратное) — 1
Так же очень помогает в администрировании модуль mobz/elasticsearch-head. На ES-Balancer:
Не забудьте перезапустить elasticsearch сервис после изменения конфигов.
Всё! Где хранить логи нам теперь известно.
Далее устанавливаем Rabbimq-Server:
можете создать пользователя для логстеша, но это не обязательно.
Для всех нод:
Теперь конфиги в /etc/logstash/conf.d
Для Filter:
Для Listener:
Подробнее можно почитать здесь и здесь
Правим /etc/haproxy/haproxy.cfg
Если вдруг не запускается, то в /etc/default/haproxy меняем ENABLED=0 на 1.
Можно смотреть статистику на 1936 порту.
У NXLOG есть версия Community, качаем её с офф сайта.
Конфиг следующего содержания:
Я намеренно поставил IP прокси более привычным, чтобы было видно, что это единственный адрес, который должен видеть клиент, кроме kibana.
Перезапускаем сервис nxlog.
Если мы всё правильно сделали, то уже можно увидеть какую-то активность на всех хостах.
Правим конфиг /usr/local/kibana/config/kibana.yml
Ну и запускаем:
Заходим через браузер на внешний ip kibana, нам предложат сделать интуитивно понятные манипуляции с настройкой.
Всё. Теперь можно откинуться в кресле и сделав 1-10 дашбордов наблюдать за логами (их, кстати, можно красиво оформить вы выкладывать в какой-нибудь cms).
Конечно же, чтобы легче было управлять всей это системой, лучше этот процесс как-то автоматизировать. В нашем случае это chef + openstack: задал какой рецепт выполнить при запуске и пошёл пить чай/кофе/лимонад.
И это далеко не всё, что можно и следует сделать. Но базовая платформа уже есть.
Минимальная комплектация:
1 HAProxy
2 Listener
1 RabbitMQ
2 Filter
1 ES-Balancer
2 ES-Master
2 ES-Data
Если RabbitMQ засунуть в кластер, то всё горизонтальное масштабирование будет сводиться к добавлению Listener`ов, Filter`ов и ES-Data нод. С учётом автоматизации этот процесс будет занимать 5-15 минут (бюрократию не берём в расчёт).
Всё это развернуть «с нуля» при помощи Chef на тестовом стенде мне удалось за 1 час, из которых 5 минут я создавал хосты, 5 минут писал скрипт, который выполнял рецепты на хостах, 40 минут читал новости на Хабре и 10 минут проверял всё ли правильно работает.
Надеюсь эта статья кому-нибудь поможет.
Те статьи, которые ОЧЕНЬ помогли:
Собираем, парсим и отдаём логи с помощью Logstash — матчасть
Собираем и анализируем логи с помощью Lumberjack+Logstash+Elasticsearch+RabbitMQ — хороший пример реального использования
Спасибо авторам!
Итак, мы будем разворачивать следующую архитектуру:
Device => HAProxy => Logstash-Listener => RabbitMQ => Logstash-Filter => Elasticsearch-Balancer => Elasticsearch DATA/MASTER
Я подобное разворачивал на DevStack (что изрядно упростило жизнь), Вашим инструментом может быть что угодно.
Систему в качестве примера возьмём Ubuntu.
На всех нодах настроен NTP.
На нодах с Logstash и Elasticsearch установлен default-jre-headless
Установка ES
Для всех ES нод:
Добавляем репозиторий
wget -qO - https://packages.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
echo "deb http://packages.elastic.co/elasticsearch/1.6/debian stable main" | sudo tee -a /etc/apt/sources.list
Устанавливаем elasticsearch пакет
sudo apt-get update && sudo apt-get install elasticsearch
Далее настраиваем конфиги.
Для Data нод:
cluster.name: CLUSTER_NAME
node.name: Data Node NAME
node.data: true
node.master: false
index.number_of_shards: 2
index.number_of_replicas: 2
http.enabled: false
path.data: /PATH/TO/DATA/DIR
Для Master нод:
cluster.name: CLUSTER_NAME
node.name: Master Node NAME
node.data: false
node.master: true
index.number_of_shards: 2
index.number_of_replicas: 2
http.enabled: false
Для Balancer нод(ы):
cluster.name: CLUSTER_NAME
node.name: Balancer Node NAME
node.master: false
node.data: false
index.number_of_shards: 2
index.number_of_replicas: 2
http.port: 9200
CLUSTER_NAME – имя кластера. В большинстве случаев этой настройки достаточно.
NAME – я использовал hostname, но можно любое уникальное имя.
/PATH/TO/DATA/DIR – путь до директории, где будут храниться данные. В моём случае это /usr/share/elasticsearch/data.
Разворачиваем по порядку:
- Data
- Master
- Balancer
Рекомендую так же проделать следующие действия:
Создать шаблон logstash-template.json
{
"template": "*",
"settings" : {
"number_of_shards" : 2,
"number_of_replicas" : 1
}
}
и выполнить на ES-Balancer
curl -XPUT 'http://localhost:9200/_template/template_logstash/' -d @logstash-template.json
Это шаблон по умолчанию для всех индексов. Каждый новый индекс будет создан с 2мя шардами и одной репликой. Это подходит для конфигурации с двумя Data-нодами.
Оптимальным будет
number_of_shards = количество ядер
number_of_replicas = количество data-нод(кратное) — 1
Так же очень помогает в администрировании модуль mobz/elasticsearch-head. На ES-Balancer:
/usr/share/elasticsearch/bin/plugin -install mobz/elasticsearch-head
Не забудьте перезапустить elasticsearch сервис после изменения конфигов.
Всё! Где хранить логи нам теперь известно.
Установка RabbitMQ
Далее устанавливаем Rabbimq-Server:
apt-get update && apt-get install rabbitmq-server -y
rabbitmq-plugins enable rabbitmq_management && service rabbitmq-server restart
rabbitmqctl set_policy ha-all ".*" '{"ha-mode":"all","ha-sync-mode":"automatic"}'
можете создать пользователя для логстеша, но это не обязательно.
Установка Logstash
Для всех нод:
wget -qO - https://packages.elasticsearch.org/GPG-KEY-elasticsearch | sudo apt-key add -
echo "deb http://packages.elasticsearch.org/logstash/1.5/debian stable main" | sudo tee -a /etc/apt/sources.list
sudo apt-get update && sudo apt-get install logstash
Теперь конфиги в /etc/logstash/conf.d
Для Filter:
config.conf
1.1.1.1 – IP адрес точки входа к RabbiMQ. В нашем случае это конкретно IP рэббита.
2.2.2.2 — IP адресс ES-Balancer. Используется для явного указания какой балансировщик использовать.
Грязный хак с eventlog нужен для того, чтоб как-то справиться с нескончаемым потоком разных кавычек и слешей, которые ломают всю «красоту».
input {
rabbitmq {
auto_delete => false
durable => true
exchange => "logstash-exchange"
exclusive => false
host => '1.1.1.1'
key => "logstash-routing-key"
password => "guest"
prefetch_count => 4
queue => "logstash-filter"
type => "logstash-filter-input"
user => "guest"
threads => 3
arguments => {"x-ha-policy" => "all"}
}
}
# Filter all data
filter {
if [type] == "apache-access" {
grok {
match => [ "message", "%{COMBINEDAPACHELOG}" ]
add_field => [ "severity", "normal" ]
}
} else if [type] == "eventlog" {
mutate {
update => { "host" => "None" }
add_field => { "severity" => "None" }
}
}
if [type] =~ "apache" {
mutate { add_field => { "Message" => "%{message}" } }
}
if [type] == "eventlog" {
mutate { gsub => [ 'message', '[\[\]\\]', ""] }
mutate { gsub => [ 'Message', ':', "-"] }
mutate { gsub => [ 'Message', '"', "'"] }
json { source => "message" }
mutate {
update => { "host" => "%{Hostname}" }
update => { "severity" => "%{Severity}" }
}
}
if [_jsonparsefailure] {
mutate {
update => { "host" => "Unknown" }
update => { "severity" => "Unknown" }
}
}
}
# Output to elasticsearch balancer
output {
elasticsearch {
cluster => "CLUSTER_NAME"
protocol => "http"
host => ['2.2.2.2']
index => "logstash-%{+YYYY.MM.dd}"
}
}
1.1.1.1 – IP адрес точки входа к RabbiMQ. В нашем случае это конкретно IP рэббита.
2.2.2.2 — IP адресс ES-Balancer. Используется для явного указания какой балансировщик использовать.
Грязный хак с eventlog нужен для того, чтоб как-то справиться с нескончаемым потоком разных кавычек и слешей, которые ломают всю «красоту».
Для Listener:
config.conf
input {
# Logstash to Logstash
lumberjack {
codec => "json"
port => 3333
ssl_certificate => "/etc/logstash/ls.crt"
ssl_key => "/etc/logstash/ls.key"
}
# Nxlog to Logstash
tcp {
type => "eventlog"
port => 3515
codec => "json"
}
}
output {
rabbitmq {
durable => true
exchange => "logstash-exchange"
key => "logstash-routing-key"
exchange_type => "direct"
host => '1.1.1.1'
password => "guest"
persistent => true
user => "guest"
}
#file { path => "/var/log/raw/%{host}/%{+YYYY-MM-dd}.log" }
}
Подробнее можно почитать здесь и здесь
Установка HAProxy
apt-get update && apt-get install haproxy -y
Правим /etc/haproxy/haproxy.cfg
haproxy.cfg
global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
user haproxy
group haproxy
daemon
defaults
log global
mode http
option tcplog
option dontlognull
contimeout 5000
clitimeout 50000
srvtimeout 50000
listen to_listeners_event_log :3515
mode tcp
balance roundrobin
option tcpka
server one 1.1.1.1:3515 check inter 5000
server two 2.2.2.2:3515 check inter 5000
…
server last n.n.n.n:3515 check inter 5000
listen to_listeners_event_log :3333
mode tcp
balance roundrobin
option tcpka
server one 1.1.1.1:3333 check inter 5000
server two 2.2.2.2:3333 check inter 5000
…
server last n.n.n.n:3333 check inter 5000
listen stats :1936
stats show-legends
stats refresh 5s
stats hide-version
stats uri /
Если вдруг не запускается, то в /etc/default/haproxy меняем ENABLED=0 на 1.
Можно смотреть статистику на 1936 порту.
Установка NXLOG
У NXLOG есть версия Community, качаем её с офф сайта.
Конфиг следующего содержания:
nxlog.conf
#define ROOT C:\Program Files\nxlog
define ROOT C:\Program Files (x86)\nxlog
Moduledir %ROOT%\modules
CacheDir %ROOT%\data
Pidfile %ROOT%\data\nxlog.pid
SpoolDir %ROOT%\data
LogFile %ROOT%\data\nxlog.log
<Extension json>
Module xm_json
</Extension>
# Windows Event Log
<Input eventlog>
# Uncomment im_msvistalog for Windows Vista/2008 and later
Module im_msvistalog
Query <QueryList> <Query Id='1'> <Select Path="Application">*[System[(Level=1 or Level=2 or Level=3 or Level=4)]]</Select> <Select Path='Security'>*</Select> <Select Path="System">*[System[(Level=1 or Level=2 or Level=3 or Level=4)]]</Select> </Query> </QueryList>
Exec $Message = replace ($Message, '"', "'");
# Uncomment im_mseventlog for Windows XP/2000/2003
# Module im_mseventlog
Exec to_json();
</Input>
<Output out>
Module om_tcp
# Ip of HAProxy listeners server
Host 192.168.0.14
# Port in Listeners
Port 3515
</Output>
<Route 1>
Path eventlog => out
</Route>
Я намеренно поставил IP прокси более привычным, чтобы было видно, что это единственный адрес, который должен видеть клиент, кроме kibana.
Перезапускаем сервис nxlog.
Если мы всё правильно сделали, то уже можно увидеть какую-то активность на всех хостах.
Установка Kibana
cd /tmp
wget https://download.elastic.co/kibana/kibana/kibana-4.1.0-linux-x64.tar.gz
tar xvfC kibana-4.1.0-linux-x64.tar.gz /usr/local
rm -vf /usr/local/kibana
ln -s /usr/local/kibana-4.1.0-linux-x64 /usr/local/kibana
cd /usr/local/kibana
Правим конфиг /usr/local/kibana/config/kibana.yml
…
port: 80
…
elasticsearch_url: 'http://IP_TO_ES_BALANCER:9200'
…
Ну и запускаем:
./bin/kibana -q &
Заходим через браузер на внешний ip kibana, нам предложат сделать интуитивно понятные манипуляции с настройкой.
Всё. Теперь можно откинуться в кресле и сделав 1-10 дашбордов наблюдать за логами (их, кстати, можно красиво оформить вы выкладывать в какой-нибудь cms).
Конечно же, чтобы легче было управлять всей это системой, лучше этот процесс как-то автоматизировать. В нашем случае это chef + openstack: задал какой рецепт выполнить при запуске и пошёл пить чай/кофе/лимонад.
И это далеко не всё, что можно и следует сделать. Но базовая платформа уже есть.
Минимальная комплектация:
1 HAProxy
2 Listener
1 RabbitMQ
2 Filter
1 ES-Balancer
2 ES-Master
2 ES-Data
Если RabbitMQ засунуть в кластер, то всё горизонтальное масштабирование будет сводиться к добавлению Listener`ов, Filter`ов и ES-Data нод. С учётом автоматизации этот процесс будет занимать 5-15 минут (бюрократию не берём в расчёт).
Всё это развернуть «с нуля» при помощи Chef на тестовом стенде мне удалось за 1 час, из которых 5 минут я создавал хосты, 5 минут писал скрипт, который выполнял рецепты на хостах, 40 минут читал новости на Хабре и 10 минут проверял всё ли правильно работает.
Надеюсь эта статья кому-нибудь поможет.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
rudenkovk
Какое количество данных безболезненно тянет ES?
onegreyonewhite Автор
Так однозначно сложно ответить. Всё зависит от количества Data-нод и производительности этих нод.
Чем больше потоков, тем быстрее.
На тестовом стенде с 2мя Data-нодами тянет 17M (~2Gb) логов в день. Каждая нода по 2 ядра и 2Гб. 2 недели логов тянет хорошо, но начинает напрягаться HDD. Но с учётом того, что ресурсы общие с ещё кучей VM, то весьма хороший результат.
В прочем сложно судить: загружаемые данные более или менее одинаковы.
rudenkovk
Спасио, я понял. Не как шпилька, но для меня это смешные объемы :) По нашим наблюдениям, при большом количестве читающих клиентов к ES(у нас порядка 100 дашбордов, для разных бизес и ИТ отделов), мы начинаем валится где-то на 8-10 Gb в день. Потому сейчас пересобираем свою елку на другие базовые рельсы, так как поток сырых логов у нас все растет и растет.
onegreyonewhite Автор
Если не секрет, в сторону чего нового смотрите?
Есть ли какая-либо cache-прослойка между дашбордами или клиентом? Мне кажется это изрядно бы разгрузило нагрузку на бд.
Есть ли распараллеливание шардами нагрузки между несколькими хостами?
Это я всё больше для себя узнаю :)
rudenkovk
О кеше между клиентами и ES пока не думали. Да и наверно не видим особо смысла. Поясню: новые данные обычно достаточно легко читаются, проблема в старых данных или больших выборках(кстати то же касается и метрик, но об этом ниже). Мы скорее хотим придти к схеме, когда на долговременные данные можно заказать отчет, которые спокойно выполнится в фоне, а kibana, использовать, в основном, для горячих данных.
В целом, мы сейчас идем к уборки логов в hadoop, и над ним уже ставить ES. Поясню почему такое решение: сейчас наш поток логов хранится 2 недели от момента появления, но по 152 ФЗ нам надо его хранить 180 дней. В перспективе на эти данные можно будет посадить аналитика и пусть он майнингом занимается, а такое уже требует бесконечного хранения. От сюда и решения. Еще плюс hadoop в том, что данные внутри его hdfs можно хранить в сжатом виде, что дает экономию места(кстати метрик то же касается).
Еще момент, что мы имеем соизмеримый с объемом логов, объем метрик(сейчас около 20Гб в день, предполагается увеличение на 25-40%), и столкнулись с проблемами хранения и репликации этого дела (Господи, упаси нас от carbon). Сейчас приходим к тому, что хорошим вариантом является opentsdb, так как оно живет на базе hbase.
Резюмируя: мы весь мониторинг (и аналитику) переводим в одной место, и даем к нему несколько интерфейсов взаимодействия, в зависимости от целей. И на едином наборе данных делаем метрики, алерты, логи и аналитику.
onegreyonewhite Автор
Т.е. если я правильно Вас понял, то у Вас будут храниться данные сразу в двух местах: неделя-две в ES и + hadoop для текущих и остальных, так? Решение интересное. Запомню на будущее.
rudenkovk
Еще до конца всю схему не проработали. Но предполагаем, что ES будет индексировать все, что хранит в себе hadoop. Как мы распределим и настроим индексы, еще не решили.
Хранить ли весь набор данных за какой-то срок в ES, мы будем решать уже по факту быстродействия рабочего кластера, на тестовом у нас маленький набор данных и слабое железо.
nucleusv
А расскажите про вашу конфигурацию: сколько нод (дата, мастер, балансер) и каких: сколько памяти, процессоров и я так понял у вас 8-10 Гб логов в день?
rudenkovk
Мы еще в глубоком пилоте, и пока работаем на простых «консервных банках». Мы идем поступательно, от задачи хранить, к задаче отдавать быстро.
Я потом может напишу статью сюда об этом.
Предварительные расчеты такие: 4 дата-ноды (2 камня, 64 Гб, диск по максимуму), два сервака с мастером и на нем же ES. К чему придем когда будем готовы переходить на продакшен — увы, но вопрос открытый.
nucleusv
А какие параметры heap для дата и мастер нод?
rudenkovk
Пока дефолт от cloudera. Повторяю, мы еще не на реальном железе.
ctrlok
Мы пишем >300 гигов в день, 5 нод эластика, достаточно большие, в принципе все упирается в ram
rudenkovk
а сколько вы их храните?
AlexWinner
А сколько RAM у вас для одной ноды используется? В документации они не рекомендуют больше 32GB использовать вроде. И оставлять столько же на кеш файловой системы.
nucleusv
А дайте конфигурацию плиз :)
Сколько и каких нод — характеристики железа.
И конфиг если можно?