Вот как раз бывает тип а. И именно в больших проектах… Сидит вот такой гуру, врос корнями в стул и пилит «мою прелесть» — библиотечку из 3-4-10 файликов. Вы может и не сможете библиотеку из 5-7 тысяч строчек кода знать — у вас она тупо не одна… а такой вот автор — запросто, это плод всей его жизни может быть.
А пользователя про «изменить» это тип б. «по классификации FYR» )))
Я все таки за важность баланса между семантикой и объемом кода… При большом объеме даже понятная семантика приводит к тому что упускаешь моменты. Отсюда сначала «стандартные библиотеки», потом и паттерны проектирования, а потом и целые фреймворки вылезают — такие своеобразные надстройки над языком.
Сказали тебе абстрактная фабрика — значит абстрактная фабрика и незачем тебе в семантику реализации читать.
Все просто — привязка месенджера к номеру телефона нужна для того… барабанная дробь..., чтобы идентифицировать пользователя.
В самом безобидном случае для того что бы обеспечить возможность лендинга на стационарные телефоны…
А так: для того чтобы сливать данные о вас (по порядку убывания) например банкам, спамерам, спецслужбам. А и не забываем также и о всей вашей записной книжке в телефоне, информацию о них тоже слить можно.
И я не поверю в непогрешимость телеги в защите приватности и несотрудничестве со спец службами ровно до тех пор, пока в телеграмме остается привязка аккаунта пользователя к номеру телефона и телефонной книге пользователя. С точки зрения функционирования сервиса — номер телефона это просто 10 цифр, а контакты пользователя это просто контакты. Зачем их привязывать к телефону — крайне непонятно.
Ну так то все нормально идея здравая, хорошая. Есть прекрасные протоколы тот же XMPP и даже можно придумать еще один со своими стиккерами и стразами, но есть одно мааааленькое но: это никому не выгодно. Не выгодно ватсапу чтобы его пользователи общались с пользователями вайбер напрямую — им выгодно чтобы эти пользователи вайбера поставили себе ватсап. Обратное верно. И телеграмное тоже верно.
Сами по судите: протокол телеги открыт — нет абсолютно никаких технологических ограничений встроить в приложение watsup поддержку протокола telegram или написать какой то «шлюз».
Но они же наверное не для того придумывали свой закрытый протокол и писали свое закрытое приложение чтобы все кто ни попадя общался?
На самом деле меня сейчас больше интересует возможность использования для препроцессинга скриптов исполняемых на самом сервере заббикса.
Например такая вот проблема:
Приложение (например elastic) имеет api диагностики через HTTP json. B заббикс может разбирать json. Но увы парсер путей там тупой до безобразия. А в диагности нашего приложения используются массивы, а элементы определяются не позицией, а наличием ключа с определенным значением (например:
и до метрики можно добраться плоским zabbix парсером: first_module.metrics.metric
Но вы правы таскать скрипты по серверам неудобно, и хотелось бы иметь такой скрипт например на сервере самого заббикса, ну или на прокси.
Есть ли какие то варианты расширения самого заббикс сервера?
Извиняюсь за паузу…
В примере есть скрипт дискавери… По сути его задача прочитать на хосте конфиг в котором написано: блочные устройства с именами в /dev/mapper/XXX* это диски индексатора, /dev/mapper/YYY* это диски BLOB, /dev/mapper/ZZZ* это разное логгирование.
Соответственно на такую группу устройств рисуется одна группа метрик которые прибиты к своему application
Затем в самом скрипте метрики чуть более сложный однострочник вида: UserParameter=custom.vfs.dev.read.sectors[*],realpath '$1' | xargs -I{} basename {} | uniq | xargs -I {} cat /sys/class/block/{}/stat | awk '{n += $$3}; END{print n}'
Который по идее суммирует информацию по блочным устройствам, которые смонтированы куда надо.
Ну и плюсом собираются метрики по отдельным дискам дабы разобраться что к чему.
Но на самом деле, меня эта схема не очень устраивает потому как учитываются «средние значения», а при этом существует разный профиль например для индексатора крайне важен iops поэтому диски работают параллельно — и там не должно быть перекосов по нагрузке. А для BLOB iops не важны — софт работает на строго последовательный доступ и там диски работают так же последовательно и то что один пашет, а остальные простаивают — это норма. Что то можно учесть кастомными триггерами для приложения, а что то нет.
На мой взгляд еще очень важно, кто и для чего работает с кодом:
а. Разработчик, который хорошо знаком с кодом — он его автор, он знает суть деталей — для него нет цикла по переменной — он знает что делает целиком этот блок for. А вот эта лябда тут и так понятно для чего.
б. Разработчик, который только использует этот код и он например «почему то не работает». Он не понимает что может делать этот for c итерацией по i. А зачем тут лямбда и что она должна делать.
в. Разработчик, использующий код как библиотеку — он вообще в потроха не полезет, ему куда важнее насколько адекватен интерфейс метода или коментарии в заголовочнике.
И у вы на практике — это работает только когда все идеально — и код, и коментарии, и пространство имен, и общепринятый coding style.
И часто ситуация промежуточная — код выглядит читаемым и понятным, но по закону Мерфи существенные моменты, где то закопаны в дебрях.
В итоге вот эта грань между семантикой и длинной кода очень тонка. Да лично я предпочту
for ( namespace::listofmyclass::iterator it=....) вместо for (auto: a… Но это просто потому что часто приходится искать именно дефекты серии «хотели сделать вот так а получилось вот эдак)
Что то или я не до конца уловил вашу мысль или вы не совсем поняли, но вроде вы и говорите про то же самое:
В моем примере делится: количество тиков за интервал измерения (по сути это есть утилизация записью) на количество операций за этот же интервал (количество параллельных записей). Т.е. как и в вашем примере так и будет:
Пусть выполнялось:
5 одновременных операций.
каждая за 100 msec (реальный латенси 1 операции )
интервал опросов заббиксом 1 секунда. тогда…
write_util будет: 100 мсек * 5 операций / 1 секунду = 0.5 = 50 % (100 * 5 = 500 тиков это колонка w_ticks (ms))
а w_svctime: 500 / 1 секунду / (5 операций / 1 секунду )…
собственно технический делитель от забикса «1 секунда» сократится и получим:
:) прощаю — у меня не было цели предложить кому-то решение. Скорее так — просто поделиться конкретным опытом. Более того я не считаю, что заббикс — правильный или наиболее подходящий инструмент для этой задачи. Просто подвернулся под руку, и возникла задача как сделать именно это и именно с заббиксом. Ну плюсом спровоцировать дискуссию из которой можно было бы почерпнуть что то новое. Вон например в комментариях выше уже были варианты как сделать тоже самое, но проще. То есть считайте профит какой то уже получен.
Еще эти графики полезны например при настройках СУБД типа Postgres и оценках работы например индексов. Т.е. же самые shared_buffers у Postgres или извечные терки — выносить ли pg_xlog на отдельные диски, а avtovacuum ли мешает работе базы.
Сложно говорить про какие то конкретные вещи, но из последнего:
рост IOPS при тех же скоростях записи — признак фрагментации файловой системы
утилизация дисковой подсистемы строго следует за пропускной способностью, и например составляет 100% для 6,2 гигабита в секунду — уперлись в пропускную способность FC 8gbps линка. Добавляем второй линк и настраиваем мультипас — утилизация падает в 2 раза
утилизация дисковой подсистемы выросла пи этом iops и скорость записи та же — глючил линк на FC на одном из каналов
покрутили queue/max_sectors_kb со штатных 512 до 4096 — утилизация упала, но максимально много не значит лучше, при 8192 — утилизация стала расти
и другое. На самом деле на практике вдруг замечаешь, что резко изменилась форма графиков и просто начинаешь разбираться что случилось. Там уж и dmesg в помощь. И не всегда проблема бывает в вашем софте.
Был случай когда при обновлении не вытерся старый бинарник — он в принципе не очень мешал, а просто подтекал и кушал память потом его OOM прибивал, он перезапускался и так по кругу. На графиках это выглядело как рост операций ввода вывода от софта в виде пилы. Софт перекопали, проблем не нашли — в итоге оказалось что софтина выкушивала кеш операционной системы, что конечно приводило к изменению количества запросов.
Данные тесты не создают какой то дополнительной нагрузки (ну кроме самого получения метрик) и используют реальные данные и реальную среду для оценок.
Мой опыт показывает, что только тестирование на реальной машине, в реальной конфигурации, с реальными данными может показать насколько ваш сферический конь в вакууме тест в лаборатории соотноситься с реальной кобылой в сарае нагрузкой.
И как раз только в реальных условиях вы сможете протестировать на реальном объеме записываемых данных с реальными ресурсами.
А то как бывает обычно: мы берем какое то хранилище у которого: кеш у дисков, кеш у raid контроллера, навороченное ssd кеширование, плюс кеш операционной системы и еще кеш внутри приложения. Еще до кучи супер пупер навороченные алгоритмы префетчинга и прочее. За все эти кеши и алгоритмы мы заплатили денежки прямо или опосредованно.
И начинаем тестировать его, так чтобы все эти кеши забились и перестали работать. Т.е. тестируя мы заведомо выходим на режимы в котором наша система работать не будет а все эти навороты ненужны. Ну и какая цена такому тестированию?
Но по другому мы действовать не можем ибо, а кто нам скажет с какой вероятностью мы будем попадать в эти кеши. А еще у которых есть 100500 настоек самого кеша, плюс в десять раз больше настроек всего остального на них влияющих начиная от конфигураций файловой системы, опций форматирования и монтирования, различных LVM.
И только наблюдая за системой «в реальной среде обитания» вы сможете сказать: «да кеши работают» или «нет не работают» или да — форма графиков в реальной среде совпадают с аналогичными в тестовой, значит скорее всего методика тестирования верна.
Вариант конечно, но и я могу ваш вариант «обхаить» зачем system.run `cut /path/to/[#lld_blk]/stat` когда можно просто: vfs.file.contents['/path/to/[#lld_blk]/stat']
Насчет цитированного — увы будет ибо, делить надо не одновременные значения а дельту… Хотя возможно зависимые элементы и отработают одновременно — в такие моменты заббикса не углублялся.
В оправдание себя скажу — в статью не попало, но реальная срока в моем скрипте посложнее — ибо суммирует значения сразу с кучки дисков, причем в качестве параметра получает маску названий алиасов (несколько устройств разом). Кроме того мне не нужен мониторинг всей тьмы дисков. Разделы побиты на группы в соответствии с назначением и мониторятся именно группы. Но это лютый кастом и лишнее для статьи.
И да любые файлики userparams легко раскидываются на 2к машин разными системами деплоймента типа Ansible например. Ну и потом не всегда можно вот так взять и обновить заббикс на 3.4.
Но справедливости ради, запросы к zabbix-api это не сама grafana, а плагин к ней — по сути сторонний, еще до кучи у которого уведомления прикручены непонятно как. И в целом связка zabbix+grafana выглядит избыточной. В боевой системе мониторинга, особенно когда идет опрос большого числа узлов (ну и когда не нужны красивые картинки для менеджмента) наверное лучше либо использовать штатные графики заббикса (может не такие красивые, но зачем там красота) либо другую систему хранения, например прометей.
Да какие функции высшего порядка, какие генераторы списков… Есть конечно в алгоритмах std::remove_if, но даже если ты его не помнишь — это элементарный обход списка итератором. Там единственный подвох — заранее ++ итератору сделать ибо после удаления развалится.
Ну о чем можно говорить с «с++ программистом» который не знает что такое итератор? И подчеркиваю это не зеленые студенты 1 курса… Это люди считающие что они достойны такого оклада…
Вот плюсую. Уже несколько лет вакансии С++ программистов не можем закрыть. Вилка 100-150т.р. территориально Нижний Новгород. Просто тупо нет нормальных самодостаточных программеров. Процентов 70 кандидатов, называющих себя с++ программистами и претендующих на оклад 100к валятся на вопросе «напишите функцию принимающую на вход список std::list и удаляющую из него элементы с четными значениями». А уж про какие то тонкости типа «порядок инициализации членов класса» или «чем реализация std::unordered_map отличается от std::map» я даже и не заикаюсь.
На самом деле не соглашусь: воровство маркированых изделий решается более чем тривиально и с гораздо меньшими техническими ресурсами, и проблема не в железе, а в желании решить проблему. А вот этого увы нет. Например когда у меня сперли запаску — я конкретно следаку и отличительные признаки указал и номер перекупа дал… Но увы заинтересованности нет, а мне в итоге через страховку все сделать быстрее было.
Тоже самое с ворованными трубками — вычислить местоположение телефона — задача нескольких секунд… но тоже…
Что значит «дешевле»? Проблема в том, что да, не считая тестовых утилит, проверяющих «полноту» и постоянно читающих часть данных, в реальных условиях хорошо если прочитают 1% или даже 0,1%. Вот только никто не знает какой именно 1% понадобится. Поэтому и будем писать все.
Почему еще? потому что могие вещи нужны постфактум для расследования.
Беда многих участвующих в дисскуссии в том, что они отталкиваются от тезиса: «ФСБ хотят следить за всеми, а это не возможно». И они правы в невозможности, но сам тезис не верен. Спец службы желают постфактум получить содержимое потоков по вполне конкретным поисковым запросам. Зачем им это — не знаю. Вероятно существуют какие то методики, веротно не нужно декодированное содержимое, а достаточно факта самого наличия потока шифрованного — не знаю.
Но кстати не 99% шифрованого… процентов 70. из которых очень многое или ненужные сайтики типа ленты или соцсети, которых можно принудить к сливу ключей.
А если писать весь трафик — то так примерно и выходит просто тупо из за цены винтов, и различного инженерного оборудования вокруг.
Именно это был сарказм :)
Увы, я не смеюсь над фактором репликации и да то что 3 реплики лучше чем 6 рейд, и какой это может дать профит на чтение (а так же какие недостатки мы поимеем на записи) я прекрасно знаю.
Проблема в том что фактор цены тут имеет определяющее значение.
Как я сказал оператор покупает систему которая не монетизируется, а еще ее эксплуатация жрет электричество и холод что тоже не бесплатно — он не заинтересован в надежности и скорости работы этой системы.
На самом деле в системе борются за каждый процент накладных расходов. У нас тут были крайне жаркие дискуссии между двумя решениями — одно требовало 3% места на диске на технологические нужды, другое 1%… Первое помедленнее, но способно работать на всем где можно нарезать ext4. Второе быстрее на порядок, но работает с дисками на низком уровне. Победило то, которое 3% за счет того что оно сможет работать с Куполом, но со скрипом. Так что ни про какие факторы репликации 3 (да хотя бы просто зеркало) мы даже не мечтаем.
А пользователя про «изменить» это тип б. «по классификации FYR» )))
Я все таки за важность баланса между семантикой и объемом кода… При большом объеме даже понятная семантика приводит к тому что упускаешь моменты. Отсюда сначала «стандартные библиотеки», потом и паттерны проектирования, а потом и целые фреймворки вылезают — такие своеобразные надстройки над языком.
Сказали тебе абстрактная фабрика — значит абстрактная фабрика и незачем тебе в семантику реализации читать.
В самом безобидном случае для того что бы обеспечить возможность лендинга на стационарные телефоны…
А так: для того чтобы сливать данные о вас (по порядку убывания) например банкам, спамерам, спецслужбам. А и не забываем также и о всей вашей записной книжке в телефоне, информацию о них тоже слить можно.
И я не поверю в непогрешимость телеги в защите приватности и несотрудничестве со спец службами ровно до тех пор, пока в телеграмме остается привязка аккаунта пользователя к номеру телефона и телефонной книге пользователя. С точки зрения функционирования сервиса — номер телефона это просто 10 цифр, а контакты пользователя это просто контакты. Зачем их привязывать к телефону — крайне непонятно.
Сами по судите: протокол телеги открыт — нет абсолютно никаких технологических ограничений встроить в приложение watsup поддержку протокола telegram или написать какой то «шлюз».
Но они же наверное не для того придумывали свой закрытый протокол и писали свое закрытое приложение чтобы все кто ни попадя общался?
Например такая вот проблема:
Приложение (например elastic) имеет api диагностики через HTTP json. B заббикс может разбирать json. Но увы парсер путей там тупой до безобразия. А в диагности нашего приложения используются массивы, а элементы определяются не позицией, а наличием ключа с определенным значением (например:
На наше счастье названия модулей «удобные» и мы написали несложненький php скриптец, который делает из такой простыни, простыню плоскую:
и до метрики можно добраться плоским zabbix парсером: first_module.metrics.metric
Но вы правы таскать скрипты по серверам неудобно, и хотелось бы иметь такой скрипт например на сервере самого заббикса, ну или на прокси.
Есть ли какие то варианты расширения самого заббикс сервера?
В примере есть скрипт дискавери… По сути его задача прочитать на хосте конфиг в котором написано: блочные устройства с именами в /dev/mapper/XXX* это диски индексатора, /dev/mapper/YYY* это диски BLOB, /dev/mapper/ZZZ* это разное логгирование.
Соответственно на такую группу устройств рисуется одна группа метрик которые прибиты к своему application
Затем в самом скрипте метрики чуть более сложный однострочник вида:
UserParameter=custom.vfs.dev.read.sectors[*],realpath '$1' | xargs -I{} basename {} | uniq | xargs -I {} cat /sys/class/block/{}/stat | awk '{n += $$3}; END{print n}'Который по идее суммирует информацию по блочным устройствам, которые смонтированы куда надо.
Ну и плюсом собираются метрики по отдельным дискам дабы разобраться что к чему.
Но на самом деле, меня эта схема не очень устраивает потому как учитываются «средние значения», а при этом существует разный профиль например для индексатора крайне важен iops поэтому диски работают параллельно — и там не должно быть перекосов по нагрузке. А для BLOB iops не важны — софт работает на строго последовательный доступ и там диски работают так же последовательно и то что один пашет, а остальные простаивают — это норма. Что то можно учесть кастомными триггерами для приложения, а что то нет.
а. Разработчик, который хорошо знаком с кодом — он его автор, он знает суть деталей — для него нет цикла по переменной — он знает что делает целиком этот блок for. А вот эта лябда тут и так понятно для чего.
б. Разработчик, который только использует этот код и он например «почему то не работает». Он не понимает что может делать этот for c итерацией по i. А зачем тут лямбда и что она должна делать.
в. Разработчик, использующий код как библиотеку — он вообще в потроха не полезет, ему куда важнее насколько адекватен интерфейс метода или коментарии в заголовочнике.
И у вы на практике — это работает только когда все идеально — и код, и коментарии, и пространство имен, и общепринятый coding style.
И часто ситуация промежуточная — код выглядит читаемым и понятным, но по закону Мерфи существенные моменты, где то закопаны в дебрях.
В итоге вот эта грань между семантикой и длинной кода очень тонка. Да лично я предпочту
for ( namespace::listofmyclass::iterator it=....) вместо for (auto: a… Но это просто потому что часто приходится искать именно дефекты серии «хотели сделать вот так а получилось вот эдак)
В моем примере делится: количество тиков за интервал измерения (по сути это есть утилизация записью) на количество операций за этот же интервал (количество параллельных записей). Т.е. как и в вашем примере так и будет:
Пусть выполнялось:
5 одновременных операций.
каждая за 100 msec (реальный латенси 1 операции )
интервал опросов заббиксом 1 секунда. тогда…
write_util будет: 100 мсек * 5 операций / 1 секунду = 0.5 = 50 % (100 * 5 = 500 тиков это колонка w_ticks (ms))
а w_svctime: 500 / 1 секунду / (5 операций / 1 секунду )…
собственно технический делитель от забикса «1 секунда» сократится и получим:
100 * 5 / 5 == 100ms или искомыя средняя latency.
и другое. На самом деле на практике вдруг замечаешь, что резко изменилась форма графиков и просто начинаешь разбираться что случилось. Там уж и dmesg в помощь. И не всегда проблема бывает в вашем софте.
Был случай когда при обновлении не вытерся старый бинарник — он в принципе не очень мешал, а просто подтекал и кушал память потом его OOM прибивал, он перезапускался и так по кругу. На графиках это выглядело как рост операций ввода вывода от софта в виде пилы. Софт перекопали, проблем не нашли — в итоге оказалось что софтина выкушивала кеш операционной системы, что конечно приводило к изменению количества запросов.
Мой опыт показывает, что только тестирование на реальной машине, в реальной конфигурации, с реальными данными может показать насколько ваш
сферический конь в вакууметест в лаборатории соотноситься с реальнойкобылой в сараенагрузкой.И как раз только в реальных условиях вы сможете протестировать на реальном объеме записываемых данных с реальными ресурсами.
А то как бывает обычно: мы берем какое то хранилище у которого: кеш у дисков, кеш у raid контроллера, навороченное ssd кеширование, плюс кеш операционной системы и еще кеш внутри приложения. Еще до кучи супер пупер навороченные алгоритмы префетчинга и прочее. За все эти кеши и алгоритмы мы заплатили денежки прямо или опосредованно.
И начинаем тестировать его, так чтобы все эти кеши забились и перестали работать. Т.е. тестируя мы заведомо выходим на режимы в котором наша система работать не будет а все эти навороты ненужны. Ну и какая цена такому тестированию?
Но по другому мы действовать не можем ибо, а кто нам скажет с какой вероятностью мы будем попадать в эти кеши. А еще у которых есть 100500 настоек самого кеша, плюс в десять раз больше настроек всего остального на них влияющих начиная от конфигураций файловой системы, опций форматирования и монтирования, различных LVM.
И только наблюдая за системой «в реальной среде обитания» вы сможете сказать: «да кеши работают» или «нет не работают» или да — форма графиков в реальной среде совпадают с аналогичными в тестовой, значит скорее всего методика тестирования верна.
Насчет цитированного — увы будет ибо, делить надо не одновременные значения а дельту… Хотя возможно зависимые элементы и отработают одновременно — в такие моменты заббикса не углублялся.
В оправдание себя скажу — в статью не попало, но реальная срока в моем скрипте посложнее — ибо суммирует значения сразу с кучки дисков, причем в качестве параметра получает маску названий алиасов (несколько устройств разом). Кроме того мне не нужен мониторинг всей тьмы дисков. Разделы побиты на группы в соответствии с назначением и мониторятся именно группы. Но это лютый кастом и лишнее для статьи.
И да любые файлики userparams легко раскидываются на 2к машин разными системами деплоймента типа Ansible например. Ну и потом не всегда можно вот так взять и обновить заббикс на 3.4.
Ну о чем можно говорить с «с++ программистом» который не знает что такое итератор? И подчеркиваю это не зеленые студенты 1 курса… Это люди считающие что они достойны такого оклада…
Тоже самое с ворованными трубками — вычислить местоположение телефона — задача нескольких секунд… но тоже…
Почему еще? потому что могие вещи нужны постфактум для расследования.
Беда многих участвующих в дисскуссии в том, что они отталкиваются от тезиса: «ФСБ хотят следить за всеми, а это не возможно». И они правы в невозможности, но сам тезис не верен. Спец службы желают постфактум получить содержимое потоков по вполне конкретным поисковым запросам. Зачем им это — не знаю. Вероятно существуют какие то методики, веротно не нужно декодированное содержимое, а достаточно факта самого наличия потока шифрованного — не знаю.
Но кстати не 99% шифрованого… процентов 70. из которых очень многое или ненужные сайтики типа ленты или соцсети, которых можно принудить к сливу ключей.
А если писать весь трафик — то так примерно и выходит просто тупо из за цены винтов, и различного инженерного оборудования вокруг.
Увы, я не смеюсь над фактором репликации и да то что 3 реплики лучше чем 6 рейд, и какой это может дать профит на чтение (а так же какие недостатки мы поимеем на записи) я прекрасно знаю.
Проблема в том что фактор цены тут имеет определяющее значение.
Как я сказал оператор покупает систему которая не монетизируется, а еще ее эксплуатация жрет электричество и холод что тоже не бесплатно — он не заинтересован в надежности и скорости работы этой системы.
На самом деле в системе борются за каждый процент накладных расходов. У нас тут были крайне жаркие дискуссии между двумя решениями — одно требовало 3% места на диске на технологические нужды, другое 1%… Первое помедленнее, но способно работать на всем где можно нарезать ext4. Второе быстрее на порядок, но работает с дисками на низком уровне. Победило то, которое 3% за счет того что оно сможет работать с Куполом, но со скрипом. Так что ни про какие факторы репликации 3 (да хотя бы просто зеркало) мы даже не мечтаем.