Grafana: Grafana 모니터링

++

: +1 :

상태 URL이 세션을 생성하지 않는지 확인

: +1 :

+1, 이것은 loadbalancer 뒤에서 grafana를 실행하는 데 매우 유용합니다. loadbalancer는 / health HTTP를 호출하여 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"}}

원래 데이터베이스 검사에서 일부 통계를 반환했지만 잘라 냈습니다. 쿼리를 "select 1"과 같이 훨씬 더 간단한 것으로 전환 할 수 있으며 오류가 없는지 확인합니다. 그만한 가치가 있는지 확실하지 않습니다.

세션 확인도 특히 만족스럽지 않습니다. 테스트 마카롱 서버를 세우고 세션 공급자를 시작할 때 발생할 수있는 패닉에서 복구 ()하지 않고 테스트하기가 쉽지 않은 것 같습니다. 또는 마카롱 / 세션을 수정하여 각 서버에 테스트 기능을 추가합니다. 공급자. 지금 당장 짜증나는 것은 특별히 원하지 않는 Set-Cookie 헤더를 반환합니다. 마카롱에 대해 더 경험이 많은 사람으로부터 이것을 가져갈 수있는 몇 가지 의견에 감사드립니다 😞

데이터 소스를 확인하는 것은 grafana가 작성되는 방식을 고려할 때 이것을 시도하는 것이 특히 제정신이 아닌 것 같습니다. 정기적 인 모니터링 시스템에 추가하는 것이 더 정상일 것입니다.

동일한 문제에 직면했으며 해결 방법으로 전용 인증 API 키를 사용하여로드 밸런서에서 API 호출을 사용합니다. option httpchk 에서 사용자 지정 HTTP 헤더를 설정하는 유용한 "숨겨진"기능이있는 HAProxy를 사용하고 있습니다.

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

(후자는 호스트 헤더를 설정해야하고 HAProxy 구성에서 동적으로 가져올 수 없기 때문에 1.1이 아닌 HTTP / 1.0을 사용해야합니다.)

/api/org 는 오버 헤드가 거의없는 가장 간단한 요청으로 보이며로드 밸런서에 정확히 필요한 HTTP 200을 반환하며 새 세션을 생성하지 않습니다.

이 문제에 대한 진전이나 홍보가 있습니까?

+1

kubernetes의 모범 사례처럼 이것을 별도의 / liveness 및 / readiness 엔드 포인트로 분할합니다. / liveness는 grafana 자체가 실행 중인지 여부 만 나타내고, / readiness는 트래픽을받을 준비가되었는지 여부를 나타내며 종속성에 도달 할 수 있는지 여부를 확인합니다.

kubernetes에서 활성 엔드 포인트가 프로브되고 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 부하 분산기에서도 작동합니다.

모든 사람이이를 기술적으로 암시하는 방법을 알고 있다고 생각하지만 요점은 외부 종속성을 포함한 서비스 상태 모니터링을 명시 적으로 지원하는 것입니다.

내 iPhone에서 보냄

2016 년 12 월 5 일 오후 4시 9 분에 Hunter Satterwhite [email protected] 은 다음과 같이 썼습니다.

간단한 HTTP 코드 200을 찾고 있다면 / login을 사용하십시오. 제 동료와 저는 방금 Grafana를 Kubernetes 클러스터에 배포했으며 해당 엔드 포인트를 사용하여 활성 / 준비 프로브에 대해 잘 작동했습니다. Google Compute Engine 부하 분산기에서도 작동합니다.

—
이 스레드를 구독했기 때문에이 메시지가 전송되었습니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하십시오.

특정 사용 사례를 추가하고 싶습니다. 사용자가 로그인하고 그래프를 표시 할 수 있는지 확인하려면 간단한 HTTP 엔드 포인트가 필요합니다. /login 와 같은 정적 리소스와 엔드 포인트를 사용하여이 문제를 해결할 수 있다는 것을 알고 있지만 Grafana 내부가 예상대로 실행되고 있는지 확인하는 것이 정말 필요합니다. 데이터 소스에 대한 별도의 상태 확인이 있으므로 데이터 소스에서 데이터를 검색하기 위해 반드시 상태 확인이 필요하지는 않습니다.

이것에 +1.

2016 년 12 월 5 일 월요일 오후 11:51, Philip Wernersbach <
[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]

헌터 새터 화이트

리드 빌드 및 운영 엔지니어, TransLoc

셀 : 252.762.5177 | http://transloc.com http://www.transloc.com/

[이미지 : 소셜 미디어 아이콘 -03.png] https://www.facebook.com/TransLoc/ [이미지 :
소셜 미디어 아이콘 -04.png] https://www.linkedin.com/company/transloc [이미지 :
소셜 미디어 아이콘 -02.png] http://www.twitter.com/transloc [이미지 : 소셜
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 상태 호출은 모든 조직의 모든 데이터 소스에 대해 실시간 확인을 수행해야합니까? / health api 호출이 이루어지면 즉시 수행해야합니까?
승인 확인은 무엇을 의미합니까?

@torkelo 는 아이디어를 던지려고하지만 / health는 grafana-server와 설치된 플러그인 모두에 대해보고 할 임의의 것을 등록 할 수 있어야한다고 생각합니다.

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

기본적으로 상태 확인은 엔드 포인트가 호출 될 때 모든 사항에 대한 실시간 확인을 수행합니다. 사람들이 상태 확인을 특정 항목으로 격리하려는 경우 elasticsearch가 클러스터 상태를 위해 하는 것과 같은 작업을 수행 할 수 있습니다. 사물이 외부 서비스 (권한 부여, 데이터베이스 등) 인 경우 최소한 연결 테스트가 수행되고 사물에 적합한 기타 온 전성 검사가 수행됩니다 (예 : 데이터베이스의 경우 SELECT 1, 인증을위한 LDAP 바인드 테스트 등).

이와 같은 출력을 사용하면 모니터링 검사에서 문제를 전체적으로 확인하는 동시에 특정 문제를 찾고 그에 따라 출력 할 수 있습니다.

+1

@torkelo 지연된 답변에 대해 죄송합니다 방금 귀하의 질문을 보았습니다.

TL; DR
@andyfeller 그의 댓글에서 좋은 일을했고 내가 염두에 두었던 것입니다.

Grafana를 모니터링하는 데 사용되는 끝점 (또는 끝점)은 세부 정보와 함께 두 가지 질문에 답해야합니다.
A)이 Grafana 인스턴스가 준비되어 있습니까?
B)이 Grafana 인스턴스가 구성 의도에 따라 예상대로 실행되고 있습니까?

여기서 "구성 의도"가 핵심입니다. 의도가 의미하는 바는 예를 들어 관리자가 데이터 소스로 추가 할 때 저장된 구성이 올바른지 여부에 관계없이 사용할 수있을 것으로 기대한다는 것입니다. 따라서 구성된 데이터 소스를 Grafana에서 사용할 수없는 경우 모니터링 엔드 포인트는 그렇게해야하며 동일한 방식으로 매우 유용한 "테스트"버튼이 작동하는 이유를 알려야합니다.

이륙하는 비행기의 관점에서 생각하는 데 도움이됩니다. 먼저 비행기가 이륙을 완료하고 공중에 있다는 것을 알아야합니다. 그런 다음 비행기가 예상대로 목적지를 향해 비행하고 있다는 것을 알아야합니다. 순항 고도에 도달 "은 ;-))를 의미합니다.

