В кластере из более чем 12 серверов centos 5.8 я развернул logstash, используя собственный отправитель logstash, который отправляет /var/log/*/*.log обратно на центральный сервер logstash.
Мы пробовали использовать rsyslogd в качестве отправителя, но из-за ошибки в модуле ImFile rsyslogd, если удаленный конец не отвечал, журналы накапливались в памяти.
В настоящее время мы используем Redis в качестве транспортного механизма, поэтому в logstash01 redis работает локально, привязанный к IP-адресу VLAN для этих журналов.
Таким образом, logstash-shipper отправляет в redis на logstash01. logstash01 отправляет в Elasticsearch, работающий в отдельном процессе.
Вот что мы видим. В Elasticsearch 141 заблокированная тема. Анализ родительского элемента elasticsearch показывает:
futex(0x7f4ccd1939d0, FUTEX_WAIT, 26374, NULL
Итак ... Прошлой ночью некоторые из веб-серверов (чьи журналы отслеживаются с помощью logstash) сошли с ума со средней загрузкой более 500.
На logstash01 есть это
Dec 19 00:44:45 logstash01 kernel: [736965.925863] Killed process 23429 (redis-server) total-vm:5493112kB, anon-rss:4248840kB, file-rss:108kB
Итак, OOM-killer убил redis-server, что означало, что журналы накапливались в памяти на серверах, которые доставляли материалы. как-то означает, что apache получает новые возможности. (Честно говоря, я не знаю, как это сделать, я просто предполагаю, что он идет в хвост) ..
Это моя теория развития событий:
Вопросы такие:
Почему apache сходит с ума, если за его журналом что-то стоит. Неужели дело в том, что он блокирует запись Apache?
Есть ли разумный способ сделать elasticsearch быстрее / лучше / устойчивее?
Есть ли разумный способ сделать Redis устойчивым и не умирать из-за OOM'd
Есть ли фундаментальный недостаток в том, как я все это настроил, или эта проблема есть у всех?
-- РЕДАКТИРОВАТЬ --
Некоторые спецификации для @lusis.
admin@log01:/etc/init$ free -m
total used free shared buffers cached
Mem: 7986 6041 1944 0 743 1157
-/+ buffers/cache: 4140 3845
Swap: 3813 3628 185
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 19G 5.3G 13G 31% /
udev 3.9G 4.0K 3.9G 1% /dev
tmpfs 1.6G 240K 1.6G 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 3.9G 0 3.9G 0% /run/shm
/dev/sda1 90M 72M 14M 85% /boot
/dev/mapper/data-disk 471G 1.2G 469G 1% /data
/dev/sda2 on / type ext3 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
/dev/sda1 on /boot type ext2 (rw)
/dev/mapper/data-disk on /data type ext3 (rw)
/data/elasticsearch on /var/lib/elasticsearch type none (rw,bind)
log01:/etc/init$ top
top - 14:12:20 up 18 days, 21:59, 2 users, load average: 0.20, 0.35, 0.40
Tasks: 103 total, 1 running, 102 sleeping, 0 stopped, 0 zombie
Cpu0 : 3.0%us, 1.0%sy, 0.0%ni, 95.7%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st
Cpu1 : 12.0%us, 1.0%sy, 0.0%ni, 86.6%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st
Cpu2 : 4.7%us, 0.3%sy, 0.0%ni, 94.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 5.6%us, 1.3%sy, 0.0%ni, 93.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu4 : 5.3%us, 1.3%sy, 0.0%ni, 93.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu5 : 6.4%us, 1.0%sy, 0.0%ni, 92.3%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st
Mem: 8178120k total, 6159036k used, 2019084k free, 761780k buffers
В вашем сообщении не очень много описания спецификаций (память в индексаторе LS, объем журнала или многое другое), но я постараюсь ответить на ваши вопросы как можно лучше. Отказ от ответственности: я один из разработчиков logstash -
Сход с ума Apache, скорее всего, был побочным эффектом работы процесса logstash. Я бы отложил это на время.
Разумный способ сделать ES f / b / s - добавить больше узлов ES. Это действительно так просто. Они даже автоматически обнаруживают друг друга в зависимости от топологии сети. За 17 лет работы в этой отрасли я никогда не видел ничего более простого в горизонтальном масштабировании, чем ElasticSearch.
Для f / b / s Redis не используйте кластеризацию Redis. Новые версии Logstash могут выполнять внутреннюю балансировку нагрузки Redis. Выходные данные Redis поддерживают список хостов Redis в конфигурации плагина, и поддержка будет добавлена к входной стороне, чтобы соответствовать этому. Тем временем вы можете использовать несколько входных определений Redis на стороне индексатора / потребителя.
Я не могу ответить на этот вопрос, кроме как сказать, что похоже, что вы слишком много пытаетесь сделать с одним (возможно, недостаточно мощным хостом).
Любой хороший процесс масштабирования начинается с разделения совместно размещенных компонентов на отдельные системы. Я нигде не вижу ваших конфигов, кроме тех мест, где "узкие места" logstash находятся в фильтрах. В зависимости от того, сколько преобразований вы выполняете, это может повлиять на использование памяти процессами Logstash.
Logstash работает очень похоже на лего. Вы можете использовать кирпич 2x4 или два кирпича 2x2 для выполнения той же задачи. За исключением случая с logstash, на самом деле надежнее использовать кирпичи меньшего размера, чем один большой.
Вот несколько общих советов, которые мы обычно даем:
как можно быстрее отправлять журналы с периферии. Если вы можете использовать чистый сетевой транспорт вместо записи на диск, это хорошо, но не обязательно. Logstash основан на JVM, и это имеет как хорошие, так и плохие последствия. Используйте альтернативного грузоотправителя. Я написал основанный на питоне ( https://github.com/lusis/logstash-shipper ), но я бы посоветовал вместо этого использовать Beaver ( https://github.com/josegonzalez/beaver ).
создавайте свои журналы в формате, который требует минимальной фильтрации (json или оптимально формат json-событий). Это не всегда возможно. Для этого я написал приложение log4j ( https://github.com/lusis/zmq-appender ) и в конечном итоге разбил макет паттерна на собственное репо ( https://github.com/lusis/log4j-jsonevent-layout ). Это означает, что мне не нужно делать ЛЮБУЮ фильтрацию в logstash для этих журналов. Я просто установил тип ввода на 'json-event'
Для apache вы можете попробовать такой подход: http://cookbook.logstash.net/recipes/apache-json-logs/
Также обратите внимание, что список рассылки logstash ОЧЕНЬ активен, поэтому всегда следует начинать с него. Продезинфицируйте и добавьте свои конфигурации, так как это лучшее место для начала.
Есть компании (например, Sonian), масштабирующие ElasticSearch до петабайтных уровней, и компании (например, Mailchimp и Dreamhost), масштабирующие Logstash до безумных уровней. Это может быть сделано.