Какие вы знаете модели мониторинга и в чем их ключевые различия?

А, ну это ж классика, ёпта! Сидишь такой, пьешь кофе, а тут тебе начинают мозг выносить про мониторинг. Типа, слушай, а ты знаешь, что есть аж три подхода? Я тебе щас так разложу, что сам от себя офигеешь.

Вот смотри, есть у нас две главные, блядь, философии, как следить за своими сервисами, чтобы они не накрылись медным тазом в самый неподходящий момент.

1. Blackbox (смотрим с улицы) vs Whitebox (лезем в трусы): Вот это, блядь, основа основ. Представь, что твой сервис — это ресторан.

• Blackbox мониторинг (как обычный клиент):

  • Суть в чём: Ты подходишь к ресторану как лох обычный. Дверь открывается? Официант "здравствуйте" говорит? Еду приносят, а не тапок? Вот это и проверяешь. Тебе похуй, что там на кухне: шеф повар с похмелья или пельмени разогревают. Главное — результат.
  • Что ловим: Доступность сайта (HTTP 200 OK), не отдаёт ли он вместо страницы "пизда рулю", скорость отклика, отвечают ли порты.
  • Чем тыкаем: Prometheus Blackbox Exporter, разные синтетические проверки в Grafana.

  • Вот смотри, как это в конфиге выглядит, тут всё просто:

    # prometheus.yml
    scrape_configs:
      - job_name: 'blackbox-http'
        metrics_path: /probe
        params:
          module: [http_2xx]
        static_configs:
          - targets:
            - https://api.example.com/health
            - https://frontend.example.com
        relabel_configs:
          - source_labels: [__address__]
            target_label: __param_target
          - source_labels: [__param_target]
            target_label: instance
          - target_label: __address__
            replacement: blackbox-exporter:9115

• Whitebox мониторинг (как санэпидемстанция на кухне):

  • Суть в чём: А вот это уже, сука, серьёзно. Ты лезешь внутрь, в самое нутро. Смотришь, сколько у шефа пульс, не перегрелась ли плита, не кончается ли память у кассового аппарата. Требует, чтобы приложение само стучалось во все двери и кричало о своих проблемах.
  • Что ловим: Всё! Метрики приложения (сколько запросов, сколько ошибок), метрики системы (процессор, память, диск — этот, бля, диск, который всегда на 95%), метрики рантайма (куча JVM, горутины в Go).
  • Чем тыкаем: Node Exporter, библиотеки Prometheus в код, всякие экспортеры.

2. Pull (сам пришёл) vs Push (сам принёс): Тут, бля, целая дилемма. Как метрики собирать-то?

• Pull (Вытягивание): Это как Prometheus — он такой активный, сам ходит по всем сервисам и стучится: "Эй, мудила, давай свои метрики!".

  • Плюсы: Удобно управлять из одной точки. Захотел — постучался к сервису вручную по /metrics, и всё видно. Доверия ебать ноль, сам всё контролируешь.
  • Минусы: А если сервис за NAT-ом сидит или в CI/CD-задаче на 10 секунд запустился и помер? Prometheus его просто не успеет найти, хитрая жопа.

• Push (Отправка): Тут наоборот. Сервис или агент сам бежит на сервер мониторинга и орет: "На, забери мои цифры, я больше не могу!".

  • Плюсы: Работает откуда угодно, хоть из-за семи firewalls. Для кратковременных задач — идеально, успел отправить и сдохнуть.
  • Минусы: А если сервер метрик лёг? Всё, данные в трубу. И ещё надо на каждом агенте конфиги править — терпения ноль ебать.

3. Метрики vs Логи vs Трейсы: Вот это, ёбана, три кита, на которых observability держится. Без этого — нихуя не понятно.

Итог, чувак: Чтобы не бздеть каждую ночь, что всё упало, нужно комбинировать. Blackbox скажет "сервис недоступен, ебать!", а Whitebox объяснит "память кончилась, потому что лог-файл нахуй съел весь диск". Метрики — для графиков и алертов, логи — чтобы копать вглубь, когда приспичило, а трейсы — когда у тебя микросервисов, как говна за баней, и нужно понять, кто из них тормозит всю малину. Вот и вся магия, ебать мои старые костыли.