Pull to refresh
11
0
Вадим Нестеров @nucleusv

User

Send message
ClickHouse используется для хранения и анализа логов различных сервисов в Яндексе. Типичным решением было бы использовать Logstash и ElasticSearch, но оно не работает на более-менее приличном потоке данных.


Ну про вставку данных могу поверить, а вот в то, что ClickHouse full text search делает лучше уже сомнительно.
Расскажите подробнее.
По опыту, это все таки проще и меньше написать patch чем совсем уже писать новый механизм взаимодействия.

А ODBC да очень нужен тоже, всякие там BI: Tableau без них никуда :)
Если решитесь выкладывать в opensource, а я очень надеюсь :) Подумайте пожалуйста в сторону использования протокола для драйверов уже готовых MySql (как сделали Memsql) или postgres — это позволит перевести текущие ПО быстрее.
В opensource ждать?
А по какому протоколу идет общение с базой? Сами писали? Или вязли Mysql, Postgres, etc?
Вы наверняка используете bonding на интерфейсах, вы не сравнивали производительность bonding драйвера и нового для centos 7 — teaming?
А дайте конфигурацию плиз :)
Сколько и каких нод — характеристики железа.

И конфиг если можно?
По поводу RDMS — Алексей обещает, что сделают плагинабл архитектуру для Zabbix, чтобы можно было разные БД использовать. Но боюсь это будет не скоро.
Индексировать через, через еластик?
Как метрики из логов делать собираетесь?
За 1-2 месяца у вас просто кол-во точек не уместится на графике (если у вас еще интервалы по 10 сек), поэтому там используется тренды.

Не подумайте, что я вас отговариваю, Яндекс давно отказался от Zabbix.
Нам он удобен именно с точки зрения легкости его скрещивать со всем ,)
Вы логи куда льете?
Для меня сейчас это очень актуальная задача. Ну в graylog2 он в монгу льет, а еластик как раз для индексации.
Нет не пробовал, у меня мускульного кластера. Дал как новодку родное решение от MariaDB.
Там просто на уровне запросов можно маршрутизацию делать.
С логами соглашусь на 100% в заббиксе это слабое место — мы идем по пути, что логи льем в elasticsearch, graylog2 и оттуда дергаем агрегированную метрику. Например вернуть кол-во вхождений слова error за последнею минуту и вешаем на нее триггер.
Ну как бы без цифирей трудно говорить, где у вас там риалтайм, выставляете в в заббиксе большие кеши мегов на 512 или больше и у вас in-memory db :)

За kale thanks!
Сделайте партиционирование, разделите установки на операционный заббикс который алертинг, историю за неделю.
Остальные данные перекладывайте в историческую-аналитическую базу, в тот же opentsdи можно раз в час переливать.

С отрисовкой мне кажется вопрос полностью решен плагином на который дал выше.

Просто менять заббикс это когда она реально считать триггеры не может. То есть у вас дикий NVPS и вы уже все разнесли по проксям.
NVPS — что у вас показывает, график на элементе zabbix[wcache,values]?

плагин Zabbix для Grafana — вы про это github.com/alexanderzobnin/grafana-zabbix?

а дайте плиз ссылку на kale?

Да это серьезно.
А NVPS в такой системе сколько?
Терабайт это объем данных истории или кол-во метрик?

До плагина графаны досидели?

На что планируете менять?
Не слушайте никого. Just do it!

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity