Какая-нибудь малозначимая и простая система может и остановиться. Но для отказоустойчивых систем, работающих 24/7, это недостаточная причина для полной остановки.
Так это касается не только 1С, а вообще любого консьюмера.
Вопрос был в контексте 1С, и я подумал, что ответ в этом же контексте будет смотреться органичнее. Но вы верно подметили - ответ применим не только к 1С.
Если в архитектуре используется кафка - то изначально предполагается, что сервисы умеют сами разбираться со своими проблемами.
Сервис не может предусмотреть все возможные проблемы. И не важно, кафка там у него или нет. Поэтому ошибки делятся на два типа - которые мы знаем как обработать и все остальные. С первым типом всё понятно, а вот со вторым уже не очень.
Допустим, встретилась ошибка сети. Очевидно, что коммитить оффсет нет смысла, так как все последующие сообщения так же упадут с этой же ошибкой и лучше ретраить текущее сообщение до победного, либо до изменения ошибки на какую-то другую.
А если возникла ошибка, которую никто никогда не видел? Можем ли мы блокировать чтение топика, отправив сообщение в "ретрай до победного"?
Типичным вариантом обработки всех подобных неизвестных ошибок является изъятие проблемного сообщения из топика и отправка его в отдельную независимую ретрай схему с увеличивающимся интервалом между попытками. И в системах на кафке такая схема делается либо очень сложно, либо с привлечением сторонних инструментов.
Потому что один застрявший документ остановит весь поток. Это нормально сработает только если 1С не принимает документ из-за каких-либо временных проблем: перегружена база, сеть барахлит и т.п. А если проблема перманентная, например, невалидный с точки зрения 1С документ, то на этом документе весь поток и встанет. А ретрай механизмов у кафки нет, что вынуждает городить костыли.
ASN.1 был придуман очень давно учёными для учёных. Очень сложная спецификация с большим количеством тонкостей и нюансов. Исчезающе малое количество актуальных компиляторов и рантайм библиотек. Это тем более удивительно, что очень широко используемые во всем мире структуры - SSL сертификаты для сайтов, кодируются именно в ASN.1.
С другой стороны, protobuf создан инженерами для инженеров. Простая спецификация, хорошая поддержка на всех языках программирования.
Обнаружил способ сделать значение опции более читабельным и поддерживаемым. В документации указана возможность задавать значения в одинарных кавычках и тогда оно автоматически преобразуется в двоичный формат. Если указано число или IP адрес, то они сразу же целиком переводятся в двоичный формат. При этом написано "Now it is also possible to combine data types into one", что даёт возможность писать серию десятичных чисел и IP адресов подряд друг за другом без мутотени с ручным преобразованием. Не очень понятно к какой конкретно версии ROS относится слово "now", но оно появилось в документации в районе ноября 2021 года, так что думаю речь идёт про ROS 6.49 и выше.
Пример 1 из статьи можно записать как '24''10''0''0''192.168.0.2'
Чтобы не запутаться в кавычках, напишу как оно делится: '24' + '10' + '0' + '0' + '192.168.0.2'. То есть отдельно в кавычках маска, отдельно каждый октет адреса назначения и адрес роутера целиком. Но записывать нужно без промежутков (без пробелов и т.п.).
Пример 2 - '8''10''192.168.0.2'
Пример 3 - '29''172.16.4.0''192.168.0.2'
В 3 примере автор накосячил. Либо ошибся когда копипастил, либо просто запутался в преобразованиях. Кстати, если маска адреса назначения 25 и больше, то адрес назначения можно написать не раздельно, а сразу целиком.
И как вы можете гарантировать что пароль в лог файл не утечет?
Проводить обучение разработчиков, админов и прочих причастных основам информационной безопасности, где объясняется, что логгирование пароля - плохо и чревато.
Особенно если учесть что nginx у вас может использоваться как tls terminator, а после него все на чистом http взаимодействовать …
Значит необходимо объяснить разработчику, что не стоит передавать пароль в query string, так как nginx по умолчанию записывает его в лог. Либо объяснить админу, что в nginx есть возможность логгировать урл без query string.
При передаче пароля в открытом виде есть одна проблема:
TLS достаточно надёжно защищает передаваемые данные между клиентом и сервером. Это подтверждено большим количеством исследований и проверено временем. Так что пароль передаётся в зашифрованном виде, а не в открытом.
Если приложение пишет пароль (или хеш пароля) в логи, то это почти наверняка не единственная и не самая большая проблема с таким-то подходом к безопасности.
Верно. Именно по этой причине пароль предварительно солят перед тем как прогнать его через хеш функцию. Бывает ещё и перчат.
Согласен. Но теперь вам нужно как-то защититься от слива базы, что происходит несравнимо чаще, чем перехват пароля/хеша в полёте. Будете хранить в базе хеш от хеша?
Запрещено пропускать, если есть персональная льгота на проезд. Например, инвалидность, статус почётного донора, студенческая/школьная скидка и т.п. За полный тариф и за своё счёт пропускай кого хочешь. Никто слова не скажет.
если мы обсуждаем приложение и оно не может работать без карты - карта - это костыль к приложению.
Все билеты и денежные средства от пополнений привязаны к аккаунту в транспортной системе. Физическая карта - просто ключ для доступа к билетам на аккаунте. На карте напечатан номер этого аккаунта и он же прописан в чипе. Виртуальная "карта" в приложении - тот же самый аккаунт, только без физической карты. Считайте слово "карта" синонимом слова "аккаунт" и тогда станет понятнее.
Я понимаю, вас смущает момент, что сущность "билет" не существует отдельно от сущности "аккаунт". Отдельно билет без каких-либо привязок можно купить только в кассе метро. Это будет картонка с чипом. Можно считать её лайт версией карты тройки с фиксированным количеством предоплаченных поездок.
Можно. Просто два раза прикладываете карту (транспортную, банковскую), телефон или qr-код виртуальной тройки. В первый раз проходит ребёнок, во второй раз взрослый.
Да. Есть приложение для покупки билетов. Называется "тройка".
вот это что-то более-менее похожее, но без карты "тройка" похоже что еще не научились обходиться
Собственно, мосметро и является оператором карт "тройка". Непонятно что вы имеете ввиду. Если б карта называлась "московское метро" вместо "тройка", то вопросов у вас бы не возникло?
это все воркэраунды, вопрос был про приложение для покупки билетов, без доп. костылей в виде транспортной карты
Если вы имеете ввиду билеты по типу как в теарты и музеи, когда на почту присылают PDF со штрих-кодом, то такого в метро нет. Билеты записываются на аккаунт транспортной карты и они бывают разных типов: абонементные на количество дней/поездок или же "Билет «Кошелек»" (да, это его официальное название), который просто хранилище денег, откуда списывается стоимость поездки при проходе через турникет. Туда же можно записывать билеты на пригородный транспорт, а не только на метро.
А что это, если не лог? Почти то же самое, что nginx пишет в свои логи. Вот только nginx не пишет тело post запросов и у ответа логгирует только http код. А в своём приложении вы можете логгировать всё. Если ваше приложение - это REST API, то логгировать запрос и ответ - маст хэв. Это потом позволит отрабатывать вопросы вида "почему мой запрос был криво обработан?" и по логам будет понятно, что клиент прислал кривой запрос.
Профилирование - это не метрики. Для mysql профиль запроса - это список действий, которая база совершила для обработки одного конкретного запроса. Выглядит вот так: +--------------------------------+----------+
| Status | Duration |
+--------------------------------+----------+
| starting | 0.000015 |
| checking query cache for query | 0.000021 |
| checking permissions | 0.000003 |
| Opening tables | 0.000007 |
| System lock | 0.000004 |
| Table lock | 0.000023 |
| init | 0.000005 |
| optimizing | 0.000005 |
| executing | 0.000025 |
| end | 0.000003 |
| end | 0.000001 |
| query end | 0.000002 |
| storing result in query cache | 0.000003 |
| freeing items | 0.000003 |
| closing tables | 0.000004 |
| logging slow query | 0.000002 |
| cleaning up | 0.000001 |
+--------------------------------+----------+ Графана откуда эти данные возьмёт?
Профилировка очень выручает в моменты, когда база начинает необъяснимо тормозить. По профилю видно где конкретно затык у базы и дальше проще понять что именно нужно сделать для устранения тормозов.
> Кстати, насчёт графаны - длинные логи там смотреть неудобно. Смотрите в файле тогда.
> А вот что писать в INFO и TRACE как-то не очень очевидно. Опишите какой у вас сервис и я подскажу. Но в целом, уровни зависят от того, что вы хотите делать с логами.
Логи уровня ERROR и выше обычно отправляются на email разработчикам. FATAL и выше уже отправляются в СМС/мессенджеры. INFO - это просто обычное нормальное выполнение приложения. Сюда записывают данные, которые помогают решить максимум вопросов, возникаюших у клиентов, пользующихся вашим сервисом и ваших сотрудников, которые тоже пользуются или эксплуатируют ваш сервис. DEBUG используется для более подробных логов. Например, значения ключевых переменных, на основе которых делается какой-то важный выбор по ходу исполнения кода. DEBUG - это расширенный INFO. Эта инфа нужна для траблшутинга более сложных и нестандартных ситуаций. TRACE - максимально подробные данные. Возможно даже требующие дополнительных действий в коде как в моём примере про профилировку mysql запросов. В обычной ситуации на проде никто не делает профилировку запросов. Но иногда нужно.
Так как DEBUG и TRACE обычно гораздо более объёмные, чем INFO, то чаще всего приложение запускают с базовым уровнем логгирования INFO. Это значит, что в логи будет записываться только инфа с уровнем INFO и выше, а всё остальное игнорироваться. DEBUG, TRACE включаются по мере необходимости для исследования сложной и нестандартной проблемы, а затем снова выключаются. То есть это данные, которые нужны время от времени, а не на постоянной основе.
Всегда имеет смысл логгировать входящий запрос и ответ на него. Если в процессе обработки запроса делаются запросы в другие сервисы, то аналогично логгируем запрос к сервису и его ответ. Дальше уже по мере жизни проекта будут добавляться более подробные логи.
Обычно много уровней используется в старых проектах с долгой историей. На старте хватает двух - INFO и ERROR. В ERROR записываются исключения, которые смогли вылезти на самый верх (обычно такие провоцируют 500 ошибку). Ещё туда можно засунуть какую-нибудь специфическую ошибку при обращении к удалённому API, типа "закончились деньги на аккаунте" или "аккаунт заблокирован". Я настраиваю логгирующие фреймворки, чтобы они отправляли все события с уровнем ERROR в sentry. В моём коде никогда не вызывается sentry напрямую.
Хороший вариант сразу логгировать все имеющиеся SQL запросы с уровнем TRACE вместе со временем выполнения запроса и количеством выбранных/затронутых строк. Далее настроить чтобы в лог записывались уровни INFO и выше. В дальнейшем при возникновении тормозов или непонятного поведения базы просто переключить уровень лога на TRACE и внимательно смотреть в логи. Маньяки могут ещё добавить профилирование запросов. Грубо говоря: if (log.isLevel(TRACE)) { db.query("SET profiling = 1"); db.query(sql); profile = db.query("SHOW PROFILE"); log.trace(profile); db.query("SET profiling = 0"); } else { db.query(sql); }. Кстати говоря, это отличный пример более тонкой разницы в уровнях. Сам запрос можно логгировать на уровне TRACE, а профайлинг на TRACE2. Или запрос на DEBUG, профайлинг на TRACE.
В java мире этот вопрос был решен давно и навсегда. Исключение обычно можно передать последним параметром при вызове лог метода и оно будет автоматически отформатировано и записано в лог с учётом вложенных исключений, если они есть. В текстовых файлах будет стек трейс столбиком с отступами, в sentry трейс тоже корректно раскладывается и склеивается с другими такими же. Если сконфигурировать json formatter, то каждый фрейм будет элементом массива. И всё это не меняя ни единой строчки кода.
Вариант попроще - закрыть интернет и сделать pull. Не знаю насчёт подмана, но утилита docker в описании ошибки напишет url, до которого не может достучаться. Что-то типа Error response from daemon: Get https://index.docker.io/v1/users/: dial tcp: ... i/o timeout. Далее берёте домен, смотрите какие на нём IP адреса (например, командами host, nslookup, dig) и прописывете в свой фаервол. Повторяете pull, смотрите какой новый домен вылез в ошибке и прописываете его. Повторяете процедуру, пока ошибки не закончатся.
Но есть загвоздка. IP адреса у докер хаба регулярно меняются, поэтому недостаточно один раз найти какие-то адреса и прописать их. Да и поддоменов у него тоже дофига. Так что будете регулярно разбираться почему докер хаб снова отвалился и какие у него теперь новые актуальные адреса.
По классике эта проблема решается использованием прокси сервера. Например, squid. На фаерволе разрешаете интернет только прокси серверу (в линуксе это возможно при помощи модуля -m owner --uid-owner). В настройках прокси разрешаете домены '*.docker.io' и '*.docker.com'. Далее настраиваете подман на использование прокси (опять же, не могу сказать как это делается у подмана, но для докера есть мануал). И всё. Проблема решена.
В дальнейшем наверняка потребуется открыть доступ к репозиториям для обновления ос (для дебиана это '*.debian.org', для убунту 'archive.ubuntu.com', 'security.ubuntu.com'), затем к другим реестрам контейнеров, например, github ('ghcr.io', 'pkg-containers.githubusercontent.com'), google ('gcr.io'), редхат ('quay.io') и может ещё какие-нибудь. Управлять этим на уровне фаервола хоть и принципиально возможно, но крайне муторно.
Так же через прокси легко обходить блокировки. Например, когда докер хаб заблокировал РФ, я просто поднял ещё один прокси в хецнере и на основном прокси сервере настроил проксирование докеровских доменов через хецнер. И когда коллеги из соседних команд ещё даже не до конца поняли что случилось и что делать, у меня уже всё работало.
Какая-нибудь малозначимая и простая система может и остановиться. Но для отказоустойчивых систем, работающих 24/7, это недостаточная причина для полной остановки.
Собственно, сложность как раз в том, что задержки и ttl любого рода на кафке делаются неудобно.
Вопрос был в контексте 1С, и я подумал, что ответ в этом же контексте будет смотреться органичнее. Но вы верно подметили - ответ применим не только к 1С.
Сервис не может предусмотреть все возможные проблемы. И не важно, кафка там у него или нет. Поэтому ошибки делятся на два типа - которые мы знаем как обработать и все остальные. С первым типом всё понятно, а вот со вторым уже не очень.
Допустим, встретилась ошибка сети. Очевидно, что коммитить оффсет нет смысла, так как все последующие сообщения так же упадут с этой же ошибкой и лучше ретраить текущее сообщение до победного, либо до изменения ошибки на какую-то другую.
А если возникла ошибка, которую никто никогда не видел? Можем ли мы блокировать чтение топика, отправив сообщение в "ретрай до победного"?
Типичным вариантом обработки всех подобных неизвестных ошибок является изъятие проблемного сообщения из топика и отправка его в отдельную независимую ретрай схему с увеличивающимся интервалом между попытками. И в системах на кафке такая схема делается либо очень сложно, либо с привлечением сторонних инструментов.
Потому что один застрявший документ остановит весь поток. Это нормально сработает только если 1С не принимает документ из-за каких-либо временных проблем: перегружена база, сеть барахлит и т.п. А если проблема перманентная, например, невалидный с точки зрения 1С документ, то на этом документе весь поток и встанет. А ретрай механизмов у кафки нет, что вынуждает городить костыли.
На мой взгляд - ничем не лучше.
ASN.1 был придуман очень давно учёными для учёных. Очень сложная спецификация с большим количеством тонкостей и нюансов. Исчезающе малое количество актуальных компиляторов и рантайм библиотек. Это тем более удивительно, что очень широко используемые во всем мире структуры - SSL сертификаты для сайтов, кодируются именно в ASN.1.
С другой стороны, protobuf создан инженерами для инженеров. Простая спецификация, хорошая поддержка на всех языках программирования.
Белый ip на устройстве не означает, что фаервол и фильтрация трафика на роутере автоматически выключаются.
Обнаружил способ сделать значение опции более читабельным и поддерживаемым. В документации указана возможность задавать значения в одинарных кавычках и тогда оно автоматически преобразуется в двоичный формат. Если указано число или IP адрес, то они сразу же целиком переводятся в двоичный формат. При этом написано "Now it is also possible to combine data types into one", что даёт возможность писать серию десятичных чисел и IP адресов подряд друг за другом без мутотени с ручным преобразованием. Не очень понятно к какой конкретно версии ROS относится слово "now", но оно появилось в документации в районе ноября 2021 года, так что думаю речь идёт про ROS 6.49 и выше.
Пример 1 из статьи можно записать как
'24''10''0''0''192.168.0.2'Чтобы не запутаться в кавычках, напишу как оно делится:
'24'+'10'+'0'+'0'+'192.168.0.2'. То есть отдельно в кавычках маска, отдельно каждый октет адреса назначения и адрес роутера целиком. Но записывать нужно без промежутков (без пробелов и т.п.).Пример 2 -
'8''10''192.168.0.2'Пример 3 -
'29''172.16.4.0''192.168.0.2'В 3 примере автор накосячил. Либо ошибся когда копипастил, либо просто запутался в преобразованиях. Кстати, если маска адреса назначения 25 и больше, то адрес назначения можно написать не раздельно, а сразу целиком.
SQQQ скорее уж...
Проводить обучение разработчиков, админов и прочих причастных основам информационной безопасности, где объясняется, что логгирование пароля - плохо и чревато.
Значит необходимо объяснить разработчику, что не стоит передавать пароль в query string, так как nginx по умолчанию записывает его в лог. Либо объяснить админу, что в nginx есть возможность логгировать урл без query string.
TLS достаточно надёжно защищает передаваемые данные между клиентом и сервером. Это подтверждено большим количеством исследований и проверено временем. Так что пароль передаётся в зашифрованном виде, а не в открытом.
Если приложение пишет пароль (или хеш пароля) в логи, то это почти наверняка не единственная и не самая большая проблема с таким-то подходом к безопасности.
Верно. Именно по этой причине пароль предварительно солят перед тем как прогнать его через хеш функцию. Бывает ещё и перчат.
Согласен. Но теперь вам нужно как-то защититься от слива базы, что происходит несравнимо чаще, чем перехват пароля/хеша в полёте. Будете хранить в базе хеш от хеша?
Запрещено пропускать, если есть персональная льгота на проезд. Например, инвалидность, статус почётного донора, студенческая/школьная скидка и т.п. За полный тариф и за своё счёт пропускай кого хочешь. Никто слова не скажет.
Это в mysql так. В постгресе правая граница исключительная:
Постгрес не позволит создать партицию с пересекающимися ренджами. Будет ошибка.
Все билеты и денежные средства от пополнений привязаны к аккаунту в транспортной системе. Физическая карта - просто ключ для доступа к билетам на аккаунте. На карте напечатан номер этого аккаунта и он же прописан в чипе. Виртуальная "карта" в приложении - тот же самый аккаунт, только без физической карты. Считайте слово "карта" синонимом слова "аккаунт" и тогда станет понятнее.
Я понимаю, вас смущает момент, что сущность "билет" не существует отдельно от сущности "аккаунт". Отдельно билет без каких-либо привязок можно купить только в кассе метро. Это будет картонка с чипом. Можно считать её лайт версией карты тройки с фиксированным количеством предоплаченных поездок.
Можно. Просто два раза прикладываете карту (транспортную, банковскую), телефон или qr-код виртуальной тройки. В первый раз проходит ребёнок, во второй раз взрослый.
Да. Есть приложение для покупки билетов. Называется "тройка".
Собственно, мосметро и является оператором карт "тройка". Непонятно что вы имеете ввиду. Если б карта называлась "московское метро" вместо "тройка", то вопросов у вас бы не возникло?
Если вы имеете ввиду билеты по типу как в теарты и музеи, когда на почту присылают PDF со штрих-кодом, то такого в метро нет. Билеты записываются на аккаунт транспортной карты и они бывают разных типов: абонементные на количество дней/поездок или же "Билет «Кошелек»" (да, это его официальное название), который просто хранилище денег, откуда списывается стоимость поездки при проходе через турникет. Туда же можно записывать билеты на пригородный транспорт, а не только на метро.
Да. Это расширение для x86 команд называется AES-NI. Реализовано и у AMD в том числе.
А что это, если не лог? Почти то же самое, что nginx пишет в свои логи. Вот только nginx не пишет тело post запросов и у ответа логгирует только http код. А в своём приложении вы можете логгировать всё. Если ваше приложение - это REST API, то логгировать запрос и ответ - маст хэв. Это потом позволит отрабатывать вопросы вида "почему мой запрос был криво обработан?" и по логам будет понятно, что клиент прислал кривой запрос.
Профилирование - это не метрики. Для mysql профиль запроса - это список действий, которая база совершила для обработки одного конкретного запроса.
Выглядит вот так:
+--------------------------------+----------+ | Status | Duration | +--------------------------------+----------+ | starting | 0.000015 | | checking query cache for query | 0.000021 | | checking permissions | 0.000003 | | Opening tables | 0.000007 | | System lock | 0.000004 | | Table lock | 0.000023 | | init | 0.000005 | | optimizing | 0.000005 | | executing | 0.000025 | | end | 0.000003 | | end | 0.000001 | | query end | 0.000002 | | storing result in query cache | 0.000003 | | freeing items | 0.000003 | | closing tables | 0.000004 | | logging slow query | 0.000002 | | cleaning up | 0.000001 | +--------------------------------+----------+Графана откуда эти данные возьмёт?
Профилировка очень выручает в моменты, когда база начинает необъяснимо тормозить. По профилю видно где конкретно затык у базы и дальше проще понять что именно нужно сделать для устранения тормозов.
> Кстати, насчёт графаны - длинные логи там смотреть неудобно.
Смотрите в файле тогда.
> А вот что писать в INFO и TRACE как-то не очень очевидно.
Опишите какой у вас сервис и я подскажу. Но в целом, уровни зависят от того, что вы хотите делать с логами.
Логи уровня ERROR и выше обычно отправляются на email разработчикам. FATAL и выше уже отправляются в СМС/мессенджеры. INFO - это просто обычное нормальное выполнение приложения. Сюда записывают данные, которые помогают решить максимум вопросов, возникаюших у клиентов, пользующихся вашим сервисом и ваших сотрудников, которые тоже пользуются или эксплуатируют ваш сервис. DEBUG используется для более подробных логов. Например, значения ключевых переменных, на основе которых делается какой-то важный выбор по ходу исполнения кода. DEBUG - это расширенный INFO. Эта инфа нужна для траблшутинга более сложных и нестандартных ситуаций. TRACE - максимально подробные данные. Возможно даже требующие дополнительных действий в коде как в моём примере про профилировку mysql запросов. В обычной ситуации на проде никто не делает профилировку запросов. Но иногда нужно.
Так как DEBUG и TRACE обычно гораздо более объёмные, чем INFO, то чаще всего приложение запускают с базовым уровнем логгирования INFO. Это значит, что в логи будет записываться только инфа с уровнем INFO и выше, а всё остальное игнорироваться. DEBUG, TRACE включаются по мере необходимости для исследования сложной и нестандартной проблемы, а затем снова выключаются. То есть это данные, которые нужны время от времени, а не на постоянной основе.
Всегда имеет смысл логгировать входящий запрос и ответ на него. Если в процессе обработки запроса делаются запросы в другие сервисы, то аналогично логгируем запрос к сервису и его ответ. Дальше уже по мере жизни проекта будут добавляться более подробные логи.
Обычно много уровней используется в старых проектах с долгой историей. На старте хватает двух - INFO и ERROR. В ERROR записываются исключения, которые смогли вылезти на самый верх (обычно такие провоцируют 500 ошибку). Ещё туда можно засунуть какую-нибудь специфическую ошибку при обращении к удалённому API, типа "закончились деньги на аккаунте" или "аккаунт заблокирован". Я настраиваю логгирующие фреймворки, чтобы они отправляли все события с уровнем ERROR в sentry. В моём коде никогда не вызывается sentry напрямую.
Хороший вариант сразу логгировать все имеющиеся SQL запросы с уровнем TRACE вместе со временем выполнения запроса и количеством выбранных/затронутых строк. Далее настроить чтобы в лог записывались уровни INFO и выше. В дальнейшем при возникновении тормозов или непонятного поведения базы просто переключить уровень лога на TRACE и внимательно смотреть в логи. Маньяки могут ещё добавить профилирование запросов. Грубо говоря:
if (log.isLevel(TRACE)) { db.query("SET profiling = 1"); db.query(sql); profile = db.query("SHOW PROFILE"); log.trace(profile); db.query("SET profiling = 0"); } else { db.query(sql); }. Кстати говоря, это отличный пример более тонкой разницы в уровнях. Сам запрос можно логгировать на уровне TRACE, а профайлинг на TRACE2. Или запрос на DEBUG, профайлинг на TRACE.В java мире этот вопрос был решен давно и навсегда. Исключение обычно можно передать последним параметром при вызове лог метода и оно будет автоматически отформатировано и записано в лог с учётом вложенных исключений, если они есть. В текстовых файлах будет стек трейс столбиком с отступами, в sentry трейс тоже корректно раскладывается и склеивается с другими такими же. Если сконфигурировать json formatter, то каждый фрейм будет элементом массива. И всё это не меняя ни единой строчки кода.
Вариант попроще - закрыть интернет и сделать pull. Не знаю насчёт подмана, но утилита docker в описании ошибки напишет url, до которого не может достучаться. Что-то типа
Error response from daemon: Get https://index.docker.io/v1/users/: dial tcp: ... i/o timeout. Далее берёте домен, смотрите какие на нём IP адреса (например, командами host, nslookup, dig) и прописывете в свой фаервол. Повторяете pull, смотрите какой новый домен вылез в ошибке и прописываете его. Повторяете процедуру, пока ошибки не закончатся.Но есть загвоздка. IP адреса у докер хаба регулярно меняются, поэтому недостаточно один раз найти какие-то адреса и прописать их. Да и поддоменов у него тоже дофига. Так что будете регулярно разбираться почему докер хаб снова отвалился и какие у него теперь новые актуальные адреса.
По классике эта проблема решается использованием прокси сервера. Например, squid. На фаерволе разрешаете интернет только прокси серверу (в линуксе это возможно при помощи модуля -m owner --uid-owner). В настройках прокси разрешаете домены '*.docker.io' и '*.docker.com'. Далее настраиваете подман на использование прокси (опять же, не могу сказать как это делается у подмана, но для докера есть мануал). И всё. Проблема решена.
В дальнейшем наверняка потребуется открыть доступ к репозиториям для обновления ос (для дебиана это '*.debian.org', для убунту 'archive.ubuntu.com', 'security.ubuntu.com'), затем к другим реестрам контейнеров, например, github ('ghcr.io', 'pkg-containers.githubusercontent.com'), google ('gcr.io'), редхат ('quay.io') и может ещё какие-нибудь. Управлять этим на уровне фаервола хоть и принципиально возможно, но крайне муторно.
Так же через прокси легко обходить блокировки. Например, когда докер хаб заблокировал РФ, я просто поднял ещё один прокси в хецнере и на основном прокси сервере настроил проксирование докеровских доменов через хецнер. И когда коллеги из соседних команд ещё даже не до конца поняли что случилось и что делать, у меня уже всё работало.
Собственно, где в статье про перехват HTTP/HTTPS?
Ожидал увидеть как вкрывают HTTPS, а на деле увидел "ЧАТ GPT".