Alert Operator: Cloud-Native решение для простой настройки сложных алертов

Как и во всех серьезных компаниях, у нас на каждую возможную неисправность настроен какой-нибудь алерт.

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

Основных проблемы мы видели две:
1. Огромные портянки Prometheus Alerting Rules, в которых черт ногу сломит, и которые бездумно дублируются в десятках разных репозиториев и сотнях кластеров
2. Никакой унификации и единого понимания, что именно нужно отслеживать, и на каких порогах алертить
3. Ну и конечно же лень, забывчивость и безответственность, куда без них.

Мы придумали и разработали свое решение на базе Operator SDK, с которым решаются хотя бы первые две проблемы, а через них немного улучшили ситуацию с третьей.

На докладе мы вместе с Евгением Баулиным (техлид и Java-разработчик) расскажем, как мы формировали спецификацию CRD, с какими подводными камнями столкнулись при разработке оператора, как шаблонизировали алерты, чтобы разработчик или инженер мог настроить все необходимые (и не очень) алерты, используя Kubernetes-ресурс со спецификацией в десяток строк.