Документацияbreadcrumb arrow Grafanabreadcrumb arrow Документация GlaberGraphbreadcrumb arrow Источники данныхbreadcrumb arrow Prometheusbreadcrumb arrow Устранение неполадок
Последнее обновление: августа 4, 2026

Устранение неполадок источника данных Prometheus

В этом документе приведена информация по устранению распространённых ошибок, с которыми вы можете столкнуться при использовании источника данных Prometheus в Grafana.

Ошибки подключения

Следующие ошибки возникают, когда Grafana не может установить или поддерживать подключение к Prometheus.

Не удалось подключиться к Prometheus

Сообщение об ошибке: «There was an error returned querying the Prometheus API»

Причина: Grafana не может установить сетевое подключение к серверу Prometheus.

Решение:

  1. Убедитесь, что URL сервера Prometheus верен в конфигурации источника данных.
  2. Проверьте, что Prometheus запущен и доступен с сервера Grafana.
  3. Убедитесь, что URL включает протокол (http:// или https://).
  4. Убедитесь, что порт верен (порт Prometheus по умолчанию — 9090).
  5. Убедитесь, что нет правил брандмауэра, блокирующих подключение.
  6. Если Grafana и Prometheus работают в отдельных контейнерах, используйте IP-адрес или имя хоста контейнера вместо localhost.
  7. Для Grafana Cloud убедитесь, что вы настроили Private data source connect, если ваш экземпляр Prometheus не является общедоступным.

Тайм-аут запроса

Сообщение об ошибке: «context deadline exceeded» или «request timeout»

Причина: Подключение к Prometheus истекло по тайм-ауту до получения ответа.

Решение:

  1. Проверьте сетевую задержку между Grafana и Prometheus.
  2. Убедитесь, что Prometheus не перегружен и не испытывает проблем с производительностью.
  3. Увеличьте настройку Query timeout в конфигурации источника данных в разделе Interval behavior.
  4. Проверьте конфигурацию тайм-аута сервера Grafana на предмет настроек тайм-аута уровня сервера.
  5. Уменьшите диапазон времени или сложность вашего запроса.
  6. Проверьте, не истекает ли по тайм-ауту подключение на каких-либо сетевых устройствах (балансировщиках нагрузки, прокси).

Не удалось разобрать URL источника данных

Сообщение об ошибке: «Failed to parse data source URL»

Причина: URL, введённый в конфигурации источника данных, недопустим.

Решение:

  1. Убедитесь, что формат URL верен (например, http://localhost:9090 или https://prometheus.example.com:9090).
  2. Убедитесь, что URL включает протокол (http:// или https://).
  3. Удалите любые завершающие слэши или недопустимые символы из URL.

Данные не появляются в Metrics Drilldown или Explore

Симптом: вы успешно проверили подключение источника данных, но никакие данные метрик не появляются в Explore или Metrics Drilldown.

Причина: выбран неверный источник данных, или имя источника данных не соответствует ожиданиям.

Решение:

  1. Убедитесь, что вы выбрали правильный источник данных в раскрывающемся меню источников данных.
  2. При использовании remote_write для отправки метрик в Grafana Cloud имя источника данных следует соглашению grafanacloud-<stackname>-prom.
  3. Проверьте, что метрики активно собираются, запросив up в представлении Explore.
  4. Если используется Grafana Cloud, убедитесь, что URL конечной точки remote_write и учётные данные верны.

Ошибки связности PDC

Сообщения об ошибках: host unreachable, EOF, network unreachable, connection reset by peer, dial tcp: lookup ... no such host

Симптом: запросы Prometheus периодически или постоянно завершаются неудачно при использовании Private data source connect (PDC) для доступа к экземпляру Prometheus за приватной сетью. Проверка источника данных может иногда проходить, но запросы завершаются неудачно под нагрузкой.

Причина: PDC туннелирует трафик через SSH-соединение между Grafana Cloud и вашим агентом PDC. Сбои связности чаще всего вызваны проблемами разрешения DNS, конфигурацией сети на стороне клиента или слишком низкими лимитами подключений агента PDC по умолчанию для объёма запросов.

Решения:

  1. Проверьте разрешение DNS с хоста агента PDC. Агент PDC должен иметь возможность разрешить имя хоста Prometheus с машины, на которой он запущен. Запустите nslookup или dig для URL Prometheus с хоста агента, чтобы подтвердить это.

  2. Проверьте сетевую связность с агента. Убедитесь, что агент PDC может достичь конечной точки Prometheus напрямую (например, curl http://prometheus-host:9090/-/healthy с машины агента).

  3. Увеличьте количество параллельных SSH-соединений. Агент PDC по умолчанию использует 1 параллельное SSH-соединение, что может стать узким местом под нагрузкой от множества вычислений алертов или запросов дашбордов. Увеличьте это, задав флаг --ssh-connections (или переменную среды PDC_SSH_CONNECTIONS) в более высокое значение (например, 4 или 8):

    sh 
    pdc-agent --ssh-connections=4

  4. Проверьте правила брандмауэра. Убедитесь, что исходящее SSH-соединение агента PDC с Grafana Cloud не прерывается правилами брандмауэра, NAT-шлюзами или тайм-аутами простаивающих подключений.

  5. Убедитесь, что агент PDC запущен и работоспособен. Проверьте журналы агента на предмет ошибок подключения или перезапусков. Агент должен поддерживать постоянное подключение к Grafana Cloud.

  6. Проверьте проблемы тайм-аута бездействия. Если подключение разрывается после периодов неактивности, настройте TCP keepalive на хосте или добавьте настройку keepalive в конфигурацию агента PDC.

Note

Проблемы связности PDC почти всегда вызваны сетью на стороне клиента (DNS, правила брандмауэра, маршрутизация), а не Grafana Cloud. Прохождение проверки источника данных не гарантирует поддерживаемую связность под нагрузкой. Она лишь подтверждает, что один запрос выполнился успешно.

Общую настройку и конфигурацию PDC см. в разделах Private data source connect (PDC) и Настройка PDC.

Не удалось проверить сертификат

Сообщение об ошибке: «x509: certificate signed by unknown authority» или «certificate verify failed»

Причина: Grafana не может проверить TLS-сертификат, предоставленный Prometheus.

Решение:

  1. Если используется самоподписанный сертификат, включите Add self-signed certificate в настройках TLS и добавьте ваш сертификат CA.
  2. Убедитесь, что цепочка сертификатов полна и действительна.
  3. Убедитесь, что срок действия сертификата не истёк.
  4. В качестве временного обходного решения для тестирования включите Skip TLS verify (не рекомендуется для продакшена).

Ошибка TLS-рукопожатия

Сообщение об ошибке: «TLS: handshake failure» или «connection reset»

Причина: TLS-рукопожатие между Grafana и Prometheus завершилось неудачно.

Решение:

  1. Убедитесь, что Prometheus настроен на использование TLS.
  2. Проверьте, что версия TLS и наборы шифров совместимы.
  3. Если используются клиентские сертификаты, убедитесь, что они правильно настроены в разделе TLS client authentication.
  4. Убедитесь, что имя сервера соответствует Common Name или Subject Alternative Name сертификата.

Ошибки аутентификации

Следующие ошибки возникают при проблемах с учётными данными или разрешениями.

Неавторизовано (401)

Сообщение об ошибке: «401 Unauthorized» или «Authorization failed»

Причина: Учётные данные аутентификации недействительны или отсутствуют.

Решение:

  1. Убедитесь, что имя пользователя и пароль верны, если используется базовая аутентификация.
  2. Проверьте, что выбранный метод аутентификации соответствует вашей конфигурации Prometheus.
  3. Если используется обратный прокси с аутентификацией, убедитесь, что учётные данные верны.
  4. Для аутентификации AWS SigV4 убедитесь в правильности учётных данных и разрешений IAM. В качестве альтернативы рассмотрите использование источника данных Amazon Managed Service for Prometheus для упрощённой аутентификации AWS.

Ошибки истечения срока действия OAuth-токена (GCP и Azure)

Сообщения об ошибках: «ACCESS_TOKEN_EXPIRED», «401 Unauthorized» в алертинге, но не в Explore

Симптом: запросы в Explore и на дашбордах работают правильно, но вычисления правил алертинга периодически завершаются неудачно с ошибками 401. Это чаще всего встречается с Google Managed Prometheus (GMP) и управляемыми Azure конечными точками Prometheus, использующими аутентификацию OAuth/OIDC.

Причина: бэкенд алертинга Grafana и интерактивный путь запроса (Explore, дашборды) обрабатывают обновление учётных данных по-разному. Вычислитель алертов может использовать кэшированный OAuth-токен за пределами его срока действия из-за проблемы проверки устаревания токена в источнике данных Prometheus. Это приводит к тому, что алертинг завершается неудачно с истёкшими учётными данными, тогда как интерактивные запросы успешны, потому что они запускают свежий обмен токена.

Решения:

Для Google Managed Prometheus (GMP):

  1. Используйте шаблон GCP datasource-syncer: запустите процесс-сайдкар, который обновляет OAuth-токены и обновляет учётные данные источника данных Grafana по расписанию, более короткому, чем время жизни токена (обычно каждые 45 минут для 60-минутного токена). Это гарантирует, что сохранённый токен всегда действителен, когда его использует бэкенд алертинга.
  2. В качестве альтернативы используйте источник данных Google Cloud Monitor со встроенным управлением учётными данными GCP вместо указания источника данных Prometheus на конечную точку GMP.
  3. Если вы работаете на GKE с Workload Identity, убедитесь, что обновление токена сервисной учётной записи Kubernetes работает и проектируемый том токена смонтирован правильно.

Для Azure Managed Prometheus:

  1. Убедитесь, что секрет клиента регистрации приложения Azure AD не истёк.
  2. Если используется Managed Identity, убедитесь, что у идентификатора экземпляра Grafana есть роль Monitoring Data Reader в рабочей области Azure Monitor.
  3. Проверьте, что Forward OAuth identity не включена вместе с аутентификацией Azure AD. Обе используют одни и те же HTTP-заголовки авторизации и конфликтуют друг с другом.

Общие шаги:

  1. Проверьте журналы сервера Grafana на предмет ошибок обновления токена примерно во время неудач алертов.
  2. Убедитесь, что проверка источника данных (Save & test) проходит. Это подтверждает, что текущие учётные данные действительны, но не гарантирует, что у бэкенда алертинга есть свежий токен.
  3. Если проблема сохраняется, установите Alert state if execution error or timeout в Keep Last State, чтобы предотвратить ложные тревоги во время расследования. См. Настройка состояния алерта при ошибках выполнения.

Note

Это поведение кэширования токена — известная проблема, которая получила исправления кода в недавних релизах Grafana. Если вы сталкиваетесь с этим на старой версии Grafana, обновление может решить это. Проверьте журнал изменений Grafana на предмет соответствующих исправлений.

LBAC не ограничивает данные на бэкендах, отличных от Mimir

Симптом: вы включили teamHttpHeadersMimir и настроили правила Team LBAC, но пользователи всё ещё видят все метрики независимо от их командных назначений.

Причина: управление доступом на основе меток (LBAC) для источника данных Prometheus работает только тогда, когда бэкенд — Grafana Cloud Metrics (Mimir) или Grafana Enterprise Metrics (GEM). Оно не работает с Google Managed Prometheus, самостоятельно размещённым Prometheus, Thanos или другими совместимыми с Prometheus конечными точками. Применение LBAC основывается на специфичных для Mimir HTTP-заголовках (X-Scope-OrgID и командных сопоставителях меток), которые другие бэкенды игнорируют.

Решение:

  1. Убедитесь, что ваш бэкенд — Grafana Cloud Metrics или GEM. Если вы используете другой совместимый с Prometheus бэкенд, LBAC не поддерживается.
  2. Для Google Managed Prometheus или других внешних конечных точек используйте разрешения источника данных, чтобы полностью контролировать, какие команды могут получить доступ к источнику данных, вместо управления доступом на уровне отдельных меток.
  3. Если вам нужны ограничения на уровне отдельных меток на бэкенде, отличном от Mimir, рассмотрите проксирование через экземпляр Mimir или использование отдельного источника данных для каждой команды с разными учётными данными, ограниченными соответствующими данными.

Опции аутентификации Azure AD или SigV4 недоступны

Симптом: опции аутентификации Azure AD или SigV4 не отображаются в раскрывающемся списке аутентификации при настройке источника данных Prometheus.

Причина: эти методы аутентификации требуют серверных флагов функций, которые не включены по умолчанию, особенно в Grafana Cloud.

Решение:

  1. Grafana Cloud: свяжитесь с поддержкой Grafana, чтобы запросить включение флага функции для вашего стека. Это не настройка самообслуживания.
  2. Самостоятельно размещённая Grafana: добавьте требуемую настройку в ваш файл конфигурации Grafana:
    • Для Azure AD: установите azure_auth_enabled = true в разделе [auth]
    • Для SigV4: установите sigv4_auth_enabled = true в разделе [auth]
  3. Для Amazon Managed Prometheus: рассмотрите использование выделенного источника данных Amazon Managed Service for Prometheus вместо этого, который обрабатывает аутентификацию AWS изначально без необходимости флага SigV4.

Запрещено (403)

Сообщение об ошибке: «403 Forbidden» или «Access denied»

Причина: у аутентифицированного пользователя нет разрешения на доступ к запрошенному ресурсу.

Решение:

  1. Убедитесь, что у пользователя есть доступ на чтение к API Prometheus.
  2. Проверьте настройки безопасности и конфигурацию управления доступом Prometheus.
  3. Если используется обратный прокси, убедитесь, что прокси не блокирует запрос.
  4. Для AWS Managed Prometheus убедитесь, что политика IAM предоставляет требуемые разрешения. В качестве альтернативы рассмотрите использование источника данных Amazon Managed Service for Prometheus для упрощённой аутентификации AWS.

Ошибки запросов

Следующие ошибки возникают при проблемах с синтаксисом PromQL или выполнением запроса.

Синтаксическая ошибка запроса

Сообщение об ошибке: parse error: unexpected character или bad_data: 1:X: parse error

Причина: запрос PromQL содержит недопустимый синтаксис.

Альтернативная причина: прокси между Grafana и Prometheus требует аутентификации. Когда аутентификация прокси завершается неудачно, прокси перенаправляет запрос на HTML-страницу аутентификации. Grafana не может разобрать HTML-ответ, что приводит к ошибке разбора. Это выглядит как проблема запроса, но на самом деле это проблема аутентификации прокси.

Решение:

  1. Проверьте синтаксис вашего запроса на предмет опечаток или недопустимых символов.
  2. Убедитесь, что имена метрик и меток — допустимые идентификаторы.
  3. Убедитесь, что строковые значения в сопоставителях меток заключены в кавычки.
  4. Используйте браузер выражений Prometheus, чтобы протестировать ваш запрос напрямую.
  5. Обратитесь к документации по запросам Prometheus за руководством по синтаксису.
  6. Если у вас есть прокси между Grafana и Prometheus, убедитесь, что аутентификация прокси настроена правильно. Проверьте журналы вашего прокси на предмет ошибок аутентификации или перенаправлений.

Запрос не возвращает данных для метрики

Симптом: запрос не возвращает данных, и визуализация пуста.

Причина: указанная метрика не существует в Prometheus, или нет данных за выбранный диапазон времени.

Решение:

  1. Убедитесь, что имя метрики написано правильно.
  2. Проверьте, что метрика собирается Prometheus.
  3. Используйте API Prometheus, чтобы просмотреть доступные метрики по адресу /api/v1/label/__name__/values.
  4. Используйте API метаданных цели, чтобы проверить, какие метрики предоставляет цель.
  5. Убедитесь, что диапазон времени включает данные для метрики.

Превышен лимит тайм-аута запроса

Сообщение об ошибке: «query timed out in expression evaluation» или «query processing would load too many samples»

Причина: запрос выполнялся дольше настроенного лимита тайм-аута или вернул бы слишком много образцов.

Решение:

  1. Уменьшите диапазон времени вашего запроса.
  2. Добавьте более конкретные фильтры меток, чтобы ограничить сканируемые данные.
  3. Увеличьте настройку Query timeout в конфигурации источника данных.
  4. Используйте агрегатные функции, такие как sum(), avg() или rate(), чтобы уменьшить количество временных рядов.
  5. Увеличьте настройки query.timeout или query.max-samples в Prometheus, если у вас есть административный доступ.

Слишком много временных рядов

Сообщение об ошибке: exceeded maximum resolution of 11,000 points per timeseries или maximum number of series limit exceeded

Причина: запрос возвращает больше временных рядов или точек данных, чем позволяют настроенные лимиты.

Решение:

  1. Уменьшите диапазон времени вашего запроса.
  2. Добавьте фильтры меток, чтобы ограничить количество возвращаемых временных рядов.
  3. Увеличьте Min interval или Resolution в параметрах запроса, чтобы уменьшить количество точек данных.
  4. Используйте агрегатные функции, чтобы объединить временные ряды.
  5. Настройте Series limit в конфигурации источника данных в разделе Other settings.

Превышен лимит памяти для запросов с высокой кардинальностью

Сообщения об ошибках: «max-estimated-memory-consumption-per-query limit exceeded», «query requires too much memory», «max samples limit reached»

Симптом: запросы к метрикам с высокой кардинальностью (тысячи уникальных комбинаций меток) за длительные диапазоны времени (дни или недели) завершаются неудачно с ошибками лимита памяти или образцов. Короткие диапазоны времени могут работать, но расширение диапазона вызывает сбой.

Причина: Prometheus и Mimir применяют лимиты памяти и образцов на запрос, чтобы защитить систему от исчерпания ресурсов. Метрики с высокой кардинальностью (например, метрики с меткой pod, request_id или user_id), умноженные на длительные диапазоны времени, создают наборы результатов, превышающие эти лимиты.

Решения:

  1. Уменьшите область запроса:

    • Сократите диапазон времени.
    • Добавьте сопоставители меток, чтобы выбрать меньше рядов (например, отфильтруйте по конкретному namespace или job).
    • Увеличьте Min step или используйте больший интервал шага, чтобы уменьшить количество точек данных на ряд.

  2. Используйте правила записи для предварительной агрегации: Создайте правила записи, которые предварительно вычисляют нужную вам агрегацию. Например, если вы часто запрашиваете sum(rate(http_requests_total[5m])) by (service), создайте для него правило записи и запрашивайте вместо этого предварительно агрегированную метрику.

    YAML 
    groups:
  - name: aggregations
    rules:
      - record: service:http_requests_total:rate5m
        expr: sum(rate(http_requests_total[5m])) by (service)

  3. Используйте Adaptive Metrics (Grafana Cloud): Если вы используете Grafana Cloud, Adaptive Metrics автоматически выявляет и агрегирует метрики с высокой кардинальностью, которые не запрашиваются с полным разрешением, снижая затраты на хранение и запросы.

  4. Перестройте дашборды для данных с высокой кардинальностью:

    • Используйте переменные шаблонов, чтобы ограничить запросы подмножеством меток, а не запрашивать все ряды сразу.
    • Разделите обзоры за длительный период (недельные/месячные) на отдельные панели, использующие предварительно агрегированные правила записи.
    • Используйте настройку Max data points в параметрах запроса, чтобы ограничить разрешение для обзорных панелей.

  5. Увеличьте лимиты (только самостоятельно размещённые): Если у вас есть административный доступ к Prometheus или Mimir, вы можете увеличить лимиты в конфигурации сервера:

    • Prometheus: флаг --query.max-samples
    • Mimir: -querier.max-samples, -querier.max-estimated-memory-consumption-per-query

    Note

    Увеличение лимитов позволяет большим запросам выполняться успешно, но также повышает риск исчерпания ресурсов. Предпочитайте уменьшение области запроса или использование правил записи повышению лимитов.

Недопустимая функция или агрегация

Сообщение об ошибке: «unknown function» или «parse error: unexpected aggregation»

Причина: запрос использует недопустимую или неподдерживаемую функцию PromQL.

Решение:

  1. Убедитесь, что имя функции написано правильно и является допустимой функцией PromQL.
  2. Проверьте, что вы используете правильный синтаксис для функции.
  3. Убедитесь, что ваша версия Prometheus поддерживает используемую вами функцию.
  4. Обратитесь к документации по функциям PromQL за доступными функциями.

rate() или increase() возвращают неожиданные значения

Симптом: increase() возвращает дробные значения для целочисленных счётчиков, rate() показывает постоянно растущее значение вместо стабильной скорости в секунду, или сбросы счётчиков вызывают большие всплески на визуализациях.

Возможные причины и решения:

Причина Решение
Дробные значения increase() Ожидаемое поведение. Prometheus использует линейную интерполяцию. Используйте ceil() или floor(), если вам нужны целые числа.
rate() растёт со временем Несколько экземпляров записывают в один и тот же ряд без уникальных меток. Убедитесь, что у каждой цели есть уникальные метки instance/pod, и агрегируйте с sum by.
Всплески сброса счётчиков после перезапусков pod Используйте $__rate_interval или более длинный векторный диапазон для сглаживания всплесков. Исследуйте частые перезапуски как первопричину.
Значения различаются в режиме редактирования и на дашборде Ширина панели влияет на $__interval, что влияет на вычисления окна rate(). Установите Min step для запроса.

Подробные объяснения этого поведения см. в разделе Ожидаемое поведение PromQL.

Агрегация по меткам с точками

Симптом: запросы, которые агрегируют по именам меток, содержащим точки (например, container.name), возвращают неверные или неполные результаты.

Причина: до Grafana 13 была ошибка, при которой метки с точками в именах обрабатывались неправильно во время операций агрегации, таких как sum by или avg by.

Решение:

  1. Обновитесь до Grafana 13 или более поздней версии, которая корректно обрабатывает метки с точками в запросах агрегации.
  2. Убедитесь, что ваш запрос использует правильное имя метки с точками (например, sum by (container.name) (metric_name)).

Ошибки конфигурации

Следующие ошибки возникают, когда источник данных настроен неправильно.

Недопустимый тип Prometheus

Сообщение об ошибке: неожиданное поведение при запросе метрик или меток

Причина: настройка Prometheus type не соответствует вашей фактической совместимой с Prometheus базе данных.

Решение:

  1. Откройте конфигурацию источника данных в Grafana.
  2. В разделе Performance выберите правильный Prometheus type (Prometheus, Cortex, Mimir или Thanos).
  3. Разные типы баз данных поддерживают разные API, поэтому неправильная установка может вызвать неожиданное поведение.

Несоответствие интервала сбора

Симптом: данные выглядят разреженными, или запросы rate() не возвращают данных либо возвращают неполные результаты.

Причина: настройка Scrape interval в Grafana не соответствует фактическому интервалу сбора в Prometheus. Это особенно затрагивает запросы rate(), которые требуют как минимум двух точек данных в указанном временном окне. Например, если ваш фактический интервал сбора — 5 минут, но Grafana использует значение по умолчанию (15 секунд для OSS, 1 минута для Grafana Cloud), запрос вида rate(http_requests_total[1m]) не возвращает данных, потому что в это 1-минутное окно не попадает ни одной точки данных.

Решение:

  1. Проверьте настройку scrape_interval в вашем файле конфигурации Prometheus.
  2. Обновите Scrape interval в конфигурации источника данных Grafana в разделе Interval behavior в соответствии с этим.
  3. Используйте $__rate_interval вместо жёстко заданных временных окон в запросах rate(). Эта переменная автоматически корректируется в зависимости от вашего интервала сбора.
  4. Дополнительную информацию см. в статье $__rate_interval for Prometheus rate queries that just work.

$__rate_interval не возвращает данных или возвращает некорректные значения

Симптом: запросы, использующие $__rate_interval, не возвращают данных, возвращают разные значения в режиме редактирования и на дашборде или создают неожиданные разрывы.

Причина: $__rate_interval вычисляется как max($__interval + scrape_interval, 4 * scrape_interval). Если любой входной параметр этой формулы неверен, результирующее окно неверно: либо слишком маленькое (нет данных), либо несогласованное в разных контекстах.

Распространённые причины и решения:

Причина Решение
Интервал сбора источника данных оставлен по умолчанию 15s, тогда как фактический интервал сбора Prometheus длиннее (например, 60s) Установите Scrape interval в разделе Interval behavior в конфигурации источника данных в соответствии с вашим scrape_interval Prometheus.
Запрос работает в режиме редактирования, но показывает разрывы на дашборде Размер панели влияет на $__interval. Меньшие панели создают большие интервалы. Установите Min step для запроса, чтобы обеспечить согласованный минимум.
Источник данных с включённым LBAC не наследует интервал сбора Установите Min step явно на каждой панели запроса, а не полагайтесь на наследование от источника данных.
Использование $__rate_interval в правилах записи или алертинге Используйте фиксированный интервал (например, [5m]) вместо $__rate_interval в контекстах без панели/дашборда.

Чтобы отладить текущее значение:

  1. Откройте query inspector на панели (нажмите заголовок панели, затем Inspect > Query).
  2. Посмотрите на развёрнутый запрос, отправленный в Prometheus. Фактическое значение интервала, заменяющее $__rate_interval, видно в запросе.
  3. Сравните это значение с вашим фактическим интервалом сбора. Если оно меньше вашего интервала сбора, вам нужно настроить интервал сбора источника данных или задать Min step.

Подробную документацию о том, как работает $__rate_interval и как его настроить, см. в разделе Использование $__rate_interval.

Проблемы производительности

Следующие проблемы влияют на скорость запросов и свежесть данных.

Медленная производительность запросов

Симптом: запросы выполняются долго, дашборды загружаются медленно, или индикатор загрузки не исчезает.

Причина: запросы сканируют слишком много данных, сервер Prometheus перегружен, или сетевое подключение медленное.

Решение:

  1. Уменьшите диапазон времени вашего запроса.
  2. Добавьте более конкретные фильтры меток, чтобы ограничить сканируемые данные.
  3. Увеличьте Min step в параметрах запроса, чтобы уменьшить количество точек данных.
  4. Проверьте производительность сервера Prometheus и использование ресурсов.
  5. Включите Disable metrics lookup в конфигурации источника данных для больших экземпляров Prometheus.
  6. Включите Incremental querying (beta), чтобы кэшировать результаты запросов.
  7. Используйте правила записи, чтобы предварительно агрегировать часто запрашиваемые данные.
  8. Для метрик с высокой кардинальностью см. Превышен лимит памяти для запросов с высокой кардинальностью.

Данные выглядят задержанными или отсутствуют последние точки

Симптом: визуализация не показывает самые последние данные даже после обновления.

Причина: тайминг сбора, дрейф часов или настройки обновления дашборда.

Решение:

  1. Проверьте диапазон времени дашборда и настройки обновления.
  2. Убедитесь, что Scrape interval настроен правильно в настройках источника данных.
  3. Убедитесь, что Prometheus завершил сбор цели (есть задержка между интервалом сбора и доступностью данных).
  4. Проверьте наличие проблем синхронизации часов между Grafana и Prometheus (используйте NTP).
  5. Для rate() и подобных функций самый последний незавершённый интервал сбора не будет иметь достаточно точек данных. Это ожидаемо.

Экземпляры не отображаются

Симптом: данные экземпляров не появляются на графиках, хотя вы этого ожидаете.

Причина: экземпляры требуют конкретной конфигурации как в источнике данных, так и в редакторе запросов.

Решение:

  1. Убедитесь, что экземпляры настроены в настройках источника данных в разделе Exemplars (должна быть определена хотя бы одна ссылка экземпляра).
  2. Проверьте, что ваша версия Prometheus поддерживает экземпляры (2.26+).
  3. Убедитесь, что ваше инструментированное приложение действительно отправляет данные экземпляров вместе с метриками.
  4. Убедитесь, что источник данных трассировки правильно настроен для ссылки экземпляра.
  5. Включите переключатель Exemplars в редакторе запросов для конкретного запроса.
  6. Экземпляры появляются только с типом запроса Range, а не Instant.

Ошибки аннотаций

Следующие проблемы возникают при использовании Prometheus в качестве источника данных для аннотаций.

Аннотации не появляются

Симптом: вы настроили запрос аннотации Prometheus, но никакие аннотации не появляются на вашем дашборде.

Возможные причины и решения:

Причина Решение
Запрос не возвращает данных в текущем диапазоне времени Убедитесь, что запрос возвращает результаты в Explore для диапазона времени дашборда.
Запрос возвращает непрерывные данные (слишком много аннотаций) Каждая возвращённая точка данных создаёт аннотацию. Если запрос возвращает сотни точек, аннотации могут отрисовываться, но быть слишком плотными, чтобы их увидеть. Увеличьте Min step или уточните запрос, чтобы возвращать данные только в моменты событий.
Выбран неверный источник данных Убедитесь, что в конфигурации аннотации выбран правильный источник данных Prometheus.
Аннотация отключена Проверьте, что переключатель аннотации включён (значок глаза) в настройках аннотаций дашборда.
Несовпадение диапазона времени Расширьте диапазон времени дашборда, чтобы включить события, которые вы ожидаете увидеть.

Note

Аннотации Prometheus создают маркер для каждой точки данных, возвращённой запросом. Автоматической фильтрации нулевых значений нет. Если вам нужны аннотации только в определённые моменты, ваше выражение PromQL должно возвращать данные только в эти моменты (например, используя > 0, changes() > 0 или метрику ALERTS).

Дополнительную информацию о настройке аннотаций см. в разделе Аннотации Prometheus.

Ошибки алертинга

Следующие проблемы возникают при использовании Prometheus с Grafana Alerting.

Временные ошибки алертов, вызывающие ложные тревоги

Сообщения об ошибках: sse.dependencyError, sse.dataQueryError, «context deadline exceeded», «i/o timeout»

Симптом: правила алертинга периодически срабатывают из-за ошибок выполнения, а не из-за реальных пересечений порогов. Дежурные команды получают ложноположительные уведомления. История состояний алертов показывает состояния ошибок, вызванные временными проблемами бэкенда (сетевые сбои, ответы HTTP 502/500, тайм-ауты), а не фактическим выполнением условий метрик.

Причина: по умолчанию, когда правило алертинга сталкивается с ошибкой выполнения или тайм-аутом, Grafana устанавливает состояние алерта в Alerting, что запускает алерт. Временные проблемы связности между Grafana и Prometheus (i/o timeouts, deadline exceeded, кратковременные простои) запускают это поведение, даже если основная метрика не пересекла свой порог.

Решение:

  1. Откройте каждое затронутое правило алертинга для редактирования.
  2. В разделе условий алерта измените Alert state if execution error or timeout с Alerting на Keep Last State.
  3. Сохраните правило.

Это гарантирует, что алерт сохраняет своё предыдущее состояние во время временных ошибок и срабатывает только тогда, когда успешное вычисление подтверждает пересечение порога.

Если ошибки часты, также исследуйте:

  1. Стабильность сети между Grafana и Prometheus.
  2. Использование ресурсов Prometheus (ЦП, память, дисковый ввод-вывод).
  3. Настройку Query timeout в конфигурации источника данных. Увеличьте её, если сложные запросы регулярно превышают лимит.
  4. Сложность запроса. Упростите запросы или используйте правила записи для предварительного вычисления дорогостоящих выражений.

Подробности конфигурации см. в разделе Настройка состояния алерта при ошибках выполнения.

Правило алертинга не вычисляется

Симптом: правило алертинга, использующее запрос Prometheus, показывает ошибки вычисления или остаётся в состоянии «No Data».

Возможные причины и решения:

Причина Решение
Переменные шаблонов в запросе Запросы алертов не поддерживают переменные шаблонов. Замените переменные жёстко заданными значениями.
Тайм-аут запроса Упростите запрос или увеличьте тайм-аут вычисления. Используйте правила записи для сложных выражений.
Источник данных недоступен Убедитесь, что подключение источника данных Prometheus работает (проверьте его в настройках источника данных).
Нет данных в диапазоне Убедитесь, что у метрики есть свежие данные. Проверьте, что Prometheus активно собирает цель.

Правила, управляемые источником данных, не видны

Симптом: правила алертинга Prometheus не появляются в интерфейсе Grafana Alerting.

Решение:

  1. Убедитесь, что Manage alerts via Alerting UI включено в конфигурации источника данных.
  2. Проверьте, что в Prometheus настроены правила алертинга в его файлах правил.
  3. Убедитесь, что Grafana может получить доступ к конечной точке API правил Prometheus (/api/v1/rules).
  4. Для Prometheus (в отличие от Mimir) интерфейс Alerting поддерживает только просмотр существующих правил, а не создание новых.

Дополнительную информацию об алертинге с Prometheus см. в разделе Алертинг Prometheus.

Получение дополнительной помощи

Если проблемы сохраняются после следования этому руководству по устранению неполадок:

  1. Обратитесь к документации Prometheus за руководством по API и PromQL.
  2. Просмотрите форумы сообщества Grafana на предмет похожих проблем.
  3. Свяжитесь с поддержкой Grafana, если вы пользователь Cloud Pro, Cloud Contracted или Enterprise.
  4. При сообщении о проблемах указывайте:
    • Версию Grafana
    • Версию и тип Prometheus (Prometheus, Mimir, Cortex, Thanos)
    • Сообщения об ошибках (удалите конфиденциальную информацию)
    • Шаги для воспроизведения
    • Соответствующую конфигурацию, такую как настройки источника данных, тайм-аут запроса и настройки TLS (удалите токены, пароли и другие учётные данные)