Что такое наблюдаемость и почему это важно?

Наблюдаемость — это черта программных систем, обеспечивающая глубокую видимость их внутренних операций. Наличие хорошей наблюдаемости способствует более быстрому решению проблем, помогая операционным группам выявлять причины проблем.

Самое простое определение «наблюдаемого» программного обеспечения — это система, которая позволяет вам делать выводы о ее внутреннем состоянии, наблюдая за выходными данными, которые она производит. Если ваша система не может предоставить эти выходные данные, она не будет полностью наблюдаемой.

Рассмотрим программную платформу, которая работает медленнее, чем обычно. На первый взгляд, у вас недостаточно информации, чтобы понять, что вызывает замедление. Но если бы система выдавала метрики производительности для каждого этапа своего выполнения, вы могли бы сразу определить проблемный компонент. Наблюдаемость системы теперь повышена.

Разве наблюдаемость — это не то же самое, что мониторинг?

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

Мониторинг в терминах DevOps обычно относится к использованию нескольких предопределенных показателей, чтобы определить, когда система работает в соответствии с ожиданиями. Охватываемые метрики обычно привязаны к использованию ресурсов (использование ЦП, пропускная способность сети), но могут также отображать базовые данные об операциях вашей системы (количество запросов, вызывающих код ошибки 500).

Наблюдаемость идет немного глубже и требует более тонких инструментов. В отличие от мониторинга, он связан с вашей системой и ее характеристиками, а не с окружающей средой.

Отслеживаемая система сообщает вам, что количество ошибок 500 повышено, и у пользователей возникают проблемы. Система наблюдаемая сообщает, что время ожидания вашей микрослужбы аутентификации истекло, поэтому сеансы пользователей не восстанавливаются, а ваш шлюз выдает 500 в крайнем случае.

Как системы становятся наблюдаемыми?

Давайте разберем различия между двумя приведенными выше примерами. При традиционном подходе вы развернетесь на своем сервере и настроите мониторинг, возможно, используя оповещения о показателях вашего облачного провайдера. Если проблема была обнаружена, вы можете пойти и проверить журналы сервера на наличие проблем.

Эта модель уже в некоторой степени наблюдаема. Однако современное использование термина «наблюдаемость» означает немного больше. Журналы ошибок сервера обычно предоставляют окончательный результат, но не состояния, которые привели к его возникновению. Чтобы система была действительно наблюдаемой, вы должны быть в состоянии определить последовательность внутренних состояний, которые привели к определенному результату, не тратя слишком много времени на ручной сбор информации.

Существуют три основных «столпа» наблюдаемости, одним из которых является хороший мониторинг. Уделение внимания всем трем столпам должно привести к созданию наблюдаемой системы, которая эффективно помогает в диагностике проблем.

Метрики и мониторинг

Наблюдаемая система должна обеспечивать постоянные измерения заранее определенных показателей. Лучшие метрики — это те, которые представляют полезную информацию, относящуюся к вашему приложению и его производительности, а не общие диаграммы ЦП и памяти.

Ведение журнала

Второй столп наблюдаемости — логирование. Это описывает более структурированный подход к ведению журнала, чем базовая запись при возникновении ошибки. Журналы должны быть хорошо интегрированы в вашу систему, чтобы каждое событие записывалось в централизованную службу ведения журналов. Сами журналы должны быть структурированы стандартизированным образом, чтобы инструменты просмотра журналов могли автоматически индексировать и форматировать их.

Отслеживание

Последний столб — трассировка. Трассировки фиксируют все, что происходит во время определенного запуска программы. Это дает вам информацию, необходимую для воспроизведения точной последовательности событий, которые привели к проблеме. Трассировка особенно важна для распределенных систем, где один запрос может попасть в дюжину или более микросервисов. Полагаться только на журналы сервисов нереально, так как вы не сможете увидеть, что произошло с запросом после его завершения с каждым сервисом. Трассировка на уровне запроса более эффективна для выявления проблем.

Вы можете начать делать систему более заметной, обеспечив охват всех трех столпов. Помните, что «наблюдаемость» — это не что-то конкретное, это черта системы, а не отдельный атрибут. Скорее всего, ваша система уже «наблюдаема» с помощью основных метрик и журналов ошибок, но она все еще может иметь низкую «наблюдаемость», если вы не можете сразу определить основную причину ошибок.

Остановит ли наблюдаемость ошибки?

Стоит отметить, что наблюдаемость не предназначена для устранения багов и ошибок. На самом деле это признание того, что проблемы могут и будут возникать. Вместо того, чтобы предполагать, что ваша система безошибочна, наблюдаемость побуждает вас планировать немыслимое. Если бы вы столкнулись с отключением, были бы у вас инструменты, необходимые для поиска причины?

Если использовать автомобильную аналогию, это разница между индикатором проверки двигателя и диагностическим программным обеспечением производителя. Как бы нежелательно и маловероятно это ни было, неисправности в дороге случаются. Большинство людей, не имеющих специального оборудования, видят общий сигнал тревоги. У преданного автомобилиста или техника будут инструменты, чтобы определить причину этого света.

Теперь вернемся к облаку. Экран с красными метриками мало поможет во время сбоя. Подобно тому, как автомеханик может считывать результаты диагностики, ваша система должна быть более поддающейся наблюдению, чтобы вы могли быстро определить, что не так, не глядя на гайки и болты. Важно планировать стихийные бедствия, чтобы не попасться.

Наблюдаемость непрерывна

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

Вы можете выявить пробелы в реализации наблюдаемости, задав системе вопросы и проверив, можете ли вы получить нужные ответы. Вы должны подумать об информации, которая вам понадобится, чтобы начать решать проблему. Сможете ли вы получить к нему доступ во время сбоя без длительного ручного вмешательства?

По-настоящему наблюдаемая система должна уметь использовать один из трех столпов для ответа на вопросы, представленные двумя другими. Почему использование памяти находится в опасной зоне? Почему в логах службы аутентификации была зафиксирована ошибка? В обоих этих случаях два других столпа должны быть вашим первым портом захода, чтобы найти ответ.

Краткое содержание

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

Хорошая наблюдаемость жизненно важна для распределенных архитектур, где функциональность распределена по микросервисам. Ненаблюдаемая система становится черной дырой, которая засасывает запросы, но ничего не возвращает. Это поставит под угрозу вашу способность реагировать на проблемы и может привести к тому, что пользователи сообщат о проблемах до того, как вы о них узнаете.

И наоборот, наблюдаемая система помогает вам опережать сообщения об ошибках. Время решения сведено к минимуму, так как система уже будет ожидать требуемой информации.