Grafana: Мониторинг Grafana

++

: +1:

убедитесь, что URL-адрес здоровья не генерирует сеансы

: +1:

+1, это было бы очень полезно для запуска grafana за балансировщиком нагрузки, loadbalancer вызовет HTTP / health, чтобы проверить, возвращает ли grafana HTTP 200 OK.

Я собрал что-то очень простое, но сейчас мне это не очень нравится.

Если кто-то хочет взглянуть на текущее состояние по сравнению с мастером: https://github.com/grafana/grafana/compare/master...theangryangel : feature / health_check

Он возвращает что-то вроде:

{"current_timestamp":"2016-06-04T18:43:49+01:00","database_ok":true,"session_ok":true,"version":{"built":1464981754,"commit":"v3.0.4+158-g7cbaf06-dirty","version":"3.1.0"}}

Проверка базы данных Изначально я возвращал некоторую статистику, но я вырезал ее. Я мог бы переключить запрос на что-то более простое, например "выберите 1", и проверить, не вызывает ли он ошибок. Не уверен, стоит ли оно того.

Проверка сеанса мне тоже не особо нравится. Кажется, нелегко протестировать без включения тестового сервера Macaron и восстановления () ing от паники, которую он вызовет при запуске провайдера сеанса, или изменения macaron / сеанса, чтобы добавить тестовую функцию к каждому из провайдеры. На данный момент раздражает возврат заголовка Set-Cookie, который мне не особо нужен. Я был бы признателен за то, что это можно сделать от кого-то более опытного с макаронами 😞

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

Я столкнулся с той же проблемой, и в качестве временного решения я использую вызов API из балансировщика нагрузки со специальным ключом API аутентификации. Я использую HAProxy, в котором есть полезная «скрытая» функция установки пользовательских заголовков HTTP в option httpchk :

option httpchk GET /api/org HTTP/1.0\r\nAccept:\ application/json\r\nContent-Type:\ application/json\r\nAuthorization:\ Bearer\ your_api_key\r\n

(Мне нужно использовать HTTP / 1.0, а не 1.1, поскольку последний требует настройки заголовка хоста, и я не могу получить его динамически в конфигурации HAProxy).

/api/org кажется простейшим запросом с небольшими накладными расходами и возвращает HTTP 200, что именно то, что нужно балансировщику нагрузки, и не создает никаких новых сеансов.

Есть ли прогресс или пиар по этому поводу?

+1

Я бы разделил это на отдельные конечные точки / liveness и / readiness, как это принято в кубернетах. / liveness только указывает, запущена ли и работает сама графана, / readiness указывает, готова ли она к приему трафика, и проверяет, достижимы ли ее зависимости.

В кубернетах будет проверяться конечная точка живучести, и если несколько раз не получится ответить 200 ok, контейнер будет убит и заменен новым. Конечная точка готовности используется для того, чтобы сделать контейнер частью службы и направить трафик в ее сторону. Например, добавление и удаление его из балансировщика нагрузки.

+1

как насчет добавления конечной точки / metrics Prometheus?

+1

Для тех, кому нужны проверки работоспособности на некоторых сервисах, таких как Amazon ECS:
Используйте этот прием: Путь /public/img/grafana_icon.svg , HTTP-код: 200.

+1

Между тем, если вы ищете только простой HTTP code: 200 , просто используйте /login . Мой коллега и я только что развернули Grafana в кластере Kubernetes, и использование этой конечной точки отлично работало для зондов жизнеспособности / готовности. Также работает с балансировщиком нагрузки Google Compute Engine.

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

отправлено из моего Айфона

5 декабря 2016 г. в 16:09 Hunter Satterwhite [email protected] написал:

Если вам нужен простой HTTP-код: 200, просто используйте / login. Мой коллега и я только что развернули Grafana в кластере Kubernetes, и использование этой конечной точки отлично работало для зондов жизнеспособности / готовности. Также работает с балансировщиком нагрузки Google Compute Engine.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите чат.

Я хотел бы добавить наш конкретный вариант использования: нам нужна простая конечная точка HTTP для проверки, может ли пользователь войти в систему и отображать графики. Я знаю, что мы можем использовать статические ресурсы и конечные точки, такие как /login чтобы обойти его отсутствие, но нам действительно нужно что-то, что проверяет, что внутренние компоненты Grafana работают должным образом. Нам не обязательно нужны проверки статуса для получения данных из источников данных, поскольку для них у нас есть отдельные проверки работоспособности.

+1 к этому.

В пн, 5 декабря 2016 г., 23:51, Филип Вернерсбах <
[email protected]> написал:

Я хотел бы добавить наш конкретный вариант использования: нам нужна простая конечная точка HTTP для
проверка, может ли пользователь войти в систему и отображать графики. Я знаю, что мы можем использовать
статические ресурсы и конечные точки, такие как / login, чтобы обойти отсутствие
этого, но нам действительно нужно что-то, что проверяет, что Grafana
внутренние компоненты работают, как ожидалось. Нам не обязательно нужны проверки статуса
для получения данных из источников данных, так как у нас есть отдельные проверки работоспособности
для тех.

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/grafana/grafana/issues/3302#issuecomment-265060171 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AIESgm7BZw3jqs8ElVWU9v7CjtcXBYFwks5rFOm-gaJpZM4Gm4T8
.

-

[изображение: TransLoc_logos_gear-blue_600x600.png]

Хантер Сэттервайт

Ведущий инженер по строительству и эксплуатации, ТрансЛок

Сотовый: 252.762.5177 | http://transloc.com http://www.transloc.com/

[image: social media icons-03.png] https://www.facebook.com/TransLoc/ [image:
social media icons-04.png] https://www.linkedin.com/company/transloc [изображение:
social media icons-02.png] http://www.twitter.com/transloc [image: social
media icons-01.png] http://www.instagram.com/transloc_inc

Итак, в настоящее время в версии 4.0 есть конечная точка / api / metrics с некоторыми внутренними метриками.

Но проблема требует чего-то вроде этого

{ "date_sources_ok": True, "database_ok": True, "authorization_ok": True, "grafana_version": "2.5.1" }

Было бы хорошо дать более подробное описание того, что здесь ожидается. Должен ли вызов работоспособности API выполнять живую проверку всех источников данных во всех организациях? следует ли это делать "на лету" при вызове API / health?
Что означает авторизация?

@torkelo собирается выкинуть идею, но определенно думаю, что / health должен позволять как графана-серверу, так и установленным плагинам регистрировать произвольные вещи, о которых следует сообщать:

{
    "ok": false,
    "items": [
        "datasources": {
            "ok": true,
        },
        "database": {
            "ok": false,
            "msg": "Cannot communicate ###.###.###.###/XXXXXXX"
        },
        ...
    ]
}

По умолчанию проверки работоспособности выполняют оперативные проверки всего, что связано с вызовом конечной точки. Если люди хотят изолировать проверки работоспособности для определенных вещей, вы можете сделать что-то вроде elasticsearch для работоспособности кластера . Когда вещь является внешней службой (авторизация, база данных и т. Д.), То выполняется как минимум проверка подключения и любая другая разумная проверка работоспособности (например, SELECT 1 для базы данных, проверка привязки LDAP для авторизации и т. Д.).

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

+1

@torkelo извините за задержку с ответом, только что увидел ваши вопросы.

TL; DR
@andyfeller Хорошо поработал в своем комментарии, и это в значительной степени то, что я имел в виду

Конечная точка (или конечные точки), используемая для мониторинга Grafana, должна ответить на 2 вопроса с подробностями:
A) Этот экземпляр Grafana готов?
B) Этот экземпляр Grafana работает должным образом в соответствии с его настройками?

«намерения конфигурации» здесь являются ключевыми, под намерением я подразумеваю то, что когда, например, администратор добавляет в качестве источника данных, она ожидает, что он будет доступен независимо от того, верна ли сохраненная конфигурация. Таким образом, если сконфигурированный источник данных недоступен для Grafana, конечная точка мониторинга должна сказать это и почему, таким же образом работает чрезвычайно полезная кнопка «тест».

Это помогает мне думать в терминах взлетающего самолета: сначала мне нужно знать, что самолет закончил взлет и находится в воздухе, затем мне нужно знать, что самолет летит к месту назначения, как ожидалось (давайте не будем вдаваться в подробности " достижение крейсерской высоты "означает ;-))

Это можно несколько сравнить с / live / ready, указанным другими, или / health (1) / state (2) модели Elasticsearch, или / health и / info Sensu (3).
ИМХО одной конечной точки достаточно, но видение двух конечных точек в большинстве современных инструментов _kinda_ меняет мое мнение; скажем так, я еще не убежден, так как я думаю, что B является подмножеством A, поэтому я бы сделал, чтобы возвращенный JSON отражал это вместо двух конечных точек. Затем однажды, когда Grafana можно будет объединить в кластер, можно будет добавить "/ cluster_state".

