вторник, 10 декабря 2019 г.

Мониторинг ZFS

               Для того чтобы разобраться с зависаниями операций по созданию snapshots в ZFS решил ее замониторить нормально. В Telegraf есть плагин для этого https://github.com/influxdata/telegraf/tree/master/plugins/inputs/zfs Начал разбираться с ним и выяснил забавное - в версии для Linux он собирает кучу детальной информации, но вот самые базовые метрики, на которые нужно смотреть в первую очередь (статус, capacity, fragmentation и тд) - не собирает. Причем такая ущербность присуща только Linux версии, под FreeBSD все нормально.  Нашел Isssue 2,5 летней давности - https://github.com/influxdata/telegraf/issues/2616
Тут во всей красе появился один из недостатков open source проектов - долго обсуждали какое решение лучше,  так и не довели ни одно до конца и забросили.  Я набросал pull request дабы эту проблему наконец-то закрыть - https://github.com/influxdata/telegraf/pull/6724  К сожалению от маинтейнеров ни ответа ни привета.
                  Забил болт, решил не ждать их и использовать свой форк. Набросал тут dashboard - может кому пригодится:

Сам dashboard можно взять отсюда https://grafana.com/grafana/dashboards/11364 или отсюда - https://github.com/yvasiyarov/zfs-dashboard    


вторник, 19 ноября 2019 г.

ZFS и ее особенности

     Поставил себе цель разобраться с тем как работает ZFS. Прочитал кучу полезной и не очень информации.  Потом наткнулся на статью http://www.bog.pp.ru/work/zfs.html Это самое подробное и детальное описание того как работает ZFS которое я встречал. Честно, я очень хотел бы быть хотябы в половину таким же умным как тот кто написал эту статью, но мне далеко еще до этого уровня.  Да, после прочтения статьи первоначальное чувство восторга от "ух ты какая ZFS крутая" смешивается  с горьковатым "херня полная багов", но на самом деле это и есть опыт. Все что есть в этом мире - это хрень полная багов. Просто не все с ними встречаются. 
      У этого же автора есть очень крутая статья про RAID - http://www.bog.pp.ru/hard/raid.html 

пятница, 18 октября 2019 г.

Proxmox VE: Replication Job failed

        Нас долгое время задалбывали рандомные варнинги приходящие от ProxmoxVE - Replication Job failed.  Какой-то дополнительной информации - что именно пошло не так и где proxmox не предоставляет. Вообще в этой системе с документацией туго,  и пул реквест им не пришлешь. Зато есть платная поддержка. 
               Эта хрень приходила в почту несколько месяцев,  админы все время грозились что-то сделать, но как-то у них не очень получалось. Мне как начальнику делать нехер, поэтому я закатав рукава полез внутрь proxmox. Внутри там с одной стороны все довольно красиво написано, API, плагины, код не плохого качества. С другой стороны - это все на перле. Никогда не думал что придется вспоминать перл, но как говорится никогда не говори никогда. 
          Оказалось что варнинги выбрасывались заданиями по репликации виртуальных машин с одного сервера на другой. Если быть более точным - реплицировались не сами виртуалки, а снэпшоты сделанные с виртуалки. Причем обычно все отрабатывало штатно, а в некоторых случаях (примерно 10%) это заканчивалось ничем. С чем это было связано - непонятно.
            Покопавшись в коде выяснил что "репликация" производится путем выполнения команд через shell, с каким-то таймаутом.  Если команды не укладывается в заданный таймаут - процесс завершается ошибкой. Никаких настроек типа "таймаут такой-то" в конфигах ProxmoxVE нет. Есть только магические чиселки, прямо в перловом коде. Чиселок много, они разным способом перетирают друг друга, комментарии в коде - это тоже для слабоков.     
            В общем если вас преследует аналогичная проблема, то в случае ZFS менять таймаут нужно в PVE/Storage/ZFS/PoolPlugin.pm, строка 185:
Если вы используете другой сторадж - логично будет посмотреть в других модулях директории PVE/Storage. Место установки  перловых модулей зависит от системы, у меня они лежат в /usr/share/perl5/

понедельник, 23 сентября 2019 г.

AppOptics и другие продукты SolarWinds

        Не в первый раз встречаюсь с продуктами SolarWinds, и каждый раз они оказываются редкостным дермищем которое стоит конских денег. Сначала я познакомился с мониторингом баз данных, в частности MS SQL. Это решение стоит нам около 5k USD в год, это при том что у нас довольно мало серверов баз данных и по сути мы мониторим только прод. Но оно выглядит как дедушка нагиоса или отец заббикса. В общем по сравнению с тем же PMM от перконы(бесплатного между прочим!!) - это просто диназавр из начала двухтясячных. 
         Другой пример - AppOptics. Это такой клон NewRelic, только херовенький. У него все нормально с юхабилити/внешним видом, но он нифига не работает. Ты его ставишь а данные не появляются. Вот уже неделю как разговариваю с саппорттом по поводу этой проблемы и пока результат никакой. Но при всем этом решение также стоит немалых денег. 
          В общем на мой взгляд - SolarWinds это хороший пример дерьмокомпании, которой я всячески желаю обанкротиться.   

вторник, 17 сентября 2019 г.

Code review

      Про code review много чего сказано, написано. Но все как-то кусочками. И не совсем тем что написано я был согласен. А тут наткнулся на документ где (с моей точки зрения) все правильно написано, и довольно полно.  https://google.github.io/eng-practices/review/reviewer/ Самое ценное в этом документе на мой взгляд то что он охватывает не только и не столько техническую часть, сколько организационную и то что касается человеческого общения. Про это вообще мало кто пишет. Многие вообще считают что диктатура при code review - это круто. И не понимают что code review - это в первую очередь менторство, а не поле для самоутверждения.  

воскресенье, 1 сентября 2019 г.

Из Golang в Assembler

       Я в последнее время все меньше пишу про Golang. Наверное потому что пишу в основном про то что меня интересует, а в мире Golang в последнее время меня не так много интересовало.  Недавно был на Golang meetup - из трех докладов интересным в какой-то степени был один, да и тот был интересен в основном отдельными техническими  деталями. Такого чтобы - ах как клево, давно не было. 
       На выходных отсматривал видео с GopherCon 2019. Из того что посмотрел очень понравился доклад Michael McLoughlin про то как они местами переписывают с Golang на Assembler. Ребята на мой взгляд пропагандируют очень здравый подход к оптимизации.  
            Посмотрев этот доклад я с удивлением обнаружил отсылку к докладу с GopherCon Russia. Вообще очень не часто можно встретить в докладах ведущих конференций ссылку на материалы российских конференций. Но в данном случае можно сказать что доклад Marko Kevac о bitmap индексах этого более чем заслужил.  
Для тех кому лень смотреть просто оставлю ссылку на https://github.com/mmcloughlin/avo