BFD flaps на стабильных линках
Линк выглядит стабильным: OSPF и BGP держат соседство, ping проходит, маршруты есть, но BFD внезапно сигнализирует «link down».
Часто причина кроется в jitter или небольших microbursts на линке. BFD очень чувствителен к задержкам: heartbeat и detect time могут «срабатывать» слишком быстро.
Проверка ситуации:
⏺ Что помогает: увеличить тайминги BFD (detect interval, multiplier), проверить качество линка на jitter и drops, применить QoS для BFD-трафика, чтобы он не терялся при нагрузке.
N.A.
Линк выглядит стабильным: OSPF и BGP держат соседство, ping проходит, маршруты есть, но BFD внезапно сигнализирует «link down».
В результате мгновенно конвергируют маршруты, появляются кратковременные packet drops, а логи показывают тревожные сообщения, хотя физический линк не упал.
Часто причина кроется в jitter или небольших microbursts на линке. BFD очень чувствителен к задержкам: heartbeat и detect time могут «срабатывать» слишком быстро.
Проверка ситуации:
show bfd neighbors
show bfd sessions
ping <neighbor-ip> repeat 100
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤1
Как понять, что упираешься в single-flow limit
Это классический случай single-flow ограничения: один TCP-поток не может «раскачать» линк из-за latency и размеров окна. Чем выше RTT, тем сильнее эффект - поток просто не успевает нарастить объём данных в полёте.
Самая быстрая проверка - сравнить один поток и несколько:
Если при -P 1 скорость низкая, а при -P 10 резко растёт - это не проблема канала. Это ограничение одного TCP-потока.
Дальше можно посмотреть детали по соединению:
Обращаем внимание на cwnd, rtt, retrans. Маленькое окно или высокий RTT сразу объясняют, почему throughput не растёт.
Что обычно влияет:
⏺ latency между узлами
⏺ TCP window size и autotuning
⏺ packet loss (даже небольшой сильно режет throughput)
⚡️ В таких ситуациях «сеть медленная» - неправильный вывод. Канал свободен, просто один поток физически не может его загрузить.
N.A.
Канал вроде быстрый, интерфейс не забит, CPU в порядке - но скорость упирается в 200–300 Мбит/с и выше не растёт. При этом параллельные загрузки «вдруг» дают почти весь канал.
Это классический случай single-flow ограничения: один TCP-поток не может «раскачать» линк из-за latency и размеров окна. Чем выше RTT, тем сильнее эффект - поток просто не успевает нарастить объём данных в полёте.
Самая быстрая проверка - сравнить один поток и несколько:
iperf3 -c <server-ip> -P 1
iperf3 -c <server-ip> -P 10
Если при -P 1 скорость низкая, а при -P 10 резко растёт - это не проблема канала. Это ограничение одного TCP-потока.
Дальше можно посмотреть детали по соединению:
ss -ti
Обращаем внимание на cwnd, rtt, retrans. Маленькое окно или высокий RTT сразу объясняют, почему throughput не растёт.
Что обычно влияет:
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤1
Parallelism в сети: почему несколько потоков - это норма
Один TCP-поток почти никогда не использует весь канал между узлами с высокой пропускной способностью или большим RTT.
Чтобы это обойти, системы создают несколько параллельных соединений. Браузеры открывают сразу несколько TCP-сессий к серверу, CDN и S3 одновременно гонят несколько потоков для одного файла.
В итоге канал используется максимально, ограничения одного TCP-потока нивелируются, а мелкие потери пакетов уже не тормозят весь трафик.
Проверка и тест:
N.A.
Один TCP-поток почти никогда не использует весь канал между узлами с высокой пропускной способностью или большим RTT.
Даже гигабитный линк может быть недогружен, если работает только одно соединение.
Чтобы это обойти, системы создают несколько параллельных соединений. Браузеры открывают сразу несколько TCP-сессий к серверу, CDN и S3 одновременно гонят несколько потоков для одного файла.
В итоге канал используется максимально, ограничения одного TCP-потока нивелируются, а мелкие потери пакетов уже не тормозят весь трафик.
Проверка и тест:
iperf3 -c <server-ip> -P 1 # один поток, упираемся в single-flow limit
iperf3 -c <server-ip> -P 8 # 8 потоков, канал почти полностью загружен
N.A.
👍15❤1
Апгрейд канала не всегда ускоряет приложение
Увеличили линк с 1 Гбит/с до 10 Гбит/с, а скорость приложения почти не изменилась. Такое часто встречается, когда речь про один TCP-поток.
RTT остался прежним, TCP window не вырос - поток просто не успевает заполнять новый bandwidth.
Реальный прирост появляется только если:
⏺ добавить параллельные потоки
⏺ оптимизировать TCP параметры
Проверка:
N.A.
Увеличили линк с 1 Гбит/с до 10 Гбит/с, а скорость приложения почти не изменилась. Такое часто встречается, когда речь про один TCP-поток.
Дело не в канале, а в том, сколько данных поток успевает держать «в полёте».
RTT остался прежним, TCP window не вырос - поток просто не успевает заполнять новый bandwidth.
Реальный прирост появляется только если:
Проверка:
iperf3 -c <server-ip> -P 1 # один поток — потолок не выше старого
iperf3 -c <server-ip> -P 8 # несколько потоков — канал полностью загружен
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11
TCP retransmits в реальных сетях
Даже на пустом канале приложения могут тормозить. Packet loss или jitter заставляют TCP пересылать пакеты снова и снова, а один поток не успевает «накачать» канал.
⏺ Признаки - медленный throughput, высокий RTT, заметные retransmits.
На Linux проверить легко
Даже 0.1–0.5% потерь на WAN сильно сказываются на скорости одного потока. Параллельные соединения и настройка TCP window позволяют компенсировать этот эффект.
Особенно это важно для high-speed каналов между датацентрами, VoIP и стриминговых сервисов, где каждая миллисекунда задержки критична.
N.A.
Даже на пустом канале приложения могут тормозить. Packet loss или jitter заставляют TCP пересылать пакеты снова и снова, а один поток не успевает «накачать» канал.
На Linux проверить легко
ss -ti | grep retrans
tcpdump -i eth0 tcp and host <peer-ip> -vv
Даже 0.1–0.5% потерь на WAN сильно сказываются на скорости одного потока. Параллельные соединения и настройка TCP window позволяют компенсировать этот эффект.
Особенно это важно для high-speed каналов между датацентрами, VoIP и стриминговых сервисов, где каждая миллисекунда задержки критична.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤1
QoS surprises в multi-tenant сетях
Даже когда вроде всё настроено, трафик может терять приоритет. CoS на L2 и DSCP на L3 не совпадают, и на trunk или overlay это особенно заметно: пакеты проходят, но VoIP, видео и контрольные протоколы начинают тормозить.
Чтобы понять, где «теряется приоритет», полезно смотреть, как устройство обрабатывает QoS. Например на Cisco:
⏺ Практика: согласовывать trust boundary между L2 и L3, следить за очередями и задержками для критичных VLAN. Даже маленький mismatch может превратить приоритетный трафик в «тормозной», а эти команды помогут быстро увидеть проблему и исправить её.
N.A.
Даже когда вроде всё настроено, трафик может терять приоритет. CoS на L2 и DSCP на L3 не совпадают, и на trunk или overlay это особенно заметно: пакеты проходят, но VoIP, видео и контрольные протоколы начинают тормозить.
Чтобы понять, где «теряется приоритет», полезно смотреть, как устройство обрабатывает QoS. Например на Cisco:
# Как классифицируются пакеты на интерфейсе
show mls qos interface Gi1/0/1
show policy-map interface Gi1/0/1
# Какие очереди и сколько пакетов дропается
show queueing interface Gi1/0/1
# Какие class-map и DSCP сопоставления настроены
show class-map
show policy-map
# Проверка QoS на VLAN
show vlan brief
show mls qos vlan 10
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤1
Почему «низкая загрузка» не означает, что сеть здорова
Но пользователи всё равно жалуются: видео фризит, API отвечает рывками, TCP ведёт себя странно.
А дело в том, что сеть редко работает равномерно. Трафик приходит не гладкой линией, а короткими всплесками. И эти microbursts легко забивают буферы даже на полностью «свободном» канале.
В этот момент интерфейс может выглядеть почти пустым по среднему значению, но внутри уже идут очереди, дропы и задержки.
И получается парадокс: по метрикам всё хорошо, а по факту сервис уже деградирует.
N.A.
На графиках всё спокойно. 10–20% загрузки, никаких красных зон, интерфейсы не перегружены. С точки зрения мониторинга - сеть «дышит».
Но пользователи всё равно жалуются: видео фризит, API отвечает рывками, TCP ведёт себя странно.
А дело в том, что сеть редко работает равномерно. Трафик приходит не гладкой линией, а короткими всплесками. И эти microbursts легко забивают буферы даже на полностью «свободном» канале.
В этот момент интерфейс может выглядеть почти пустым по среднему значению, но внутри уже идут очереди, дропы и задержки.
show interfaces counters
show interface <int> | include rate
show queueing interface <int>
И получается парадокс: по метрикам всё хорошо, а по факту сервис уже деградирует.
N.A.
👍8❤1
DNS кеш на уровне системы и «устаревшие» ответы
В таких ситуациях проблема часто не в DNS как сервисе, а в том, что ответ уже зафиксирован ближе к клиенту.
Это может быть кеш ОС, systemd-resolved, браузера или самого приложения. Пока TTL не истечёт или кеш не сброшится, запросы продолжают уходить на старый адрес.
В реальной работе это чаще всего проявляется при миграциях сервисов, смене backend или переезде между датацентрами.
Сеть уже работает на новом IP, но часть трафика всё ещё живёт в старой картине из-за локального резолва.
N.A.
Сервис уже переехал, DNS запись обновлена, инфраструктура выглядит корректно. Но часть клиентов продолжает ходить на старый IP и поведение выглядит нестабильно.
В таких ситуациях проблема часто не в DNS как сервисе, а в том, что ответ уже зафиксирован ближе к клиенту.
Это может быть кеш ОС, systemd-resolved, браузера или самого приложения. Пока TTL не истечёт или кеш не сброшится, запросы продолжают уходить на старый адрес.
resolvectl status
resolvectl statistics
dig <domain>
nslookup <domain>
getent hosts <domain>
В реальной работе это чаще всего проявляется при миграциях сервисов, смене backend или переезде между датацентрами.
Сеть уже работает на новом IP, но часть трафика всё ещё живёт в старой картине из-за локального резолва.
N.A.
👍7❤1
Link aggregation hashing algorithms и почему нагрузка распределяется неравномерно
Port-channel или bond выглядит как один быстрый интерфейс, но внутри трафик всегда режется по алгоритму хеширования. И от того, какие поля участвуют в hash, зависит реальная загрузка линков.
Если hash основан на L2 (например src-mac или dst-mac), распределение зависит от количества MAC-адресов. В сети с few talkers это быстро приводит к перекосу, когда один линк загружен, а остальные почти пустые.
⏺ Если используется L3/L4 (src-ip, dst-ip, 5-tuple), балансировка становится ближе к реальной нагрузке приложений, но все равно упирается в количество потоков. Один большой поток всегда останется на одном физическом линке.
Cisco:
Можно посмотреть, как именно устройство строит hash и какие поля участвуют в распределении.
MikroTik:
А проявляется так: порт-канал есть, суммарная скорость высокая, но один линк перегружен, остальные недоиспользованы. И поведение может меняться просто из-за смены типа трафика или количества потоков.
N.A.
Port-channel или bond выглядит как один быстрый интерфейс, но внутри трафик всегда режется по алгоритму хеширования. И от того, какие поля участвуют в hash, зависит реальная загрузка линков.
Если hash основан на L2 (например src-mac или dst-mac), распределение зависит от количества MAC-адресов. В сети с few talkers это быстро приводит к перекосу, когда один линк загружен, а остальные почти пустые.
Cisco:
show etherchannel load-balance
show etherchannel summary
show interfaces port-channel 1
Можно посмотреть, как именно устройство строит hash и какие поля участвуют в распределении.
MikroTik:
/interface bonding print
/interface bonding monitor bond1
А проявляется так: порт-канал есть, суммарная скорость высокая, но один линк перегружен, остальные недоиспользованы. И поведение может меняться просто из-за смены типа трафика или количества потоков.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8👍3
VXLAN vs MPLS vs VLAN design в датацентре
Три разных подхода к сегментации и масштабированию сети. Отличаются не только технологией, но и моделью построения всей инфраструктуры.
1️⃣ VLAN design
VLAN - это классическая L2 сегментация через broadcast domain. Всё просто: разделили сеть на VLAN и связали их через trunk или L3 устройство.
Подходит для небольших и средних сетей, где важна простота и быстрый запуск.
Проблемы начинаются при масштабировании: рост количества VLAN, зависимость от STP и сложность расширения между сегментами и стойками.
2️⃣ MPLS
MPLS использует label switching вместо чистого IP routing. Трафик идет по меткам, что позволяет строить масштабируемый core и управлять путями.
Часто используется в операторских сетях и больших backbone инфраструктурах, где важны контроль и предсказуемость.
Сложность выше за счет control-plane (LDP, RSVP, BGP) и более сложной диагностики.
3️⃣ VXLAN
VXLAN строит overlay поверх IP сети. Ethernet кадры инкапсулируются в UDP и переносятся через L3 underlay.
Это основной подход для современных spine-leaf DC, где underlay остается простым IP routing, а логика сегментации уходит в overlay.
Минус - добавляется слой абстракции, который нужно дебажить вместе с underlay.
N.A.
Три разных подхода к сегментации и масштабированию сети. Отличаются не только технологией, но и моделью построения всей инфраструктуры.
VLAN - это классическая L2 сегментация через broadcast domain. Всё просто: разделили сеть на VLAN и связали их через trunk или L3 устройство.
Подходит для небольших и средних сетей, где важна простота и быстрый запуск.
Проблемы начинаются при масштабировании: рост количества VLAN, зависимость от STP и сложность расширения между сегментами и стойками.
show vlan brief
show interfaces trunk
show spanning-tree
MPLS использует label switching вместо чистого IP routing. Трафик идет по меткам, что позволяет строить масштабируемый core и управлять путями.
Часто используется в операторских сетях и больших backbone инфраструктурах, где важны контроль и предсказуемость.
Сложность выше за счет control-plane (LDP, RSVP, BGP) и более сложной диагностики.
show mpls forwarding-table
show mpls ldp neighbor
show ip route
VXLAN строит overlay поверх IP сети. Ethernet кадры инкапсулируются в UDP и переносятся через L3 underlay.
Это основной подход для современных spine-leaf DC, где underlay остается простым IP routing, а логика сегментации уходит в overlay.
Минус - добавляется слой абстракции, который нужно дебажить вместе с underlay.
show nve peers
show nve vni
show bgp l2vpn evpn summary
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9❤1👍1
FastPath vs FastTrack и разрыв модели обработки трафика
⏺ FastPath пытается вывести трафик из полного firewall pipeline и отправить его напрямую в forwarding path, если условия позволяют.
⏺ FastTrack работает поверх conntrack и ускоряет уже установленные соединения, сокращая участие firewall, mangle и части обработки для established/related потоков.
Один и тот же поток сначала проходит полный стек обработки, а после установления состояния часть трафика начинает идти по ускоренному пути.
В итоге поведение firewall, очередей и счетчиков может меняться в процессе жизни соединения без изменения конфигурации.
MikroTik проверка
N.A.
FastPath и FastTrack оба ускоряют обработку, но работают на разных уровнях и ломают привычную линейную модель прохождения пакета через RouterOS.
Один и тот же поток сначала проходит полный стек обработки, а после установления состояния часть трафика начинает идти по ускоренному пути.
В итоге поведение firewall, очередей и счетчиков может меняться в процессе жизни соединения без изменения конфигурации.
MikroTik проверка
/ip firewall filter print
/ip firewall mangle print
/ip firewall connection print
/ip settings print
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
Правильное Питание (ПП) коммутационного оборудования
Система резервного электроснабжения должна обеспечивать не просто бесперебойное, но правильное питание. ПП — как у зожников, только для электроприборов. Много есть неочевидных нюансов — и первые в мире ПП-ИБП, решающие все проблемы с плохим качеством электричества, делает Systeme Electric.
Тотальный онлайн-ЗОЖ — онлайн Защита от Отключений Железа. ПП-ИБП Systeme Electric с онлайн-топологией двойного преобразования обеспечат чистый синус, защитят от помех и скачков напряжения.
Повышенная БЖУ — Бесперебойность Жизненно-важных Устройств. Тянут нагрузку в 150% от номинальной. Система не рухнет в момент включения мощных потребителей (именно в это время возникают краткосрочные, но сильные перегрузки).
Настоящий суперфуд для оборудования — высочайший КПД 95%. Из-за этого ПП-ИБП Systeme Electric не перегреваются.
Самое полное ПП-меню — поддерживают все возможные интерфейсы и протоколы (EPO, SNMP, RS-485, RS-232, USB, RJ45/RJ11, EMBS). Не будет сложностей с подключением нового бесперебойника к существующему оборудованию.
Гарантия рекордная — 3 года — такую больше никто не дает.
Техподдержка 24/7 (в мессенджерах, днем и по телефону): после 6 — можно!
ПП-ИБП Systeme Electric — это не какой-то китайский электро-фастфуд. Это бывшее российское подразделение Schneider Electric, производителя легендарных APC. Технологии и лучшая команда инженеров те же самые — только вывеска новая (из-за евросанкций). Эти люди точно знают: на здоровье оборудования не экономят!
Первые в мире ПП-ИБП тут.
Система резервного электроснабжения должна обеспечивать не просто бесперебойное, но правильное питание. ПП — как у зожников, только для электроприборов. Много есть неочевидных нюансов — и первые в мире ПП-ИБП, решающие все проблемы с плохим качеством электричества, делает Systeme Electric.
Тотальный онлайн-ЗОЖ — онлайн Защита от Отключений Железа. ПП-ИБП Systeme Electric с онлайн-топологией двойного преобразования обеспечат чистый синус, защитят от помех и скачков напряжения.
Повышенная БЖУ — Бесперебойность Жизненно-важных Устройств. Тянут нагрузку в 150% от номинальной. Система не рухнет в момент включения мощных потребителей (именно в это время возникают краткосрочные, но сильные перегрузки).
Настоящий суперфуд для оборудования — высочайший КПД 95%. Из-за этого ПП-ИБП Systeme Electric не перегреваются.
Самое полное ПП-меню — поддерживают все возможные интерфейсы и протоколы (EPO, SNMP, RS-485, RS-232, USB, RJ45/RJ11, EMBS). Не будет сложностей с подключением нового бесперебойника к существующему оборудованию.
Гарантия рекордная — 3 года — такую больше никто не дает.
Техподдержка 24/7 (в мессенджерах, днем и по телефону): после 6 — можно!
ПП-ИБП Systeme Electric — это не какой-то китайский электро-фастфуд. Это бывшее российское подразделение Schneider Electric, производителя легендарных APC. Технологии и лучшая команда инженеров те же самые — только вывеска новая (из-за евросанкций). Эти люди точно знают: на здоровье оборудования не экономят!
Первые в мире ПП-ИБП тут.
❤5🤔2
Почему после изменения ACL пропадает доступ к части сети
Настроили новый ACL на интерфейсе или между сегментами, но часть сервисов перестала отвечать: одни IP доступны, другие нет, часть приложений зависает на таймаутах.
Чаще всего проблема не в самом ACL, а в порядке правил и скрытых “deny any” в конце. Также часто забывают про обратный трафик, из-за чего запрос проходит, а ответ блокируется.
Типовые причины:⏺ правило блокирует обратный трафик (return traffic) ⏺ ACL применён не в том направлении (in/out) ⏺ отсутствуют разрешения для established/related соединений ⏺ правило выше по списку перекрывает нужный allow ⏺ забытый implicit deny в конце списка ⏺ ACL применён только на одном интерфейсе в цепочке
Команды для проверки:
Проверка пути:
Проверка логики ACL:
Если проблема в направлении применения ACL:
Если ломается из-за порядка правил — правило выше перекрывает нужный трафик, поэтому проверять нужно сверху вниз, а не по смыслу.
N.A.
Настроили новый ACL на интерфейсе или между сегментами, но часть сервисов перестала отвечать: одни IP доступны, другие нет, часть приложений зависает на таймаутах.
Чаще всего проблема не в самом ACL, а в порядке правил и скрытых “deny any” в конце. Также часто забывают про обратный трафик, из-за чего запрос проходит, а ответ блокируется.
Типовые причины:
Команды для проверки:
show access-lists
show ip interface
show run interface Gi0/0
debug ip packet
(аккуратно в проде)
Проверка пути:
traceroute <ip>
ping <ip>
Проверка логики ACL:
show access-lists <name>
Если проблема в направлении применения ACL:
interface Gi0/0
ip access-group <name> in
ip access-group <name> out
Если ломается из-за порядка правил — правило выше перекрывает нужный трафик, поэтому проверять нужно сверху вниз, а не по смыслу.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤1
Почему после добавления VLAN пропадает связь
Добавили VLAN, всё выглядит корректно, но хосты внезапно перестают видеть шлюз или друг друга. При этом линк “зелёный”, порты up, явных ошибок нет.
Проверка обычно начинается с того, что VLAN вообще существует и не потерялся на уровне коммутатора.
Дальше почти всегда упирается в транк: VLAN создан, но между устройствами он просто не доходит.
Если с транком всё ок, проверяется интерфейс с точки зрения реальной конфигурации, а не ожиданий.
Если есть L3, дальше смотрят SVI - и тут часто оказывается, что интерфейс просто не поднялся.
Проверка маршрутов иногда быстро подтверждает картину.
N.A.
Добавили VLAN, всё выглядит корректно, но хосты внезапно перестают видеть шлюз или друг друга. При этом линк “зелёный”, порты up, явных ошибок нет.
Проверка обычно начинается с того, что VLAN вообще существует и не потерялся на уровне коммутатора.
show vlan brief
Дальше почти всегда упирается в транк: VLAN создан, но между устройствами он просто не доходит.
show interfaces trunk
Если с транком всё ок, проверяется интерфейс с точки зрения реальной конфигурации, а не ожиданий.
show running-config interface Gi0/1
Если есть L3, дальше смотрят SVI - и тут часто оказывается, что интерфейс просто не поднялся.
show ip interface brief | include Vlan
Проверка маршрутов иногда быстро подтверждает картину.
show ip route connected
N.A.
👍12💯1
Появился удобный AI-инструмент для подготовки к найму и прохождения собеседований - Sobes Copilot.
Это ассистент, который помогает прямо во время интервью: слушает диалог, распознаёт речь в реальном времени и подсказывает, как лучше ответить. Работает в Zoom, Google Meet, Teams, VK Calls и других платформах, и не виден при демонстрации экрана.
Что есть в Sobes Copilot:
• Подсказки в реальном времени во время собеседований
• Пост-анализ интервью - сервис разбирает прошедший созвон, выделяет сильные и слабые места, удачные формулировки и зоны роста
• Генератор и улучшение резюме - помогает собрать сильное резюме под конкретную вакансию
• Мок-собеседования (и System Design) - тренировки с ИИ, приближённые к реальным интервью
• Авто-отклики на HH - автоматизируют массовую подачу на вакансии по заданным фильтрам
Если хочешь проходить собеседования спокойнее, увереннее и системнее - посмотри, что умеет Sobes Copilot.
Это ассистент, который помогает прямо во время интервью: слушает диалог, распознаёт речь в реальном времени и подсказывает, как лучше ответить. Работает в Zoom, Google Meet, Teams, VK Calls и других платформах, и не виден при демонстрации экрана.
Что есть в Sobes Copilot:
• Подсказки в реальном времени во время собеседований
• Пост-анализ интервью - сервис разбирает прошедший созвон, выделяет сильные и слабые места, удачные формулировки и зоны роста
• Генератор и улучшение резюме - помогает собрать сильное резюме под конкретную вакансию
• Мок-собеседования (и System Design) - тренировки с ИИ, приближённые к реальным интервью
• Авто-отклики на HH - автоматизируют массовую подачу на вакансии по заданным фильтрам
Если хочешь проходить собеседования спокойнее, увереннее и системнее - посмотри, что умеет Sobes Copilot.
🔥1
Почему сервис “умирает” после включения retry
Retry включили на клиенте или gateway, и вместо стабилизации получили рост нагрузки и ощущение деградации, хотя инфраструктура не менялась.
Дальше это проявляется как рост latency и “тяжёлые” ответы, даже если сервис формально не падает.
Если посмотреть на уровень пакетов:
На HTTP уровне это превращается в повторяющиеся обращения к одному endpoint без необходимости.
N.A.
Retry включили на клиенте или gateway, и вместо стабилизации получили рост нагрузки и ощущение деградации, хотя инфраструктура не менялась.
curl -v <url>
Дальше это проявляется как рост latency и “тяжёлые” ответы, даже если сервис формально не падает.
mtr <ip>
Если посмотреть на уровень пакетов:
tcpdump -i <iface>
На HTTP уровне это превращается в повторяющиеся обращения к одному endpoint без необходимости.
curl -I <url>
N.A.
👍5❤1
Почему “не видно проблему” в сети, пока не посмотришь состояние TCP очередей
Иногда сервис не падает, но начинает “вязнуть”: запросы идут, ответы есть, но задержки растут без очевидной причины.
В таких случаях полезно смотреть не соединения как факт, а их внутреннее состояние в ядре.
Почему “всё открывается”, но часть запросов теряется
Бывает ситуация, когда сеть вроде бы живая, но часть пакетов просто не доходит. Это не видно на уровне приложения, пока не посмотреть статистику интерфейса.
Почему DNS “работает”, но поведение разное у клиентов
Иногда проблема вообще не в резолвинге как таковом, а в том, как ядро кеширует и повторно использует результаты.
N.A.
Иногда сервис не падает, но начинает “вязнуть”: запросы идут, ответы есть, но задержки растут без очевидной причины.
В таких случаях полезно смотреть не соединения как факт, а их внутреннее состояние в ядре.
ss -tin state established
Почему “всё открывается”, но часть запросов теряется
Бывает ситуация, когда сеть вроде бы живая, но часть пакетов просто не доходит. Это не видно на уровне приложения, пока не посмотреть статистику интерфейса.
ip -s link show <iface>
Почему DNS “работает”, но поведение разное у клиентов
Иногда проблема вообще не в резолвинге как таковом, а в том, как ядро кеширует и повторно использует результаты.
getent ahosts <domain>
N.A.
👍3