DevOps спільнота

Дякую вам, по ресурсам документація AWS але для вивчення краще практика з безкоштовними сервісами AWS

ну вот по фотографии — тоже самое. У них судя по доке, тоже включен префетч — соотвественно был бы такой же queue poisoning

Теоретически — да. Практически — вот до сих пор слішал только теоретические рассуждения :)

ага. тут замечать как бы такое — сервисов 200+. Тут не замечать надо, а ставить нотификацию. Ее не стояло

Дякую за статтю, доволі цікаво і корисно. Було б цікаво, якби Ви ще поділилися самими корисними ресурасами, які допомогли вивчати з aws.

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

Команды не рождаются со всей необходимой экспертизой 🙂

Это часто считают антипаттерном. И в этом случае вряд ли помогло бы, потому что сервис крешился с OOMKilled. Обычно это детектися и решается алертами на K8s events.

Залежить від того, як той аларм задефайнений: Могли вибрати якусь банальну метрику і вікно відпрацювання тригера було занадто широким: В ідеалі, повинен був бути задефайнений хелз чек, який би включав у себе перевірку доступу до усіх зовнішніх застосунків...

Є простіше рішення. Якщо система ще в активній розробці і є супорт інженери — не включати «container restart». Тоді при падінні ви зразу знаєте де проблема.

Большой вопрос к команде, которая ответственна за рестартующий сервис. Обычно должен к ним прилетать алерт, что сервис unhealthy.

Цікаво, але «такое». Тобто у вас один із сервісів знаходився у постійному циклі народження-смерті не встигаючи навіть працювати, але ви цього не помічали поки меседж брокер не всрався )

Цікаво шо було б якби замість RMQ був SQS.

А що це за порт на 200 Мбіт?

Захопливо!