ребята в проекте хотят слать напрямую в ES аудит логи. Какие могут быть риски ? Вообще я чувствую, мне хотелось бы заюзать как то nginx тут и просто проксировать траффик на еластиксерч, возможно на уровне нжинкс можно сделать какой то редирект трафика в бэкграунд режиме ? А сервера, которые за апи отвечают хотелось бы освободить от такой работы
imho никаких рисков. Ведь и logstash и filebeat тоже льют напрямую в ES и он как-то справляется...
Да лааадно, начнут слать по одному документу за запрос - придёт труба эластику. Начнут ещё какое-то говно делать - тоже будет весело, и зарезать может быть нетривиальная задача. А если надо что-то потом изменить - ух весёлая задачка без промежуточного звена
в исходном сообщении не указано как будут лить)) Может и через bulk. Но я бы отправлял по классике - в логстэш, а он уже сам разберётся
Вот именно что не сказано, а Вы бодро человеку заявляете что никаких рисков :)
у меня есть пример под рукой где с эластиком работают и напрямую, без bulk api. Пару тысяч ops держит. Рисков не вижу - потребуется, будем переписывать на bulk методы
сорян, глупый вопрос - logstash делает все операции с логами в фоновом режиме ? то есть когда ему шлются какие то данные, он их куда то складирует и потом шлет в фоновом режиме ?
Он умеет аггрегировать в памяти и отсылать пачкой (делает это по умолчанию). Касательно складирования на диске - по умолчанию не делает вроде, но такой функционал есть, кажется persistent queue называется
я имею ввиду - чтобы он не делал эти операции - отсылку в еластиксерч прямо во время приема данных, чтобы не замедлять работу приложения, которое ему туда шлет что то
он может сложить их в постоянную очередь рядом с собой, может сразу пачкой(подержав чуток в памяти) отправить напрямую в ES, может сложить в кафку.
но для приложения отправившего логи в логстэш это уже будет фоновый режим, да
Обсуждают сегодня