Системное администрирование *

OpenTelemetry постепенно становится универсальным пылесосом для телеметрии. Осталось только научить его аккуратно засасывать всё то наследие, которое приложения десятилетиями складывали в файлы. В этом переводе статьи разбирается как использовать filelog receiver на практике — от простого чтения JSON-логов до продакшен-сценариев с настройкой производительности. Ещё больше полезных материалов я публикую у себя в авторском телеграм-канале Мониторим ИТ. Всегда рад новым подписчикам.

Даже в эпоху облачных приложений и распределенного трейсинга обычные файлы логов остаются одним из самых ценных источников достоверной информации в любой системе. От корпоративных приложений и пакетных заданий до NGINX, баз данных и локальной инфраструктуры — критически важная диагностическая информация по-прежнему записывается на диск.

Получатель filelog в OpenTelemetry Collector позволяет интегрировать эти логи в современный конвейер наблюдаемости. Он непрерывно отслеживает файлы, анализирует их содержимое и преобразует необработанный текст в структурированные записи логов OpenTelemetry.

В этой статье показано, как использовать эти возможности на практике, от базового чтения файла до построения готового к эксплуатации конвейера, который корректно обрабатывает ротацию логов, восстанавливает работу после перезапуска и не теряет ни одной строки.

Прежде чем углубляться: если вы контролируете приложения, записывающие эти логи, наилучшим решением будет настроить их на вывод структурированных JSON-логов, размещённых в одной строке. Чтобы получатель filelog в этом случае стал простым и удобным уровнем приема данных.

Значительная часть этой статьи посвящена ситуациям, когда такой вариант невозможен. В подобных случаях получатель filelog предоставляет мощные инструменты для анализа, структурирования и обогащения любых получаемых логов, превращая их в полноценные данные наблюдаемости.

Начнём!

Разбираем сетевые драйверы Docker — bridge, host, overlay, macvlan, ipvlan — DNS, порты и плагины: от основ до продвинутых сценариев.

Есть довольно простой вопрос, который стоит задать ИТ-архитектору: «Что произойдёт, если сервер, на котором расположена служба каталогов, решит прилечь?». Если ответ начинается со слов «ну, вообще-то у нас есть бэкап», это не совсем отказоустойчивая архитектура.

Бэкап помогает восстановить систему. Но он не помогает пользователю войти в корпоративный сервис прямо сейчас.

Поэтому в новой версии MULTIDIRECTORY мы развиваем архитектуру службы каталогов в сторону мультиконтроллерной установки: несколько контроллеров домена, локальные (автономные) копии данных, репликация файлов и балансировка запросов.

В этой статье разберём, что происходит внутри такой системы и почему поставить второй сервер — ещё не значит получить отказоустойчивое решение.

У каждого, кто работает с Kubernetes, рано или поздно возникает потребность «посмотреть на кластер глазами»: кто с кем связан, почему под в CrashLoopBackOff, что изменилось за ночь, какие сертификаты истекают. Вариантов обычно два — Kubernetes Dashboard (слишком бедный) или Lens / Headlamp (десктопное приложение или тяжёлый стек с зависимостями). А kubectl-специалисты откапывают причины инцидентов в простынях YAML, где сигнал тонет в managedFields и status.conditions.

Radar — open-source UI для Kubernetes от Skyhook (YC W23). Один бинарник на Go, без регистрации и аккаунта, бесплатный навсегда. Топология кластера, браузер ресурсов, timeline событий, менеджер Helm-релизов, GitOps для FluxCD, карта трафика, аудит безопасности, анализ impact'а перед апгрейдом K8s и даже встроенный MCP-сервер, чтобы ИИ-агенты могли смотреть кластер глазами Radar вместо сырого kubectl.

В этой статье мы развернём Radar в Yandex Managed Kubernetes через Helm — с ingress-nginx и доменом из публичного IP — и разберём все основные экраны. Разворачиваемый инстанс — общий для команды разработчиков, поэтому конфигурация строго read-only: все write-права выключены, ИИ-агенты подключаются к read-only MCP.

