Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-19

1 Или почему "оно работает" - это не то же самое, что "я понимаю, как оно работает"

2 Кирилл Казарин, спикер курса<a>"Администрирование Linux"</a>и автор телеграм-канала Kazarin.online, простыми словами объясняет, что такое Observability и зачем оно нужно. Несмотря на то, что термин уже не новый, статья будет полезна людям, плохо с ним знакомым или незнакомым вовсе. Кирилл опирается на практику и на те примеры (пусть даже вымышленные), где наблюдаемости явно не хватает.

3 Рассмотрели три столпа наблюдаемости, необходимые инструменты, blind spots, а также составили чек-лист "Как понять, что у вас плохое observability".

4 Что вообще такое Observability?

5 Observability ("наблюдаемость") - это способность понять внутреннее состояние системы только по её внешним проявлениям. Часто ещё говорят, что это свойство системы "быть наблюдаемой" (а значит ее нужно так построить. Или перестроить).

6 Как можно представить наличие такого свойства:

7 <ul><li>У вас есть черный ящик</li>

8 <li>Вы не можете открыть его, но можете смотреть, как он реагирует на входные сигналы</li>

9 <li>И по этим реакциям вы должны понять, что у него внутри: как он устроен, работает ли правильно, где болит</li>

10 </ul>Пример из жизни:

11 Сломался лифт. На табло - ничего. Кнопки не горят. Диспетчер говори: "Нажмите на все кнопки". Лифт молчит. Это плохая наблюдаемость. Или вовсе её отсутствие

12 Теперь представим, что у лифта:

13 <ul><li>горят статусы: "ожидание запроса", "движение вверх", "ошибка двери";</li>

14 <li>логируются события: "вызов получен, но не выполнен";</li>

15 <li>и у нас есть телеметрия с контроллера.</li>

16 </ul>Это уже хорошая наблюдаемость. Мы можем понять, что происходит - не вскрывая кабину, не залезая в моторный отсек, шахту и т.д.

17 Наблюдаемость ≠ Мониторинг

18 Можно подумать что observability - это метрики, графики и алерты. Нет. Это смешение понятий и подмена свойства "наблюдаемости" (подчеркну - свойства), процессом сбора телеметрии, ее автоматическим анализом, визуализацией и эскалацией. То есть тем, что в современном мире называют обычно "мониторинг". Мониторинг - процесс, наблюдаемость - свойство!

19 Мониторинг отвечает на вопрос: "Сломалось?", "Что сломалось?", "Когда сломалось?", и даже, возможно, "Сколько раз?".

20 Observability отвечает на вопрос: "Почему?"

21 Мониторинг скажет: "API /checkout возвращает 5xx. Началось 5 минут назад" (это кстати еще хороший мониторинг)

22 Observability поможет понять, почему: "Потому что новый релиз сломал работу с Redis, а на третьей ноде таймауты к кластеру выросли до 3 секунд".

23 Можно также сказать, что мониторинг отвечает на известные вопросы, observability помогает формулировать новые.

24 Три столпа наблюдаемости: метрики, логи и трассировки

25 1. Метрики, она же телеметрия

26 Что это: численные значения, которые можно агрегировать и отображать, обрабатывать триггером, зажигать алерт, ретроспективно анализировать.

27 Примеры:

28 - Количество запросов в секунду.

29 - Утилизация CPU.

30 - Ошибки 5xx.

31 - Время ответа 95-го перцентиля.

32 Где полезны:

33 - Оперативный мониторинг.

34 - Дашборды.

35 - Триггеры алертов.

36 Пример: Мы видим, что latency checkout вырос с 150ms до 900ms - и это не просто "кажется", это метрика на графике в Grafana.

37 2. Логи

38 Что это: текстовые события, часто с контекстом (уровень, время, тред, пользователь).

39 Примеры:

40 - ERROR Could not connect to DB

41 - INFO User 123 placed order

42 - WARN Timeout during external API call

43 Где полезны:

44 - Разбор инцидентов.

45 - Отладка (дебаг, траблшутинг)

46 - Поиск аномалий.

47 Пример: Логи показывают, что ошибка NullPointerException началась ровно после релиза версии 1.4.2.

48 3. Трассировки (distributed tracing)

49 Что это: хронология вызовов между компонентами системы.

50 Примеры:

51 - запрос от клиента → API Gateway → backend → сервис оплаты → база.

52 Где полезны:

53 - Понимание сложных связей в микросервисах.

54 - Выявление "долго думающих" компонентов.

55 - Оптимизация цепочек.

56 Пример: Вы видите, что 70% времени на оплату тратится в вызове к стороннему платежному API. И это видно в одном клике - потому что трассировка это зафиксировала.

57 Инструменты: с чего начинается наблюдаемость

58 Prometheus - сбор и хранение метрик. Альтернатив много - от Zabbix до платных облачных сервисов типа Datadog

59 Grafana - визуализация, алерты. Есть альтернативы но будем честны - стандарт де-факто.

60 OpenTelemetry - относительно новый, открытый стандарт для сбора логов, метрик и трассировок.

61 Jaeger / Zipkin - трассировки.

