Evgeny
логи - свой костыль
Kirill
Kirill
Потстоны, началось
Alexander
@lorddaedra а как логи в сентри уходят?
если точнее, то вот через их официальный клиент https://docs.getsentry.com/hosted/clients/python/integrations/django/
Alexander
если оно сломается у 1 проекта во время какого-нибудь обновления - это не затронет другие проекты
Oleksandr
Ясно
Pavel
@lorddaedra но 504 там не увидишь же? не говоря про 499
Alexander
@lorddaedra но 504 там не увидишь же? не говоря про 499
если, к примеру, контейнер с фреймворком сдох и контейнер с nginx не может к нему подключиться - тут никак в Sentry это не зафиксируется, да
Pavel
@lorddaedra я скорее про то когда джанга отвечает как может, а nginx или вообще браузер уже устали ждать
Alexander
@lorddaedra я скорее про то когда джанга отвечает как может, а nginx или вообще браузер уже устали ждать
мне как разработчику этих проектов интересны ошибки, связанные с кодом, которые можно починить, а тут, видимо, дело немного в другом... у самого uwsgi есть свои логи, их тоже можно читать
Pavel
кажется не devops детектед
Pavel
or what
Denis
да
а можете сказать какие хосты по параметрам были, и в каком режиме использовали и скольк объектов хранили ?
Alexander
кажется не devops детектед
ну я по нужде devops :-) я занимаюсь поддержкой проектов на Django, администрирование сервера/облачка - это тоже ко мне, просто конкретно у меня проекты довольно дохлые, вот такие ситуации, когда что-то там отваливается потому что не успело вовремя выполниться - это вряд ли случится)
Alexander
я согласен с тем, что если проекты серьёзные - логи в nginx нужны)
Dan
Logan
я согласен с тем, что если проекты серьёзные - логи в nginx нужны)
логи нужны, если вам важны запросы. Если запрос ничего не стоит и потеря ни на что не влияет - лог не нужен, статистики достаточно. Лог можно включать только в тот момент, когда что-то поломалось и настало время собирать камни.
Dmitry
просто часто задачу статистики решают логами
Logan
просто часто задачу статистики решают логами
это выход на улицу через окно. Можно, но неудобно.
Pavel
@not_logan а где работаете?
Pavel
И вообще в hangops например у большинства участников хоть какое-то инфо можно посмотреть
Pavel
@count0ru а вы?
Logan
@not_logan а где работаете?
Kefir digital (реклама в интернете) + поддержка отдельных проектов. В анамнезе - WebPlus, Infobox, Korus consulting
Logan
о, мы ее использовали когда-то (evaphone, вы нас, возможно, помните). Не пошло, к сожалению, очень медленно работало
Roman
у нас докер в проде, уже года 3, до 3 лямов контейнеров в сутки
Roman
говно то еще, но работает
Alexander
главная крутость докера - это то, что если раньше в чём-то накосячил - били со всех сторон, а теперь только с одной))
Alexander
если заказчик успел заметить, что ему накосячили
Pavel
@rkononov может найдешь 10 сек ответить на мои 3 вопроса (см выше)
Alexander
можно и раньше, конечно, было использовать всякие OpenVZ и прочее - но, во-первых, управлять этим зоопарком было неудобно, а во-вторых, оверхёд больше от них
Seva
Кстати
Timur
оверхед больше?
Seva
а что за вопросы?
Pavel
1. какие storage drivers используются? в основном, судя по вашему опыту? (edited)
2. как обычно организованы контейнеры с nginx? Правильно ли, что конфиг, директория с данными, директория с логами маунтится с хоста? (edited)
т.к. кажется что перенаправление access_log в /dev/stdout должно же хреново работать под нагрузкой
3. как обычно организована сеть: bridge + проброс портов или часто хостовую сеть юзаете напрямую?
Dmitry
погодитека
опенвз контейнер
Roman
1. какие storage drivers используются? в основном, судя по вашему опыту? (edited)
devicemapper/aufs/overlayfs - у каждого свои заморочки, оппции и совместимость с облаками - например оверлей у нас на ebs на амазоне не очень работает, у aufs при удалении контейнеров тормоза, девмаппер долгое время достаточно стабильно работал, на небольших нагрузках (долгоживущие контейнеры, мало записей на диск) - все работают более менее стабильно
Seva
1. overlay 2. Не, у нас конфиги генерятся и доставляются в отдельном контейнере 3. Есть и напрямую, есть и проброс докерный, в зависимости от нагрузки
Timur
>погодитека
>опенвз контейнер
вот-вот. тот же докер, только без интерфейса. почему же больше кушает то?
Pavel
@rkononov интересует не принцип, а реальное использование — т.е. как реально у вас в проектах
Roman
2. как обычно организованы контейнеры с nginx? Правильно ли, что конфиг, директория с данными, директория с логами маунтится с хоста? (edited)
т.к. кажется что перенаправление access_log в /dev/stdout должно же хреново работать под нагрузкой
Нжинкса нет, но логи бывает маунтим на хост-ос, в качестве хоста кстати импользуем CoreOS, вообще в основном логи сразу шлем в papertrail/loggly
Roman
@tru_pablo а все от кейсов зависит
Roman
смотря для чего
Alexander
погодитека
опенвз контейнер
возможно, я ошибаюсь, но их (openvz) всегда сравнивали с xen kvm, а не с тем же docker'ом
Timur
тогда докера еще не было просто
Seva
ну кстати мы ж в амазоне пишем логи на ssd :) но вообще активно смотрим на возможность не писать на диски
Pavel
@rkononov кул! спасибо
Alexander
для меня главным фактором было то, что я не мог бы удобно управлять установкой софта в эти 20 виртуалок, а вот докер могу запросто
Timur
с этим согласен
Pavel
@ctrlok а куда писать? я думал писать это всегда диски
Logan
возможно, я ошибаюсь, но их (openvz) всегда сравнивали с xen kvm, а не с тем же docker'ом
openvz - это контейнер.
Roman
3. как обычно организована сеть: bridge + проброс портов или часто хостовую сеть юзаете напрямую?
порты бросаем, но опять же только на долгоживущих контейнерах и где нужно, в основном сеть стараемся не настраивать (bridge по дефолту) - бывают заскоки
Seva
@ctrlok а куда писать? я думал писать это всегда диски
ну в nginx раньше было можно в сислог формате по сети писать.
Pavel
@rkononov не совсем понял - как не настраивать? заскоки?
Seva
да и плагины такие есть
Pavel
@ctrlok "раньше"?
Roman
@tru_pablo без необходимости никаких портов не бросаем
Dmitry
openvz и докер похожи
Dmitry
но просто опенвз для серверов, а докер все так для апликух
Roman
заскоки - там с версии 1.5-6 вроде ввесли сеть как отдельный сервис, он бывает сбоит
Dmitry
просто нюансы
Roman
*наш кейс использования экстремальный - короткоживущие контейнеры и куча контейнеров на одной машине
Roman
а вот апишные сервера под кореось+докером живут достаточно стабильно (CoreOS+дефолтный докер, только проброшенные порты)
Timur
LXC -- недо-OpenVZ. а вот докер -- это человеческий интерфейс к нему
Seva
@tru_pablo имел ввиду уже давно
Dmitry
proxmox кстати отказался от ovz в пользу lxc
Pavel
@rkononov а что делаете то, что такие контейнеры у вас?
Seva
у тебя кстати в нике ошибка
Seva
вроде было пабло
Seva
а не пкюбло тру
Aleksandr
прикольно видеть здесь узнаваемые тайтлы компаний, земля кажется такой маленькой
Roman
@tru_pablo https://www.iron.io/platform/ironworker/ а тут я рассказывал чуть - http://ctocast.com/post/141163806538/ctocast-20-roman-kononov-ironio
Roman
кстати да докер вначале был тупо оберткой над LXC
Pavel
я не знаю, может уже было, но вот это мы — https://sdcast.ksdaemon.ru/2016/05/sdcast-43/ интервью с моим кофаундером
Denis
прям звездный чат )