Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 3733 сообщений
Cообщения с меткой

мониторинг - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Мониторинг работы производства веб-студии

Пятница, 21 Июля 2017 г. 12:41 (ссылка)





Прежде чем что-то оценить, это нужно измерить. В предыдущих материалах мы строили производство веб-студии. Теперь давайте научимся измерять его эффективность. Как только научимся измерять, будет понятно, что нужно улучшать. В нашем деле любой, даже самый незначительный эффект, может дать существенный прирост прибыли.



Предлагая разработку сайтов по низкой стоимости и обеспечивая высокое качество, вы можете быть уверены, что не столкнетесь с недостатком заказов. Но имейте в виду, что с точки зрения бизнеса, такая модель очень неустойчива. Если погнаться за количеством, можно быстро растерять своих клиентов, а замешкавшись, можно и вовсе уйти в минус, не получив и шанса на развитие.



Мне всегда было интересно создать сбалансированную систему показателей, ориентируясь на которую, можно было бы эффективно управлять веб-производством, стремясь к золотой середине. В этой небольшой статье я расскажу про систему оценки эффективности, которую мы уже много лет используем в WebCanape.



Если вы захотите примерить эту систему на себя, имейте в виду, что приведенные показатели, скорее всего, подходят производствам, которые, как и мы, выпускают однородный продукт и имеют четкую ценовую политику. Цены на сайты меняются в зависимости от функционала, но порядок формирования цены одинаков.



Показатели эффективности работы веб-студии



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



Общий план по доходам (ОПД). Данный показатель говорит о способности производства генерировать необходимый денежный поток.



Тут все просто. Мы ставим два плановых показателя: минимальный и желаемый. Минимальный необходим, чтобы покрыть расходы с небольшим запасом, желаемый — чтобы получить прибыль. И тот, и другой планы ежемесячно увеличиваются с учетом ежегодного плана роста компании.



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



Использование фонда рабочего времени (ФРВ). Данный показатель говорит об уровне дисциплины на производстве и эффективности организации труда, что является фундаментом для успешного бизнеса.



ФРВ складывается из общего числа часов, выделенных задействованным на производстве разработчикам. Чтобы рассчитать показатель, разделим фактическое время, затраченное разработчиками, на общий ФРВ. Показатель лучше всего выводить в процентах. Чем выше данный показатель, тем лучше. Количество рабочих часов на человека в месяц можно найти в любом производственном календаре.



Для нас норма — это 80%. Это значит, что 80% доступного фонда рабочего времени мы тратим на работу по проектам. Остальные 20% мы оставляем на обучение, чай, обсуждение решений для тех или иных задач, совещания.



Использование ФРВ на коммерческие проекты (ФРВ$). С помощью данного показателя мы оцениваем целевое использование производственных ресурсов компании.



Определяя его, мы узнаем, какой процент от ФРВ ушел на коммерческие проекты. Для разделения часов (коммерческие/некоммерческие) мы используем трекеры в Redmine, по которым в дальнейшем легко делать срезы статистики.



Чтобы рассчитать показатель, разделим общее время по коммерческим проектам на время, отработанное по всем проектам, и умножим на 100%. В нашем случае ФРВ$ должен быть не менее 80%. Остальное время мы можем тратить на внутренние проекты и развитие.



Выполнение нормативов. Через этот показатель можно оценить способность производства выполнять заложенные в стоимость продукта нормативы.



Каждый договор с клиентом — это определенное число часов на разработку проекта. В конце месяца по каждому выполненному проекту мы подсчитываем количество затраченного времени и сопоставляем его с плановым (договорным), оценивая, насколько мы уложились в нормативы или превысили их. Помните табличку в материале «Подбор команды веб-студии и распределение ролей»?



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



Рентабельность производственных активов (РПА). Фактически, это итоговая стоимость часа, по которой мы отработали месяц.



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



Рассчитывается показатель легко. Среднее время на проект (в часах) делим на среднюю стоимость проекта. Данные по затраченным часам берем из Redmine или любого другого task-менеджера, а стоимость разработки проекта — из договора.



Выполнение сроков. Заключительный и очень важный показатель для оценки – выполнение обязательств по срокам.



Для его расчета мы учитываем фактические рабочие дни, затраченные на проект, и сравниваем их с плановыми договорными сроками. Делим средний по проектам плановый срок на средний фактический срок и получаем показатель выполнения сроков. Правило то же: показатель должен быть не менее 70% и расти с каждым месяцем.



Если интересно, предлагаю ознакомиться с таблицей, которую можно использовать для расчета.



Замечу, что приведенные показатели имеет смысл рассматривать не только в разрезе всего производства, но и применительно к проектам по каждому менеджеру. Анализ показателей отдельно по каждому менеджеру проектов дает хорошую почву для размышлений. Это и есть самое ценное в данных расчетах.



Результаты мы анализируем в течение месяца, для своевременной диагностики проблем — разбираем на собраниях, смотрим «узкие места», используем для выбора лучших разработчиков и менеджеров. На основе этих же данных мы рассчитываем премии менеджерского состава.



Как работать с показателями?



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



Добейтесь показателей:


  • Выполнение плана по доходам: > 100%

  • Использование ФРВ: > 70%

  • Использование ФРВ на коммерческие проекты: > 70%

  • Рентабельность производственных активов: > 90%

  • Выполнение нормативов: > 90%

  • Выполнение сроков: > 90%





Работайте с показателями последовательно. За каждым из них стоит значительное количество изменений на производстве и в головах сотрудников. Добейтесь максимальных результатов, не поднимая стоимость проектов. Поднять стоимость можно всегда, и гораздо приятней делать это, когда все остальные показатели в норме.



Вытягивание нормативов может занять 6-8 месяцев, это нормально. На нужные цифры можно выйти благодаря автоматизации, росту квалификации разработчиков, отказу от части работ, правильному походу к выбору клиентов, повышению цен, в конце концов, и другие.



Лично мы, постигая все на собственных ошибках, на показатель выполнения сроков обратили серьезное внимание не сразу. Когда осознали важность этого, родилась идея с телевизором, который до сих пор исправно работает.



Вместо заключения



Многие зададут вопрос: «А как же показатель качества?» Почему он не вошел в данную систему? Мы считаем, что это понятие относительное, и у каждой студии о нем свое представление. Для соблюдения технических показателей качества WebCanape мы разработали технологию производства сайтов для малого бизнеса, которая включает 120 параметров (плюс/минус). Этот чек-лист проверяет служба тестирования и менеджер проекта, прежде чем дать разрешение на выкладку сайта. Время, необходимое на проверку качества, закладывается в стоимость продукта и учитывается при расчете вышеперечисленных показателей.



Надеюсь, доступно рассказал про нашу систему контроля производства? В следующем материале напишу про градацию сотрудников и систему мотивации.



Подключайтесь в общую тусовку в telegram, где можно задавать вопросы и общаться + подписывайтесь на наш хабра-блог.



Команда WebCanape
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333842/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
ОНФ_Камчатки

ОНФ на Камчатке проверит удовлетворенность граждан реализацией проекта благоустройства городской среды

Среда, 13 Июля 2017 г. 00:51 (ссылка)

DSC07158 (600x450, 131Kb)


Активисты регионального штаба Общероссийского народного фронта в Камчатском крае проверят удовлетворенность граждан реализацией правительственного проекта «Формирование комфортной городской среды». В ходе июльского мониторинга им предстоит оценить работу органов власти в данном направлении, общественное участие и удовлетворенность граждан дизайн-проектами, утвержденными в рамках муниципальных программ формирования современной городской среды в 2017 г.



