Оригинал: Debunking the ‘Three Pillars of Observability’ Myth by Ben Sigelman
Вы уже слышали о «трёх столпах наблюдаемости»? Нет? История такова:
Если вы используете микросервисы, то уже знаете, что их практически невозможно понять с помощью обычных инструментов мониторинга: поскольку микросервисы были буквально разработаны для того, чтобы команды DevOps, работающие по принципу «две пиццы», не знали друг о друге, оказывается, что любому человеку невероятно сложно понять всю картину или даже своего ближайшего соседа в графе сервисов.
Ну, Google, Facebook и Netflix создавали микросервисы ещё до того, как их стали так называть, и я читал в Твиттере, что они уже решили все эти проблемы… фух! Они сделали это с помощью метрик, логов и распределённой трассировки, так что вам тоже стоит это сделать — это называется «Три столпа наблюдаемости», и вы, вероятно, уже знаете, как они выглядят:
Метрики!
Логи!
Трейсы!
Итак, если вы хотите решить проблемы наблюдаемости, с которыми сталкиваются Google, Facebook и Twitter, это просто… найдите поставщика метрик, поставщика логов, поставщика трассировок, и вуаля: ваши команды DevOps будут наслаждаться преимуществами наблюдаемой распределённой системы.
Фатальные недостатки
Возможно, вышесказанное — преувеличение. Тем не менее для тех, кто использовал «три столпа» как отдельные технологии, первоначальное воодушевление быстро улетучилось из-за фатальных недостатков.
Метрики и мощность
Что касается метрик, нам всем нужно было выучить новое слово: кардинальность (cardinality). Прелесть метрик в том, что они позволяют легко определить, когда происходит что-то плохое: метрика выглядит как волнистая линия, и вы можете видеть, как она поднимается (или опускается), когда происходит что-то плохое. Но диагностировать такие аномальные моменты, используя только метрики, крайне сложно… лучшее, что мы можем сделать, — это «проанализировать подробнее», что обычно означает группировку метрик по тегам в надежде, что конкретное значение тега объясняет аномалию, а затем фильтрацию по этому тегу и повторение процесса анализа подробнее.
«Cardinality» — это количество элементов в множестве. В случае с метриками кардинальное число — это количество значений для любого конкретного тега метрики. Если значений пять, то, скорее всего, всё в порядке; если 50 — тоже нормально; если 500 — вероятно, это слишком дорого; а когда счёт идёт на тысячи, вы просто не сможете оправдать рентабельность инвестиций. К сожалению, многие реальные теги содержат тысячи или миллионы значений (например, идентификатор пользователя, идентификатор контейнера и т. д.), поэтому с точки зрения расследования метрики часто оказываются бесполезными.
Ведение журнала томов с помощью микросервисов
Что касается логов, то эту проблему описать проще: они просто становятся слишком дорогими, и всё. В прошлом году я был на ужине для спикеров перед конференцией по мониторингу, и один из докладчиков — действительно умный и авторитетный человек, который руководил ведением логов в одной из самых известных технологических компаний на сегодняшний день, — на следующий день выступал с докладом о том, как вести логи в среде микросервисов. Меня заинтересовала эта тема, и я спросил его, в чём заключается его основная идея. Он ответил: «О, всё очень просто: больше ничего не регистрируйте».
Легко понять почему: если мы хотим использовать логи для отслеживания отдельных транзакций (как мы делали во времена монолитных веб-серверов), нам придётся платить за следующее:
Системы логирования больше не могут позволить себе хранить данные о каждой транзакции, потому что стоимость таких журналов транзакций пропорциональна количеству микросервисов, задействованных в средней транзакции. Не говоря уже о том, что сами журналы менее полезны (независимо от стоимости) из-за необходимости анализировать параллелизм и причинно-следственные связи в транзакциях микросервисов. Таким образом, обычного логирования недостаточно в нашем дивном новом архитектурном мире.
Отслеживание и предвидение
Это подводит нас к «распределённой трассировке» — технологии, специально разработанной для решения вышеупомянутой проблемы с системами логирования. Я сам создал Dapper проект в Google. Он, безусловно, был полезен, особенно для анализа задержек в стабильном состоянии, но мы решили проблему с объёмом данных, применив бессмысленную, полностью случайную и очень агрессивную выборку. Это давняя проблема распределённой трассировки, и именно поэтому Dapper было неудобно использовать в сценариях с дежурствами.
Очевидным решением было бы вообще отказаться от выборки. Однако для масштабируемых микросервисов это неприемлемо. Более реалистичным решением будет отложить принятие решения о выборке до завершения транзакции: это улучшит ситуацию, хотя такой подход оставляет без ответа важный вопрос: какие именно трассировки следует выбирать? Если мы ограничиваем анализ отдельными трассировками, то обычно фокусируемся на «медленных» или приводящих к ошибкам. Однако проблемы с производительностью и надёжностью в рабочем программном обеспечении обычно являются следствием взаимодействия между транзакциями, и понимание этого взаимодействия требует гораздо более сложных стратегий выборки, которые объединяют связанные трассировки, конкурирующие за одни и те же ресурсы.
В любом случае, одна распределённая трассировка иногда может быть полезной, но это всё равно что надеяться на чудо. Отбор подходящих распределённых трассировок и извлечение из них значимой и доступной информации — более сложная задача, но и результат будет гораздо ценнее.
А что касается подражания Google (и не только)…
Ещё одна проблема, связанная с «Тремя столпами», заключается в самом представлении о том, что мы всегда должны стремиться создавать программное обеспечение, подходящее для инфраструктуры «планетарного масштаба» в Google (или Facebook, или Twitter и так далее). Короче говоря: не подражайте Google. Это не критика в адрес Google — там работают блестящие специалисты, и они проделали потрясающую работу с учётом своих требований.
Но! Технологии Google масштабируются как сумасшедшие, и это не обязательно «хорошо»: Джефф Дин (один из тех блестящих сотрудников Google, которые заслуживают всех похвал — у него даже есть свой мем) иногда говорил о том, что практически невозможно разработать программную систему, которая была бы пригодна для масштабирования более чем на 3–4 порядка. Кроме того, существует естественное противоречие между масштабируемостью системы и набором её функций.
Микросервисы Google генерируют около 5 миллиардов RPC-запросов в секунду; таким образом, создание инструментов мониторинга, способных масштабироваться до 5 млрд RPC-запросов в секунду, сводится к созданию инструментов мониторинга с крайне ограниченным набором функций. Если ваша организация обрабатывает около 5 миллионов RPC-запросов в секунду, это всё равно впечатляет, но вам почти наверняка не стоит использовать то, что использует Google: при масштабе в 1/1000 вы можете позволить себе гораздо более мощные функции.
Биты vs преимущества
Таким образом, у каждого «столпа» есть фатальный недостаток (или три), и это проблема. Другая проблема ещё более фундаментальна: метрики, логи и распределённые трассировки — это просто биты. Каждый из них описывает определённый тип структуры данных, и когда мы думаем о них, то представляем себе самую тривиальную визуализацию этих структур данных: метрики выглядят как волнистые линии; логи — как хронологический список отформатированных строк; а трассировки — как вложенные каскадные диаграммы времени.
Ничто из вышеперечисленного напрямую не связано с конкретной проблемой, вариантом использования или бизнес-потребностью. То есть, придерживаясь ортодоксального подхода «трех столпов», мы неявно перекладываем чрезвычайно сложную задачу по фактическому анализу метрик, журналов и трассировок на «читателя». И, учитывая вышеупомянутые фатальные недостатки, а также тонкие взаимосвязи и взаимозависимости между этими тремя типами данных, наша наблюдаемость сильно страдает.
На пути к лучшей модели
Таким образом, метрики, логи и трассировки — это не «наблюдаемость», а просто телеметрия. Тогда что же такое наблюдаемость? Если необработанные данные сами по себе не представляют ценности, то что же представляет? Наблюдаемость — это просто новое слово для обозначения мониторинга? И можем ли мы добиться этого с помощью одной продвинутой базы данных?
Все эти вопросы отличные, но ответы на них неочевидны. Они также выходят за рамки этой статьи, но вы можете узнать больше обо всём этом здесь: Наблюдаемость не заменит мониторинг (потому что и не должна его заменять). Есть способ сделать телеметрию полезной — даже преобразующей, — но сначала нам понадобится более совершенная модель наблюдаемости.
