Самый худший способ сбора метрик в сервисе

Когда только начинал погружаться в observability, то любил нафигачить побольше метрик:

* метрика на число запросов к БД
* отдельно метрика на ошибку парсинга ответа от БД
* отдельно метрика на ошибку коннекта к БД
* …

В общем, на каждую ошибку делал свою метрику

И ЭТО ФИГОВО СЕБЯ ПОКАЗАЛО!

* код разрастался нереально
* алерты плодились как не в себя
* и т. д.

Но потом до меня дошло простое правило: метрика говорит, где примерно сломалось, а что именно сломалось, можно посмотреть в логах

Например:

* завести метрику на число ошибочных запросов к БД
* и отдельно метрику на число успешных запросов к БД

А когда прилетит алерт, смотреть по ЛОГАМ, ЧТО ИМЕННО это была за ошибка с БД

P.S. А кому хочется поглубже, можно посмотреть на такие практики организации метрик:

* Four Golden Signals (Google SRE Book) - latency, traffic, errors, saturation
* RED - Rate, Errors, Duration. Для сервисов хорошо подходит
* USE (Brendan Gregg) - Utilization, Saturation, Errors. Для ресурсов: CPU и других

И бахни 🌭, если уже успел нафигачить мусорных метрик в своем сервисе