Кхм. Громковатый заголовок, но я всё объясню.

Итак, у меня был сервис. Обычная молотилка данных, каждый с такой хотя бы раз да сталкивался - что-то на входе, что-то на выходе, а внутри походы в базу, HTTP-вызовы, шаблоны, скриптовая логика... В общем, много всякого.

Ну, ладно, тут стоит сразу уточнить, что сервис с особенностями - молотилка данных устроена так, что пытается работать с разными форматами на входе и выходе, а внутри держать всё в одном представлении. Но вот из-за этой потребности работать с разным, внутреннее представление это - мапы, слайсы, мапы в слайсах, слайсы в мапах, да ещё и из всех щелей торчит куча метрик.

Поэтому вот такая картина потребления памяти меня до недавних пор особо не смущала:

Starlark (ранее известный как Skylark) - питоноподобный язык, изначально разработанный для системы сборки Bazel, со временем выбравшийся за её пределы через интерпретаторы для Go и Rust.

Язык располагает к использованию в роли инструмента конфигурации, однако, благодаря хорошо написанному интерпретатору на Go и описанию спецификации, его можно использовать в виде встроенного в приложение языка программирования - например, когда вы хотите дать пользователю повзаимодействовать с объектом логики приложения, но не хотите постоянно плодить сущности под почти одинаковые кейсы через сотню настроечных параметров (мой случай).

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

Эта статья – продолжение текста о мониторинге. Здесь предлагаю нам с вами поговорить о роли логов в оценке состояния наблюдаемой площадки, посмотреть, что они способны нам дать, а также затронуть вопрос – «можно ли отрывать логи от метрик?».

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

Итак, давайте поговорим о логировании.

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

Давайте обсудим мониторинг.