Как стать автором
Обновить

Комментарии 24

Статью однозначно в закладки. Это лучшее что было написано про мониторинг с 2008 года. Один только вопрос, как донести эту мысль до руководства.
Донести будет сложно и организовать это все будет еще сложнее. Очень много вовлеченных сторон получается.
Посмотрите/почитайте тогда и вот это :-) Акцент в докладе на Kubernetes, но он и про мониторинг вообще.

Огромное спасибо. Теперь будет куда посылать особо одарённых.

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
У нас в компании полно SRE. Они следят за сервисами, да. Иногда что-то докручивают в мониторинге и других местах.

Но настройка мониторинга у нового сервиса — не их задача. Ибо только разработчики знают что, где и как у них может отказать. Знают не всегда, но так, приблизительно. А вот когда узнают точно и пропишут правила реагирования на те или иные типовые проблемы, отловленные мониторингом — можно передавать сервис SRE и отключать «пейджер» (когда-то давно это реально был пейджер, сейчас, конечно, сотовый… но носит его, поначалу, разраб — и передать SRE его можно, в частности, когда есть адекватный работающий мониторинг).

А не так: мы тут наваяли бог-знает-что, кинули SRE — а они пусть расхлёбывают. Так это не работает.
Отличная статья! Нужно сохранить в избранное и всякий раз давать ссылку, когда тебе говорят — «мы не понимаем чем ты занимаешься, серверов же стало меньше, 25 до 22».

Существует множество промышленных/ентерпрайз решений по мониторингу, что называется full stack monitoring — от точек входа пользователей, мониторинга мобильных приложений, до уровня приложения и инфраструктуры, APM, автоматический трейсинг, API-тесты, синтетика, бизнес метрики, алертинг. Все в одном флаконе. Да, это стоит денег. Но часто это дешевле чем выделять одного-двух админов допиливать open source и ещё тратить 30% времени всех разработчиков.

Вот именно про это автор и говорит, что остались ещё люди, которые верят в то, что есть в мире где-то продукт, пусть за много денег, но есть, который каким-то магическим образом внедрит трейсы в мой легаси, распарсит мой plain text stdout и надёргает оттуда логи, найдет точки входа пользователей, напишет тесты моего не документированного api, соберёт бизнес метрики, которые бизнес уже пол года пытается сформулировать и никак не может и т.д. Чуда нет, любой энтерпайз продукт будет ещё как-то неплохо смотреться, если у вас всё в стеке от одного вендора и мониторинг берёте у него же, но у нас тут вроде 2019й, микросервисы, open source, а всё написано на новом PyGoRustElixir++
Проблемы как раз с легаси, а с мониторингом и трейсингом того, что написано и запущено в 2019 как раз все хорошо и из коробки. Автоматический трейсинг в разнородной мирокросервисной среде прекрасно работает. Просто многим выгодно нанимать людей и заставлять их пилить вручную свой велосипед, а не покупать готовое, по разным причинам. Но это вопрос приоритетов и вкуса, с технологической стороны ограничений гораздо меньше.
Всё это работает только в том случае, если у вас типовой софт в типовой конфигурации. А в этом случае, в общем-то, не очень понятно — зачем вам нужны разработчики, мониторинг и всё вот это вот. Заключите договор с фирмой, которая «сделает вам красиво», увольте всех разработчиков нафиг — и получите нехилую экономию.

А вот если у вас задачи несколько отлчиаются от типовых и разработчики вам, всё-таки нужны — тогда и и придётся отдуваться за то, что они сотворили. Ибо никакое «промышленное решение» не способно справится с неограниченным полётом мысли разработчика…
Ответ был сюда
Какое-то противоречивое чувство от статьи. Вроде вначале говорите, что мониторинга не бывает, а потом даете правильные советы как его организовать.

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

Тут я хвастаюсь
Я организовал и поддерживаю весь мониторинг в одной конторке один. Чтобы представить масштабы приведу пример на банковской сфере. Допустим наше приложение это банковский фронтенд. У нас больше 2000 крупных отделений банка и несколько сотен тысяч сотрудников. Кроме того пара сравнимых по масштабу сайтов и 3 мобильных приложения.
Кроме мониторинга бизнес показателей, интеграций, апи, кластера, логов, ошибок, кучи баз, всяких кафок и рэббитэмкю, эластиксерчей и прочего что вы можете придумать, создания алертов и красивых графиков, разруливания инцидентов, дежурства 24/7 на пейджердюти одному, я ищу баги на проде, расследую баги от бизнеса и конечных пользователей, фикшу баги, пилю фичи в десятке репозиториев, делаю репорты из десятка БД и бигквери для бизнеса, фикшу данные в прод базах в случае косяков.
Причем приложения (микросервисы) находятся постоянно в состоянии переписывания и миграции с одной бд на другую.
А весь секрет в том, что все в облаке под управлением кубернетеса, приложение отказоустойчивое, настроен CI/CD, мониторинг простой, логирование полное и одинаковое везде. Ну и наверное, стоит отметить менеджеров от самых низких уровней до СТО, у которых есть чему поучиться.
За два года прозевал один раз, когда система с которой мы интегрировались упала, и один раз когда у нас кое-что отвалилось.
Для полноты картины неплохо было добавить Service Discovery, которая интегрируется с системой мониторинга и позволяет решить ряд задач в этом направлении.
Так а может вместо выделенного скажем админа Васи разработчики должны сами мониторить свой софт?
Админ — выделяет ресурсы и предоставляет инфраструктуру (graphite, prometheus, grafana ..)
Разрабы — конструируют себе метрики и алерты.

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

Это не «современный» мониторинг. Это любой мониторинг. Забудьте про сервера, базы данных и прочую фигню.

Посмотрите на любую сложноу хрень, не связанную с программированием. Хоть самолёт, хотя электроскутер… да хотя бы ваш дом.

Задача эксплуатационщиков — следить за параметрами и реагировать на разные «красные лампочки». Но никак не разработка этих лампочек!

И только в IT считается нормальным прикрутить электродвигатель к колесу изолентой и сказать «всё: электроскутер готов… как им управлять и как добиться того, чтобы он не развалился при наезде на кочку — админ разберётся… купит какой-нибудь руль и пару датчиков, что он — маленький, что ли».
Вы в каком-то странном мире живете, где это мониторингом админ занимается? Основная часть мониторинга это мониторинг бизнес показателей.

Ой, да повсюду в мелко-среднем бизнесе. И хорошо, если мониторинг вообще хоть какой-то есть.

Это проблема не с мониторингом =). Это глобальная проблема «эффективных менеджеров» и «тяп-ляп и в продакшн» =).

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

Так что… Жалейте денег на разработчиков мониторинга. Отдавайте эти деньги более грамотным разработчикам основного продукта и пинайте их на тему документирования кода и логики приложений (это сэкономит время, если разработчик сменится, кстати ;) ).
А нам пришлось принести жертву богу велосипедов и написать свою систему мониторинга с нуля. Главные требования — полная синхронность времени 87ми метрик и минимальное потребление ресурсов.
В результате система мониторинга занимает 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, в активном бесконечном цикле самоопроса, то есть постфактум, когда поздно что-то изменить и спасти под, бд, ноду. То есть считается, что вывод и ввод в строй одной ноды другой должно решать эти проблемы, однако из-за низкого качества выходного кода, недостатка управления и отсуствия внутренних метрик произвордительности и работоспособности проекта, вам придется иметь дель либо с полным отсуствием логов, либо с его переизбытком, и в любом случае, если проблема будет скрываться в коде, перезапуск лишь отсрочит вероятную проблему, но никак не поможет с ее решением.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий