И рестартует до победного то, что зависит от чего то, пока оно само не поднимется

камрады привет. вопрос - кто юзал прометей для мониторинга докера - возможно ли мониторить не сам докер контейнер, а именно апликейшин в нем, допустим который экспозит порт сервиса наружу. хотя бы на уровне - живой порт или нет. дока докера пишет что пока апликейшины нельзя мониторить, только метрики самого контейнера https://docs.docker.com/engine/admin/prometheus/ Currently, you can only monitor Docker itself. You cannot currently monitor your application using the Docker target. у меня есть десяток контейнеров рассыпаных по серверам. докер стек. каждый контрейнер экспозит в оверлейную сеть порт своего микросервиса. мне надо както мониторить - живой сервис или нет. пока не было оверлея - я забиксом проверял порты. а счас забикс не видит же - все внутри сетки оверлейной мне для начала надо просто знать - живой сервис или нет и из-за того, что этот сервис внутри оверлейно сетки докера - я не могу достучаться к нему из сети хоста.

камрады привет. вопрос - кто юзал прометей для мониторинга докера - возможно ли мониторить не сам докер контейнер, а именно апликейшин в нем, допустим который экспозит порт сервиса наружу. хотя бы на уровне - живой порт или нет. дока докера пишет что пока апликейшины нельзя мониторить, только метрики самого контейнера https://docs.docker.com/engine/admin/prometheus/ Currently, you can only monitor Docker itself. You cannot currently monitor your application using the Docker target. у меня есть десяток контейнеров рассыпаных по серверам. докер стек. каждый контрейнер экспозит в оверлейную сеть порт своего микросервиса. мне надо както мониторить - живой сервис или нет. пока не было оверлея - я забиксом проверял порты. а счас забикс не видит же - все внутри сетки оверлейной мне для начала надо просто знать - живой сервис или нет и из-за того, что этот сервис внутри оверлейно сетки докера - я не могу достучаться к нему из сети хоста.

Как вариант поставить заббикс прокси внутрь оверлейной сети

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

но как настроить этот забикс прокси сервер? ведь в забиксе это делается через веб - создать хосты, применить темплейты.

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

но как настроить этот забикс прокси сервер? ведь в забиксе это делается через веб - создать хосты, применить темплейты.

Как вариант включить автообнаружение

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

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

С Заббиксом одна проблема - он не для динамичных сред. Если контейнеры сотнями и тысячами появляются - все плохо.

С Заббиксом одна проблема - он не для динамичных сред. Если контейнеры сотнями и тысячами появляются - все плохо.

+

Заббикс из коробки умеет удалять пропавшие метрики минимум через сутки

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

то есть надо чтото добавлять по любому? в простейшем случае Прометей, что - не умеет просто прочекать живой ли порт на нужном IP или нет?

У нас иной раз сервисы в сварме по несколько раз на дню обновляются. Пробовал Заббиксом - печалька получается.

обновляются, но не новые же создаются.

то есть надо чтото добавлять по любому? в простейшем случае Прометей, что - не умеет просто прочекать живой ли порт на нужном IP или нет?

Мы простенький мониторинг на ноде накидали. Читает периодически через докер апи и пишет в статсд.

обновляются, но не новые же создаются.

Для этого и делается автообнаружение с прототипами элементов данных, триггеров

у нас фиксированное кол-во докер контейнеров и следовательно - микросервисов. воти надо просто для начала видеть - живой сервис или нет. потом уже метрики буду читать с них

Для этого и делается автообнаружение с прототипами элементов данных, триггеров

я с этой чОрной магией так и не разобрался. забил.

Мы простенький мониторинг на ноде накидали. Читает периодически через докер апи и пишет в статсд.

ничо не понял) это все еще в контексте прометея?

я с этой чОрной магией так и не разобрался. забил.

Она не такая чёрная, чуть подумать потыкать - и можно разобраться

ничо не понял) это все еще в контексте прометея?

Нет, свою скрейпилку метрик запилили. К Прометею не относится

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

Я с прометеем не работал, а на заббиксе не сложно поднять систему

Тебе надо чекать порты просто на живучесть?

да

Не сложно тогда

типа net.tcp.service[tcp,, номер порта]

забикс уже есть. просто он ослеп, так как живет на хост сети

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

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

да

лучше для сетевика observium

имхо

это чтото вроде munin

Так а не проще приложению самому отдавать метрику своего статуса, тогда все в Прометее будет

Не проще, а правильнее

Тем более если у контейнера несколько реплик, то он чекать будет каждую реплику? И что тогда считать доступность апликейшена а данном случае?

Любые метрики из вне приложения это костыль

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

Дай я тебя обниму

https://github.com/deslum/pyrabbit2

Я пока про метрики не говорю. А просто спрашиваю как Прометей может проверить доступность порта

https://github.com/prometheus/blackbox_exporter

https://www.robustperception.io/checking-if-ssh-is-responding-with-prometheus/

Я пока про метрики не говорю. А просто спрашиваю как Прометей может проверить доступность порта

Прометей сделан в первую очередь для сбора метрик, так что от них и надо плясать, есть метрика на доступность апликейшена , то Прометей проверит, сам по себе он ничего не проверяет

Кроме доступности экспортеров

Прометей сделан в первую очередь для сбора метрик, так что от них и надо плясать, есть метрика на доступность апликейшена , то Прометей проверит, сам по себе он ничего не проверяет

вот это не очень понятно. что значит "сделан для сбора метрик"? он умеет только стучаеться по http на какойто ендпоинт типа url:port/metrics ? и высасывать оттуда json с метриками?

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

label-schema.org кто-то использует? и кто в чате пользует метаданные в образах? подскажите свои кейсы плз, для саморазвития интересуюсь

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

прометей это не заббикс, он собирает метрики с экспортеров и складирует их

не не пингует, не коннектится по ssh не чекает порты

все делает экспортеры, а он только берет метрики с них

https://prometheus.io/docs/introduction/overview/

экспортеры можно писать и самому, если напишите тот который будет опрашивать порты (если такого еще нет) то он будет знать о доступности портов

но выглядеть это будет типо http_port_access=1

в виде метрики

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

/spam

Привет!Кто сможет подсказать, докер если запускаю такой командой sudo docker run -i -t -d —env-file /home/users/onlyoffice_env onlyoffice/documentserver То образ запускается в процессах висит но через 80 порт не подключается. Если делаю перенаправление на порт 8080 docker run -i -t -d -p 8080:80 onlyoffice/documentserver Тогда через браузер открывает.Если добавляю 8080

порт 80 открытый

ERROR: S client not available

так если хочешь на 80 порт повесить то и прокидывай на 80

-p 80:80

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

и?

где проброс то?

expose абсолютно ничего не значит и по нему не достучишься если не прописал. -p 80:80

expose абсолютно ничего не значит и по нему не достучишься если не прописал. -p 80:80

