Агрегация логов с помощью сервиса Logentries

8 апреля 2015

Когда вы начинаете использовать auto scaling groups, перед вами встает новая интересная проблема. На серверах, входящих в группу, нужно как-то смотреть логи, но размер и состав группы постоянно меняется. Ходить по SSH и делать tail -f больше не вариант. Есть много решений проблемы, как SaaS, так и не SaaS. Среди последних следует отметить Syslog, Graylog2 и Logstash. Однако в рамках это заметки речь пойдет об одном из SaaS решений, а именно Logentries.

Среди конкурентов Logentries оказался, пожалуй, самым недорогим сервисом. Но не в ущерб качеству! Сервис не только на пятерку справляется со своей основной задачей, но и отличается простым, интуитивно понятным интерфейсом, хорошей документацией, отзывчивым саппортом, а также интеграцией со Slack и Amazon Web Services. В том числе сервис умеет заливать бэкап всех логов в Amazon S3, если предоставить ему соответствующие access и secret ключи.

Допустим, вы раскатываете обновления вашего приложения, используя AMI, как было описано в одной из ранее опубликованных заметок. Как прикрутить ко всей этой схеме Logentries?

Заходим на source instance и устанавливаем агент системы:

wget "https://raw.githubusercontent.com/logentries/le/master/install/"\
"linux/logentries_install.sh" && sudo bash logentries_install.sh

Понадобится ввести логин и пароль в Logentries.

Кое-какие отладочные ручки:

sudo le whoami
sudo le whoami --debug
sudo le monitor --debug

В веб-интерфейсе сервиса добавляем хосты и логи. В качестве имени «хостов» вводим имена окружений — dev, stage и так далее. Названия логов можно выбрать любые, главное не ошибиться с путями. Выглядеть настройки должны примерно таким образом:

Настройка Logentries

После того, как создадите все окружения и логи на них, откройте одно из окружений и обратите внимание на адресную строку браузера. В ней должно быть что-то вроде:

logentries.com/app/6dbd0f#s=host&id=d8578edf-84d8-ce06-fbc5-bb76...

Здесь d8578edf-84d8-ce06-fbc5-bb76a58c5ca4 — это ID хоста/окружения.

Вернитесь в source instance и скажите:

sudo le reinit --host-key=d8578edf-84d8-ce06-fbc5-bb76a58c5ca4 && \
  sudo service logentries restart

Попробуйте пописать что-нибудь в логи:

logger --priority warn 'Test log message from source instance'

Если все было сделано правильно, в логе с названием Syslog вы увидите сообщение, набранное в консоли. Если по каким-то причинам вы решили не отправлять Syslog в сервис, соответственно, попробуйте записать что-нибудь в логи, которые отправляются.

Теперь перед тем, как создать образ для раскладки в заданном окружении, ваши continuous delivery скрипты должны не только устанавливать нужные пакеты, но и проставлять ID хоста/окружения описанным выше образом. Логи со всех хостов будут агрегироваться на стороне Logentries и вы получите картинку, очень похожую на приведенную здесь:

Агрегация логов с помощью Logentries

Примите во внимание, что логи одного и того же сервиса с разных машин будут писаться вперемешку одним потоком. Чтобы разобраться, с какой машины пришла конкретная строчка, в ней доложен содержаться ip хоста или какая-то еще метка. Тут все сильно зависит от приложения. Если вы все логи пишите в syslog, то имя хоста там наверняка уже есть и ни о чем думать не надо. Если в приложении используется Akka Cluster, то каждая строчка обычно содержит адрес ноды, и тоже все в порядке. В прочих Java-приложениях может потребоваться изменить формат лога, поправив logback.xml, ну и так далее.

Остается открытым вопрос о том, следует ли настраивать синхронизацию времени с помощью ntpd между EC2 Instances, чтобы таймстампы в логах на разных машинах вообще о чем-то говорили. Согласно этому трэду, время на машинах в Амазоне может существенно разъезжаться. С другой стороны, Logentries пишет свои таймстампы, используя, по всей видимости, собственное серверное время на момент получения логов от агента, что в большинстве случаев, скорее всего, будет достаточно точно.

Многие из возможностей Logentries остались за кадром. Помимо прочего, сервис поддерживает дашборды с графиками, присвоение строкам определенных тэгов, если строки соответствуют заданному выражению, фильтрацию по логам с помощью тэгов или произвольных выражений, в том числе в реальном времени, возможность сохранять поисковые запросы, работу с агрегированными логами с разных хостов, алерты на тэги, алерты на отсутствие активности, алерты на аномалии, создание множества учетных записей для доступа к логам, автоматическое определение доменных имен для IP в логах (включено по умолчанию и может очень неслабо ввести в заблуждение, если не знать об этой фиче!) и не только. Но все это вы можете самостоятельно изучить буквально за считанные минуты, благо интерфейс у системы действительно очень прост и интуитивно понятен. Кроме того, сервис предоставляет API.

А чем вы агрегируете логи?

Метки: .

Понравился пост? Узнайте, как можно поддержать развитие этого блога.

Также подпишитесь на RSS, Google+, Facebook, ВКонтакте или Twitter.