Comments 47
Еще бы веб-морду, аля Splunk, к этому всему — и вообще идеально
Интересная утилита!
Правда вот эта секция в конфиге не понятна
Это получается туда надо прописать все машины? А если их сотни?
А если добавлять новые то перезапускать наверное надо?
Правда вот эта секция в конфиге не понятна
# What hosts to connect to gather logs from.
[hosts]
first=machine1.example.com
second=nobody@machine2.example.com
Это получается туда надо прописать все машины? А если их сотни?
А если добавлять новые то перезапускать наверное надо?
Ну с сотней машиной я, честно говоря, не пробовал. Несколько десятков — точно потянет (там на каждую машину форкается отдельный процесс на лог-сервере). Может быть, и сотню тоже потянет, но в таких масштабах лучше, наверное, пользоваться какими-то другими, более тяжеловесными инструментами — типа как в фейсбуке делают. Перезапускать после изменения конфига надо, да — но это довольно дешевый процесс, а главное, данные, которые накопятся за время перезапуска, не потеряются, так что тут все ОК.
Где ты раньше то был :(
Утилита на dklab выложена несколько месяцев как (правда, на английском). Там есть и другие какие-то вещи, кстати. Я просто потихоньку разные инструменты, которые только на английском сейчас опубликованы, облагораживаю и анонсирую на Хабре.
А почему именно over ssh. Небыло мысли клиент сервер написать?
ставить клиента на сотню серверов — то еще развлечение
Пользователя создать и ключи положить — тоже трудозатраты :) зато не будет потенциальной опасности, что если кто-то получит доступ к ключу приватному лог-сервера, тот получит ssh доступ на все сервера которые вы добавили. Конечно можно и chroot делать пользователю забирающему логи, но это уже опять же те же трудозатраты как и на раскидать пакет по серверам и набрать gpkg -i имяпакета (ну или rpm)
Опять же зачем по шифрованому каналу пускать, а если большой поток логов, дешевле в плане ресурсов будет напрямую. Ещё можно и gzипить логи на лету туда обратно чтобы траффик сетевой уменьшить, но это для гурманов и вообще спорная мысль.
Опять же зачем по шифрованому каналу пускать, а если большой поток логов, дешевле в плане ресурсов будет напрямую. Ещё можно и gzипить логи на лету туда обратно чтобы траффик сетевой уменьшить, но это для гурманов и вообще спорная мысль.
Ключи, кстати, раскладывать несложно — это ведь просто один файлик. Можно его в шаблон виртуальной машины дефолтный положить (это публичный ключ, так что не стоит бояться, что он утечет).
Из описания в статье получается что нужно делать ключи для root.
Как-то не камильфо получается…
Как-то не камильфо получается…
Обычно из /var/log/* может только рут читать, не?
В любом случае — можно указать в директиве user любого другого юзера (и положить именно для него публичный ключ). Тогда на удаленные машины будет коннектиться именно под этим пользователем.
В любом случае — можно указать в директиве user любого другого юзера (и положить именно для него публичный ключ). Тогда на удаленные машины будет коннектиться именно под этим пользователем.
Я про то что с Syslog`ом безопаснее :)
Нет никакой возможности получить доступ к серверу.
Вообще я говорю с точки зрения маньяка по безопасности, а так да, ключи вполне надежны :)
Основная проблема с SSH это трафик и затраты на шифрование/сжатие при больших объемах.
Нет никакой возможности получить доступ к серверу.
Вообще я говорю с точки зрения маньяка по безопасности, а так да, ключи вполне надежны :)
Основная проблема с SSH это трафик и затраты на шифрование/сжатие при больших объемах.
Уже лучше. Но всё равно, зачем давать shell на сервера только для того чтобы логи складывать. Неужели так сложно простой клиент-сервер реализовать?.. Ах, да, он есть уже — syslog. Куда же без велосипедов…
Кстати, насчет gzip — в ssh же есть режим сжатия потока, нужно его использовать (там какой-то ключ командной строки). Для logreplica это будет прозрачно.
Ни от чего это не защитит. Тот кто имеет доступ к серверу с логами очевидно сможет с него и на сервер зайти, защита по IP не актуальна (только помешает если нужно будет ip-шник сервера сменить). Ну зайдя на сервер с no-pty, злоумышленник первым делом избавиться от этой назойливой строчки в файле, просто перезаписав его, это ему будет позволено.
Для сотни серверов можно использовать системы деплоя конфигурации, например chef.
Отлично! У меня тут сотни узлов, а логи собирать руками влом. Поглядим.
чтобы не ставить и не запускать netstat: каким образом всё же происходит отправка инфы на сервер с машины-клиента?
На удаленной машине-источнике логов запускается небольшой perl-процесс (его код прямо в командной строке через -e передается), и уже этот perl-процесс мониторит изменения в лог-файлах по маске и посылает в свой stdout пачки изменений. А сервер эти изменения принимает и раскладывает по файлам у себя. Протокол чем-то похож на tail -f файл1 файл2 ..., но только он чуть более приспособлен к дальнейшему парсингу и устойчив к разрывам связи.
а Scribe?
Мануал по Syslog-NG вам в помощь. Он умеет и не Syslog данные передовать и производить фильтрацию, и собирать логи с других серверов, и делать UDP-spoofing если вдруг решите собирать логи на центральный коллектор и пересылать на нормальны интерфейс для обработки логов, например тот-же Splunk.
Для высоко-нагруженных проектов где логи генерятся в огромных количествах их передача по SSH станет вам боком из-за использования CPU с обеих сторон, собственно по этой причине протокол Syslog не заморачивается на сохранность данных при передаче по сети и тупо шлет их по UDP.
Если сохранность данных критична, юзайте Splunk + NFS.
Для высоко-нагруженных проектов где логи генерятся в огромных количествах их передача по SSH станет вам боком из-за использования CPU с обеих сторон, собственно по этой причине протокол Syslog не заморачивается на сохранность данных при передаче по сети и тупо шлет их по UDP.
Если сохранность данных критична, юзайте Splunk + NFS.
* нормальный
Про syslog-ng в конце статьи есть детальный разбор, почему он не всегда оказывается удобен.
Проблему синхронизации конфигов Syslog[-NG] (и не только) на кластере можно решить при помощи какой-нибудь CMS (Configuration Managment System), например Puppet (http://stproject.info/blog/?tag=puppet).
Проблему описанную в 3 пункте я решал сбором всех конфигов Apache/Nginx в один файл с добавлением в конец строки имени VHOST`а к которому относится строчка, что кстати упрощает фильтрацию и обработку при помощи все того-же Splunk или самописных скриптов.
Проблему описанную в 3 пункте я решал сбором всех конфигов Apache/Nginx в один файл с добавлением в конец строки имени VHOST`а к которому относится строчка, что кстати упрощает фильтрацию и обработку при помощи все того-же Splunk или самописных скриптов.
А для винды такого нету?
есть в этой схеме печальные моменты.
1. все машины, с которых собираются логи, вынуждены пускать рута по ssh.
2. ключ хранится в незащищенном виде на машине с logreplica.
с точки зрения безопасности это очевидные минусы. с точки зрения какой-нибудь более менее серьезной
сертификации по защищенности — такая схема будет неприемлима.
1. все машины, с которых собираются логи, вынуждены пускать рута по ssh.
2. ключ хранится в незащищенном виде на машине с logreplica.
с точки зрения безопасности это очевидные минусы. с точки зрения какой-нибудь более менее серьезной
сертификации по защищенности — такая схема будет неприемлима.
ИМХО вред от пускания рута по SSH несколько преувеличивают (особенно для случая, когда логин происходит не по паролю, а по ключу, который к тому же никогда за пределы одной машины не выходит). Помогает ведь ограничение по ip-адресу и фаервол. Но это весьма холиварный вопрос.
Вопрос совсем не холиварный, это просто вопрос компетенции специалиста. Класть толстый таёжный прибор на безопасность сервера(ов) помещая все яйца в одну корзину с ключиком который ещё и паролем не защищен, может только полный идиот. Любой, кому будет предоставлен доступ на сервер где хранятся логи, в твоей системе получает root-доступ на все сервера.
Конечно в реальности всё равно приходится делать общий root-ключ для управления серверами при их большом количестве, но система, в которой этот ключ хранится защищается просто параноидально. К серверу хранения логов конечно тоже должны предъявляться серьезные требования по безопасности, но круг лиц, имеющих доступ к этому серверу гораздо шире чем можно позволить для машины с ключом от всех серверов.
Конечно в реальности всё равно приходится делать общий root-ключ для управления серверами при их большом количестве, но система, в которой этот ключ хранится защищается просто параноидально. К серверу хранения логов конечно тоже должны предъявляться серьезные требования по безопасности, но круг лиц, имеющих доступ к этому серверу гораздо шире чем можно позволить для машины с ключом от всех серверов.
Для ключей SSH, помимо ограничения по адресам, есть еще и forced command, которая может принимать и валидировать параметры, переданные через STDIN. Это конечно усложнит развертывание (хотя тем, у кого сотни машин не усложнит — они либо автоматизировали такие вещи, либо их уже уволили), однако это более серьёзная мера. Не говоря о том, что получать привилегии рута можно только на определенные действия, через тот же sudo
более удобный и надежный способ сбора логов в центральное место, нежели способ использования настроек syslog/syslog-ng
facepalm.png
Напоминает как мой однокурсник написал на диплом свою программку и заявил что она круче openssh.
Часто хочется реплицировать лог-файлы на центральную машину по маске, а не жестко указав имя лог-файла. Syslog и syslog-ng этого делать не умеют.
RTFM
Наконец, на практике оказывается очень удобно хранить логи не только на центральной машине, но и на той машине, где они создаются (на машине-источнике может при этом настраиваться более узкое «окно ротации»). Так что ваши конфиги syslog и syslog-ng снова растут...
Ну растут. Ровно на три строчки, в которых написано «сохраняй логи в файлы прежде чем отправлять их по сети».
Не всем подходит такой способ. Есть системы, где логи на диск писать нельзя, но читать надо. В I/O каждый tps на счету.
Надежность. За год работы нашего лог сервера syslog-ng ничего не потерялось. Весь служебный ядерный трафик ходит по своему влану и по отдельному интерфейсу. Так что этот мотив очень спорный.
Целесообразность. Если мы начнем писать логи прямо на сервис, а потом его забирать, да еще по ssh, у нас точно все работать для пользователей перестанет и начнет работать только затем, чтобы передать логи.
Способ хорош, но он один из многих. И минусов, кажется, больше, чем плюсов.
Надежность. За год работы нашего лог сервера syslog-ng ничего не потерялось. Весь служебный ядерный трафик ходит по своему влану и по отдельному интерфейсу. Так что этот мотив очень спорный.
Целесообразность. Если мы начнем писать логи прямо на сервис, а потом его забирать, да еще по ssh, у нас точно все работать для пользователей перестанет и начнет работать только затем, чтобы передать логи.
Способ хорош, но он один из многих. И минусов, кажется, больше, чем плюсов.
Вот что отдельно бесит, так это пихание пяти букв дклаб повсюду.
Выглядит уебански.
Почему не просто /etc/logreplica?
Самолюбие тешите?
Выглядит уебански.
Почему не просто /etc/logreplica?
Самолюбие тешите?
Sign up to leave a comment.
Logreplica: сбор логов со всего кластера в единую точку в реальном времени