docker run -i -t -d -p 80:80 -v /app/onlyoffice/DocumentServer/logs:/var/log/onlyoffice -v /app/onlyoffice/DocumentServer/data:/var/www/onlyoffice/Data -v /app/onlyoffice/DocumentServer/lib:/var/lib/onlyoffice onlyoffice/documentserver Вот такой командой сделал запуск контейнера и монтированных директорий и потом для 443 docker run -i -t -d -p 443:443 -v /app/onlyoffice/DocumentServer/data:/var/www/onlyoffice/Data Доступ из браузера есть только для 443, по 80 все же не хочет С докером несколько дней разбираюсь((

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

спасибо за внятное объяснение. все же переспрошу - так вот этот самописный или уже готовый експортер для чека доступности портов - это что? отдельный агент-демон-процесс на целевой машине или конфиг файл на сервере прометея? и опять повторюсь - мне не надо по взрослому - мне надо както мониторить доступность портов на контейнерах где запущены микросервисы. они живут в оверлейной сетке докер стека - поэтому снаружи к ним доступа нет. все усложняется еще тем, что эти контейнеры не в одной реплике, а их по три штуки на сервис - то есть оно балансируется средствами докера, но мне НАДО знать о доступности КАЖДОГО. пока я использовал докер сварм и экспозил эти порты в физ сетку - я мог забиксом проверять каждый хост с этими кнтенерами и видел все что надо. а теперь на этих хостах они не висят в LISTENING на физ интерфейсе вот и ищу варианты как к ним достучаться

docker run -i -t -d -p 80:80 -v /app/onlyoffice/DocumentServer/data:/var/www/onlyoffice/Data вот так пробовал?

еще в конце естественно должно быть название имаджа

спасибо за внятное объяснение. все же переспрошу - так вот этот самописный или уже готовый експортер для чека доступности портов - это что? отдельный агент-демон-процесс на целевой машине или конфиг файл на сервере прометея? и опять повторюсь - мне не надо по взрослому - мне надо както мониторить доступность портов на контейнерах где запущены микросервисы. они живут в оверлейной сетке докер стека - поэтому снаружи к ним доступа нет. все усложняется еще тем, что эти контейнеры не в одной реплике, а их по три штуки на сервис - то есть оно балансируется средствами докера, но мне НАДО знать о доступности КАЖДОГО. пока я использовал докер сварм и экспозил эти порты в физ сетку - я мог забиксом проверять каждый хост с этими кнтенерами и видел все что надо. а теперь на этих хостах они не висят в LISTENING на физ интерфейсе вот и ищу варианты как к ним достучаться

Во первых, если у тебя правильно используется докер (1 реплика = 1 процесс/апликейшн) то доступность каждого проверять смысла нет, т.к. если реплика работает, то приложение доступно, если оно будет недоступно/крашнулось , то реплика просто падает. Соответственно проверять нужно только через балансировщик сервиса сворма, а это как раз таки лучше делать через реплики отдаваемы приложением. Экспортер это контейнер который крутится рядом с приложением и который шлет собираемые ими данные на прометеус который в свою очеред может быть вообще за пределами хоста на внешнем ip, главное что экспортер рядом со свормом Вот примеры экспортеров можно глянуть https://prometheus.io/docs/instrumenting/exporters/

docker run -i -t -d -p 80:80 -v /app/onlyoffice/DocumentServer/data:/var/www/onlyoffice/Data вот так пробовал?

пишит занят docker: Error response from daemon: driver failed programming external connectivity on endpoint gallant_mahavira (0f7ce8c3f128fc159f9424042e4d0e5cbda0d1243e5255d7b93f3832239aab12): Bind for 0.0.0.0:80 failed: port is already allocated.

я ж его перед этим заупусти

>доступность каждого проверять смысла нет, нe почему вы так решили? у меня есть смысл)

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

1 контейнер - 1 процесс, без всяких там супервизоров

пишит занят docker: Error response from daemon: driver failed programming external connectivity on endpoint gallant_mahavira (0f7ce8c3f128fc159f9424042e4d0e5cbda0d1243e5255d7b93f3832239aab12): Bind for 0.0.0.0:80 failed: port is already allocated.

зачем ты запускаешь второй контейнер?

чтобы пробросить 2 порта достаточно указать их оба в пробросах

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

не в этом МОЯ ЗАДАЧА.

>Экспортер это контейнер который крутится рядом с приложением значит если у меня десяток приложений в контейнерах на одном хосте, каждое со своим портом, то чтобы мониторить эти порты надо еще 10 контейнеров с експортерами? по одному на каждое приложение?

можно одним экспортером собирать кучу метрик

это просто промежуточное звено для доставки их в прометеус

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

сворм уже сам разрулит ситуацию по репликам за вас

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

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

но у нас есть некая специфика, долго писать. заточено все было под заббикс и счас хочется повторить.