На кластере из более чем 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 заблокированных тем. Распределение родительского элементаasticsearch показывает:
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
Так ОЫЙ-убийца убил Redis-сервер, который затем предназначенные журналы свалили в памяти на серверах , которые были судоходных вещами .. Какой каким - то образом означают , что апач получает свои панталоны в повороте. (Честно говоря, я не уверен, как, я просто предполагаю, что это следит за журналом) ..
Это моя теория о том, как разворачивались события:
- У нас был всплеск трафика.
- Было создано огромное количество журналов.
- Они накапливались в Redis, так как logstash /asticsearch, кажется, способен обрабатывать только 300-400 новых событий в секунду.
- Redis полностью наполнился до такой степени, что OOM-убийца бездумно его зарезал.
- Redis перестает принимать новые предметы.
- Предметы теперь начинают накапливаться на стороне удаленных хостов.
- Все сходит с ума . Apache прекращает принимать запросы. (Почему?).
Вопросы такие:
Почему Apache сходит с ума, если есть что-то, что следит за его журналом. Это то, что эта штуковина мешает Apache писать?
Есть ли разумный способ сделать упругое исследование быстрее / лучше / упругее?
Есть ли нормальный способ сделать 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 на стороне индексатора / потребителя.
Я не могу ответить на это, кроме как сказать, что это звучит так, будто вы пытаетесь многое сделать с одним (возможно, слабым хостом).
Любой хороший процесс масштабирования начинается с разбивки совместно расположенных компонентов на отдельные системы. Я не вижу ваших конфигов gist'd нигде, кроме мест, где logstash 'узкие места' в фильтрах. В зависимости от того, сколько преобразований вы делаете, это может повлиять на использование памяти процессами Logstash.
Logstash работает во многом как легос. Вы можете использовать кирпич 2х4 или два кирпича 2х2 для выполнения той же задачи. За исключением случая с logstash, на самом деле более разумно использовать кирпичи меньшего размера, чем один большой кирпич.
Некоторые общие советы, которые мы обычно даем:
отправляйте журналы как можно быстрее с периферии. Если вы можете использовать чистый сетевой транспорт вместо записи на диск, это хорошо, но не обязательно. Logstash основан на JVM, и это имеет хорошие и плохие последствия. Используйте альтернативный грузоотправитель. Я написал один на основе Python ( 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 до безумных уровней. Это может быть сделано.
источник