UFW показывает DENY, а контейнер отвечает снаружи за 130 миллисекунд. Разбираю на стенде, почему файрвол тут ни при чём, почему популярный совет с правилом в DOCKER-USER не работает, и что об этом написано в документации Docker.

Это статья будет в большой степени для обычных пользователей интернета, но так же и для владельцев и разработчиков (в конце будут решения), Вы поймете почему у Вас не открываются определенные легитимные сайты и что делать.

Я не программист, не девопс и не системный администратор. По диплому — недоучившийся инженер-энергетик, программировать учился сам по учебникам, команды никогда не было. При этом у меня выросли два сервера, полсотни виртуалок и десяток микросервисов. В ночь на четвёртое июня всё это едва не закончилось: кто-то зашёл на резервный сервер и снёс двадцать две виртуальные машины вместе с дисками примерно за десять минут. Разбираю по шагам, где именно я оставил дверь открытой.

Всё началось с желания организовать и автоматизировать работу с Terraform, впоследствии с Terragrunt, выстроить управляемый процесс, централизовать, настроить понятный RBAC, в общем, сделать так, «чтобы было красиво». Было сделано несколько подходов, и были рассмотрены разные варианты. Отправной точкой стало структурирование кода, его декомпозиция и рефакторинг, и постепенно дошло до автоматизации самого процесса применения (или просто plan/apply). К этому моменту основная часть кода сконцентрировалась в монорепозитории в self-hosted GitLab, общая и повторяемая логика отделилась во внутренние приватные модули, а сам код вырос в объёмах: более 4 000 .tf файлов, не учитывая внешних и внутренних модулей, более 900 проектов (каталогов), более 30 000 ресурсов, более 30 уникальных провайдеров Terraform. Конечно, все эти условия в той или иной степени повлияли на конечный выбор.

В этой статье расскажу, как мы перешли от ручного управления Terraform и Terragrunt к автоматизированному процессу на базе Atlantis, какие альтернативы рассматривали, почему выбрали именно Atlantis и с какими неочевидными особенностями столкнулись при его эксплуатации.

Привет, Хабр! Меня зовут Денис Корбаков, я технический директор «Смарт-Софт». Мы разрабатываем NGFW и регулярно разбираем, какие сетевые события можно использовать для независимого контроля автоматизированных систем. Последний год эта задача резко усложнилась. В инфраструктуре массово появился новый операционный тип машинного субъекта: автономный агент, который сам выбирает инструменты, меняет контекст и делегирует полномочия.

Zero Trust никогда не ограничивался только людьми. NIST SP 800-207 прямо включает в модель non-person entities: сервисы, приложения, автоматизированное ПО, и обсуждает их ещё с версии 2020 года. Субъект как класс не новый, новыми являются масштаб, автономность и модель поведения. Большинство корпоративных реализаций IAM на практике заточены либо под человека с интерактивной сессией, либо под стабильный сервисный аккаунт, который работает годами с предсказуемым поведением. ИИ-агент находится между этими моделями: не человек, способный самостоятельно оценить допустимый объём своих полномочий, и не полностью статичный сервис с неизменным поведением. Как отмечает исследование Cloud Security Alliance, проведённое при поддержке Aembit, существующие подходы к IAM испытывают нагрузку, на которую изначально не проектировались.

Современные жилые комплексы сложно представить без умных цифровых решений. Но по состоянию на 2026 год многие цифровые системы в новостройках перестают полноценно работать уже через несколько лет после ввода дома в эксплуатацию. Часть функций отключается, отдельные сервисы становятся недоступны, данные перестают обновляться. 

Собрал причины, по которым система умного дома начинает буксовать вскоре после ввода в эксплуатацию. Расскажу, как на это влияет маркетинг строительных объектов и почему бытовые гаджеты с AliExpress и других маркетплейсов не заменяют промышленные решения. А также предложу свой взгляд с точки зрения эксперта-практика, принимавшего участие в реализации 50+ проектов умного дома,  как добиться от системы  такой устойчивости, чтобы и через 10-20 лет все работало, как в первый день. 