Теперь, что касается деталей каждого ответа, вот мои, не исчерпывающие, начальные мысли:
Детали:

• Статус (например, красный / желтый / зеленый)
• Комментарий статуса (например, «Все в порядке» / «Не удалось запустить компонент Foo» / «Запускается»)
• Версия (например, v4.1.1-1)

Детали B:

• Статус БД (например, красный / желтый / зеленый)
• Сведения о БД (например, «не удалось подключиться, неправильная проверка подлинности» или подключение к mySQL v4.1 в порядке xxx.yyy. Zzz : 3306 , версия схемы v34132, да, схемы SQL должны иметь версии (4))
• Аутентификация / авторизация (например, подключение LDAP к xx.xx.xx: 389 ok)
• Источники данных (например, Datasource 1, type Graphite, status Red, статусный комментарий «ошибка аутентификации, Datasource 2, type Elasticsearch, статус Green, статусный комментарий« all good »)

В B можно сделать гораздо больше, поэтому разбиение мониторинга на 2 конечные точки может иметь больше смысла, да.

Что касается того, что происходит при запросе конечной точки («на лету», API и т. Д.), Я бы посоветовался с тем, кто когда-либо реализует.

Но пара - очевидных? - советов:

• внимательно относитесь к ресурсам, используемым для сбора данных мониторинга, и будьте очень «защитными» с помощью кода инструментария, помогите администраторам Grafana избежать ситуаций «мой мониторинг Grafana остановил Grafana» или «Grafana замедлилась на X% с тех пор, как я начал отслеживать его» .

• будьте как можно более уверены в предоставленных данных мониторинга, тревожная усталость - это чума

(1) https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-health.html.
(2) https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-state.html.
(3) https://sensuapp.org/docs/0.23/api/health-and-info-api.html#the -info-api-endpoint.
(4) https://blog.codinghorror.com/get-your-database-under-version-control/

Итак, 4.2.0 только что вышла и все еще нет возможности зондировать сервис? (думаю, кластер k8s)

@torkelo Я думаю, что @dynek прав , это уже не является обязательным. Будь то новый раздел в документации, посвященный «как отслеживать Grafana», где документируется то, что можно сделать сегодня с существующим инструментарием (например, использовать админку или страницу показателей), или полноценный выделенный API, как в этом предложении, нам нужно что-то вчера .
Пожалуйста, не поймите это неправильно, я не хочу говорить вам, какими должны быть приоритеты. Просто приложению трудно быть «Enterprise Ready» без специальной части, посвященной тому, как его контролировать.

+1

Добавлена ​​простая конечная точка http для проверки работоспособности графаны:

GET /api/health 
{
  "commit": "349f3eb",
  "database": "ok",
  "version": "4.1.0"
}

Если база данных (mysql / postgres / sqlite3) недоступна, она вернет «сбой» в поле database . Grafana все равно ответит с кодом состояния 200. Не уверен, что в этом случае правильно.

Самая важная вещь в этой конечной точке заключается в том, что она никогда не будет вызывать создание сеансов (что-то может сделать другие вызовы api, если вы не вызываете их с помощью ключа api или базовой аутентификации).

Разве не лучше было бы вернуться с кодом состояния 503, когда база данных недоступна?

Kubernetes использует:

Любой код больше или равен 200 и меньше 400 указывает на успех. Любой другой код указывает на сбой.

Да, я думаю, что код состояния 503, когда состояние db не удалось, лучше всего, будет обновлять

503 означает, что конечную точку /api/health лучше всего использовать только для проверки readiness в Kubernetes. Если эта проверка используется для liveness проблема с базой данных приведет к уничтожению всех подов. Есть ли параметр запроса, не учитывающий проверку базы данных?

@JorritSalverda, вы, вероятно, могли бы использовать tcpSocket check в livenessProbe

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

у нас обычно есть агрессивные проверки готовности и расслабленные проверки живучести, 1 секунда, 1 сбой для готовности, в то время как это 60 секунд 10 сбоев 1 успех для живучести, это позволяет оперативно перенаправить, когда есть проблема, но в то же время, если самовосстановление возможно, предотвращает ненужные перезапуски модуля. Но постоянная проблема с БД приведет к перезапуску, который действительно может помочь, если он был из-за плохого состояния контейнера.