Координатор Центра мониторинга благоустройства городской среды Народного фронта, сопредседатель регионального штаба ОНФ Татьяна Смирнова отметила, что контроль за процессами благоустройства ведется в постоянном режиме: активисты ОНФ следят за сроками исполнения этапов проекта, соответствием местных нормативных документов предъявляемым требованиям, информационной открытостью. Пристальное внимание общественников направлено на проблемы, которые возникают в ходе исполнения программ.



«Муниципальные программы, направленные на благоустройство городской среды, реализуются первый год. Не удивительно, что возникают нюансы и трудности, которые разработчики предусмотреть не смогли. Именно поэтому сейчас так важна аналитическая работа, которая позволит совершенствовать правовую базу проекта и скорректировать усилия уполномоченных органов администрации», – заявила Смирнова.



В ходе мониторинга активистам ОНФ предстоит изучить сопутствующую документацию, поговорить с жителями домов, чьи дворы включены в программу на 2017 г. Однако уже сейчас, по мнению Смирновой, можно говорить об отдельных недостатках реализации в Камчатском крае приоритетного госпроекта.



Для программ, разработанных в Петропавловске-Камчатском, Елизово и Вилючинске, характерно отсутствие образцов элементов благоустройства. На интернет-сайтах Елизовского муниципального образования и Вилючинска в разделе «Современная городская среда» представлены их единичные экземпляры. На сайте администрации Петропавловск-Камчатского городского округа визуализация объектов отсутствует вовсе. Представитель ОНФ уверена, что этот организационный недостаток мешает созданию представления о возможностях преобразования территорий.



«Нужно сделать так, чтобы у людей был выбор малых архитектурных форм, скамеек, световых опор и прочих элементов, чтобы они могли обустроить свой двор не только с учетом функциональности, но и с учетом собственных представлений о красоте», – считает Смирнова.



Еще одна озабоченность общественников связана с ремонтом дворовых проездов, который в 2017 г. в большинстве случаев планируется выполнить без обустройства ливневых стоков. Представитель ОНФ отметила, что эта тенденция может вызвать крайне нежелательные последствия, поскольку есть вероятность затопления отдельных дворов. Причиной такого решения, по мнению Смирновой, может быть то, что укладка асфальтового покрытия входит в основной перечень работ и финансируется из средств проекта «Формирование комфортной городской среды», а обустройство ливневок относится к перечню дополнительных работ, которые проводятся на условиях софинансирования жителями. Сложившаяся практика показывает, что вкладывать собственные средства в благоустройство дворов жители Камчатки не готовы.




По мнению Смирновой, выходом из этой ситуации может служить расширение перечня обязательных работ с включением тех видов работ, которые по техническому регламенту должны выполняться одновременно. Еще один путь – тщательный отбор претендентов. «Я бы рекомендовала муниципальным комиссиям при рассмотрении заявок на участие в программе отдавать предпочтение тем проектам, которые предполагают комплексное обустройство дворовых территорий», – резюмировала она.




Центр мониторинга благоустройства городской среды ОНФ призван вовлекать граждан в принятие решений по благоустройству своих дворов и общедоступных зон отдыха, парковых зон, скверов, площадей улиц и сформировать у них чувство ответственности по отношению к инфраструктуре своего места жительства. При утверждении программ благоустройства городской среды будет учитываться мнение граждан путем общественного обсуждения проектов, проведения обучающих мероприятий и разработки методических рекомендаций.

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
mahandreare71

Без заголовка

Понедельник, 10 Июля 2017 г. 21:32 (ссылка)

Мониторинг событий иб в Москве, Московской области
Подробнее тут - http://www.securityvision.ru/


ГК ИНТЕЛЛЕКТУАЛЬНАЯ БЕЗОПАСНОСТЬ
Телефон: +7 (495) 729-3196, +7 (926) 619-3379

Email: sales@securityvision.ru
http://www.securityvision.ru/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
nokyla

Без заголовка

Понедельник, 10 Июля 2017 г. 16:20 (ссылка)

Мониторинг событий иб в Москве, Московской области - https://vk.com/page-129403672_54554429

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Kubernetes & production — быть или не быть?

Пятница, 07 Июля 2017 г. 09:01 (ссылка)

Сотни контейнеров. Миллионы внешних запросов. Миллиарды внутренних транзакций. Мониторинг и нотификации проблем. Простое масштабирование. 99% up time. Деплои и откатывание релизов.







Kubernetes как решение всех проблем! «Быть или не быть?» — вот в чем вопрос!





Disclaimer



Не смотря на публичность данной статьи, скорее всего, я пишу это в первую очередь для себя, как разговор с резиновой уточкой. После более чем двухгодового плавания с «хипстерскими» технологиями, я должен сделать шаг в сторону и адекватно оценить насколько это было обоснованно и будет адекватно для моего любого следующего проекта.



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



Я попытаюсь описать весь опыт, полученный нами в `Lazada Express Logistics`, компании являющейся частью `Lazada Group`, которая в свою очередь — часть `Alibaba Group`. Мы разрабатываем и осуществляем поддержку систем автоматизирующих по-максимуму весь операционный цикл доставки и фулфилмента в 6 крупнейших странах Юго-восточной Азии.



Предпосылки к использованию



Однажды представитель компании, продающей облачные решения по всему миру, спросил у меня: «А что для Вас 'облако'?». Помешкав пару секунд (и подумав:«Хммм… наш диалог явно не о взвешенных в атмосфере конденсациях водяного пара...»), я ответил, что, мол, это как будто один сверх-надежный компьютер с неограниченными ресурсами и практически не имеющий накладных расходов на передачу потоков данных(cеть, диск, память, т.д.). Словно это мой лэптоп работающий для всего мира и способный держать такую нагрузку, а я в одиночку способен им управлять.







Собственно зачем нам это облачное чудо? Все в общем-то очень просто! Мы стремимся облегчить жизнь разработчиков, системных администраторов, devops-ов, тех-менеджеров. А такая вещь, как правильно приготовленное облако, многократно облегчает жизнь всем. Да и помимо всего прочего, мономорфные системы работающие на бизнес всегда дешевле и порождают меньше рисков.



Мы задались целью найти простую, удобную и надежную платформу приватного облака для всех наших приложений и для всех типов ролей в команде перечисленных выше. Провели небольшое исследование: Docker, Puppet, Swarm, Mesos, Openshift + Kubernetes, Kubernetes — Openshift… остановились на последнем — Kubernetes безо всяких аддонов.



Функционал описанный на самой первой странице отлично вписывался и годился для всего нашего предприятия. Подробное изучение документации, болтовня с коллегами и небольшой опыт быстрой пробы. Все это дало уверенность, что авторы продукта не врут, и мы сможем получить наше великолепное облако!



Засучили рукава. И понеслось…



Проблемы и их решения









3-х уровневая архитектура



Все идет с основ. Для того чтобы создать систему, способную хорошо жить в кластере Kubernetes, вам придется продумать архитектуру и процессы разработки, настроить кучу механизмов и средств доставки, научиться мириться с ограничениями/концепциями мира Docker и изолированных процессов.







Как итог: мы приходим к выводу, что идеология микро-сервисной и сервисно-ориентированной архитектуры как не кстати годится для наших задач. Если вы читали статью Мартина Фаулера(перевод) на эту тему, то более-менее должны представлять какой титанический труд должен быть проделан, прежде чем первый сервис оживет.



Мой чек-лист разделяет инфраструктуру на три слоя, а затем примерно описывает то, о чем на каждом из уровней нужно помнить при создании подобных систем. Три слоя о которых идет речь:


  • Hardware — сервера, физические сети

  • Cluster — в нашем случае Kubernetes и системные сервисы поддерживающие его (flannel, etcd, confd, docker)

  • Service — непосредственно процесс упакованный в Docker — микро/макро сервис в своем домене



