Kibana-мать или Зачем вам вообще нужны логи?

    Вы можете сказать, что “иногда бывает нужно...” Но на самом деле, вы хотите всегда видеть, что у вас в логах, через графический интерфейс. Это позволяет:

    • Облегчить жизнь разработчикам и сисадминам, время которых просто жалко и дорого тратить на написание grep-конвейеров и парсеров под каждый отдельный случай.
    • Предоставить доступ к информации, содержащейся в логах, умеренно-продвинутым пользователям — менеджерам и техподдержке.
    • И видеть динамику и тенденции появления залогированых событий (например, ошибок).

    Так что сегодня вновь поговорим о стэке ELK (Elasticsearch+Logstash+Kibana).
    Но на этот раз — в условиях json-логов!

    Такой use case обещает наполнить вашу жизнь совершенно новыми красками и заставит испытать полную гамму чувств.



    Пролог:

    «Пойми, на Хабрахабре только и разговоров, что о Kibana и Elasticsearch. О том, как это чертовски здорово — наблюдать, как огромный текстовый лог превращается в красивые графики, а еле видимая нагрузка на CPU горит где-то в глубине top-а. А ты?.. Что ты им скажешь?»


    Матчасть


    В жизни каждого нормального пацана возникает момент, когда он решил-таки поставить на своем проекте связку ELK.

    Схема среднестатистического пайплайна выглядит примерно так:


    Мы шлём в Kibana 2 вида логов:

    1. “Почти обычный” лог nginx. Единственная его изюминка – request-id. Их мы будем генерировать, как сейчас модно, с помощью Lua-в-конфиге™ .
    2. “Необычные” логи самого приложения на node.js. То есть лог ошибок и “продлог”, куда летят “нормальные” события — например, “пользователь создал новый сайт”.

      Необычность этого типа логов в том, что он:
      • Сериализованный json (логирует события npm-модуль bunyan)
      • Бесформенный. Набор полей у сообщений разный, кроме того, в одних и тех же полях у разных сообщений могут быть разные типы данных (это важно!).
      • Очень жирный. Длина некоторых сообщений превышает 3Мб.

    Это, соответственно, front- и back-end-ы всей нашей системы… Приступим!

    filebeat
    filebeat.yml:
    Описываем пути к файлам и добавляем к сообщениям поля, которые нам понадобятся для определения типов логов на этапе фильтрации и при отправке в ES.

    filebeat:
      prospectors:
        - 
          paths:
            - /home/appuser/app/production.log.json
          input_type: log
          document_type: production
          fields:
            format: json
            es_index_name: production
            es_document_type: production.log
        - 
          paths:
            - /home/appuser/app/error.log.json
          input_type: log
          document_type: production
          fields:
            format: json
            es_index_name: production
            es_document_type: production.log
        - 
          paths:
            - /home/appuser/app/log/nginx.log
          input_type: log
          document_type: nginx
          fields:
            format: nginx
            es_index_name: nginx
            es_document_type: nginx.log
      registry_file: /var/lib/filebeat/registry
    output:
      logstash:
        hosts: ["kibana-server:5044"]
    shipper:
      name: ukit
      tags: ["prod"]
    logging:
      files:
        rotateeverybytes: 10485760 # = 10MB
    



    logstash
    logstash-listener/01-beats-input.conf:
    input {
      beats {
        port => 5044
      }
    }
    


    logstash-listener/30-rabbit-output.conf:
    output {
            rabbitmq {
                exchange => "logstash-rabbitmq"
                exchange_type => "direct"
                key => "logstash-key"
                host => "localhost"
                port => 5672
                workers => 4
                durable => true
                persistent => true
            }
    }
    


    logstash-indexer/01-rabbit-input.conf:
    input {
      rabbitmq {
          host => "localhost"
          queue => "logstash-queue"
          durable => true
          key => "logstash-key"
          exchange => "logstash-rabbitmq"
          threads => 4
          prefetch_count => 50
          port => 5672
      }
    }
    


    logstash-indexer/09-filter.conf:
    В зависимости от формата, прогоняем его через соответствующий кодек.

    В случае с nginx, это будут вот такие “необычные” регулярки-полуфабрикаты, предлагаемые фильтрующим модулем “grok” (слева), и названия полей, в которые попадут заматченые данные (справа). Для пущей красоты у нас есть еще фильтр geoip, который определяет локацию клиента. В Кибане можно будет сделать “географию” клиентов. Базу качаем отсюда dev.maxmind.com/geoip/legacy/geolite.

    А в случае с json, как видите, ничего делать вообще не надо, что не может не радовать.

    filter {
      if [fields][format] == "nginx" {
            grok {
                    match => [
                      "message", "%{IPORHOST:clientip} - \[%{HTTPDATE:timestamp}\] %{IPORHOST:domain} \"(?:%{WORD:verb} %{NOTSPACE:request}(?: HTTP/%{NUMBER:httpversion})?|%{DATA:rawrequest})\" %{NUMBER:status:int} (?:%{NUMBER:bytes:int}|-) %{QS:referrer} %{QS:agent} %{NUMBER:request_time:float} (?:%{NUMBER:upstream_time:float}|-)( %{UUID:request_id})?"
                    ]
            }
            date {
                    locale => "en"
                    match => [ "timestamp" , "dd/MMM/YYYY:HH:mm:ss Z" ]
            }
            geoip {
                    source => "clientip"
                    database => "/opt/logstash/geoip/GeoLiteCity.dat"
            }
      }
      if [fields][format] == "json" {
        json {
                    source => "message"
        }
      }
    }
    


    logstash-indexer/30-elasticsearch-output.conf:
    Имя индекса и document_type для ES берем из полей, которые в самом начале пути приклеили к сообщениям в filebeat-е.

    output {
            elasticsearch {
                    hosts => ["localhost:9200"]
                    index => "logstash-%{[fields][es_index_name]}-%{+YYYY.MM.dd}"
                    document_type => "%{[fields][es_document_type]}"
            }
    }
    



    Связывание событий в логах фронта и бэка


    Завязка:

    “У нас было 2 типа логов, 5 сервисов в стэке, полтерабайта данных в ES, а также несчетное множество полей в логах приложений. Не то чтобы это был необходимый набор для риалтайм-анализа состояния сервиса, но когда начинаешь задумываться еще и о связывании событий nginx-а и приложения, становится сложно остановиться.

    Единственное, что вызывало у меня опасения — Lua. Нет ничего более беспомощного, безответственного и порочного, чем Lua в конфигах Nginx. Я знал, что рано или поздно мы перейдем и на эту дрянь”.



    Для генерации request-id на Nginx-е будем использовать Lua-библиотеку, которая генерирует uuid-ы. Она, в целом, справляется со своей задачей, но пришлось немного доработать ее напильником — ибо в первозданном виде она (та-дам!) дуплит uuid-ы.

    http {
    ...
    # Либа для генерации идентификаторов запросов
    lua_package_path '/etc/nginx/lua/uuid4.lua';
    init_worker_by_lua '
        uuid4 = require "uuid4"
        math = require "math"
    ';
    ...
    # Объявляем переменную request_id, 
    # обычный способ (set $var) не будет работать в контексте http
    map $host $request_uuid { default ''; }
    
    # Описываем формат лога
    log_format ukit  '$remote_addr - [$time_local] $host "$request" '
                        '$status $body_bytes_sent "$http_referer" '
                        '"$http_user_agent" $request_time '
                        '$upstream_response_time $request_uuid';
    
    # Путь к файлу и формат лога
    access_log    /home/appuser/app/log/nginx.log ukit;
    }
    
    server { 
    ...
    	# Генерируем id запроса
    set_by_lua $request_uuid '
            if ngx.var.http_x_request_id == nil then
                return uuid4.getUUID()
            else
                return ngx.var.http_x_request_id
            end
    ';
    
    	# Отправляем его в бекэнд в виде заголовка, чтобы он у себя тоже его залогировал.
    	location @backend {
                proxy_pass       http://127.0.0.1:$app_port;
                proxy_redirect   http://127.0.0.1:$app_port http://$host;
                proxy_http_version 1.1;
                proxy_set_header Connection "";
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Nginx-Request-ID $request_uuid; #id запроса
                proxy_set_header Host $host;
                ...
            }
    ...
    }
    


    На выходе получаем возможность по событию в логе приложения найти повлекший его запрос, прилетевший на Nginx. И наоборот.

    Довольно быстро обнаружилось, что наши “вселенски-уникальные” айдишники не такие уж уникальные. Дело в том, что randomseed библиотека берет из таймстампа на момент запуска nginx-воркера. А воркеров у нас столько, сколько ядер у процессора, и запускаются они одновременно… Не беда! Подмешаем туда pid воркера и будет нам счастье:

    ...
    local M = {}
    local pid = ngx.worker.pid()
    -----
    math.randomseed( pid + os.time() )
    math.random()
    ...
    

    P.S. В репозитарии Debian-а есть готовый пакет nginx-extras. Там сразу есть Lua и еще куча полезных модулей. Рекомендую, вместо того чтобы вкомпиливать модуль Lua руками (еще бывает openresty, но я не пробовал).

    Группировка ошибок по частоте возникновения.


    Kibana позволяет группировать (строить рейтинги) событий на основе одинаковых значений полей.

    В логе ошибок у нас есть стэктрейсы, они почти идеально подходят в качестве ключа группировки, но загвоздка в том, что в Кибане нельзя группировать по ключам длиннее 256 символов, а стэки конечно длиннее. Поэтому мы делаем md5-хэши стэктрейсов в bunyan и группируем уже по ним. Красота!

    Так выглядит топ 20 ошибок:


    И отдельно взятый тип ошибки на графике и списком эпизодов:


    Теперь мы знаем, какой баг в системе можно пофиксить когда-нибудь потом, т.к. он слишком редкий. Согласитесь, такой подход куда научнее, чем “за эту неделю было много подобных тикетов в саппорт”.

    А теперь — срыв покровов: оно работает, но плохо


    Кульминация:

    «Я понимаю. Ты нашёл в NoSQL рай: у тебя быстро шла разработка, ведь ты хранил все в MongoDB, и тебе не нужны были такие друзья, как я. А теперь, ты приходишь и говоришь: мне нужен поиск. Но ты не просишь с уважением, ты даже не называешь меня Лучшим Поисковым Движком. Нет, ты приходишь ко мне в дом в день рождения Lucene и просишь меня индексировать неструктурированные логи бесплатно»



    Неожиданности

    Все ли сообщения из лога попадают в Кибану?

    Нет. Не все попадают.

    Маппинг запоминает название поля и его тип (число, строка, массив, объект и т.д.). Если мы посылаем в ES сообщение, в котором есть поле, уже существующее в маппинге, но тип не совпадает с тем, что было в этом поле раньше (например, в маппинге — массив, а пришел объект), то такое сообщение не попадет в ES, а в его логе будет не слишком очевидное сообщение:

    {«error»:«MapperParsingException[object mapping for [something] tried to parse as object, but got EOF, has a concrete value been provided to it?]»
    Источник

    Имена полей в json-логах

    Elasticsearch v2.x не принимает сообщения, в которых есть поля, имена которых содержат точки. В v1.x этого ограничения не было, и мы не можем перейти на новую версию, не переделав все логи, т.к. у нас такие поля уже “исторически сложились”.
    Источник

    Кроме того, в Kibana не поддерживаются поля имена которых начинаются с подчеркивания ‘_’.


    Комментарий разработчика

    Автоматическое уползание данных в соседние инстансы ES

    По-умолчанию в ES включена опция Zen Discovery. Благодаря ей, если вы запустите несколько инстансов ES в одной сети (например, несколько докер-контейнеров на одном хосте), то они друг друга найдут и поделят данные между собой. Очень удобный способ смешать продуктивные и тестовые данные и долго с этим разбираться.

    Оно падает и потом долго поднимается. Это еще больнее, когда docker


    Стэк вовлеченных в нашу преступную схему демонов достаточно многочисленен. Кроме того, некоторые из них любят непонятно падать и очень долго подниматься (да, те, что на Java). Чаще всех зависает logstash-indexer, в логах при этом тишина или неудачные попытки послать данные в ES (видно, что они были давно, а не вот только что). Процесс жив, если послать ему kill — он очень долго умирает. Приходится слать kill -9, если некогда ждать.

    Реже, но тоже бывает, что падает Elasticsearch. Делает он это “по-английски” (т.е. молча).

    Чтобы понять, кто из них двоих упал, делаем http-запрос в ES — если ответил, значит лежит не он. Кроме того, когда у вас относительно много данных (скажем, 500G), то ваш Elasticsearch после запуска будет еще около получаса просасывать эти данные, и в это время они будут недоступны. Данные самой Kibana хранятся там же, поэтому она тоже не работает, пока ее индекс не подхватится. По закону подлости, до нее обычно очередь доходит в самом конце.

    Приходится мониторить мониторингом длину очереди в rabbitmq, чтобы оперативно реагировать на инциденты. Раз в неделю они стабильно случаются.

    А когда у вас всё в docker-е, и контейнеры слинкованы между собой, то вам нужно перезапустить еще и все контейнеры которые были слинкованы с контейнером ES, кроме него самого.

    Большие дампы памяти при OOM

    По-умолчанию в ES включена опция HeapDumpOnOutOfMemoryError. Это может привести к тому, что у вас неожиданно закончилось место на диске из-за одного или нескольких дампов размером ~30GB. Сбрасываются они, разумеется, в директорию, где лежат бинарники (а не туда, где данные). Происходит это быстро, мониторинг даже не успевает прислать смс-ку. Отключить это поведение можно в bin/elasticsearch.in.sh.

    Производительность


    В Elasticsearch существует т.н. “маппинг” индексов. По-сути, это схема таблицы, в которой хранятся данные в формате “поле — тип”. Создается она автоматически на основе поступающих данных. Это значит, что ES запомнит имя и тип данных поля, исходя из того, данные какого типа пришли в этом поле в первый раз.

    Например, у нас есть 2 очень разных лога: access-log nginx и production-log nodejs-приложения. В одном стандартный набор полей, он короткий, типы данных никогда не меняются. В другом же, напротив, полей много, они nested, они свои у каждой строчки лога, названия могут пересекаться, данные внутри полей могут быть разных типов, длина строки доходит до 3 и более Mб. В итоге автомаппинг ES делает так:

    Маппинг здорового “прямоугольного” лога nginx:
    root@localhost:/ > du -h ./nginx.mapping
    16K ./nginx.mapping

    Маппинг курильщика “бесформенного” json-лога нашего приложения:
    root@localhost:/ > du -h ./prodlog.mapping
    2,1M ./prodlog.mapping

    В общем, оно сильно тормозит как при индексации данных, так и при поиске через Kibana. При этом, чем больше накопилось данных, тем хуже.

    Мы пытались бороться с этим закрытием старых индексов c помощью curator. Положительный эффект безусловно есть, но все-таки это анестезия, а не лечение.

    Поэтому мы придумали более радикальное решение. Весь тяжелый nested-json в production-логе отныне будет логироваться в виде строки в специально-отведенном одном поле сообщения. Т.е. вот прямо JSON.stringify(). За счет этого набор полей в сообщениях становится фиксированным и коротким, мы приходим к “легкому” маппингу как у nginx-лога.

    Конечно, это своего рода “ампутация с дальнейшим протезированием”, но вариант рабочий. Будет интересно увидеть в комментариях, как еще можно было сделать.

    Промежуточный итог


    Стэк ELK — классный инструмент. Для нас он стал просто незаменимым. Менеджеры следят за всплесками ошибок на фронтэнде после очередного релиза и приходят жаловаться к разработчикам уже “не с пустыми руками”. Те, в свою очередь, находят корреляции с ошибками в приложении, сразу видят их стэки и прочие важнейшие данные, необходимые для дебага. Есть возможность моментально строить различные отчеты из серии “хиты по доменам сайтов” и т.п. Словом, непонятно как мы жили раньше. Но с другой стороны…

    “Robust, Reliable, Predictable” — все это не про ELK. Cистема очень капризная и богатая на неприятные сюрпризы. Очень уж часто приходится копаться во всем этом шатком, извините, Jav-не. Лично я не могу припомнить технологию, которая бы так плохо следовала принципу “настроил и забыл”.

    Поэтому за последние 2 месяца мы полностью переделали логи приложения. Как в плане формата (избавляемся от точек в именах, чтобы перейти на ES v.2), так и в плане подхода к тому, что вообще логировать а что нет. Сам по себе этот процесс, имхо, абсолютно нормальный и логичный для такого проекта, как наш — недавно uKit отпраздновал свой первый день рождения.

    «В начале пути вы сваливаете в логи как можно больше инфы, т.к. заранее неизвестно, что понадобится, а потом, начав „взрослеть“, постепенно убираете лишнее». (c. pavel_kudinov)
    uKit Group
    46,00
    Конструкторы и решения для сайтов на ваш выбор
    Поделиться публикацией

    Комментарии 23

      0
      А вот расскажите мне, что вы делаете с ситуацией, когда по клику на строчку лога в кибане, она разворачивается, меняется размер колонок и текущая строчка (развёрнутая) улетает фиг знает куда? Сейчас это основное, что меня раздражает.
        0
        У меня такого, вроде бы, не происходит. Может, зависит от версии Кибаны и от размера экрана (там есть адаптивность). Скриншотом можете показать о чем речь?
        0
        Кроме того, когда у вас относительно много данных (скажем, 500G), то ваш Elasticsearch после запуска будет еще около получаса просасывать эти данные, и в это время они будут недоступны.

        Если не ошибаюсь — можно настроить число потоков, которые обрабатывают данные при рестарте эластика, и запуск будет происходить в разы быстрее?
          0
          Не уверен, какие именно треды вы имеете ввиду, но недоутилизированности ядер при этом не наблюдали — все были в потолок. На сегодняшний день просто curator-ом закрываем всё что старше 2-х месяцев (делаем close) и ES поднимается в приемлемый срок (до 5 минут).
          +2
          Я получил на поддержку ELK комплект, настроенный другими людьми. Там задействована кибана 3 (которая полностью живет на клиенте) и логсташ 1.0.1 (который не просто проапгрейдить, потому как завязан на версию логсташа из-за elasticsearch output-а). В этой системе используются индексы за день, так как при переключении на часовые индексы у кибаны начинаются проблемы с длиной урла. Логи хранятся за 2 недели. Из-за размера индекса перезагрузка инстанса elasticsearch занимает около суток (пока кластер опять не станет зеленым). В качестве входного буфера используется редис, емкости которого хватает минут на 40, потом начинаем терять логи. Я построил альтернативную систему: взял elasticsearch 1.74, kibana 4, переключился на часовые логи, стал хранить 3 дня логов и стал использовать кафку вместо редиса — стало лучше. Из-за сокращения времени хранения было решено сделать еще архивирование в хадуп кластер для доступа к старым данным. Последний пункт затянулся и вышел elasticksearch 2.x и вот тогда началось веселье. Для начала они поломали трайб ноды, а я их использовал для агрегации данных из разных датацентров. После некоторого общения худо-бедно починили. Потом оказалось, что новый elasticsearch не терпит конфликтов типов в отличие от 1.х. У меня приложений много, привести все к единообразию практически не возможно, стал писать лог каждого приложения в отдельный индекс — поплыла стабильность. Эмпирически выяснил, что критичным является количество шард. Количество документов влияет на стабильность гораздо меньше. После гугления и экспериментов выяснил, что ситуацию спасают выделенные elasticsearch master ноды. Стал поднимать, оказалось, что эти машины должны быть достаточно мощные, более-менее стабильных результатов удалось достичь с 3-мя мастерами 4 ядра 8 гб памяти, что обидно, потому как в каждый момент времени работает только один, остальные просто сидят на подхвате и тратят память. Ну и на сладкое наступил на грабли с точками в именах полей. Изменить это я не могу, попробовал использовать рекомендуемый фильтр de_dot — просела производительность. Пытался общаться с представителями elasticsearch, но они мне сразу сказали, что на мои вопросы будут отвечать если мы купим у них поддержку. Начал вести переговоры о покупке — ребята вообще пропали. В сухом остатке — очень много головной боли. Да, когда оно работает — очень удобно. Но уверенности в стабильности системы нет. Мы видимо будем переходить на систему, где elasticsearch будет держать только несколько последних часов логов плюс логи в хадупе, которые можно будет обработать при помощи map-reduce job-ов.
            +3
            Во-первых, соболезную.
              +2
              Во-вторых, наверное, у вас очень много логов и довольно-таки экономичное железо. Для сравнения, у нас ELK живет на 16 ядрах и 31 Гб памяти (индексы дневные).
              В-третих, de_dot… Вообще, с ним всё заранее понятно, такое нельзя делать быстро. Ну и он умеет ровно один уровень вложенности, что нам не подходило сразу, хотя если бы умел это было бы еще в 100 раз медленнее, по-этому пришлось убирать саму вложенность ;-).
                0
                У меня кластер из 10 физических машин 24 ядра 48гб памяти плюс 3 мастера на витруалках 4 ядра 8гб. Сегодня, к слову прорезались ребята из elastic. Я попросил их оценить что нам нужно, чтобы обрабатывать 400к логов/с 130мб/с логов в пике (в среднем 250к логов/с и 80мб/с) при средней длине лога 1к и хранении 2-х недель логов. Они мне написали, что 500 машин с 64гб. Я уточнил, а что если логи храним 3 дня и у машин 128гб. Оказалось, что достаточно 15 нод на данные плюс 3 мастера. Они также мне объяснили, что исходят из 1гб памяти на 32 гб на диске. Все это звучит подозрительно, но получил добро от начальства на эксперимент, заказал дополнительную память для кластера — посмотрим, как оно себя поведет.
                  0
                  Все это звучит подозрительно

                  Да, уж. Интересно что из этого получится, было бы очень интересно узнать (спасибо заранее).

                  Мы, вот, буквально вчера обесточили логи (в смысле, точки убрали) и стали слать их в ES v2. По первым ощущениям — сильно меньше грузит CPU и память. Хотя, конечно, могло сильно повлиять еще то что убрали вложенность и то что данных пока мало.
            +1
            Я использую похожую связку — rsyslog + graylog, и influxdb на подхвате. Генерацией uuid занимается первый из бэкэндов, куда попадает запрос. Логи nginx нигде не используются поэтому необходимости lua в nginx пока нет. Приложения пишут параллельно в файл и в rsyslog в разных форматах (и в файл уровень логирования выше). Далее rsyslog всё отправляет в graylog. Единственная пока проблема, по какой то причине так и не удалось настроить триггеры в graylog, они просто ни на что не реагируют.
              +2
              Интересно. А из файла graylog не умеет? А (nested) json?
              Насчет lua в nginx, на самом деле, это не первое грехопадение, давно мы уже… перешли на него. Есть ряд "мелких, файловых" вещей из-за которых не хотелось лишний раз трогать бакэнд. У нас вообще, проект скорее жив чем мертв при лежачем бакэнде.
              Вероятно, об этом пойдет речь в следующих статьях (если интересно).
              0
              Спасибо за статью, интересно. Года полтора назад я собирал сервер логирования logstash+elasticsearch данные отправлял из rsyslog-а на прямую, а так же из apach-а перенаправлением вывода в nc. Logstash+elasticsearch работали не очень стабильно с течением времени и объёма логов. Так же строил различные счётчики и визуализировал с помощью graphite. Теперь судя по всему, проект сильно развился с тех пор, нужно будет взглянуть ещё раз.
                +1
                Вам спасибо, за внимание.

                Я примерно на тех же версиях начинал первые тесты. Развились Logstash и Elasticsearch, похоже сильно, но только с переходом на v2. На v.1 я особых улучшений не заметил. Кибана тоже полностью преобразилась в 4-й версии (причем в обе стороны), мы долго привыкали. Но самое приятное для меня что появилось с тех пор это filebeat. Сколько было мучений с logstash-forwader-ом, сначала Go поставь, собери бинарник, сертификат сделай, и он ему еще и не нравится. Были даже спец. утилиты на гитхабах которые генерировали сертификат специально "чтобы нравился lоgstash-forwarder-у". Потом его даже форкнули в "log-courier" и выпилили обязательность шифрования).

                Другие "beats" кстати тоже пока не пробовали. Возможно, будем (и расскажем).
                0
                За картинку — плюсик.
                  0
                  Товарищи, у кого-нибудь был опыт промышленной эксплуатации elasticsearh на винде? Есть ли какие-либо особенности?
                    0
                    P.S. В репозитарии Debian-а есть готовый пакет nginx-extras. Там сразу есть Lua и еще куча полезных модулей. Рекомендую, вместо того чтобы вкомпиливать модуль Lua руками

                    Только этот пакет собран с поддержкой стандартного Lua интерпретатора. Для использования LuaJIT компилятора придётся его пересобрать.
                      0
                      А можно поподробнее? Я наивно считал что раз nginx-extras тянет за собой libluajit, то jit всё-таки там используется. Это не так?
                        0
                        Можно проверить используется jit или нет http://stackoverflow.com/questions/19056429/how-to-check-if-nginx-uses-luajit-and-not-lua Мне пришлось пересобирать extras пакет для работы с LuaJIT.
                          0
                          У меня выдало LuaJIT 2.0.4 на сервере с debian 7. Nginx-extras ставил с официального репа. В любом случае, спасибо за инфу.
                      0
                      Кажется вы переизобретаете graylog. Но в нем тоже не хватает части, которая будет следить за типами полей.

                      когда у вас относительно много данных (скажем, 500G), то ваш Elasticsearch после запуска будет еще около получаса просасывать эти данные

                      320Гб, 1 минута 13 секунд:

                      [ ei-grad@ei-grad ~/repos/deal/devops git:master* ]
                      → du -sh /var/lib/elasticsearch 
                      320G    /var/lib/elasticsearch
                      [ ei-grad@ei-grad ~/repos/deal/devops git:master* ]
                      → docker kill compose_elasticsearch_1
                      compose_elasticsearch_1
                      [ ei-grad@ei-grad ~/repos/deal/devops git:master* ]
                      → docker start compose_elasticsearch_1
                      compose_elasticsearch_1
                      [ ei-grad@ei-grad ~/repos/deal/devops git:master* ]
                      → time (while [ `http :9200/_cluster/health | jq .status` != '"green"' ]; do sleep 1; done)
                      ( while [ `http :9200/_cluster/health | jq .status` != '"green"' ]; do; sleep)  12,67s user 0,94s system 18% cpu 1:12,43 total

                      Это с дефолтным "cluster.routing.allocation.node_initial_primaries_recoveries: 4". Если у вас SSD — можно увеличить хоть до 1000. Но лучше уменьшить количество индексов и шардов.
                        0
                        А это на каком (хотя бы примерно) железе? И какие индексы, дневные/месячные/… ?
                        0
                        Народ, кто-нить может дать ссылку на нормальный полный туториал по kibana 4?
                        Такое ощущение, что зря на 4ую перешел… визуализация ущербная или я не все изучил
                          +1
                          Народ, кто-нить может дать ссылку на нормальный полный туториал по kibana 4?

                          https://www.elastic.co/guide/en/kibana/current/index.html

                          Такое ощущение, что зря на 4ую перешел…

                          У нас тоже так было. Что-то там было совсем нельзя, что-то частично, а что-то появлялось с новыми минорными релизами Кибаны.

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое