[{"data":1,"prerenderedAt":269},["ShallowReactive",2],{"article-83-tr":3,"related-83":113,"ArticleBody_DGqWjvCC6IM2BRycUvk3GCDMRpDUFEmbrPpcgmKKik":264},{"id":4,"title":5,"slug":6,"content":7,"metaTitle":5,"metaDescription":8,"coverUrl":9,"views":10,"likes":11,"createdAt":12,"updatedAt":13,"category":14,"tags":23,"author":9,"tableOfContents":60,"locale":110,"translated":111,"indexable":112},83,"Свой мониторинг: Uptime Kuma или Prometheus с Grafana, и почему он обязан жить на отдельном сервере","svoy-monitoring-uptime-kuma-ili-prometheus-s-grafana-i-pochemu-on-obyazan-jit-na-otdelnom-servere","# Свой мониторинг: Uptime Kuma или Prometheus с Grafana, и почему он обязан жить на отдельном сервере\n\n**Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему**\n\n**Сторонний мой проект: [Zapret2UI.](https://github.com/Asterlike/zapret2UI)**\n\n---\n\n>**Я думаю необходимо сделать оговорку, я тоже человек и материала действительно большое количество, в котором невозможно не ошибиться/не быть точным. Перепровяйте то, о чем вам говорят, не доверяйте всему, что читаете(источники внизу)**\n\nСервер лёг в три ночи. Узнали вы об этом в девять утра, когда написал пользователь. При том, что мониторинг у вас стоял, всё было настроено, бот в телегу подключён, проверка каждые тридцать секунд.\n\nТолько стоял он на том же сервере, который и лёг.\n\nСхема настолько распространённая, что её пора считать обрядом посвящения. Человек поднимает VPS, ставит туда сайт, базу, бота, а потом рядышком в докере поднимает Uptime Kuma - «чтобы всё было в одном месте, удобно же». И живёт с ощущением, что прикрыт. Пока не выясняется, что прикрыт он ровно от тех проблем, которые и так бы заметил: упал контейнер, кончилось место, отвалился сертификат. А от того единственного сценария, ради которого мониторинг и заводят - машина целиком перестала отвечать - не прикрыт вообще никак.\n\nРазберём, чем Uptime Kuma отличается от связки Prometheus с Grafana (спойлер: они отвечают на разные вопросы и вообще не конкуренты), сколько это ест ресурсов, как развести мониторилку и цели по разным машинам и не открыть при этом дыру на весь интернет. И отдельно - кто сторожит самого сторожа.\n\n**Кому пригодится:** если у вас один-два сервера и вы до сих пор узнаёте о падениях от людей; если хочется графиков, а не только «ок / не ок»; или если мониторинг уже есть, но вы подозреваете, что он стоит не там, где надо.\n\n> Всё, что ниже, гоняется на самом дешёвом VPS. Отдельная машина под мониторинг обходится дешевле одного часа простоя - если из статьи запомнить одну строчку, пусть будет эта.\n\n---\n\n## Содержание\n\n1. [Почему мониторинг на том же сервере бесполезен](#почему-мониторинг-на-том-же-сервере-бесполезен)\n2. [Два разных вопроса к своей инфраструктуре](#два-разных-вопроса-к-своей-инфраструктуре)\n3. [Uptime Kuma: десять минут и работает](#uptime-kuma-десять-минут-и-работает)\n4. [Prometheus и Grafana: когда нужен ответ «почему»](#prometheus-и-grafana-когда-нужен-ответ-почему)\n5. [Как теперь мониторинг доберётся до целей](#как-теперь-мониторинг-доберётся-до-целей)\n6. [Главная дыра: node_exporter наружу](#главная-дыра-node_exporter-наружу)\n7. [Кто сторожит сторожа](#кто-сторожит-сторожа)\n8. [Как не оглохнуть от алертов](#как-не-оглохнуть-от-алертов)\n9. [Что в итоге брать](#что-в-итоге-брать)\n10. [Частые ошибки](#частые-ошибки)\n11. [Где это поднимать](#где-это-поднимать)\n12. [Короткий итог](#короткий-итог)\n\n[Источники](#источники)\n\n---\n\n## Почему мониторинг на том же сервере бесполезен\n\nНачну отсюда, потому что без этого всё остальное не имеет смысла. Можно взять самый навороченный стек, нарисовать сорок дашбордов и всё равно проспать аварию, если мониторилка сидит внутри того, за чем следит.\n\nРазложим по уровням отказа, от мелкого к крупному.\n\n**Упал один сервис.** Отвалился nginx, ушёл в себя PostgreSQL, контейнер перезапускается по кругу. Вот тут локальный мониторинг работает нормально: он жив, он видит, что порт не отвечает, он шлёт уведомление. Одна беда - такие штуки вы и без него заметите за час, а часто и за минуту.\n\n**Кончилась память, пришёл OOM killer.** Ядро начинает отстреливать процессы по оценке `oom_score`, и жертвой становится не обязательно тот, кто съел память. Прожорливый питоновский скрипт может выжить, а мониторилка на Node.js - улететь первой, просто потому что у неё резидентная память больше. Уведомление не уходит, потому что уходить уже некому.\n\n**Машина встала целиком.** Кернел-паника, зависший гипервизор, сосед по ноде устроил дискотеку и всё встало в iowait. Мониторинг мёртв ровно в тот момент, когда он нужен. Ноль уведомлений, полная тишина.\n\n**Отвалилась сеть.** Вот это самое обидное. Сервер жив, все процессы крутятся, мониторинг честно видит, что локально всё зелёное. Но пакеты наружу не уходят: упал аплинк, хостер словил DDoS и загнал вашу подсеть в блэкхол, IP приехал в блэклист (про это есть отдельная статья(Не вышла на момент написания)). Мониторинг не сломан, он просто не может докричаться. Снаружи ваш сервис недоступен уже сорок минут, а внутри всё прекрасно.\n\n**Лёг дата-центр.** Тут комментарии излишни.\n\nВидите закономерность? Чем серьёзнее авария, тем меньше шансов, что локальный мониторинг о ней сообщит. Он надёжен ровно там, где не нужен, и бесполезен ровно там, где нужен. Это как поставить пожарную сигнализацию внутри печки.\n\n### Есть и вторая причина, менее очевидная\n\nНаблюдатель искажает наблюдаемое. Prometheus с его базой временных рядов постоянно пишет на диск: WAL, потом блоки каждые два часа, потом компакция. Grafana при отрисовке дашборда за месяц выгребает из базы прилично данных и грузит процессор.\n\nИ вот вы сидите, смотрите на график iowait, пытаетесь понять, почему у вас тормозит диск. А часть этого iowait рисует сам мониторинг. На сервере с нормальным NVMe это в пределах погрешности, а вот на дешёвом тарифе с общим дисковым пулом - уже нет. Вы меряете термометром температуру термометра.\n\n### Что считать «отдельным»\n\nТут градация, и она важнее, чем кажется:\n\n- **Тот же сервер.** Не мониторинг. Просто красивые графики, которые исчезнут вместе с сервером.\n- **Другая виртуалка у того же хостера.** Уже лучше, но если это соседняя VPS на той же физической ноде - вы прикрыты только от программных проблем. Нода легла, легли обе.\n- **Другой дата-центр того же хостера.** Нормально. Разные машины, разные аплинки, разное питание. Общая точка отказа остаётся одна: биллинг. Забыли продлить - и всё погасло одновременно, включая мониторинг, который должен был об этом предупредить.\n- **Другой хостер, другая страна.** Правильно. Никакой общей точки отказа, кроме вашей банковской карты.\n\nМой личный порог: пока серверов один-два, хватает отдельной VPS у того же хостера, но в другой локации. Когда их становится больше и на них крутится что-то, за что платят деньги, - выносите к другому провайдеру. Это дешевле, чем кажется: мониторилке не нужен мощный сервер, ей нужна доступность.\n\nТеперь про обратную сторону, иначе картина выйдет слишком благостной. У выноса наружу есть плата: между мониторингом и целью теперь лежит сеть, и все замеры получаются с её примесью. Проверка сказала «ответ за 900 мс» - и это может значить «сайт тормозит», а может «маршрут между двумя ДЦ вечером превращается в тыкву». Отличать одно от другого надо уметь, а про это у меня отдельная статья о том, почему пинг ничего не говорит(Не вышла на момент написания). Но даже с этой примесью внешний мониторинг честнее внутреннего, потому что он меряет то же самое, что видит пользователь.\n\n---\n\n## Два разных вопроса к своей инфраструктуре\n\nСравнивать Uptime Kuma с Prometheus в лоб - примерно как сравнивать градусник с анализом крови. Вроде оба про здоровье, но задачи разные.\n\n**Вопрос первый: оно вообще живое?** Бинарный, снаружи, без доступа внутрь. Дёрнули порт, дёрнули URL, посмотрели на код ответа. Такой подход называют black-box: что внутри коробки, нас не волнует, волнует только отвечает она или нет. Ровно это и делает Uptime Kuma.\n\n**Вопрос второй: почему оно так себя ведёт?** Тут снаружи ничего не увидишь. Нужны цифры изнутри: сколько свободной памяти, какой iowait, сколько открытых соединений, сколько времени процесс провёл в GC. Это white-box, и это территория Prometheus.\n\nРазница проявляется в тот момент, когда что-то сломалось. Kuma скажет: «сайт не отвечал с 03:12 до 03:47». Полезно, спору нет. Но на вопрос «а почему» она не ответит никогда, потому что данных у неё нет - она снаружи стояла. Prometheus покажет, что с 02:50 начала расти память, к 03:10 своп забился под завязку, в 03:12 приехал OOM killer. Вот это уже разбор полётов.\n\nОбратный случай тоже бывает. Prometheus видит только то, до чего дотягивается его scrape. Если у вас лёг DNS и домен перестал резолвиться, все метрики останутся зелёными: сервер жив, процессы крутятся, всё прекрасно. А сайт при этом не открывается ни у кого. Внешняя проверка, которая ходит по домену как обычный пользователь, поймает это мгновенно.\n\nПоэтому «Kuma против Prometheus» - неправильная постановка. Правильная звучит так: чем закрывать вопрос «живо ли», а чем вопрос «почему». Довольно часто ответ на оба - «поставить оба, они не мешают друг другу».\n\n---\n\n## Uptime Kuma: десять минут и работает\n\nОпенсорсная мониторилка от Louis Lam, на Node.js, с приятным интерфейсом и репутацией «поставил и забыл». В августе 2026-го актуальна ветка 2.x, последняя версия 2.5.0.\n\nЧто она умеет проверять: в двойке типов проверок стало за тридцать. Самое ходовое:\n\n- **HTTP(s)** - код ответа, время ответа, редиректы, свои заголовки и метод.\n- **Ключевое слово на странице.** Отдельно ценная штука: сайт может честно отдавать 200 и при этом показывать заглушку «технические работы». Проверка на слово ловит то, что код ответа проглатывает.\n- **TCP-порт** - для баз, прокси, SSH, всего, у чего нет HTTP.\n- **Ping** - именно ICMP. Работает, но врёт чаще всех остальных, об этом ниже.\n- **DNS** - резолвится ли имя и в тот ли адрес.\n- **Срок действия сертификата.** Из коробки, без плясок. Предупредит заранее, что через N дней всё встанет.\n- **Docker-контейнер** через сокет, gRPC, SNMP, Kafka, RabbitMQ и прочая экзотика, которая в двойке подъехала.\n\nКаналов уведомлений в 2.x стало 91. В реальной жизни используются полтора: Telegram и почта. Telegram настраивается за минуту через BotFather, и это правда самый удобный вариант для одиночки.\n\n### Push-мониторы - штука, которую все проглядывают\n\nОбычная проверка работает так: Kuma сама ходит и стучится. Push-монитор работает наоборот: Kuma генерирует уникальный URL, сидит и ждёт, что кто-то на него постучится. Не постучались в срок - уведомление.\n\nЗачем это надо? Затем, что так проверяются вещи, у которых нет порта. Бэкап по крону, ротация логов, скрипт синхронизации, задача, которая должна отработать раз в сутки. Дописываете в конец крон-задания одну строку:\n\n```bash\n0 4 * * * /opt/backup.sh && curl -fsS -m 10 https://kuma.example.com/api/push/AbCdEf12\n```\n\nИ теперь вы узнаете о двух разных бедах: что бэкап упал и что он тихо перестал запускаться вообще. Второе случается чаще, а обнаруживается обычно в самый неподходящий момент - когда бэкап понадобился.\n\n### Страница статуса\n\nKuma умеет генерить публичную страницу со статусом ваших сервисов и историей аптайма. Мелочь, но приятная: если вы что-то держите для людей, ссылка на такую страницу снимает половину вопросов «у вас там всё упало или у меня интернет?».\n\n### Ресурсы и установка\n\nNode.js 20 и выше, база по умолчанию SQLite (в двойке появилась опциональная MariaDB - нужна, если у вас сотни мониторов, при десятке она только лишняя деталь). Ест в районе двух-трёх сотен мегабайт памяти. На тариф 1 vCPU / 1 ГБ встаёт с большим запасом.\n\n```yaml\n# docker-compose.yml\nservices:\n  uptime-kuma:\n    image: louislam/uptime-kuma:2\n    container_name: uptime-kuma\n    restart: unless-stopped\n    volumes:\n      - ./data:/app/data\n    ports:\n      - \"127.0.0.1:3001:3001\"\n```\n\nОбратите внимание на `127.0.0.1` в проброске порта. Наружу вешать веб-морду мониторинга не надо, заверните её через nginx с нормальным TLS, а лучше вообще спрячьте за WireGuard. В админке мониторинга лежит полная карта вашей инфраструктуры: адреса, порты, имена сервисов. Отличный подарок тому, кто её найдёт.\n\nЕщё нюанс при переезде с единички: официальный образ 2.x запускается от непривилегированного пользователя. Штука правильная, но старая папка `data` осталась с рутовыми правами, и контейнер в неё не запишет. Лечится одной командой `chown` перед первым запуском, но если не знать, выглядит как «обновился и всё сломалось».\n\n### Чего она не умеет\n\nИ вот тут начинается граница применимости. Kuma хранит историю пингов, но это не база метрик. Она не ответит:\n\n- почему во вторник вечером всё тормозило (данных о нагрузке у неё нет);\n- сколько осталось места на диске и когда оно кончится;\n- растёт ли потребление памяти третью неделю подряд;\n- какой из ваших пяти сервисов съел процессор.\n\nВсё это не потому, что Kuma плохая, а потому, что она стоит снаружи и внутрь не заглядывает. Хотите ответы - нужна база временных рядов.\n\n---\n\n## Prometheus и Grafana: когда нужен ответ «почему»\n\nТут не одна программа, а конструктор из нескольких. Сразу предупреждаю: порог входа заметно выше, за вечер вы это не соберёте, если раньше не собирали.\n\n### Как это устроено\n\n**Prometheus** - база временных рядов плюс сборщик. Работает по pull-модели: он сам ходит на цели по HTTP и забирает метрики. Никакие агенты никуда ничего не отправляют, инициатива всегда на стороне Prometheus.\n\nЧто он забирает - обычный текст:\n\n```\nnode_memory_MemAvailable_bytes 3.221225472e+09\nnode_filesystem_avail_bytes{mountpoint=\"/\",fstype=\"ext4\"} 2.1474836e+10\nnode_cpu_seconds_total{cpu=\"0\",mode=\"steal\"} 1834.21\n```\n\nИмя метрики, метки в фигурных скобках, число. Всё. Каждые пятнадцать секунд (или сколько настроите) Prometheus дёргает эту страницу и складывает значения к себе с меткой времени. Из этого потом строятся графики и считаются условия для алертов.\n\nОтдельно отмечу приятный побочный эффект pull-модели: если цель не ответила на scrape, Prometheus сам синтезирует метрику `up` со значением ноль. То есть базовая проверка «жив ли хост» получается бесплатно, без всякой отдельной настройки.\n\n**Экспортеры** - маленькие демоны, которые отдают ту самую страницу с метриками. `node_exporter` для системных метрик Linux, `blackbox_exporter` для внешних проверок HTTP/TCP/ICMP (по сути, тот же функционал, что у Kuma, только в терминах Prometheus), плюс отдельные экспортеры под PostgreSQL, nginx, Redis и вообще всё на свете.\n\n**Alertmanager** - отдельный компонент, который принимает сработавшие алерты от Prometheus и решает, что с ними делать: кому слать, как группировать, что заглушить. Разделение неочевидное, но правильное: Prometheus считает условия, Alertmanager разруливает уведомления.\n\n**Grafana** - рисовалка. Ходит в Prometheus, строит графики. С тринадцатой версии (её показали на GrafanaCON в апреле 2026-го) там ещё и своё алертинг-хозяйство, довольно вменяемое.\n\nКстати про версии, потому что в гайдах каша. Третий Prometheus вышел в ноябре 2024-го, и это было первое крупное обновление за семь лет: новый интерфейс на React вместо древнего бутстрапа, полноценная поддержка UTF-8 в именах метрик, встроенный приём OTLP-метрик и Remote Write 2.0. Актуальная LTS на сегодня - 3.13.2. Если натыкаетесь на статью, где скриншоты со старым синим интерфейсом, статье как минимум пара лет, и половина советов оттуда уже мимо.\n\n### PromQL - за что всё это терпят\n\nЯзык запросов, ради которого люди и лезут в эту сложность. Пара примеров, чтобы стало понятно, о чём речь.\n\nРеальная загрузка процессора в процентах:\n\n```promql\n100 - (avg by (instance) (rate(node_cpu_seconds_total{mode=\"idle\"}[5m])) * 100)\n```\n\nТот самый steal time, из-за которого пишут в поддержку (подробно про него - в [статье про оверселл](https://serv.host/articles/59)):\n\n```promql\navg by (instance) (rate(node_cpu_seconds_total{mode=\"steal\"}[5m])) * 100\n```\n\nА вот этот запрос я считаю лучшей рекламой всего стека:\n\n```promql\npredict_linear(node_filesystem_avail_bytes{fstype!~\"tmpfs|overlay\"}[6h], 4*3600) \u003C 0\n```\n\nЧитается так: возьми, как менялось свободное место последние шесть часов, продли тренд на четыре часа вперёд и скажи, уйдёт ли оно в минус. То есть Prometheus предупреждает не «место кончилось», а «место кончится к утру». Разница между этими двумя уведомлениями - разница между спокойным вечером и подъёмом в четыре ночи.\n\nНи одна проверка типа «жив или нет» такого не сделает в принципе. Для прогноза нужна история, а история есть только у базы метрик.\n\n### Сколько это ест\n\nВот тут людей обычно пугают страшилками про гигабайты, поэтому давайте посчитаем на реальных числах.\n\n`node_exporter` со стандартным набором коллекторов отдаёт порядка тысячи с небольшим временных рядов на хост. При интервале в 15 секунд это примерно 70-100 сэмплов в секунду с одного сервера. Пять серверов - около 500 сэмплов в секунду.\n\nФормула для диска простая, она прямо в документации:\n\n```\nместо = время_хранения × сэмплов_в_секунду × байт_на_сэмпл\n```\n\nБайт на сэмпл после сжатия выходит порядка полутора-двух. Считаем месяц хранения для пяти хостов: 2 592 000 секунд × 500 × 2 байта ≈ 2,6 ГБ. Не гигабайты ужаса, а пара гигабайт. По умолчанию Prometheus вообще хранит 15 дней, меняется флагом:\n\n```\n--storage.tsdb.retention.time=30d\n```\n\nС памятью честнее так: сам Prometheus на такой нагрузке уложится в гигабайт, но сверху ещё Grafana (250-500 МБ), Alertmanager и обычно пара экспортеров. Тариф на 1 ГБ вы забьёте и будете жить на грани, на 2 ГБ станет комфортно. Для сравнения: Uptime Kuma в тех же условиях занимает треть гигабайта и не замечает нагрузки вообще.\n\nЕсли тесно с ресурсами, но история нужна - посмотрите в сторону VictoriaMetrics. Совместима с PromQL, ест заметно меньше, ставится в один бинарник. Grafana поверх работает так же.\n\n---\n\n## Как теперь мониторинг доберётся до целей\n\nРазвели по разным машинам - и сразу вылез вопрос, которого на одном сервере не было. Раньше всё лежало на localhost, теперь между мониторингом и целями километры чужой сети.\n\nИ вот тут разница между двумя подходами становится практической, а не философской.\n\n**Uptime Kuma ходит туда, куда и так ходят все.** Ей нужен ваш 443-й порт, ваш 80-й, ваш DNS. Всё это и так открыто наружу, потому что иначе сайт бы не работал. Никакой дополнительной поверхности атаки вы не создаёте, ставится и работает без единой настройки на стороне цели. За это её и любят, хотя вслух проговаривают редко.\n\n**Prometheus, наоборот, лезет внутрь.** Ему нужен `node_exporter` на каждой цели, а это порт 9100, которого раньше не было. И вот его открывать наружу нельзя. Совсем.\n\nПравильная схема выглядит так:\n\n```\n                 [ VPS с мониторингом ]\n                  Prometheus + Grafana\n                    Alertmanager\n                          |\n              WireGuard (10.8.0.0/24)\n                    /           \\\n                   /             \\\n        [ сервер 1 ]           [ сервер 2 ]\n        node_exporter          node_exporter\n        слушает 10.8.0.2       слушает 10.8.0.3\n```\n\nМежду мониторингом и целями поднимается WireGuard, экспортеры слушают только на внутреннем адресе туннеля, снаружи порт 9100 не существует вообще. Prometheus ходит по адресам внутри туннеля.\n\nКонфиг Prometheus в таком раскладе:\n\n```yaml\nglobal:\n  scrape_interval: 15s\n  evaluation_interval: 15s\n\nalerting:\n  alertmanagers:\n    - static_configs:\n        - targets: ['alertmanager:9093']\n\nrule_files:\n  - /etc/prometheus/rules/*.yml\n\nscrape_configs:\n  - job_name: 'node'\n    static_configs:\n      - targets: ['10.8.0.2:9100', '10.8.0.3:9100']\n\n  - job_name: 'blackbox'\n    metrics_path: /probe\n    params:\n      module: [http_2xx]\n    static_configs:\n      - targets:\n          - https://example.com\n    relabel_configs:\n      - source_labels: [__address__]\n        target_label: __param_target\n      - source_labels: [__param_target]\n        target_label: instance\n      - target_label: __address__\n        replacement: blackbox:9115\n```\n\nВторой job - это blackbox_exporter, он же внешняя проверка. Обратите внимание, что живёт он на самой мониторилке и ходит на сайт снаружи, как обычный посетитель. Та самая функция, которую Kuma даёт из коробки и мышкой, а тут собирается из трёх блоков relabel-конфига. Хотите понять разницу в пороге входа - вот она, наглядно.\n\nЭкспортер на целевом сервере запускается с явным адресом:\n\n```ini\n# /etc/systemd/system/node_exporter.service\n[Service]\nUser=node_exporter\nExecStart=/usr/local/bin/node_exporter \\\n  --web.listen-address=10.8.0.2:9100 \\\n  --collector.systemd\nRestart=always\n```\n\nВесь смысл тут в `--web.listen-address=10.8.0.2:9100`. По умолчанию экспортер слушает на всех интерфейсах, и это надо менять руками.\n\n---\n\n## Главная дыра: node_exporter наружу\n\nВыношу в отдельный раздел, потому что это самая массовая ошибка во всём мониторинге, и последствия у неё неприятнее, чем кажется.\n\n`node_exporter` по умолчанию не требует никакой аутентификации. Пришёл, дёрнул `/metrics`, получил всё. И слушает он при запуске без флагов на всех интерфейсах. То есть базовая установка по гайду с первой страницы поиска выставляет ваш сервер наружу.\n\nAqua Security прогоняла это через Shodan и насчитала больше 296 тысяч торчащих в интернет экспортеров и ещё около 40 тысяч открытых серверов Prometheus. Триста с лишним тысяч машин, метрики которых может забрать кто угодно.\n\nЧто оттуда достаётся без единого пароля:\n\n- имя хоста, версия ядра, дистрибутив, аптайм;\n- полный список примонтированных файловых систем с путями и заполненностью;\n- все сетевые интерфейсы с адресами, включая внутренние и VPN-овые;\n- список юнитов systemd, если включён соответствующий коллектор - то есть перечень всего, что у вас крутится;\n- количество ядер, объём памяти, модель железа.\n\nПо отдельности каждый пункт вроде и не секрет. Вместе это готовая карта: что за система, насколько давно не обновлялась (аптайм в 400 дней означает, что ядро не патчилось с той же поры), какие сервисы запущены, какая внутренняя адресация. Разведка, за которую обычно надо потрудиться, отдаётся одним GET-запросом.\n\nОтдельная история - профилировочные ручки Go по адресу `/debug/pprof/`. Они включены по умолчанию во многих компонентах Prometheus и сами по себе на пентестах отлетают как information disclosure. Плюс их можно использовать для отъедания ресурсов: запрос профиля - штука недешёвая.\n\nТри способа закрыться, по возрастанию правильности:\n\n1. **Файрвол.** Тупо и работает: `ufw allow from 10.8.0.1 to any port 9100`. Минимум, ниже которого опускаться нельзя.\n2. **Слушать не на всех интерфейсах.** Флаг `--web.listen-address` на адрес приватной сети или туннеля. Порт просто не существует для внешнего мира.\n3. **WireGuard плюс первые два пункта.** Трафик метрик шифруется, экспортер вообще не виден снаружи, а Prometheus гарантированно разговаривает с вашей машиной, а не с чужой.\n\nЕсли туннель по каким-то причинам не вариант, у экспортера с недавних версий есть встроенные TLS и basic auth через отдельный файл:\n\n```yaml\n# /etc/node_exporter/web-config.yml\nbasic_auth_users:\n  prometheus: $2y$10$\u003Cbcrypt-хэш-пароля>\ntls_server_config:\n  cert_file: /etc/node_exporter/cert.pem\n  key_file: /etc/node_exporter/key.pem\n```\n\nЗапускается с `--web.config.file=/etc/node_exporter/web-config.yml`. Это лучше, чем ничего, но туннель всё равно надёжнее.\n\nИ маленькая, но важная деталь: сама Grafana тоже не должна торчать наружу с дефолтным `admin/admin`. Смешно, но это до сих пор регулярно встречается.\n\n---\n\n## Кто сторожит сторожа\n\nВынесли мониторинг на отдельную машину, молодцы. Теперь у вас две машины, и одна из них может лечь так же тихо, как раньше ложилась первая.\n\nПроблема забавная своей рекурсивностью: мониторинг не может уведомить о собственной смерти. Ставить второй мониторинг для первого - путь в бесконечность.\n\nРешается это через **дохлого сторожа** (dead man's switch): логику переворачивают. Вместо «сообщи, когда сломалось» - «постоянно сообщай, что всё в порядке, и если сообщения прекратились, значит, сломалось».\n\n**Для Prometheus** это делается алертом, который всегда активен:\n\n```yaml\ngroups:\n  - name: watchdog\n    rules:\n      - alert: Watchdog\n        expr: vector(1)\n        labels:\n          severity: none\n        annotations:\n          summary: \"Всегда активен. Пропал - значит, цепочка алертов сдохла\"\n```\n\n`vector(1)` возвращает единицу всегда, безусловно. Алерт горит постоянно и уходит в Alertmanager, оттуда - на внешний сервис, который ждёт этот сигнал каждые N минут. Не дождался - пишет вам. Так проверяется вся цепочка целиком: Prometheus считает, Alertmanager маршрутизирует, канал доставки работает. Отвалилось любое звено - вы об этом узнаете.\n\n**Для Uptime Kuma** есть аккуратный трюк, до которого не сразу додумываешься. Заводите бесплатный аккаунт на healthchecks.io, берёте оттуда ping-URL и добавляете его в Kuma как обычный HTTP-монитор. Для Kuma это рядовая проверка, она будет дёргать адрес каждую минуту, а для healthchecks каждое такое дёрганье и есть сигнал «я жива». Умерла Kuma целиком - пинги прекратились, healthchecks пишет вам. Бесплатного тарифа под такое хватает с запасом.\n\nНе хочется зависеть от чужого сервиса - второй вариант: поднять Kuma в двух локациях и настроить их следить друг за другом крест-накрест. Слегка параноидально, зато всё своё.\n\nОтдельно про канал доставки, потому что это тоже точка отказа. Уведомления должны уходить через инфраструктуру, которая от вашей не зависит - и Telegram тут неожиданно хорош именно этим. Его серверы не ваши, они не лягут вместе с вашим ДЦ. А вот почта со своего же VPS - плохая идея по той же причине, по которой плох локальный мониторинг: упадёт вместе со всем остальным. Плюс письмо с вашего IP может тихо уехать в спам, и вы даже не узнаете (про репутацию IP - есть статья(Ещё не вышла на момент написания)).\n\n---\n\n## Как не оглохнуть от алертов\n\nТехнически настроить уведомления просто. Сложно настроить их так, чтобы через месяц вы не начали смахивать их не глядя.\n\nЯвление называется alert fatigue, и убивает оно мониторинг вернее, чем любая техническая поломка. Приходит двадцать уведомлений в день, девятнадцать из них - ерунда, вы привыкаете игнорировать - и пропускаете двадцатое, настоящее.\n\n**Правило ночного дежурства.** Перед тем как завести алерт, спросите себя: если он придёт в три ночи, я встану? Не встану - значит, это не алерт, а запись в дашборд. Пусть себе рисуется графиком, будильник трогать не должен.\n\n**Алертить на симптомы, а не на причины.** Загрузка процессора 95% сама по себе ничего не значит - может, там видео кодируется, так и должно быть. А вот «сайт отвечает дольше трёх секунд» - симптом, который чувствует пользователь. Хорошее уведомление отвечает на вопрос «кому-то сейчас плохо?», а не «изменилась ли какая-то цифра?».\n\n**Обязательный `for`.** Поле, без которого правила Prometheus превращаются в спам-машину:\n\n```yaml\n- alert: InstanceDown\n  expr: up == 0\n  for: 3m\n  labels:\n    severity: critical\n  annotations:\n    summary: \"{{ $labels.instance }} не отвечает больше трёх минут\"\n```\n\nБез `for: 3m` вы получите уведомление на каждую секундную сетевую икоту. С ним - только когда проблема продержалась достаточно, чтобы быть настоящей. В Kuma то же самое настраивается полем retries: количество неудачных попыток подряд, после которых она поднимает тревогу. Ставьте минимум 2-3, дефолт слишком нервный.\n\n**Группировка.** Лёг гипервизор, отвалились восемь серверов - вы должны получить одно сообщение, а не восемь. За это отвечает Alertmanager:\n\n```yaml\nroute:\n  group_by: ['alertname', 'cluster']\n  group_wait: 30s\n  group_interval: 5m\n  repeat_interval: 4h\n  receiver: telegram\n```\n\n`group_wait` тут особенно полезен: подождать полминуты, вдруг сейчас приедут ещё - и отправить всё одним пакетом.\n\nМинимальный набор того, на что реально стоит алертить, из моего опыта:\n\n- `up == 0` дольше трёх минут;\n- место кончится в ближайшие сутки (тот самый `predict_linear`);\n- сертификат протухает через семь дней;\n- сервис отвечает дольше N секунд стабильно, а не разово;\n- упал systemd-юнит: `node_systemd_unit_state{state=\"failed\"} == 1`.\n\nПять пунктов. Хочется больше - сначала поживите с этими пятью месяц.\n\n---\n\n## Что в итоге брать\n\n| | Uptime Kuma | Prometheus и Grafana |\n|---|---|---|\n| На какой вопрос отвечает | работает или нет | почему оно так себя ведёт |\n| Откуда смотрит | снаружи, как пользователь | изнутри, через агента |\n| Время до первого результата | минут десять | вечер, если раньше не собирали |\n| Память на мониторилке | ~300 МБ | 2 ГБ по-хорошему |\n| Нужен агент на целевом сервере | нет | да, `node_exporter` |\n| Что с историей | история аптайма и времени отклика | все метрики за месяцы, с графиками |\n| Прогнозы | нет | есть, `predict_linear` и компания |\n| Уведомления | 91 канал из коробки, мышкой | Alertmanager или алертинг Grafana, конфигами |\n| Публичная страница статуса | есть | нет |\n| Сколько компонентов держать | один контейнер | четыре и больше |\n\nКак я бы решал:\n\n**Один-два сервера, личные проекты, боты, сайт-визитка.** Uptime Kuma, и не выдумывайте. Отдельная дешёвая VPS, docker compose, Telegram-бот, шесть проверок. Полчаса работы, и закрыто почти всё, ради чего мониторинг вообще заводят.\n\n**Что-то, за что платят деньги.** Ставьте оба. Kuma отвечает на «лежит ли» и будит ночью, Prometheus копит историю и отвечает на «почему». Живут на одной мониторилке и друг другу не мешают, ресурсов хватит на самом скромном тарифе с двумя гигабайтами.\n\n**Только Prometheus, без Kuma** - вариант рабочий, blackbox_exporter закрывает внешние проверки. Но настраивается это заметно дольше, а сертификаты и страница статуса потребуют отдельной возни. Если вы не собираете стек ради самого стека, экономить один контейнер особого смысла нет.\n\n**Только Kuma, без метрик** - тоже нормально, и это, пожалуй, самый частый честный выбор. Просто отдавайте себе отчёт: в момент разбора аварии у вас не будет данных, чтобы понять, что произошло. Будет только время начала и конца.\n\n---\n\n## Частые ошибки\n\n- **Мониторинг на том же сервере.** Главная и самая массовая. Прикрывает ровно от тех проблем, которые вы и так заметите.\n- **`node_exporter` на 0.0.0.0 без файрвола.** Триста тысяч машин в Shodan лежат готовым списком, по которому кто-то регулярно проходится.\n- **Веб-морда мониторинга наружу.** В ней лежит карта всей инфраструктуры: адреса, порты, имена сервисов, время отклика. Прячьте за туннель или хотя бы за нормальную авторизацию.\n- **Проверка только по ICMP.** Ping говорит, что сетевой стек хоста отвечает. Про то, жив ли ваш сервис, он не говорит ничего: сайт может лежать при идеальном пинге. И наоборот - хостер может резать ICMP как класс, и вы получите ложную тревогу на ровном месте. Проверяйте то, чем пользуются люди: HTTP, порт, ключевое слово на странице.\n- **Нет `for` и нет retries.** Уведомление на каждое моргание сети - прямая дорога к тому, чтобы через неделю всё замьютить.\n- **Алерты без дохлого сторожа.** Тишина в канале уведомлений двусмысленна: то ли всё хорошо, то ли мониторинг сдох. Разница принципиальная.\n- **Забыли про ретеншен.** Prometheus по умолчанию хранит 15 дней. Люди месяцами живут в уверенности, что у них есть годовая история, а потом идут смотреть прошлый квартал и обнаруживают пустоту.\n- **Дашборд вместо алертов.** Сорок красивых панелей, на которые никто не смотрит, потому что смотреть в них надо специально. Уведомление приходит само, дашборд - нет. Дашборды нужны для разбора, а не для обнаружения.\n\n---\n\n## Где это поднимать\n\nМониторилке нужны две вещи, и мощность не входит ни в одну из них: стоять **отдельно от того, за чем она следит**, и быть **доступной**. Один процессор, гигабайт памяти, десять гигабайт диска - и Uptime Kuma с полусотней проверок будет скучать. Под Prometheus с историей возьмите два гигабайта.\n\nИз этого следует приятное: отдельная машина под мониторинг обходится в стоимость чашки кофе в месяц, а закрывает сценарий, который иначе не закрывается никак. Мне для такого хватает самого младшего тарифа на [serv.host](https://serv.host/?from=22382) (промокод `promo22382`) - главное брать локацию, отличную от той, где стоит основной сервер, иначе весь смысл разъезда теряется. Пара минут на выбор дата-центра сейчас против «почему я узнал об аварии от пользователя» потом.\n\nПорядок действий на свежей мониторилке:\n\n1. Поднять WireGuard между мониторингом и целями (нужен только для Prometheus, Kuma обойдётся).\n2. Запустить `docker compose` с Uptime Kuma, повесить порт на localhost.\n3. Завести бота в BotFather, вкрутить токен в уведомления.\n4. Добавить проверки: HTTP по домену, ключевое слово, TCP на важные порты, срок сертификата.\n5. Настроить retries хотя бы 3, чтобы не будило на каждый чих.\n6. Прикрутить push-монитор к ночному бэкапу.\n7. Проверить, что оно вообще работает: погасите тестовый сервис и дождитесь уведомления. Мониторинг, который ни разу не срабатывал, - это мониторинг с неизвестным статусом.\n\nПоследний пункт пропускают почти все. А без него у вас не мониторинг, а вера в мониторинг: вроде всё настроено, но сработает ли - никто не проверял.\n\n---\n\n## Короткий итог\n\n- **Мониторинг на той же машине не мониторинг.** Он умирает вместе с тем, за чем следит, и молчит ровно тогда, когда должен кричать.\n- **«Отдельно» - это шкала,** а не да/нет: другая нода лучше того же сервера, другой ДЦ лучше другой ноды, другой хостер лучше всего.\n- **Kuma и Prometheus не конкуренты.** Первая отвечает «живо ли оно», второй - «почему оно так себя ведёт». Вопросы разные, инструменты разные.\n- **Uptime Kuma** ставится за десять минут, ест триста мегабайт, ходит по тем портам, что и так открыты, и закрывает большинство бытовых сценариев.\n- **Prometheus с Grafana** дают историю и прогноз (`predict_linear` предупреждает, что место кончится к утру, а не сообщает, что оно кончилось), но это конструктор на вечер и два гигабайта памяти.\n- **`node_exporter` наружу не выставлять.** Он без пароля отдаёт карту системы, и таких машин в Shodan больше трёхсот тысяч. Туннель, `--web.listen-address`, файрвол.\n- **Дохлый сторож обязателен.** Без него молчание в канале уведомлений означает либо «всё хорошо», либо «мониторинг умер», и вы не отличите одно от другого.\n- **Пять алертов, на которые вы реально встанете ночью,** полезнее сорока, которые вы через неделю замьютите.\n\nСмысл мониторинга не в графиках. Он в том, чтобы узнавать о своих проблемах раньше, чем о них узнают ваши пользователи. Всё остальное детали.\n\n---\n\n**Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему**\n\n**Сторонний мой проект: [Zapret2UI.](https://github.com/Asterlike/zapret2UI)**\n\n---\n\n## Источники\n\n- [Uptime Kuma - репозиторий проекта](https://github.com/louislam/uptime-kuma)\n- [Что нового в Uptime Kuma v2](https://uptimekuma.io/uptime-kuma-v2-whats-new/)\n- [Анонс Prometheus 3.0 - блог проекта](https://prometheus.io/blog/2024/11/14/prometheus-3-0/)\n- [Prometheus - хранение и расчёт места на диске](https://prometheus.io/docs/prometheus/latest/storage/)\n- [node_exporter - репозиторий](https://github.com/prometheus/node_exporter)\n- [blackbox_exporter - внешние проверки](https://github.com/prometheus/blackbox_exporter)\n- [Alertmanager - маршрутизация и группировка](https://prometheus.io/docs/alerting/latest/configuration/)\n- [Aqua Security: 300 000+ открытых серверов Prometheus и экспортеров](https://www.aquasec.com/blog/300000-prometheus-servers-and-exporters-exposed-to-dos-attacks/)\n- [Grafana 13 - анонс на GrafanaCON 2026](https://grafana.com/blog/grafana-13-release-all-the-latest-features/)\n- [VictoriaMetrics - лёгкая альтернатива хранилищу](https://github.com/VictoriaMetrics/VictoriaMetrics)\n","Свой мониторинг: Uptime Kuma или Prometheus с Grafana, и почему он обязан жить на отдельном сервере Вообще я микроразработчик, со мной можно связаться как угодн",null,95,1,"2026-08-09T05:54:48.670Z","2026-09-01T19:52:00.000Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":19},24,"gaydy","Гайды",0,{"id":20,"value":21,"content":22,"sortOrder":18},23,"obshchee","Общее",[24,28,32,36,40,44,48,52,56],{"id":25,"value":26,"content":27},18,"gayd","гайд",{"id":29,"value":30,"content":31},19,"pravila","правила",{"id":33,"value":34,"content":35},113,"monitoring","Мониторинг",{"id":37,"value":38,"content":39},114,"bezopasnost","Безопасность",{"id":41,"value":42,"content":43},115,"rukovodstvo","Руководство",{"id":45,"value":46,"content":47},116,"instrukciya","Инструкция",{"id":49,"value":50,"content":51},117,"tutorial","Туториал",{"id":53,"value":54,"content":55},118,"nastroyka","Настройка",{"id":57,"value":58,"content":59},120,"sovety","Советы",[61,62,65,67,70,72,74,76,78,80,82,84,86,88,90,92,94,96,98,100,102,104,106,108],{"level":11,"text":5},{"level":63,"text":64},2,"Содержание",{"level":63,"text":66},"Почему мониторинг на том же сервере бесполезен",{"level":68,"text":69},3,"Есть и вторая причина, менее очевидная",{"level":68,"text":71},"Что считать «отдельным»",{"level":63,"text":73},"Два разных вопроса к своей инфраструктуре",{"level":63,"text":75},"Uptime Kuma: десять минут и работает",{"level":68,"text":77},"Push-мониторы - штука, которую все проглядывают",{"level":68,"text":79},"Страница статуса",{"level":68,"text":81},"Ресурсы и установка",{"level":68,"text":83},"Чего она не умеет",{"level":63,"text":85},"Prometheus и Grafana: когда нужен ответ «почему»",{"level":68,"text":87},"Как это устроено",{"level":68,"text":89},"PromQL - за что всё это терпят",{"level":68,"text":91},"Сколько это ест",{"level":63,"text":93},"Как теперь мониторинг доберётся до целей",{"level":63,"text":95},"Главная дыра: node_exporter наружу",{"level":63,"text":97},"Кто сторожит сторожа",{"level":63,"text":99},"Как не оглохнуть от алертов",{"level":63,"text":101},"Что в итоге брать",{"level":63,"text":103},"Частые ошибки",{"level":63,"text":105},"Где это поднимать",{"level":63,"text":107},"Короткий итог",{"level":63,"text":109},"Источники","tr",false,true,[114,138,151,165,178,192,205,219,232,249],{"id":115,"title":116,"slug":117,"content":118,"description":118,"coverUrl":9,"views":119,"likes":18,"createdAt":120,"category":121,"tags":123,"author":135},89,"Что такое uptime VPS и почему 99,9% - это не 100%","chto-takoe-uptime-vps","Что такое uptime VPS и почему 99,9% - это не 100% == Когда выбирают VPS, одним из первых показателей, на который обращают внимание, становится uptime. Провайдер",92,"2026-08-17T14:22:17.023Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":122},{"id":20,"value":21,"content":22,"sortOrder":18},[124,125,126,127,128,129,130,134],{"id":25,"value":26,"content":27},{"id":29,"value":30,"content":31},{"id":37,"value":38,"content":39},{"id":41,"value":42,"content":43},{"id":45,"value":46,"content":47},{"id":49,"value":50,"content":51},{"id":131,"value":132,"content":133},119,"ustanovka","Установка",{"id":57,"value":58,"content":59},{"id":136,"name":137,"slug":9},109,"serv.host",{"id":139,"title":140,"slug":141,"content":142,"description":142,"coverUrl":9,"views":143,"likes":11,"createdAt":144,"category":145,"tags":147,"author":150},87,"Хостинг API и бэкенд-приложений на VPS","hosting-api-i-bekend-prilojeniy-na-vps","Хостинг API и бэкенд-приложений на VPS == Если вы разрабатываете сайт, мобильное приложение или собственный сервис, рано или поздно возникает вопрос - где разме",94,"2026-08-17T13:52:11.777Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":146},{"id":20,"value":21,"content":22,"sortOrder":18},[148,149],{"id":25,"value":26,"content":27},{"id":49,"value":50,"content":51},{"id":136,"name":137,"slug":9},{"id":152,"title":153,"slug":154,"content":155,"description":155,"coverUrl":9,"views":156,"likes":11,"createdAt":157,"category":158,"tags":160,"author":9},86,"ИИ в технической работе: где помогает, а где нельзя доверять","ii-v-tehnicheskoy-rabote-gde-pomogaet-a-gde-nelzya-doveryat","ИИ в технической работе: где помогает, а где нельзя доверять Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему Сторонний мой прое",100,"2026-08-09T09:26:13.317Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":159},{"id":20,"value":21,"content":22,"sortOrder":18},[161,162,163,164],{"id":25,"value":26,"content":27},{"id":29,"value":30,"content":31},{"id":41,"value":42,"content":43},{"id":57,"value":58,"content":59},{"id":166,"title":167,"slug":168,"content":169,"description":169,"coverUrl":9,"views":170,"likes":18,"createdAt":171,"category":172,"tags":174,"author":9},85,"Почему ИИ делает не то, что просили, и врёт слишком правдоподобно.","pochemu-ii-delaet-ne-to-chto-prosili-i-vret-slishkom-pravdopodobno","Почему ИИ делает не то, что просили, и врёт слишком правдоподобно. Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему Сторонний мо",97,"2026-08-09T08:51:02.943Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":173},{"id":20,"value":21,"content":22,"sortOrder":18},[175,176,177],{"id":29,"value":30,"content":31},{"id":41,"value":42,"content":43},{"id":57,"value":58,"content":59},{"id":179,"title":180,"slug":181,"content":182,"description":182,"coverUrl":9,"views":115,"likes":18,"createdAt":183,"category":184,"tags":186,"author":9},84,"Почему пинг ничего не говорит: jitter, потери пакетов и bufferbloat","pochemu-ping-nichego-ne-govorit-jitter-poteri-paketov-i-bufferbloat","Почему пинг ничего не говорит: jitter, потери пакетов и bufferbloat Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему Сторонний м","2026-08-09T05:55:28.579Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":185},{"id":20,"value":21,"content":22,"sortOrder":18},[187,188,189,190,191],{"id":29,"value":30,"content":31},{"id":33,"value":34,"content":35},{"id":37,"value":38,"content":39},{"id":41,"value":42,"content":43},{"id":45,"value":46,"content":47},{"id":4,"title":5,"slug":6,"content":8,"description":8,"coverUrl":9,"views":119,"likes":11,"createdAt":12,"category":193,"tags":195,"author":9},{"id":15,"value":16,"content":17,"sortOrder":18,"parent":194},{"id":20,"value":21,"content":22,"sortOrder":18},[196,197,198,199,200,201,202,203,204],{"id":25,"value":26,"content":27},{"id":29,"value":30,"content":31},{"id":33,"value":34,"content":35},{"id":37,"value":38,"content":39},{"id":41,"value":42,"content":43},{"id":45,"value":46,"content":47},{"id":49,"value":50,"content":51},{"id":53,"value":54,"content":55},{"id":57,"value":58,"content":59},{"id":206,"title":207,"slug":208,"content":209,"description":209,"coverUrl":9,"views":210,"likes":11,"createdAt":211,"category":212,"tags":214,"author":9},82,"TLS-фингерпринтинг: как сервер узнаёт твой клиент (JA3/JA4, uTLS)","tls-fingerprinting-kak-server-uznaet-tvoy-klient-ja3ja4-utls","TLS-фингерпринтинг: как сервер узнаёт твой клиент (JA3/JA4, uTLS) Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему Сторонний мой",63,"2026-08-07T21:34:46.778Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":213},{"id":20,"value":21,"content":22,"sortOrder":18},[215,216,217,218],{"id":25,"value":26,"content":27},{"id":29,"value":30,"content":31},{"id":41,"value":42,"content":43},{"id":57,"value":58,"content":59},{"id":220,"title":221,"slug":222,"content":223,"description":223,"coverUrl":9,"views":224,"likes":11,"createdAt":225,"category":226,"tags":228,"author":9},81,"Whois-приватность: кто на самом деле видит твои данные при регистрации домена","whois-privatnost-kto-na-samom-dele-vidit-tvoi-dannye-pri-registracii-domena","Whois-приватность: кто на самом деле видит твои данные при регистрации домена Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему С",56,"2026-08-07T21:03:10.184Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":227},{"id":20,"value":21,"content":22,"sortOrder":18},[229,230,231],{"id":29,"value":30,"content":31},{"id":37,"value":38,"content":39},{"id":41,"value":42,"content":43},{"id":233,"title":234,"slug":235,"content":236,"description":236,"coverUrl":9,"views":237,"likes":11,"createdAt":238,"category":239,"tags":241,"author":247},76,"Локальные LLM, что это, где брать и как запустить.","lokalnye-llm-chto-eto-gde-brat-i-kak-zapustit","Локальные LLM, что это, где брать и как запустить Локальные LLM — это те же самые языковые модели, но веса лежат у тебя на диске, а весь инференс крутится на тв",57,"2026-08-01T12:07:22.600Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":240},{"id":20,"value":21,"content":22,"sortOrder":18},[242,243,244,245,246],{"id":25,"value":26,"content":27},{"id":41,"value":42,"content":43},{"id":45,"value":46,"content":47},{"id":49,"value":50,"content":51},{"id":53,"value":54,"content":55},{"id":45,"name":248,"slug":9},"Lever",{"id":250,"title":251,"slug":252,"content":253,"description":253,"coverUrl":9,"views":254,"likes":11,"createdAt":255,"category":256,"tags":258,"author":9},74,"Xray core на пальцах: xmux, mux, fragment, noise и как это выглядит в трёх боевых конфигах.","xray-core","Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему Сторонний мой проект: Zapret2UI. --- Если хоть раз тащили себе чужой конфиг для",78,"2026-07-31T04:59:26.141Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":257},{"id":20,"value":21,"content":22,"sortOrder":18},[259,260,261,262,263],{"id":25,"value":26,"content":27},{"id":29,"value":30,"content":31},{"id":41,"value":42,"content":43},{"id":45,"value":46,"content":47},{"id":53,"value":54,"content":55},["Island",265],{"key":266,"result":267},"ArticleBody_DGqWjvCC6IM2BRycUvk3GCDMRpDUFEmbrPpcgmKKik",{"head":268},{},1788480198742]