Comments 24
Огромное спасибо. Теперь будет куда посылать особо одарённых.
Но настройка мониторинга у нового сервиса — не их задача. Ибо только разработчики знают что, где и как у них может отказать. Знают не всегда, но так, приблизительно. А вот когда узнают точно и пропишут правила реагирования на те или иные типовые проблемы, отловленные мониторингом — можно передавать сервис SRE и отключать «пейджер» (когда-то давно это реально был пейджер, сейчас, конечно, сотовый… но носит его, поначалу, разраб — и передать SRE его можно, в частности, когда есть адекватный работающий мониторинг).
А не так: мы тут наваяли бог-знает-что, кинули SRE — а они пусть расхлёбывают. Так это не работает.
Существует множество промышленных/ентерпрайз решений по мониторингу, что называется full stack monitoring — от точек входа пользователей, мониторинга мобильных приложений, до уровня приложения и инфраструктуры, APM, автоматический трейсинг, API-тесты, синтетика, бизнес метрики, алертинг. Все в одном флаконе. Да, это стоит денег. Но часто это дешевле чем выделять одного-двух админов допиливать open source и ещё тратить 30% времени всех разработчиков.
А вот если у вас задачи несколько отлчиаются от типовых и разработчики вам, всё-таки нужны — тогда и и придётся отдуваться за то, что они сотворили. Ибо никакое «промышленное решение» не способно справится с неограниченным полётом мысли разработчика…
Ну и следуя вашим советам даже один разработчик вполне себе может организовать и поддерживать мониторинг. Конечно если инфраструктура на ладан дышит, то ничего не выйдет.
Кроме мониторинга бизнес показателей, интеграций, апи, кластера, логов, ошибок, кучи баз, всяких кафок и рэббитэмкю, эластиксерчей и прочего что вы можете придумать, создания алертов и красивых графиков, разруливания инцидентов, дежурства 24/7 на пейджердюти одному, я ищу баги на проде, расследую баги от бизнеса и конечных пользователей, фикшу баги, пилю фичи в десятке репозиториев, делаю репорты из десятка БД и бигквери для бизнеса, фикшу данные в прод базах в случае косяков.
Причем приложения (микросервисы) находятся постоянно в состоянии переписывания и миграции с одной бд на другую.
А весь секрет в том, что все в облаке под управлением кубернетеса, приложение отказоустойчивое, настроен CI/CD, мониторинг простой, логирование полное и одинаковое везде. Ну и наверное, стоит отметить менеджеров от самых низких уровней до СТО, у которых есть чему поучиться.
За два года прозевал один раз, когда система с которой мы интегрировались упала, и один раз когда у нас кое-что отвалилось.
Админ — выделяет ресурсы и предоставляет инфраструктуру (graphite, prometheus, grafana ..)
Разрабы — конструируют себе метрики и алерты.
Так по-моему это и есть один из посылов доклада: современный мониторинг это не изолированный компонент, а неотъемлимая часть самого приложения и у разработчиков в плане должно быть заложено время на реализацию источников метрик.
Посмотрите на любую сложноу хрень, не связанную с программированием. Хоть самолёт, хотя электроскутер… да хотя бы ваш дом.
Задача эксплуатационщиков — следить за параметрами и реагировать на разные «красные лампочки». Но никак не разработка этих лампочек!
И только в IT считается нормальным прикрутить электродвигатель к колесу изолентой и сказать «всё: электроскутер готов… как им управлять и как добиться того, чтобы он не развалился при наезде на кочку — админ разберётся… купит какой-нибудь руль и пару датчиков, что он — маленький, что ли».
Помню как в институте, хоть мой профиль и не был на 100% программистским, нас учили любой код обвязывать тестирующими функциями. Ну и про документирование много рассказывали. С этими данными обвязать приложение мониторингом не титаническая задача.
Так что… Жалейте денег на разработчиков мониторинга. Отдавайте эти деньги более грамотным разработчикам основного продукта и пинайте их на тему документирования кода и логики приложений (это сэкономит время, если разработчик сменится, кстати ;) ).
В результате система мониторинга занимает 4Мб на диске. Примерно 8% ее функционала на этом видео: www.youtube.com/watch?v=uEk_kQBbdP0
А ещё я обнаружил, что существующие системы нового поколения очень хорошие конструкторы, но очень фиговые продукты. В nagios/shinken'е был миллион нюансов для скедулинга даунтаймов, операционного управления какие чеки заткнуть а какие отключить и т.д. Но при этом при написании чеков всё сводилось к унылой командной строке и всяким $HOST$, а так же полной невозможности отвязать сервис от хоста.
Новые конструкторы дали возможность описать сложное на уровне проверки, но всё последующее — просто ужас. По крайней мере нормального операционного центра (тут flexible downtime, тут у сервисов зависимость и т.д.) нового поколения (под стать Prometheus/TICK) я не видел.
Согласен с выводами автора поста. В свою очередь, я как 80% .NET Core разработчик и лишь на 20% DevOps, скажу, что в теории есть возможность интерации с системами мониторинга любого уровня, той же Grafana, как на уровне АПИ тик и на уровне игерации и предоствления внутренних счетчиков произвродительности .NET, как память, управляемая и неуправляемая кучи, статистика и внутренние пользовтельские показатели, как и с любой другой программной системой, либо собственная реализация ping/pong, и мониторинг ресурсов, если не хочется использовать интеграцию с DevOps, однако на реальных проектах, с точки зрения разработки, на это — на уровне проекта и менеджмента, — не выделяется вообще никаких ресуросов как при сборке и написании монолитных бекенд сервисов, так и микровервисов, так как подразумевается, что ранне обнаружение проблем (связи, состояния БД, сети — частично падающие пакеты, например) не нужно, другими словами, в 99.999% случаев, вам в дальнейшем придется ставить сложную, дорогую (TCO) и ненадежную систему ВНЕШНЕГО мониторинга ресурсов, не интегрированого в написанный тут же, рядом, код, то есть без пользовательских мониторинга счетчиков производительности, ОС, логов и окружения, и вам придется использовать ее, вместо того, чтобы мониторть только то, для чего изначально предназначелись — работоспособность вашего кода. Я бы с радость написал код, который поддерживает Grafana, но когда я просто в пайплайне деплоя реализовал докером и SoundCloud сервером систему мониторинга качства исходного кода (я не говорю, уж даже о продакшене), я это делал фактически за свой счет, заказчику важность этого функционала никто не обьяснил, а это начало той самой цепочки фатальных решений, принятие которых заначивается провалом проекта в целом, то есть сначала, проекто становится тяжело развивать, а уже потом — и мониторить. Изначально, по современной тенденции, проекты эволюционируют, экспоненциально, по сложности, а мониторинг производительности, как дергал htop, так и дергает, пир этом сами сервисы, VNC, сами АПИ бекенда могут работать и выдавать какую-то адекватную информацию, но без внутренней информации, доступа к внутреннему черному (уже белому) ящику, найти пирчины отказа при работе в среде окружения на реальных пользователях, так-же из тривиальной приевращается в задачу с привлечением машинного обучения и еще большей сложности проекта, вместо того, чтобы двигаться в сторону упрощения. Как-то когда-то решили, что проекты бека мониторить не нужно, просто мониторьте подсы, и будет вам щастье, с помощю встроенных средств, ну они ваи и говорят, что место закончилось, наример 500 гигов, на ноду, или что-то такое-эе невразумительное, как загрузка всех ядер на 100% каким-то процессом node.js, в активном бесконечном цикле самоопроса, то есть постфактум, когда поздно что-то изменить и спасти под, бд, ноду. То есть считается, что вывод и ввод в строй одной ноды другой должно решать эти проблемы, однако из-за низкого качества выходного кода, недостатка управления и отсуствия внутренних метрик произвордительности и работоспособности проекта, вам придется иметь дель либо с полным отсуствием логов, либо с его переизбытком, и в любом случае, если проблема будет скрываться в коде, перезапуск лишь отсрочит вероятную проблему, но никак не поможет с ее решением.
Мониторинг мёртв? — Да здравствует мониторинг