странно при любой проблеме, пытаться решить ее написанием кода )

ну вообще то не при любой, а при конкретно твоей

ты же не осилил поменять сигнал - а это и есть способ номер один

собственно единственно правильный способ

эээ

окай гай

у нас всегда было retention.hostname.subsystem.counter и я ни разу не жалел о такой схеме

а как бы ты с такой системой назвал метрику, в которой лежит, например, время копирования файла?

one_min.superhost.subsystem_that_copies_a_file.time м?)

или copy_time

хм)

#naming как вы метрики именуете? нагуглил кучу советов вроде hostname.app.subsystem.noun.past_verbтипа s1.huifikator.webserver.words.huified, но это всё про каунтеры, а как называть gauges и timers?

У нас первым идет кластер (условно по глобальному назначению - например load balancers, nginx, sys, db, ...) Потом в зависимости от кластера уже, часто сервис.датацентр.метрика

коллеги

смарите чо

sum(100.0 - (sum by (host)(cpu_usage_idle{host=~"$host.*"}))/(count by (host)(cpu_usage_idle{host=~"$host.*"})))

есть прометей, телеграф и графана

вот эта шняга выше - это перцентаж занятости процессора

на одном хосте

а как посчитать для всей выборки разом?

чтобы в singlestat запихать

На тему тестирования SHDD под метриками.

картинка после замены какая то такая.

у меня непонимание кол-во операций уменьшилось, значит поидее время отклика стало выше. Но почему такая фигня с очередью, и взвешенным временем ? ну и соотвественно от обратного, если saturation примерно такой же, а в очереди меньше операций, суммарно взвешенное время (очередь+использование) ниже, почему кол-во операций меньше а не больше ?

у меня непонимание кол-во операций уменьшилось, значит поидее время отклика стало выше. Но почему такая фигня с очередью, и взвешенным временем ? ну и соотвественно от обратного, если saturation примерно такой же, а в очереди меньше операций, суммарно взвешенное время (очередь+использование) ниже, почему кол-во операций меньше а не больше ?

Пальцем в небо - возможно количество операций уменьшилось потому что размер сектора поменялся и ос оптимизирует мелкие записи.

хм.

и вот хрен проверишь теперь.

Увы, ответа не знаю, но 512б -> 4кб сектор у диска может объяснить такое

хотя.

я могу сказать разницу. до было ext4 новый xfs но размер чанка рейда одинаковый

Xfs точно менее надежен и более быстр, если брать умолчантя

да брось

быстрее на мелких объектах

Я к тому что кэширование промежуточного агрессивнее ценой того что при ресете больше проблем будет

там докатывается

там конденсаторик на slc

Это то что в кэше диска

А то что в раме то ой

эт да

Xfs точно менее надежен и более быстр, если брать умолчантя

Почему?

Почему?

Ну оно примерно такие же гарантии дает как ext4 + nobarrier + data=writeback

Ну оно примерно такие же гарантии дает как ext4 + nobarrier + data=writeback

Про барьеры откуда инфо?

Про барьеры откуда инфо?

Ниоткуда, я не знаю достоверно, просто по поведению при отключении питания кажется так

я могу сказать разницу. до было ext4 новый xfs но размер чанка рейда одинаковый

xfs активно сортирует io, потому при прочих равных меньше гоняет головки по диску.

Ниоткуда, я не знаю достоверно, просто по поведению при отключении питания кажется так

Поведению какого года на каком ядре? Я спрашиваю, потому что в 3.2 поменяли механизм журналирования.

Поведению какого года на каком ядре? Я спрашиваю, потому что в 3.2 поменяли механизм журналирования.

Что то из диапазонов 2.6.32-2.6.38 помню хорошо

Что то из диапазонов 2.6.32-2.6.38 помню хорошо

Это старая версия xfs.

Сейчас гарантии такие же как у ext4 без data=journal.

Ну хорошо тогда.

Вообще, глядя на число фиксов для ext4 как-то даже страшно использовать ее

Вообще, глядя на число фиксов для ext4 как-то даже страшно использовать ее

Как раз таки нет

чем снимал метрики ?

чем снимал метрики ?

коллектд.

а телеграф никто не юзает?

я юзаю

о

скажи, у него net_bytes_sent и net_bytes_recv в каких единицах вообще?

в байтах

у тя в прометеусе тоже небъется rate ?

выгребаю графаной из прометея вот так: sum by(host, interface) (irate(net_bytes_recv{host=~"$host.*", interface=~"eth.*"}[5m]))

и получаю цифру ровно в 10 раз ниже заббикса

Максим, мы с тобой 2 недели назад дебажили ровно эту же проблему.

только у меня

при чем у меня _все_ каунтеры так.

ровно в 10 раз меньше.

тлен какой-то...

байты с битами не попутали?

нене, это каунтер

при том у меня телеграф отдает в инфлюкс и в прометеуй

прометей рисует в 10 раз меньше

а инфлюкс типа верно?

да :(

однако...

блин, причем с node_exporter'ом все было ок

ну цифры сходились

не факт....

у меня такое же повдеение на node_exporter

я для этого спецом водрузил его на ноутбук

кстати, а diskio_read_bytes / diskio_write_bytes снимаешь?

да

тут у меня вообще запредельная картинка

https://dl.dropboxusercontent.com/s/d7m8pdusca9sjut/Grafana_-_Host_Stats_2016-09-24_14-18-47.png?dl=0

все "пики" ровненько по 179.0 mbps

а скинь формулу

я у ся проверю

irate(diskio_read_bytes{host=~"$host.*"}[5m])

ыы

бггг

причем такое чувство, что мы какие-то жалкие неудачники

всмысле - только мы с тобой

вот например дашборд: https://grafana.net/dashboards/371

в нем есть нетворк

https://grafana.net/api/dashboards/371/images/287/image

качаем, смотрим

"targets": [ { "expr": "irate(node_network_receive_bytes{alias=\"$instance\", device!=\"lo\"}[5m])", "intervalFactor": 1, "legendFormat": "Inbound: {{ device }}", "refId": "A", "step": 120 }, { "expr": "irate(node_network_transmit_bytes{alias=\"$instance\", device!=\"lo\"}[5m])", "intervalFactor": 1, "legendFormat": "Outbound: {{ device }}", "refId": "B", "step": 120 }

ну и ищем десять различий

судя по node_network_transmit_bytes - это node_exporter