я тестировал и не заметил. ES очень аккуратно хранит свою внутреннюю структуру, вмешательство файлсистемы в работу чанков минимально, они большие и их мало

it depends

ну у меня не много нагрузки будет. Гигов может 400 в день, сырых

такой типа достал и положил.

it depends

мне не представить сценарий, когда файловая система окажет влияние на работу ES. Но если вы придумаете тест - я с удовольствием его проведу

мне не представить сценарий, когда файловая система окажет влияние на работу ES. Но если вы придумаете тест - я с удовольствием его проведу

на вскидку не могу сказать, но мне кажется в случае большого датасета, большого вол-ва шардов и индексов, файликов будет многааа

и это может ролять. не ?

на вскидку не могу сказать, но мне кажется в случае большого датасета, большого вол-ва шардов и индексов, файликов будет многааа

не думаю. нужно, чтобы индексов и шардов было прямо фантастически много. Думаю, что от такого сам эластик загнется раньше

триллион индексов для эластика поведение явно нетипичное

ну к примеру у меня вот на ноде 5к шардов, и это 150к файлов

а есть у кого-нибудь The Visible Ops Handbook почитать?

Есть, но я не в Москве :-)

парни кликхаус кто то мониторит ? который экспортер для прометея взять ?

а их много?

а кто-то go-carbon + carbonapi + grafana дружил ?

а то у меня internal server error падает

"/metrics/find?query=*", "http_code": 500, "reason": "proto.Unmarshal: unexpected EOF", "runtime"

вот так

А версии какие? Настройки?

0.9.1-1.el6 go carbon

carbonapi последний с гитхаба

а carbonapi/grafana?

так

графана 4я

мы тут в мастере ушатали protobuf и теперь поддерживаем только protobuf3

https://github.com/dgryski/carbonapi/releases/tag/0.5 это было последнее что умело 2-ой

мм ага я догадываюсь

go-carbon умеющий protobuf3 - master

ага счас значит пересоберу

В целом мы сами сидим на master-master сейчас

ошибся в использовании пакета го-карбона, думал хватит его одного чтобы графит апи заменить

к сожалению нет, нужен карбонапи

у нас вообще в планах есть выкладка dockerfile'ов и создание image'ей с нашим стеком, но руки не доходят

интересно поможет ли если мы уже в цересе в диск и графит-апи уперлись

графит-апи да, с дисков - вопрос

в го-карбоне можно получить больше метрик в секунду, но если есть много рам для кэша

то есть 32-64ГБ рам под кэш отдать

./src/github.com/lomik/go-carbon/carbonserver/carbonserver.go:1378: unknown http.Server field 'IdleTimeout' in struct litera

змм

да тут гугло клауд поэтому много рамы есть чтобы иопсы были на диске

Го 1.8 нужен

и только он

либо руками убрать IdleTimeout, но он там не просто так

@uMagistr мы стэк наш проверяем с Го 1.8 только по сути

апи и зиппер билдятся с 1.7 пока еще, но ненадолго

эхх

ну таков мир Го - там нет кажется смысла сидеть на старых версиях

да уже обновил

2017/04/03 12:37:16 user: Lookup requires cgo

хмм

CGO_ENABLED=1

но ваще там же есть мейкфайл

у го-карбона

а я чз го билд билдю

там есть make submodules && make

правильный способ для go-carbon

он сабмодули нужными коммитами подгрузит

ld: unknown option: --build-id=none clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [go-carbon] Error 2

хмм

я под маком компиляю

cgo нужно

@uMagistr ну я под маком make'ом гокарбон собирал

я под линукс компиляю

carbonapi не кросскомпилируется нормально, если нужна поддержка png

кросс-компиляцию я не проверял для go-carbon

я знаю что carbonapi кросс-компилируется если не собирать поддержку png/svg

ага придеться на ноде всеже компилять эхх

ERROR: S client not available

можешь в докере собрать

локально

о тоже верно

уф запустился

мы тут в мастере ушатали protobuf и теперь поддерживаем только protobuf3

Слышал что protobuf не ок из-за schema-less. Что изменилось в версии 3?

Слышал что protobuf не ок из-за schema-less. Что изменилось в версии 3?

Ну смотря что понимать под schemaless

В 3ей версии он стал дружелюбнее на вид, всякие фичи ненужные порезали

Ну смотря что понимать под schemaless

Ну вот msgpack как json, только сжатый. А protobuf - нет! И я прочитал много боли об этом.

Ну вот msgpack как json, только сжатый. А protobuf - нет! И я прочитал много боли об этом.

М... Не понимаю

@RShishkin наоборот кстати, у протока четкая схема

В отличии от

Так человек менял схему и json было бы ок, но в проекте был protobuf

@RShishkin наоборот кстати, у протока четкая схема

ну у этого свои минусы есть. трудно жить в привычном режиме, когда новое поле добавилось, но оно по умолчанию тупо игнорируется. с протобуфом в этом месте нужно подкладывать солому вручную.

ну у этого свои минусы есть. трудно жить в привычном режиме, когда новое поле добавилось, но оно по умолчанию тупо игнорируется. с протобуфом в этом месте нужно подкладывать солому вручную.

Да

Я для своего проекта склоняюсь пока к чистому json

Я для своего проекта склоняюсь пока к чистому json

Вопрос в том зачем тебе там сериализация

Кстати, мне задвинули мощную лекцию о стеке ELK

Я честно json не люблю за пару особенностей

Я для своего проекта склоняюсь пока к чистому json

it depends. если трафика относительно немного, затраты на парсинг/генерацию допустимы, задержка не очень важна, то да, отличный выбор :)

И если не нужно гонять по сети nanы вместо чисел

что за тема с nan?

что за тема с nan?

Как в json будет Nan для числа?

а зачем оно вообще?

можно просто поле не передавать

а зачем оно вообще?

М... Массив точек, показать что в нем есть дыра

можно просто поле не передавать

это оч плохой путь

ты ждёшь ключа, а тебе ключ не пришёл

а NaN – хороший?

а NaN – хороший?

Ieee754 считает что это валидная штука

Банально ты не можешь в json передать полноценный float64

Точнее тебе нужно минимум одно дополнительное поле

И нетривиальный процесс кодирования-декодирования