Five years ago Manticore began as a fork of an open source version of the once popular search engine Sphinx Search. We had two bags of grass, seventy-five pellets of mescaline, three C++ developers, a support engineer, a power user of Sphinx Search / backend team lead, an experienced manager, a mother of five helping us part-time, and a ton of bugs, crashes, and technical debts. So we got a shovel and other digging tools and started working to get it up to the search engine industry standards. Not that Sphinx was impossible to use, but many things were missing, and existing features weren’t quite stable or mature. And we had pushed it about as far as we could. So after 5 years and hundreds of new users, we’re ready to say that Manticore Search can be used as an alternative to Elasticsearch for both full-text search and (now) data analytics too.
Среди требований была поддержка полнотекстового поиска (Loki работает на основе лейблов), да и в 2019 году Loki только появился, а хотелось чего-то проверенного.
Prometheus — изначально метрики были в нем, но у него один из главных недостатков — он не умеет масштабироваться горизонтально, да и хранить в нем метрики долгосрочно (и доставать их поисковыми запросами) не так оптимально, как в VictoriaMetrics, которая к тому же менее требовательна к дисковой подсистеме.
GDRP и прочие регуляторные штуки — в логах не должно быть sensitive data и перс. данных, такие логи запрещается писать и они удаляются сразу, к отправителям логов быстро придут безопасники и отбезопасят.
Как сопровождавший такую систему с логами — соглашусь, что лучше не писать логи. Но без логов не решить многие проблемы в тех случаях, когда нужно большое cardinality, да и проблемы на проде надо как-то диагностировать. Мы стараемся не строить реалтайм-мониторинг на логах (вместо этого пишем метрики), но не во всех случаях это поможет.
У команд может быть несколько систем на сопровождении, и часто полезно смотреть логи из нескольких взаимосвязанных систем вместе.
В таких эпизодических случаях данные удаляются, как правило, прямо индексами. За счет того, что данные льются в индексы в разрезе группы/энва/системы, и нарезаются по времени в зависимости от потока, то удалить данные не сложно. В особых случаях можно и отдельные записи удалить.
Насчет облачного варианта ПО я еще могу понять, но если это On-premise инсталляция? Хотя судя по учетке, зареганной сегодня — я зря трачу буквы на тролля.
Если не используете Splunk, то ничего не делать.
Ну или представить, что будет если завтра то же самое сделает другой зарубежный (или российский) вендор, сервисы/услуги которого вы используете сейчас.
Какое бы решение вы выбрали в 2019 году с учетом требований из статьи?
Five years ago Manticore began as a fork of an open source version of the once popular search engine Sphinx Search. We had
two bags of grass, seventy-five pellets of mescaline, three C++ developers, a support engineer, a power user of Sphinx Search / backend team lead, an experienced manager, a mother of five helping us part-time, and a ton of bugs, crashes, and technical debts. So we got a shovel and other digging tools and started working to get it up to the search engine industry standards. Not that Sphinx was impossible to use, but many things were missing, and existing features weren’t quite stable or mature. And we had pushed it about as far as we could. So after 5 years and hundreds of new users, we’re ready to say that Manticore Search can be used as an alternative to Elasticsearch for both full-text search and (now) data analytics too.Звучит интересно, спасибо!
Среди требований была поддержка полнотекстового поиска (Loki работает на основе лейблов), да и в 2019 году Loki только появился, а хотелось чего-то проверенного.
Prometheus — изначально метрики были в нем, но у него один из главных недостатков — он не умеет масштабироваться горизонтально, да и хранить в нем метрики долгосрочно (и доставать их поисковыми запросами) не так оптимально, как в VictoriaMetrics, которая к тому же менее требовательна к дисковой подсистеме.
Я могу ошибаться, и это неактуальная инфа, но Clickhouse вроде не умеет в настоящий полнотекст: https://prohoster.info/blog/administrirovanie/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah#fulltext-search
GDRP и прочие регуляторные штуки — в логах не должно быть sensitive data и перс. данных, такие логи запрещается писать и они удаляются сразу, к отправителям логов быстро придут безопасники и отбезопасят.
Как сопровождавший такую систему с логами — соглашусь, что лучше не писать логи. Но без логов не решить многие проблемы в тех случаях, когда нужно большое cardinality, да и проблемы на проде надо как-то диагностировать. Мы стараемся не строить реалтайм-мониторинг на логах (вместо этого пишем метрики), но не во всех случаях это поможет.
У команд может быть несколько систем на сопровождении, и часто полезно смотреть логи из нескольких взаимосвязанных систем вместе.
В таких эпизодических случаях данные удаляются, как правило, прямо индексами. За счет того, что данные льются в индексы в разрезе группы/энва/системы, и нарезаются по времени в зависимости от потока, то удалить данные не сложно. В особых случаях можно и отдельные записи удалить.
в то время, как установить можно через Ansible: https://blog.zabbix.com/installing-the-zabbix-server-with-ansible/13317/
Для этого уже давно придумали виртуальные доп. карты. А палить свою реальную карту в инете, даже с лимитами — так себе совет.
Это значит, что текущие контракты можно продлевать? И лицензии тоже?
Хотя после темы со Splunk уже не очень хочется смотреть что-либо не open source.
Из open source наиболее интересно выглядит Loki.
Ну или представить, что будет если завтра то же самое сделает другой зарубежный (или российский) вендор, сервисы/услуги которого вы используете сейчас.