Как системы мониторинга собирают данные с серверов и приложений?

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

1. Pull-модель (Опрос, или «Сам пришёл и спросил») Это как будто ты — сервер мониторинга, такой дотошный зануда, который каждые 30 секунд стучится ко всем в дверь и спрашивает: «Ну чё там по показаниям? Жив ещё?». Король этой движухи — Prometheus, конечно.

• Суть: Он сам, этот Prometheus, берёт список адресов (targets) и начинает им названивать по HTTP, вытягивая оттуда метрики в виде простого текста. Никакой инициативы от цели не ждёт.
• Вот смотри, как это в конфиге выглядит, обычный такой prometheus.yml:

  scrape_configs:
    - job_name: 'kubernetes-nodes'
      kubernetes_sd_configs:
        - role: node
      relabel_configs:
        - action: labelmap
          regex: __meta_kubernetes_node_label_(.+)

  Видишь? Он сам находит все ноды в кубере (kubernetes_sd_configs) и начинает их скрестить (scrape). Полный контроль, как у завхоза над складом.

• Чем хорошо: Всё под контролем. Не пришла метрика? Значит, цель сдохла или не отвечает. Нагрузку ты регулируешь сам, не даёшь серверам мониторинга захлебнуться от внезапного потока данных. Безопасность тоже проще — ты сам решаешь, к кому ходить.

2. Push-модель (Отправка, или «Сам принёс, положил и ушёл») А это уже другая философия. На каждом сервере сидит маленький агент-трудяга, типа Telegraf или клиент для StatsD. Он собрал данные и сам, по своей инициативе, пёрнул их на центральный сервер по сети. UDP, TCP, HTTP — не важно.

• Суть: Сервер молча ждёт у моря погоды, а на него сыпятся пакеты с метриками. Как в дверной глазок заглядываешь, а там уже кирпич летит.
• Вот тебе примитивный пример, как в StatsD отправить:

  echo "app.login.count:1|c" | nc -u -w1 statsd-server 8125

  Отправил и забыл. А приняли там или нет — уже не твоя забота, агент свою работу сделал.

• Чем хорошо: Овердохуища пользы для кратковременных задач (jobs), которые сделались и умерли. Или когда твои сервера сидят за NAT'ом или фаерволом, куда снаружи не постучаться. Они сами выходят на связь, когда надо.

3. Сбор логов (Log Shipping, или «Читаем чужие дневники») С логами вообще отдельная песня, там почти всегда push. Ставишь на сервер Filebeat или в контейнер Fluent Bit — и эта мартышлюшка начинает следить за файлами или stdout'ом. Как только что-то новое появилось, она тут же срывается с места и несёт эту простыню текста в Elasticsearch или, что моднее сейчас, в Loki. Типа «держи, разбирайся сам».

4. Экспортеры (Exporters, или «Переводчик с буржуйского») А это мои любимые ребята. Бывает же, что приложение (типа MySQL или Nginx) свои метрики выдает в каком-то своём, ебанько-замороченном виде. Так вот, экспортер (mysql_exporter, nginx-prometheus-exporter) — это такой хитрожопый переводчик. Он сидит рядом с приложением, вытягивает из него нативные метрики, переводит на понятный Prometheus'у язык и выставляет на своём порту. А Prometheus уже приходит и забирает этот готовенький, переведённый вариант. Красота!

Если по-простому, как я делал в кубере: Собирал себе этакий франкенштейн, который просто пиздец как работал.

1. Prometheus — главный зануда, который ходит и pull'ит метрики со всех, кого видит.
2. Fluent Bit — шустрый курьер, который push'ит логи из всех подряд контейнеров прямиком в хранилище.
3. kube-state-metrics — это вообще гениальная штука. Такой экспортер, который превращает состояние куберовских объектов (поды, деплойменты) в обычные метрики. Prometheus потом приходит и забирает их, как свои.

Вот и вся магия. Ничего сложного, просто нужно понимать, когда кого послать — самому сходить за данными или дождаться, пока их принесут. Главное — чтобы система не накрылась медным тазом от нагрузки.