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

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

В этом документе приведены решения распространённых проблем, с которыми вы можете столкнуться при настройке или использовании источника данных Amazon CloudWatch. Инструкции по настройке см. в разделе Настройка CloudWatch.

Note

Проверка работоспособности источника данных проверяет разрешения и для метрик, и для логов. Если ваша политика IAM предоставляет доступ только к одному из них (например, только к метрикам или только к логам), проверка работоспособности отобразит красный статус. Однако сервис, на который у вас есть разрешения, всё равно остаётся доступным — вы можете запрашивать метрики или логи в зависимости от того, какие разрешения настроены.

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

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

Сообщение об ошибке Вероятная причина См. раздел
AccessDenied: User is not authorized to perform: cloudwatch:... В политике IAM отсутствуют необходимые разрешения CloudWatch. Access Denied или Not authorized to perform this operation
InvalidClientTokenId or UnrecognizedClientException: The security token included in the request is invalid Учётные данные недействительны, деактивированы или ротированы, либо идёт временный инцидент Grafana Cloud. InvalidClientTokenId или UnrecognizedClientException
AccessDenied: ... not authorized to perform: sts:AssumeRole Неверно настроено доверительное отношение роли, ARN роли или external ID. Unable to assume role
AccessDenied: ... no VPC endpoint policy allows the cloudwatch:ListMetrics action Действие блокируется политикой VPC endpoint или service control policy (SCP). Access blocked by a VPC endpoint policy or service control policy

“Access Denied” or “Not authorized to perform this operation”

Симптомы:

  • Save & test завершается ошибкой “Access Denied”
  • Запросы возвращают ошибки авторизации
  • Пространства имён, метрики или dimension не загружаются

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

Причина Решение
В политике IAM отсутствуют необходимые разрешения Привяжите соответствующую политику IAM к вашему пользователю или роли. Для метрик нужны cloudwatch:ListMetrics, cloudwatch:GetMetricData и связанные разрешения. Для логов нужны logs:DescribeLogGroups, logs:StartQuery, logs:GetQueryResults и связанные разрешения. Полные примеры политик см. в разделе Настройка CloudWatch.
Неверный access key или secret key Проверьте учётные данные в консоли AWS в разделе IAM > Users > ваш пользователь > Security credentials. При необходимости создайте новые учётные данные.
Срок действия учётных данных истёк Для временных учётных данных создайте новые. Для access key проверьте, не были ли они деактивированы или удалены.
Неверный регион AWS Проверьте, что регион по умолчанию в конфигурации источника данных совпадает с регионом, где находятся ваши ресурсы.
У роли IAM нет разрешений в запрашиваемом регионе AWS оценивает разрешения по регионам. Если у вашей роли есть доступ к CloudWatch только в некоторых регионах, запрос к другому региону вернёт AccessDenied, причём в ошибке регион может не указываться. Установите Default Region источника данных в регион, где у роли есть разрешения, и запрашивайте только регионы, разрешённые вашей политикой IAM.
Неверный Assume Role ARN Проверьте формат ARN роли: arn:aws:iam::<account-id>:role/<role-name>. Убедитесь, что роль существует в консоли AWS.

“InvalidClientTokenId” or “UnrecognizedClientException”

Симптомы:

  • Save & test завершается ошибкой InvalidClientTokenId: The security token included in the request is invalid
  • Запросы завершаются ошибкой UnrecognizedClientException: The security token included in the request is invalid
  • Ошибка появляется внезапно, без каких-либо изменений конфигурации

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

Причина Решение
Access key или secret key недействителен либо введён с ошибкой Проверьте учётные данные в консоли AWS в разделе IAM > Users > ваш пользователь > Security credentials. Введите их заново в конфигурации источника данных.
Учётные данные были деактивированы, удалены или ротированы Создайте новые учётные данные в AWS и обновите конфигурацию источника данных.
Временные учётные данные истекли Создайте новые временные учётные данные или переключитесь на долгоживущий метод аутентификации, например Assume Role.
Временный инцидент Grafana Cloud Если несколько источников данных одновременно завершаются ошибкой InvalidClientTokenId, а ваши учётные данные не менялись, проверьте страницу статуса Grafana Cloud на наличие текущего инцидента, прежде чем ротировать учётные данные.

“Unable to assume role”

Симптомы:

  • Аутентификация завершается ошибкой при использовании Assume Role ARN
  • В ошибке упоминаются STS или AssumeRole, например AccessDenied: User is not authorized to perform: sts:AssumeRole

Решения:

  1. Убедитесь, что доверительное отношение роли IAM позволяет учётным данным Grafana принять её.
  2. Проверьте, что trust policy содержит правильный principal (пользователя или роль, от имени которых работает Grafana).
  3. Если вы используете метод аутентификации Grafana Assume Role, убедитесь, что trust policy использует точный ID учётной записи AWS Grafana и external ID, указанные в информационном блоке на вкладке Settings источника данных. Указание другого ID учётной записи — распространённая ошибка, из-за которой запрос assume-role завершается неудачей.
  4. Если вы используете external ID, убедитесь, что он точно совпадает и в trust policy роли, и в конфигурации источника данных Grafana.
  5. Убедитесь, что основные учётные данные имеют разрешение sts:AssumeRole.
  6. Проверьте, что ARN роли указан верно и роль существует.

Пример trust policy:

JSON 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<your-account-id>:user/<grafana-user>"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "<your-external-id>"
        }
      }
    }
  ]
}

“Save & test” passes but queries return no data

Симптомы:

  • Save & test завершается успешно, но панели и редактор запросов не возвращают данных
  • Пространства имён, метрики или dimension не загружаются, хотя проверка соединения прошла
  • Проблема проявляется только при использовании Assume Role ARN

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

Причина Решение
Проверка соединения проверяет только шаг принятия роли Когда вы настраиваете Assume Role ARN, Save & test подтверждает, что основные учётные данные могут выполнить sts:AssumeRole. Он не проверяет, что у принимаемой роли есть разрешения CloudWatch или Logs. Привяжите необходимые разрешения на запросы к принимаемой роли, а не только к основным учётным данным.
У принимаемой роли отсутствуют разрешения CloudWatch Добавьте в политику принимаемой роли действия для метрик и логов, такие как cloudwatch:ListMetrics, cloudwatch:GetMetricData, logs:DescribeLogGroups и logs:StartQuery. Полные примеры политик см. в разделе Настройка CloudWatch.
Разрешения привязаны к неверному идентификатору Убедитесь, что политика привязана к роли, указанной в Assume Role ARN, а не к пользователю или роли IAM, предоставляющим основные учётные данные.

Источник данных перестаёт работать примерно через час

Симптомы:

  • Изначально источник данных работает, затем примерно через час запросы начинают завершаться ошибкой
  • В ошибках упоминается истёкший или недействительный security token
  • Повторное сохранение источника данных или перезапуск Grafana временно восстанавливает доступ, пока он снова не перестанет работать

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

Причина Решение
Временные учётные данные истекли и не были обновлены Методы, использующие временные учётные данные, такие как Assume Role или STS, выдают краткоживущие токены. Если источник данных использует статические временные учётные данные, переключитесь на метод аутентификации с автоматическим обновлением, например Assume Role с долгоживущими основными учётными данными или ролью инстанса EKS/EC2. См. раздел Аутентификация AWS.

Access blocked by a VPC endpoint policy or service control policy

Симптомы:

  • Учётные данные действительны и политика IAM разрешает действие, но запросы всё равно завершаются ошибкой AccessDenied
  • В ошибке упоминается политика VPC endpoint, например AccessDenied: ... no VPC endpoint policy allows the cloudwatch:ListMetrics action
  • Доступ не работает только изнутри VPC или в ограниченной учётной записи, например в среде FedRAMP

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

Причина Решение
Политика VPC endpoint ограничивает, какие действия разрешены Обновите политику на VPC endpoints CloudWatch, Logs, EC2 или STS, чтобы разрешить необходимые действия, такие как cloudwatch:ListMetrics и cloudwatch:GetMetricData.
Service control policy (SCP) явно запрещает необходимое действие Проверьте service control policies, применённые к учётной записи или организационной единице. Явный Deny в SCP переопределяет любой Allow в политике IAM, поэтому действие должно быть разрешено на обоих уровнях.
Запросы идут через неверный endpoint Убедитесь, что регион источника данных и любой пользовательский endpoint соответствуют VPC endpoints, которые разрешают необходимые действия.

AWS SDK Default authentication not working

Симптомы:

  • Проверка источника данных завершается ошибкой при использовании AWS SDK Default
  • Работает локально, но не работает в продакшене

Решения:

  1. Убедитесь, что учётные данные AWS настроены в среде, где работает Grafana.
  2. Проверьте наличие учётных данных в стандартных местах:
    • Переменные окружения (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)
    • Общий файл учётных данных (~/.aws/credentials)
    • Метаданные инстанса EC2 (если работа идёт на EC2)
    • Роль задачи ECS (если работа идёт в ECS)
    • Сервисная учётная запись EKS (если работа идёт в EKS)
  3. Убедитесь, что у процесса Grafana есть разрешение на чтение файла учётных данных.
  4. Для EKS с IRSA настройте security context пода так, чтобы пользователь 472 (grafana) имел доступ к проецируемому токену. Подробности см. в разделе Аутентификация AWS.

Credentials file not found

Симптомы:

  • В ошибке указано, что файл учётных данных не удаётся прочитать
  • Аутентификация завершается ошибкой при использовании опции “Credentials file”

Решения:

  1. Создайте файл учётных данных по пути ~/.aws/credentials для пользователя, под которым работает сервис grafana-server.
  2. Убедитесь, что файл имеет правильные разрешения (0644).
  3. Если файл существует, но не работает, переместите его в /usr/share/grafana/ и установите разрешения 0644.
  4. Убедитесь, что имя профиля в конфигурации источника данных совпадает с профилем в файле учётных данных.

Ошибки соединения

Эти ошибки возникают, когда Grafana не может достичь endpoints AWS CloudWatch.

“Request timed out” or connection failures

Симптомы:

  • Проверка источника данных завершается по тайм-ауту
  • Запросы завершаются ошибками тайм-аута
  • Периодические проблемы с соединением

Решения:

  1. Проверьте сетевую связность между сервером Grafana и endpoints AWS.
  2. Проверьте, что правила firewall разрешают исходящий HTTPS (порт 443) к сервисам AWS.
  3. Если вы используете VPC, убедитесь в правильной настройке NAT gateway или VPC endpoint.
  4. Для Grafana Cloud, подключающегося к приватным ресурсам, настройте Private data source connect.
  5. Проверьте, правильно ли указан регион по умолчанию — неверные регионы могут вызывать более длительные тайм-ауты.
  6. Увеличьте настройки тайм-аута, если запросы обрабатывают большие объёмы данных.

Custom endpoint configuration issues

Симптомы:

  • Соединение не устанавливается при использовании пользовательского endpoint
  • URL endpoint отклонён

Решения:

  1. Убедитесь, что формат URL endpoint указан верно.
  2. Убедитесь, что endpoint доступен с сервера Grafana.
  3. Проверьте, что endpoint поддерживает необходимые API AWS.
  4. Для VPC endpoints убедитесь, что политика endpoint разрешает необходимые действия.

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

Эти ошибки возникают при запросах к CloudWatch Metrics.

“No data” or empty results

Симптомы:

  • Запрос выполняется без ошибок, но не возвращает данных
  • Графики показывают сообщение “No data”

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

Причина Решение
В диапазоне времени нет данных Расширьте диапазон времени дашборда. Метрики CloudWatch имеют разные сроки хранения в зависимости от разрешения.
Неверное пространство имён или имя метрики Убедитесь, что пространство имён (например, AWS/EC2) и имя метрики (например, CPUUtilization) указаны верно.
Неверные dimensions Убедитесь, что имена и значения dimensions точно соответствуют вашим ресурсам AWS.
Match Exact включён некорректно Когда включён Match Exact, все dimensions должны быть указаны. Попробуйте отключить его, чтобы проверить, появятся ли метрики.
Period слишком большой Уменьшите значение period или установите “auto”, чтобы гарантировать возврат точек данных для вашего диапазона времени.
Пользовательские метрики не настроены Добавьте пространства имён пользовательских метрик в конфигурации источника данных в поле Namespaces of Custom Metrics.

“Metric not found” or metrics don’t appear in drop-down

Симптомы:

  • Ожидаемые метрики не появляются в редакторе запросов
  • Выпадающий список метрик пуст для пространства имён
  • Конкретная метрика отсутствует в выпадающем списке, хотя она есть в консоли CloudWatch

Решения:

  1. Проверьте, что метрика существует в выбранном регионе.
  2. Для пользовательских метрик добавьте пространство имён в Namespaces of Custom Metrics в конфигурации источника данных.
  3. Проверьте, что политика IAM содержит разрешение cloudwatch:ListMetrics.
  4. CloudWatch ограничивает ListMetrics до 500 результатов на страницу. Чтобы получить больше метрик, увеличьте параметр list_metrics_page_limit в файле конфигурации Grafana.
  5. Введите имя метрики напрямую в поле Metric name. Для некоторых пространств имён AWS источник данных использует предопределённый список метрик, поэтому более новые или менее распространённые метрики могут не отображаться в выпадающем списке, хотя их всё равно можно запрашивать. Если метрика есть в вашей консоли CloudWatch, введите её точное имя, чтобы запросить её.
  6. Используйте Query Inspector, чтобы проверить запрос и ответ API.

Dimension values not loading

Симптомы:

  • Выпадающий список значений dimension не заполняется
  • Поиск по маске не возвращает результатов

Решения:

  1. Проверьте, что политика IAM содержит разрешение cloudwatch:ListMetrics.
  2. Проверьте, что пространство имён и метрика выбраны до того, как могут загрузиться значения dimension.
  3. Для dimensions EC2 убедитесь, что предоставлены разрешения ec2:DescribeTags и ec2:DescribeInstances.
  4. Значения dimension требуют существующих метрик — если ни одна метрика не совпадает, значения не появляются.

“Too many data points” or API throttling

Симптомы:

  • Запросы завершаются ошибками throttling
  • Производительность снижается при большом количестве панелей

Решения:

  1. Увеличьте значение period, чтобы уменьшить количество точек данных.
  2. Сократите диапазон времени ваших запросов.
  3. Используйте меньше dimensions или запросов по маске на панель.
  4. Запросите увеличение квоты на количество запросов GetMetricData в секунду в консоли AWS Service Quotas.
  5. Включите кэширование запросов в Grafana, чтобы уменьшить количество вызовов API.

Этот раздел описывает throttling на уровне запроса. Общеаккаунтные ограничения скорости и увеличение квот см. в разделе Ошибки throttling API.

Metric math expression errors

Симптомы:

  • Выражение возвращает ошибки
  • Указанные метрики не найдены

Решения:

  1. Убедитесь, что у каждой указанной метрики задан уникальный ID.
  2. Проверьте, что ID метрик начинаются со строчной буквы и содержат только буквы, цифры и подчёркивания.
  3. Убедитесь, что все указанные метрики находятся в одном запросе.
  4. Проверьте, что синтаксис выражения соответствует документации AWS Metric Math.
  5. Выражения метрик нельзя использовать с оповещениями Grafana, если они ссылаются на другие строки запросов.

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

Эти ошибки возникают при запросах к CloudWatch Logs.

“Query failed” or logs don’t appear

Симптомы:

  • Запросы к логам возвращают ошибки
  • Данные логов не отображаются

Решения:

  1. Убедитесь, что имена групп логов указаны верно и существуют в выбранном регионе.
  2. Проверьте, что политика IAM содержит разрешения logs:StartQuery, logs:GetQueryResults и logs:DescribeLogGroups.
  3. Убедитесь, что диапазон времени содержит данные логов.
  4. Убедитесь, что синтаксис запроса корректен. Для CloudWatch Logs Insights QL протестируйте запрос в консоли AWS.
  5. Выберите правильный язык запросов (Logs Insights QL, OpenSearch PPL или OpenSearch SQL) в зависимости от синтаксиса вашего запроса.

Log query timeout

Симптомы:

  • Запрос выполняется долго, затем завершается неудачей
  • В ошибке упоминается тайм-аут

Решения:

  1. Увеличьте настройку Query Result Timeout в конфигурации источника данных (по умолчанию 30 минут).
  2. Сузьте диапазон времени, чтобы уменьшить объём сканируемых данных.
  3. Добавьте в запрос фильтры, чтобы ограничить результаты.
  4. Разбейте сложные запросы на меньшие, более целенаправленные.
  5. Для оповещений приоритет имеет тайм-аут, заданный в файле конфигурации Grafana.

Log groups not appearing in selector

Симптомы:

  • Селектор групп логов пуст
  • Не удаётся найти ожидаемые группы логов

Решения:

  1. Проверьте, что политика IAM содержит разрешение logs:DescribeLogGroups.
  2. Проверьте, что группы логов существуют в выбранном регионе.
  3. Для наблюдаемости между учётными записями убедитесь в правильности разрешений IAM для oam:ListSinks и oam:ListAttachedLinks.
  4. Используйте поиск по префиксу, чтобы отфильтровать группы логов, если групп много.
  5. Проверьте, что выбранная учётная запись (для работы между учётными записями) содержит ожидаемые группы логов.

OpenSearch SQL query errors

Симптомы:

  • Запросы OpenSearch SQL завершаются неудачей
  • Синтаксические ошибки в SQL-запросах

Решения:

  1. Укажите идентификатор или ARN группы логов в предложении FROM:

    SQL 
    SELECT * FROM `log_group_name` WHERE `@message` LIKE '%error%'

  2. Для нескольких групп логов используйте функцию logGroups:

    SQL 
    SELECT * FROM `logGroups(logGroupIdentifier: ['LogGroup1', 'LogGroup2'])`

  3. Amazon CloudWatch поддерживает только подмножество команд OpenSearch SQL. Поддерживаемый синтаксис см. в документации CloudWatch Logs.

Ошибки шаблонных переменных

Эти ошибки возникают при использовании шаблонных переменных с источником данных CloudWatch.

Variables return no values

Симптомы:

  • Выпадающий список переменной пуст
  • Дашборд не загружается из-за ошибок переменных

Решения:

  1. Убедитесь, что соединение с источником данных работает.
  2. Проверьте, что политика IAM содержит разрешения для типа запроса переменной:
    • Regions: дополнительные разрешения не нужны.
    • Namespaces: дополнительные разрешения не нужны.
    • Metrics: требуется cloudwatch:ListMetrics.
    • Dimension Values: требуется cloudwatch:ListMetrics.
    • EC2 Instance Attributes: требуется ec2:DescribeInstances.
    • EBS Volume IDs: требуется ec2:DescribeVolumes.
    • Resource ARNs: требуется tag:GetResources.
    • Log Groups: требуется logs:DescribeLogGroups.
  3. Для зависимых переменных убедитесь, что у родительских переменных выбраны допустимые значения.
  4. Убедитесь, что регион указан верно (используйте “default” для региона по умолчанию источника данных).

Дополнительную информацию о шаблонных переменных см. в разделе Шаблонные переменные CloudWatch.

Multi-value template variables cause query failures

Симптомы:

  • Запросы завершаются ошибкой при выборе нескольких значений dimension
  • Ошибка об ограничениях search expression

Решения:

  1. Search expressions ограничены 1024 символами. Уменьшите количество выбранных значений.
  2. Используйте подстановочный знак звёздочки (*) вместо выбора “All”, чтобы запрашивать все метрики для dimension.
  3. Шаблонные переменные с несколькими значениями поддерживаются только для значений dimension — не для Region, Namespace или Metric Name.

Ошибки наблюдаемости между учётными записями

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

Cross-account queries fail

Симптомы:

  • Не удаётся запрашивать метрики или логи из связанных учётных записей
  • Значок monitoring account не отображается

Решения:

  1. Убедитесь, что наблюдаемость между учётными записями настроена в консоли AWS CloudWatch.

  2. Добавьте необходимые разрешения IAM:

    JSON 
    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": ["oam:ListSinks", "oam:ListAttachedLinks"],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

  3. Проверьте, что monitoring-учётная запись и source-учётные записи правильно связаны в AWS.

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

  5. EC2 Instance Attributes нельзя запрашивать между учётными записями, поскольку они используют API EC2, а не API CloudWatch.

Проблемы с квотами и стоимостью

Эти проблемы связаны с квотами сервисов AWS и управлением затратами.

API throttling errors

Симптомы:

  • Ошибки “Rate exceeded”
  • Панели дашборда периодически не загружаются

Решения:

  1. Уменьшите частоту обновления дашбордов.
  2. Увеличьте значение period, чтобы уменьшить количество запросов GetMetricData.
  3. Включите кэширование запросов в Grafana (доступно в Grafana Enterprise и Grafana Cloud).
  4. Запросите увеличение квоты в консоли AWS Service Quotas.
  5. Рассмотрите объединение похожих запросов с помощью метрик.

Если throttling возникает из-за того, что один запрос возвращает слишком много точек данных, см. раздел “Too many data points” или throttling API.

Unexpectedly high CloudWatch costs

Симптомы:

  • Затраты на AWS CloudWatch выше ожидаемых
  • Частые вызовы API из Grafana

Решения:

  1. API GetMetricData не попадает под бесплатный уровень API CloudWatch.
  2. Уменьшите частоту автообновления дашбордов.
  3. Увеличьте значение period, чтобы уменьшить количество возвращаемых точек данных.
  4. Используйте кэширование запросов, чтобы уменьшить повторные вызовы API.
  5. Проверьте настройки запросов переменных — установите обновление переменной “On dashboard load” вместо “On time range change”.
  6. По возможности избегайте подстановочных знаков в dimensions, поскольку они порождают search expressions с несколькими вызовами API.

Другие распространённые проблемы

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

Custom metrics don’t appear

Симптомы:

  • Пользовательские метрики из приложений или агентов не отображаются в выпадающем списке пространств имён
  • Видны только стандартные пространства имён AWS

Решения:

  1. Добавьте пространство имён ваших пользовательских метрик в поле Namespaces of Custom Metrics в конфигурации источника данных.
  2. Разделяйте несколько пространств имён запятыми (например, CWAgent,CustomNamespace).
  3. Убедитесь, что пользовательские метрики опубликованы в CloudWatch в выбранном регионе.

Pre-configured dashboards not working

Симптомы:

  • Импортированные дашборды не показывают данных
  • Переменные дашборда не загружаются

Решения:

  1. Убедитесь, что имя источника данных в дашборде совпадает с вашим источником данных CloudWatch.
  2. Проверьте, что настройка региона AWS в дашборде соответствует региону, где находятся ваши ресурсы.
  3. Убедитесь, что политика IAM предоставляет доступ к необходимым сервисам (EC2, Lambda, RDS и т. д.).
  4. Убедитесь, что ресурсы существуют и отправляют метрики в выбранном регионе.

Симптомы:

  • Записи логов не показывают ссылки на трейсы Application Signals
  • Поле @xrayTraceId не отображается

Решения:

  1. Убедитесь, что источник данных Application Signals настроен и связан в настройках источника данных CloudWatch.
  2. Убедитесь, что ваши логи содержат поле @xrayTraceId.
  3. Обновите запросы к логам, чтобы включить @xrayTraceId в поля, например: fields @message, @xrayTraceId.
  4. Настройте ваше приложение на логирование ID трейсов Application Signals. См. документацию AWS Application Signals.

Включение отладочного логирования

Чтобы получить подробную информацию об ошибках для устранения неполадок:

  1. Установите уровень логирования Grafana в debug в файле конфигурации:

    ini 
    [log]
level = debug

  2. Проверьте логи в /var/log/grafana/grafana.log (или в настроенном вами месте хранения логов).

  3. Ищите записи, специфичные для CloudWatch, которые содержат сведения о запросах и ответах.

  4. После устранения неполадок верните уровень логирования в info, чтобы избежать чрезмерного объёма логов.

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

Если вы попробовали описанные выше решения, но проблемы остались:

  1. Проверьте форумы сообщества Grafana на наличие похожих проблем.
  2. Просмотрите issues плагина CloudWatch на GitHub на наличие известных ошибок.
  3. Обратитесь к документации AWS CloudWatch за рекомендациями по сервису.
  4. Свяжитесь со службой поддержки Grafana, если вы пользователь Enterprise, Cloud Pro или Cloud Contracted.
  5. При сообщении о проблемах укажите:
    • Версию Grafana
    • Регион AWS
    • Сообщения об ошибках (удалите конфиденциальную информацию)
    • Шаги для воспроизведения
    • Конфигурацию запроса (удалите учётные данные и ID учётных записей)