Pull to refresh

Comments 14

А нормального его можно конфигурировать? Без менюшек и прочего web 2.0. А то как-то довольно трудно собирать логи с половины мира, накликивая конфигурацию.

Можно. Но если человек способен разобраться в api то подобные инструкции ему не нужны.
Одно другому не мешает. Те кто умеет разбираться с АПИ — это вовсе не люди, которые все делают мгновенно.
Тут нет никаких сакральных знаний, всё что здесь есть описано в доке. Api как бы подразумевает что нужно почитать доку.

У API есть огромный недостаток — нет версионности конфигурации: кто-то, что-то изменил и все сломал — теперь сиди разбирайся что произошло.


Мой взгляд, что такие системы должны конфигурироватся из конфигов.

Ну пиши в монгу напрямую.
Меня и веб, и апи устраивает.

Ну пиши в монгу напрямую.

И чем это отличается? Та же проблема остаётся.

Ну если это критическое требование, то тут 2 варианта либо грейлог не подходит, либо делать это раскладывая конфиги прям на машины своей автоматизацией.
Нас устроило и апи, и веб интерфейс, чего-то более удобного в плане централизованного управления мы не нашли.
А можно узнать подробнее, как конкретно у вас устроена подсистема хранения на нодах эластика? Hdd|SSD, рейды, объем, тюнинг эластика и т.п.
Обычные 11 HDD по 4Тб в 0 рейде,
Про тюнинг напишем следующую статью, но сам эластик особо не тюнили.
А какой рейт сообщений в секунду и какого они объема примерно? На сколько быстро ищет при запросе логов за 2 недели, например?
За 2 недели логи около полутора минут собираются по одному источнику.
У себя тоже используем Graylog для сбора логов от Nginx (около 40-50 разных параметров) и немножко ещё от другого ПО. В день у нас приходит чуть побольше данных, около 3-4ТБ со средним рейтом днём около 60-80к/сек. Но хранимый объём меньше, 4 дата ноды эластика с 4 SATA дисками по 2 ТБ + 2 рабочие ноды Graylog с 250ГБ журнала + 1 нода с мастерами и монгой. А из-за малого количества IOPs'ов приходится идти на разные ухищрения.
Sign up to leave a comment.