Вообще идея 3-х слойной архитектуры и задач связанных с ней — это тема отдельной статьи. Но в свет она выйдет не раньше, чем этот самый чек-лист будет безукоризненно полон. Это может и не случиться никогда :)




Квалифицированные специалисты



Насколько тема приватных облаков актуальна и интересна все больше и больше среднему и крупному бизнесу, настолько же актуален вопрос о квалифицированных архитекторах, devops-ах, разработчиках, администраторах баз данных способных с этим работать.







Причина тому — новые технологии, которые, поступая на рынок, не успевают обрастать нужным объемом документации, обучающих статей и ответов на `Stack Overflow`. Однако, не смотря на это, такие технологии, как в нашем случае, Kubernetes — становятся очень популярными и создают дефицит кадров.



Решение простое — нужно взращивать специалистов внутри компании! Благо, в нашем случае, мы уже знали что такое Docker и как его готовить — остальное пришлось нагонять.



Continuous Delivery/Integration



Не смотря на всю прелесть технологии «умного облачного кластера», нам были необходимы средства общения и установки объектов внутрь Kubernetes. Пройдя дорогу от самописного bash скрипта и сотен ветвей логики, мы закончили вполне понятными и читаемыми рецептами для Ansible. Для полноценного превращения Docker файлов в живые объекты нам понадобилось:




  • Набор стандартных решений:


    • Team City — для автоматизированных деплоев

    • Ansible — для сборки шаблонов и доставки/установки объектов

    • Docker Registry — для хранения и доставки Docker образов


  • images-builder — скрипт для рекурсивного поиска Docker файлов в репозитории и отправки образов на их основе после сборки в централизованное registry

  • Ansible Kubernetes Module — модуль для установки объектов с различными стратегиями в зависимости от объекта (создать или обновить/создать или заменить/создать или пропустить)









По мимо всего прочего мы изучали вопрос о Kubernetes Helm. Но тем не менее, не смогли найти той самой killer-feature, которая могла бы заставить нас отказаться или заменить Ansible шаблонизацию на Helm чарты. Других полезных способностей этого решения мы не смогли найти.



Например, как делать проверку того, что один из объектов успешно установлен и можно продолжить выкатку других? Или как делать более тонкие настройки и установки контейнеров, которые уже работают, и нужно просто выполнить пару команд внутри их?



Эти и многие другие вопросы обязывают относиться к Helm как к простому шаблонизатору. Но зачем это?.. если Jinja2, входящая в состав Ansible, даст фору любому не профильному решению.





Сервисы хранящие состояние



Как полноценное решение для любого типа сервисов, включая statefull(имеющие состояние), Kubernetes поставляется с набором драйверов для работы с сетевыми блочными устройствами. В случае с AWS, единственный приемлемый вариант — EBS.



Как вы можете убедится, треккер k8s пестрит кучей багов связанных с EBS, и решаются они довольно медленно. На сегодня, мы не страдаем от каких-то серьезных проблем, помимо того, что, иногда, для создания объекта с персистентным хранилищем требуется до 20 минут. Интеграция EBS-k8s очень, очень, очень сомнительного качества.







Однако, даже если вы используете другие решения для хранилищ и не испытываете особых проблем, то, все равно, будете нуждаться в качественных решениях для всего, что может хранить данные. Мы потратили уйму времени, чтобы заполнить пробелы и предоставить качественные решения для каждого из случаев:







Помимо всего прочего, Kubernetes, да и Docker мир, в принципе, обязывает, иногда, к множеству хитростей и тонкостей, которые очевидны на первый взгляд, но требуют дополнительного решения.



Небольшой пример.

Собирать логи внутри запущенного Docker контейнера нельзя. НО очень много систем и фреймворков не готовы к стримингу в `STDOUT`. Нужно заниматься `патчингом` и осознанной разработкой на системном уровне: писать в пайпы, заботиться о процессах и т.д. Немного времени и у нас есть Monolog Handler для `php`, который способен выдавать логи так, как их поймет Docker/k8s




API Gateway



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



Все довольно просто — нужна единая точка отказа доступа ко всем вашим сервисам.







Есть ряд задач которые мы решали в разрезе Kubernetes кластера:




  • Контроль доступа и лимитация запросов извне — как пример небольшой LUA скрипт проливает свет на проблему

  • Единая точка аутентификации/авторизации пользователей для любых сервисов

  • Отсутствие множества сервисов требующих доступ по HTTP из `мира` — резервирование портов на серверах для каждого желающего сервиса управляется тяжелее, чем роутинг в Nginx

  • Интеграция Kubernetes-AWS для работы с AWS Load Balancer

  • Единая точка мониторинга HTTP статусов — удобно даже для внутреннего общения сервисов

  • Динамическая маршрутизация запросов на сервисы или версии сервисов, A/B тесты (альтернативно проблема может решаться разными pod-ами за сервисом Kubernetes)



Искушенный пользователь Kubernetes поспешит спросить о Kubernetes Ingress Resource, который предназначен именно для решения подобных задач. Все верно! Но мы требовали немного больше `фич`, как вы могли заметить, для нашего API Gateway чем есть в Ingress. Тем более, это всего лишь обертка для Nginx, с которым мы и так умеем работать.




Текущее состояние



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







Что же из себя представляет платформа в текущем состоянии — немного сухих фактов:


  • Всего 2-3 человека для поддержки всей платформы

  • Один репозиторий хранящий всю информацию обо всей инфраструктуре

  • От 10-50 независимых автоматизированных релизов в день — CI/CD mode

  • Ansible как средство управления кластером

  • Считанные часы для создания идентичного `life` окружения — локально на minikube или на реальных серверах

  • AWS-based архитектура на базе EC2 + EBS, CentOS, Flannel

  • 500~1000 pod-ов в системе

  • Лист технологий завернутых в Docker/K8s: Go, PHP, JAVA/Spring FW/Apache Camel, Postgres/Pgpool/Repmgr, RabbitMQ, Redis, Elastic Search/Kibana, FluentD, Prometheus, etc

  • Инфраструктура вне кластера отсутствует, за исключением мониторинга на уровне `Hardware`

  • Централизованное хранилище логов на базе Elastic Search внутри Kubernetes кластера

  • Единая точка сбора метрик и алертинга проблем на базе Prometheus



Список отражает множество фактов, но опущенными остаются явные преимущества и приятные особенности Kubernetes как системы управления Docker процессами. Подробнее с этими вещами можно ознакомится на оффициальном сайте Kubernetes, в статьях на том же Хабре или Medium.


Длинный список наших пожеланий, которые находятся на стадии прототипов или пока еще покрывают небольшую часть системы, тоже очень большой:


  • Система профилирования и трэйсинга — например, zipkin

  • Anomaly detectionмашинно обучаемые алгоритмы для анализа проблем по сотням метрик, когда мы не можем или не хотим понимать что значит каждая метрика/набор метрик в отдельности, но хотим знать о проблеме связанной с этими метриками

  • Автоматическое планирование мощностей и масштабирование как количества pod-ов в сервисе так и серверов в кластере на основе определенных метрик

  • Интеллектуальная система управления бэкапами — для любых stateful сервисов, в первую очередь баз данных

  • Система мониторинга сетей и визуализации связей — внутри кластера, между сервисами и pod-ами, прежде всего (интересный пример)

  • Federation mode — распределенный и связнный режим работы нескольких кластеров





Тaк быть или не быть?



