Обновить

3 ключевые метрики, которые спасут микросервисный проект

Современные системы — это сложные экосистемы, где каждая ошибка может стоить бизнесу денег и репутации. Рассказываем, какие метрики нельзя игнорировать, чтобы не пропустить критичные сбои.

Инфраструктурные метрики

Базовые показатели вроде CPU и RAM уже не спасают. Для микросервисов важнее:

Статус подов в Kubernetes:

  • Количество рестартов.

  • Фейлы readiness/liveness проб.

  • Используйте метрику kube_pod_status_ready в Prometheus, чтобы находить «битые» поды.

Трассировка запросов: время выполнения каждого этапа через Jaeger.

Пример: Если поды перезапускаются чаще 5 раз в час — это сигнал к немедленной проверке.

Бизнес-метрики

Инфраструктура может быть идеальной, но если падает конверсия — бизнес теряет клиентов. Отслеживайте:

  • Конверсию платежей (например, от корзины к оплате).

  • Время обработки заказов.

Код для .NET-сервиса:

using App.Metrics;

public class PaymentService {
    private readonly IMetrics _metrics;
    public PaymentService(IMetrics metrics) => _metrics = metrics;
    
    public void ProcessPayment() {
        try {
            // Логика платежа...
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentSuccessCounter);
        } 
        catch {
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentFailedCounter);
        }
    }
}

Эти метрики интегрируются в Grafana, чтобы вы видели, как каждая транзакция влияет на бизнес.

Пользовательский опыт

Даже 1 секунда задержки может увеличить отток пользователей на 7%. Контролируйте:

  • Время отклика API (p95, p99).

  • Частоту ошибок 5xx/4xx.

  • Структурированные логи с контекстом:

{
  "timestamp": "2023-10-05T12:34:56Z",
  "level": "ERROR",
  "userId": "a1b2c3",
  "operation": "process_payment",
  "message": "Failed to charge card: insufficient funds"
}

Теги вроде userId помогают быстро найти все связанные с ошибкой события.

Теги:
Рейтинг0
Комментарии0
ЕЖЕДНЕВНЫЙ ХАБР | 13 АВГ 2026
Охват3.7K

::%16777216 — странный артефакт в логах RDP: история одного расследования

В логах RDP-подключений иногда встречается запись, которая выглядит как ::%16777216 — и это вместо привычного IP-адреса. Про такой артефакт пишут в отраслевых отчетах уже несколько лет. Он всплывает в описаниях атак с туннелированием RDP, и практически всегда авторы упоминают утилиту ngrok. Но при этом почти никто не объясняет, что это за значение, какова его природа и почему оно записано именно так. Складывается впечатление, что авторы либо не знают ответа, либо считают эту деталь слишком мелкой для пояснений.

Я Константин Грищенко, в Positive Technologies я отвечаю за развитие технологий SOC. Работаю в этой сфере больше пяти лет, а всего в практической информационной безопасности — уже 23 года. В ноябре 2024 года в одном из докладов на конференции SOC Forum я в очередной раз увидел упоминание этого артефакта и решил все-таки попробовать разобраться в том, что это такое.

::%16777216 — странный артефакт в логах RDP: история одного расследования

Публикации