Если вы держите on‑prem кластер на десятки или сотни нод, дальше можно не объяснять. Обновили CNI, или ядро, или драйвер сетевой карты, или просто переехали частью нод в новый сегмент. Проходит какое‑то время, и начинают капать тикеты: «у нас иногда таймаутит между подами», «DNS иногда не резолвится», «health‑check то падает, то нет».
Всем привет! Хотел бы поговорить о мониторинге наших web, да и не только web, приложений, в первую очередь, о проблемах, с которыми мы сталкиваемся. В этой статье я буду использовать язык python и популярные сервисы, чтобы содержимое было максимально понятно большинству.
К примеру, мы написали простой проект, ставить Prometheus с Grafana ради одной машины скорее избыточно, поэтому мы используем что‑то типо этого:
curl -sf https://example.com/ >/dev/null ||
curl -s "https://api.telegram.org/bot$TOKEN/sendMessage"
-d chat_id=$CHAT_ID -d text="Сайт лежит"Стандартная (для многих) история. Отдаём какие‑то данные в реальном времени через server‑side web‑gRPC стримы. Цепочка: балансировщик, дальше Envoy с grpc‑web, дальше бэкенд.
Все проверки зелёные: TCP поднят, хендшейк проходит, /healthz отвечает 200, в графане/slack'e тишина. А фронтенд у клиентов замёрз. И узнали мы об этом от клиентов, а не от мониторинга.
Две сцены, которые видел в разных компаниях в последний год.
Сцена первая. На стене в кабинете директора по ИТ висит большой телек, на нём дашборд: «Availability 99.83%», зелёные плашки, всё хорошо. В этот же момент этажом ниже бухгалтерия пишет в поддержку: «1С зависла, не можем закрыть смену». Дашборд не врёт — 99.83% хостов реально доступны. Просто из этих хостов 78 — тестовые стенды, 12 — резервные узлы, и ещё пачка в SCADA-сегменте, который вообще про другое.
Сцена вторая.Читать полностью »
Полчаса в день у меня уходило на ручной обход шести нод Proxmox через веб-интерфейс — он показывает по одной ноде за раз. И часть рутины всё равно проскакивала: задание PBS остановилось — никто не заметил, ZFS scrub отключили на maintenance и забыли включить, на ноде накопились pending kernel updates, и о них узнаёшь, когда уже надо ребутить. На небольшом кластере ручного обхода хватает. На кластере из шести нод с парой сотен виртуалок и контейнеров — уже нет.
В современных Data-driven компаниях Kafka называют «центральной нервной системой» данных. Но даже идеально настроенный кластер может стать причиной Data Loss, если конфигурация инфраструктуры не синхронизирована с реальностью бизнес-потоков. В этой статье я поделюсь кейсом из практики Platform Engineer: как неочевидный конфликт настроек приводил к потерям данных и как я решил это, внедрив метрику «Data Safety Window».
Привет! В данной статье хотел бы раскрыть тему - почему на 'младших' стендах api работает стабильно, но в проде начинаются проблемы: рост памяти, кол-во горутин множится, и через несколько часов - просадка производительности, gc не справляется, out of memory killer и т. д.
Давайте разберемся, что разработчику может помочь, чтобы он мог спать спокойно после деплоя своего решения. Попробуем детально разобраться в природе утечек ресурсов, научимся находить их с помощью профилировщиков и построим систему защиты от самых распространённых паттернов утечек.
Разобьем на несколько частей, в 1-ой части:
Привет! Меня зовут - Евгений, работаю в финтехе и проектирую системы, которые обрабатывают миллионы запросов, интегрируются с десятками внешних сервисов и живут в Kubernetes. А еще я преподаю Java/Spring Boot и рассказываю студентам, как не наступать на чужие грабли, а создавать свои и прыгать на них.
Всем привет! Меня, как и многих здесь, в какой-то момент достало. Достало логиниться по SSH, чтобы проверить htop. Достало запускать Termius на телефоне, чтобы сделать sudo reboot зависшему инстансу. Достало ставить тяжелые веб-панели, которые жрут ресурсы и открывают лишний порт, только ради того, чтобы посмотреть загрузку диска.
Я админю VPS. Мне нужен был инструмент, который:
Мгновенно даёт сводку по системе.
Работает легковесно, не отъедая ресурсы.
Безопасен (никаких "запусти_от_рута_в_один_пайп").
Надёжен, как швейцарские часы (и не спамит алертами).