Опытный читатель, скорее всего, уже догадался, что статья врядли даст однозначный ответ на такой, казалось бы, простой короткий вопрос. Множество деталей и мелочей могут сделают вашу систему безумно крутой и производительной. Или другое множество багов и кривых имплементаций превратят вашу жизнь в ад.



Решать вам! Но мое мнение по поводу всего этого: «БЫТЬ!.. но очень аккуратно»
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/332108/

Комментарии (0)КомментироватьВ цитатник или сообщество
Алла_Ру

Мониторинг качества образования 1-2 класс.

Воскресенье, 03 Июля 2017 г. 00:33 (ссылка)
https://www.metod-kopilka.r...-47041.htm

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Алла_Ру

Мониторинг ЗУН 1-2 класс.

Воскресенье, 03 Июля 2017 г. 00:29 (ссылка)
festival.1september.ru/articles/612820/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Использование Pinba в Badoo: то, чего вы еще не знаете

Пятница, 30 Июня 2017 г. 11:21 (ссылка)



Привет, Хабр! Меня зовут Денис, я – PHP-разработчик в Badoo, и сейчас я расскажу, как мы сами используем Pinba. Предполагается, что вы уже знаете, что это за инструмент, и у вас есть опыт его эксплуатации. Если нет, то для ознакомления рекомендую статью моего коллеги, Максима Матюхина.



Вообще на Хабре есть достаточно материалов об использовании Pinba в различных компаниях, включая пост Олега Ефимова в нашем блоге. Но все они касаются других компаний, а не Badoo, что немного нелогично: сами придумали инструмент, выложили в open source и не делимся опытом. Да, мы часто упоминаем Pinba в различных публикациях и в докладах на IT-конференциях, но обычно это выглядит как-то так: «А вот эти замечательные графики мы получили по данным из Pinba» или «Для измерения мы использовали Pinba», и всё.



Общение с коллегами из других компаний показало две вещи: во-первых, достаточно много людей используют Pinba, а во-вторых, часть из них не знают или не используют все возможности этого инструмента, а некоторые не до конца понимают его предназначение. Поэтому я постараюсь рассказать о тех нюансах, которые явно не указаны в документации, о новых возможностях и наиболее интересных кейсах применения Pinba в Badoo. Поехали!



Небольшое введение



В документации сказано, что «Pinba – это сервер статистики, использующий MySQL в качестве интерфейса...» Обратите внимание на понятие «интерфейс», использующееся не в значении хранилища данных, а именно в значении интерфейса. В первых версиях Pinba, автором которой был ещё Андрей Нигматуллин, не было никакого MySQL-интерфейса, и для получения данных необходимо было использовать отдельный протокол. Что, естественно, неудобно.



Позднее Антон Довгаль tony2001 добавил этот функционал, чем значительно облегчил процесс получения данных. Стало возможным не писать никакие скрипты, достаточно любым MySQL-клиентом присоединиться к базе и простыми SQL-запросами получить всю информацию. Но при этом внутри себя Pinba хранит данные в своём внутреннем формате, и MySQL-движок используется только для отображения. Что это значит? А значит это то, что на самом деле никаких реальных таблиц не существует. «Ложки нет». Вы даже можете спокойно удалить одну из так называемых таблиц с «сырыми» данными, например, requests – и после этого все ваши отчёты по-прежнему будут работать.



Ведь сами данные никуда не исчезнут. Вы просто не сможете обращаться к этой таблице в SQL-запросах. Именно поэтому основной причиной использования именно отчётов (а не «сырых» таблиц) является то, что при сложных запросах (несколько JOIN и т. п.) Pinba должна «на лету» отфильтровать и сгруппировать все данные.



Я понимаю, что, зная SQL, можно легко из таблиц с «сырыми» данными получить все выборки, но это путь к тёмной стороне силы. Этот способ крайне ресурсозатратен. Конечно, все запросы будут работать, и зачастую, когда нужно срочно что-нибудь отдебажить, можно залезть в таблицу requests или tags. Но очень не рекомендую делать это без надобности только потому, что так проще и быстрее. Вся сила Pinba – в отчётах.



Создавать отчёты достаточно просто, но и тут существуют некоторые тонкости. Как я уже сказал, никаких таблиц не существует, и когда вы создаёте отчёт, то есть выполняете запрос CREATE TABLE, вы лишь сообщаете сервису о том, какие агрегации вам будут нужны. И пока не будет сделан первый запрос в эту «таблицу», никакие агрегации не будут собираться. Тут есть один важный нюанс: если вы начали собирать какие-то данные, а потом они уже не нужны, то «таблицу» с отчётом лучше удалить. Pinba не мониторит, перестали вы пользоваться отчётом или нет: один раз запросили данные – они будут собираться всегда.



Ещё один момент, который нужно учитывать при создании отчётов: для каждого типа отчёта есть свой набор полей. При отображении в MySQL Pinba ориентируется на порядок полей, а не на их названия, поэтому нельзя просто взять и поменять местами поля или не указать часть полей:



CREATE TABLE `tag_report_perf` (
`script_name` varchar(128) NOT NULL DEFAULT '',
`tag_value` varchar(64) DEFAULT NULL,
`req_count` int(11) DEFAULT NULL,
`req_per_sec` float DEFAULT NULL,
`hit_count` int(11) DEFAULT NULL,
`hit_per_sec` float DEFAULT NULL,
`timer_value` float DEFAULT NULL,
`timer_median` float DEFAULT NULL,
`ru_utime_value` float DEFAULT NULL,
`ru_stime_value` float DEFAULT NULL,
`index_value` varchar(256) DEFAULT NULL,
`p75` float DEFAULT NULL,
`p95` float DEFAULT NULL,
`p99` float DEFAULT NULL,
`p100` float DEFAULT NULL,
KEY `script_name` (`script_name`)
) ENGINE=PINBA DEFAULT CHARSET=latin1
COMMENT='tag_report:perf::75,95,99,100'


В этом примере мы создаём отчёт типа tag_report; значит, первое поле всегда будет содержать название скрипта, за ним будет идти значение тега perf, затем – полный набор всех полей и в конце – нужные нам перцентили. Это тот случай, когда не надо фантазировать, а следует просто взять структуру таблицы из документации и скопировать её. Естественно, поля с названием тегов можно и даже нужно назвать более понятно, чем tag1_value, tag2_value, и порядок тегов и перцентилей в таблице должен совпадать с их порядком в описании.



Агрегации по тегам запроса (request’s tags)



Как вы знаете, у Pinba есть несколько типов отчётов, и относительно недавно (полтора года назад) мы добавили ещё отчёты по тегам запроса. До этого по тегам запроса (не путайте с тегами таймеров, это разные вещи) можно было только фильтровать, но никаких агрегаций не было.



Зачем нам потребовалась такой функционал? Один из основных типов контента в Badoo – фотографии. Нашим сервисом пользуются более 350 миллионов пользователей, у большинства из которых есть фотографии. Для отдачи фотографий у нас есть два типа машин: так называемые фотокеши – машины с «быстрыми» дисками, на которых лежат только активно запрашиваемые изображения, и основные “стороджи” — машины, где хранятся все фотографии.



Подробнее о системе хранения фотографий рассказывал на последнем HighLoad++ Артём Денисов. Если мы откажемся от кеширования и пустим весь трафик на «медленные» фотохранилища, то в лучшем случае сущеcтвенно увеличится время отдачи фото, в худшем – мы вообще не сможем с некоторых машин отдавать контент, и запросы будут отваливаться по тайм-ауту. Сейчас хитрейт у нас порядка 98%.