62 Elastic stack - логи, метрики, APM. Альтернатив много, например Loki - лог-агрегатор от Grafana.

63 Важно: инструменты вторичны. Сначала - понимание, какие вопросы мы хотим уметь задавать системе.

64 Пример: есть ли у нас наблюдаемость?

65 Представим гипотетический инцидент:

66 В 03:14 начались ошибки 502 Bad Gateway. Через 7 минут алерт. На поиск причины ушло ещё 40 минут (оптимистично). Смотрели логи ряда сервисов, по документации вспоминали флоу и т.д. Параллельно смотрели а что сегодня выкатывалось (слава богам если у нас поставлен процесс change-management)! В итоге оказалось - обновили сервис расчёта доставки, и он стал отдавать 500ые ошибки из-за несовместимости с новой схемой данных, потом это другим, зависимым от него сервисом конвертнулось в 503, потому что разработчик того сервиса так решил и в итоге на API gateway мы получили 502 что и зафиксировал клиент.

67 Вопрос: Могли бы мы выяснить это быстрее? С меньшими усилиями? С меньшим ущербом для конечного опыта пользователей?

68 Да, могли. Если бы мы сразу получили ответ в формате цепочки сервисов - кто от кого зависит, кто начал сбоить, когда и что в это время происходило еще (какие события могли к этому привести).

69 Что тут могло пригодиться:

70 - логи разных компонент связаны за счет единого trace-id/request-id

71 - в идеале есть трейсинг запроса между компонентами. Не обязательно трейсить каждый. Можно каждый 100-ый, например, или вообще динамически включать

72 - все компоненты отдают метрики и у нас есть выборка скажем топ 10, которые вероятнее расскажут о проблеме. Эти метрики точно покрыты триггерами. Например latency, error rate, request rate, duration и тд. Привет USE, RED, 4GS.

73 Если же у вас:

74 - нет трассировок между компонентами,

75 - логи разрозненные и не связаны по trace-id,

76 - метрики, например, есть только у Nginx…

77 то у вас плохая наблюдаемость.

78 Blind spots - невидимые зоны

79 "Всё, что не логируется и не мониторится - исчезает в момент инцидента"

80 Blind spot - это участок системы, по которому мы ничего не знаем.

81 Примеры:

82 - Вызов к стороннему API, который мы не мониторим.

83 - Скрипт, который запускается по cron и не логирует ни свою работу, ни результат. К тому же не мониторится.

84 - Внутренний сервис, который пишет в stdout, а не в централизованную систему логов (забыли мы с него настроить сбор логов)

85 Как искать такие зоны:

86 - Составить карту компонентов и зависимостей.

87 - Пройтись по запросу от клиента до базы: на каждом этапе - есть ли логика, метрики, трассировки?

88 - Если нет - это и есть blind spot.

89 Что отличает хорошую Observability от плохой

90 Хорошая:

91 - Система отвечает на вопросы: "что происходит", "почему", "когда началось", "что ещё пострадало".

92 - Лёгкий доступ к данным.

93 - Консистентные trace-id между логами, метриками, трассировками.

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

95 Плохая:

96 - Есть только дашборд "всё зелёное" (или все красное. Светофор)

97 - Нет trace-id, но есть 200 Gb логов в plaintext без таймстампов.

98 - Метрики только у сторонних компонент, типа Redis, MySQL, Nginx и то просто потому что их по дефолту экспортирует мониторинг агент

99 - Никто не знает, откуда взять трассировку, если она вообще есть.

100 - Вы никогда не проверяли теорию о том что выход из строя компонента Х может быть найден за Y времени с тратой Z человеческих ресурсов.

101 Observability - это культура

102 Наблюдаемость - не библиотека, не тул, не плагин.

103 Это подход:

104 - Придумывать, какие сигналы система должна излучать.

105 - Проектировать фичи с вопросом: "а как мы поймем, что она работает?". И самое главное - “когда и почему она НЕ работает”

106 - Не верить, что "если запрос вернул 200 - всё хорошо". Потому что видели мы JSON: 200ok {Status: “Request failed”}.

107 Итоги

108 Observability - это не про "если что, посмотрим по логам". Это про систему, которая сама себя объясняет. Начинайте с вопросов, на которые вы хотите уметь отвечать.

109 Чеклист: как понять, что у вас плохое observability

110 1. 🔍 Есть только метрики на уровне ingress-а, но не внутри приложения.

111 2. ❓ Вы не можете за 5 минут понять, почему выросли ошибки 5xx.

112 3. 🧩 Логи разрознены, нет trace-id или они не совпадают между сервисами.

113 4. 📉 У вас есть дашборды, но вы на них не смотрите (и никто не знает, что они показывают).

114 5. 🌪️ В случае инцидента все бегают с kubectl logs по разным подам и грепают в надежде найти "что-то странное".

115 6. 🛠️ Алёрты приходят, но вы не знаете, что с ними делать.

116 7. 🔧 У новых фич нет логирования или метрик вообще.

117 8. 🔐 Запрос через 3 микросервиса нельзя восстановить end-to-end.

118 9. 🧱 Вы не знаете, какие компоненты у вас в системе и как они связаны.

119 10. 🐛 "Сейчас вроде работает - давайте не трогать".