#opensearch #kubernetes #troubleshooting #одинденьизжизни "Алекс, у нас пропали логи. Но только на стейдже." Иду смотреть. Куб живой, метрики зелёные, поды в норме, а в OpenSearch тишина. Ни одного алёрта. Ладно. Пошёл проверять по классике: - не упал ли агент сбора логов - не отвалились ли права - не умер ли endpoint - не сломали ли что-то свежими коммитами Первый заход: Никаких коммитов, которые могли это поломать нет. Ок, идём в куб. kubectl get ds -n kube-system fluent-bit живой, все реплики Ready kubectl get pods -n kube-system | grep fluent-bit всё раннит kubectl logs -n kube-system daemonset/fluent-bit --since=30m И вот там уже не тишина. В логах: - validation_exception - this action would add [4] total shards - cluster currently has [1000]/[1000] maximum shards open Красота. Значит не "логов нет", а "логгер не может писать". Дальше мысль идёт так: куб живой, агенты живые, опенсёрч живой, с pvc всё ок. но если шардов в потолок, значит retention не чистит старые индексы.🤔 И тут флешбек: несколько месяцев назад мигрировали с filebeat на fluent-bit. Индексный префикс поменяли. Ну там было нечто типа eks-filebeat- на eks-fluentbit-, не помню уже. А retention policy, как это обычно бывает в суровой реальности, осталась смотреть на старое имя индекса ☔️. Итог: - новые индексы копились - старые правила их не трогали - шардов стало 1000/1000 - OpenSearch начал отвечать 400 на bulk insert - fluent-bit ретраил, потом сдавался - в UI ощущение, что "логи пропали только на stage" То есть виноват не новый деплой, не "вчерашний коммит", не магия. Просто policy смотрела не туда. И да, жаль, что эта policy была не в IaC, а когда-то сделана руками в консоли. Именно поэтому при миграции её и проглядели. Что проверил и что сработало: - поправил index pattern в retention/ISM policy на актуальный префикс - подчистил лишние старые индексы вручную (DELETE /indexname* предыдущих лет/месяцев) - освободились шарды - проверил повторно логи fluent-bit -> ошибки по maximum shards open ушли - в OpenSearch новые логи снова пошли Короткий вывод: - миграция агента логирования = почти всегда миграция index naming - если не обновить retention под новый pattern, инцидент это вопрос времени - всё, что не в IaC, рано или поздно теряется в памяти любой команды - алерт на долю открытых шардов нужен заранее (80-85%), а не в момент 1000/1000 (а алёрта и не было) Постмортем одной строкой: Логи не пропали. Мы сами забили OpenSearch старыми индексами, потому что retention policy жила в прошлом и смотрела на имя эпохи filebeat.