이것은 다른 사람들이 지적한 / live / ready 또는 Elasticsearch 모델의 / health (1) / state (2) 또는 Sensu (3)의 / health 및 / info와 다소 비교 될 수 있습니다.
IMHO 하나의 엔드 포인트로 충분하지만 대부분의 최신 도구에서 두 개의 엔드 포인트를 보는 것은 내 마음을 바꾸는 것입니다. B가 A의 하위 집합이라고 생각하므로 아직 설득되지 않았다고 가정 해 보겠습니다. 따라서 반환 된 JSON에 2 개의 끝 점이있는 대신이를 반영합니다. 그런 다음 Grafana를 클러스터링 할 수있는 어느 날 "/ cluster_state"를 추가 할 수 있습니다.

이제 각 답변의 세부 사항과 관련하여 다음과 같은 초기 생각이 있습니다.
세부 사항 :

• 상태 (예 : 빨간색 / 노란색 / 녹색)
• 상태 설명 (예 : "모두 양호"/ "Foo 구성 요소를 시작할 수 없음"/ "시작 중")
• 버전 (예 : v4.1.1-1)

B 세부 사항 :

• DB 상태 (예 : 빨간색 / 노란색 / 녹색)
• DB 세부 정보 (예 : "연결할 수 없음, 잘못된 인증"또는 xxx.yyy에서 mySQL v4.1에 대한 연결 확인. zzz : 3306 , 스키마 버전 v34132, 예 SQL 스키마의 버전을 관리해야 함 (4))
• 인증 / 승인 (예 : xx.xx.xx : 389에 대한 LDAP 연결 확인)
• 데이터 소스 (예 : 데이터 소스 1, 유형 Graphite, 상태 Red, 상태 설명 "인증 실패, 데이터 소스 2, 유형 Elasticsearch, 상태 녹색, 상태 설명"모두 양호 ")

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 든 어제 필요합니다. .
잘못된 방식으로 받아들이지 마십시오. 우선 순위가 무엇인지 말씀 드리려는 것이 아닙니다. 모니터링 방법에 대한 전담 부분없이 응용 프로그램이 "엔터프라이즈 준비"상태가되는 것은 힘든 판매라는 것입니다.

+1

grafana 상태를 확인하기 위해 간단한 http 끝점을 추가했습니다.

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

데이터베이스 (mysql / postgres / sqlite3)에 연결할 수없는 경우 database 필드에 "실패"를 반환합니다. Grafana는 여전히 상태 코드 200으로 응답합니다.이 경우 무엇이 올바른지 확실하지 않습니다.

이 엔드 포인트에서 가장 중요한 점은 세션이 생성되지 않는다는 것입니다 (API 키 또는 기본 인증으로 세션을 호출하지 않으면 다른 API 호출이 수행 할 수있는 작업).

데이터베이스에 연결할 수 없을 때 상태 코드 503으로 반환하는 것이 가장 좋지 않습니까?

Kubernetes는 다음을 사용합니다.

200보다 크거나 같고 400보다 작은 코드는 성공을 나타냅니다. 다른 코드는 실패를 나타냅니다.

예, db 상태가 실패했을 때 503 상태 코드가 가장 좋다고 생각합니다.

503은 /api/health 엔드 포인트가 Kubernetes의 readiness 확인에만 가장 적합하다는 것을 의미합니다. 이 검사가 liveness 되면 데이터베이스 문제로 인해 모든 포드가 종료됩니다. 데이터베이스 검사를 생략하는 쿼리 매개 변수가 있습니까?

@JorritSalverda 아마도 tcpSocket 체크인을 livenessProbe

/metrics 는 세션을 생성하거나 db 요청을 발행하지 않습니다.

우리는 일반적으로 공격적인 준비 상태 확인 및 완화 된 활성 상태 확인을 수행합니다. 1 초, 준비 ​​상태에서 1 번 실패, 60 초 10 번 실패 1 번 활성 상태에서 성공, 문제가있을 때 응답 재 라우팅이 가능하지만 동시에 자체 복구가 필요한 경우 가능한, 불필요한 포드 다시 시작을 방지합니다. 그러나 지속적인 DB 문제로 인해 재시작이 발생하여 컨테이너 상태가 좋지 않은 경우 실제로 도움이 될 수 있습니다.