Вот я пока хер знает, как им помочь

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

Нене

Это легко

через prometeus?

а по поводу мониторинга деплоев (ну когда ошибки происходят) - я пока заюзал opbeat.com, он бесплатный

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

Для логов пытаюсь fluentd + graylog2

У вас не 12factors app? В stdout же проще + ES +kibana

ну так эти стдауты собрать же надо

флюент для сборки

ну в кубернтесе это из коробки

fluentd

через prometeus?

не, банальнее все spec: template: spec: containters: - <container> lifecycle: postStart: exec: command: - /bin/bash - /app/bin/post_start_notify.sh

есть еще preStop

ну тут мы узнаем о том что под стартанул

не, банальнее все spec: template: spec: containters: - <container> lifecycle: postStart: exec: command: - /bin/bash - /app/bin/post_start_notify.sh

костыльненько

если мы разворачиваем на 10 инстансов...

> да, мне бы тоже хотелось знать когда "деплой завершился" ответ на этот вопрос

костыльненько

вариант знатоков? ;)

Прометус?) И кастомные метрики

метрики из чего?

ну например kubectl дергать и смотреть статус подов/деплоймента

я могу в прометее узнать, что running_containers_total стало +=1 за последнюю минуту

кстати, по поводу 12 факторов: а вот есть stdout/stderr, условно говоря это log.info и log.error... а если я хочу log.warn иметь и log.debug то как поступать?

но какой конкретно контейнер добавился - уже не могу

мы выплевываем json в stdout , там уже тип ошибки указывается

кибана /ES все парсит

хм ну да ок

кстати, по поводу 12 факторов: а вот есть stdout/stderr, условно говоря это log.info и log.error... а если я хочу log.warn иметь и log.debug то как поступать?

ты не должен этого хотеть ;)

самая проблема в stdout в пхп

там php-fpm к каждому сообщению добавляет ворнинг

s/в stdout//

s/в stdout//

ну была идея писать в fifo

Можно конечно писать в fifo и тейлить его в контейнере

но тогда в контейнере уже два процесса

да нет, это была шутка если из фразы "самая проблема в stdout в пхп" убрать "в stdout", то получится "самая проблема в пхп"

ну я типа под хейтера закосил

шучу-шучу

хаха-хаха...

да ладно, пэхэпэ норм, я вообще свою карьеру с битрикса начинал)

тот еще зашквар

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

ну в кубернтесе это из коробки

fluentd

лучше что?

ELK

Ну они в связке с fluentd работают

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

и собирают логи с кластера

ааа, это было ELK vs graylog2

http://kubernetes.io/docs/getting-started-guides/logging-elasticsearch/

ааа, это было ELK vs graylog2

Ну типа да)

С fluentd кстати забавно вообще было, мы добавили правило в конфиг, посылать копию всех записей в сислог на другом сервере, так у нас стали рандомом пропадать сообщения и в ELK и в сислоге, причем разные

o_O

ну и в логах пусто, я даже через strace уже процесс смотрел

никаких ошибок

отключили это - все перестало пропадать

по поводу мониторинга деплоев и кастомных метрик

программисты у меня тут ленивые, поэтому мне пришлось написать им обертку вокруг kubectl

такой недохельм

страсти какие

она обновляет версию в манифесте и пушает все в гитхаб с деплойным тегом

в итоге получается так:

кстати какую ACL используешь для программистов?

скрипт (да и деплой вообще) сейчас работает так: 1. обновление версии в манифесте 2. git commit; git tag -a; git push; git push —tags 3. kubectl apply -f <манифест> дальше скрипт умирает, а все остальное разделяется на два потока 1. квай получает хук от гитхаба и начинает билдить образ 2. кубернетес получает обновленный манифест и начинает готовить его к запуску 2.1 подготавливается новый под в состоянии pending 2.2 качается образ с квая (до усера, пока квай его не опубликует) после того, как квай собрал и опубликовал новый образ 2.3 образ скачивается на ту ноду, где под в состоянии pending 2.4 гасится один из старых подов 2.5 под, бывший в состоянии pending, получает образ и стартует 2.6 гасится второй старый под 2.7 поднимается второй новый под ... профит

кстати какую ACL используешь для программистов?

ABAC или ты о чем?

об этом

токены для аутентификации, ABAC для авторизации

"версия в манифесте" ты имеешь в виду tag?

да

и вот этот вышеописанный процесс надо как-то отмониторить

пока что в голову пришла только такая схема:

шаг 1: в скрипте куда-то высираем номер версии, которую деплоим шаг 2: в постСтарт хуке контейнера высираем туда же номер версии, которая задеплоилась цифирьки сошлись - улюлю, все хорошо цифирьки не сошлись - какое-то говно второй цифирьки нет больше н-минут - что-то с вероятностью пошло не так

но куда срать и чем ловить пока не придумал

нужен совет знатоков ;)

а почему не запустить какой-нибудь CI сервер прямо в кубике? тогда все может происходить в одном pipeline

заеб компании

все что можно вынести наружу, надо вынести наружу

поэтому никакого гитлаба, никаких CI внутре, etc

У вас не 12factors app? В stdout же проще + ES +kibana

грейлог - это тот же ES, но в более интересной обертке, чем кибана