Полчаса паники, десяток дашбордов и один вопрос без ответа: что вообще происходит. Именно столько в среднем уходит на то, чтобы просто подтвердить инцидент, пока дежурный инженер не поймёт, что горит.

DevOps-инженер Сергей Тимиряев решил эту проблему сам, без вендоров и бюджетов: за полгода в одиночку собрал ИИ-агента, который проходит весь этот путь за секунды и присылает готовую гипотезу причины прямо в Telegram. Промпт у него всего 14 строк, а две недели непрерывной работы стенда обошлись в 20%.

Как это устроено внутри, что случилось на демо с живым кластером и почему агенту намеренно не дали прав хоть что-то сломать в проде, рассказываем в конспекте с первого занятия «Вечерней школы. ИИ для инженеров» от Слёрма.

SDS-кластер, собранный на глазок и прошедший приёмочные тесты, вполне может проработать полгода без единой жалобы, а потом упереться в стену. Причина обычно в том, что при проектировании никто не подумал об эксплуатации на годы вперёд — не заложили рост по узлам, памяти или сети, и нагрузка уперлась в архитектурный лимит, который без остановки и миграции не раздвинуть.

Большинство таких проблем можно предсказать и предотвратить ещё на этапе проектирования — об этом статья: как выбрать архитектуру для кластеров MIND uStor, посчитать ресурсы сервера, спроектировать сеть и настроить кластер так, чтобы он держал нагрузку предсказуемо и переживал отказы без драмы. Материал написан для инженеров, которые проектируют или сопровождают такие кластеры.

Привет! Сразу признаюсь, я — гуманитарий. Уже лет двадцать работаю в IT, притворяясь своим среди хардкорных технарей. Людей, которые писали на Фортране и Бейсике, пережили диалап и вспоминают «3dfx» с лёгкой ностальгией. 

Мой максимум — навайбкодить какой‑нибудь скрипт для аналитики. Для гуманитариев это звучит страшно, потому что ничего не понятно. Для IT‑специалистов — страшно, потому что всё со мной понятно. 

Меня до сих пор не раскрыли только потому, что айтишники обычно смотрят в монитор, а не друг на друга. Зато наблюдать за ними невероятно интересно. Благодаря подлой гуманитарной сущности я смог оформить эти наблюдения в рассказ о жизни удивительного биологического вида Informaticus vulgaris, он же «айтишник обыкновенный». 

Рассказ буду вести от первого лица. Все совпадения случайны, как бы вы не пытались доказать обратное.

Документация Яндекс 360 API на 20 августа 2026 года перечисляет 17 сервисов, и раздела о вебхуках или подписке на события среди них нет; аудит-лог организации документирует 26 типов событий — двенадцать почтовых и четырнадцать дисковых. Кадровых и оргструктурных событий не документировано ни одного. Разбираю, что из этого следует тем, кто строит провижининг: чем располагает UserService_List для поллинга, почему isDismissed нельзя записать и что документация обещает при создании пользователя с занятым логином.

Зелёный пайплайн ещё не означает, что деплой прошёл как надо. В Bash хватает ситуаций, где ошибка теряется, код возврата маскируется, а скрипт спокойно идёт дальше. Разберём типичные ловушки и способы сделать такие сценарии предсказуемее.

Разбираемся, что за зверь хранит весь ваш Kubernetes, учимся читать его ошибки и честно отвечаем на вопрос, можно ли ему доверять.

Вопрос, который я задал себе и своей команде: что произойдёт, если по одному сотруднику из кадровой системы прилетят два запроса на входящий вебхук? Ответ у меня есть с 20 августа 2026 года, и он укладывается в строку: два независимых запуска, движок их между собой не связывает, ключа дедупликации нет. Ниже — что из этого следует тому, кто прямо сейчас рисует схему обмена 1С с облачным офисом.

