#Признаки неисправности и область применимости
В Yandex Monitoring график перестал обновляться: старая линия видна, но новые точки не появляются. Причина может быть в выбранном диапазоне времени, метках ресурса, отсутствии сбора внутри гостевой ОС или неработающем агенте пользовательских метрик.
#Почему это происходит
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Неправильные фильтр и интервалЗапрос выбирает старую метку instance, каталог или временной диапазон. | На другом графике те же данные есть | Сбросьте фильтр и расширьте интервал. |
| Агент больше не отправляет данныеГостевые метрики памяти и диска обычно требуют агента или пользовательского экспорта. | Сервисные метрики есть, RAM/диск пустые | Проверьте конфигурацию и состояние агента. |
| Ресурс заменён или остановленНовый ID ресурса создаёт другой набор временных рядов. | Новые точки появились у нового экземпляра | Исправьте метки и идентификаторы на панели. |
#Пошаговая диагностика и устранение
- Разделите системные и пользовательские метрикиОткройте Yandex Monitoring → нужный каталог и график. Запишите точное название метрики, единицу измерения и метки. CPU/сеть облачного ресурса и память внутри ВМ собираются разными способами: отсутствие RAM без агента не означает поломку облака.
- Установите свежий интервалНа графике выберите последние 1–6 часов, сбросьте закреплённый диапазон старой даты и обновите страницу. Снимите слишком строгий фильтр instance_id. Если данные есть после изменения фильтра, причина была в настройке отображения.
- Сравните с встроенной панелью ресурсаВ Compute Cloud откройте ту же ВМ и её сервисные графики. Если облачные показатели обновляются, а пользовательские нет, проблема вероятнее в агенте или экспорте. Если не обновляется ничего, уточните состояние ВМ и наличие сетевой активности.
- Проверьте ID после перевыпуска ресурсаПосле восстановления из образа у новой ВМ будет другой идентификатор. Найдите его в карточке ресурса и сравните с метками
instanceна графике. Исправьте фильтр дашборда, не переименовывая чужие временные ряды.
- Диагностируйте агент внутри LinuxЕсли использован Unified Agent, подключитесь к ВМ и проверьте установленный сервис и его журнал по документированному для вашего образа имени. Не запускайте команду перезапуска, пока не прочитали ошибки конфигурации и не сохранили исходный файл.
- Дополнительная команда по темеLinux · Терминал (Bash)КомандаLinux с systemd; просмотр списка служб, имя агента уточняйте по собственному развёртыванию. Отсутствие строки не означает, что метрики не собираются иным способом.
systemctl list-units --type=service --all | grep -i agent
- Проверьте конфигурацию отправкиПосмотрите выбранный input
linux_metricsлибоmetrics_pull, адрес output и метод авторизации агента. Для Prometheus-формата меток могут быть специальные ограничения, включая зарезервированное имяname. Проверяйте настройки на тестовом узле, без публикации токенов.
- Проверьте IAM и сеть для агентаЕсли агент выдаёт 401/403, сопоставьте сервисный аккаунт с разрешениями на отправку метрик; при тайм-ауте проверьте исходящий HTTPS и DNS. Не открывайте входящие порты и не отключайте проверку TLS ради теста.
- Сравните поступающие точки через интервал сбораПосле точечной правки дождитесь нескольких циклов отправки и обновите график. Проверьте метки имени ресурса и временную зону, сопоставьте пик известной безопасной нагрузки с новой точкой. При неуспехе верните старую конфигурацию агента.
#Как проверить, что проблема исправлена
Новая точка с текущим временем появляется у правильного ресурса, график продолжает обновляться после нескольких интервалов, а встроенные облачные и пользовательские метрики согласуются по назначению.
#Если проблема осталась
Если есть точки по старому ID, но нет по новому, исправьте фильтр. Если метрика не собиралась никогда, для гостевой памяти и диска сначала разверните поддерживаемый агент; Monitoring не читает RAM внутри гостевой ОС автоматически.