From 19ecb5f40d9afd5298bab179d023915339f21467 Mon Sep 17 00:00:00 2001 From: kgoh <11963737+KGOH@users.noreply.github.com> Date: Thu, 20 Aug 2026 14:01:05 +0200 Subject: [PATCH] add k8s doc --- _sidebar.md | 3 + modules/infra.md | 1 + modules/kubernetes.md | 39 +++++++++++ modules/kubernetes/guide.md | 125 ++++++++++++++++++++++++++++++++++++ modules/kubernetes/setup.md | 29 +++++++++ modules/mcp.md | 4 +- modules/mcp/guide.md | 41 +++++++++++- 7 files changed, 239 insertions(+), 3 deletions(-) create mode 100644 modules/kubernetes.md create mode 100644 modules/kubernetes/guide.md create mode 100644 modules/kubernetes/setup.md diff --git a/_sidebar.md b/_sidebar.md index 960f1d4..eaaf5f4 100644 --- a/_sidebar.md +++ b/_sidebar.md @@ -41,6 +41,9 @@ - [Использование](modules/alert-pack/guide.md) - [Таблица активных оповещений](modules/alert-pack/alert-table-labels.md) - [Инфраструктурный мониторинг](modules/infra.md) + - [Kubernetes](modules/kubernetes.md) + - [Настройка](modules/kubernetes/setup.md) + - [Использование](modules/kubernetes/guide.md) - [Синтетический мониторинг](modules/synthetics.md) - [Настройка](modules/synthetics/setup.md) - [Использование](modules/synthetics/guide.md) diff --git a/modules/infra.md b/modules/infra.md index 39ffd31..ca770f2 100644 --- a/modules/infra.md +++ b/modules/infra.md @@ -16,6 +16,7 @@ GMONIT поддерживает из коробки мониторинг БД Or ## Поддерживаемые платформы - [Мониторинг хоста и Docker-контейнеров](/modules/infra/docker.md) +- [Мониторинг Kubernetes](/modules/kubernetes.md) - [Мониторинг NGINX](/modules/infra/nginx.md) - [Мониторинг СУБД](/modules/infra/db.md) - [Мониторинг PostgreSQL](/modules/infra/postgres.md) diff --git a/modules/kubernetes.md b/modules/kubernetes.md new file mode 100644 index 0000000..b5d6a52 --- /dev/null +++ b/modules/kubernetes.md @@ -0,0 +1,39 @@ +# Kubernetes + +Мониторинг кластеров Kubernetes: от сводки по всему парку до отдельного контейнера. Ключевая особенность — переход от контейнера к приложению, которое внутри него работает, то есть от «контейнеру не хватает ресурсов» к «пользователям приложения плохо». + +## Как это работает + +Инфраструктурный агент GMONIT, развёрнутый в кластере, опрашивает API-сервер и kubelet и присылает в коллектор состояние объектов: кластер, узлы, пространства имён, рабочие нагрузки, поды и контейнеры. Отдельной установки для раздела не требуется — как только агент в кластере начал отчитываться, данные появляются в интерфейсе. + +Раздел построен одинаково для всех видов объектов: список с показателями, из него — проваливание в карточку конкретного объекта с графиками за выбранный период. Переходы между уровнями связаны: из узла видно его поды, из пода — его контейнеры, из контейнера — узел, на котором он работает. + +Связь с APM держится на имени: APM-агент внутри пода отчитывается именем пода как именем хоста, поэтому в карточке пода перечислены приложения, работающие в нём, вместе с Apdex, временем ответа и долей ошибок. + +## Возможности + +- [Сводка по всему парку кластеров: сколько объектов, что не готово, перезапуски и OOM за период](/modules/kubernetes/guide.md#Оценить-состояние-парка) +- [Кластеры: версия, состав, утилизация и доля зарезервированных ресурсов](/modules/kubernetes/guide.md#Оценить-состояние-парка) +- [Узлы: утилизация, занятые слоты подов, заполнение диска и флаги состояния](/modules/kubernetes/guide.md#Найти-перегруженный-узел) +- [Пространства имён: состав подов и потребление ресурсов в разрезе команды или окружения](/modules/kubernetes/guide.md#Посмотреть-нагрузку-по-пространствам-имён) +- [Рабочие нагрузки: сколько реплик заказано, готово, недостаёт и недоступно](/modules/kubernetes/guide.md#Проверить-выкат-рабочей-нагрузки) +- [Поды и контейнеры: состояние, перезапуски, OOM, причина последнего завершения](/modules/kubernetes/guide.md#Найти-перезапускающиеся-поды-и-контейнеры) +- [Троттлинг CPU и потребление относительно лимитов контейнера](/modules/kubernetes/guide.md#Найти-перезапускающиеся-поды-и-контейнеры) +- [Переход от пода к приложениям, которые в нём работают](/modules/kubernetes/guide.md#Связать-под-с-приложением-внутри-него) +- Запросы к тем же данным через AI-агента — раздел доступен по [MCP](/modules/mcp/guide.md#kubernetes) + +## Планируемые возможности + +- Тома и заявки на хранилище (PV, PVC): заполнение, класс хранилища, привязка +- Сервисы и эндпоинты, включая сервис без живых эндпоинтов +- Job и CronJob: успешность и длительность выполнения +- Ход выката по ревизиям и признак застрявшего выката +- Потребление относительно request, а не только относительно лимита: лимиты проставлены у меньшинства контейнеров, поэтому сейчас соответствующие колонки у большинства строк пустые +- Расширенный набор флагов состояния узла +- События кластера (kube events) рядом с метриками +- Коробочные оповещения по Kubernetes + +## Далее + +- [Настройка](/modules/kubernetes/setup.md) — развёртывание агента в кластере и проверка, что данные пошли +- [Использование](/modules/kubernetes/guide.md) — типовые задачи: от сводки по парку до разбора одного контейнера diff --git a/modules/kubernetes/guide.md b/modules/kubernetes/guide.md new file mode 100644 index 0000000..0e903dc --- /dev/null +++ b/modules/kubernetes/guide.md @@ -0,0 +1,125 @@ +# Kubernetes — Использование + +Раздел устроен одинаково на всех уровнях: список объектов с показателями за выбранный период, из него — проваливание в карточку объекта с графиками. Период задаётся в правом верхнем углу и действует на все экраны раздела. + +## Оценить состояние парка + +Понять, есть ли проблема, не открывая каждый кластер. + + + +1. Откройте **Kubernetes → Обзор**. Верхний ряд счётчиков — сколько в парке кластеров, узлов, пространств имён, рабочих нагрузок, подов и контейнеров. +2. Панель **Здоровье** — сколько подов не готовы, сколько было перезапусков и OOM за период. Это три числа, по которым видно, надо ли копать дальше. +3. Панель **Утилизация узлов (allocatable)** — средняя загрузка CPU и памяти по узлам относительно того, что узлы могут отдать подам. +4. Панель **Топ подов по рестартам** — поды с наибольшим числом перезапусков, с пространством имён, числом OOM и причиной последнего завершения. Клик по строке ведёт в карточку пода. +5. Для разреза по кластерам откройте **Kubernetes → Кластеры**: версия Kubernetes, число узлов и **Узлы NotReady**, состав объектов, **CPU %** и **Память %**, а также **CPU заказ. %** и **Память заказ. %**. +6. Клик по кластеру открывает его карточку с утилизацией, списком узлов и списком пространств имён. + +Что важно знать: + +- **«Заказано» и «потребляется» — разные числа.** **CPU заказ. %** — сколько мощности узлов уже зарезервировано под запросы подов, **CPU %** — сколько реально используется. Кластер, где заказано под сотню процентов при низком потреблении, не сможет разместить новые поды, хотя выглядит незагруженным. Это повод пересмотреть запросы, а не добавлять узлы. +- **Перезапуски и OOM считаются за выбранный период,** а не за всё время жизни контейнеров. Ненулевое значение означает, что перезапуски происходят сейчас. +- **Узлы NotReady и не готовые поды считаются по принципу «был в таком состоянии хотя бы раз за период»,** а не на текущий момент. Расширив период, вы увидите больше. +- **Отсутствие кластера в списке — не признак здоровья.** Сбор идёт непрерывно, поэтому пропавший кластер означает проблему с агентом; см. [проверку поступления данных](/modules/kubernetes/setup.md#Проверка-что-данные-пошли). + + + +## Найти перегруженный узел + +Понять, какому узлу тяжело и что на нём работает. + + + +1. Откройте **Kubernetes → Узлы**. В списке — **CPU %** и **Память %** относительно доступного подам, абсолютные **CPU, ядра** и **Память**, занятые слоты **Поды** против **Поды (лимит)**, **Диск %** и признак **Unschedulable**. +2. Отсортируйте по интересующему показателю и откройте узел. +3. В карточке узла панель **Состояние** показывает флаги **Ready**, **DiskPressure**, **MemoryPressure**, **PIDPressure**, **NetworkUnavailable**, признак **Unschedulable**, число запущенных подов против лимита и версию **Kubelet**. +4. Панели **CPU**, **Память**, **Диск** и сетевая панель дают динамику за период — по ним видно, разовый это всплеск или устойчивый рост. +5. Панель со списком подов показывает, что размещено на узле, с потреблением каждого пода. Отсюда можно провалиться в под. + +Что важно знать: + +- **Флаг Ready читается прямо, флаги давления — наоборот.** Для **Ready** нормально значение 1. Для **DiskPressure**, **MemoryPressure**, **PIDPressure** и **NetworkUnavailable** проблема — это как раз 1. Значение −1 означает, что узел перестал сообщать этот флаг. +- **Unschedulable — это не поломка, а решение оператора:** на такой узел не поставят новые поды, что нормально во время обслуживания и подозрительно в остальное время. +- **Дисков у узла два.** Панель **Диск** показывает и файловую систему kubelet, и отдельный раздел под образы контейнеров. Переполнение второго вызывает DiskPressure и вытеснение подов, при этом первый может быть свободен. +- **Занятые слоты подов важны не меньше CPU.** Узел с запасом по ресурсам, но с исчерпанным лимитом подов, новые поды не примет. + + + +## Посмотреть нагрузку по пространствам имён + +Понять, какая команда или окружение потребляет ресурсы и где шумно. + + + +1. Откройте **Kubernetes → Пространства имен**. В списке — **Статус**, число **Поды** и сколько из них **Running**, а также потребление **CPU, ядра** и **Память**. +2. Список отсортирован по потреблению CPU: сверху те, кто ест больше всего. +3. Клик по строке открывает карточку с динамикой CPU и памяти и списком подов пространства имён. +4. Фильтры по кластеру и пространству имён в верхней части раздела сужают все списки — ими удобно оставить одно окружение. + +Что важно знать: + +- **Имена пространств имён не уникальны между кластерами:** `default` и `kube-system` есть в каждом. Поэтому в списке рядом с именем всегда смотрите кластер, а при нескольких кластерах пользуйтесь фильтром. +- **Разница между числом подов и числом Running** — это поды, которые не работают: ждут размещения, тянут образ или падают. Это первый признак того, куда смотреть дальше. +- **Потребление считается по контейнерам пространства имён,** поэтому пространство имён без работающих контейнеров покажет нули при живых объектах. + + + +## Проверить выкат рабочей нагрузки + +Понять, доехал ли выкат до нужного числа реплик. + + + +1. Откройте **Kubernetes → Рабочая нагрузка**. В списке — **Тип** (Deployment, StatefulSet, DaemonSet), имя, **Пространство имен** и четыре числа по репликам: **Желаемо**, **Готово**, **Не хватает**, **Недоступно**. +2. Список отсортирован так, что проблемные нагрузки идут первыми. +3. Клик открывает карточку: панель **Реплики** показывает динамику заказанного и готового числа реплик за период, а список подов — из чего нагрузка состоит сейчас. +4. Сравните **Готово** с **Желаемо**: расхождение означает, что выкат не сошёлся. + +Что важно знать: + +- **«Не хватает» и «Недоступно» — разные вещи.** Не хватает — реплики не созданы вовсе; недоступны — созданы, но не обслуживают запросы. Первое обычно про планирование и ресурсы, второе — про сам под и его проверки готовности. +- **У StatefulSet колонка «Недоступно» пуста:** Kubernetes не сообщает это число для этого типа. Пустое значение здесь означает «неизвестно», а не «ноль». +- **Панель Реплики полезнее моментального снимка:** по ней видно, просело ли число готовых реплик во время выката и вернулось ли обратно. +- **Показываются три типа объектов.** Job и CronJob в разделе пока не отражены. + + + +## Найти перезапускающиеся поды и контейнеры + +Понять, что падает, почему и упирается ли это в лимиты. + + + +1. Откройте **Kubernetes → Поды**. В списке — **Статус**, **Узел**, потребление и две колонки, ради которых сюда и приходят: **Рестарты** и **OOM**. +2. Отсортируйте по **Рестарты** и откройте проблемный под. Панель **Рестарты и OOM** покажет, когда именно это происходило, панель **Контейнеры** — какой из контейнеров пода виноват. +3. Для разреза по контейнерам откройте **Kubernetes → Контейнеры**: помимо **Рестарты** и **OOM** там есть **CPU %** и **Память %** относительно лимитов контейнера и **Throttling**. +4. Откройте карточку контейнера: в ней **Образ**, **Статус**, узел, **Причина завершения** и **Код** последнего завершения, занятое место на файловой системе, а также графики CPU, памяти, перезапусков и троттлинга. +5. Причина `OOMKilled` вместе с ненулевыми перезапусками означает, что контейнеру не хватает памяти по лимиту. + +Что важно знать: + +- **В списках перезапуски считаются за период, а в карточке пода — за всё время жизни контейнера.** Одно и то же слово «Рестарты» отвечает на два разных вопроса: «падает ли сейчас» и «падало ли когда-нибудь». Ноль в списке при большом числе в карточке означает, что контейнер стабилен последнее время. +- **Проценты CPU и памяти у контейнера считаются от его лимита, а не от ёмкости узла.** Там, где лимит не задан, колонка пуста — это не то же самое, что нулевая нагрузка, и таких контейнеров в обычном кластере большинство. +- **Троттлинг не виден по метрикам узла.** Контейнер, упирающийся в лимит CPU, работает медленно, пока узел под ним выглядит незагруженным. Высокий **Throttling** при низком **CPU, ядра** — типичная картина слишком низкого лимита. +- **Список контейнеров показывает верхушку по потреблению CPU,** а не все контейнеры кластера: их в разы больше, чем подов. Сужайте выборку фильтрами по кластеру и пространству имён. + + + +## Связать под с приложением внутри него + +Перейти от проблемы контейнера к тому, что почувствовали пользователи приложения. + + + +1. Откройте карточку пода: **Kubernetes → Поды** и клик по строке. +2. Панель с приложениями показывает APM-приложения, работающие внутри пода, с языком, **Apdex**, временем ответа, RPM и долей ошибок. +3. Из неё переходите в раздел приложения, чтобы разбирать транзакции, ошибки и трассировки обычными средствами APM. +4. Обратный порядок тоже работает: зная приложение, найдите его под в списке подов по имени и посмотрите, не упирается ли контейнер в лимиты. + +Что важно знать: + +- **Связь держится на имени.** APM-агент внутри пода отчитывается именем пода как именем хоста — по нему и сопоставляются инфраструктура и приложения. Никакой отдельной настройки для этого не требуется. +- **Пустой список приложений означает одно из двух:** внутри пода нет APM-агента, либо агент отчитывается другим именем хоста, чем зовётся под. Второе встречается, когда имя хоста задано в конфигурации агента вручную. +- **Это самый короткий путь от инфраструктуры к пользователю.** Троттлинг контейнера или нехватка памяти сами по себе не говорят, стало ли хуже людям; Apdex и доля ошибок приложения — говорят. + + diff --git a/modules/kubernetes/setup.md b/modules/kubernetes/setup.md new file mode 100644 index 0000000..b457de3 --- /dev/null +++ b/modules/kubernetes/setup.md @@ -0,0 +1,29 @@ +# Kubernetes — Настройка + +Раздел не требует включения на коллекторе, и отдельного агента для Kubernetes тоже нет: данные собирает [инфраструктурный агент](/agent_installation_guide/Infra/infra_install.md), развёрнутый в кластере. Настройка сводится к его развёртыванию и проверке, что данные дошли. + +## Развёртывание агента в кластере + +Тот же инфраструктурный агент, что ставится на обычные хосты, в кластере разворачивается по-другому: он опрашивает API-сервер и kubelet, поэтому ему нужны права на чтение объектов кластера и по экземпляру на каждом узле. + + + + +## Проверка, что данные пошли + +Первый экран раздела отвечает на вопрос, дошли ли данные, ещё до того как в них разбираться. + + + +1. Откройте **Kubernetes → Обзор**. +2. Проверьте счётчики в верхнем ряду: **Кластеры**, **Узлы**, **Пространства имен**, **Рабочие нагрузки**, **Поды**, **Контейнеры**. Если агент отчитывается, заполнены все шесть. +3. Убедитесь, что выбранный в правом верхнем углу период включает настоящее время. Все счётчики считаются за период, а не на текущий момент, поэтому окно в прошлом даст пустые значения при живом агенте. +4. Проверьте, что кластер называется так, как вы ожидаете: имя приходит от агента и используется во всех списках раздела и в фильтре по кластеру. + +Что означают неполные данные: + +- **Пустой раздел при живом кластере** — агент не запущен, не дошёл до коллектора или не получил доступ к API-серверу. Сбор идёт непрерывно, поэтому пустота означает проблему со сбором, а не пустой кластер. +- **Есть узлы, но нет подов и контейнеров** — агент видит API-сервер, но не kubelet. Показатели потребления ресурсов приходят именно от kubelet. +- **Заполнен только один кластер из нескольких** — проверьте агент в остальных: каждый кластер отчитывается своим агентом, и отсутствие кластера в списке ничем не отличается от кластера, в котором всё хорошо. + + diff --git a/modules/mcp.md b/modules/mcp.md index 32f9b96..c7c0b2e 100644 --- a/modules/mcp.md +++ b/modules/mcp.md @@ -4,7 +4,7 @@ MCP-сервер коллектора, через который AI-агенты ## Как это работает -Коллектор поднимает MCP-эндпоинт по протоколу Streamable HTTP. Клиент подключается к нему по Bearer-токену — общему секрету коллектора либо персональному токену сервис-аккаунта Grafana — и получает набор инструментов по всем модулям платформы: от состояния приложений и разбора медленной транзакции до инфраструктуры, серверов баз данных, логов, браузерного и мобильного мониторинга, инцидентов, целей уровня сервиса и бизнес-процессов; опционально — произвольный SQL, а через прокси в Grafana — оповещения, дашборды и аннотации. Какой инструмент дёрнуть, агент решает сам по формулировке вопроса. При аутентификации по токену Grafana доступный набор инструментов ограничивается ролью пользователя, а действия можно писать в структурированный журнал аудита для передачи в SIEM. +Коллектор поднимает MCP-эндпоинт по протоколу Streamable HTTP. Клиент подключается к нему по Bearer-токену — общему секрету коллектора либо персональному токену сервис-аккаунта Grafana — и получает набор инструментов по всем модулям платформы: от состояния приложений и разбора медленной транзакции до инфраструктуры, Kubernetes, серверов баз данных, логов, браузерного и мобильного мониторинга, инцидентов, целей уровня сервиса и бизнес-процессов; опционально — произвольный SQL, а через прокси в Grafana — оповещения, дашборды и аннотации. Какой инструмент дёрнуть, агент решает сам по формулировке вопроса. При аутентификации по токену Grafana доступный набор инструментов ограничивается ролью пользователя, а действия можно писать в структурированный журнал аудита для передачи в SIEM. Одним подключением едут не только инструменты, но и **знания о платформе**: методики расследования, карта данных по всем источникам GMONIT и корректный язык запросов к метрикам. Агент подтягивает их сам, ставить ничего не нужно — обычный AI-агент при подключении становится экспертом по GMONIT, а не угадывает структуру данных. @@ -22,6 +22,7 @@ MCP-сервер коллектора, через который AI-агенты - Встроенные методики расследования, карта данных и язык запросов — агент получает их вместе с подключением ([настройка](/modules/mcp/setup.md#Встроенная-экспертиза), [использование](/modules/mcp/guide.md#Встроенная-экспертиза)) - Готовые сценарии расследования — приезжают вместе с подключением ([настройка](/modules/mcp/setup.md#Готовые-сценарии), [использование](/modules/mcp/guide.md#Готовые-сценарии)) +- Подстройка ответа под читателя: инженеру — метрика, разрез и доказательство, тому кто принимает решение — что не работало у пользователей и как долго ([правило](/modules/mcp/guide.md#Встроенная-экспертиза), [аргумент сценария](/modules/mcp/guide.md#Готовые-сценарии)) - Журнал наблюдений между сессиями — по желанию, локально на машине пользователя - [Готовые сценарии расследования — командой прямо в клиенте](/modules/mcp/guide.md#Готовые-сценарии) @@ -34,6 +35,7 @@ MCP-сервер коллектора, через который AI-агенты - [Состояние конкретного приложения](/modules/mcp/guide.md#Состояние-конкретного-приложения) - [Диагностика приложения: транзакции, ошибки, трассировки, запросы к БД, профилирование](/modules/mcp/guide.md#Диагностика-приложения) - [Инфраструктура, серверы баз данных и доступность внешних адресов](/modules/mcp/guide.md#Инфраструктура-и-базы-данных) +- [Kubernetes: кластеры, узлы, ворклоады, поды и контейнеры — с переходом от контейнера к приложению внутри него](/modules/mcp/guide.md#kubernetes) - [Пользовательский опыт: браузер, мобильные приложения, логи](/modules/mcp/guide.md#Пользовательский-опыт) - [Бизнес-процессы: воронка, причины потерь, застрявшие экземпляры](/modules/mcp/guide.md#Бизнес-мониторинг) - [Проверка здоровья ClickHouse и pipeline коллектора](/modules/mcp/guide.md#Здоровье-системы) diff --git a/modules/mcp/guide.md b/modules/mcp/guide.md index 6c4ccf8..3ead133 100644 --- a/modules/mcp/guide.md +++ b/modules/mcp/guide.md @@ -31,7 +31,9 @@ | Инструмент | Что делает | |---|---| | `infra_read` | Хосты, контейнеры, процессы, доступность внешних адресов | +| `k8s_read` | Kubernetes: кластеры, узлы, пространства имён, ворклоады, поды и контейнеры | | `db_servers_read` | Серверы БД (PostgreSQL, MySQL, MSSQL, Redis, Oracle, Elasticsearch, MongoDB, ClickHouse) | +| `one_c_read` | 1С: информационные базы, процессы, сеансы, блокировки, техжурнал и журнал регистрации | **Пользовательский опыт** @@ -73,7 +75,7 @@ | Группа | Требование | |---|---| | Приложения, инфраструктура, схема данных | Работают всегда | -| Мониторинг браузера, логи, бизнес-мониторинг, профилирование, трассировки, инциденты | Включённый соответствующий модуль коллектора — см. [Доступность инструментов](/modules/mcp/setup.md#Доступность-инструментов) | +| Мониторинг браузера, логи, бизнес-мониторинг, профилирование, трассировки, инциденты, 1С | Включённый соответствующий модуль коллектора — см. [Доступность инструментов](/modules/mcp/setup.md#Доступность-инструментов) | | Оповещения, инциденты, цели, дашборды, аннотации, бизнес-мониторинг | Включённые [инструменты Grafana](/modules/mcp/setup.md#Инструменты-grafana) | | `execute_query`, `bm_query` | Включённый [режим произвольного SQL](/modules/mcp/setup.md#Режим-произвольного-sql) и роль **Admin** | | Любое изменение (`*_manage`) | При входе по токену Grafana — роль **Editor** и выше | @@ -96,7 +98,7 @@ MCP GMONIT вместе с инструментами отдаёт **знани Что входит: - **Методики расследования** — три сценария: от сработавшего оповещения к первопричине, от замеченного симптома (когда оповещения нет) к первопричине, и проактивный поиск проблем с предложением алертов на них -- **Карта данных** — все источники GMONIT (APM-агенты, браузерный и мобильный мониторинг, инфраструктура, OpenTelemetry, трассировки, техжурнал 1С), какая таблица за что отвечает и указатель «симптом → где смотреть» +- **Карта данных** — все источники GMONIT (APM-агенты, браузерный и мобильный мониторинг, инфраструктура и Kubernetes, OpenTelemetry, трассировки, техжурнал 1С), какая таблица за что отвечает и указатель «симптом → где смотреть» - **Язык запросов** — набор функций GMONIT для корректного счёта метрик, шаблоны типовых запросов, правила построения дашбордов Практический эффект: @@ -105,6 +107,7 @@ MCP GMONIT вместе с инструментами отдаёт **знани - Метрики считаются правильно. Метрические таблицы хранят агрегаты в специальном виде, и обычные `sum()`/`count()` по ним дают тихо неверные числа — агент знает, что применять вместо них - На вопрос «всё ли в порядке?» агент сначала смотрит активные оповещения, а не гадает - Пустой ответ метрики трактуется как проблема со сбором данных, а не как «всё хорошо» +- Прежде чем отдавать выводы, агент выясняет, для кого ответ. Инженеру нужны метрика, разрез и доказательство; тому, кто принимает решение, — что именно не работало у пользователей и как долго. Если из разговора это не ясно, агент спросит один раз — и дальше держится выбранного регистра, не занижая при этом неопределённость ни для того, ни для другого **Журнал наблюдений (по желанию).** Если расследование выявило неочевидную закономерность, агент предложит записать её в локальный файл `~/.gmonit-skill-journal.md`. В следующих сессиях он прочитает журнал и учтёт прошлые находки. Спросят один раз; отказ — и тема закрыта. Файл лежит на вашей машине, в GMONIT ничего не уходит. @@ -230,6 +233,36 @@ MCP GMONIT вместе с инструментами отдаёт **знани +## Kubernetes + +Кластеры, узлы, пространства имён, ворклоады, поды и контейнеры — и связь пода с приложениями, которые внутри него работают. + + + +| Спросить | Что вернётся | +|---|---| +| «Что с кубером?» | Сводка по всему парку: сколько объектов каждого вида, сколько подов и узлов не готовы, перезапуски и OOM за окно, утилизация узлов и поды с самыми частыми перезапусками | +| «Какие у нас кластеры?» | Версия Kubernetes, число узлов и подов, утилизация и то, сколько ресурсов уже зарезервировано под запросы подов | +| «Каким узлам тяжело?» | Утилизация CPU и памяти, занятые слоты подов, заполнение файловой системы и флаги состояния узла | +| «Что на узле vm-k8s-1?» | Узел в деталях плюс поды, размещённые на нём | +| «Какие пространства имён самые тяжёлые?» | Поды, их состояние, потребление ресурсов и перезапуски в разрезе пространства имён | +| «Все ли ворклоады раскатились?» | Deployment, StatefulSet и DaemonSet: сколько реплик заказано, сколько готово, сколько недостаёт | +| «Что перезапускается?» | Поды и контейнеры с перезапусками и OOM, с причиной последнего завершения | +| «Кто упирается в лимиты?» | Контейнеры с потреблением относительно лимита и долей троттлинга по CPU | +| «Что внутри пода api-gateway-…?» | Контейнеры пода и приложения, которые в нём работают, — с их Apdex, временем ответа и долей ошибок | + +Что важно знать: + +- **Под связан с приложением по имени.** APM-агент внутри пода отчитывается именем пода как именем хоста, поэтому от проблемы контейнера можно сразу перейти к тому, что почувствовали пользователи приложения. Если приложение не нашлось — либо внутри нет APM-агента, либо агент назвался иначе, чем зовётся под. +- **Перезапуски и OOM считаются за выбранное окно, а не за всё время.** Ненулевое число означает, что контейнер перезапускается сейчас. Накопленный счётчик с момента создания контейнера возвращается отдельно — это ответ на другой вопрос: «случалось ли когда-нибудь». +- **Проценты потребления контейнера считаются от его лимита, а не от ёмкости узла.** Там, где лимит не задан, значения нет — это не то же самое, что ноль. +- **Троттлинг не виден по метрикам хоста.** Контейнер, упирающийся в свой лимит CPU, работает медленно, пока узел под ним выглядит незагруженным. Причина «OOMKilled» вместе с перезапусками — почти всегда слишком низкий лимит памяти. +- **Зарезервировано и потребляется — разные числа.** Кластер, где под запросы подов зарезервировано почти всё, не сможет разместить новые поды, даже если фактическая утилизация низкая. Лечится пересмотром запросов, а не добавлением узлов. +- **Пустой ответ означает, что агент не собирает данные из кластера**, а не что кластер пуст: сбор идёт непрерывно, поэтому тишина — это неработающий агент или потерянный доступ к API-серверу. +- **Имена уникальны только внутри родителя** — поды внутри пространства имён, пространства имён внутри кластера. Если имя встречается в двух местах, агент не выберет за вас, а попросит уточнить кластер или пространство имён. + + + ## Пользовательский опыт Что видели реальные посетители сайта и пользователи мобильного приложения, и что писало приложение в логи. @@ -555,6 +588,10 @@ SQL-запрос к ClickHouse, который агент пишет сам по Аргументы необязательны: без них сценарий берёт разумные значения по умолчанию (например, последние три часа) — команда не откажется работать из-за незаполненного поля. +У всех трёх сценариев есть аргумент **для кого ответ**: `an engineer` — тому, кто будет починять, `a business reader` — тому, кто принимает решение. От этого меняется не тон, а состав ответа: инженеру достаются метрика, разрез и доказательство, второму — что именно не работало у пользователей и как долго, а механизм одной фразой в конце. В отчёте о здоровье это те же четыре раздела, но в терминах сервиса; в сводке «что горит» пункты группируются по тому, на что они влияют, и агент говорит, сколько пунктов он отбросил как не влияющие на пользователя. + +Этот аргумент — единственный, у которого нет значения по умолчанию: если его не передать, агент сначала спросит, для кого ответ, и только потом напишет. + Отдельной установки не требуют: приезжают вместе с подключением, как и [встроенная экспертиза](#Встроенная-экспертиза).