Как работать с Prometheus в Go на примере рекламного сервера - VyacheArt
HTML-код
- Опубликовано: 26 июл 2024
- Что делать, если вы разработали микросервис на Go, нагрузили его, и обнаружили, что работает он очень медленно? Где искать причину? Как оптимизировать? На эти вопросы вам могут помочь найти ответы метрики!
В этом ролике мы возьмём за основу рекламный сервер на GoLang и покроем его метриками. А поможет нам в этом система мониторинга Prometheus.
Prometheus - система мониторинга с активным сбором данных.
Весь код в репозитории github.com/VyacheArt/simple-a...
--
VyacheArt в Telegram t.me/VyacheArt
#ityoutubersru #ityoutubers
0:00 Введение
01:08 Теория
02:06 Почему Prometheus?
03:05 Задача
03:52 Поднимаем Prometheus
06:08 Код
16:33 Визуализация
20:02 Заключение
![Cordae - Saturday Mornings (feat. Lil Wayne) [Official Music Video]](http://i.ytimg.com/vi/z2GYJua09F0/mqdefault.jpg)
Привет, большое спасибо за качественный контент!
Про графану было бы тоже интересно посмотреть
Привет, спасибо большое за отзыв! Про графану замётано, расскажу!
Очень крутое и интересное видео, спасибо! С нетерпением жду про графану)
Спасибо большущее! Про графану сделаю!
Спасибо за видео. Коммент в поддержку! Сделайте еще продолжение c Графаной!!!
Спасибо!! Уже делаю! 🙃
Спасибо большое, очень понятно + приятный голос и оформление
Спасибо! Превосходный контент и шикарные знания. Однозначно лайк и подписка.
Спасибо!
Спасибо за контент! Очень интересные и качественные видео! Конечно же ждём видос про графану)!
Спасииибо! И очень рад, что нравятся видео. Про графану будет!
Эластик не про метрики, эластик про логи. Собственно, три столпа observability: метрики, логи, профайлинг.
Видео с подачей очень хорошее, спасибо!
Спасибо большое!
И отдельное спасибо за уточнение, но, если не ошибаюсь, не совсем так: elasticsearch да, про хранение, обработку и аналитику логов. Но есть Elastic APM, который строится на базе агента-коллектора, кибаны и elasticsearch, и он вполне себе про метрики производительности. Но да, я в видео не уточнил про конкретно APM
Спасибо за видео! Интересно было бы посмотреть про SD, в частности про консул
Спасиибо! Я пока не силён в SD, но вероятно скоро поднаберусь ещё практического опыта и попробую рассказать!
Спасибо за видео, с нетерпением жду видео о Графане
Спасибо большущее! Видео с графаной уже даже в работе:)
Спасибо огромное! Очень круто, интересно и качественно!
Большущее спасибо за такие тёплые слова!
Супер! Спасибо за ваш труд. Жду уроки по графане
Спасииибо! Уже готовлю!
Лайк за светлую тему IDE
Хехе, не ожидал, что кто-то оценит)) Спасииибо!
Спасибо за видео! Хотел бы увидеть визуализацию в grafana)
Спасибо большое за коммент! Визуализацию в графане покажу, замётано!
да мы юзаем так же бакеты и каунты но не саммори) видео все актуальней становятся)
стоит сделать про графану и обязательно про дата сорс , а то как выяснилось не все девопсы в курсе как можно крутить вертеть там данными)
> а то как выяснилось не все девопсы в курсе как можно крутить вертеть там данными)
О да, мне дико заходит, что в графане можно выводить данные из того же кликхауса. И более того ставить на эти данные метрики! Обязательно расскажу об этом в ролике про графану, готовлю его как раз.
Спасибо большущее за коммент и оценку!
спасибо, очень полезно) про графану было бы классно рассказать
Спасибоо! Рад, что оказалось полезным, а про графану уже готовлю!
❤
Не ну Grafana стопудов нужна, чтоб понять как это всё красиво сделать)
p.s. монтаж шикарен (разве что в паре мест графики были перекрыты, но это несущественно), тема интересна 👍
p.p.s. между pull и push сбором метрик есть какая-то принципиальная разница или тот или иной вариант выбирают только из-за выбора конкретной тулзы?
По поводу графаны замётано, сделаю! Спасибо большое за отзыв и монтаже и теме:))
По поводу pull и push - тут тема большая, но попробую ответить. Изначально это зависит от ваших возможностей: если ваш сервис доступен снаружи, и к нему может достучаться сервер метрик, то он может работать по Pull модели. Но может быть обратная ситуация: сервис находится за NAT, и тогда возможно использовать только Push модель. Также у вас может быть короткоживущий сервис, который запускается, что-то делает, и завершается. Тогда Pull модель тоже не подойдёт, потому что большую часть времени сервис будет недоступен.
В Pull модели очень удобно то, что Вы можете настраивать сбор централизованно и в одном месте. Но когда серверов много, и они часто меняются, то каждый раз править конфиг неудобно, и было бы удобнее на стороне приложения пушить метрики.
На практике вот какие наблюдения: мы (где я работаю) очень давно используем прометеус и классическую Pull модель. Но был период, когда у нас происходил рост в несколько десятков серверов в неделю, и приходилось часто лезть в конфиг и релоадить сервер (хотя и есть всякие ансиблы). И это в целом ок, но это отдельный процесс, который отнимает время. В такой ситуации я бы предпочёл уже Push модель, когда мне вполне ок переложить на приложение ответственность за отправку метрик.
При этом мы работаем с аутсорс девопсами, которые поддерживают инфраструктуру многих компаний, и они предпочитают использовать Push модель, потому что во-первых не угадаешь есть ли у сервера вообще публичный IP адрес, а во-вторых так проще добавлять и убирать с мониторинга.
Я сейчас придерживаюсь такого принципа: по умолчанию использую Pull модель, потому что удобна централизованная настройка, а для короткоживущих сервисов Push. При этом даже необязательно менять тулзу: в prometheus можно использовать push модель через "push-gateway". Поэтому тут выбор исключительно исходя из Ваших возможностей и требований
@@VyacheArt спасибо за такой развёрнутый ответ, стало куда понятней) это реально тема для отдельного видео! Было бы круто, после графаны, увидеть и небольшое видео про выбор между pull и push и реализацию 'push модель через "push-gateway"' - был бы довольно исчерпывающий плейлист 💪
Спасибо, давай с grafana)
Спасибо! Уже работаю над ним!
Гоу урок про графану!
Уже в процессе, спасиибо!
Спасибо за урок! Пожалуйста, можно поподробнее про необходимость мультиплексора? Не очень понятна фраза "Вы можете получить на неожиданном порту свои метрики". Как такое возможно, если мы явно его прописываем?
Пожалуйста! И спасибо за коммент!!
Это я говорил про два варианта:
1. С мультиплексором, как в видео
2. С использованием `http.Handle` и `http.ListenAndServe(address, nil)`, то есть без мультиплексора
Вот во втором случае будет использоваться мультиплексор по умолчанию, который `http.DefaultServeMux`. Если в каком-то другом месте кода тоже будет `http.ListenAndServe(address2, nil)`, то оба слушателя будут идти к единственному DefaultServeMux, и на другом порту тоже будут доступны метрики.
Вот чтобы таких неожиданностей не случалось, лучше использовать явный мультиплексор. В частности в метриках.
@@VyacheArt Правильно понимаю, что если сначала инициализировать server := &http.Server{Addr: addr}, и уже у сервера использовать server.ListenAndServe(), то проблемы с глобальным мультеплексором не будет, и это тоже можно считать вариантом использования для метрик?
@@unlite2896 только сейчас заметил, что не ответил на комментарий из-за не пришедшего уведомления ютуба(
Это немного разные вещи. Мультиплексор - это по сути роутер, который матчит пришедший адрес и его обработчик (если такой есть). А http.Server - это сервер, задача которого слушать TCP порт и понимать HTTP протокол.
Если Вы явно прокинете в созданный http.Server отдельный Handler (то есть &http.Server{Addr: addr, Handler: mux}), то проблемы не будет, но это будет аналогично тому что Вы вызовете http.ListenAndServe(address, mux), потому что внутри он просто создаёт &Server{Addr: address, Handler: mux}.
А если вы сделаете просто &http.Server{Addr: addr}, то Handler будет также nil, и сработает вот это условие с использованием дефолтного мультиплексора github.com/golang/go/blob/0853f8caec60f59df234c287be7f5971ab62133f/src/net/http/server.go#L2927
нужен ролик про графану)
Будет, спасибо за фидбек!
подскажи актуальный форк bombardier, а то в главном проекте go1.15 и даже на 1.17 не ставится?
Я использую как раз github.com/codesenberg/bombardier
У него в go.mod 1.15, но это говорит о версии, на котором он разрабатывался. У гошки же обратная совместимость, поэтому на старших 1.* должно всё работать:
➜ ~ bombardier --version
bombardier version unspecified darwin/arm64
➜ ~ go version
go version go1.19.5 darwin/arm64
А какая ошибка возникает?
Привет. У меня бомбардир выдает среди прочего и значения Errors Timout. Я так понимаю это какие-то потери? Подскажи пожалуйста что это и как с этим бороться?
Как сделать такую же офигенную консольку?
Ееее, всегда мечтал чтоб кто-то заметил:)) Это оболочка oh my zsh, плагин zsh-autosuggestions, и настроенная под себя тема Powerlevel10k
есть видео по графане?
Есть, воть ruclips.net/video/1RpbstvgnVE/видео.html
Го Графану
Будет!
еще идея для видел, эврона входило видео про чистую архитектуру, мне многое показалось спорным
было бы интересно увидеть твое мнение по архитектуре приложения на гошке
ruclips.net/video/V6lQG6d5LgU/видео.html
Спасибо за идею! Попробую подумать в эту сторону