Перейти к содержимому
Калькуляторы

Civil

Новичок
  • Публикации

    4
  • Зарегистрирован

  • Посещение

О Civil

  • Звание
    Абитуриент
  1. Тут проблема в том, что люди любят смотреть на дашборды с графиками и глазами анализировать. Им просто так нравится, а это создает довольно большое колличество запросов к базе на чтение. Грубо говоря у каждой команды свой "телевизор с графиками", плюс у каждого разработчика-менеджера-начальства свои любимые наборы графиков, которые они периодически смотрят (второй-третий монитор на котором на пол экрана ротируются заданные графики). Я сам честно не понимаю, как такое может быть удобным и юзабельным, но факт есть факт. В текущий момент меня пока все устраивает. Я просто поделился граблями, на которые наступил, когда щупал InfluxDB, чтобы это было где-то записано. Я на него смотрю уже довольно давно (первый раз проверял еще в начале лета, на релизе 0.7, последний раз буквально в октябре на 0.8). Он выглядит интересно, многообещающе, но по скорости далек от идеала, также по стабильности тоже есть некоторые проблемы. Притом, похоже, проблемы со скоростью - фундаментальные для всех LevelDB-based движков. С переходом на RocksDB стабильность скорости чтения и записи сильно выросла, но меня не устраивает именно то, что чтение и удаление данных - очень дорогие операции в Influx'е. плюс ко всему, в Ceres можно симлинками довольно гибко поменять структуру метрик, а простым rm'ом удалить лишние данные (изменения имени также просто делается и с Whisper/RRD, с удалением правда чуть сложнее, как и с добавлением новых линий), а вот с Influx'ом такое не прокатит.
  2. У influx'а проблема со скоростью чтения и есть еще ряд нерешнных проблем: https://github.com/influxdb/influxdb/issues/884 + https://github.com/influxdb/influxdb/issues/1042 + https://github.com/influxdb/influxdb/issues/945 которые немного мешают его эксплуатации. Но в целом он выглядит неплохо, согласен. Скорее всего к 0.9 или 1.0 будет очень юзабельным. Про графит - ну да, он многослойный, но на небольших объемах (до 1 млн точек в минуту) ему достаточно почти любого 4-х ядерного процессора + ссдшки десктопного класса. Да, прийдется слегка пошаманить подбирая конкретно под себя связку из relay + writer'ов и немного поковыряться в конфиге, но потом оно будет просто работать. На текущем месте работы, графит у нас вообще живет на самой дешевой железке из hetzner'а с ссдшками (это i7-2600, 16GB Ram, 2x OCZ Vertex 3 120GB в mdadm raid 1), в него пишут примерно 0.5млн точек в минуту, la на сервере порядка 3 (и это при параллельном чтении), по диску тоже еще есть куда стремится. На тестах перед тем как вводить это дело в строй, удавалось писать стабильных 1млн точек (параллельно с чтением), пиковое до 4 с лишним. Да, influxdb (0.8.1, на момент тестов самый свежий) позволял писать стабильных 4 млн (или пиковые нагрузки до 5млн на короткое время), но не мог читать с нужной скоростью, к сожалению (на graphite-api приходится примерно 60 запросов в секунду в пике, каждый запрос - выборки вида groupByNode(server.somestat.*,"sumSeries") где * раскрывается в 30-40 линий). Правда чтобы добится такого низкого LA весь графит работает на pypy 2.4 сейчас (megacarbon и graphite-api) + как релей используется патченный carbon-relay-ng (патчем добавлена поддержка Consistent Hashing).
  3. А с этим все просто: https://github.com/graphite-project/carbon/blob/dec9dfed89ea19e756fd5a45ff6462874b03b904/lib/carbon/writer.py#L73 Читаем эту строку и коммент после нее. Если очень лениво, то процитирую коммит: У мегакарбона другое поведение, более логичное, но и более опасное (в карбоне обычном так сделано, чтобы не пришел ООМ если очень много данных запихнуть в графит).
  4. В Яндексе (см. доклад с Яка 2013) используется graphite-web (+патчи, назначение некоторых из которых я не знаю, но вроде все это было нужно) + свой форк ceres (апстрим слегка умер, а у Дмитрия Куликовского на его гитхабе лежат фиксы ceres-maintaince и еще каких-то мелких багов в самом ceres) + свой форк carbon (использеутся ветка megacarbon, она по тестам была быстрее чем просто карбон и в целом управляется легче). К сожалению инструкция, которая была на Ярушке, недоступна больше. Из чего-то вменяемого я бы посоветовал http://anatolijd.blogspot.de/2013/06/graphitemegacarbonceres-multi-node.html (и вообще в том блоге о Ceres есть заметки, интересные и полезные), только брать форки от Дмитрия. Почему Ceres а не Whisper расказано на докладе с яка 2013 (вкратце - церес быстрее). Из особенностей: 1) carbon-writer любит ssd'шки, поэтому лучше держать базу графита на ssd (это в общем касается даже rrd). 2) carbon написан на питоне и, видимо, не самым лучшим образом, поэтому один инстанс writer'а (и relay'а) может прокачать примерно 250 тысяч точек в минуту (при условии что диск столько запишет). 3) carbon-relay призван делать роутинг (притом с consistent hashing'ом, чтобы одни и те же метрики всегда попадали одному и тому же writer'у), но у него те же проблемы что и у остальных carbon-демонов. Как решение - можно взять carbon-relay-ng (https://github.com/graphite-ng/carbon-relay-ng), он написан на Go и сильно быстрее (один инстанс может прокачать до 1.2млн метрик в минуту, что уже близко к разумному пределу на Ceres'е). Плюс еще есть места, где его можно оптимизировать и выжать больше. но у него нет consistent hashing'а (пока), поэтому прийдется или впиливать руками или ждать пока впилят за тебя (есть в ближайших планах) 4) Касательно морды - есть штатная морда, graphite-web, она довольно жирная (Django и все такое), есть альтернативная - graphite-api, но она не умеет ceres (нужно плагин портировать), сам церес нужно подпачить слегка (есть PR https://github.com/dkulikovsky/ceres/pull/2 на это), он на flask'е, тоньше, быстрее и чище (и у него очень адекватный апстрим, всегда можно поговорить с разработчиком и хорошие PRы разработчик быстро принимает). Но вся эта штука очень любит CPU - что graphite-web/graphite-api, что carbon. И узкое место будет именно в процессоре (при наличии ссд дисков конечно же). Как альтернативную базу данных для графита, можно взять influxdb (influxdb.com + https://github.com/vimeo/graphite-influxdb), на запись оно работает довольно адекватно (хотя возможно есть баги), но вот чтение данных лучше делать как можно реже (оно очень медленно данные читает, вот прям очень-очень). Касателньо конкретных цифр - яндексовая схема вида: haproxy -> 8x carbon-relay -> 12x carbon-writer выжимает примерно 1-1.5млн точек в минуту на 2x e5-2660, 64GB Ram, Raid 10 из 4x300GB Intel 520 (SSD). Замена carbon-relay на carbon-relay-ng позволит пиково получать примерно 4-5 млн точек в минуту (примерно столько же и на influxdb), но постоянная скорость будет ограничена диском уже (примерно на уровне 2 млн, может даже меньше), у influx'а - 4млн точек в минуту легко будет писаться почти что сколь угодно долгое время (я сам тестировал на более слабом железе, примерно 12 часов записи по 4млн в минуту оно выдерживало). Только вот прочитать эти данные будет сложновато. И еще небольшой UPD: graphite-api конечно быстрый, но с очень большим колличеством запросов тоже плохо справляется. Он прекрасно (с виду) работает с pypy-2.4, притом прекрасно = в несколько раз быстрее. У графита есть tcp + udp, и tcp работает постабильнее в данном случаи.