Понимание ведения журнала в облаке

Недавно я прочитал интересную пару из статей  о Logging Application в OpenShift. Хотя это отличные статьи о том, как использовать log4j и Apache Commons Logging , они вообще не решают проблему ведения журнала в облаке.

В чем проблема облачной регистрации?

Предположим, у меня есть приложение, которое я хочу развернуть в облаке. Я также хочу автоматически эластично масштабировать это приложение. На самом деле, я надеюсь, что это приложение будет успешным, а затем я хочу развернуть его в разных местах. Я использую EC2 для начинающих, но мне может понадобиться перенести его позже. Хорошо, это звучит немного ЯГНИ . Давайте урезать требования. Я запускаю свое приложение в облаке, на одном сервере в одном гео.

Я не хочу входить в локальную файловую систему.

Почему бы и нет? Ну, во-первых, если это, скажем, EC2, то сервер может быть остановлен, и я потеряю свои логи. Если он не  перезапустится, они будут расти и уничтожать мою локальную файловую систему. В любом случае, я в беспорядке.

Мне нужно регистрировать свои журналы где-нибудь, что:
1) предназначено для поддержки получения журналов из нескольких мест — например, в каком бы EC2 или другом экземпляре ни находился мой сервер сегодня
2) отдельно от моего рабочего экземпляра, чтобы, когда он останавливается и запускается, он живет
3) поддерживает правильную ротацию логов и т. Д.

Если у меня есть это, то он поддерживает мою первоначальную проблему, но на самом деле он также поддерживает мои большие требования, касающиеся автоматического масштабирования и гео.

Stratosэто платформа с открытым исходным кодом, основанная на платформе как услуга, которую мы создали на WSO2. В Stratos нам пришлось иметь дело с этим на ранней стадии, потому что мы поддерживаем эластичное автоматическое масштабирование по умолчанию.

В Stratos 1.x мы создали модель, основанную на syslog-ng . В основном мы использовали log4j для приложений для входа. Так что, как и при любой обычной регистрации в log4j, вы бы сделали что-то вроде:

Logger  logger = Logger.getLogger("org.fremantle.myApp");

logger.warn("This is a warning");

Мы автоматически настраиваем приложения журнала в службах Stratos для использования приложения log4j syslog . Когда мы запускаем экземпляр, мы автоматически настраиваем его под прикрытием, чтобы передать вывод syslog в syslog-ng. Затем мы автоматически сопоставляем эти журналы и делаем их доступными.

В Stratos 2.x мы улучшили это.
Модель syslog-ng не так эффективна, как нам нужно, а также нам нужен был лучший способ нарезки и нарезки результирующих файлов журнала.

В Stratos PaaS у нас также есть другое ключевое требование — мультитенантность. У нас есть много экземпляров серверов, некоторые из которых по одному экземпляру на каждого арендатора / домен, а некоторые совместно используются арендаторами. В обоих случаях нам нужно разделить журналы, чтобы каждый арендатор видел только свои журналы.

Таким образом, в Stratos 2.x (в ближайшие пару месяцев) у нас есть простой интерфейс Apache Thrift (и JSON / REST тоже). У нас уже есть цель log4j, которая подталкивает к этому. Таким образом, тот же код, что и выше, работает в Stratos 2.x без изменений.  Мы также собираемся добавить модели для не-Java (например, syslog, log4php и т. Д.). Теперь, что происходит дальше? Локальный агент в экземпляре облака настраивается автоматически для публикации на локальном центральном сервере журналов. Это берет журналы и публикует их в базе данных Apache Cassandra . Затем мы запускаем скрипты Apache Hive, которые нарезают журналы для каждого клиента и для каждого приложения. Затем они становятся доступны пользователю через наш веб-интерфейс, а также через простые сетевые вызовы. Почему эта модель? Это действительно