← назад к разделу

Сервис тормозит, и непонятно, база это или приложение, а смотреть логи входом на каждую из шести машин невозможно. Вторая история: пароль базы лежит в конфиге, конфиг продублирован в трёх репозиториях, и когда его пора менять, никто не помнит, где ещё он есть.

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

Главное

  • Логи, метрики и сигналы тревоги — три части одной системы наблюдаемости провайдера; метрики управляемых сервисов появляются в ней без настройки.
  • Логи пишут структурированно, с полями, а не сплошным текстом; платят за объём, поэтому «писать всё» стоит денег.
  • Сигнал тревоги ставят на симптом для пользователя (ошибки, задержка), а не на каждую метрику, и с инструкцией, что делать.
  • Секреты хранят в хранилище секретов, а приложение забирает их при старте по правам своего сервисного аккаунта; в конфиге и git секретов нет.
  • Данные в облаке шифруются всегда ключом провайдера; управляемое хранилище ключей нужно, когда ключ должен быть вашим и отзываемым.
  • Журнал действий в аккаунте отвечает «кто удалил очередь»; события уровня данных в него не пишутся, пока их не включили.

Логи, метрики, сигналы тревоги

У провайдера три части наблюдаемости, и их легко перепутать. Логи — текстовые записи приложений и сервисов, собранные в одно место, где их ищут по полям. Метрики — числа во времени: загрузка процессора базы, длина очереди, число запросов и ошибок. Сигналы тревоги — правила вида «если ошибок больше стольких-то за минуту — разбудить дежурного», привязанные к метрикам.

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

За что платят и где ошибаются

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

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

Где хранить секреты

Пароль базы, ключ платёжного провайдера, токен внешнего API — секреты, и в конфиге им не место: конфиг уезжает в git и живёт там годами. У провайдера есть хранилище секретов: секрет кладут туда один раз, доступ к нему выдают ролью сервисному аккаунту приложения, а приложение забирает значение при старте. Кто и когда читал секрет, видно в журнале; смена пароля — обновление одной записи, а не поиск по репозиториям.

Рядом с секретами живут обычные настройки: адреса, флаги, лимиты. Их держат в хранилище параметров — дешевле и без шифрования, но с той же моделью доступа. Правило простое: всё, что даёт доступ, — в секреты; всё, что просто настраивает, — в параметры.

Ключи шифрования и журнал действий

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

Отдельный сервис пишет журнал действий в аккаунте: кто, когда и откуда создал машину, поменял политику, удалил очередь. Это не инструмент только для безопасников — так ищут причину «кто удалил очередь» за минуты. Две оговорки: события уровня данных (чтение объектов, вызовы функций) по умолчанию в журнал не попадают, их включают отдельно; и хранится журнал ограниченное время, если не настроить постоянную выгрузку.

Глубже: трассировка запроса через несколько сервисов

Когда запрос проходит через пять сервисов, логи каждого по отдельности не показывают, где потерялось время. Для этого есть трассировка: каждый запрос получает идентификатор, он едет в заголовке от сервиса к сервису, и все записи с одним идентификатором складываются в одну картину с длительностью каждого шага. Провайдеры дают свои сервисы трассировки, а приложение подключается через стандартную библиотеку, которая передаёт идентификатор сама. Условие одно: идентификатор должен попадать и в логи, иначе от трассы к строке лога не перейти.

Глубже: цена локальной проверки и отзыва

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

Что почитать дальше