нда. лучше и правда не знать

нда. лучше и правда не знать

ну да. поэтому надо запретить игры.

ну и gui тоже. как и wysiwyg редакторы.

ну и gui тоже. как и wysiwyg редакторы.

обсмотрятся своего гуя и идут стрелять одноклассников.

а я один раньше ничего не слышал про datasaurus ?

https://www.autodeskresearch.com/publications/samestats

очень крутое

Я пока к ним на собеседование не сходил тоже не знал

Коллеги, а кто нить придумал нормальный способ предачи информации о том что идет деплой в пром ?

хочу алерт для этого

ты хочешь метрику "идёт деплой"?

видимо да. но не понимаю как ее делать

или може пойдёт типа "деплой прошёл не больше 5 минут назад"

таймстамп деплоя например

не пойдёт?

в итоге я хочу info alert в дашборде

Кстати есть аналогичный вопрос про ребут

Как алертнуть что нода ребутнулась

Если есть только boot timestp

Кстати есть аналогичный вопрос про ребут

аптайм собирается

Если есть только boot timestp

time() - boot_timestamp < 3600 примерно

- alert: system_uptime_change_warning expr: system_uptime < 300 labels: environment: Production service: uptime severity: warning value: '{{$value}}' annotations: description: 'System reboot : {{$labels.host}} ' summary: System reboot

а вот деплой он по идее должен сам куда то написать

но куда ?

Коллеги, а кто нить придумал нормальный способ предачи информации о том что идет деплой в пром ?

в пушгейтвей можно посылать?

да хоть в пушгейтвей

а посылает кто ?

для этой задачи вроде должно норм быть

деплоилка

ну идет у тебя деплой, и в конце посылаешь

нее. я про то что кто то уже пошел таким путём? кажется оно не очень удобно

вообще по доке он ка краз предназначен для batch job

и выглядит будто это оно

зависит от твоей деплоилки всё-таки

The Pushgateway is not an event store

ты можешь в текстфайл коллектор складывать таймстамп события

ну короче несколько вариантов есть, какой хочешь такой и юзай

:)

два стула, ага

спасибо за картинку но я не понял к чему она

Jenkins и gitlab-ci почти нативно отдают метрики в пром о прогрессе и статусе деплоя

как и чем ?

Prometheus Plugin для jenkins, на выходе jenkins_builds_last_build_duration_milliseconds по {{exported_job}} - каждый проект видно когда начал собираться, сколько заняло времени и тд

понятно он хранит это у себя

если jenkins или giltab-ci в процессе отсутствуют то как ?

Было напрямую лог gcc парсил и в базу складывал, неудобно. Было артефактом призжал iso и deb - парсил статус сборки, тоже велосипед на регулярках

Логи yarn`a, pm2 - этих погромистов не догнать вообще, чем только не собирают.

но куда ?

Текстфайл коллектор?

Коллеги, а кто нить придумал нормальный способ предачи информации о том что идет деплой в пром ?

я немного кривовато, но сделал подобное через https://github.com/Yelp/elastalert (логи через fluentd коллектятся в ELK)

ну вот тоже склоняются к тому что евенты надо положить в систему работы с евентами

но очень не хочется тащить эластик

а вот деплой он по идее должен сам куда то написать

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

метрику чего

версии ?

ну можно коллектить логи тем же fluentd в syslog, и в syslog через пайпы передавать какому-нибудь go/awk'у/python/perl данные, который будет сам разруливать нотификации

elk все равно советую завести, для визуализации, у меня все никак руки не дойдут от ingress контроллера рисовать geomap что-бы показывать локации клиентов для определенных сервисов. по идеи, там делов на 40 минут

видимо да. но не понимаю как ее делать

Ну вот а сейчас как ты узнаёшь, что идёт деплой?

вижу буквы на экране которые бегут в верх.

специфика короч

я могу ансиблом в это время куда то стрельнуть.

сейчас стреляю ради сайленса в сторону alertmanager

метрику чего

Типо того, как это делают остальные приложения. Версию пихать в теги и отдавать всегда 1. Как только метрика пропадает, деплой прошел

Типо того, как это делают остальные приложения. Версию пихать в теги и отдавать всегда 1. Как только метрика пропадает, деплой прошел

версия в тегах антипаттерн.

Мм ..... А библиотека для go так делает go_info{version="go1.10.3"} 1

Более того, сам пром выдает в качестве метрики: prometheus_build_info{branch="HEAD",goversion="go1.10.3",revision="c305ffaa092e94e9d2dbbddf8226c4813b1190a0",version="2.4.2"} 1

Мне кажется, называть антипаттерном поведения прома несколько странно

у них все верно. просто они выдают версии редко

у меня версии сильно чаще. и по факту это просто sha256 коммита.

в таком ключе это становится антипаттерном

Можно приводить sha256 комита в число и его показывать?)

у меня версии сильно чаще. и по факту это просто sha256 коммита.

Коммита куда?:)

но sha256 это и есть число ?

Коммита куда?:)

whatever

Ну, технически обычно оно 16-ричное и я имел ввиду приводить к десятичному

Мне просто интересно зачем 256:)

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

дело то не в том что влезет. дело в том что их много. предлагаю эту ветку более не рассматривать. не применимо.

Ну, если коммит будет хранится в значении - все равно плохо?

идея хранить версию в самом проме годная в целом. но в моём окружении выглядит плохо

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

хм. тоже вариант.

у меня версии сильно чаще. и по факту это просто sha256 коммита.

Версия же только в одной метрике

- alert: system_uptime_change_warning expr: system_uptime < 300 labels: environment: Production service: uptime severity: warning value: '{{$value}}' annotations: description: 'System reboot : {{$labels.host}} ' summary: System reboot

этого нету в node_exporter, есть только node_boot_time_seconds

этого нету в node_exporter, есть только node_boot_time_seconds

теже яйца в профиль

ну да, я только чего-то не соображу как лучше сделать алерт, чтобы он не стрелял чаще одного раза

У нас сделано через триггеры в Z (да-да знаю), которые выводятся в графане как эвенты на графиках, есть 3 типа начало, успех и неуспех отправляются в процессе выкладки, на графиках видны разным цветом в виде отсечек, и в целом вполне информативно, видно когда начался деплой версии и когда и как(успех/неуспех) закончился.

как отправляется ? куда ?

Zabbix_sender отправляет в сторону заббикса, что поджигает соответсвующий тригер

Планировал переделать на внутренние эвенты графаны, все времени нет.

Я вот про эти эвенты(анотации в терминах графаны) http://docs.grafana.org/http_api/annotations/

да да. цель нарисовать в том числе их

но для этого нужен источник данных.

там их не очень то много.

Так шли курлом в процессе деполоя ансиблом/Jenkins/TeamCity на выбор, там теги и сообщения куда удобнее туда и пихай информацию

в графану слать ?

Ну да

а ретненшить как ?

и что под графану нормальную базу подкладывать что ли ?