Size: a a a

2020 January 20

АК

Александр Крыжановский in E.L.K.
добрый всем день.
есть 11 документов
в них значения поле1 неуникальны
соответственно, делая аргрегацию terms по поле1 я получаю список из значений поле1 и рядом количество документов где значение поле1 совпадает
есть поле2, в нем кусок текста
я пытаюсь для каждого документа с поле1 вывести в ответе также и поле2
делаю субагрегацию terms по поле2
и вмето того чтобы получить 11 пар поле1 - поле2
я получаю 3 пары для документов с одним значением поле1, остальные доки с поле1 как бы игнорируются
что я могу делать не так?
источник

АК

Александр Крыжановский in E.L.K.
добрый всем день.
аггрегация по полю значение в котором длиннее 255 символов возвращает пустое значение.
кто знает как обойти?
источник

R

Reykjanes in E.L.K.
Добрый день!
Судя по всему, рисуете таблицу?
источник

АК

Александр Крыжановский in E.L.K.
да
источник

АК

Александр Крыжановский in E.L.K.
в консоли возвращает пустой массив "buckets" : [ ] без ключей
источник

АК

Александр Крыжановский in E.L.K.
так что не только при построении таблицы проявляется
источник
2020 January 21

SR

Stanislav Renskiy in E.L.K.
Привет.
У куратора в рамках одного action количество  filtertype ограничено или нет?
источник

MP

Mike Pulman in E.L.K.
по-моему нет
источник

КВ

Климов Вячеслав in E.L.K.
Коллеги, доброго дня.
Существует задача собирать логи с приложений размазанных по разным странам в один кластер ELK
В роли отправителей логов - само приложений (php или java и filebeat)
rtt между logstash центрального кластера и самыми удаленными приложениями порядка 100-130 ms
у меня есть опасение что отправка метрик с приложения будет притормаживать, тем самым сильно замедлять исполнение учатсков кода  из-за rtt между кластером и самим приложением
а так же что я могу словить какие-либо странности с filebeat
нагрузка до 8keps

возникла идея как то буфиризировать логи по ближе к проекту и уже потом досылать их в центральный кластер
в качестве реализации смотрю на :
1)локальный logstash принимает логи и перенаправляет их в центральный logstash
2)локальный logstash принимает логи и складывает их в redis, дальше центральный logstash забирает их из redis


что посоветуете под мою задачу?
источник

D

Dmitriy in E.L.K.
в первую очередь, я бы посоветовал вынести все непрофильное и долговыполняющееся в коде в отдельные потоки, а то я уже устал смеяться над нашими кодерами... перезапускаем шлюз трассировок - падает интернет-банк) но если изменение ПО невозможно - то да, схема рабочая. не особо понятно, зачем там редис, но если есть желание - почему нет?
источник

Н

Николай in E.L.K.
как буфер. ксли чтото отвалится
источник

Н

Николай in E.L.K.
можно редис. можно кролика
источник

D

Dmitriy in E.L.K.
да у тебя и в логстеше есть...
источник

Н

Николай in E.L.K.
не такой большой
источник

D

Dmitriy in E.L.K.
поставь диск побольше)
источник

MA

M A in E.L.K.
Климов Вячеслав
Коллеги, доброго дня.
Существует задача собирать логи с приложений размазанных по разным странам в один кластер ELK
В роли отправителей логов - само приложений (php или java и filebeat)
rtt между logstash центрального кластера и самыми удаленными приложениями порядка 100-130 ms
у меня есть опасение что отправка метрик с приложения будет притормаживать, тем самым сильно замедлять исполнение учатсков кода  из-за rtt между кластером и самим приложением
а так же что я могу словить какие-либо странности с filebeat
нагрузка до 8keps

возникла идея как то буфиризировать логи по ближе к проекту и уже потом досылать их в центральный кластер
в качестве реализации смотрю на :
1)локальный logstash принимает логи и перенаправляет их в центральный logstash
2)локальный logstash принимает логи и складывает их в redis, дальше центральный logstash забирает их из redis


что посоветуете под мою задачу?
редис как буфер вполне сгодится для этой задачи. Минус в том, что для большого кол-ва инсталляций логсташа будет потрачен дополнительный вычислительный ресурс + мониторинг + поддержка одинаковых конфигов + обновление. Проще использовать syslog-ng с отправкой логов в редис, из которого потом будет забирать логсташ с центрального сервера(ов)
источник

КВ

Климов Вячеслав in E.L.K.
Dmitriy
в первую очередь, я бы посоветовал вынести все непрофильное и долговыполняющееся в коде в отдельные потоки, а то я уже устал смеяться над нашими кодерами... перезапускаем шлюз трассировок - падает интернет-банк) но если изменение ПО невозможно - то да, схема рабочая. не особо понятно, зачем там редис, но если есть желание - почему нет?
что бы не потерять логи в случае проблем со связью между центральным кластером и приложением
источник

D

Dmitriy in E.L.K.
Климов Вячеслав
что бы не потерять логи в случае проблем со связью между центральным кластером и приложением
выше уже писал - в логстеше вполне компактный буфер, использовал - полет нормальный
источник

КВ

Климов Вячеслав in E.L.K.
Dmitriy
выше уже писал - в логстеше вполне компактный буфер, использовал - полет нормальный
сколько Keps ?
источник

D

Dmitriy in E.L.K.
ммм... что есть keps?)
источник