При анализе артефактов с Linux систем journal являются источником огромного количества полезной информации. Из журналов можно достать:

🚀 название машины;

🚀 идентификатор события;

🚀 тип события;

🚀 критичность события;

🚀 сообщение;

🚀 объект породивший событие;

🚀 и многое другое.

Существует множество утилит которые позволяют парсить журналы:

🚀 встроенный во многие дистрибутивы linux journalctl;

🚀 кроссплатформенный go-journalctl от Velocidex;

🚀 библиотека go-systemd;

🚀 и т.д.

Однако, у всех этих утилит есть свои минусы. Так go-systemd и journalctl не имеют встроенной кроссплатформенности, а go-journalctl не может парсить все файлы находящиеся в директории рекурсивно.

Нашему веб-серверу Angie исполнилось три года. Становится хорошей традицией, что к этой дате выходит текст, в котором мы — основатели Angie Software — описываем, как прожили последний год, немного говорим про состояние опенсорс проекта и его места в отрасли и мире. Надеемся, что и в этой простыне вы найдете для себя много чего интересного.

В прошлом году текст «Два года Angie», кажется, вам понравился. В нем мы более-менее подробно писали о том, как именно создавалась компания Angie Software, почему вообще мы стартовали с опенсорса, какую роль в появлении Angie сыграли китайские товарищи, и как мы, сообразив, что заработать на опенсорс проекте мы не можем, стремительно переобулись в сторону производства целой линейки продуктов. Ну и еще немного плевались в сторону F5, которая вымарала наших коллег из истории Nginx. Кому интересно, как все начиналось, почитайте.

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

Наверняка у вас тоже было такое, что сервис работает себе спокойно, радует пользователей своей стабильностью и производительностью, а вас — зелёным мониторингом. А в следующий момент хлоп — и нет его. Вы в панике смотрите в логи ошибок, а там или невнятный сегфолт, или просто ничего. Что делать — непонятно, и вообще надо прод спасать, поэтому вы поднимаете его обратно, и всё работает как раньше. Поначалу вы пытаетесь разобраться в причинах случившегося, но со временем переключаетесь на другие задачи, а этот случай отходит на дальний план или вообще забывается.

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

Для многих администраторов Linux одна пара SSH-ключей используется по умолчанию для входа на каждый сервер, staging-окружение или облачный инстанс, которым они владеют. Это просто, удобно — и является единой точкой отказа.

Иногда самые опасные угрозы — это не атаки методом перебора или уязвимости нулевого дня. Это тихие, настойчивые точки закрепления, скрывающиеся из виду. Однажды я обнаружил reverse shell, незаметно работавший под пользователем www-data на моем веб-сервере Ubuntu. Вот как я ее обнаружил — и какие именно шаги предпринял для ее удаления.

Наш API был медленным. Не сломанным — просто медленным.

Таким медленным, из-за которого пользователи обновляют страницу. Таким, из-за которого телефон кажется старым. У нас была задержка 200 мс на эндпоинтах, которые должны были отвечать за 40 мс. Каждая оптимизация, которую мы пробовали, делала всё только хуже. Затем я удалил большую часть нашей конфигурации Kubernetes. Задержка снизилась до 35 мс.

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

Один из самых простых и удобных в обслуживании путей — переход от традиционных ресурсов Ingress к Gateway API, современному стандарту сетевого взаимодействия в Kubernetes. Для упрощения этого процесса сообщество Kubernetes SIG Network предоставляет инструмент ingress2gateway с открытым исходным кодом, который автоматически преобразует объекты Ingress в ресурсы Gateway API.

Теперь Postgresus — это Databasus. И поддерживает другие базы: MySQL, MariaDB и MongoDB (при этом оставляя основной фокус на PostgreSQL).