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

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

В этом документе приведены решения типичных проблем, с которыми вы можете столкнуться при настройке или использовании источника данных Microsoft SQL Server (MSSQL) в Grafana.

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

Эти ошибки возникают при настройке или доступе к конфигурации источника данных в Grafana.

Форма конфигурации не отображается

Симптомы: на странице настроек источника данных отображаются только кнопки Delete и Back, без полей конфигурации.

Причина: у вошедшего в систему пользователя недостаточно прав для настройки источников данных. Доступ к форме конфигурации источника данных есть только у пользователей с ролью Organization administrator (или с пользовательской ролью RBAC с правами datasources:write).

Решение:

  1. Попросите администратора организации предоставить вам роль Organization administrator или назначить пользовательскую роль RBAC с правами на запись источников данных.
  2. В качестве альтернативы попросите администратора настроить источник данных за вас или используйте провижининг для определения источника данных в YAML.

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

Эти ошибки возникают, когда Grafana не может установить или поддерживать подключение к Microsoft SQL Server.

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

Сообщение об ошибке: Unable to open tcp connection или dial tcp: connection refused

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

Решение:

  1. Убедитесь, что SQL Server запущен и доступен.
  2. Проверьте, что хост и порт указаны верно в конфигурации источника данных. Порт SQL Server по умолчанию — 1433.
  3. Убедитесь, что нет правил брандмауэра, блокирующих подключение между Grafana и SQL Server.
  4. Убедитесь, что SQL Server настроен на разрешение удалённых подключений.
  5. Для Grafana Cloud убедитесь, что вы настроили Private data source connect, если ваш экземпляр SQL Server не доступен публично.

Тайм-аут подключения

Сообщение об ошибке: “Connection timed out” или “I/O timeout”

Причина: время ожидания подключения к SQL Server истекло до получения ответа.

Решение:

  1. Проверьте сетевую задержку между Grafana и SQL Server.
  2. Убедитесь, что SQL Server не перегружен и не испытывает проблем с производительностью.
  3. Увеличьте параметр Connection timeout в конфигурации источника данных в разделе Additional settings.
  4. Проверьте, не обрывают ли подключение по тайм-ауту какие-либо сетевые устройства (балансировщики нагрузки, прокси).

Сообщение об ошибке: “TLS handshake failed” или “certificate verify failed”

Причина: есть несоответствие между настройками шифрования в Grafana и тем, что поддерживает или требует SQL Server.

Решение:

  1. Для старых версий SQL Server (2008, 2008R2) установите параметр Encrypt в значение Disable или False в конфигурации источника данных.
  2. Если Encrypt — True, убедитесь, что у SQL Server есть действительный TLS-сертификат.
  3. Проверьте, что сертификат является доверенным для сервера Grafana (либо в системном наборе CA, либо указан в TLS/SSL Root Certificate).
  4. Если имя хоста в сертификате не соответствует настроенному значению Host (например, при использовании балансировщика нагрузки или PDC), установите Hostname in server certificate в соответствии с CN или SAN сертификата.
  5. В качестве временного обходного решения для тестирования включите Skip TLS Verify (не рекомендуется для продуктивной среды).
  6. Убедитесь, что вы используете последний доступный пакет обновления для вашей версии SQL Server, чтобы обеспечить оптимальную совместимость.

Сбои TLS-рукопожатия в Grafana с включённым FIPS

Сообщение об ошибке: “TLS handshake failed” или “no cipher suite supported by both client and server”

Причина: сборки Grafana, использующие BoringCrypto (сборки, совместимые с FIPS), требуют набора шифров по стандарту FIPS 140-3. Экземпляры SQL Server, поддерживающие только старые наборы шифров (TLS 1.0, RC4 или 3DES), несовместимы с такими сборками.

Решение:

  1. Обновите экземпляр SQL Server для поддержки TLS 1.2 с наборами шифров, одобренными FIPS (на основе AES).
  2. На хосте SQL Server убедитесь, что TLS 1.2 включён в реестре Windows или в сетевой конфигурации SQL Server.
  3. Если вы не можете обновить SQL Server, используйте сборку Grafana без FIPS.
  4. Проверьте, какие версии TLS поддерживает ваш SQL Server, найдя в журнале ошибок SQL Server записи “TLS handshake”.

Ошибки TLS-сертификата через PDC

Сообщение об ошибке: “certificate verify failed” или “x509: certificate signed by unknown authority” при подключении через Private data source connect

Причина: TLS-сертификат SQL Server должен быть проверяемым с точки зрения агента PDC, а не со стороны Grafana Cloud. Если SQL Server использует сертификат частного CA, хост агента PDC должен доверять этому CA.

Решение:

  1. Установите сертификат частного CA в системное хранилище доверенных сертификатов хоста агента PDC.
  2. В качестве альтернативы укажите путь к сертификату CA в поле TLS/SSL Root Certificate источника данных (путь должен быть доступен с агента PDC, а не из Grafana Cloud).
  3. Если имя хоста в сертификате не соответствует тому, что видит агент PDC, установите Hostname in server certificate в правильное значение.
  4. Убедитесь, что сертификат действителен (не истёк) с хоста агента PDC: openssl s_client -connect <SQL_SERVER_HOST>:1433 -starttls mssql.

Проблемы подключения к именованному экземпляру

Сообщение об ошибке: “Cannot connect to named instance” или подключение не удаётся при использовании имени экземпляра

Причина: Grafana не может разрешить именованный экземпляр SQL Server.

Решение:

  1. Используйте формат hostname\instancename или hostname\instancename,port в поле Host.
  2. Убедитесь, что служба SQL Server Browser запущена на машине SQL Server.
  3. Если служба Browser недоступна, укажите номер порта напрямую: hostname,port.
  4. Проверьте, что UDP-порт 1434 открыт, если используется служба SQL Server Browser.

Ошибки Private data source connect (PDC)

Эти ошибки возникают при использовании Grafana Cloud с Private data source connect для доступа к SQL Server, расположенному в локальной или частной сети.

“No such host” при подключении через PDC

Сообщение об ошибке: dial tcp: lookup sqlserver.internal.example.com: no such host

Причина: агент PDC не может разрешить имя хоста SQL Server из своей сети. Обычно это происходит, когда:

  • Имя хоста в конфигурации источника данных — это публичное DNS-имя, которое не разрешается внутри частной сети.
  • У хоста агента PDC нет доступа к внутреннему DNS-серверу.
  • DNS-запись кластера или Availability Group Listener настроена неверно.

Решение:

  1. В поле Host источника данных используйте имя хоста, разрешаемое из сети агента PDC (например, внутренний FQDN или IP-адрес, а не публичное DNS-имя).
  2. Убедитесь, что хост агента PDC может разрешить имя хоста: выполните nslookup <SQL_SERVER_HOST> на машине агента.
  3. Если используется кластер или Availability Group Listener, убедитесь, что DNS-запись слушателя существует и разрешается в правильный IP-адрес из сети агента.
  4. Проверьте, что на хосте агента PDC настроены правильные DNS-серверы.

Подключение PDC обрывается после обслуживания или смены IP

Причина: IP-адрес конечной точки SSH-туннеля PDC изменился после обслуживания инфраструктуры, что нарушило установленное подключение.

Решение:

  1. Перезапустите службу агента PDC, чтобы заново установить SSH-туннель с обновлённой конечной точкой.
  2. Убедитесь, что статус агента PDC показывает рабочее подключение в Connections > Private data source connect в вашем стеке Grafana Cloud.
  3. Если в вашей сети используются правила брандмауэра на основе IP для исходящего трафика, обновите список разрешённых адресов. IP-адреса конечных точек PDC могут меняться во время окон обслуживания.
  4. Рассмотрите возможность использования списков разрешённых адресов на основе DNS вместо правил на основе IP, где это возможно, чтобы избежать подобных сбоев в будущем.

Учётные данные не сохраняются при включённом PDC

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

Решение:

  1. После включения PDC сначала сохраните конфигурацию источника данных, затем заново введите имя пользователя и пароль и сохраните ещё раз.
  2. Нажмите Save & test, чтобы убедиться, что учётные данные сохранены и подключение успешно.
  3. Если проблема сохраняется, попробуйте отключить PDC, сохранить учётные данные, а затем снова включить PDC.

Не удаётся подключиться к частному SQL Server из Grafana Cloud

Причина: попытка подключиться к SQL Server в локальной или частной сети из Grafana Cloud без настроенного PDC.

Решение:

  1. Для любого SQL Server, не доступного публично, Grafana Cloud требует Private data source connect (PDC).
  2. Одного добавления в список разрешённых адресов брандмауэра недостаточно, поскольку подключения источников данных Grafana Cloud не используют статические IP-адреса.
  3. Установите и настройте агент PDC на хосте в вашей частной сети, который может достичь SQL Server по порту 1433.
  4. Убедитесь, что хост агента PDC разрешает исходящие подключения по порту 22 к конечной точке PDC Grafana Cloud.

Инструкции по настройке см. в разделе Connect to on-premises SQL Server from Grafana Cloud.

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

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

Ошибка входа для пользователя

Сообщение об ошибке: “Login failed for user ‘username’” или “Authentication failed”

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

Решение:

  1. Убедитесь, что имя пользователя и пароль указаны верно.
  2. Проверьте, что пользователь существует в SQL Server и включён.
  3. Убедитесь, что у пользователя есть доступ к указанной базе данных.
  4. Для Windows Authentication убедитесь, что учётные данные имеют правильный формат (DOMAIN\User).
  5. Проверьте, что режим аутентификации SQL Server допускает используемый вами тип входа (SQL Server Authentication, Windows Authentication или Mixed Mode).

Ошибка входа для пользователя ’’ (пустое имя пользователя)

Сообщение об ошибке: “Login failed for user ‘’”. Сохранённое имя пользователя отображается пустым, когда Grafana подключается к SQL Server.

Причина: известная проблема в некоторых каналах выпуска Grafana приводила к тому, что имя пользователя для SQL Server Authentication отображалось сохранённым в UI, но при подключении на сервер отправлялась пустая строка. Это было выявлено в канале выпуска “fast”.

Решение:

  1. Переключитесь на канал выпуска “steady”, если вы используете “fast” и столкнулись с этой проблемой.
  2. После обновления или переключения каналов откройте конфигурацию источника данных, заново введите имя пользователя и пароль и нажмите Save & test, чтобы убедиться, что учётные данные сохранены правильно.
  3. Если проблема сохраняется после повторного сохранения, очистите кэш браузера и попробуйте снова.

Подключение не удаётся, если пароль содержит специальные символы

Сообщение об ошибке: “Login failed for user” или “Connection string parse error”, когда учётные данные содержат точки с запятой (;) или закрывающие фигурные скобки (})

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

Решение:

  1. Обновитесь до Grafana v13.0 или более поздней версии, в которой эти специальные символы обрабатываются корректно.
  2. Если обновление невозможно, измените пароль SQL Server, чтобы избежать символов ; и }.

Доступ к базе данных запрещён

Сообщение об ошибке: Cannot open database 'dbname' requested by the login

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

Решение:

  1. Убедитесь, что имя базы данных указано верно в конфигурации источника данных.

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

  3. Предоставьте как минимум разрешение SELECT на нужные таблицы:

    SQL 
    USE [your_database]
GRANT SELECT ON dbo.YourTable TO [your_user]

  4. Проверьте, что у пользователя нет конфликтующих разрешений от роли public.

Проблемы с Windows Authentication (Kerberos)

Сообщение об ошибке: “Kerberos authentication failed” или “Cannot initialize Kerberos”

Причина: конфигурация Kerberos неверна или неполна.

Решение:

  1. Убедитесь, что путь к файлу конфигурации Kerberos (krb5.conf) указан верно в настройках источника данных. Путь по умолчанию — /etc/krb5.conf.
  2. Для аутентификации по keytab убедитесь, что файл keytab существует и доступен для чтения сервисной учётной записью Grafana.
  3. Проверьте, что настройки realm и KDC указаны верно в конфигурации Kerberos.
  4. Убедитесь, что DNS правильно разрешает серверы KDC.
  5. Убедитесь, что имя участника службы (SPN) зарегистрировано для экземпляра SQL Server.

Note

Аутентификация Kerberos не поддерживается в Grafana Cloud. Используйте вместо неё SQL Server Authentication или Azure Entra ID.

KDC_ERR_C_PRINCIPAL_UNKNOWN с Availability Group listeners

Сообщение об ошибке: “KDC_ERR_C_PRINCIPAL_UNKNOWN” при подключении через SQL Server Availability Group Listener

Причина: SPN, зарегистрированный для экземпляра SQL Server, не совпадает с DNS-именем Availability Group Listener. Аутентификация Kerberos требует SPN, соответствующего имени хоста, к которому подключается клиент.

Решение:

  1. Зарегистрируйте SPN для DNS-имени Availability Group Listener:

    text 
    setspn -S MSSQLSvc/<LISTENER_FQDN>:1433 <DOMAIN>\<SERVICE_ACCOUNT>
setspn -S MSSQLSvc/<LISTENER_FQDN> <DOMAIN>\<SERVICE_ACCOUNT>

  2. Убедитесь, что SPN зарегистрирован правильно: setspn -L <DOMAIN>\<SERVICE_ACCOUNT>.

  3. Убедитесь, что krb5.conf содержит правильное сопоставление realm для домена слушателя.

  4. Если используется несколько realm, добавьте записи доверия между realm в krb5.conf.

Ошибки недоверенного домена с Windows Authentication

Сообщение об ошибке: “The login is from an untrusted domain and cannot be used with Windows authentication”

Причина: домену сервера Grafana не доверяет домен SQL Server, либо конфигурация realm Kerberos не сопоставляется правильно между доменами.

Решение:

  1. Убедитесь, что между доменом сервера Grafana и доменом SQL Server существуют доверительные отношения.

  2. Проверьте, что krb5.conf содержит сопоставления realm для обоих доменов:

    ini 
    [realms]
DOMAIN_A.COM = {
  kdc = kdc1.domain_a.com
}
DOMAIN_B.COM = {
  kdc = kdc1.domain_b.com
}

[domain_realm]
.domain_a.com = DOMAIN_A.COM
.domain_b.com = DOMAIN_B.COM

  3. Убедитесь, что сервисная учётная запись SQL Server имеет разрешения на делегирование, если требуется доступ между доменами.

  4. В качестве альтернативы используйте SQL Server Authentication или Azure Entra ID (App Registration), которые не требуют доверия доменов.

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

Сообщение об ошибке: “AADSTS error codes” или “Azure AD authentication failed”

Причина: аутентификация Azure Entra ID (ранее Azure AD) настроена неверно.

Решение:

  1. Для аутентификации App Registration:

    • Убедитесь, что tenant ID, client ID и client secret указаны верно.
    • Убедитесь, что регистрация приложения добавлена как пользователь в базу данных Azure SQL.
    • Проверьте, что срок действия client secret не истёк.

  2. Для аутентификации Managed Identity:

    • Убедитесь, что в конфигурации сервера Grafana задано managed_identity_enabled = true.
    • Убедитесь, что управляемое удостоверение добавлено в базу данных Azure SQL.
    • Подтвердите, что у ресурса Azure, размещающего Grafana, включено управляемое удостоверение.

  3. Для аутентификации Current User:

    • Убедитесь, что в конфигурации сервера Grafana задано user_identity_enabled = true.
    • Убедитесь, что регистрация приложения настроена на выдачу как Access Tokens, так и ID Tokens.
    • Проверьте, что настроены необходимые разрешения API (user_impersonation для Azure SQL).

Подробную информацию о настройке аутентификации Azure см. в разделе Configure the Microsoft SQL Server data source.

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

Эти ошибки возникают при проблемах с синтаксисом или конфигурацией запросов.

Столбец времени не найден или некорректен

Сообщение об ошибке: “Could not find time column” или визуализация временных рядов не показывает данные

Причина: запрос не возвращает правильно отформатированный столбец time для визуализации временных рядов.

Решение:

  1. Убедитесь, что ваш запрос включает столбец с именем time при использовании формата Time series.
  2. Используйте макрос $__time() для переименования столбца даты: $__time(your_date_column).
  3. Убедитесь, что столбец времени имеет действительный тип даты/времени SQL (datetime, datetime2, date) или содержит значения Unix epoch.
  4. Убедитесь, что результирующий набор отсортирован по столбцу времени с помощью ORDER BY.

Ошибки разворачивания макросов

Сообщение об ошибке: “Error parsing query” или макросы отображаются в запросе неразвёрнутыми

Причина: макросы Grafana используются неправильно.

Решение:

  1. Проверьте синтаксис макроса: используйте $__timeFilter(column), а не $_timeFilter(column).
  2. Макросы не работают внутри хранимых процедур. Используйте вместо них явные параметры даты.
  3. Проверьте, что имя столбца, передаваемое в макросы, существует в вашей таблице.
  4. Просмотрите развёрнутый запрос, нажав Generated SQL после выполнения запроса, чтобы отладить разворачивание макросов.

Проблемы с часовыми поясами и сдвигом времени

Причина: данные временных рядов выглядят сдвинутыми или не совпадают с ожидаемым временем.

Решение:

  1. Храните метки времени в базе данных в UTC, чтобы избежать проблем с часовыми поясами.

  2. Макросы времени ($__time, $__timeFilter и т. д.) всегда разворачиваются в значения UTC.

  3. Если ваши метки времени хранятся в локальном времени, преобразуйте их в UTC в запросе:

    SQL 
    SELECT
  your_datetime_column AT TIME ZONE 'Your Local Timezone' AT TIME ZONE 'UTC' AS time,
  value
FROM your_table

  4. Не передавайте параметры часового пояса в макросы времени. Они не поддерживаются.

Запрос возвращает слишком много строк

Сообщение об ошибке: “Result set too large” или браузер перестаёт отвечать

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

Решение:

  1. Добавьте фильтры времени с помощью $__timeFilter(column), чтобы ограничить данные диапазоном времени дашборда.
  2. Используйте агрегации (AVG, SUM, COUNT) с GROUP BY вместо возврата необработанных строк.
  3. Добавьте предложение TOP для ограничения результатов: SELECT TOP 1000 ....
  4. Используйте макрос $__timeGroup() для агрегирования данных по интервалам времени.

Хранимая процедура не возвращает данные

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

Решение:

  1. Убедитесь, что хранимая процедура использует операторы SELECT, а не только присваивания переменных.
  2. Удалите SET NOCOUNT ON, если он присутствует, или убедитесь, что за ним следует оператор SELECT.
  3. Убедитесь, что параметры хранимой процедуры передаются правильно.
  4. Протестируйте хранимую процедуру напрямую в SQL Server Management Studio с теми же параметрами.

Дополнительные сведения об использовании хранимых процедур см. в документации по редактору запросов.

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

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

Медленное выполнение запросов

Причина: запросы выполняются долго.

Решение:

  1. Сократите диапазон времени дашборда, чтобы ограничить объём данных.
  2. Добавьте индексы по столбцам, используемым в предложениях WHERE и фильтрах времени.
  3. Используйте агрегации вместо возврата отдельных строк.
  4. Увеличьте параметр Min time interval, чтобы уменьшить количество точек данных.
  5. Изучите план выполнения запроса в SQL Server Management Studio, чтобы выявить узкие места.

Исчерпание пула подключений

Сообщение об ошибке: “Too many connections”, “Connection pool exhausted” или “failed to connect to server”

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

Решение:

  1. Увеличьте лимит подключений Max open в конфигурации источника данных. Значение от 50 до 100 покрывает большинство развёртываний с параллельной работой дашбордов и алертов.
  2. Включите Auto max idle, чтобы автоматически управлять неактивными подключениями.
  3. Установите Max lifetime в 14400 (4 часа), чтобы устаревшие подключения пересоздавались.
  4. Сократите количество панелей, одновременно запрашивающих один и тот же источник данных, или разделите тяжёлые дашборды на несколько страниц.
  5. Проверьте наличие длительно выполняющихся запросов, которые могут удерживать подключения открытыми (изучите sys.dm_exec_sessions в SQL Server).
  6. Если алерты периодически сбоят, а дашборды работают, это сильный признак исчерпания пула при параллельной нагрузке.

Медленная загрузка дашборда с репликами только для чтения

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

Причина: источник данных настроен с ApplicationIntent=ReadOnly в поле Host, что направляет все запросы на вторичную реплику только для чтения. Если реплика недостаточно мощная, недостаточно проиндексирована или испытывает задержку репликации, запросы выполняются намного медленнее, чем на первичном сервере.

Решение:

  1. Удалите ApplicationIntent=ReadOnly из поля Host, чтобы направлять запросы обратно на первичный экземпляр.
  2. Если вам нужно использовать реплику только для чтения, убедитесь, что у неё те же индексы и ресурсы, что и у первичного сервера.
  3. Проверьте задержку репликации и использование ресурсов реплики (CPU, I/O) в периоды медленной работы.
  4. Рассмотрите создание отдельного источника данных для запросов к реплике и его использование только для конкретных дашбордов, не требующих низкой задержки.

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

Эти ошибки возникают при использовании запросов Microsoft SQL Server в Grafana Alerting.

Алерты периодически сбоят, тогда как дашборды работают

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

Решение:

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

Запросы алертинга не возвращают данные

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

Решение:

  1. Убедитесь, что для формата запроса задано Time series (формат Table не поддерживается для алертинга).
  2. Убедитесь, что запрос не использует переменные шаблонов (запросы алертинга не могут разрешать переменные дашборда).
  3. Проверьте, что запрос возвращает данные в пределах диапазона времени вычисления алерта.
  4. Протестируйте запрос в Explore с фиксированным диапазоном времени, чтобы убедиться, что он возвращает результаты.

Дополнительные сведения см. в разделе Microsoft SQL Server alerting.

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

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

Запросы переменных шаблонов не выполняются

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

Решение:

  1. Убедитесь, что синтаксис запроса переменной — это корректный SQL, возвращающий один столбец.
  2. Проверьте, что подключение к источнику данных работает.
  3. Убедитесь, что у пользователя есть разрешение на доступ к таблицам, на которые ссылается запрос переменной.
  4. Протестируйте запрос в редакторе запросов, прежде чем использовать его как запрос переменной.

Двойное заключение в кавычки ломает запросы с многовыбираемыми переменными

Причина: начиная с Grafana v11.3 многовыбираемые переменные, используемые с IN, автоматически заключаются в кавычки. Если вы вручную заключили переменную в кавычки (например, WHERE col IN ('${var}')), значения теперь заключаются в двойные кавычки (например, ''value''), что вызывает сбои запросов.

Решение:

  1. Уберите кавычки вручную вокруг переменной: используйте WHERE col IN ($var) вместо WHERE col IN ('${var}').
  2. Для сравнений одного значения используйте формат sqlstring: WHERE col = ${var:sqlstring}.
  3. Варианты форматирования см. в разделе Template variables.

Прочие распространённые проблемы

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

Системные базы данных появляются в запросах

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

Решение:

  1. Редактор запросов автоматически исключает tempdb, model, msdb и master из раскрывающегося списка баз данных.
  2. Всегда указывайте базу данных в конфигурации источника данных, чтобы ограничить доступ.
  3. Убедитесь, что у пользователя базы данных есть разрешения только на предполагаемую базу данных.

Данные отображаются неверно или смещены

Причина: проблемы с форматированием данных или преобразованием типов.

Решение:

  1. Используйте явные псевдонимы столбцов, чтобы обеспечить согласованность именования: SELECT value AS metric.
  2. Убедитесь, что числовые столбцы действительно имеют числовые типы, а не строковые.
  3. Проверьте наличие значений NULL, которые могут повлиять на агрегации.
  4. Используйте параметр FILL в макросе $__timeGroup() для обработки отсутствующих точек данных.

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

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

  1. Проверьте форумы сообщества Grafana на наличие похожих проблем.
  2. Изучите issues в GitHub Grafana на предмет известных ошибок.
  3. Включите отладочное логирование в Grafana, чтобы зафиксировать подробную информацию об ошибке.
  4. Проверьте журналы SQL Server для получения дополнительных сведений об ошибке.
  5. Обратитесь в Grafana Support, если вы являетесь клиентом Enterprise или Cloud.

При сообщении о проблемах указывайте:

  • Версию Grafana
  • Версию плагина источника данных Microsoft SQL Server, которую можно найти на странице Administration > Plugins. Плагин обновляется независимо от выпусков Grafana.
  • Версию SQL Server
  • Сообщения об ошибках (удалите конфиденциальную информацию)
  • Шаги для воспроизведения
  • Соответствующие примеры запросов (удалите конфиденциальные данные)