Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni

🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!

20.07.2024

Логи та топологія

Логи мають дещо спільне з бекапами: вони цінні, коли можеш їх прочитати, а не тільки збираєш. Після першої версії інструменту перегляду журналів для CodeDeploy багато про це думаю.

Ну, скажете ви, прочитати журнал — це тривіально. На жаль, тільки поки топологія проєкту тривіальна. З кожним новим сервісом зʼявляються проблеми. (Навіть не буду про те, що логи мусять сходитися в єдину базу — це, сподіваюся, зрозуміло.) Стає складно зрозуміти, який журнал чого стосується: логічний розподіл сервісів не завжди відповідає фактичному набору журнальних потоків. Тобто щоб визначити потрібний журнал, потрібно знати подробиці реалізації, а не тільки мати уявлення про загальну архітектуру.

Типове використання журналу: дослідити причину несподіваної ситуації. Для цього потрібна можливість передивлятися журнали за графом архітектури: від того сервісу, де ситуація трапилась, до його залежностей, і так далі. З одного боку, тут доречно впровадити APM, тобто журналювання запитів з відстеженням сліду через сервіси. З іншого, мої проблеми це не розвʼязує. Уявимо ситуацію: база даних була перевантажена, тому не змогла прийняти запит від сервісу. Тут мене цікавить не сам запит, а що відбувалося в базі на той час.

Поки не знайшов інструменту такого “топологічного” перегляду журналів. Та ще й AWS CloudWatch - не дуже зручна база. Фактично вони пропонують лише два способи перегляду: або конкретний потік (гарно тільки коли ти точно знаєш, яка копія сервісу цікавить), або пошук запитом Log Insights - це хоч і гнучко, але писати щоразу запит дуже втомлює.