Мониторинг веб-приложения на Rust с использованием Prometheus и Grafana

Спасибо.

cadvisor туда же - он попросту в таком сетапе становится не нужен.

При деплое в k8s что-то другое используется для мониторинга контейнеров?

это логично, потому что эти метрики считают разные типы памяти...

Да, к сожалению пока не нашёл такой вариант метрик памяти контейнера и приложения, который измеряет один и тот же тип памяти и при этом корректно отображается на графике

Мониторинг веб-приложения на Rust с использованием Prometheus и Grafana

Интересен был именно такой набор инструментов, возможно потому, что в работе не сталкивался с Zabbix

Мониторинг веб-приложения на Rust с использованием Prometheus и Grafana

Не сталкивался с проблемой высокого потребления CPU, но нашёл issue, где также есть варианты решения

Начало работы с MongoDB и Redis на Rust

Мужики, добавил автоэкспирацию записей в кэше с пояснением в статье :) Джуны могут спать спокойно :)

Начало работы с MongoDB и Redis на Rust

А то потом джуны копируют этот код и оно пролазит в продакшен.

И? Баг? Так и поделом такой компании, без синьоров и тестеров :)

Начало работы с MongoDB и Redis на Rust

Конечно, эти варианты возможны, но не считаю, что

• утверждение о маловероятности опровергнуто

• обязательно стоит предусматривать их обработку в учебном проекте

Начало работы с MongoDB и Redis на Rust

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

Справедливое замечание, поменял

С очисткой кеша, при обновлении записи в монге, тоже вопрос не простой. А что если приложение навернётся сразу после обновления документа в монге, но до того как кеш в редиске будет удалён? Очевидно не хватает "авто-протухания" кеша через какое-то время.

Конкретно здесь:

pub async fn update_planet(
    &self,
    planet_id: &str,
    planet: Planet,
) -> Result<Planet, CustomError> {
    let updated_planet = self
        .mongodb_client
        .update_planet(ObjectId::from_str(planet_id)?, planet)
        .await?;

    let cache_key = self.get_planet_cache_key(planet_id);
    self.redis_connection_manager.clone().del(cache_key).await?;

    Ok(updated_planet)
}

маловероятно, что что-то может пойти не так. Для порядка можно перенести формирование строки ключа в начало метода. Для "продакшн" приложения, возможно, и стоит рассмотреть вариант с автоэкспирацией.

Начало работы с MongoDB и Redis на Rust

Вполне возможно, что не для всех backend задач есть библиотеки или существующие недостаточно развиты. Пока что я сталкивался только со вторым, при этом в части случаев мейнтейнеры были готовы доработать крейты. Кроме того, для многих задач (например, GraphQL, ORM) есть 2 или более поддерживаемых библиотек.

По поводу переключения (в моём случае основными языками были Java/Kotlin), в первые месяцы действительно сложно.

Начало работы с MongoDB и Redis на Rust

Думаю, это могло бы быть справедливо, если бы результаты вызовов этих `await`'ов были логически независимы. Но, например, в этом случае:

pub async fn update_planet(
    &self,
    planet_id: &str,
    planet: Planet,
) -> Result<Planet, CustomError> {
    let updated_planet = self
        .mongodb_client
        .update_planet(ObjectId::from_str(planet_id)?, planet)
        .await?;

    let cache_key = self.get_planet_cache_key(planet_id);
    self.redis_connection_manager.clone().del(cache_key).await?;

    Ok(updated_planet)
}

на мой взгляд, очистка кэша должна выполняться только после завершения обновления в БД.

У нас длинные руки

У Zoom, кажется, непорядок с приватностью:

twitter.com/Ouren/status/1241398181205889024

Создание микросервиса на Quarkus, Kotlin и Gradle

Для рассматриваемого приложения выигрыш есть, и значительный. Причём не только у Quarkus, но и у Micronaut (а также у Ktor и Helidon SE, но это микрофреймворки, а не fullstack). Вот, например, сравнение примерного времени старта сервиса. При использовании GraalVM выигрыш по времени старта будет ещё больше.

Создание микросервиса на Quarkus, Kotlin и Gradle

del

Какие английские слова IT-лексикона мы неправильно произносим чаще всего

Часто замечаю произношение слова «add» как аббревиатуры (АДД (а-дэ-дэ)).

Регистрация и авторизация с помощью Spring Security на примере простого приложения

Хорошая статья для начинающих. Я бы предложил сделать стек более современным и удобным для такого проекта:
— in-memory БД (например, H2)
— Thymeleaf или что-то подобное вместо jsp. Можно пойти дальше и сделать сервис чисто REST API для отдельного фронта
— YAML вместо .properties для конфигурации
— как уже упоминалось, Lombok для геттеров, сеттеров и т. п.
— думаю, было бы интереснее реализовать подобный пример, используя WebFlux вместо Spring MVC

Не Spring Boot’ом единым: обзор альтернатив

Спасибо, посмотрю.

Не Spring Boot’ом единым: обзор альтернатив

Уточню, приложение работает под JDK 12, но сборка (Maven, Gradle) падает.

Не Spring Boot’ом единым: обзор альтернатив

Почему?

Не Spring Boot’ом единым: обзор альтернатив

С удовольствием реализовал бы сервис на Apache Camel (и других фреймворках) будь чуть больше свободного времени :)

Не Spring Boot’ом единым: обзор альтернатив

Тоже была идея включить в проект микросервис на Quarkus. Но, к сожалению, он пока не поддерживает JDK 12, что было одним из требований.

Не Spring Boot’ом единым: обзор альтернатив

По поводу микрофреймворка: этот пункт относится только к Helidon SE, но не к Helidon MP, в котором действительно есть CDI. В Helidon SE его нет, поэтому для DI нужно использовать third-party библиотеку, в данном случае — Koin.