Рубрика «monitoring»

Две сцены, которые видел в разных компаниях в последний год.

Сцена первая. На стене в кабинете директора по ИТ висит большой телек, на нём дашборд: «Availability 99.83%», зелёные плашки, всё хорошо. В этот же момент этажом ниже бухгалтерия пишет в поддержку: «1С зависла, не можем закрыть смену». Дашборд не врёт — 99.83% хостов реально доступны. Просто из этих хостов 78 — тестовые стенды, 12 — резервные узлы, и ещё пачка в SCADA-сегменте, который вообще про другое.

Сцена вторая.Читать полностью »

Зачем вообще отдельный мониторинг поверх Proxmox

Полчаса в день у меня уходило на ручной обход шести нод Proxmox через веб-интерфейс — он показывает по одной ноде за раз. И часть рутины всё равно проскакивала: задание PBS остановилось — никто не заметил, ZFS scrub отключили на maintenance и забыли включить, на ноде накопились pending kernel updates, и о них узнаёшь, когда уже надо ребутить. На небольшом кластере ручного обхода хватает. На кластере из шести нод с парой сотен виртуалок и контейнеров — уже нет.

Читать полностью »

В современных Data-driven компаниях Kafka называют «центральной нервной системой» данных. Но даже идеально настроенный кластер может стать причиной Data Loss, если конфигурация инфраструктуры не синхронизирована с реальностью бизнес-потоков. В этой статье я поделюсь кейсом из практики Platform Engineer: как неочевидный конфликт настроек приводил к потерям данных и как я решил это, внедрив метрику «Data Safety Window».

Проблема: «Дырки» в данных при плановых работах

Читать полностью »

Нет повести печальнее на свете, чем повесть о лежачем алерте.

Колобок-стек: я от бабушки ушёл, или как мы написали свой сервер алертов на 16 МБ - 1

PuskЧитать полностью »

Привет! В данной статье хотел бы раскрыть тему - почему на 'младших' стендах api работает стабильно, но в проде начинаются проблемы: рост памяти, кол-во горутин множится, и через несколько часов - просадка производительности, gc не справляется, out of memory killer и т. д.

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

Что внутри

Разобьем на несколько частей, в 1-ой части:

OpenTelemetry — не то, чем кажется… - 1

Привет! Меня зовут - Евгений, работаю в финтехе и проектирую системы, которые обрабатывают миллионы запросов, интегрируются с десятками внешних сервисов и живут в Kubernetes. А еще я преподаю Java/Spring Boot и рассказываю студентам, как не наступать на чужие грабли, а создавать свои и прыгать на них.

Читать полностью »

Всем привет! Меня, как и многих здесь, в какой-то момент достало. Достало логиниться по SSH, чтобы проверить htop. Достало запускать Termius на телефоне, чтобы сделать sudo reboot зависшему инстансу. Достало ставить тяжелые веб-панели, которые жрут ресурсы и открывают лишний порт, только ради того, чтобы посмотреть загрузку диска.

Я админю VPS. Мне нужен был инструмент, который:

  1. Мгновенно даёт сводку по системе.

  2. Работает легковесно, не отъедая ресурсы.

  3. Безопасен (никаких "запусти_от_рута_в_один_пайп").

  4. Надёжен, как швейцарские часы (и не спамит алертами).

  5. Читать полностью »

Чернокнижки из AWS обнаружили павший US-EAST-1

Чернокнижки из AWS обнаружили павший US-EAST-1

Мрачным утром 20 октября 2025 года мониторинг AWS был краснее некуда, его залило кровью сервисов. Пал крупнейший и по совместительству старейший регион, обрабатывающий 35–40% всего глобального трафика AWS — US-EAST-1Читать полностью »

1. Вступление

Я работаю в одном крупном российском банке, где занимаюсь разработкой распределённых систем. За последние несколько лет наша архитектура заметно усложнилась — часть сервисов работает в OpenShift, часть на виртуалках, а кое-что до сих пор крутится на «железе».

Читать полностью »

Горящие релизы и ночные дежурства: мой персональный ад

Когда я пришёл на проект, всё было похоже на нескончаемый пожар. В продакшене сыпались алерты один за другим, CI/CD-пайплайны (GitLab и Jenkins) постоянно фейлили, а релизы проходили хаотично — каждый новый билд мог «уложить» сервис. Я пил кофе в три ночи, когда прозвучал очередной звонок на мобильник: «сервис упал — немедленно разбирайся!». MTTR (Mean Time To Recovery)Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js