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

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

31.07.2024

Розподілені транзакції в Sentry

Розбирався вчора з цікавою ситуацією з моніторингом продуктивності від Sentry. (Мікровідгук: в цілому мені цей продукт подобається, він хоч і не такий виточений як New Relic, але свою задачу виконує успішно.) Ситуація була в тому, що в проєкт насипалося забагато подій — а з кишені висипалася пропорційна сума грошей.

Зазвичай ми не зберігаємо прямо кожну операцію в Sentry. Це було б очевидно надто витратно. Для того є параметр traces_sample_rate - так можна знизити частоту хоч до кожної 100-ї операції, хоч до 10000-ї - як хочете. Також є можливість задати складніший алгоритм в параметрі traces_sampler: наприклад, можна зберігати тільки ті операції, що впливають на наше поточне дослідження продуктивності; або ті, що були надто повільними тощо.

Але дізнався, що розподілені транзакції впливають на цю логіку. Розподілені транзакції в Sentry - це механізм відстеження операції через межі сервісів. Виклики з кожного сервісу будуть поєднані в єдину транзакцію. Це надає розширений контекст; наприклад, можна побачити, які дії користувача призводять до навантаження на внутрішній мікросервіс.

Так от, якщо батьківська операція розподіленої транзакції обрана для збереження, то всі дочірні також будуть збережені! Виходить, що обмежувати частоту збереження має сенс тільки на “кореневому” сервісі. Але коли дивишся статистику, то це може бути зовсім не очевидно, якщо сам кореневий сервіс не пише багато даних.