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

я видел в гугле, но чет не прочел, а зря, видимо

Там один хоп, а значит сайт на defgw висит. Что там по L2 наверчено в промежутке, уже неважно.

У тебя там nginx-крутится или ты DNAT сделал?

тут уже был днат

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

сейчас поищу, что сделать можно с Hairpin

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

ок, спасибо

всем спасибо)

в зависимости от хостера может быть и не так

но если был nat, то смотреть действительно на нем правильно

кажется заработало, сейчас погляжу еще

да, божечки, да. Оно заработало

спасибо большое я вас люблю. Пусть у вас всех все будет хорошо

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

Привет всем! Здесь ведь можно будет задать вопрос не совсем про девопс? (замечал, что здесь могут обсуждать просто вопросы ОС и железа)
Если ближе к делу: есть железный сервер с ОС debian jessie 8.2

uname -a
Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u1 (2015-12-14) x86_64 GNU/Linux

На сервере запущено довольно много сервисов (Elasticsearch, впн, докер (storage driver - aufs) контейнеры с сервисами). Сервер жил не тужил до недавнего времени. Периодически (за 2 недели это второе падение) он стопается наглухо. Есть скриншот call trace при первом падении .
Начал разбираться, при втором падении были следующая ситуация:
- в 22:20 сервер упал (отрапортовала система мониторинга + плюс отсутствие метрик с этого периода)
- по логам сервера (syslog, kern.log) сервер еще жил до 22:32 (писались логи докера, типа kernel: docker0: port 15(veth63b10e9) entered disabled state)
- в atop последние данные только за 22:20
- по метрикам никаких аномалий нету (метрики хоста, контейнеров, эластика). Сервер выполняет чисто служебные роли (на sata-диски конечно идет высокая нагрузка на запись из-за эластика, но так уже живем несколько лет (это только при мне, а так мб и дольше))

У нас как-то относительно была похожая ситуация с другим сервером (но там вроде в консоли были другие ошибки). Обновились до stretch и уже больше месяца, тьфу-тьфу, проблем нет. Чем руководствовались, что обновление может помочь? На сервере стоял докер c aufs, хотели посмотреть что будет когда станет overlay2))
Память на том другом сервере тестили только из под ОС (но старались в момент тестов все сервисы тушить, чтобы проверить максимальное кол-во памяти) - всё было OK.

Также все сервера в md-рэйде (1), смарты дисков конечно проверяли.

Следовательно есть несколько вопросов:
- как бы далее пытались понять, что с сервером мб не так? (снять дамп ядра - у меня не хватит навыков его прочитать и понять).
Обновить-то обновим, проблема может быть уйдет, но причина так и останется неясной. Сервер длительное время работал без проблем.
- ниже есть скриншот консоли в момент ошибки. Для меня малоинформативно. Есть подозрение, что когда смотрим в консоль через ipmi, мы просто не видим части информации (экран и так маленький, и всю важная инфа вполне могла быть просто промотана). Возможно ли вывод экрана физической консоли перенаправлять куда-либо? Погуглил обзорно, но что-то ничего не нашел. Если бы было это возможно, вполне вероятно, ошибка была до этого call trace с более ясным описанием.

сам скрин ошибки в консоли:

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