Или почему «оно работает» — это не то же самое, что «я понимаю, как оно работает»
Кирилл Казарин, спикер курса «Администрирование Linux» и автор телеграм-канала Kazarin.online, простыми словами объясняет, что такое Observability и зачем оно нужно. Несмотря на то, что термин уже не новый, статья будет полезна людям, плохо с ним знакомым или незнакомым вовсе. Кирилл опирается на практику и на те примеры (пусть даже вымышленные), где наблюдаемости явно не хватает.
Рассмотрели три столпа наблюдаемости, необходимые инструменты, blind spots, а также составили чек-лист «Как понять, что у вас плохое observability».
Кирилл Казарин, спикер курса «Администрирование Linux» и автор телеграм-канала Kazarin.online, простыми словами объясняет, что такое Observability и зачем оно нужно. Несмотря на то, что термин уже не новый, статья будет полезна людям, плохо с ним знакомым или незнакомым вовсе. Кирилл опирается на практику и на те примеры (пусть даже вымышленные), где наблюдаемости явно не хватает.
Рассмотрели три столпа наблюдаемости, необходимые инструменты, blind spots, а также составили чек-лист «Как понять, что у вас плохое observability».
Что вообще такое Observability?
Observability («наблюдаемость») — это способность понять внутреннее состояние системы только по её внешним проявлениям. Часто ещё говорят, что это свойство системы «быть наблюдаемой» (а значит ее нужно так построить. Или перестроить).
Как можно представить наличие такого свойства:
Пример из жизни:
Сломался лифт. На табло — ничего. Кнопки не горят. Диспетчер говори: «Нажмите на все кнопки». Лифт молчит. Это плохая наблюдаемость. Или вовсе её отсутствие
Теперь представим, что у лифта:
Это уже хорошая наблюдаемость. Мы можем понять, что происходит — не вскрывая кабину, не залезая в моторный отсек, шахту и т.д.
Наблюдаемость ≠ Мониторинг
Можно подумать что observability — это метрики, графики и алерты. Нет. Это смешение понятий и подмена свойства «наблюдаемости» (подчеркну — свойства), процессом сбора телеметрии, ее автоматическим анализом, визуализацией и эскалацией. То есть тем, что в современном мире называют обычно «мониторинг». Мониторинг — процесс, наблюдаемость — свойство!
Мониторинг отвечает на вопрос: «Сломалось?», «Что сломалось?», «Когда сломалось?», и даже, возможно, «Сколько раз?».
Observability поможет понять, почему: «Потому что новый релиз сломал работу с Redis, а на третьей ноде таймауты к кластеру выросли до 3 секунд».
Можно также сказать, что мониторинг отвечает на известные вопросы, observability помогает формулировать новые.
Три столпа наблюдаемости: метрики, логи и трассировки
1. Метрики, она же телеметрия
Что это: численные значения, которые можно агрегировать и отображать, обрабатывать триггером, зажигать алерт, ретроспективно анализировать.
Примеры:
- Количество запросов в секунду.
- Утилизация CPU.
- Ошибки 5xx.
- Время ответа 95-го перцентиля.
Где полезны:
- Оперативный мониторинг.
- Дашборды.
- Триггеры алертов.
Пример: Мы видим, что latency checkout вырос с 150ms до 900ms — и это не просто "кажется", это метрика на графике в Grafana.
2. Логи
Что это: текстовые события, часто с контекстом (уровень, время, тред, пользователь).
Примеры:
- ERROR Could not connect to DB
- INFO User 123 placed order
- WARN Timeout during external API call
Где полезны:
- Разбор инцидентов.
- Отладка (дебаг, траблшутинг)
- Поиск аномалий.
Пример: Логи показывают, что ошибка NullPointerException началась ровно после релиза версии 1.4.2.
3. Трассировки (distributed tracing)
Что это: хронология вызовов между компонентами системы.
Примеры:
- запрос от клиента → API Gateway → backend → сервис оплаты → база.
Где полезны:
- Понимание сложных связей в микросервисах.
- Выявление «долго думающих» компонентов.
- Оптимизация цепочек.
Пример: Вы видите, что 70% времени на оплату тратится в вызове к стороннему платежному API. И это видно в одном клике — потому что трассировка это зафиксировала.
Инструменты: с чего начинается наблюдаемость
Prometheus — сбор и хранение метрик. Альтернатив много - от Zabbix до платных облачных сервисов типа Datadog
Grafana — визуализация, алерты. Есть альтернативы но будем честны - стандарт де-факто.
OpenTelemetry — относительно новый, открытый стандарт для сбора логов, метрик и трассировок.
Jaeger / Zipkin — трассировки.
Elastic stack — логи, метрики, APM. Альтернатив много, например Loki — лог-агрегатор от Grafana.
Важно: инструменты вторичны. Сначала — понимание, какие вопросы мы хотим уметь задавать системе.
Пример: есть ли у нас наблюдаемость?
Представим гипотетический инцидент:
Вопрос: Могли бы мы выяснить это быстрее? С меньшими усилиями? С меньшим ущербом для конечного опыта пользователей?
Да, могли. Если бы мы сразу получили ответ в формате цепочки сервисов - кто от кого зависит, кто начал сбоить, когда и что в это время происходило еще (какие события могли к этому привести).
Что тут могло пригодиться:
- логи разных компонент связаны за счет единого trace-id/request-id
- в идеале есть трейсинг запроса между компонентами. Не обязательно трейсить каждый. Можно каждый 100-ый, например, или вообще динамически включать
- все компоненты отдают метрики и у нас есть выборка скажем топ 10, которые вероятнее расскажут о проблеме. Эти метрики точно покрыты триггерами. Например latency, error rate, request rate, duration и тд. Привет USE, RED, 4GS.
Если же у вас:
- нет трассировок между компонентами,
- логи разрозненные и не связаны по trace-id,
- метрики, например, есть только у Nginx…
то у вас плохая наблюдаемость.
Blind spots — невидимые зоны
«Всё, что не логируется и не мониторится — исчезает в момент инцидента»
Blind spot — это участок системы, по которому мы ничего не знаем.
Примеры:
- Вызов к стороннему API, который мы не мониторим.
- Скрипт, который запускается по cron и не логирует ни свою работу, ни результат. К тому же не мониторится.
- Внутренний сервис, который пишет в stdout, а не в централизованную систему логов (забыли мы с него настроить сбор логов)
Как искать такие зоны:
- Составить карту компонентов и зависимостей.
- Пройтись по запросу от клиента до базы: на каждом этапе — есть ли логика, метрики, трассировки?
- Если нет — это и есть blind spot.
Что отличает хорошую Observability от плохой
Хорошая:
- Система отвечает на вопросы: "что происходит", "почему", "когда началось", "что ещё пострадало".
- Лёгкий доступ к данным.
- Консистентные trace-id между логами, метриками, трассировками.
- История событий доступна хотя бы за неделю. В идеале пусть даже с некоторым усреднением есть статистика за месяц-квартал-год.
Плохая:
- Есть только дашборд «всё зелёное» (или все красное. Светофор)
- Нет trace-id, но есть 200 Gb логов в plaintext без таймстампов.
- Метрики только у сторонних компонент, типа Redis, MySQL, Nginx и то просто потому что их по дефолту экспортирует мониторинг агент
- Никто не знает, откуда взять трассировку, если она вообще есть.
- Вы никогда не проверяли теорию о том что выход из строя компонента Х может быть найден за Y времени с тратой Z человеческих ресурсов.
Observability — это культура
Наблюдаемость — не библиотека, не тул, не плагин.
Это подход:
- Придумывать, какие сигналы система должна излучать.
- Проектировать фичи с вопросом: "а как мы поймем, что она работает?". И самое главное - “когда и почему она НЕ работает”
- Не верить, что "если запрос вернул 200 — всё хорошо". Потому что видели мы JSON: 200ok {Status: “Request failed”}.
Итоги
Observability — это не про «если что, посмотрим по логам». Это про систему, которая сама себя объясняет. Начинайте с вопросов, на которые вы хотите уметь отвечать.
Чеклист: как понять, что у вас плохое observability
1. 🔍 Есть только метрики на уровне ingress-а, но не внутри приложения.
2. ❓ Вы не можете за 5 минут понять, почему выросли ошибки 5xx.
3. 🧩 Логи разрознены, нет trace-id или они не совпадают между сервисами.
4. 📉 У вас есть дашборды, но вы на них не смотрите (и никто не знает, что они показывают).
5. 🌪️ В случае инцидента все бегают с kubectl logs по разным подам и грепают в надежде найти «что-то странное».
6. 🛠️ Алёрты приходят, но вы не знаете, что с ними делать.
7. 🔧 У новых фич нет логирования или метрик вообще.
8. 🔐 Запрос через 3 микросервиса нельзя восстановить end-to-end.
9. 🧱 Вы не знаете, какие компоненты у вас в системе и как они связаны.
10. 🐛 «Сейчас вроде работает — давайте не трогать».
Observability («наблюдаемость») — это способность понять внутреннее состояние системы только по её внешним проявлениям. Часто ещё говорят, что это свойство системы «быть наблюдаемой» (а значит ее нужно так построить. Или перестроить).
Как можно представить наличие такого свойства:
- У вас есть черный ящик
- Вы не можете открыть его, но можете смотреть, как он реагирует на входные сигналы
- И по этим реакциям вы должны понять, что у него внутри: как он устроен, работает ли правильно, где болит
Пример из жизни:
Сломался лифт. На табло — ничего. Кнопки не горят. Диспетчер говори: «Нажмите на все кнопки». Лифт молчит. Это плохая наблюдаемость. Или вовсе её отсутствие
Теперь представим, что у лифта:
- горят статусы: «ожидание запроса», «движение вверх», «ошибка двери»;
- логируются события: «вызов получен, но не выполнен»;
- и у нас есть телеметрия с контроллера.
Это уже хорошая наблюдаемость. Мы можем понять, что происходит — не вскрывая кабину, не залезая в моторный отсек, шахту и т.д.
Наблюдаемость ≠ Мониторинг
Можно подумать что observability — это метрики, графики и алерты. Нет. Это смешение понятий и подмена свойства «наблюдаемости» (подчеркну — свойства), процессом сбора телеметрии, ее автоматическим анализом, визуализацией и эскалацией. То есть тем, что в современном мире называют обычно «мониторинг». Мониторинг — процесс, наблюдаемость — свойство!
Мониторинг отвечает на вопрос: «Сломалось?», «Что сломалось?», «Когда сломалось?», и даже, возможно, «Сколько раз?».
Observability отвечает на вопрос: «Почему?»
Мониторинг скажет: «API /checkout возвращает 5xx. Началось 5 минут назад» (это кстати еще хороший мониторинг)
Observability поможет понять, почему: «Потому что новый релиз сломал работу с Redis, а на третьей ноде таймауты к кластеру выросли до 3 секунд».
Можно также сказать, что мониторинг отвечает на известные вопросы, observability помогает формулировать новые.
Три столпа наблюдаемости: метрики, логи и трассировки
1. Метрики, она же телеметрия
Что это: численные значения, которые можно агрегировать и отображать, обрабатывать триггером, зажигать алерт, ретроспективно анализировать.
Примеры:
- Количество запросов в секунду.
- Утилизация CPU.
- Ошибки 5xx.
- Время ответа 95-го перцентиля.
Где полезны:
- Оперативный мониторинг.
- Дашборды.
- Триггеры алертов.
Пример: Мы видим, что latency checkout вырос с 150ms до 900ms — и это не просто "кажется", это метрика на графике в Grafana.
2. Логи
Что это: текстовые события, часто с контекстом (уровень, время, тред, пользователь).
Примеры:
- ERROR Could not connect to DB
- INFO User 123 placed order
- WARN Timeout during external API call
Где полезны:
- Разбор инцидентов.
- Отладка (дебаг, траблшутинг)
- Поиск аномалий.
Пример: Логи показывают, что ошибка NullPointerException началась ровно после релиза версии 1.4.2.
3. Трассировки (distributed tracing)
Что это: хронология вызовов между компонентами системы.
Примеры:
- запрос от клиента → API Gateway → backend → сервис оплаты → база.
Где полезны:
- Понимание сложных связей в микросервисах.
- Выявление «долго думающих» компонентов.
- Оптимизация цепочек.
Пример: Вы видите, что 70% времени на оплату тратится в вызове к стороннему платежному API. И это видно в одном клике — потому что трассировка это зафиксировала.
Инструменты: с чего начинается наблюдаемость
Prometheus — сбор и хранение метрик. Альтернатив много - от Zabbix до платных облачных сервисов типа Datadog
Grafana — визуализация, алерты. Есть альтернативы но будем честны - стандарт де-факто.
OpenTelemetry — относительно новый, открытый стандарт для сбора логов, метрик и трассировок.
Jaeger / Zipkin — трассировки.
Elastic stack — логи, метрики, APM. Альтернатив много, например Loki — лог-агрегатор от Grafana.
Важно: инструменты вторичны. Сначала — понимание, какие вопросы мы хотим уметь задавать системе.
Пример: есть ли у нас наблюдаемость?
Представим гипотетический инцидент:
В 03:14 начались ошибки 502 Bad Gateway. Через 7 минут алерт. На поиск причины ушло ещё 40 минут (оптимистично). Смотрели логи ряда сервисов, по документации вспоминали флоу и т.д. Параллельно смотрели а что сегодня выкатывалось (слава богам если у нас поставлен процесс change-management)! В итоге оказалось — обновили сервис расчёта доставки, и он стал отдавать 500ые ошибки из-за несовместимости с новой схемой данных, потом это другим, зависимым от него сервисом конвертнулось в 503, потому что разработчик того сервиса так решил и в итоге на API gateway мы получили 502 что и зафиксировал клиент.
Вопрос: Могли бы мы выяснить это быстрее? С меньшими усилиями? С меньшим ущербом для конечного опыта пользователей?
Да, могли. Если бы мы сразу получили ответ в формате цепочки сервисов - кто от кого зависит, кто начал сбоить, когда и что в это время происходило еще (какие события могли к этому привести).
Что тут могло пригодиться:
- логи разных компонент связаны за счет единого trace-id/request-id
- в идеале есть трейсинг запроса между компонентами. Не обязательно трейсить каждый. Можно каждый 100-ый, например, или вообще динамически включать
- все компоненты отдают метрики и у нас есть выборка скажем топ 10, которые вероятнее расскажут о проблеме. Эти метрики точно покрыты триггерами. Например latency, error rate, request rate, duration и тд. Привет USE, RED, 4GS.
Если же у вас:
- нет трассировок между компонентами,
- логи разрозненные и не связаны по trace-id,
- метрики, например, есть только у Nginx…
то у вас плохая наблюдаемость.
Blind spots — невидимые зоны
«Всё, что не логируется и не мониторится — исчезает в момент инцидента»
Blind spot — это участок системы, по которому мы ничего не знаем.
Примеры:
- Вызов к стороннему API, который мы не мониторим.
- Скрипт, который запускается по cron и не логирует ни свою работу, ни результат. К тому же не мониторится.
- Внутренний сервис, который пишет в stdout, а не в централизованную систему логов (забыли мы с него настроить сбор логов)
Как искать такие зоны:
- Составить карту компонентов и зависимостей.
- Пройтись по запросу от клиента до базы: на каждом этапе — есть ли логика, метрики, трассировки?
- Если нет — это и есть blind spot.
Что отличает хорошую Observability от плохой
Хорошая:
- Система отвечает на вопросы: "что происходит", "почему", "когда началось", "что ещё пострадало".
- Лёгкий доступ к данным.
- Консистентные trace-id между логами, метриками, трассировками.
- История событий доступна хотя бы за неделю. В идеале пусть даже с некоторым усреднением есть статистика за месяц-квартал-год.
Плохая:
- Есть только дашборд «всё зелёное» (или все красное. Светофор)
- Нет trace-id, но есть 200 Gb логов в plaintext без таймстампов.
- Метрики только у сторонних компонент, типа Redis, MySQL, Nginx и то просто потому что их по дефолту экспортирует мониторинг агент
- Никто не знает, откуда взять трассировку, если она вообще есть.
- Вы никогда не проверяли теорию о том что выход из строя компонента Х может быть найден за Y времени с тратой Z человеческих ресурсов.
Observability — это культура
Наблюдаемость — не библиотека, не тул, не плагин.
Это подход:
- Придумывать, какие сигналы система должна излучать.
- Проектировать фичи с вопросом: "а как мы поймем, что она работает?". И самое главное - “когда и почему она НЕ работает”
- Не верить, что "если запрос вернул 200 — всё хорошо". Потому что видели мы JSON: 200ok {Status: “Request failed”}.
Итоги
Observability — это не про «если что, посмотрим по логам». Это про систему, которая сама себя объясняет. Начинайте с вопросов, на которые вы хотите уметь отвечать.
Чеклист: как понять, что у вас плохое observability
1. 🔍 Есть только метрики на уровне ingress-а, но не внутри приложения.
2. ❓ Вы не можете за 5 минут понять, почему выросли ошибки 5xx.
3. 🧩 Логи разрознены, нет trace-id или они не совпадают между сервисами.
4. 📉 У вас есть дашборды, но вы на них не смотрите (и никто не знает, что они показывают).
5. 🌪️ В случае инцидента все бегают с kubectl logs по разным подам и грепают в надежде найти «что-то странное».
6. 🛠️ Алёрты приходят, но вы не знаете, что с ними делать.
7. 🔧 У новых фич нет логирования или метрик вообще.
8. 🔐 Запрос через 3 микросервиса нельзя восстановить end-to-end.
9. 🧱 Вы не знаете, какие компоненты у вас в системе и как они связаны.
10. 🐛 «Сейчас вроде работает — давайте не трогать».