Компанию +Альянс основал я. Руковожу ею тоже я, а по существу занимаюсь одним: тем, чтобы кадровое решение доезжало до облачного офиса без человека посередине. Инструменты в тексте остаются безымянными, и наши, и сторонние: речь про требования к приёмнику входящих запросов. Яндекс 360 упомянут как платформа, на которой живут учётные записи, и как источник, который читатель откроет сам.

Сразу про слабое место текста. Всё, что сказано ниже про поведение движка автоматизации, — моя собственная фиксация ответов, а не публичный документ, на который можно дать ссылку. Проверить это можно только на стенде, поэтому такие утверждения я даю вместе с процедурой проверки. Зато про саму платформу есть открытая документация, и на неё я опираюсь дословно. Даты такие. Каталог триггеров и действий зафиксирован 30 июля 2026, история запусков 3 августа, контракт вебхука 20 августа, страницы документации Яндекс 360 API сверены тоже 20 августа 2026.

Привет, Хабр! В работе почти каждого, кто плотно сидит в Linux, есть один недостаток: одни и те же команды забываются с завидной регулярностью. Я, например, иногда по десять раз лезу в историю, чтобы уточнить - «так как в rsync директорию исключить, но структуру оставить?»

Можно, конечно, вести свои заметки. Можно - дрессировать Ctrl+R. А можно установить небольшую утилиту, которая будет жить в трее и выдавать нужную подсказку за полсекунды. Именно о такой утилите сегодня и расскажу - DevToolbox Cheats.

Любые серьёзные изменения инфраструктуры начинаются с одного вопроса: что именно у нас есть сейчас?

На первый взгляд ответ кажется очевидным. Есть схемы, таблицы, выгрузки из систем мониторинга, описания стоек и списки оборудования. Но когда дело доходит до переезда  или модернизации площадок, часто оказывается, что единой и актуальной картины инфраструктуры нет.

За последние годы мы участвовали в нескольких проектах по переносу оборудования — от перемещения отдельных стоек внутри дата-центра до миграции инфраструктуры между площадками. Масштаб проектов отличался, но первая проблема практически всегда была одинаковой.

Документация существует, но её актуальность вызывает вопросы. В одном документе устройство называется одним образом, в другом — другим, а на самой стойке используется третье обозначение. В таблице порт отмечен как свободный, хотя в него включён рабочий линк. На схеме uplink уходит в один коммутатор, а LLDP показывает другой. Какие-то подключения давно не используются, но продолжают числиться в документации. Какие-то, наоборот, работают много месяцев и нигде не описаны.

CTE в PostgreSQL упрощают код, но могут снижать производительность. Разбираем 4 антипаттерна, примеры EXPLAIN ANALYZE и практические способы оптимизации.

В прошлой статье мы упоминали основные SQL‑антипаттерны, способные замедлять работу базы данных. Продолжаем тему — на этот раз про CTE. 

Common Table Expressions (CTE), или конструкции WITH, — привычный инструмент SQL-разработчика. Чем сложнее запрос, тем выше шанс встретить в нём WITH: код становится чище, а запутанная логика разбивается на понятные блоки. CTE используют как альтернативу вложенным запросам и временным таблицам. Однако за внешней простотой и читаемостью скрываются риски снижения производительности, которые не всегда удаётся предвидеть.

Такие запросы на первый взгляд выглядят правильными, но работают неэффективно, и проблема вылезает только в EXPLAIN ANALYZE (инструмент разбирали в прошлом гайде). Разберём четыре антипаттерна CTE, посмотрим планы выполнения и покажем, как переписать запрос. В конце — короткий чек-лист диагностики.

Эта статья может быть полезна начинающим разработчикам и аналитикам, которые уже полюбили синтаксис CTE, но хотят понять, что на самом деле происходит «под капотом» в PostgreSQL.