Какие существуют способы для обнаружения сбоев в работе сервиса?

А, слушай, вот этот твой бэкенд, он же как живой организм, блядь! Если он приболел, а ты нихуя не видишь — это пиздец, конец истории. Поэтому надо его насквозь просвечивать, как на рентгене, ёпта! Это и есть Observability, или, по-нашему, «наблюдаемость», чтобы не охуеть с неожиданностей.

Вот смотри, из чего этот цирк состоит:

1. Логирование (Logging)

   • Что это такое: Это когда твоё приложение ведёт дневник, как девочка-подросток, блядь. Записывает всё: «ой, зашёл пользователь», «ой, ошибка 500 вылезла». Особенно важно ловить эти error и panic — они как крики «ААА, ПИЗДЕЦ!» из серверной.
   • Как правильно: Забудь про эти log.Printf("что-то пошло не так: %v", err), это уровень детского сада. Бери структурированное логирование! В Go 1.21+ есть родной slog, а если хочешь скорости — zerolog или zap. Потом эти структурированные логи ты в ELK или Loki засунешь, и они тебе такие графики нарисуют, мать их, красивые!

2. Метрики (Metrics)

   • Что это такое: Циферки, блядь! Всё, что можно измерить. Классика — RED-метод: Rate (сколько запросов в секунду жрём), Errors (сколько раз обосрались), Duration (как долго мучались). Ну и, само собой, CPU, память, диск — чтобы знать, не горит ли что.
   • Как правильно: Ставишь Prometheus, он как жадный бухгалтер — всё собирает и считает. А потом Grafana — это уже художник, который из этих циферок такие дашборды рисует, что просто заебись!

3. Health Checks (Проверки здоровья)

   • Что это такое: Специальные ручки, за которые дёргает оркестратор (типа Kubernetes), чтобы понять, жив ли ты ещё или уже в отключке. Если не отвечаешь — тебя выкидывают из балансировки или вообще перезагружают, без церемоний.
   • Как правильно: Делаешь два эндпоинта, чтобы не путаться:
     • /livez (Liveness probe): «Я дышу?» — проверяет, не завис ли процесс намертво. Упала проверка — контейнеру пизда, его убивают и пересоздают.
     • /readyz (Readiness probe): «Я готов работать?» — проверяет, всё ли в порядке с зависимостями (БД, кеш, другие сервисы). Упала — тебя временно вычёркивают из списка получателей трафика, пока не оклемаешься.

   http.HandleFunc("/readyz", func(w http.ResponseWriter, r *http.Request) {
       if !isDatabaseConnected() {
           http.Error(w, "Database not ready", http.StatusServiceUnavailable)
           return
       }
       w.WriteHeader(http.StatusOK)
   })

   Вот, смотри код. Если БД отвалилась — сервис честно скажет: «Ребят, я пока не готов, идите нахуй». И его не будут трогать, пока он не починит связь.

4. Трассировка (Tracing)

   • Что это такое: Это когда один запрос побежал через десяток микросервисов, и ты хочешь проследить его путь, как в детективе. Где он застрял? Кто его обосрал? Без трассировки в микросервисах — это как искать чёрную кошку в тёмной комнате, особенно если её там нет.
   • Как правильно: Используй OpenTelemetry — это сейчас стандарт де-факто. А результаты смотри в Jaeger или Zipkin. Там будет красивый граф, где видно, на каком сервисе запрос провёл 300 мс, а на каком — 3 секунды, потому что тот, мудак, спал.

5. Алертинг (Alerting)

   • Что это такое: Автоматический стук в дверь, когда начинается пиздец. Чтобы не сидеть и не пялиться в Grafana 24/7, ожидая, когда график уйдёт в космос.
   • Как правильно: Настраиваешь правила в Prometheus Alertmanager или прямо в Grafana: «Если ошибок больше 1% — пиши в Slack», «Если задержка больше 500 мс — звони мне в PagerDuty, пусть разбудит, ёбта!». Главное — не настроить так, чтобы алерты спамили каждые пять минут, а то все на них забьют хуй, и когда реальный пожар начнётся — никто не заметит.

Вот так, собственно, и живём. Собираем логи, метрики, трассируем, проверяем здоровье и ставим алерты. Чтобы когда что-то полетит к чертям, ты не охуевал с вопроса «Что случилось?», а сразу видел — «А, это БД легла, пошёл перезапускать».