Казалось бы, всё очень хорошо, но падение хитрейта, скажем, до 96% сразу увеличивает нагрузку на кластер фотохранилища в два раза. Поэтому нам очень важно следить за хитрейтом и не допускать значительных падений. И мы решили делать это с помощью Pinba. Поскольку на машинах с фотокешами не используется PHP (весь контент отдаётся через веб-сервер), мы используем плагин Pinba к nginx.



Но вот незадача – внутри nginx мы не можем использовать таймеры и агрегацию по тегам таймера, но активно можем проставлять теги на сам запрос. Причём нам очень хотелось сделать разбивку по размеру изображений, по типу приложения и по ещё нескольким параметрам. У запроса может быть несколько тегов, и по всем нам нужно агрегировать. Для этой цели были созданы следующие типы отчётов:




  • rtag_info – агрегация по одному тегу,

  • rtagN_info – агрегкация по нескольким тегам,

  • rtag_report – агрегация по одному тегу и хосту,

  • rtagN_report – агрегация по нескольким тегам и хосту.



Вот примеры отчётов:



CREATE TABLE `photoscache_report_hitrate` (
`hostname` varchar(64) NOT NULL DEFAULT '',
`tag1_value` varchar(64) DEFAULT NULL,
`tag2_value` varchar(64) DEFAULT NULL,
`tag3_value` varchar(64) DEFAULT NULL,
`req_count` int(11) DEFAULT NULL,
`req_per_sec` float DEFAULT NULL,
`req_time_total` float DEFAULT NULL,
`req_time_percent` float DEFAULT NULL,
`req_time_per_sec` float DEFAULT NULL,
`ru_utime_total` float DEFAULT NULL,
`ru_utime_percent` float DEFAULT NULL,
`ru_utime_per_sec` float DEFAULT NULL,
`ru_stime_total` float DEFAULT NULL,
`ru_stime_percent` float DEFAULT NULL,
`ru_stime_per_sec` float DEFAULT NULL,
`traffic_total` float DEFAULT NULL,
`traffic_percent` float DEFAULT NULL,
`traffic_per_sec` float DEFAULT NULL,
`memory_footprint_total` float DEFAULT NULL,
`memory_footprint_percent` float DEFAULT NULL,
`req_time_median` float DEFAULT NULL,
`index_value` varchar(256) DEFAULT NULL,
KEY `hostname` (`hostname`)
) ENGINE=PINBA DEFAULT CHARSET=latin1 COMMENT='rtagN_report:served_by,build,img_size'

CREATE TABLE `photoscache_top_size` (
`geo` varchar(64) DEFAULT NULL,
`req_count` int(11) DEFAULT NULL,
`req_per_sec` float DEFAULT NULL,
`req_time_total` float DEFAULT NULL,
`req_time_percent` float DEFAULT NULL,
`req_time_per_sec` float DEFAULT NULL,
`ru_utime_total` float DEFAULT NULL,
`ru_utime_percent` float DEFAULT NULL,
`ru_utime_per_sec` float DEFAULT NULL,
`ru_stime_total` float DEFAULT NULL,
`ru_stime_percent` float DEFAULT NULL,
`ru_stime_per_sec` float DEFAULT NULL,
`traffic_total` float DEFAULT NULL,
`traffic_percent` float DEFAULT NULL,
`traffic_per_sec` float DEFAULT NULL,
`memory_footprint_total` float DEFAULT NULL,
`memory_footprint_percent` float DEFAULT NULL,
`req_time_median` float DEFAULT NULL,
`index_value` varchar(256) DEFAULT NULL,
`p95` float DEFAULT NULL,
`p99` float DEFAULT NULL
) ENGINE=PINBA DEFAULT CHARSET=latin1 COMMENT='rtag_info:geo:tag.img_size=top:95,99'


(да в последнем отчёте мы агрегируем по тегу geo и фильтруем по тегу img_size).



В конфигурационных файлах nginx устанавливаем нужные теги:



location ~ '.....' {
...
pinba_tag fit_size '500x500';
pinba_tag is_fit 1;
pinba_tag img_size '920';


– и в итоге можем получить вот такие графики хитрейта:





Мы плавно перешли к примерам использования. Я не буду заострять внимание на достаточно тривиальных примерах – просто перечислю некоторые основные вещи, которые мы мониторим с помощью Pinba:




  • количество и время запросов на PHP-кластеры;

  • потребление памяти PHP-скриптами;

  • время запроса ко всем внешним сервисам (демоны на C, Go, Memcached, MySQL и т. п.);

  • с помощью nginx-плагина мониторим количество запросов в секунду и время каждого запроса к nginx с разбиением по статус ответа;

  • и другие.



Мониторинг очередей



Практически в каждом более-менее серьёзном проекте рано или поздно возникает задача обработки очереди событий. Определённые действия пользователя на сайте инициируют отправку события, на которое может быть подписано несколько обработчиков, и для каждого из них есть своя очередь. У нас этот процесс разделён на три части:




  • транспорт – события со всех хостов собираются и отправляются на машину, где работает скрипт-клонировщик, который клонирует события в очередь для каждого подписчика;

  • очередь: событие лежит в очереди (мы для очередей используем как MySQL, так и другие брокеры, например, Darner);

  • процессинг: событие дошло до подписчика и начинает обрабатываться.



В какой-то момент нам захотелось измерить, сколько времени проходит с момента генерации события до его обработки. Проблема в том, что это уже не какой-то один PHP-скрипт, а несколько различных скриптов (в общем случае даже не PHP): в одном событие бросается, в другом – происходит отправка события в очередь обработчику, наконец, сам скрипт-обработчик, который получает событие из очереди. Как же быть? На самом деле, всё очень просто. В момент генерации события мы фиксируем время и записываем его в данные события и далее на каждом этапе запоминаем разницу между временем отправки и текущим временем. В итоге в самом конце, когда событие обработано, у нас есть все нужные значения таймеров, которые мы отправляем в Pinba. В результате мы можем сделать вот такой отчёт:



CREATE TABLE `tag_info_measure_cpq_consumer` (
`type` varchar(64) DEFAULT NULL,
`consumer` varchar(64) DEFAULT NULL,
`timer` varchar(64) DEFAULT NULL,
....
) ENGINE=PINBA DEFAULT CHARSET=latin1 COMMENT='tagN_info:type,consumer,timer'


где timer – это название таймера для определённого этапа обработки события, consumer – название подписчика, type – в нашем случае это тип отправки события (внутри одной площадки или межплощадочный (у нас две площадки с одинаковой инфраструктурой – в Европе и в США, и события могут отправляться с площадки на площадку).



С помощью этого отчёта мы получили вот такие графики:





В этом примере рассматривается событие обновления данных о координатах пользователя. Как видно, весь процесс занимает меньше пяти секунд. Это значит, что, когда вы пришли в любимый бар, открыли приложение Badoo и попробовали найти пользователей рядом, вам действительно покажут тех, кто сейчас находится в этом месте, а не в том, где вы были полчаса назад (естественно, если ваше мобильное устройство отправляет данные о вашем местоположении).



Такой принцип (собрать все таймеры, а потом отправить их в Pinba) используется в Jinba. Jinba – это наш проект для измерения производительности клиентской части, в основе которого лежит Pinba; расшифровывается как JavaScript is not a bottleneck anymore. Подробнее о Jinba можно узнать из доклада Павла Довбуша и на сайте проекта.



Мы собираем все таймеры на клиенте и потом одним запросом отправляем их на PHP-скрипт, который уже отсылает всё в Pinba. Помимо стандартных типов отчётов, в Jinba мы активно используем гистограммы. Я не буду подробно рассказывать про них – скажу только, что благодаря функционалу гистограмм мы имеем возможность в отчётах указывать перцентили.



По умолчанию Pinba делит весь временной интервал, в который попадали запросы, на 512 сегментов, и в гистограмме мы сохраняем количество запросов, попавших в тот или иной сегмент. Я уже говорил, что мы измеряем время работы PHP-скриптов, время ответа nginx, время обращения к внешним сервисам и т. п. Но какое время мы измеряем? Например, в секунду было 1000 запросов на какой-то скрипт, соответственно, мы имеем 1000 различных значений. Какое из них нужно отобразить на графике? Большинство скажут: «Среднее арифметическое», – кто-то скажет, что нужно смотреть, сколько выполняются самые медленные запросы. Оставим этот вопрос за рамками этого поста. Для тех, кто не знает, что такое перцентиль, приведу простейший пример: 50-й перцентиль (или медиана) – это такое значение, когда 50% запросов выполняются за время, не превышающее данное значение.





Мы всегда измеряем среднее арифметическое и старшие перцентили: 95-й, 99-й и даже 100-й (самое высокое время выполнения запроса). Почему нам так важны старшие перцентили? Вот пример графика с ответами одного из наших внешних сервисов:





Из рисунка видно, что и среднее арифметическое, и медиана (50-й перцентиль) примерно в два раза меньше, чем 95-й перцентиль. То есть, когда вы будете делать отчёт для руководства или выступать на конференции, то выгодно будет показать именно это время запроса, но если хочется сделать пользователей счастливее, то правильнее будет обратить внимание на 5% медленных запросов. Бывают случаи, когда значение 95-го перцентиля почти на порядок превышает среднее, а это значит, что где-то есть проблема, которую нужно найти и устранить.



MySQL is not a bottleneck anymore



Поскольку мы мониторим запросы ко всем внешним сервисам, то, естественно, мы не можем обойти стороной запросы к базе данных. Мы в Badoo используем MySQL. Когда у нас возникла задача её мониторинга, сначала мы решили использовать Slowlog + Zabbix. Но это оказалось очень неудобно. Slowlog может быть очень большой, и зачастую найти в нём причину возникшей проблемы довольно сложно, особенно когда это нужно сделать быстро. Поэтому мы стали рассматривать коммерческие решения.



На первый взгляд, всё было прекрасно, но смущало то, что триальная версия работала только на ограниченном количестве серверов (на порядок меньшем, чем у нас на одной площадке), и был риск, что на всём кластере решение может на заработать.



Одновременно с тестированием коммерческого решения наши DBA (кстати, у нас их всего два: основной и резервный, или мастер и слейв) сделали собственную разработку. Они использовали performance_schema, скрипты на Python, всё это отправляли в Elastic, а для отчётов использовали Kibana. И, как ни странно, всё работало, но, чтобы сделать мониторинг всего нашего кластера MySQL, потребовался бы сравнимый по мощности кластер Elasticsearch.



К сожалению, даже в Badoo нельзя по щелчку пальцев получить сотню лишних машин для кластера. И тут мы вспомнили про Pinba. Но возник следующий нюанс: как в Pinba сохранять информацию об SQL-запросе? Более того, нужно сохранять информацию не о конкретном запросе, а о «шаблоне» запроса, то есть, если у вас есть 1000 запросов вида Select * from table where field = field_value, и в каждом из них значение поля field_value разное, то нужно в Pinba сохранять данные о шаблоне Select * from table where field = #placeholder#. Для этого мы провели рефакторинг всего кода и везде, где в SQL прямо в коде подставлялись значения полей, мы проставили плейсхолдеры. Но всё равно шаблон запроса может быть слишком большой, поэтому от каждого шаблона мы берём хеш и именно его значение идёт в Pinba. Соответственно, в отдельной таблице мы храним связки «хеш – текст шаблона». В Pinba был создан вот такой отчёт:



CREATE TABLE `minba_query_details` (
`tag_value` varchar(64) DEFAULT NULL,
...
`p95` float DEFAULT NULL,
`p99` float DEFAULT NULL
) ENGINE=PINBA DEFAULT CHARSET=latin1
COMMENT='tag_info:query::95,99'


В PHP-коде мы формируем для каждого запроса такой массив тегов:



$tags = [
‘query’ => $query_hash,
‘dest_host’ => ‘dbs1.mlan’,
‘src_host’ => ‘www1.mlan’,
‘dest_cluster’ => ‘dbs.mlan’,
‘sql_op’ => ‘select’,
‘script_name’ => ‘demoScript.php’,
];


Естественно, в коде должно быть одно место, где выполняется запрос к БД, некий класс-обёртка; напрямую вызывать методы mysql_query или mysqli_query, конечно, нельзя.



В том месте, где выполняется запрос, мы считаем время запроса и отправляем данные в Pinba.



$config = [‘host’ => ‘pinbamysql.mlan’, ‘pinba_port’ => 30002];
$PinbaClient = new \PinbaClient($config);
$timer_value = /*Execute query and get execution time */
$PinbaClient->addTimer($tags, $timer_value);
/* Some logic */
$PinbaClient->send();


Обратите внимание на использование класса \PinbaClient. Если вы собрали PHP с поддержкой Pinba, то у вас будет этот класс «из коробки» (если используется не PHP, то для других языков есть свои аналоги этого класса). Понятно, что запросов к БД будет очень много, и писать в тот же сервер Pinba, куда собирается статистика по скриптам, не получится. Хомячка разорвет. В настройках php.ini можно указать только один хост Pinba, куда будут отправляться данные по завершении работы скрипта. И тут нам на помощь и приходит класс \PinbaClient. Он позволяет указать произвольный хост с Pinba и отправлять туда значения таймеров. Кстати, для мониторинга очередей у нас тоже используется отдельный сервер Pinba. Поскольку данные в Pinba хранятся ограниченное количество времени, то и в таблице со связкой «хеш – SQL-шаблон» хранятся лишь актуальные хеши.



Запросов действительно много, поэтому мы решили отправлять в Pinba каждый второй. Это примерно сто пятьдесят тысяч запросов в секунду. И всё работает. В любой момент мы можем посмотреть, какие запросы на каких хостах тормозят, какие запросы появились, каких запросов выполняется очень много. И эти отчёты доступны каждому сотруднику.



Ещё один нетривиальный кейс использования Pinba – мониторинг хитрейта мемкеша. На каждой площадке у нас есть кластер машин с Memcached, и необходимо было понять, эффективно ли мы используем мемкеш. Проблема в том, что у нас очень много различных ключей, и объём данных для каждого из них варьируется от нескольких байт до сотен килобайт. Мемкеш разбивает всю предоставленную ему память на страницы, которые затем распределяются по слабам (slabs). Слаб – это фиксированный объём памяти, выделяемый под один ключ. Например, третий слаб имеет размер 152 байта, а четвёртый – 192 байта. Это значит, что все ключи с данными от 152 до 192 байт будут лежать в четвёртом слабе. Под каждый слаб выделяется определённое количество страниц, каждая делится на кусочки (chunks), равные размеру слаба. Соответственно, может возникнуть ситуация, когда некоторым слабам выделяется больше страниц, чем нужно, и хитрейт по этим ключам достаточно высокий, а по другим ключам хитрейт может быть очень низкий, при этом у мемкеша достаточно свободной памяти. Чтобы этого не произошло, нужно перераспределять страницы между слабами. Соответственно, нам нужно знать хитрейт каждого ключа в данный момент времени, и для этого мы тоже используем Pinba.



В данном случае мы поступили аналогично мониторингу запросов к MySQL – сделали рефакторинг и привели все ключи к виду “key_family”:%s_%s, то есть выделили неизменяемую часть (семейство ключа) и отделили её двоеточием от изменяемых частей, например, messages_cnt:13589 (количество сообщений у пользователя с идентификатором 13589) или personal_messages_cnt:13589_4569 (количество сообщений от пользователя 13589 пользователю 4569).



В том месте, где происходит чтение данных по ключу, мы формируем следующий массив тегов:



$tags = [
‘key’ =>’uc’,
‘cluster’ => ‘wwwbma’,
‘hit’ => 1,
‘mchost’ => ‘memcache1.mlan’,
‘cmd’ => ‘get’,
];


где key – семейство ключа, cluster – кластер машин, с которого идёт запрос в мемкеш, hit – есть данные в кеше или нет, mchost – хост с мемкешем, cmd – команда, отправляемая в мемкеш.



А в Pinba создан вот такой отчёт:



tag_info_key_hit_mchost | CREATE TABLE `tag_info_key_hit_mchost` (
`key` varchar(190) DEFAULT NULL,
`hit` tinyint(1) DEFAULT NULL,
`mchost` varchar(40) DEFAULT NULL,
...
) ENGINE=PINBA DEFAULT CHARSET=latin1
COMMENT='tagN_info:key,hit,mchost',


благодаря которому мы смогли построить вот такие графики:





По аналогии с мониторингом MySQL под эти отчёты используется отдельный Pinba.



Шардинг



C ростом количества пользователей и развитием функционала мы столкнулись с ситуацией, когда на самом высоконагруженном PHP-кластере, куда приходят запросы с мобильных устройств, Pinba перестала справляться. Решение мы нашли очень простое – поднять несколько сервисов Pinba и «раунд робином» отправлять данные в произвольный. Сложность тут одна – как потом собирать данные? При сборе данных мы создали для каждого типа поля своё правило «слияния». Например, количество запросов суммируются, а для значений перцентилей всегда берётся максимальное и т. п.



Резюме



Во-первых, помните, что Pinba – это не хранилище данных. Pinba вообще не про хранение, а про агрегации, поэтому в большинстве случаев достаточно выбрать нужный тип отчёта, указать набор перцентилей – и вы получите нужную выборку в режиме реального времени.



Во-вторых, не используйте без необходимости таблицы с «сырыми» данными, даже если у вас всё работает и ничего не тормозит.



В-третьих, не бойтесь экспериментировать. Как показывает практика, с помощью Pinba можно решать широкий круг задач.



P. S. В следующий раз я постараюсь рассказать вам о граблях, на которые мы наступали во время работы с Pinba, и о том, какие проблемы могут возникнуть. И на этот раз я не ограничусь примерами из PHP.


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/331866/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
ОНФ_Камчатки

Активисты ОНФ проверили организацию отдыха детей в загородных лагерях Камчатки

Среда, 29 Июня 2017 г. 00:46 (ссылка)

IMG_2870м (400x300, 91Kb)


Активисты регионального отделения Общероссийского народного фронта в Камчатском крае проверили организацию отдыха детей в загородных здравницах «Волна», «Восход» и оздоровительном лагере имени Ю.А. Гагарина. В каждом из них общественники отметили наличие особой атмосферы.



«Это атмосфера праздника, творческого поиска, открытия. Сохранение лучших традиций детского коллективного отдыха – это большой труд. Хочется отдать должное коллективам здравниц, которые поддерживают характер этих мест и создают достойные условия для пребывания школьников. Но надо признать, что в условиях ветшающей лагерной недвижимости делать это с каждым годом становится все труднее», – сказала руководитель региональной рабочей группы ОНФ «Образование и культура как основы национальной идентичности», педагог Марина Лысенко.



По мнению представителя ОНФ, меньше всего изменений за последние два года претерпела инфраструктура детского оздоровительного лагеря «Восход». «Волна» и лагерь имени Гагарина заметно преобразились. Меньше всего замечаний у общественников возникло к «Волне», получившей критику ОНФ по итогам мониторинга годичной давности. Забор по периметру лагеря, представляющий опасность для детей, отремонтирован. Старое игровое оборудование, не отвечающее современным требованиям безопасности, демонтировано. К содержанию территории сделаны минимальные замечания.



«Хотелось бы, чтобы администрация лагеря все-таки обратила внимание на лестницу, ведущую к бассейну, снабдив ее дополнительными поручнями для низкорослых ребят. Этот недостаток за время, прошедшее между мониторингами, так и не устранили», – отметила Лысенко.



В «Восходе» одной из наболевших проблем является наружное ограждение, которое ремонтом и усилением подпорками уже не исправить. Общественники отметили наличие на территории потенциально опасного устаревшего игрового оборудования. И хотя представитель руководства учреждения заверила, что дети к нему не допускаются, активисты ОНФ не исключили возможности контакта и рекомендовали произвести демонтаж.



Глобальные изменения за последний год произошли в детском оздоровительном лагере имени Ю.А. Гагарина, где заново возведены здание для кружковой работы с двумя бассейнами, футбольное поле, волейбольная и баскетбольная площадки. Однако ситуация омрачается тем, что лагерь пребывает в состоянии неоконченного строительства. Возведение двух новых корпусов на его территории заморожено в июне 2016 г. Директор лагеря Сергей Клименов, наблюдая появление признаков разрушения остовов зданий, считает, что дальнейшее промедление будет стоить потерей уже потраченных средств. Он уверен, что если в этом году не продолжить строительство, то в следующем году нужно будет искать деньги на снос. Затянувшаяся стройка не дает решать вопросы благоустройства территории, в частности, восстановления асфальтовых дорожек, состояние которых, так же, как и в «Восходе», неудовлетворительно.



Условия доступности для детей с ограниченными возможностями здоровья в старом лагерном фонде отсутствуют или усугубляются его ветхостью. В новых и возводимых сооружениях потребности инвалидов учитываются: объекты оборудуются пандусами и иными вспомогательными устройствами. Замечаний к организации медицинского обслуживания и оснащению медицинских кабинетов у активистов ОНФ не было.



Представитель Народного фронта подчеркнула, что состояние и настроение детей, с которыми довелось пообщаться в ходе проверки, не вызвало сомнений в том, что их время организовано разнообразно и увлекательно. «Дети довольны созданными условиями, глаза у них горят. Мы не услышали ни одного негативного отзыва», – сообщила Лысенко.




Выводы экспертов ОНФ, сделанные по итогам мониторинга, будут направлены в профильное ведомство для принятия соответствующих мер.




 Общероссийский народный фронт (ОНФ) – движение единомышленников, коалиция общественных сил, созданная в мае 2011 года. Лидером движения является президент РФ Владимир Путин. Региональные отделения Народного фронта работают во всех 85 регионах страны. Главные задачи ОНФ – повышение качества жизни граждан, контроль за исполнением «майских указов» и поручений главы государства, а также борьба с коррупцией и расточительством, неэффективными тратами государственных средств.



1.
IMG_2841 (600x450, 426Kb)

2.
IMG_2847 (600x450, 466Kb)

3.
IMG_2852 (600x450, 237Kb)

4.
IMG_2863 (600x450, 268Kb)

5.
IMG_2867 (600x450, 368Kb)

6.
IMG_2894 (600x450, 377Kb)

7.
IMG_2926 (600x450, 415Kb)

8.
IMG_2956 (600x450, 404Kb)

9.
IMG_2998 (600x450, 328Kb)

10.
IMG_3009 (600x450, 340Kb)

11.
IMG_3030 (600x450, 222Kb)

12.
IMG_3065 (600x450, 365Kb)
Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Мониторинг задержек системы с помощью JHiccup

Вторник, 27 Июня 2017 г. 16:05 (ссылка)



О JHiccup



JHiccup это простая программа, которая позволяет измерить задержки операционной системы с точки зрения конечного приложения. Она была написана CTO компании Azul — Гилом Тени для измерения задержек ОС.





Почему задержки так важны



Мы в живем во времена сетевых приложений. Большинство программ запущенных на нашем компьютере регулярно ходят в интернет. Если мы запустим браузер и откроем google.com, то произойдет 50–60 запросов.





Для открытия google.com произошло 56 запросов



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



Рассмотрев пример с сайтами, мы можем легко провести аналогию с клиент-серверным приложение или популярными микро-сервисами. Если в цепочке вызова микро-сервисом один из микро-сервисов вернет ответ позже обычного, то это может затормозить всю логику. Например, медленный ответ о цене продукта из БД может замедлить весь процесс покупки в интернет магазине.



Поэтому когда мы говорим о производительности и задержках программы, важен не только лучший и средний результат, но и худшие результаты.



Зачем нужен мониторинг ОС



Часто разработчикам поступают жалобы от клиентов или других систем о том, что приложение обрабатывало запрос слишком долго. К сожалению, такую проблему бывает трудно воспроизвести локально или даже заметить в реальном окружении.



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



Большинство ос не являются операционными системами реального времени. А значит они не могут давать гарантии на определенное время выполнение операций. Значит производительность программ, запущенный на таких ос, может сильно отличаться в течение времени работы программы. Попросту говоря, программа может даже не получать процессорное время в какой-то момент. И тогда абсолютно не важно какой код выполняется в программе.



Вот несколько причин почему программа может “спать” не имея возможности выполнять полезные действия:




  • ОС может выполнять внутреннюю сборку мусора;

  • Другое ресурсоемкое приложение может использовать CPU или другие ресурсы;

  • ОС может выполняться поверх гипервизора и не зная об этом быть не единственной ос запущенной на этом железе.



Почему jHiccup?



Существует множество утилит и метрик, позволяющих увидеть загруженность разных компонентов системы с разной степенью детализации. Проблема в том, что таких метрик очень много и для каждой программисту нужно ответить на два вопроса:




  • Может ли эта метрика быть причиной задержки?

  • Является ли конкретное значение этой метрики аномальным?



jHiccup позволяет посмотреть на систему с точки зрения приложения. jHiccup это маленькое приложение с простой функцией : бесконечный поток засыпает и просит ос разбудить его через определенный период, например 1 секунду. Если ос была занят через 1 секунду и не смогла разбудить поток, то приложение это увидит сравнив время пробуждения с расчетным временем пробуждения (время засыпания + 1 сек). Мы можем построить график, где мы увидем задержки системы в течение выполнения программы.





На оси X время выполнения программы в секундах. На оси Y задержка пробуждения в миллисекундах (то сколько программа ждала, когда ОС даст ей возможность выполняться)



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



На предыдущем графике мы рассмотрели задержки относительно времени выполнения программы. Кроме этого бывает удобно взять все задержки и отсортировать по возрастанию. Это даст нам представление о распределении задержек и их вероятности.





Задержка в миллисекундах на оси y и ее вероятность на оси x



Некоторые особенности JHiccup:




  • не страдает проблемой Coordinate Omission хорошо описанной Гилом Тене в его видео



Внутри jHiccup использует гисторгамму как структуру данных. Обычная гисторамма разбивает весь интервал задержек (например от 1мс до 1 сек) на отрезки и подсчитывает сколько задержек попало в определенный интервал. Это позволяет представить данные о задержках в более компактном виде, чем просто список наблюдаемых значений (1.55мс, 2.6мс и тд). 



На самом деле в jHicuup используется специальная имплементация гистограммы — HDR-Histogram, которая обладает следующими свойствами:




  • Гистограммы имеют высокое разрешение. Мы можем видеть не только 95% и 99% худших результатов, но и намного более подробные данные ( 99.999%).

  • Хранит данные в компактном виде, что позволяет измерять производительность в течение долгого времени. Для этого размер сегмента гистограммы увеличивается экспоненциально. Благодаря этому получается более компактно хранить аномальные значения.



Библиотека HDR-Histogram получило широкое распространение. Можно найти имплементации на разных языках. Разные системы для сбора метрик стали поддерживать hdr-historgram как один из внутренних форматов, благодаря ее компактности и точности.



Зачем такая точность?



На графиках выше мы видели данные о 99.9999% случае. У многих возникает вопрос, нужна ли такая точность и надо ли рассматривать данные дальше 95% или 99% персентиля. Давайте рассмотрим два примера. В обоих примерах мы возьмем вероятность аномальной задержки P(A) как 5% и 1% соответственно. Нам надо ответь на вопрос, какова вероятность того, что пользователь увидит аномальный запрос P(B):




  • Мы видели что google.com делает около 60 запросов. Для примера рассмотрим сайт онлайн-магазина где для покупки необходимо выполнить 200 запросов. В случае P(A)=5%, P(B)=1–(0.95 в степени 200)=99.997%. В случае P(A)=1%, P(B)=1-(0.99 в степени 200)=86.6%

  • Пусть у нас есть 10 микро-сервисов. И каждый вызывается дважды во время выполнения определенного сценария, то есть происходит 20 вызовов. В случае P(A)=5%, P(B)=1–(0.95 в степени 20)=64.15%. В случае P(A)=1%, P(B)=1-(0.99 в степени 20)=18.2%.



Как мы видим, рассматривать данные только до 95-ого или 99-ого персентеля недостаточно.



Пример использования jHiccup



Скачать jhiccup можно с http://www.azul.com/downloads/jhiccup/ или https://github.com/giltene/jHiccup.



./jHiccup -d 4000 /usr/bin/java org.jhiccup.Idle -t 300000 
# первые 4 секунды старта не буду записаны, всего будет записано 300 секунд. По умолчанию поток будет просыпаться каждые 5 секунд (настраивается с помощью параметра -i).
# создан hiccup.170617.1120.3461.hlog
./jHiccupLogProcessor -i hiccup.170617.1120.3461.hlog -o hiccup.170617.1120.3461
# создан hiccup.170617.1120.3461 и hiccup.170617.1120.3461.hgrm


Файл hiccup.170617.1120.3461 можно просмотреть с помощью excel-файла jHiccupPlotter.xls.







Для просмотра hiccup.170617.1120.3461.hgrm можно воспользоваться онлайн приложением https://hdrhistogram.github.io/HdrHistogram/plotFiles.html. Оно также удобно для сравнения нескольких hdrm файлов (например, во время разной загрузки системы или с разных серверов).





Сравнивая график производительности нашей программы (например, задержки http-ответов) с полученной hdr-диаграммой, мы можем понять работала ли вся система медленно в определенный период или только наша программа.



Мы запускали jhiccup как отдельный процесс. Другой способ это запуск javaagent-а вместе с нашей программой.



java -javaagent:jHiccup.jar="-d 0 -i 1000 -l hiccuplog -c" MyProgram.jar -a -b -c


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



В этих двух способах запуска есть одно важное различие. В первом случае jHiccup запускается на отдельной JVM в другом на той же JVM. То есть во втором случае мы увидим задержки связанные с работой JVM (например паузы GC), на которой запущено основное приложение.



В файле jHiccupPlotter.xls есть возможность добавить линии SLA на график.





Я вижу два удобных применения для SLA:






    jHiccup удобная утилита для мониторинга задержек системы. В отличии от системных метрик, jHiccup позволяет взглянуть на загрузку системы с точки зрения приложения.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/331436/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<мониторинг - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda