Ведение журнала MongoDB

Question

Я создаю систему регистрации, которая будет регистрировать запросы и ответы на веб-сервис, который распределен по нескольким узлам приложения. Я думал об использовании MongoDB в качестве репозитория и регистрации в режиме реального времени, или о более реалистичном сбрасывании журналов в БД после x количества запросов. Приложение предназначено для значительно большого объема и встроено в Perl. У кого-нибудь есть опыт в этом? Рекомендации? Или это нет-нет?

Answer 1

Я видел, что многие компании используют MongoDB для хранения логов.Его чистота схемы действительно гибка для журналов приложений, в которых схема имеет тенденцию меняться время от времени.Кроме того, его функция Capped Collection действительно полезна, поскольку она автоматически удаляет старые данные, чтобы сохранить их в памяти.

Люди объединяют журналы с помощью обычной группировки или MapReduce * 1006.*, но это не так быстроОсобенно MapReduce MongoDB работает только в пределах одного потока, и его накладные расходы на выполнение JavaScript огромны. Новая структура агрегации может решить эту проблему.

Другая проблема - высокая скорость записи через пут.Хотя вставка MongoDB по умолчанию работает по принципу «забей и забывай», при вызове большого количества команд вставки возникает острая проблема блокировки записи.Это может повлиять на производительность приложения и помешать читателям объединять / фильтровать сохраненные журналы.

Одним из решений может быть использование инфраструктуры сборщика журналов, например Fluentd , Logstash или Флюм .Предполагается, что эти демоны запускаются на всех узлах приложения и получают журналы от процессов приложения.

Они буферизируют журналы и асинхронно записывают данные в другие системы, такие как MongoDB / PostgreSQL / и т. Д. Запись выполняется пакетами, поэтому она намного эффективнее записипрямо из приложений.Эта ссылка описывает, как поместить журналы в программу Fluentd из Perl.

• Fluentd: импорт данных из приложений Perl

Answer 2

Я использую его в нескольких приложениях через Log :: Dispatch :: MongoDB ;работает как шарм!

# Declaration
use Log::Dispatch;
use Log::Dispatch::MongoDB;
use Log::Dispatch::Screen;
use Moose;

has log => (is => 'ro', isa => 'Log::Dispatch', default => sub { Log::Dispatch->new }, lazy => 1)

...

# Configuration
$self->log->add(
    Log::Dispatch::Screen->new(
        min_level   => 'debug',
        name        => 'screen',
        newline     => 1,
    )
);
$self->log->add(
    Log::Dispatch::MongoDB->new(
        collection  => MongoDB::Connection->new(
            host    => $self->config->mongodb
        )->saveme->log,
        min_level   => 'debug',
        name        => 'crawler',
    )
);

...

# The logging facility
$self->log->log(
    level   => 'info',
    message => 'Crawler finished',
    info    => {
        origin  => $self->origin,
        country => $self->country,
        counter => $self->counter,
        start   => $self->start,
        finish  => time,
    }
);

А вот пример записи из закрытой коллекции :

{
    "_id" : ObjectId("50c453421329307e4f000007"),
    "info" : {
            "country" : "sa",
            "finish" : NumberLong(1355043650),
            "origin" : "onedayonly_sa",
            "counter" : NumberLong(2),
            "start" : NumberLong(1355043646)
    },
    "level" : "info",
    "name" : "crawler",
    "message" : "Crawler finished"
}

Answer 3

Я сделал это в веб-приложении, которое работает на двух серверах приложений. Записи в mongodb по умолчанию не блокируют (драйвер java просто получает запрос для вас и возвращает его немедленно, я полагаю, что это то же самое для perl, но вам лучше проверить), что идеально подходит для этого варианта использования, так как вы не хотите ваши пользователи ждут записи журнала.

Недостатком этого является то, что в определенных сценариях сбоев вы можете потерять некоторые журналы (например, ваше приложение дает сбой, прежде чем Монго получит данные).

Answer 4

Для некоторых интересных идей для вашего приложения, я рекомендую проверить Graylog2 , если вы еще этого не сделали.Они используют комбинацию MongoDB и Elasticsearch довольно эффективно.Добавление мощного поискового движка в список может дать вам несколько интересных вариантов запросов и анализа.

Для справки приведена страница Elasticsearch , посвященная инструментам и методам обработки журналов.

Если вы планируете поставить в очередь записи журнала перед обработкой (что я бы порекомендовал), я предлагаю Kestrel в качестве надежной очереди сообщений.Это то, что использует Gaug.es, и в последнее время я проходил через это.Приложение Java, оно чрезвычайно быстрое и атомарное, и оно удобно говорит по протоколу Memcache.Это отличный способ масштабирования по горизонтали, а кэш-память резервируется в файл журнала для обеспечения оптимального баланса скорости и надежности.