Лишь бы юзер был доволен
Гигабитный канал может быть загружен лишь наполовину, а пинг под нагрузкой всё равно взлетает до сотен миллисекунд.
Разбираемся, где копятся очереди, как распознать bufferbloat и какие механизмы действительно удерживают задержку под контролем.
Это заключительная статья цикла о том, как я пытался сделать алерты Zabbix в домашней лаборатории чуть умнее, прикрутив к ним локальную LLM и не получить на выходе архитектурного монстра Франкенштейна.
В первой и второй частях мы разобрались с постановкой задачи и выбрали себе фаворита из локальных LLM, в третьей — занимались скучным проектированием HLD и LLD. Теперь же переходим к самому интересному — прикладному материалу. В этой статье рассмотрим, что получилось, когда архитектурный каркас начали последовательно превращать в рабочий self-hosted сервис в коде, и с какими узкими местами пришлось столкнуться в процессе.
DISCLAIMER: к сожалению, выпуск задержался, ведь основное место работы отнимает огромное количество времени, только отпуск позволяет вернуться к личным проектам.
Часть 1: Вводная и формирование ТЗ
Часть 3: Формирование HLD и немного LLD
Часть 4: Что из этого вышло (Вы здесь)
Если вы эксплуатируете VictoriaLogs, повседневная работа сводится к трём вещам: отправке логов, выполнению запросов и настройке срока хранения, чтобы не переполнить диск. Всё остальное незаметно происходит на диске.
В этой статье мы проследим путь одной записи лога — от поступления в VictoriaLogs до окончательного размещения на диске. Это поможет представить, что происходит внутри системы, и понять наблюдаемое поведение: почему запросы выполняются быстро, почему на диске иногда появляется множество файлов и какие флаги и метрики важны при поиске неполадок. Статья рассчитана на широкую аудиторию: не требуется ни опыт программирования, ни знание Go. Тем, кто захочет разобраться глубже, первоисточником послужит исходный код VictoriaLogs.
В первой статье я говорил, что безопасность — это свойство архитектуры, а во второй разложил по полочкам способы построить logical air gap. Теперь самое главное: «А зачем вообще это всё? У нас есть firewall, WAF, TLS и патч-менеджмент».
Привет, это Данил Киселев, сетевой инженер в Yandex Infrastructure. Представьте себе, что у вас не просто офис, а очень большой офис с тысячами пользователей, которые ходят с созвона на созвон, перемещаясь между переговорками. Разумеется, им хочется оставаться на связи в процессе и не думать о ближайших точках доступа к Wi‑Fi. Для сетевого инженера это не выглядит проблемой на небольших масштабах. Но что если скоро ваш офис вырастет и таких точек доступа в сетевой фабрике может стать уже 20 000 и больше?
В статье расскажу про опыт использования технологии VxLAN в корпоративных сетях Яндекса. В частности речь пойдёт про построение Wi‑Fi поверх VxLAN‑туннелей, которые таким образом смогли помочь нам с большим доменом и заодно избежать широковещательного шторма.
Российский рынок observability парадоксален. У нас есть сильные продуктовые и внутренние инженерные команды, сложные заказчики, открытые технологии и редкое окно для развития собственного рынка. И одновременно десятки компаний параллельно оплачивают один и тот же фундамент: сбор, хранение, права, аудит, обновления, дедупликацию и корреляцию.
13,84 млрд рублей потерялись. Моя гипотеза: заметную часть этой суммы мы тратим на повторное создание одинаковых платформенных функций. Размер этой части ещё нужно измерить, но он точно существенен. И эта часть вместо мультиплицирования технологического задела в тиражируемых решениях российских вендоров остается технологиями для одного клиента.
За последние несколько месяцев плотной работы над инфраструктурой для проекта я прошёл путь от первых команд в терминале Linux до настройки полностью отказоустойчивого K3s‑кластера с Zero‑Downtime деплоем. Шишек на этом деле я набил огромное количество, и мне определённо есть чем поделиться.
Сразу оговорюсь: в этой статье не будет монотонных гайдов, слепых копипастов YAML‑манифестов и пересказа официальной документации. С базовой настройкой вы отлично справитесь, прочитав мануалы создателей этих инструментов.
Для меня этот материал — способ структурировать собственный опыт. Хотя, не буду скрывать, обсуждения в комментариях мне тоже интересны. Я хочу разобрать реальные ошибки при переходе от простого Docker Compose к Kubernetes, показать процесс траблшутинга и критически взглянуть на проделанную работу, чтобы понять: а всё ли было сделано верно?
Уверен, статья будет интересна не только DevOps‑инженерам, но и backend‑ и frontend‑разработчикам, а также любым техническим специалистам, которые хотят понимать, что на самом деле происходит с их кодом после пуша в репозиторий, почему локальная среда так сильно отличается от реального продакшена и как заставить приложение выживать при сбоях инфраструктуры.
Управление данными в Kubernetes часто кажется сложным. Если грамотно не подключить внешнее хранилище, то при любом перезапуске пода все накопленные файлы бесследно исчезнут. Этот материал — практическое руководство для тех, кто только осваивает администрирование K8s и хочет разобраться в логике работы дисков без погружения в запутанную документацию.
На простых примерах с реальной инфраструктурой изучим всю архитектуру выделения ресурсов. Развернем хранилище в тестовом кластере, смонтируем диск и заглянем внутрь файловой системы ноды.
Привет! Я Катя, младший системный администратор в Selectel. Надеюсь, моя работа поможет выстроить в голове четкую картину и сэкономит часы на дебаге, если нужный диск однажды откажется подключаться.
За несколько лет мы автоматизировали несколько сити-ферм: от небольшой лаборатории до производства с посевной площадью 100 м². Теперь мы запустили ферму уже на 380 м². Каждый новый проект заставлял пересматривать архитектуру системы управления: одни решения подтверждали свою эффективность, другие приходилось менять или вовсе отбрасывать.
В этой статье расскажу, какие подходы выдержали проверку практикой и как сегодня устроена автоматизация нашей самой большой фермы.
Поднял сервер за границей, всё летает - а потом маркетплейс просит капчу, банк отказывает в операции, сайт объявлений не открывается. Совет один: сделай обратный впн. Рецептов несколько, и работают они по-разному.
Собрал их у себя и посмотрел не на описания, а на то, что о вашем адресе видно снаружи. «Российский IP» оказался не одним свойством, а тремя, и закрывает все три только один вариант из четырёх.
Мы делаем RCQ, мессенджер со сквозным шифрованием и открытым кодом (Android, iOS, протокол). В нашем основном регионе приложение блокируют, поэтому обход встроен внутрь клиента: sing-box в самом приложении, пул релеев, подписанный конфиг с их списком, запасной путь через CDN.
Всё это писалось месяцами и ни разу не измерялось. Мы знали, что механизмы есть, а срабатывают ли они хоть когда-нибудь и в каком проценте случаев, никто из нас сказать не мог, потому что спрашивать было не у чего.
В начале августа ушло двое суток на приборы. Ни одной новой функции, только измерение уже написанного. Нашлось восемь мест одной и той же формы: механизм построен, задеплоен, в него верят, а в продакшене он либо не выполнялся ни разу, либо выполнялся не так, как все были уверены.
Дальше про приборы. Обход блокировок тут просто предметная область, приёмы работают на любом коде, который включается редко и по чужому расписанию: ретраи, фолбэки, аварийные переключения, резервные каналы доставки.
У директив proxy_* и fastcgi_* совпадает 46 опций из 53 — буферизация, таймауты, кеш, next_upstream, с точностью до префикса и вплоть до значений по умолчанию. Два независимо написанных модуля так не сходятся.
Они и не независимы. Всё, чем proxy_pass отличается от fastcgi_pass, — девять указателей на функции в ngx_http_upstream_t. Соединение, таймауты, повторы, буферизация и отдача клиенту лежат в общих 7352 строках ngx_http_upstream.c, и восемь модулей — от proxy до свежего tunnel — дёргают один и тот же код.
Только контракт из этих девяти указателей врёт в обе стороны. Один из них, abort_request, ставят все восемь модулей — а машинерия не вызывает его ни разу: ноль вызовов во всём дереве и ни одного коммита с вызовом за всю публичную историю, с импорта 0.1.14 в январе 2005-го. Другой, pipe->input_filter, в контракте не объявлен вовсе — но обязателен, как только включена буферизация, и вызывается без проверки на NULL.
Разбираем по тегу release-1.31.3 со ссылками файл:строка: все места вызова каждого колбэка, включая тот, который разбирает заголовок не из сокета, а из файла кеша; матрица «кто какие указатели ставит» по всем восьми модулям; два сценария падения с разными стек-трейсами. Плюс свой рабочий upstream-модуль на 335 строк, собранный и проверенный curl'ом, и tunnel — самый маленький из восьми, приехавший в open source в апреле.
Первая часть закончилась тем, что телефон заработал, и какое-то время этим всё и ограничивалось. postmarketOS на mainline-ядре, сверху Docker, Tailscale и один небольшой сервис, которому от меня ничего не требовалось. Я убрал телефон на полку и перестал о нём думать — ровно этого я от него и хотел.
Сервис работал. Заодно выяснилось, что процессор всё это время держался на 70 °C. Не под нагрузкой, а в покое, днём и ночью, на устройстве без вентилятора и без радиатора, где тепло уходит только через собственный алюминиевый корпус.
Вопрос, который стоило задать сразу: чем он занят, что даёт такую температуру. Дальше — ответ на него.
Личная корзина Диска - 30 дней. Корзина организации - “обычно” тоже 30, но по 10 ГБ на сотрудника, без общих дисков и не на всех тарифах. Письма в “Удалённых” - опять 30 дней. А про удаление аккаунта на домене документация говорит коротко: “восстановить данные будет невозможно”. Прошёлся по справке Яндекс 360 и свёл в одну таблицу, где заканчивается каждый штатный механизм восстановления - и что спрашивать со схемы, которая начинается там, где корзины кончаются.
Для проверки сквозного трейсинга GenAI-приложения мы взяли OpenTelemetry Demo 3.0. В обновлённом стенде уже были сервисы chatbot, agentи mcp, а также ИИ-спаны. Оставалось направить телеметрию по OTLP в ProtoOBP и открыть готовую цепочку вызовов. Но все спаны приехали, а единой истории не получилось: один пользовательский запрос распался на два трейса на границе MCP.
Автоматическая HTTP-инструментация связь не восстановила. Мы проследили traceparent до MCP _meta, нашли место потери контекста и добавили небольшой слой над ClientSession. После исправления цепочка собралась в единый трейс из 27 спанов.
В статье покажем исходный разрыв, код исправления и проверку результата по клиентскому и серверному спанам и карте связей.
Привет, Хаброжители! Откройте для себя захватывающий мир Kali Linux — ведущей платформы для продвинутого тестирования на проникновение. Оттачивайте навыки, проводите сложные пентесты в корпоративных сетях — Kali Linux предоставляет специалистам по кибербезопасности все необходимые для этого инструменты.
Наиболее полное руководство по этичному взлому и тестированию на проникновение в Kali Linux для новичков и профессионалов.
Привет, Хабр! Меня зовут Динар, я один из разработчиков службы каталогов «Эллес» в ИТ-Холдинге Т1. Кратко о продукте «Эллес», откуда он взялся и что из себя представляет, писал мой коллега. Подробное описание и документацию можете найти на официальном сайте. Но если коротко, то «Эллес» — это служба каталогов (в основе которой лежит глубоко модернизированный код проекта Samba), функционально аналогичная Microsoft Active Directory, с возможностью работы в гетерогенной среде с бесшовной интеграцией и миграцией клиентов.
Привет. Это снова Саша Басун. Я работаю в «Петрович-Тех» инженером направления пользовательских ИТ-сервисов. Моя предыдущая статья про FortiClient VPN нашла отклик, потому я решил рассказать о самых распространённых ошибках при установке или запуске FortiClient VPN.
Итак, обычный будний день. Админу приходит заявка от пользователя, который жалуется, что FortiClient не подключается к серверу. При этом шквала подобных заявок не наблюдается, из-за чего админ делает вывод, что проблема у пользователя локальная.
Он подключается на удалённый компьютер, чтобы провести диагностику. Открыв логи программы, админ понимает, что помимо бутылки тут может потребоваться ещё и тонометр. Всплывающие окна с предупреждениями выглядят хотя бы немного понятнее. О них я вам и расскажу.
Каждый раз при создании новой виртуальной машины проходить через ручную установку ОС, разметку дисков, создание пользователей и прокидывание SSH‑ключей — сомнительное удовольствие, забирающее кучу времени.
К счастью, в Proxmox VE можно один раз потратить 10 минут, настроить правильный «золотой» шаблон с Cloud‑Init и забыть о рутине, раскатывая свежие ВМ буквально в пару кликов. Но тут есть свои подводные камни: от правильного выбора видеоадаптера до хитростей с расширением дискового пространства через qm import.
Как собрать такой идеальный шаблон без лишней боли? Разберем по шагам.
В комментариях к прошлой подборке спросили: «Как понять, где проблема — на сервере или у провайдера?». И вопрос сейчас в целом актуальный, ведь теперь интернет не всегда стабилен, и непонятно, или упал сервер, или лёг канал, или с сетью беды. Эта подборка — про инструменты, которые отвечают на этот вопрос.