Когда я впервые открыл счёт за наблюдаемость в конце квартала, я долго проверял, не перепутала ли бухгалтерия периоды. Вычисления, база, трафик и балансировщик вместе стоили меньше, чем три сервиса, которые отвечали за метрики, логи и трейсы. Отдельной графы под сбор телеметрии в моём бюджете не было никогда, и совершенно напрасно: именно она тихо выросла в главную статью расходов.
Началось всё с метрик, и это самая коварная часть. Пока ты пишешь в лейблы имя сервиса и статус ответа, всё выглядит невинно. Но стоит добавить туда идентификатор пользователя, идентификатор запроса или путь с параметрами, как одна метрика превращается в миллионы уникальных временных рядов. Каждый ряд стоит денег: его надо принять, проиндексировать, сохранить и уметь по нему быстро отвечать. У меня был случай, когда одна забытая гистограмма с лейблом по номеру заказа давала больше нагрузки, чем все остальные метрики проекта вместе взятые.
С логами история проще и от этого больнее. Логи растут линейно вместе с трафиком, и никакая разумная архитектура это не отменяет. Причина обычно одна: в прод уезжает уровень отладки, потому что так удобнее разбираться с инцидентами. Второй источник — запись полных тел запросов и ответов, где в одной строке на сотни килобайт лежит всё сразу, включая то, что логировать вообще не следовало.
Трейсы добавляют третью часть счёта, и тут я долго не мог понять, почему они обходятся так дорого, пока не увидел, что хранение самих спанов почти ничего не стоит по сравнению с их индексацией и возможностью поиска по любым полям. Дело не в том, что данные занимают место, а в том, что ты платишь за скорость ответа на вопрос, который задаёшь раз в месяц. И ещё отдельная строка расходов на то, что логи и метрики надо куда-то вывозить, дублировать в холодное хранилище и держать там годами на всякий случай.
Когда я сложил всё вместе, картина оказалась неожиданной: наблюдаемость обгоняла облако не потому, что была дороже по своей природе, а потому, что росла быстрее и незаметнее. Инстансы я видел каждый день в панели и понимал, что там происходит. А рост числа временных рядов и объёма логов никак не бросался в глаза до момента, когда приходит счёт.
Что реально помогло мне навести порядок. Первое — я ввёл правило и стал его соблюдать: любой новый лейбл в метрике проходит через ревью, как код, а идентификаторы пользователей и запросов туда не попадают никогда. Второе — перевёл отладочные логи на включение по требованию и убрал тела запросов из записи. Третье — включил выборку трейсов: сначала небольшую долю, потом подстроил её под реальность. Четвёртое, самое скучное и самое действенное, — назначил одного человека, который раз в месяц смотрит на график расходов и объёмов и задаёт неудобные вопросы.
Читателям, которые сейчас строят свою систему наблюдаемости или уже получили неприятный счёт, я бы посоветовал несколько простых вещей. Относитесь к телеметрии как к продукту с бюджетом и владельцем, а не как к бесплатному побочному эффекту работы сервисов. Заведите алерт не только на падение сервиса, но и на рост расходов и объёма данных. Договоритесь о сроках хранения отдельно для метрик, логов и трейсов, потому что это совершенно разные истории с разной ценой ошибки. И честно ответьте себе, что вы реально ищете в старых логах: если ничего, то хранить их вечно незачем.
При этом я не считаю, что наблюдаемость — это зло, на котором стоит экономить своё спокойствие. После инцидента, который нашёлся за пятнадцать минут вместо трёх часов, моё отношение к этим расходам стало куда более взвешенным. Просто у любого инструмента есть цена, и её полезно знать заранее, а не узнавать из письма от финансового отдела. А как у вас обстоят дела: что в вашем бюджете оказалось самым неожиданным — метрики, логи, трейсы или что-то совсем другое?
Началось всё с метрик, и это самая коварная часть. Пока ты пишешь в лейблы имя сервиса и статус ответа, всё выглядит невинно. Но стоит добавить туда идентификатор пользователя, идентификатор запроса или путь с параметрами, как одна метрика превращается в миллионы уникальных временных рядов. Каждый ряд стоит денег: его надо принять, проиндексировать, сохранить и уметь по нему быстро отвечать. У меня был случай, когда одна забытая гистограмма с лейблом по номеру заказа давала больше нагрузки, чем все остальные метрики проекта вместе взятые.
С логами история проще и от этого больнее. Логи растут линейно вместе с трафиком, и никакая разумная архитектура это не отменяет. Причина обычно одна: в прод уезжает уровень отладки, потому что так удобнее разбираться с инцидентами. Второй источник — запись полных тел запросов и ответов, где в одной строке на сотни килобайт лежит всё сразу, включая то, что логировать вообще не следовало.
Трейсы добавляют третью часть счёта, и тут я долго не мог понять, почему они обходятся так дорого, пока не увидел, что хранение самих спанов почти ничего не стоит по сравнению с их индексацией и возможностью поиска по любым полям. Дело не в том, что данные занимают место, а в том, что ты платишь за скорость ответа на вопрос, который задаёшь раз в месяц. И ещё отдельная строка расходов на то, что логи и метрики надо куда-то вывозить, дублировать в холодное хранилище и держать там годами на всякий случай.
Когда я сложил всё вместе, картина оказалась неожиданной: наблюдаемость обгоняла облако не потому, что была дороже по своей природе, а потому, что росла быстрее и незаметнее. Инстансы я видел каждый день в панели и понимал, что там происходит. А рост числа временных рядов и объёма логов никак не бросался в глаза до момента, когда приходит счёт.
Что реально помогло мне навести порядок. Первое — я ввёл правило и стал его соблюдать: любой новый лейбл в метрике проходит через ревью, как код, а идентификаторы пользователей и запросов туда не попадают никогда. Второе — перевёл отладочные логи на включение по требованию и убрал тела запросов из записи. Третье — включил выборку трейсов: сначала небольшую долю, потом подстроил её под реальность. Четвёртое, самое скучное и самое действенное, — назначил одного человека, который раз в месяц смотрит на график расходов и объёмов и задаёт неудобные вопросы.
Читателям, которые сейчас строят свою систему наблюдаемости или уже получили неприятный счёт, я бы посоветовал несколько простых вещей. Относитесь к телеметрии как к продукту с бюджетом и владельцем, а не как к бесплатному побочному эффекту работы сервисов. Заведите алерт не только на падение сервиса, но и на рост расходов и объёма данных. Договоритесь о сроках хранения отдельно для метрик, логов и трейсов, потому что это совершенно разные истории с разной ценой ошибки. И честно ответьте себе, что вы реально ищете в старых логах: если ничего, то хранить их вечно незачем.
При этом я не считаю, что наблюдаемость — это зло, на котором стоит экономить своё спокойствие. После инцидента, который нашёлся за пятнадцать минут вместо трёх часов, моё отношение к этим расходам стало куда более взвешенным. Просто у любого инструмента есть цена, и её полезно знать заранее, а не узнавать из письма от финансового отдела. А как у вас обстоят дела: что в вашем бюджете оказалось самым неожиданным — метрики, логи, трейсы или что-то совсем другое?