Мне нужно настроить централизованное ведение журнала для набора серверов (10-20) в Amazon VPC. Ведение журнала должно быть таким, чтобы не терять никаких сообщений журнала в случае, если какой-либо отдельный сервер перейдет в автономный режим - или в случае отключения всей зоны доступности. Он также должен допускать потерю пакетов и другие нормальные сетевые условия без потери или дублирования сообщений. Он должен надежно хранить сообщения, как минимум, на двух разных томах EBS в двух зонах доступности, но S3 также является хорошим местом. Это также должно быть в реальном времени, чтобы сообщения приходили в две разные зоны доступности в течение нескольких секунд после их создания. Мне также нужно синхронизировать файлы журналов, не созданные через системный журнал, поэтому централизованное решение для ведения журнала только для системного журнала не будет удовлетворять все потребности, хотя я думаю, что это ограничение можно обойти.
Я уже рассмотрел несколько решений и перечислю их здесь:
От канала к каналу до S3: Я мог бы настроить два сервера журналов в качестве хостов Flume, которые будут хранить сообщения журнала либо локально, либо в S3, и настроить все серверы с помощью Flume для отправки всех сообщений на оба сервера, используя параметры сквозной надежности. Таким образом, потеря одного сервера не должна приводить к потере сообщений, и все сообщения будут приходить в две зоны доступности в реальном времени. Однако должен быть какой-то способ объединить журналы двух серверов, дедуплицируя все сообщения, доставленные обоим. Это можно сделать, добавив уникальный идентификатор на стороне отправителя к каждому сообщению, а затем записав несколько запусков дедупликации вручную в файлы журнала. Я не нашел простого решения проблемы дублирования.
Из Logstash в Logstash в ElasticSearch: Я мог бы установить Logstash на серверах и доставить их на центральный сервер через AMQP, с включенными параметрами устойчивости. Однако для того, чтобы это сработало, мне нужно было бы использовать некоторые из реализаций AMQP с возможностью кластеризации или разветвлять доставку, как в случае с Flume. AMQP, похоже, является еще одной движущейся частью с несколькими реализациями и без реального руководства по тому, что лучше всего работает в этом виде настройки. И я не совсем уверен, что смогу получить реальную сквозную надежность от logstash до elasticsearch, предполагая сбой серверов между ними. Решения разветвления снова приводят к проблеме дедупликации. Лучшее решение, которое могло бы справиться со всеми случаями, - это Beetle, который, похоже, обеспечивает высокую доступность и дедупликацию через хранилище Redis. Однако я не видел никаких указаний по настройке этого с помощью Logstash, и Redis - еще одна движущаяся часть для чего-то, что не должно быть ужасно сложным.
Logstash в ElasticSearch: Я мог бы запустить Logstash на всех серверах, иметь все правила фильтрации и обработки на самих серверах и просто заставить их регистрироваться непосредственно на удаленном сервере ElasticSearch. Я думаю, что это должно обеспечить мне надежное ведение журнала, и я могу использовать функции кластеризации ElasticSearch для прозрачного совместного использования базы данных. Однако я не уверен, действительно ли установка выдерживает перезагрузки Logstash и периодические сетевые проблемы без дублирования сообщений в случае аварийного переключения или аналогичных. Но такой подход звучит многообещающе.
rsync: Я мог бы просто синхронизировать все соответствующие файлы журналов с двумя разными серверами. Аспект надежности здесь должен быть идеальным, так как файлы должны быть идентичны исходным файлам после завершения синхронизации. Однако выполнение rsync несколько раз в секунду звучит неинтересно. Кроме того, мне нужно, чтобы журналы не подвергались повреждению после их отправки, поэтому rsync должны быть в режиме только для добавления. И ротация журналов все испортит, если я не буду осторожен.
rsyslog с RELP: Я мог бы настроить rsyslog для отправки сообщений на два удаленных хоста через RELP и иметь локальную очередь для хранения сообщений. Снова возникает проблема дедупликации, и сам RELP также может дублировать некоторые сообщения. Однако это будет обрабатывать только те вещи, которые регистрируются через системный журнал.
Ни одно из этих решений не кажется очень хорошим, и у них все еще есть много неизвестных, поэтому я прошу здесь дополнительную информацию у людей, которые установили централизованное надежное ведение журнала, о том, какие инструменты являются лучшими для достижения этой цели.
Я создатель LogZilla и мы совсем рядом с выпуском облачного решения Amazon EC2 для нашего программного обеспечения. Я был бы рад возможности обсудить ваши цели и возможность предоставить вам это решение. Если вам интересно, свяжитесь со мной.
Хотя я уверен, что вы могли бы использовать rsyslog, мы используем syslog-ng с tcp (вы также можете использовать tls-шифрование и дисковую буферизацию как для защиты, так и для обеспечения доставки сообщений).
Наши тестовые боксы отправляют до 3000 событий в секунду без потерь - и все это на микропроцессоре Amazon EC2 (заметьте, это не будет работать в производственной среде в основном из-за потребности в хранилище, но это свидетельство нашей работы. сделано).
Для HA было бы проще использовать два целевых сервера журналов, чем пытаться дедуплицировать их - тогда просто используйте тактовый сигнал между двумя серверами и не переключитесь на резервный, если основной перейдет в автономный режим. Вы по-прежнему можете выполнять дедупликацию, если хотите, но первое, как правило, намного проще в реализации и работает очень хорошо.
Синхронизация файлов, не относящихся к системному журналу, - это простой вопрос их синтаксического анализа с помощью Perl и отправки их по системному журналу с помощью Log :: Syslog :: Fast - пример этого включен в каталог contrib нашего программного обеспечения (проверьте svn, если вы хотите копия). Вы также можете просто скопировать их на сервер LogZilla и передать их прямо в наш препроцессор.