Grafana: grafana에 대한 경고 시스템 구축

도움이 되고 싶습니다! 내 제안은 nagios 스타일 지침을 고수하는 것입니다. 그렇게 하면 도구를 다른 모니터링 도구와 함께 쉽게 사용할 수 있습니다. 예: Nagios, Zenoss, Icinga 등.

이 기능의 가장 큰 장점은 기본 아키텍처를 바로 잡는 것입니다.

내가 탐구하고 싶은 몇 가지 질문
1) 어떤 구성 요소가 어떻게 실행되는지(in proc in grafana, out of proc),
2) 사물이 어떻게 조정되어야 하는가.
3) "스트림 내" 경고를 무시해야 하나요? (풀 기반에만 집중)

1)에 대해 더 자세히 알아보기
grafana-server를 모놀리스로 만드는 것에 대해 걱정하고 있습니다. grafana-server를 서로 더 격리된 서비스로 분리하는 방법을 찾고 싶습니다(그리고 inproc 또는 별도의 프로세스로 실행할 수 있음). 이것은 일종의 버스 추상화 계획이었습니다. 또 다른 옵션은 경고 구성 요소가 HTTP API를 통해서만 grafana와 통신하도록 하는 것이며 통합을 제한할 수 있습니다.

나는 torkelo에 동의합니다. 모든 "내장"이 있는 다른 프로젝트에 대한 제 경험에 따르면 문제를 해결하는 것이 상당히 번거로울 수 있습니다. 서비스가 외부에서 실행된다는 아이디어가 마음에 들지만 모든 경고 관리를 처리하기 위해 HTTP API를 통해 서비스와 통신하는 grafana의 멋진 구성 페이지가 있습니다. 또한 대규모 배포의 경우 성능이 결국 저하되므로 결국 이것이 요구 사항이 될 것입니다(적어도 구성 옵션으로 사용할 수 있음).

현재 grafana 그래프 임계값 설정(현재 처리용이 아니라 비주얼리제이션 전용)과 통합합니까? 표현식이 임계값 검사인 경우 임계값 라인을 자동으로 표시할 수 있습니다.

좋은 출발점이 될 수 있다고 생각합니다. 설정되어 있으면 경고하고 그렇지 않으면 표시하지 마십시오.

1번으로 돌아가기. bosun 서비스가 개별적으로 실행될 수 있지만 여전히 grafana를 통해 모든 것을 완전히 구성할 수 있는 기능이 있다면 제 생각에는 이상적일 것입니다.

멋진 작업을 계속하십시오.

bosun에서 내가 본 유일한 단점은 사용할 수 있는 데이터 소스입니다. bosun 경고를 표현하기 위해 언어를 활용할 수 있지만 일반 grafana UI를 통해 구성된 기존 데이터 소스와 통합할 수 있다면 확실히 이상적일 것입니다.

경고 임계값에 근접했을 때 표시할 수 있을 뿐만 아니라 내 마음에 트리거되었을 때 주석을 자동으로 푸시할 수 있는 기능은 이상적인 단일 창 UI를 만듭니다.

여기서 할 작업이 기대됩니다!

1. 경고하려면 대시보드에 정의된 임계값을 사용해야 합니다.
   간단하게 합시다. 대시보드에 경고 색상이 표시되면 경고하는 것입니다.
2. 이것은 grafana-server 프로세스 자체의 외부에 있는 것일 수 있습니다.
   ... 나머지 API를 사용하여 대시보드와 설정을 긁어내고 외부 명령을 사용하여 렌더링하고 경고하는 것.
3. 경고 수준; 이 대시보드를 모니터링해야 하는 편집기에 드롭하는 상자입니다. 매분마다 확인해야 합니다. 데이터가 없으면 일정 기간 동안 계속 경고해야 합니까? (체크박스)

마지막으로; 우리가 Grafana에 더 많이 의존함에 따라 2. 기꺼이 지불할 의향이 있습니다.

사람들이 왜 이것이 Grafana에 포함되어야 한다고 생각하는지 궁금합니다.
Grafana는 실제 데이터를 수신하거나 저장하지 않고 "오직" 시각화합니다. 경고 시스템은 대신 메트릭 저장소의 데이터를 기반으로 해야 합니다.
이것이 Grafana에 실제로 통합된다면 이 기능을 비활성화할 수 있기를 바랍니다. 여기에서는 이미 Icinga를 경고에 사용하고 있으므로 Grafana의 모든 경고는 전혀 사용되지 않더라도 GUI를 더 복잡하게 만들 뿐입니다.

절대적으로 정확합니다 @dennisjac; Grafana는 사물만 렌더링합니다.

하지만 서버 측으로 이동하면서 더 이상 클라이언트 렌더링이 아닙니다. 메트릭 및 경고를 확인할 수 있는 작업자 프로세스의 가능성; 덜 어렵습니다.

데이터는 데이터베이스에 있습니다. 메트릭을 확인하도록 지시하는 데이터가 뿌려진 경우 ...

어떤 사람들은 우리가 흐름을 건너지 않고 Grafana가 (대략) 시각화하는 것 이상의 일을 하도록 해서는 안 된다는 데 동의하거나 동의하지 않을 수 있지만 저는 그런 사람이 아닙니다.

나는 이 기능이 통합되기를 원하는 사람들을 위한 기능에 반대하지는 않지만 이미 모니터링/경고 시스템을 사용할 수 있는 사람들을 위해 이 기능이 선택 사항이 되기를 바랍니다.

새로운 Telegraf 프로젝트(influxdb의 메트릭 수집기)도 같은 이유로 싫어하는 모니터링/경고 기능을 찾고 있습니다. 여기에 대해 자세히 설명했습니다.
https://influxdb.com/blog/2015/06/19/Announcing-Telegraf-a-metrics-collector-for-InfluxDB.html#comment -2114821565

torkelo는 Grafana2에서 활성화할 필요가 없는 기능을 제공하는 데 있어 정말 좋은 일을 해냈다고 생각합니다.

influxdb에 관한 한 그들은 어떻게든 돈을 벌어야 할 것입니다. influxdb 및 전문 서비스 또는 제품의 지원을 중단합니다.

후자가 훨씬 더 실용적으로 들립니다.

이것에 대한 또 다른 각도. grafana를 위한 메트릭 저장소로 Elasticsearch에 대한 지원이 곧 있을 것 같습니다. Bosun은 지금 Elasticsearch에서 로그 데이터를 쿼리할 수 있습니다.

로그 데이터의 경고도 허용하도록 경고 시스템을 설계할 때 의미가 있습니까? 첫 번째 버전의 기능은 아니지만 나중에 구현할 수 있는 기능일 수 있습니다.

또한 프로세스를 분할한다는 아이디어에 동의합니다. Grafana 인터페이스에서 경고를 보고 생성하도록 하고 다른 것으로 경고를 처리하도록 합니다. 경고 부분 API를 기반으로 하면 다른 도구에서도 이와 인터페이스할 수 있습니다.

경고에 +1. DevOps 사용 외에 최종 사용자를 위해 구축된 애플리케이션은 사용자 정의 경고를 제공해야 합니다. 시각화 도구에 있는 것이 좋습니다...

+1 이것은 루프를 닫을 것입니다 - 메트릭 가져오기 제안.

+1 Grafana의 경고 + InfluxDB의 수평 확장 백엔드는 메트릭 경고 구성을 위한 표준이 될 것입니다.

+1 여러 grafana 노드에서 경고의 수평 확장을 원합니다.

경고와 같은 동작과 같은 "디바운스"를 연결할 수 있다면 좋을 것입니다. 예를 들어 정의된 임계값이 N분 동안 X를 초과하는 경우에만 경고를 발생시키고 싶습니다.

일부 경고 도구에서 이를 보았지만 불행히도 현재 이러한 옵션을 제공하지 않는 것으로 보이는 Seyren을 사용하고 있습니다. 우리는 대시보드 개발을 위해 Grafana를 사용하고 있으며 Grafana에도 경고를 적용하기를 기대하고 있습니다. 좋은 일을 계속하십시오.

두 가지 사용 사례가 있습니다.

• 인프라 팀은 일반적인 모니터링 스택에 평소와 같이 프로비저닝 도구를 통해 경고를 생성합니다(나기오스 친화적 시스템에서 공통 클러스터 검사 또는 시스템 검사).
• 소프트웨어 개발자는 Grafana를 통해 앱 메트릭을 생성합니다.

통합 경고 시스템이 경고, 플랩 감지, 에스컬레이션 및 연락처를 처리하기를 바랍니다. 이는 동일한 소스에서 이벤트/작업을 기록하고 연관시키는 데 도움이 됩니다. 많은 시스템이 경고 문제를 해결했습니다. Grafana가 장기적으로 더 잘할 수 있기를 바랍니다. 단기적으로는 기존 시스템을 재창조하지 않는 것이 결과물 측면에서 도움이 될 것입니다.

한 가지 제안은 Grafana가 모니터링 정의(경고 상태)를 추출하기 위한 API를 제공할 수 있고 타사가 구성 내보내기 플러그인을 제공할 수 있다는 것입니다. 이것은 nagios 구성을 내보내는 사용 사례에서 매우 이상적입니다.

더 중요한 것은 통합된 이상 감지 솔루션도 보고 싶습니다!

2015년 7월 15일 17:40에 Pierig Le Saux [email protected] 은 다음과 같이 썼습니다.

+1 여러 grafana 노드에서 경고의 수평 확장을 원합니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.

@activars에 동의합니다. 나는 대시보드 솔루션이 대부분 꽤 성숙한 다른 많은 도구에 의해 다소 해결된 문제인 경고를 처리해야 하는 이유를 정말로 이해하지 못합니다. 한 가지만 잘 하면 됩니다.

IMHO _integration_ 부분에 초점을 맞추는 것이 더 합리적입니다.

예: grafana에서 동적 경고/위험 임계값을 정의하고(예: 위의 @Dieterbe 예에서와 같이) 정확히 이 그래프의 상태(정상, 경고,

우리의 경우 서비스 카탈로그와 정의된 작업이 어려운 부분입니다. 어떤 서비스가 비즈니스 크리티컬한지, 이메일을 어디로 보낼지, 플래핑 등입니다. 또한 대부분의 회사에서 이미 가지고 있는 grafana의 사용자/그룹 관리에 대해 걱정할 필요가 없습니다. 중앙 장소(AD, LDAP, Crowd 등) 및 경고 시스템과 통합됩니다.

또한 우리는 대시보드 솔루션과 달리 경고 도구에 대한 품질 요구 사항이 과소 평가되어서는 안 되는 (테스트) 노력을 생성하는 안정성, 탄력성, 안정성 등의 측면에서 훨씬 더 높은 것으로 간주될 수 있다는 점을 고려해야 합니다.

또한 웹 서비스 호출, 시스템 ping, 사용자 정의 스크립트 실행과 같은 시계열이 아닌 관련 검사는 어떻습니까? grafana에서도 이를 원하십니까? bosun 입양이 이 모든 것을 제공할 것이라고 생각하지만 나는 그것에 대해 잘 모릅니다.

반면에 간단한 경고 시스템이 적절한 대안이 없는 많은 사용자를 행복하게 만드는 방법을 상상할 수 있지만 다른 경고 도구에 대한 몇 가지 예제 통합 패턴으로 해결할 수 있습니다.

Grafana가 내 모든 문제를 해결해주기를 바라는 만큼 falkenbt가 이 문제로 머리를 못 박았다고 생각합니다.

언급된 데이터, bosun의 일부 배관 및 공통 경고 플랫폼과의 일부 통합 패턴을 노출하는 API는 많은 의미가 있습니다.

Raintank @Dieterbe에서의 새 직장을 축하합니다! 나는 잠시 동안 귀하의 블로그를 읽었으며 특히 메트릭 및 경고에서의 위치와 관련하여 모니터링에 대한 몇 가지 건전한 아이디어를 가지고 있습니다. grafana에서 경고를 구현하는 좋은 방법을 찾을 수 있을 것이라고 확신합니다.

아마 동의하시겠지만, Bosun 뒤에 있는 사람들은 올바른 방법으로 경고를 하고 있습니다. Bosun의 부족한 점은 사실 시각화입니다. Grafana UI 뒤에 있는 Bosun을 보고 싶습니다. 동일한 인터페이스 뒤에서 Grafanas 대시보드와 bosuns 경고를 결합하면 훌륭하고 완벽한 모니터링 솔루션이 됩니다.

또한 오픈 소스 모니터링 커뮤니티를 더 세분화하는 것은 부끄러운 일이라고 생각합니다. 모니터링에 대한 귀하의 아이디어는 Bosun 뒤에 있는 사람들의 아이디어와 정말 호환되는 것 같습니다. 당신이 단결한다면 나는 그 결과가 좋을 것이라고 확신합니다.

제가 일하는 곳에서는 로그/이벤트에 Elastic을 사용하고 있으며 지표에 InfluxDB를 사용하기 시작했습니다. 우리는 모니터링을 위한 다양한 솔루션을 모색해 왔으며 현재 Bosun 쪽으로 기울고 있습니다. 우리는 이미 대시보드에 Grafana를 사용하고 있지만 동일한 인터페이스를 통해 모든 모니터링 정보에 액세스하고 싶습니다. Grafana가 해당 인터페이스가 될 수 있다면 좋을 것입니다.

좋은 일을 계속하고 행운을 빕니다!

관련 탄젠트에서 우리는 grafana와 riemann을 통합하여 경고 작동 경고 부분을 얻었습니다. grafana의 내부를 알아가는 좋은 운동이었습니다 :).

구성이 클로저 코드일 뿐이므로 riemann을 사용하면 더 쉬웠습니다. 이 통합은 보순에서 더 어려울 것이라고 생각합니다.

다음은 작동 중인 몇 가지 스크린샷입니다.

grafana 부분에 대한 변경 사항에는 "/alerts" 및 "/subscriptions" 엔드포인트 추가가 포함되었으며 riemann이 crud를 수행할 수 있도록 맨 위에 있는 다른 작은 API와 통신하도록 했습니다.

좋은 점은 경보 정의의 변경 사항이 riemann에 SIGHUP을 보낼 필요 없이 즉시 반영된다는 사실입니다. 따라서 상태 변경에 대한 시간 주기 조정을 활성화/비활성화하는 것은 UI에서 변경하고 해당 변경이 riemann에 전파되도록 하는 것입니다.

아직 이 통합을 벤치마킹하지 않았지만 그렇게 나쁘지 않을 것이라고 생각합니다. 코드를 정리하고 일단 실행되면 그것에 대해 블로그에 올릴 것입니다.

우리가 이렇게 한 모든 이유는 사람들이 매우 친숙한 UI에서 이러한 경고 및 알림을 설정하고 riemann 구성을 작성하는 데 방해가 되지 않기 때문입니다.

@sudharsh 구현이 정말 흥미롭게 들립니다. 이것을 야생에 공개할 계획입니까?

많은 좋은 아이디어, 모두 감사합니다.
일부 의견과 @pabloa 의 https://github.com/pabloa/grafana-alerts 프로젝트에서 영감을 받아 동일한 워크플로의 일부로 경고 규칙을 구성하고 관리하기 위한 UI 및 UX에 가장 먼저 집중하기로 결정했습니다. 대시보드 및 패널 편집. Grafana는 이러한 규칙을 어딘가에 저장하고 다른 스크립트나 도구가 경고 규칙을 가져올 수 있도록 쉽게 액세스할 수 있도록 합니다.
아마도 파일, API 호출, 대시보드 구성의 섹션 또는 데이터베이스의 항목을 통해.
(저는 그것을 대시보드 정의 자체의 일부로 갖는 아이디어를 좋아합니다. 그래서 오픈 소스 프로젝트는 기본적으로 활성화되어 있지 않아도 경고 규칙이 포함된 grafana 대시보드 json 파일과 함께 제공될 수 있습니다. 데이터베이스가 더 강력해 보입니다)
어느 쪽이든, 우리는 사용자가 실제로 경고 규칙을 실행하고 이벤트를 처리하는 다른 시스템에 대한 구성을 생성할 수 있도록 쉬운 액세스를 제공하고자 합니다. (이제부터 이것을 "핸들러"라고 부를 것입니다).
이러한 처리기는 작성하는 도구인 nagios, sensu 또는 bosun이거나 bosun이 지원하는 훌륭하고 간단한 통합을 제공하는 grafana로 컴파일할 수 있는 처리기인 litmus alert scheduler-executor일 수 있지만 우리는 정말 원합니다. 원하는 시스템을 사용할 수 있는지 확인하십시오.

핸들러가 사용하는 데이터 저장소 쿼리를 지원하는 한. 간단한 정적 임계값으로 시작하지만 나중에 축소 함수, 여러 조건 간의 부울 표현식 등을 쉽게 선택할 수도 있습니다.

@sudharsh 아주 좋은 접근 방식입니다. 나는 당신의 솔루션이 위에서 설명한 중간 단계를 우회하여 원격 API와 직접 통신할 수 있는 방법을 좋아합니다(물론 이것은 우리가 피하려고 하는 주어진 백엔드 1개에서만 작동함을 의미합니다). 그리고 자동으로 구성을 다시 로드할 수 있습니다. (당신이 맞습니다. bosun은 현재 그것을 지원하지 않습니다. 미래에 그럴 수도 있습니다. FWIW 리트머스 핸들러는 이것을 잘 처리하고 bosun의 표현 평가 메커니즘을 사용합니다). 나는 riemann에 대해 별로 들어본 적이 없다. 대부분의 경우 문제가 발생했을 때 많은 사람들이 이해하지 못하거나 디버그할 수 없는 다른 언어를 스택에 추가하는 것에 대해 우려했습니다. 그러나 귀하의 시스템과 Riemann의 CLJ 코드에 대해 자세히 알고 싶습니다. (내 의심이 틀리면 좋겠어)

@dennisjac 네, 선택 사항입니다.
@elvarb 데이터 소스로 ES에 대한 티켓이 있습니다. 실제로 목표는 grafana가 주어진 데이터 소스에서 데이터 렌더링을 지원하는 경우 이에 대한 경고 규칙 구성도 지원해야 한다는 것입니다. 쿼리 실행/쿼리는 물론 사용하기로 결정한 핸들러에 따라 다릅니다. (리트머스 핸들러의 경우 흑연 및 influxdb와 같은 가장 인기 있는 것으로 시작합니다)
@rsetzer : 동의합니다. 트리거하기 전에 임계값을 초과해야 하는 시간을 지정할 수 있다는 것은 좋은 일입니다.
@falkenbt : 많은 것들이 시계열 쿼리 문제로 표현될 수 있다고 생각합니다(예: pings 예제). 그러나 당신 말이 맞습니다. 어떤 것들은 실제로 시계열과 관련이 없고 그것들은 우리가 여기서 구축하려고 하는 범위를 벗어납니다. 그리고 저는 그게 맞다고 생각합니다. 우리는 시계열에 대한 경고를 구성 및 관리하는 가장 좋은 방법을 제공하고 "기타 스크립트" 사례(예: nagios, icinga, sensu, .. .). 배달의 신뢰성, 에스컬레이션 등과 같은 문제에 관해서는 호출기 같은 서비스에 연결할 수 있습니다.
@activars & @falkenbt 이것이 당신의 기대와 일치하는 것
@jemilson 감사합니다! 그리고 그것이 바로 내가 보는 방식입니다. bosun은 경고에 능숙하지만 시각화에는 능숙하지 않습니다. Grafana는 시각화 및 UX에 탁월하지만 경고가 없습니다. 시간이 지남에 따라 성장하는 협업을 추진하고 있다고 생각합니다.

이메일과 같은 알림에 어떤 종류의 컨텍스트를 제공할지 생각하는 사람이 있습니까?
최소한 알림에는 경고하는 데이터의 비주얼리제이션이 포함되어야 하지만 다른 관련 그래프를 포함할 수 있어야 합니다. 여기에서 알림 콘텐츠를 생성할 때 grafana의 png 렌더링 백엔드를 사용할 수 있습니다. grafana의 스냅샷 기능을 활용하는 방법도 생각하고 있습니다. 경고가 트리거될 때와 같이 컨텍스트를 위해 특정 대시보드의 스냅샷을 만듭니다.
그리고 그 스냅샷(html 페이지)이 이메일에 포함될 수도 있고, 너무 많은 데이터/복잡성일 수도 있습니다. 또한 자바 스크립트 기능은 어쨌든 메일 클라이언트에서 사용할 수 없습니다(그래서 이메일에서 그래프를 확대할 수 없음). 이메일에서 호스팅된 대시보드 스냅샷으로 연결할 수 있습니다.

나는 배터리가 포함되어 있지만 제거할 수 있는 도커의 일반적인 접근 방식을 좋아합니다. 따라서 교체할 수 있는 기본 경고 구현은 좋은 접근 방식이 될 것입니다.

influxdb는 경고에 대해 지원됩니까? 아니면 흑연만?

내가 보고 싶은 한 가지는 계층적 경고 트리에 대한 아이디어입니다. 모니터링되는 패싯이 너무 많고 독립 실행형 경고 상태에는 관리할 수 없는 카디널리티가 있습니다. 계층 트리를 사용하여 높은 수준으로 롤업되는 중간 수준 경고로 롤업되는 이러한 모든 낮은 수준 경고를 정의할 수 있습니다.

따라서 롤업된 각 경고는 자동으로 그 아래에 있는 모든 하위 항목의 심각도가 높음을 가정합니다. 그렇게 하면 훨씬 낮은 표면적의 분석으로 시스템 상태를 정확하게 파악하고 관리할 수 있습니다.

이것은 내가 얼마 전에 작성한 오래된 문서에서 빌린 예입니다. 예, "Struts"라는 단어를 사용하는 데 웃어주세요. 오래됐어 괜찮아? 이것은 하나의 서버에 대한 매우 간단한 계층 구조를 나타냅니다.

어떤 시점에서 서버는 75%의 CPU 사용률을 유지하므로 이러한 경고가 경고 상태로 전환됩니다. CPU-# --> CPU --> 호스트/OS --> 시스템

실제로 적용하면 하나의 지표로 전체 데이터 센터를 주시할 수 있습니다. (예, 실제로는 아니지만 이것은 사고 연습으로 사용됩니다)

흑연 비콘을 사용하지 않는 이유는 무엇입니까? 그라파나로 아주 가벼운 그래파이트 비콘을 합칠 수 있다고 생각합니다.

@felixbarny 저는 그 용어를 좋아합니다. 우리는 그 문구를 채택할 것입니다.
@JulienChampseix 예 표준 처리기는 influxdb를 지원합니다/지원합니다
@nickman 흥미
@amirhosseinrajabi 는 멋진 프로젝트처럼 보이며 grafana UI를 통해 구성된 경고에 대한 처리기로 graphite-beacon을 만드는 것이 많은 의미가 있다고 생각합니다.

@Dieterbe 현재 상태를 업데이트할 수 있습니까? 경보 시스템용
어떤 시스템이 호환되는지 알기 위해(graphite/influxdb)?
어떤 구독이 가능합니까? 어떤 경고 유형을 사용할 수 있습니까?
업데이트해주셔서 감사합니다.

우리는 현재 UX/UI 프로토타이핑 중입니다. 그래서 우리는 이것을 사용할 수 있는 방법이 있습니다.

안녕하세요 @Dieterbe

경보 시스템의 진행 상황에 대한 업데이트가 있습니까 ??

Grafana에 알림이 있으면 정말 좋을 것입니다! 이 기능을 기대합니다. 지금 업데이트가 있습니까?

@mattttt UX 작업에 대한 업데이트를 제공할 수 있습니까?

네 그럼요. 내일 일부 화면/사용자 흐름을 업로드할 예정입니다.

경고가 필요합니다. 규칙 정의를 위한 UI, 규칙 정의를 위한 API, 경고 알림을 위한 API. 관심을 가지고 이 스레드를 볼 것입니다. 우리는 다중 테넌트 시스템을 가지고 있으며 Grafana UI와 백엔드를 좋아합니다.

예, 저는 또한 이 새로운 기능을 보는 데 매우 관심이 있고 참을성이 없습니다!
고마워요 맷! ;)

2015-08-27 6:49 GMT+02:00 andyl [email protected] :

경고가 필요합니다: 규칙 정의를 위한 UI, 규칙 정의를 위한 API 및 API
경고 알림을 위해. 관심을 가지고 이 스레드를 볼 것입니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/grafana/grafana/issues/2209#issuecomment -135290295.

내부적으로 제자리에 떨어지는 많은 항목이 있지만 이 스레드를 무시하고 싶지 않았습니다.

여기 내가 작업한 패널의 모형 중 하나가 있습니다. 이것은 상태를 도구 설명에 통합하고 패널 구성에 정의된 기존 임계값을 사용하여 경고를 구성하는 시간 경과에 따른 과거 상태를 보여줍니다.

이 예에서는 여러 시리즈가 있는 단일 쿼리에 대해 경고합니다. 마우스 오버 시 상태를 표시하도록 툴팁이 확장되었습니다.

_몇 가지 작은 미해결 질문 _: 경고 알림에 대한 정보가 있는 경우 도구 설명에 얼마나 많은 정보가 포함되어야 합니까? 아니면 이 정보를 보다 자세한 보기의 다른 곳에서 액세스해야 합니까? 현재로서는 후자를 믿지만 큰 소리로 물어볼 가치가 있습니다.

구성, 알림 화면, 사용자 흐름이 천천히 나옵니다. 많이 올 것입니다.

@mattttt 좋아요 !

차트 아래의 녹색과 빨간색 선을 좋아하십시오!

가동 시간 계산과 관련이 있으며 어딘가에서 숫자로 볼 수 있기를 바랍니다. 모든 쿼리 및 각 측정항목에 대한 합계입니다.

툴팁에 대해 라인 위로 마우스를 가져갈 때 표시되는 통계를 말하는 것입니까?

젠장 @mattttt 굉장해 보입니다. 나는 툴팁에 아무것도 입력하는 것에 대해 걱정하지 않을 것입니다. 임계값 선과 하단의 경고 상태 상태 표시줄은 충분합니다.

완료되면 이것을 볼 수 있기를 기다릴 수 없습니다!

나는 이것이 잘 진행되고 있는 것을 보게 되어 기쁩니다!

우리는 현재 Grafana+Bosun+OpenTSDB를 모니터링 및 경고 스택으로 사용합니다. Grafana의 훌륭한 UX에 Bosun의 힘을 갖게 된다면 정말 대단할 것이라는 데에는 동의합니다.

다음은 Grafana의 구성 UX가 Bosun의 구성보다 나은 예입니다.

문맥

우리의 모니터링 스택은 여러 팀과 해당 서비스 간에 공유됩니다. 프로젝트 사양에 따라 다른 서비스 세트가 다른 클러스터/사이트에 배포됩니다. 각 팀/서비스는 자체 대시보드/경고를 책임져야 합니다.

비교

Grafana의 HTTP API 팀은 서비스를 배포할 때 자신의 대시보드를 PUT할 수 있습니다. 현재 Bosun에는 구성을 저장하기 위한 단일 파일만 있습니다. 이로 인해 다른 팀과 다른 프로젝트 간에 공유하기가 어렵습니다.

@mattttt @torkelo @Dieterbe 릴리스 알림 조각(또는 베타 릴리스)에 대한 아이디어가 있습니까?

에코 ^. 이것에 대한 베타 또는 알파 릴리스입니까? 경고 솔루션을 연구하고 있지만 grafana에 내장된 무언가를 갖고 싶습니다. 많은 테스트 피드백을 제공할 수 있습니다.

알림 기능은 아직 몇 개월 후이며, 우리는 여전히 UI 프로토타입을 만들고 구현하는 다양한 방법을 생각하고 있지만 앞으로 2개월 동안 진행 상황이 더 빨리 진행되어 그때 더 많이 알게 될 것입니다.

@mattttt 기록 건강 막대의 색상을 구성할 수 있도록 하시겠습니까? 녹색과 빨간색은 색맹과 잘 어울리지 않습니다 ;)

경고에 관하여: 나는 이것이 어떻게 진행되는지에 상당히 관심이 있습니다. 우리는 잠시 동안 데이터를 수집하고 시각화했으며 경고는 현재 파악하려고 노력하고 있습니다. Grafana는 특히 시각화가 이미 준비되어 있기 때문에 좋은 위치를 차지할 수 있습니다. 내가 궁금한 점은: Grafana가 경고를 위한 메트릭 시리즈보다 '엔티티'를 얼마나 더 많이 인식해야 합니까? 메트릭 기반 경고 외에도 내 경우에는 서버가 될 항목에 대해 시각적 상태 변경(ping 또는 http 확인 실패) 또는 수동(유지 관리 수행)을 자동으로 토글하고 싶다고 상상할 수 있습니다.

Grafana에서 경고가 어디로 가는지 보고 싶지만 지금 무언가가 필요한 분들을 위해 https://exchange.nagios.org/directory/Plugins/System-Metrics/Others/check_graphite_metric/details 와 같은 nagios 플러그인이

@baaym

내가 궁금한 점은: Grafana가 경고를 위한 메트릭 시리즈보다 '엔티티'를 얼마나 더 많이 인식해야 합니까? 메트릭 기반 경고 외에도 내 경우에는 서버가 될 항목에 대해 시각적 상태 변경(ping 또는 http 확인 실패) 또는 수동(유지 관리 수행)을 자동으로 토글하고 싶다고 상상할 수 있습니다.

이것은 좋은 질문이자 우리가 조금 이야기한 것이기도 합니다.
우리가 단기적으로(그리고 아마도 장기적으로) 함께 가고자 하는 솔루션은 grafana가 그러한 더 높은 수준의 개념을 인식하지 못하도록 하는 것입니다. 즉, 사용자는 메트릭 시리즈에 대한 경고를 설정할 수 있는 권한이 있으며 이러한 경고 규칙에서 경고 결과가 생성됩니다(시리즈 이름의 속성 또는 태그 포함). 여기서 원하는 엔터티를 구성할 수 있습니다. 이것은 우리가 조금 더 생각해야 할 부분이지만 예를 들어

movingAverage(cluster1.web-*.cpu.idle,10) < 20 -> warn 라인을 따라 경고를 설정했다고 가정해 보겠습니다. 이것은 주어진 클러스터의 모든 웹 서버에 대한 임계값을 확인하고 movingAverage(cluster1.web-123.cpu.idle,10) is currently 3! 와 같은 위반에 대한 경고를 생성합니다.
경고에 더 좋은 정보를 포함할 수 있도록 "첫 번째 필드는 클러스터 이름, 두 번째 필드는 호스트 이름" 등으로 말할 수 있습니다.
그러나 요점은 경고 _outcome_에 문제가 있는 엔터티를 식별하는 데 필요한 정보가 포함되어 있지만 grafana의 범위를 벗어납니다. Grafana는 경고 규칙 구성의 소스가 될 것이며 경고 상태를 시각화하기 위해 주석 및 What-have-you를 로드하도록 grafana 대시보드를 구성할 수 있지만 호스트 또는 클러스터. 나는 이것이 경고 처리기에서 처리 될 수있는 것이라고 생각합니다.

@디터베

경고 기능을 구축할 때 두 가지 유형의 사용자/조직 문제가 있습니다.

• 일반적으로 자체 알림 솔루션을 구축할 시간이 없는 스타트업. 모든 것은 Grafana에 의존하여 메트릭에 대해 경고합니다.
• 엔지니어링 조직을 구축하고 기존 경고 도구를 사내에 구축했으며 비즈니스 규칙에 대한 경고는 기타 세분화된 경고 신호를 기반으로 구축했습니다(Grafana가 그 중 하나임).

Grafana는 기존의 잘 정립된 운영 관행과 함께 작업해야 합니다. 주기를 벗어나는 것은 경고 목표를 무시하는 것입니다. 경고는 환경의 명확한 상태를 구축할 수 있도록 중앙 집중화하는 것이 좋습니다. grafana API(또는 다른 솔루션)를 사용하는 고급 사용자가 경고 규칙을 다른 시스템으로 내보낼 수 있도록 하는 것이 중요합니다.

작동 중이라고 말할 때 각 경고는 선택적으로 경고 및 과거 동작의 목적을 설명하는 문서/링크 필드를 포함해야 합니다.

@activars 나는 그 모든 것에 동의한다고 생각합니다. 내 생각에 우리는 grafana를 나머지 환경에 연결하는 방식을 취하고 있습니다(주로 연결 가능한 핸들러를 사용하여 관심사 분리 덕분에). 제안된 디자인이 어떤 식으로든 개선될 수 있다고 생각합니까?

@deebs031 은 "최종 사용자를 위해 구축된 응용 프로그램은 사용자 정의 경고를 제공해야 함"에 대해 많이 다루지 않은 좋은 지적이라고 생각합니다.
IMHO the graal은 셀프 서비스 메트릭 기반 모니터링 입니다. 제 경우에는 Grafana가 메트릭을 보고자 하는 사람들을 위한 메인 프런트 엔드이며 동일한 UI 내에서 스스로 경고를 생성할 수 있도록 하는 것이 합리적입니다.
저는 개인적으로 메트릭을 기반으로 Sensu 알림을 수행했지만 셀프 서비스로 제공하는 것은 Grafana와 통합될 경우 얼마나 원활할지에 비해 실제로 케이크 조각이 아닙니다. Cabot 도 시각화 기능이 있어서 살펴봤는데 셀프 서비스를 염두에 두고 구축되지 않았기 때문에 그대로 사용할 수 없었습니다.
저는 "한 가지 일을 잘하는" 편에 속하지만 메트릭을 기반으로 하는 셀프 서비스 경고의 특정 경우에는 해당 기능을 메트릭 시각화 레이어와 페어링하는 것이 매우 합리적이라고 생각합니다.

• 사용자는 이미 UI에 익숙합니다.
• 사용자가 인증되어 자신 또는 인증이 활성화하는 모든 권한 스키마에 대한 경고를 생성할 수 있습니다.
• 사용자는 메트릭 기반 경고를 생성할 때 일반적으로 매우 유용한 그래프를 볼 수 있습니다.

경고에 대한 내 grafanacon 프레젠테이션 슬라이드:
http://www.slideshare.net/Dieterbe/alerting-in-grafana-grafanacon-2015
문맥 없이는 이해하기가 다소 어렵습니다. 비디오는 약 일주일 안에 온라인 상태가 될 것입니다. 준비되면 게시하겠습니다.

우리는 이제 경고 모델/UI/정의/등을 구현하는 방법의 프로토타이핑을 시작했습니다. 우리는 주요 워크플로에 대해 꽤 좋은 아이디어를 가지고 있지만, 여전히 알아내려고 하는 한 가지 중요한 점은 타사 경고 처리기와의 통합이 어떤 모습이어야 하는지입니다.
현재 우리의 생각은 grafana를 사용하여 임계값 설정/경고 규칙/알림 정의 및 경고 규칙의 기록 및 현재 상태를 시각화할 수 있다는 것입니다.

선택한 경고 소프트웨어(bosun/cabot/sensu/nagios/...)를 사용하려는 것으로 가정합니다.
따라서 http API를 통해 grafana를 쿼리하여 모든 경고 규칙을 검색하는 별도의 도구가 있습니다. 그러면 해당 도구가 bosun/cabot/sensu/nagios/... 구성을 업데이트할 수 있으므로 선택한 경고 소프트웨어를 사용하여 경고를 실행 및 실행하고 알림을 보낼 수 있습니다.
그러나 우리는 현재 및 과거 상태를 적절하게 시각화할 수 있기를 원하므로 경고 프로그램은 스크립트나 웹훅 또는 grafana에게 새 상태를 알리기 위해 무언가를 호출할 수 있어야 합니다. 그렇지 않으면 grafana가 이를 쿼리해야 합니다. (대부분의 도구가 훌륭한 API를 가지고 있지 않은 것 같다는 점을 감안할 때 이것은 유감스러운 것 같습니다)
이것은 모두 약간 복잡하지만 경고 규칙을 정의하고 상태를 시각화하는 데 grafana를 사용하는 동안 선택한 경고 소프트웨어를 계속 사용할 수 있도록 하는 것이 중요한 사람들을 지원하려면 이 방법을 사용해야 합니다.

현재 선택한 알림 도구를 사용할 수 있다는 것이 중요합니까?

우리가 하고 싶은 또 다른 일은 grafana API에 경고를 쿼리하고, 예약하고, 실행하고, 알림을 수행하는 간단한 경고 실행기를 직접 작성하는 것입니다(이메일, 여유, 호출기, 사용자 정의 스크립트 및 아마도 다른 몇 가지) 및 grafana의 상태를 다시 업데이트합니다.
우리를 위해 작성하는 것이 상당히 쉬울 것이고 사용하기 쉽고 우리는 훌륭한 상호 운용성을 가질 수 있습니다.

내장된 경고 실행기(위 참조)가 grafana에서 설정한 모든 경고 규칙을 처리하기에 충분하다고 생각하는 것입니까?

또한 여러 경고 처리기를 사용할 수 있기를 원하십니까? 어느 ?

@jaimegago 아멘 ;)

모든 것이 원활하게 작동하도록 구성해야 하는 항목의 수를 최소화할 수 있다는 점에서 2번이 더 나은 것 같습니다. 우리의 현재 설정에서는 그렇게 할 것입니다.

다른 모든 사람들이 동의하지 않는 경우에만 그렇게 말한 것입니다 ;)

빠른 편집: 멋진 슬라이드. 완제품이 그것의 반으로 나온다면 그것은 놀라운 것입니다.

+1
이 통합이 포함된 내부 알림 처리기가 완벽하다는 데 동의합니다! 가장 일반적인 사용 사례입니다.

저는 베타 테스팅을 하게 되어 기쁩니다. :) 슬라이드도 훌륭합니다!

@Dieterbe 의 마지막 게시물이 상황을 상당히

Grafana에서 경고는 셀프 서비스 경고 구성( @jaimegago 덕분에 스스로 더 잘 말할 수

Grafana 경고 처리기를 배송할 뿐만 아니라 선택한 경고 소프트웨어와 통합할 수 있는 프레임워크도 제공합니다.

+1 다른 경고 시스템에 대한 일종의 다리 구축(일부 일반적인 경고 플러그인 시스템 구현에 대해 생각할 수 있음 :-))

"외부 경고 처리기" 부분에도 Prometheus 추가할 수 있습니다. 첫 번째 Prometheus alertmanager 버전은 여러 회사에서 생산 중이며 현재 완전한 재작성이 작업 중입니다. SoundCloud는 Grafana를 사용하여 경고를 구성할 수 있지만 Prometheus alertmanager가 경고 처리기로 사용되는 경우에만 그렇습니다.

@grobie , 좋은 캐치, 원래 주석에서 수정되었습니다.

@mattttt @Dieterbe 멋지네요 ! 두 세계의 IMHO인 "배터리가 포함되지만 제거 가능"한 경로에 있는 것 같습니다. 경고 처리기에 권한 부여 데이터를 전달하는 방법에 대해 이미 생각했습니까? 나는 다음과 같은 이야기를 생각하고 있다.
Grafana 사용자로서 (Grafana 알림 UI를 통해 구축된 일부 조건) 발생 시 _email_ 및/또는 _pagerduty_ 및/또는 _foo_를 통해 알림을 받고 싶습니다.
해당 사용자는 승인된 알림 시스템에만 경고를 보낼 수 있어야 합니다. 이는 셀프 서비스의 요구 사항이며 어떻게든 해결해야 합니다. Grafana 2 이후로 SQL 백엔드 + LDAP 통합을 통한 사용자 인증/권한 부여가 있으므로 경고 첫날부터 해당 기능을 갖기에는 너무 무리한 것 같지 않습니까?
내가 연결할 도구인 Sensu를 사용하면 핸들러를 통해 경고 대상(예: 이메일 주소)을 전달하는 것이 매우 간단해야 하며 다른 것에 대해서는 말할 수 없습니다.

안녕하세요 여러분,
나는 셀프 서비스 경고 구성 접근 방식을 좋아하기 때문에 이 여유가 계속해서 추진되고 있다는 것을 알게 되어 기쁩니다.

개인적으로 특정 경고 처리기가 필요하지 않습니다. 경고가 발생하자마자 트리거되는 일반 HTTP POST 처리기를 보고 싶습니다. 나는 대부분의 관리자가 HTTP를 받아들일 수 있는 무언가를 빠르게 구축할 수 있다고 생각합니다. 따라서 경고에 대한 모든 정보를 JSON 데이터로 보내는 HTTP 처리기에 만족합니다.

grafana를 통한 경고에 대해 이야기하면서 플래핑 감지와 같은 것을 추가할 계획입니까? 아니면 외부 모니터링 시스템에서 처리해야 하는 사항입니까?

좋은 일을 계속하십시오!

건배

경고가 발생하자마자 트리거되는 일반 HTTP POST 처리기를 보고 싶습니다. 나는 대부분의 관리자가 HTTP를 받아들일 수 있는 것을 빠르게 구축할 수 있다고 생각합니다.

따라서 경고가 발생하고(예: "web123에 중요한 CPU 유휴 상태가 있습니다!, 값 1이 임계값 15보다 낮음") 해당 데이터의 http 게시를 수행하는 경우 nagios에서 이를 어떻게 처리할까요? nagios가 수동 서비스 검사로 받아들인 다음 nagios가 알림을 보낼 것임을 의미합니까?

grafana를 통한 경고에 대해 이야기하면서 플래핑 감지와 같은 것을 추가할 계획입니까? 아니면 외부 모니터링 시스템에서 처리해야 하는 사항입니까?

이것은 또한 우리가 더 생각해야 하는 것입니다. 이것은 지저분해질 수 있고 사람들이 pagerduty 또는 flapjack과 같은 것을 사용하는 경우 이벤트를 집계하거나 중복을 억제하는 데 사용할 수 있으므로 grafana 처리기에서 구현하는 것을 피할 수 있는지 확인해야 할 수도 있습니다. 또한 임의의 메트릭 쿼리 표현식에 대한 경고를 설정할 수 있기 때문에 실제 표현식에서 과거 데이터를 고려할 수 있는 많은 권한이 있으므로 표현식에서 보다 강력한 신호를 생성할 수 있습니다. 상태를 자주 변경하지 않습니다.

따라서 경고가 발생하고(예: "web123에 중요한 CPU 유휴 상태가 있습니다!, 값 1이 임계값 15보다 낮음") 해당 데이터의 >http 게시를 수행하면 nagios에서 이를 어떻게 처리할까요? nagios가 >수동 서비스 검사로 받아들인 다음 nagios가 알림을 보낼 것이라는 뜻입니까?

거의. 나는 실제로 nagios를 제거하기 위해 grafana 경고를 기대하고 있습니다. HTTP 처리기를 사용하여 nagios가 결과를 제출할 수 있도록 수동 검사를 구성해야 합니다. 그러나 경고를 구성할 수 있는 하나의 소스로 grafana를 사용하고 싶습니다. 우리의 경우 경고를 추가할 수 있는 사람은 nagios에서 검사도 구성할 실제 시스템 관리자입니다.

http 핸들러를 사용하면 grafana에는 실시간 모니터링을 위한 대시보드, API, 쉬운 경고 구성 및 내부 알림 시스템에 경고를 전달할 수 있는 http 핸들러 등 필요한 모든 것이 있습니다.

건배

이 통합 전략에서 논리를 볼 수는 있지만 조금 과하다는 생각을 지울 수 없습니다. 내가 이해하고 스레드에서 읽을 수 있는 것은 대부분의 Grafana 사용자가 독립형 경고 기술을 계속 사용하는 유일한 이유는 Grafana가 제안하지 않기 때문입니다. 따라서 먼저 Grafana Alerting 부분에 초점을 맞추고 API를 통해 나머지 스택과 통신하는 구성 요소로 개발하여 다른 기여자가 동작을 모방하고 나중에 특정 어댑터?

tl;dr: 먼저 자체 "배터리"를 구축하는 데 집중함으로써 Grafana는 모든 기능을 갖춘 경고 시스템을 갖게 되며 나중에 타사 경고 도구와의 통합을 위한 서비스로 발전할 수 있습니다.

이 문제가 해결되지 않은 경우 사소한 문제입니다. 리소스가 매우 동적(프로비저닝 및 폐기)되기 때문에 기존 경고 시스템은 클라우드 인프라에 맞게 확장되지 않습니다. 메트릭에 대한 경고는 유혹 또는 그룹화 기능을 지원해야 합니다(예외 재정의 포함, 때때로 워크로드가 다름). 템플릿 또는 그룹화된 경고는 새 그룹 집합을 검색할 수 있어야 합니다.

업데이트해주셔서 감사합니다! 내 사용 사례에서 Grafana의 기본 제공 경고는 현재 필요한 모든 것입니다. 나는 참을성 있게 Grafana 경고를 참을성 있게 기다리고 있었습니다.

IRC에서 약속한 대로 다음은 이에 대한 사용 사례입니다.

searches our logs 대해 patterns searches our logs 레거시 Rails 앱이 있으며
특정 pattern 가 thresholds 넘으면 응답하는 HTTP API이고
따라서 상태는 {OK,WARNING,CRITICAL} 입니다.

Threshold 는 다음 중 하나일 수 있습니다.

• pattern 가 존재하는 경우 CRITICAL 의 status 입니다.
• pattern 가 X번 이상 발견되면 status 는 WARNING
status 는 Y번 이상 발견되면 CRITICAL 입니다.
• pattern 가 1시간 미만이면 status 는 OK .
  3시간 미만 status 은 WARNING 이고 그렇지 않으면 status 입니다.
  CRITICAL .

이 기능을 올바르게 이해하면 Grafana에서 이 사용법을 지원할 것입니다.
이 기능과
Elasticsearch 데이터 소스가 완전히 구현되었습니까?

@Dieterbe @matttttt 슬라이드와 목업은 정말 놀랍습니다! 이것은 진정으로 게임 체인저입니다.
나에게 내부 Grafana 경고 처리기는 우리의 요구에 가장 적합할 것입니다.
원인:

• 셀프 서비스 - 매우 중요 합니다. 우리 사용자들은 Grafana 내에서 스스로 종단 간 경고를 만들고 싶다고 크고 명확하게 말했습니다.
• 통합 워크플로 - 움직이는 부분을 늘리지 않고 최소화하고 싶습니다. @Dieterbe가 지적했듯이 타사 경고 처리기는 내부 경고 처리기가 1개만 필요로 하는 최소 4단계가 필요합니다(각 임계값에 대한 알림 방법을 정의해야 하는 경우 2
• 긴밀한 통합 및 타사 알림 인프라에 대한 종속성이 없습니다.

몇 가지 우려 사항:

• 주파수 검사 임계값은 무엇입니까?
• 데이터를 다시 가져오기에는 너무 빠른 폴링 빈도를 어떻게 처리합니까? 로그, 경고 및 대기 중이거나 삭제되었습니까?
• 확장의 경우 Grafana가 검사 횟수, 빠른 빈도, 특히 내부 경고를 지원하기 위해 Grafana 서버를 추가/확장해야 하는 데이터 소스 간의 대기 시간을 따라가지 못할 수 있다는 점을 우려합니다. 지금 여러 타사 경고 처리기 인스턴스가 필요하기 때문에 이 사실을 알고 있습니다. 이 경우 특히 검사가 동일한 데이터 소스에서 온 경우 Grafana 서버 클러스터 간에 임계값 검사를 원활하게 할당하거나 대기열에 넣을 수 있습니까? 사용자 경험에서 저는 사용자가 특정 확인을 위해 Grafana의 특정 "할당" 인스턴스로 이동하지 않고도 부하 분산된 Grafana 서버 클러스터를 통해 임계값을 원활하게 생성할 수 있기를 바랍니다.
• 알림의 경우 알림을 쉽게 개발하고 통합할 수 있도록 일종의 플러그인 아키텍처를 지원합니까? 일반적으로 HTTP POST를 수행할 수 있는 것이 필요합니다. 이것은 PagerDuty, xMatters, VictorOps, Opsgenie 등과 같은 것들에서 가장 일반적입니다. 각각은 약간 다른 형식, 인증 등이 필요합니다. 이 스레드에서 이전에 언급했듯이 아마도 일반 HTTP POST 처리기가 작동할 것입니다. 원하는 모든 작업을 수행할 수 있는 사용자 지정 HTTP 서비스입니다. 또는 사용자 정의 스크립트 기능도 작동해야 합니다.
• API를 통해 임계값을 설정, 검색 및 위반할 수 있다고 가정합니다. 나는 이것이 도움이 될 것이라고 생각한다

기존 경고 시스템에 경고를 통합할 수 있는 것이 이상적이라고 생각합니다. 언급된 플랩 감지와 같은 어렵고 못생긴 문제가 처리되었으며 처음부터 모든 것을 재창조하는 것은 낭비인 것 같습니다. 나는 이것이 기능 크리프의 무게 아래 묻혀있는 것을보고 싶지 않습니다.

그러나 이것이 이러한 모든 경고 처리기에 긴밀하게 통합될 필요는 없다고 생각합니다. 훌륭하고 잘 문서화된 API는 이러한 시스템에 익숙한 사람들이 적은 노력으로 통합할 수 있도록 해야 합니다. 그래서 'grafana api -> handler'가 있는 슬라이드가 매력적으로 보입니다.

스콧

안녕하세요. 저는 이 토론에 늦게 참여했지만 이 주제에 대한 전문 지식이 있으며 경고 문제를 해결하려고 시도한 도구 중 하나의 수석 개발자입니다. 우리의 도구인 StatsAgg 는

어쨌든 경고 주제에 대한 몇 가지 생각:

• 개별 메트릭으로 알림을 보내는 것은 좋지 않습니다. 저는 수천 대의 서버를 관리하는 회사에서 일하고 있으며 '사용 가능한 디스크 공간 %'의 각 메트릭 시리즈에 대해 별도의 경고를 생성/구성/관리해야 하는 것은 논리적으로 실행 불가능합니다. 엔터프라이즈 모니터링 도구는 여러 메트릭 시리즈를 정규식(또는 와일드카드 식)과 함께 묶는 경우가 많습니다. StatsAgg는 동일한 전제에 구축되었습니다. 여러 메트릭 시리즈가 함께 연결되면 메트릭 그룹에 단일 '경보'로 경고 임계값 검사가 실행됩니다. 규모에서 이러한 종류의 기능은 필수입니다.
• 경고 도구가 개별 메트릭에 대해 경고를 보내서는 안 된다는 나의 이전 주장을 받아들인다면 도구에는 자격을 갖춘 메트릭 및 메트릭 값 목록을 신속하게 얻을 수 있는 메커니즘이 있어야 합니다. 많은 도구가 쿼리 데이터 저장소에 의존하여 메트릭 및 메트릭 값 목록을 가져오며 이 솔루션은 솔직히 대규모로 잘 작동하지 않습니다. 경고 논리는 본질적으로 자주 실행해야 합니다(X초마다 또는 각각의 새로운 적격 데이터 포인트가 롤인될 때마다). 데이터 저장소(graphite, opentsdb, influxdb 등)는 '이 패턴을 준수하는 현재 메트릭 목록 제공' 및 '이 Y 메트릭에 대한 마지막 X 값 표시'의 지속적인 쿼리를 처리하도록 구축되지 않았습니다. 적절한 API/쿼리 언어가 없거나 단순히 로드를 처리할 수 없습니다. 분명히 하자면, 데이터 저장소에 10,000,000개의 사용 가능한 메트릭 시리즈가 있을 때 10,000개의 메트릭 시리즈에 대해 경고 논리를 실행하는 규모에 대해 이야기하고 있습니다. 이것은 모든 사람의 사용 사례는 아니지만 우리 회사의 사용 사례입니다.
• 스트림 처리를 통해 문제를 해결하는 것이 마지막 글머리 기호에서 제기한 문제를 해결할 수 있는 유일한 실행 가능한 방법이라는 것을 알았습니다. 이것이 StatsAgg가 데이터 저장소 앞에 위치하도록 구축된 이유입니다. 경고 논리는 데이터 저장소를 건드리지 않고 지표에 대해 실행할 수 있으며 지표는 데이터 저장소로 전달됩니다. 이 접근 방식의 주요 개념은 1) 새로 생성된 경고는 경고 평가를 위해 이전/아카이브된 메트릭 값을 사용할 수 없거나 사용하지 않을 것입니다. 2) 스트림 처리 프로그램(예: StatsAgg)이 충돌하면 데이터 포인트가 3) 경보 평가에 필요한 메트릭 값이 메모리에 저장되므로 서버 안정성 문제가 될 수 있습니다. 4) 스트림 처리 프로그램은 들어오는 메트릭을 분해 및 재구성할 수 있어야 합니다(InfluxDB는 작년에 쉽게 만들지 못했습니다...). 이러한 자만심에도 불구하고 이 솔루션은 우리 회사와 대규모 규모에서 매우 효과적이었습니다. 때때로 우리는 200,000개 이상의 라이브 메트릭 시리즈, 평균 30,000개 이상의 수신 메트릭/초, 수천 개의 메트릭 시리즈를 평가하는 수백 개의 경고 및 거의 땀을 흘리지 않는 StatsAgg를 실행하는 서버를 가지고 있습니다. 그 동안 데이터 저장소는 전혀 쿼리되지 않습니다.

이것들이 내가 언급하고 싶었던 주요 내용입니다. 경고에 대한 다른 중요한 측면도 많이 있지만(알림, 일시 중단 등) 이러한 솔루션은 핵심 문제의 아키텍처가 해결되면 쉽게 적용할 수 있습니다. 우리가 필요로 하는 규모가 일반 사용자와 같지 않다는 것을 알고 있지만 여러분 모두가 이 관점을 이해할 수 있기를 바랍니다.

Alerta에 데이터를 보낼 수 있는 알림 처리기로 시작하는 것을 제안하고 싶습니다: https://github.com/guardian/alerta

Alerta에는 알림 수신을 위한 매우 정상적인 REST API가 있습니다.

나는 린 grafana 전용 구현을 선호합니다!
모든 사람들이 전형적인 환상적인 Grafana UX에서 이 기능을 경험한 후에 재평가할 가치가 있다고 생각합니다.

사람들이 통합하고 싶어하는 복잡한 사례 및/또는 맞춤형 백엔드 시스템이 많이 있을 것입니다. 이 스레드에서 많은 것을 볼 수 있습니다. 대부분은 오픈 소스이지만 시중에는 너무 많은 상용 제품도 있습니다! 개별 핸들러를 신경 쓰지 마십시오. 쥐 전체가 될 것이며 항상 잡기 모드에 있게 됩니다.

두 가지 유형의 핸들러만 구현하는 것이 좋습니다. 하나는 확실히 HTTP POST이며 가장 다재다능하고 유연한 도구가 될 것입니다. 다른 하나는 사용자 지정 스크립팅이므로 사용자가 선택한 특정 도구와의 통합을 구현할 수 있습니다. Plugin 모델은 나쁘지 않은데 특정 Plugin 언어를 강제로 사용해야 하는 제약이 있다. 외부 스크립트가 더 좋습니다. 스크립트에 모든 세부 정보를 전달하는 한, 스크립트는 모든 언어(셸 스크립트, Python 등)로 작성할 수 있습니다.

@007reader 와 함께해요

나는 동의한다. 공통 통합 방법이 제공되는 한 사용자 정의 구현은 별도의 프로젝트 또는 배포가 될 수 있습니다.

예를 들어 최근 CloudWatch 릴리스도 괜찮지만 대체 스토리지에 동기식으로 선택한 메트릭만 사용하여 별도의 프로젝트로 만들고 싶습니다. 단 2주 데이터 대신 전체 보존을 제공합니다.

안녕 모두들,
내 grafanacon 프레젠테이션 비디오가 온라인에 있습니다!
https://www.youtube.com/watch?v=C_H2ew8e5OM에 있습니다.
나는 당신이 볼 수 있듯이 그것이 많이 해결 될 것이라고 생각합니다. 통합의 세부 사항은 아직 파악해야 하며 많은 사람들이 논의하고 싶어하는 주제이기도 했습니다. (시간이 제한되어 모든 사람들이 참여할 수 있도록 여기에서 대화를 계속하도록 요청했지만)

@simmel 맞습니다. ES 쿼리를 사용하고 이에 대한 규칙을 설정합니다.
@activars re grouping and discovery, 많은 부분이 데이터 소스에 따라 달라질 것이라고 생각하지만 이전에 볼 수 없었던 메트릭/시리즈를 "자동 검색"하는 데 매우 능숙한 흑연이나 ES와 같은 것을 사용하는 경우 가장 일반적인 요구 사항을 해결해야 합니다. /흑연 또는 쿼리(ES의 경우)에 대해 주어진 표현식(와일드카드 포함)과 일치하는 문서. 다른 출처는 확실하지 않습니다. 규칙에 예외를 적용해야 하는 것에 대한 귀하의 의견은 더 까다롭습니다. 우리는 아마도 어느 시점에서 이를 해결해야 할 것이지만 상황이 더 명확하고 더 안정될 때까지 기다릴 수 있다고 생각합니다. 어쩌면 우리는 어떻게 든 그것을 필요로하지 않을 수 있습니다.
@mgravlin 빈도는 아직 확실하지 않은 너무 느린 데이터 소스를 처리하는 규칙의 설정입니다. 하지만 하지 마세요 ;-) . 또한 핸들러 종속. 확장 배포가 가능해야 하며 핸들러도 포함되어 있으므로 확실히 살펴보겠습니다. 그러나 첫 번째 릴리스의 우선 순위가 아닐 수도 있습니다. 예, 알림 플러그인이 핵심이며 원하는/필요한 것을 사용할 수 있는지 확인합니다. 다시 API: 네 :)
@sknolin 내가 올바르게 이해한다면 grafana는 nagios/bosun과 같은 다른 시스템을 사용하는 경우에도 경고 예약, 실행, 알림 후크 트리거 등을 수행합니다. 그렇다면 외부 시스템(nagios/bosun/...)의 역할은 정확히 무엇입니까? 이것은 @Crapworks 가 말하는 것과도 유사합니다.
@jds86930 StatsAgg는 꽤 흥미롭게 보입니다. 여기에서도 grafana와의 통합이 의미가 있다고 생각합니다. 스트림 처리는 반복되는 쿼리에 대한 대안이 될 수 있는 유효한 접근 방식이라고 생각합니다. 그러나 후자는 시작하기가 더 간단하고 일반적으로 더 간단하다고 생각합니다. 그러나 둘 다 지원되어야 합니다. 예, grafana에서는 데이터 스펙트럼과 일치하는 패턴/쿼리를 설정할 수 있고 잠재적으로 새로운 시리즈/데이터가 라이브가 될 때 이를 포함할 수 있습니다. 그러나 우리의 견해로는 데이터 소스가 가지고 있는 모든 기능을 활용할 것입니다(예: 흑연은 와일드카드, glob 표현식 등, Elasticsearch 풍부한 데이터 및 쿼리 모델을 사용하여 이 작업에 매우 능숙함). 또는 누군가가 grafana+StatsAgg를 사용한다면 StatsAgg를 사용하여 해결하세요. grafana 자체가 여기서 특정 작업을 수행해야 한다는 말씀이신가요? 데이터 소스가 충분히 빠르지 않다면 데이터 소스 문제를 해결하십시오. 메트릭 메타데이터에 대한 캐싱이 있는 더 빠른 것을 얻을 수 있습니다. 하지만 어느 쪽이든 Grafana에 관한 한, 내가 생각할 수 있는 많은 변화가 없을까요?
@blysik 예 재미있어 보입니다. 우리가 통합해야 하는 알림 도구가 너무 많습니다 :) 분명히 하기 위해 알림 규칙을 관리하고 지금까지 제시된 방식으로 알림 규칙을 시각화하는 아이디어가 마음에 드시나요? 하지만 알림을 처리하기 위해 알림을 사용하고 싶습니까? ? alerta는 경고 상태를 확인하는 주요 장소이지만(이는 합리적인 일처럼 보임) 통합을 보는 방법을 완전히 이해하고 있는지 확인하고 싶습니다.

@007reader , @shanielh , @activars 일반 HTTP 게시물 또는 스크립트를 통한 이 통합의 목표는 무엇입니까? 외부 시스템에 "새로운 규칙이 있습니다. 여기에 쿼리, 임계값, 빈도 등이 있습니다. 이제 실행하십시오"라고 알리려면? 아니면 grafana가 규칙을 실행한 다음 외부 시스템을 새 상태로 업데이트하는 것입니까?

@blysik 예 재미있어 보입니다. 우리가 통합해야 하는 알림 도구가 너무 많습니다 :) 분명히 하기 위해 알림 규칙을 관리하고 지금까지 제시된 방식으로 알림 규칙을 시각화하는 아이디어가 마음에 드시나요? 하지만 알림을 처리하기 위해 알림을 사용하고 싶습니까? ? alerta는 경고 상태를 확인하는 주요 장소이지만(이는 합리적인 일처럼 보임) 통합을 보는 방법을 완전히 이해하고 있는지 확인하고 싶습니다.

옳은. Alerta는 알림 허브가 될 것입니다. 경고를 보내는 모든 종류의 것들. 예: 사용자 정의 스크립트, Cabot, Zenoss, vCenter 및 아마도 Grafana. 이는 운영팀이 모든 경고를 볼 수 있는 단일 장소를 제공합니다. 그런 다음 대기 중인 엔지니어에게 알림을 보내는 단일 위치입니다.

@sknolin https://github.com/sknolin 내가 올바르게 이해한다면 귀하의
보기, grafana는 경고 예약, 실행, 트리거를 수행합니다.
알림 후크 등, 다음과 같은 다른 시스템을 사용하는 경우에도
나기오스/보순. 그렇다면 외부 시스템의 역할은 정확히 무엇입니까?
(나기오스/보순/...) . 이것은 @Crapworks와도 유사합니다.
https://github.com/Crapworks 에 대해 이야기했습니다.

제가 설명을 잘 못드린거 같네요. 그건 내가 원하는 것이 아니야, 그라파나
그 모든 일을 하고 있습니다. @Crapworks (입력하는 것이 재미있음)는 수동적으로 말하고 있습니다.
서비스 검사, 나는 그냥 액티브 폴링을 사용할 것입니다.

그래서 내가 원하는 것은 grafana 경고 상태를 읽을 수 있는 API뿐입니다.
외부 시스템은 다른 모든 작업을 수행합니다.

그것은 그것이 어떻게 든 위대한 장군으로 발전하지 않았다는 것을 의미하지 않습니다.
경고 도구 나는 그것을 사용하지 않을 것입니다. 그냥 내가 지금 할 것입니다.

스콧

@sknolin

그래서 내가 원하는 것은 grafana 경고 상태를 읽을 수 있는 API뿐입니다.

그 상태는 grafana에서 어떻게 업데이트됩니까? grafana에서 경고를 실행하고 상태를 업데이트하는 프로세스는 무엇입니까?

폴링될 때마다 grafana는 경고 상태를 업데이트하며, 이를 폴링하는 여러 시스템을 처리하기 위해 일종의 캐싱 간격을 사용합니다.

나는 이것이 여전히 경고에 대한 논리를 수행하고 그것을 제시하기 위해 grafana가 필요하다는 점을 알고 있습니다. 생각해 보니 어떤 종류의 경고도 필요하지 않습니다.

그래프 패널에서 메트릭에 대한 현재 값을 검색할 수 있다면 필요한 모든 경고를 수행할 수 있다고 생각합니다. 예를 들어 여러 카운터 메트릭의 합계에서 비율을 도출하고 그래프로 표시하는 경우 모니터링 시스템으로 현재 값을 폴링하는 것이 좋습니다. 어쩌면 지금은 완전히 가능하고 나는 둔감합니다.

스콧

@Dieterbe 후자 :

grafana는 규칙을 실행한 다음 외부 시스템을 새 상태로 업데이트하는 것입니다.

@Dieterbe 데이터 소스의 기본 쿼리 구문을 사용하여 데이터 소스(Graphite, OpenTSDB 등)를 폴링하는 것이 가장 간단하고 쉬우며 Grafana에 기본적으로 경고를 보내는 가장 빠른 방법일 것이라는 데 동의합니다. 많은 사람들에게 이러한 종류의 솔루션은 그들의 요구를 충족시킬 것이며 이것이 초기 Grafana 구현을 위한 최상의 솔루션이라고 생각합니다(제 생각에는). 내 주요 요점은 '데이터 소스 폴링' 모델로 과거에 작업하기 힘든 경고 구성 가능성 및 성능에 대한 상한선이 있다는 것입니다.

Grafana가 장기적인 경고 솔루션으로 갈 수 있는 방향과 관련하여 몇 가지 옵션을 볼 수 있습니다.

• 데이터 저장소 유지 관리자와 협력하여 알림 사용 사례에 대해 더 빠르고 더 나은 목적에 맞게 구축된 API를 구축합니다. 많은 프로젝트가 더 느린 속도로(몇 개월에서 몇 년) 진행되고 개선 요청의 일부/전체를 수락하지 않을 수 있기 때문에 이 옵션이 마음에 들지 않습니다. 그들은 또한 항상 빠른 언어(예: Python의 Graphite)가 아닌 데이터 저장소의 모국어로 코딩하기를 원할 것입니다.
• 각 데이터 저장소에 대한 스트림 처리/캐싱 레이어를 별도의 레인탱크 프로젝트로 구축합니다. 다양한 데이터 저장소 유지 관리자가 프로젝트를 위한 솔루션을 구축하도록 유도하는 것보다 궁극적으로 더 나은 결과를 얻을 수 있다고 생각합니다. 이렇게 하면 이미 수행 중인 작업을 계속 확장할 수도 있습니다(기존 데이터 저장소 쿼리 메커니즘 사용). 데이터 저장소에 대한 Grafana의 쿼리 구문을 단순화할 수 있는 스트림 처리/캐싱 계층에 고유한 사용자 지정 API를 구축할 수도 있습니다.
• 작업 중인 기본 솔루션을 고수하고 잘 작동하도록 하세요. StatsAgg, bosun 등과 같은 타사 도구는 더 까다롭고/특화되고/복잡한 사용 사례에 사용할 수 있습니다. Grafana를 이러한 도구와 통합하는 것은 사용자에게 분명히 추가적인 이점이 될 것이지만 Grafana에 사소하지 않은 복잡성을 추가할 것입니다. 즉, 어쨌든 이 작업을 수행하게 될 것 같습니다(지금 프레젠테이션의 슬라이드 35에서 'Alerting Backends'를 보고 있습니다). 저는 개인적으로 StatsAgg에서 Grafana 친화적인 API 세트를 구현하는 데 열려 있습니다. API가 무엇인지 파악하고 API 프로토콜 문서 초안을 작성해야 합니다. 그것에 대해 논의하고 싶다면 언제든지 저에게 메시지/이메일을 보내주십시오.

안녕하세요 여러분,

@Dieterbe 방금 귀하의 프레젠테이션을 보았고 내용이 훌륭해 보입니다. 많은 커뮤니티 의견을 사용하여 "올바른" 방식으로 경고 시스템을 구축하려고 노력하고 있다는 점에 진심으로 감사드립니다! 감사 해요!

나는 또한 내가 말하려는 것이 분명하지 않다고 생각하기 때문에 내 요점을 조금 더 명확하게 하고 싶습니다. 나는 grafana가 Nagios, Icinga, Bosun 등과 같은 다른 모니터링 시스템을 인식하도록 요구하지 않습니다.

• 프레젠테이션에서 과시한 멋진 사용자 인터페이스 또는 완전히 완성되었을 때의 모습
• 완전히 구성 가능한 일반 HTTP POST 처리기(여기에 다른 사람들도 제안한 것처럼)(나중에 예제를 제공할 것입니다)

내가 생각하는 이벤트 흐름 :

• grafana에서 데이터를 시각화합니다.
• grafana에서 경고에 대한 임계값을 추가합니다.
• 임계값을 초과하는 즉시 HTTP POST 처리기가 트리거됩니다.
• 이때부터 그라파나 작업이 완료됩니다.

@mgravlin 및 @007reader가 언급한 것처럼 대부분의 알림 및 경고 서비스는 HTTP POST를 사용하여 다양한 종류의 데이터를 요구합니다. 따라서 내가 생각할 수 있는 가장 일반적인 것은 사용자가 POST 데이터와 헤더를 정의하도록 하여 다른 템플릿을 사용하여 하나의 핸들러로 여러 시스템에 공급할 수 있도록 하는 것입니다. 의사 코드 예:

"notificator": {
    "httppost": {
        "data": {
            "host": "$hostname",
            "alert": "$alertname",
            "state": "$state"
        },
        "header": {
            "content-type": "application/json"
        }
    }
}

사용자에게 여기에서 사용할 충분한 변수를 제공하면 수많은 백엔드를 공급할 수 있을 만큼 강력합니다.

그리고 이러한 종류의 핸들러를 사용하면 코딩 지식이 있는 모든 시스템 관리자가 자체 http 게시물 수신기를 구축하고 예를 들어 http 게시물을 이해하지 못하는 피드 백엔드를 원하는 방식으로 변환할 수 있습니다.

이는 상태 비저장이므로 확장됩니다. 백엔드/API/무엇이든 간에 로드 밸런서를 배치하기만 하면 됩니다.

적어도 이것은 내 문제의 대부분/거의를 해결할 것입니다 ;)

건배

이 기능을 만들어 주셔서 감사합니다. 대략적인 출시일이 있나요?

torkelo는 IRC에서 대략 3개월이라고 말했습니다.
내가 그를 올바르게 이해했다면 그것은 정말 대략적인 추정치이며 그렇게 취급되어야 합니다.

나는 grafana로 경고를 할 수 있는 능력에 대해 흥분합니다. 이것이 grafana가 궁극적인 모니터링 도구가 되지 못하게 하는 하나의 기능이라고 생각합니다.

초기 알파/베타 릴리스가 있는 경우 프로덕션 데이터를 테스트하고 초기 피드백을 제공하고 싶습니다.

++

나 2 ㅋㅋㅋ

+1

Em seg, 2015년 11월 16일 21:03, Jing Dong [email protected]
에스크로:

초기 알파/베타 릴리스가 있다면 일찍 테스트하고 제공하고 싶습니다.
생산 데이터에 대한 피드백.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/grafana/grafana/issues/2209#issuecomment -157202686.

+1
초기 알파/베타 릴리스가 있는 경우 프로덕션 데이터를 테스트하고 초기 피드백을 제공하고 싶습니다.

+1 나 2

2015-11-21 14:44 GMT-02:00 chaosong [email protected] :

+1
초기 알파/베타 릴리스가 있는 경우 일찍 테스트하고 제공하고 싶습니다.
생산 데이터에 대한 피드백.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/grafana/grafana/issues/2209#issuecomment -158661279.

+1

모든 +1을 보는 것은 좋지만 FWIW에서는 실제로 필요하지 않습니다. 우리는 그것이 가장 간절히 기다려온 새로운 기능이라는 것을 이미 알고 있으며, 일단 가시적인 진전이 있으면 코드는 누구나 사용할 수 있는 별도의 분기에 나타납니다. BTW 우리는 또한 grafana에서 풀타임으로 일할 더 많은 사람들을 데려오고 있으므로 모두 지켜봐 주십시오. :)

예, 484명이 이 문제를 "보고 있습니다". "+1"할 때마다 484명이 이메일 알림을 받습니다. 알림을 구독하기만 하면 해당 문제에 대한 관심이 표시됩니다.

+1 >; NS

2015년 11월 30일 월요일 10:33:52 -0800에 Vadim Chekan은 다음과 같이 썼습니다.

예, 484명이 이 문제를 "보고 있습니다". "+1"할 때마다 484명이 이메일 알림을 받습니다.

죄송합니다. 여러분이 이 일을 위해 매우 열심히 일하고 있다는 것을 압니다. 첫 출시 일정이 있나요?

경고 메트릭 및 임계값(웹 인터페이스 또는 API를 통해) 및 이러한 메트릭을 확인하고 JSON으로 HTTP POST를 수행하거나 stdout에서 JSON으로 스크립트를 호출하는 Grafana cronjob/데몬을 구성할 수 있게 되어 더할 나위 없이 기쁩니다. 개인이 이 정보를 Pagerduty, Slack, IRC, SMS, 이메일 등으로 전달하는 간단한 파이썬 스크립트를 작성하는 것은 _매우 간단합니다.

편리함을 높이 평가하고 싶지만, 타사 도구와 긴밀하게 통합하는 것이 Grafana의 역할이라고 생각하지 않으며, 나중에 제대로 구현되는 것보다 빨리 최소한의 구현을 보는 것이 좋습니다.

@anlutro 에 전적으로 동의합니다. 시작할 수 있는 간단한 정보를 제공하세요. 저에게 가장 흥미로운 점은 사람들이 스스로 간단한 알림을 설정할 수 있도록 하는 것입니다(셀프 서비스). Grafana는 기존 알림/에스컬레이션 솔루션을 대체하려고 해서는 안 됩니다.

저도 @anlutro에 동의합니다. 그러나 단순한 API를 제공하는 대신 API와 상호 작용하는 사용자 정의 플러그인을 처리할 수 있는 경고 부분이 있습니다. 그렇게 하면 기본 패키지에 이메일, 호출기 및 기타 몇 가지가 포함될 수 있으며 커뮤니티는 필요에 따라 추가할 수 있습니다. Logstash 플러그인이 지금 처리되는 방식과 유사합니다.

+1

경보 시스템에 대한 소식이 있습니까? 어떤 견적?

+1

+1
히트 및 히스테리시스 메커니즘은 고려해야 할 개념으로 수집 경보에 대해 언급할 가치가 있습니다.

이상 탐지, 상관 관계 탐지, 근본 원인 탐지 등과 같은 고급 경고 기능에 대해 생각해 보셨습니까?

+1. 플러그인 하위 시스템으로 알림 - 가장 유연한 솔루션입니다. 백엔드에서 이 작업을 더 잘 수행할 수 있는 프로젝트가 많은 경우 grafana 내부에 너무 많은 기능을 추가할 필요가 없습니다.

@Dieterbe @torkelo 이것에 대해 아주 대략적인 "추측"이라도 하는 것이 좋을 것입니다. 개인적으로 메트릭 기반 셀프 서비스 알림이 제 경우에 매우 필요한 기능이기 때문에 계속 유지해 왔으며 Grafana가 이에 적합한 사용자 프런트 엔드라고 확신합니다. 문제는 이제 6개월이 지났고 ETA 업데이트가 없었고 꽤 오랫동안 여러분 중 한 사람의 댓글도 없었기 때문에 생산적인 생각에 반대하는 "나는 그저 뭔가를 해킹해야 할 것입니다"라는 생각이 들기 시작했다는 것입니다. ..만약 6개월이 더 걸릴지 몇 주가 더 걸릴지 알 수 있다면 훨씬 더 나은 정보에 입각한 결정을 내릴 수 있습니다.

감사 해요!

+1
2016년 1월 18일 오후 9시 54분에 "Jaime Gago" [email protected]이 다음과 같이 썼습니다.

@Dieterbe https://github.com/Dieterbe @torkelo
https://github.com/torkelo 매우 거칠어도 좋습니다.
이에 대해 "추측"합니다. 개인적으로 메트릭스 이후로 계속 유지하고 있습니다.
기반 셀프 서비스 알림은 제 경우에 매우 필요한 기능이며 저는
Grafana는 이에 적합한 사용자 프런트 엔드라고 확신했습니다. 문제는 지금이다.
6개월이 지났지만 ETA 업데이트가 없었고
당신은 꽤 오랫동안 그래서 나는 "나는 단지해야 할 것입니다.
뭔가 해킹" 생산적인 생각에 반대...
몇 주 더 6개월을 더 하면 훨씬 더 많이 벌 수 있습니다.
더 나은 정보에 입각한 결정.

감사 해요!

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/grafana/grafana/issues/2209#issuecomment -172722684.

+1

+1

@jaimegago 진행 상황이나 이 문제에 대한 진행 상황을 업데이트하지

9월에 저는 데이터 소스 중심 2.5 릴리스의 기반이 된 Elasticsearch 데이터 소스 지원 작업을 시작했습니다. 그 후 v1 이후 Grafana에서 가장 높은 평가를 받은 문제는 테이블 패널이었습니다. 특히 Elasticsearch 지원 이후에는 테이블과 함께 작은 릴리스를 느꼈습니다. 패널은 경고보다 중요하므로 2.6의 기반이 되었습니다.

최근에 Grafana와 더 많은 통합을 원하는 많은 사용자와 회사가 있어 플러그인 API 및 기능을 개선하기 위한 작업을 하게 되어 이 문제에 대한 또 다른 연기가 발생했습니다. 우리가 이것을 제대로 전달하지 못해서 정말 죄송합니다. 우리는 항상 SOON을 시작하려는 야망을 가지고 있었지만 SOON은 계속해서 밀려났습니다 :(

하지만 희망이 있습니다! 우리는 풀타임 Grafana 집중 팀을 확장했으며, 12월 @bergquist가 합류했으며 2월에 다시 한 번 강화될 것입니다. ETA를 제공할 수는 없지만 이것은 여전히 ​​우선순위가 높은 문제이며 최대한 빨리 시작하기를 원합니다. 우리는 이 기능이 Grafana 3.0의 헤드라인 기능이 되기를 바랍니다.

@torkelo 업데이트에 감사드립니다. 내가 행복하다고 말할 수는 없지만 적어도 새로운 우리는 우리가 어디에 서 있는지 알고 있습니다.

남은 질문은 2.x가 더 많은 포인트 릴리스를 얻을 것인지 아니면 3.x가 다음 릴리스가 될 것인지입니다. ;)

@RichiH 다른 포인트 릴리스에 대해서는 확실하지 않지만 3.0 이전의 다른 포인트 릴리스가 2월에 릴리스될 가능성이 있습니다.

@torkelo 시간을 내어 자세한 업데이트를 제공

이것은 이미 로드맵에 있을 수 있습니다. 그렇지 않은 경우 알림에 "POST"를 추가하는 것을 고려하십시오.
따라서 kafak과 같이 다른 시스템에 경고를 보내 처리하도록 할 수 있습니다.

+1 SNMP 알림!

+1 이것이 Grafana를 생산을 위한 실행 가능한(동급 최고의) 모니터링 도구로 만드는 가장 큰 누락 기능이라고 생각합니다.

+1

공동 작업자가 아닌 이 문제에 대한 댓글을 잠글 수 있는 관리자(@Dieterbe?)가 있습니까? 따라서 우리는 기능 향상에 대한 흥미로운 콘텐츠만 얻을 것이며 쓸모없는 +1은 얻을 수 없습니다...

이 기능을 모르는 경우 임시 GitHub 문서에 대한

감사합니다:하트:

@Mayeu 어, 이 문제에 +1 이상 기여한 "비협력자" 중 한 명으로서 다른 곳에서 이 문제를 협력자에게 고정시키는 것이 갈 길이 아니라고 생각합니다. 이메일에 스마트 필터를 만드세요 ;-).

나는 또한 +1이 목적을 채우고 이것에 대한 관심의 양과 스프레드를 보여주고 있다고 생각합니다.
아마도 누락된 것은 동일한 역할을 수행하지만 모든 구독자에 대한 모든 알림이 없는 UI의 +1 버튼입니다. 그래서 @github에 대한 기능 요청입니다.

우리는 주제에서 벗어나고 있으며 이것이 내가 이것에 관해 글을 쓰는 처음이자 마지막입니다.

이 문제에 관심이 있는 사람은 오른쪽 상단에서 구독해야 합니다. 그것은 당신에게 정보를 유지하고 모든 사람에게 이메일을 보내지 않을 것입니다.

+1의 누적을 방지하기 위한 투표 시스템에 대해서는 https://github.com/dear-github/dear-github - 27일 stale 및 GitHub의 반응 없음을 참조

+1

이것에 대한 소식이 있습니까?

아직 이 문제에 대한 소식이 없다고 생각합니다. 그러나 Grafana의 다음 릴리스에 대한 좋은 점은 다음과 같습니다.

Grafana는 맞춤형 앱/플러그인을 처리할 수 있습니다. 그런 다음 자체 사용자 지정 알림 플러그인/앱을 작성하고 Grafana로 가져올 수 있습니다. 이러한 작은 앱/플러그인을 작성하는 것은 큰 알림 기능을 기다리는 동안 빠른 승리가 될 것입니다.

시각화와 같은 위치에 경고를 구성한다는 아이디어가 마음에 듭니다. https://www.youtube.com/watch?v=C_H2ew8e5OM의 놀라운 모형이지만 언제 출시되는지 날짜가 있습니까?

좋은 영상, 감사합니다!

일부 피드백.

나는 단순한 선형 임계값과 고급 사용자 정의 쿼리라는 아이디어에 만족합니다.

가장 유용한 알리미:

• exec - ssh 또는 sendmail과 같은 것을 사용할 수 있습니다.
• webhooks - 사용자는 webcgi를 세워서 web-hooks를 픽업하여 작업을 수행할 수 있습니다...
• 이메일 - 알림 데이터의 json 덤프가 포함된 간단한 이메일을 실행합니다.
• 플러그인 ...별로 필요하지 않습니다.

경고 상태를 가져오는 API... 나쁜 생각처럼 느껴집니다.
그러나 기본 json 형식으로 경고 구성을 가져오는 API가 좋을 수 있습니다.
이 json 덤프는 다른 시스템이 변환하는 데 도움이 될 수 있는 것으로 변환될 수 있습니다.

이것이 눈살을 찌푸리게 하는 것인지 아닌지 확실하지 않습니다. 어디에도 기부 링크를 찾을 수 없지만 월말까지 이것을 v3로 가져오려면 어떤 종류의 기여가 필요할 것입니다.. 우리는 이 기능 할당을 실제로 사용할 수 있지만 리소스를 사용할 수 있습니다. 묶여있다 ATM

+1

+1

이것은 Work Market에서 우리에게 매우 필요한 기능입니다.

알림 기능이 출시되었습니까?

아니요
2016년 2월 25일 목요일 오후 11시 13분에 kskaran94 [email protected]에서 다음과 같이 작성했습니다.

알림 기능이 출시되었습니까?

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/grafana/grafana/issues/2209#issuecomment -189143056.

경고 기능이 여름에 출시될 것이라고 가정하는 것이 안전할까요?

_서스펜스 심화_
2016년 2월 26일 오전 10시 23분에 "Ian Ha" [email protected]이 작성했습니다.

경고 기능이 출시될 것이라고 가정하는 것이 안전합니까?
여름?

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/grafana/grafana/issues/2209#issuecomment -189320869.

이것에 대한 소식이 있습니까?

+1

+1 이미 가지고 있으면 좋을 것입니다. 사람들은 이미 일년 내내 또는 그 이상을 기다리고 있습니다.

:+1: 좋아요. 비디오와 프레젠테이션에 감사드립니다. @Dieterbe. 테스트/얼리 어답터가 사용할 수 있습니까?

@torkelo 당신이 발표했습니다

이 기능이 Grafana 3.0의 헤드라인 기능이 되기를 바랍니다.

그러나 3.0 릴리스되지 않은 분기 변경 로그를 보면 (1) 경고에 대한 언급이 없습니다. 울면서 시작해야 합니까 아니면 경고 3.0 헤드라인 기능을 계속 가질 계획입니까?

(1) https://github.com/grafana/grafana/blob/master/CHANGELOG.md

우리는 grafana 3를 릴리스할 수 있도록 grafana 3용 플러그인 시스템을 작업하기로 결정하고 불필요하게 grafana 3을 연기하는 대신 경고 작업을 시작합니다.

@Dieterbe 내가 행복하다고 말할 수는 없지만 의미가 있습니다. 명백한 후속 조치는 경고에 대한 ETA 같은 것이 있는지 여부입니다. 3.1에 대한 확인되고 커밋된 기능인 경우.

또한 해결 방법으로 http://alerta.io/ 는 Grafana에서 원하는 작업의 일부를 수행합니다. 이 기능을 기다리는 사람들은 사용해 볼 수 있습니다.

플러그인에 대한 사양이 있습니까? 에서 무언가를 구축하는 것이 좋을 수 있습니다.
버전 3의 릴리스와 일치하도록 경고를 처리하는 커뮤니티?

베스
2016년 3월 16일 오전 8시 44분, "Richard Hartmann" [email protected]
썼다:

@Dieterbe https://github.com/Dieterbe 행복하다고 말할 수는 없지만
의미가 있습니다. 명백한 후속 조치는 ETA 같은 것이 있는지 여부입니다.
경고; 3.1에 대한 확인되고 커밋된 기능인 경우.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/grafana/grafana/issues/2209#issuecomment -197214149

@Dieterbe 클라이언트 측에서 알림을 생성하는 기능도 있으면 좋을 것 같습니다. 예를 들어 대시보드가 ​​있는 공용 모니터의 음성 메시지이므로 문제가 있음을 알기 위해 대시보드를 볼 필요가 없습니다. Zabbix 사운드 경고처럼. 이를 위해 특정 대시보드를 스캔하고 문제가 있으면 Web Speech API를 사용하여 알려주는 간단한 JavaScript 코드 를 작성했습니다. 지금은 저에게 효과적입니다.

kapacitor 를 경고용 백엔드로 사용하는

이제 3.0이 출시되었으므로 grafana에서 알림을 받을 수 있기를 바랍니다. 경고는 grafana를 최고의 도구로 만들 것입니다.

안녕하세요 @Dieterbe ,

이 버전 https://github.com/raintank/grafana (경고 패키지가 있다고 말함)에서 볼 수 있듯이 repo는 이제 더 이상 사용되지 않으며 모든 새로운 개발이 https://github 에서 진행 중인지 아니면 다른 것을 위해 계획 및 변경되었는지 궁금합니다(예: 여기에서 논의한 것과 같지 않은

안녕하세요 @minhdanh님 , 목표는 항상 grafana에 "적절하게" 경고를 추가하는 것이었습니다. 단순히 빗물탱크 전용 포크의 해킹이 아니라 귀하가 언급하는 저장소(어쨌든 매우 좁은 도메인만 다루었습니다. 해당 리포지토리에 있는 스케줄러/실행기에서 작업을 시작하면 해당 코드의 일부를 재사용하는 것이 합리적일 수 있습니다. 그래서 우리는 다가오는 grafana 3 릴리스를 위해 grafana를 플러그형으로 만들기 위해 열심히 노력해 왔습니다. (그리고 그 결과 우리는 우리 자신의 필요를 당신이 말하는 worldping-api인 독립 실행형 앱으로 옮길 수 있었습니다).
첫 번째 단계로 grafana 대시보드 및 패널 내부에서 규칙을 관리하고 일종의 API를 통해 이를 노출하여 플러그인이 규칙을 실행하는 데 사용할 수 있도록 UI를 빌드해야 한다는 것이 매우 분명해졌습니다. 이것은 경고를 시작하는 가장 빠른 방법이 될 것입니다. "배터리 포함 스케줄러/실행기"는 나중에 나타나며 참조한 코드 중 일부를 재사용할 수 있습니다.

어쨌든 먼저 grafana에서 관리 UI를 수행하고 API를 통해 규칙을 노출하고 거기에서 가져옵니다.

@dieterbe 감사합니다.

항상 그렇듯이 "아니요"일지라도 대략적인 타임 라인의 문제가 있습니다.
X 이전에".

나는 이 질문이
두 번째 부분. 상대방을 기다리는 게 얼마나 답답한지 이해해 주길 바래
울타리의 측면이 될 수 있습니다.

리차드

모바일로 보냈습니다. 나의 간결함을 용서하십시오.

안녕하세요 여러분,

Raintank가 여기에서 말하는 것이 좋기를 바랍니다. 그러나 우리는 최근에 Raintank에서 경고 작업을 위해 거의 한 달 동안의 전용 코딩 시간을 주문했습니다. 따라서 이것이 아직 최종 경고 기능으로 이어지지 않는 이유는 grafana에서 경고의 기반을 놓을 무언가가 곧 나올 것입니다. 다른 회사가 우리의 접근 방식을 따르거나 개인이 이 문제에 약간의 현금을 투자한다면 생각과 우선 순위가 훨씬 더 빨라질 것입니다.

@flyersa ,

존

모두들 안녕,

많은 사람들이 이 기능에 대해 걱정하고 있다는 것을 알고 있으며 팀에서 이 기능에 대한 작업을 시작했다는 소식을 전하게 된 것을 기쁘게 생각합니다. Grafana 3.0 베타 발표 블로그 에서 지연 이유를 설명

2단계에 걸쳐 경고 기능을 출시할 예정입니다. 첫 번째 단계에서는 사용자가 Grafana UI 내에서 경고 및 임계값을 정의할 수 있습니다. 또한 Grafana는 HTTP API를 통해 이러한 경고 정의를 타사 스케줄러 및 경고 백엔드에 노출합니다. 두 번째 단계에서는 완전히 통합된 솔루션을 위해 이러한 정의를 사용하고 조치를 취하는 백엔드 서비스를 제공합니다.

몇 주 안에 첫 번째 단계가 릴리스되기를 바랍니다.

우리는 속도와 수익성의 균형을 유지하기 위해 노력하고 있으며 @flyersa와 같은 고객의 상업적 지원에 진심으로 감사드립니다. 다른 사람들이 일반적으로 이 기능과 Grafana의 개발을 지원하고 싶다면 지원 계획 구매를 고려하십시오. 100% 오픈 소스인 훌륭한 소프트웨어를 개발하는 데 도움이 될 것입니다.

기능을 출시하고 고객의 요구 사항을 잘 충족할 수 있도록 지원하는 모든 고객과 긴밀히 협력할 것입니다.

-라지 두트 | CEO/공동 창립자 | 빗물탱크

안녕하세요 @nopzor1200 ,

업데이트해주셔서 감사합니다. 경고를 언제 사용할 수 있는지 예상하십니까?

분명히 특정 날짜에 커밋하는 것은 불가능하지만 시간 프레임(주, 개월 등)은 매우 감사할 것입니다.

10배!

안녕하세요 여러분, 정말 기대됩니다. 누군가가 이것이 표준/지원 패턴인지 확인할 수 있다면 이것을 사용하는 방법을 구상하고 있습니다. 감사합니다.

• 모니터링하려는 각 호스트는 "검사"를 내보냅니다. "수표"는 다음으로 구성됩니다.
  
  
  
  • 호스트 이름
  
  
  • 타임스탬프
  
  
  • 0=OK, 1=WARN 또는 2=CRITICAL인 상태
  
  
• 이러한 검사는 다양한 임의 소스(셸 스크립트 + cron, statsd/collectd, Nagios 검사 등)에서 올 수 있으며 Elasticsearch에 누적됩니다. 동일한 검사가 다른 호스트에서 다른 구성을 가질 수 있지만 이것은 Grafana에 불투명합니다.
• Grafana가 Elasticsearch에 연결하도록 구성하고 호스트에서 오는 모든 검사가 상태 값 >= 1일 때 경고하도록 구성하겠습니다.
• 새 호스트가 클러스터에 가입하면 Grafana에서 구성이 필요하지 않습니다. Grafana는 데이터 포인트의 출처에 관계없이 상태 1 또는 2의 모든 데이터 포인트를 볼 수 있습니다.
• 호스트가 갑자기 죽고 수표 전송을 중지하면 이를 감지해야 합니다. 이를 처리하기 위해 호스트가 시작될 때 마스터 검사를 "ON" 상태로 등록하고 값은 정상적으로 중지되었을 때만 "OFF"로 이동합니다. 이렇게 하면 지난 X초 동안 검사를 내보내지 않은 "켜짐" 호스트를 찾을 수 있습니다.
• 일반적으로 Graphana의 시계열 데이터에 대한 임계값 기반 경고를 사용하지 않습니다. 즉, Grafana 자체 내에서 "CPU Usage > 80%인지 확인"하지 않고 Grafana는 "CPU Usage State" 확인(0 / 1 / 2)을 수신하고 1 또는 2 상태에서 경고합니다.

안녕하세요 @johnnyshields ,

꽤 괜찮아 보이지만 "0=OK, 1=WARN 또는 2=CRITICAL" 대신 표준 수준 정의를 사용하지 않는 이유는 무엇입니까? syslog에서 사용하는 것은 다음 사항에 대한 사실상의 표준입니다.

• 가치 -> 심각도
• 0 -> 비상
• 1 -> 경고
• 2 -> 크리티컬
• 3 -> 오류
• 4 -> 경고
• 5 -> 공지
• 6 -> 정보 제공
• 7 -> 디버그

그리고 경고 임계값으로 고려할 수준을 grafana에 알려주는 (전역?) 구성이 있습니다.

이를 감안할 때 귀하의 게시물에 다음 변경 사항을 추가하겠습니다.

• 호스트에서 오는 모든 검사의 상태 값이 CONFIGURABLE_ALERT_LEVEL보다 크면 경고합니다.
• Grafana는 출처에 관계없이 >= CONFIGURABLE_ALERT_LEVEL 상태의 모든 데이터 포인트를 간단히 볼 수 있습니다.
• Grafana는 "CPU 사용량 상태" 검사 수준을 수신하고 적절하게 구성된 경우 경고합니다.

@brunorey 감사합니다, 의미가 있습니다!

로그 수준과 상태는 서로 다른 두 가지입니다. 6-정보 로그 메시지가 있을 수 있지만 어떻게 모든 것이 6-정보 상태에 있을 수 있습니까?

OK, WARN 및 CRITICAL 상태는 괜찮고 OK 및 CRITICAL에만 관심이 있는 사람들에게는 너무 좋을 수 있습니다. 더 많은 상태를 추가하면 의미가 보편적으로 이해되지 않는 한 혼란이 추가되므로 3으로 제한하는 것이 좋습니다.

"CPU 상태 >= WARN" 대 "CPU > 80%"에 대한 경고만 관련하여 일부 사람들은 시계열 DB에 3단계 상태를 유지하여 시간이 지남에 따라 상태가 어떻게 변경되었는지 확인할 수 있습니다. 해당 사람들은 상태 시계열 데이터를 기반으로 경고합니다. 다른 사람들은 원시 CPU 값이 80%를 초과하는 경우 경고를 원할 것입니다. 요점은 시계열 데이터에 경고를 보내는 것만으로 충분하다는 것입니다.

시계열 데이터를 직접 사용하는 것보다 정수 로그 상태 비율을 선택하는 이유는 각 노드에서 경고로 간주되는 항목을 제어할 수 있기를 원하기 때문입니다.

예를 들어 작업자 서버의 CPU는 일상적으로 100%에 가깝고 문제가 되지 않습니다. 모든 코어에서 전체 스로틀을 실행하기를 원합니다. 그러나 웹 서버의 CPU는 20% 이상이어야 합니다. 따라서 일반 CPU를 > 80%로 만든다면 웹에서는 너무 높고 작업자에게는 너무 낮습니다. (이것은 단지 하나의 경우입니다).

@johnnyshields 시계열 데이터에 대한 임계값 기반 경고를 사용하지 않는 이유를 이해할 수 없습니다. IMO는 grafana/graphite에 경고를 추가하는 데 있어 정말 강력한(유일한?) 가치입니다. 당신의 "체크" 스타일은 monit와 같은 단순한 것에 더 적합하게 들립니다. 제가 여기서 뭔가를 놓쳤나요?

위에서 설명한 것처럼 역할이 다른 서버가 많이 있으며 서버마다 임계값이 다릅니다. 궁극적으로 임계값이 Grafana 내에서 정의되는지 아니면 서버 자체에서 정의되는지의 문제입니다. 제 경우에는 서버가 더 쉽다고 생각합니다.

또한 일부 검사는 "예 또는 아니오"입니다. 예를 들어 프로세스 X가 실행 중인지, 포트 Y에 대한 핑이 응답하는지 등입니다.

이해했다. 때때로 이러한 상태를 결정하는 것은 간단하고(>80%) 때로는 복잡합니다. 복잡할 때 일부 코드는 수준을 결정하고 수준을 TS 데이터베이스로 보냅니다. 데이터가 정보로 변환되는 일반적인 관행입니다. 내 요점은, 경보 감각과 차이가 없다는 것입니다.

경고에 대한 복잡한 규칙이 필요한 경우 경고 엔진에 규칙을 빌드하고 새 TS 데이터를 생성하기 위해 규칙을 TS 파이프라인에 빌드한 다음 경고를 표시하지 마십시오.

경고 시스템을 간소화합니다. TS 파이프라인에서 복잡성을 숨깁니다.

파이프라인과 규칙 기반 경고 시스템에서 새 TS 데이터를 생성할 때의 이점은 경고를 설정하고 받는 사람에 대해 시각적이고 단순하게 경고를 유지한다는 것입니다. 20분 전에 상태가 WARN에서 CRITICAL로 변경된 것을 볼 수 있는 간단한 상태 차트일지라도 경고된 항목만 보여주는 이메일이나 SMS를 통해 보낼 수 있는 시각화가 있습니다.

호스트/역할별로 경고할 가치가 있는 것으로 간주되는 항목을 제어하려면 WARN으로 간주되는 항목과 CRIT로 간주되는 항목에 논리를 추가하는 것이 좋습니다. 알리다.

거의 모든 다른 최신 경고 시스템은 OK/WARN/CRIT로 수렴된 것으로 보이며 부분적으로 Nagios 검사와의 호환성을 원하지만 단순하게 유지하려는 아이디어가 더 중요하다고 생각합니다. Grafana가 동일한 작업을 수행하면 다른 알림/모니터링 서비스와의 통합이 더 쉬워집니다. 예를 들어, 제 경우에는 Sensu에 Grafana 경고를 보내고 나면 Sensu가 이메일, 여유 메시지 등을 보낼 것입니다. Sensu에는 OK/WARN/CRIT만 있으므로 더 이상 세분화하면 낭비됩니다.

동의 로그 경고 수준이 지나치게 엔지니어링된 것 같습니다. OK, Warn, Crit는 대부분의 경우 작업을 수행합니다.

경고 임계값에서 표준 편차 기반 경고를 수행할 수 있기를 바랍니다. 그들은 실제로 가장 유용합니다.

2016년 5월 12일 오전 8시 49분에 RWhar [email protected]에서 다음과 같이 썼습니다.

@johnnyshields 시계열 데이터에 대한 임계값 기반 경고를 사용하지 않는 이유를 이해할 수 없습니다. IMO는 grafana/graphite에 경고를 추가하는 데 있어 정말 강력한(유일한?) 가치입니다. 당신의 "체크" 스타일은 monit와 같은 단순한 것에 더 적합하게 들립니다. 제가 여기서 뭔가를 놓쳤나요?

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.

개인적으로 흑연에 입력되는 기존 TS 데이터를 사용하여 경고하는 것을 기대하고 있습니다. 특히 지정된 시간 범위 내에서 (StatsD를 통해) 응용 프로그램 메트릭의 통계를 집계합니다.

또한 경보가 임계값에서 트리거될 수 있고 임계값을 초과하는 지정된 간격(예: "rpl_delay" 경보 임계값 200 int 50 설정)이 없는 경우 200, 250, 300 등에서 경보를 유발할 수 있는 옵션이 있으면 좋을 것입니다. 추가 임계값 수준을 수동으로 지정해야 합니다.

@johnnyshields 1=WARN 또는 2=CRITICAL의 차이를
또한 5분 동안 연속 80% 이상을 감지하여 일시적인 스파이크에 대한 경고를 받지 않도록 하는 더 스마트한 경고를 사용하는 것이 좋습니다. 훨씬 더 발전된 것은 임계값 이동과 같은 것입니다. 예를 들어 웹 사이트 트래픽을 모니터링하면 X 양의 트래픽이 발생하고 한 달에 1%로 천천히 증가하지만 갑자기 트래픽이 10% 급증합니다. 시간. 또한 트래픽이 갑자기 감소하는 반대 현상도 모니터링할 수 있기를 원할 것입니다. Skyline이 없어졌기 때문에 https://github.com/etsy/skyline 과 비슷한 것입니다.

여러분, 여기 내 게시물은 사용할 경고 상태의 정확한 수에 관한 것이 아닙니다. 저는 더 일반적으로 "Grafana가 경고 사용 사례로 열거된 상태를 지원할 것입니까?"라고 묻고 있었습니다.

최적의 수(Nagios는 3을 사용하고 syslog는 7을 사용하고 일부 사람들은 2를 사용하는 등)에 대해 의견이 다르기 때문에 Grafana는 임의의 수의 상태를 지원해야 합니다.

방금 전에 말한 것을 다시 말하면 각 경고에 대해 1이 트리거되거나 0이 트리거되지 않은 상태가 두 가지만 있어야 한다고 생각합니다. 임계값에 가까워지고 있는지 알고 싶다면 더 낮은 값에 대한 추가 임계값을 만드십시오.

WARN vs. CRITICAL의 이유는 취하는 조치가 다르기 때문입니다. 한 그룹의 사람과 조치는 일반적으로 WARN에 통지되고 다른 그룹/다른 조치는 CRITICAL에 통지됩니다.

그것은 내가 0-1 시스템으로 사라지고 싶지 않다는 꽤 가치 있는 차별화입니다.

@lorenwest 다른 임계값에 대해 다른 검사를 원하면 해당 개별 그룹에 대한 추가 임계값을 만드십시오.
따라서 각 임계값은 0 또는 1입니다.
예를 들어 이 방법으로 경고를 설정하려는 또 다른 이유는 임계값이 70%보다 클 때 전자 메일을 원하고 80%를 초과할 때 페이지를 원할 때입니다. 별도의 그룹을 원하는 것처럼. WARN vs. CRITICAL은 너무 모호합니다.

@doanerock 이해가 됩니다. 하나의 TS 메트릭 또는 이벤트에 대해 임의의 수의 경고를 허용하면 유연성이 극대화됩니다. 이는 여러 수준에 대해 여러 작업을 수행하지 않음으로써 경고의 정의를 단순화합니다.

그래서:

• 메트릭은 임의의 수의 상태를 가질 수 있습니다(십진수/시계열 값 포함).
• 메트릭에는 동일한 메트릭에 연결된 여러 경고 작업이 있을 수 있습니다.
• 각 경고는 true 또는 false 부울입니다. 트리거되거나 트리거되지 않습니다.

예를 들어:

• 값이 0 = OK, 1 = WARN, 2 = CRITICAL인 특정 측정항목이 있습니다.
• 3가지 알림을 구성합니다.
  
  
  
  • 값 = 1인 경우 내 대시보드에 노란색 플래그 표시
  
  
  • 값 = 2인 경우 내 대시보드에 빨간색 플래그 표시
  
  
  • 값 >= 1인 경우 이메일을 보내주세요.
  
  

모두들 안녕,

이 주제에 대해 질문하기에 적절한 장소인지는 모르겠지만 곧 출시될 Grafana 경고 모듈과 관련하여 어떤 식으로든 시도해 보겠습니다.
우리 조직에는 이벤트에 대한 Logstash/Elasticsearch를 제공하는 모든 보안 경고 센서가 있으며 Yelp/elastalert 를 사용하여 다음 기준에 따라 특정 패턴으로 경고를 실행합니다.

"Match where there are X events in Y time" (frequency type)
"Match when the rate of events increases or decreases" (spike type)
"Match when a certain field matches a blacklist/whitelist" (blacklist and whitelist type)
"Match on any event matching a given filter" (any type)
"Match when a field has two different values within some time" (change type)

또한 경고 기준이 감지되면 Elastalert에서 소스/대상 IP 필드, 이벤트 및 타임스탬프 필드와 같은 정보가 있는 스크립트로 인수를 전달하는 인수를 사용하여 외부 Python 스크립트를 실행하고 NAC 시스템이 거기에서 처리합니다.

이제 Grafana Upcoming Alerting 모듈과 Elasticsearch를 데이터 소스로 보고 있는데, Grafan Alerting 모듈이 Elastalert와 동일하게 협력하고 결국 위에 주어진 정보로 대체할 수 있을지 궁금합니다.
조언 부탁드립니다

감사 해요

나는 grafana 팀이 이 일에서 열심히 일하고 있다는 것을 알고 있으며 이 스레드는 길지만 Kapacitor가 프론트엔드 경고 구성 애플리케이션의 개발을 크게 용이하게 하는 기능을 방금 병합했다는 점을 지적하고 싶습니다. influxdata/kapacitor#577

내가 이해하는 한 Grafana 측의 목표는 경고 백엔드를 플러그인 가능하게 만드는 것이지만(Grafana가 여러 TSDB 저장소를 지원하는 방식과 동일) Grafana의 경고 기능이 출시될 때 Kapacitor가 최고 수준의 지원을 받기를 희망하면서 언급하고 싶었습니다. InfluxDB + Grafana와 마찬가지로 아주 잘 맞는 것 같습니다.

@thom-nic 팁 주셔서 감사합니다. Kapacitor는 정확히 제가 찾고 있는 것입니다...

Riemann은 또한 위대하고 매우 강력합니다. telegraf -> riemann (경고) -> influxdb <- grafana

alerting_definitions 분기에서 진행 중입니다.

이제 UI 및 HTTP API를 통해 정의할 수 있는 간단한 경고 규칙 모델이 있습니다. HTTP API를 통해 규칙, 규칙 변경, 규칙 상태를 가져올 수 있습니다. 간단한 경고 규칙 예약 및 쿼리 실행 및 규칙 실행도 함께 시작됩니다.

현재 저에게 큰 물음표 한 가지는 현재 경고 모델이 너무 단순하고 막다른 골목입니다. 즉, 앞으로 경고 규칙 모델을 확장하려면 광범위한 변경이 필요합니다.

현재 규칙 모델:

description
query: #A  (referencing a query in the metrics tab)
aggregation: avg
timerange:  3600   (seconds from now to look back when fetching data)
frequency: 60  (how often to execute alert rule query and evaluation rule)
critLevel: 80
warnLevel: 50

이 스토리지 모델은 UI와 실제 데이터베이스 테이블에 모두 표시됩니다. 내 두려움은 이 간단한 규칙 모델이 시계열 데이터를 충분히 활용하지 못한다는 것입니다. 동적 임계값(임계값 자체가 쿼리의 결과인 경우)을 지정할 수 없습니다. 물론 이
나중에 추가할 수 있지만 매우 다른 규칙 모델과 실행 엔진이 필요합니다.

그래서 제 생각은 이 간단한 모델을 폐기하고 나중에 다른 시간 범위에 대해 여러 쿼리를 지원할 수 있는 더 복잡하고 동적인 새로운 모델을 만드는 것입니다.

단순 쿼리:

"alert": {
   "name": "CPU usage last 5min above 90%",
   "frequency": "1m",      
   "expr": "query(#A, 5m, now, avg)",
   "operator": ">",
   "critLevel": 90,
  },

// 이제 전달된 값을 기반으로 동적 임계값을 사용하는 경고로 이동합니다.

"alert": {
   "name": "CPU usage last 5m is 20% higher compared to last 24hours avg",
   "frequency": "1m",
   "expr": "query(#A, 5m, now, avg) => percentDiff() => query(#A, 1d, now, avg)",
   "operator": ">",
   "critLevel": 20,
  },

이제 여기에서 Graphite를 재창조하고 있으며 이와 같은 표현은 TSDB에서 처리해야 한다고 말함으로써 이에 대해 의문을 제기할 수 있습니다. 그러나 다른 시간 범위에 대한 쿼리로 계산을 지원하는 TSDB는 없습니다(timeShift는 동일한 시간 범위만 이동합니다). 동적 임계값의 일부 문제는 이를 시각화하는 방법입니다. 또한 경고 규칙을 패널에 실제로 시각화된 것과 더 분리되게 만들 수도 있습니다.

GAL(Grafana Alerting Language)이 어떻게 생겼는지 잘 모르겠습니다. 각 부분이 하나 이상의 시리즈(각 시리즈는 한 지점으로 집계됨)를 반환하는 쿼리가 될 수 있고 다른 쿼리와 비교할 수 있는 선택적 빼기 또는 백분율 함수가 될 수 있는 표현식 체인이어야 합니다. 전체 표현식은 경보 상태를 얻기 위해 연산자 및 위험/경고 수준과 함께 사용할 수 있는 값을 생성합니다.

아니면 표현식에 연산자와 수준이 포함되어야 합니까?

다른 옵션은 전체 프로그래밍 언어로 이동하여 다음을 수행합니다.

expr: "
let last5mAvg = query(#A, 5m, now, avg)
let last24hAvg = query(#A, 1d, now, avg)

return percentDiff(last5minAvg, last24Avg)
"

@토르켈로 :

1. 이것을 독립형 구성 요소로 설계하고 있습니까? 궁극적으로 Kapacitor for Influxdb **와 유사한 신호 프로세서를 구축하고 있습니다. 이 프로세서는 자체적으로 신호를 방출합니다(0 = "ok", 1 = "warn", 2 = "crit"). 이 신호를 Grafana가 아닌 다른 곳으로 보낼 수 있습니까? 예를 들어 A) Nagios로 또는 B) 다시 DB로 파이프합니까?
2. 유사하게, grafana에는 위의 신호 엔진을 사용하지 않고 오히려 많은 것이 이미 야생에 존재하는 Nagios 플러그인과 같은 타사 소스에서 0/1/2 신호를 수신하는 옵션이 있습니까?

** = 승인된 Kapicator는 시계열 스트림 처리를 사용하는 반면 귀하는 폴링 기반 엔진이지만 여전히 신호를 방출합니다.

입력을 요청해 주셔서 감사합니다.

내 의견은 grafana 경고를 단순하게 유지하는 것이며 단순성을 위한 최고의 척도는 시각화입니다. 기존 TS 그래프에서 경고를 선으로 시각화할 수 없다면 너무 복잡한 것입니다.

복잡성은 TS 그래프에 맡기십시오. 경고에 더 큰 요구 사항이 있는 경우 해당 요구 사항을 기반으로 다른 TS 데이터 세트를 구축하고 해당 데이터의 그래프에 경고를 배치합니다.

기본 원칙이 하나만 있는 경우 경고에 대한 간단한 시각화가 필요합니다.

다른 문제는 "얼마나 많은 경고를 구성해야 하는지"입니다. 이 주제는 이 스레드에서 논의되었으며, 여러 경고를 하나의 경고(경고, 오류, 높은 경고, 낮은 오류 등)에 넣자마자 유연성을 잃기 시작한다고 생각합니다. 경고와 오류는 다른 것입니다. 다른 수준이 있고 다른 사람들이 관심을 갖고 있으며 다른 알림 방법이 있습니다.

경고를 단순하게 유지하고 사람들이 그래프에 여러 경고를 표시할 수 있도록 합니다.

여기에서 #3677(시계열 쿼리 결과의 일반 변환)이 매우 유용할 것이라고 생각합니다. 이러한 TSDB 독립 기능을 사용하면 경고, 치명타 등에 대한 간단한 고정 값 임계값을 사용할 수 있는 복잡한 "경고 그래프"를 만들 수 있습니다.

그러면 간단한 경고 규칙 모델만 있으면 됩니다. 그런 다음 그래프 생성 및 조합에서 복잡성이 "숨겨져" 있습니다.

나는 그것을 간단하게 유지하기 위해 최선을 다하고 있습니다. 저는 개발자가 아니며, 좀 더 가벼운 터치 개발 작업이며, 관리할 관리자 팀에 Grafana/Graphite 플랫폼을 넘길 수 있기를 원합니다. 이것이 사실이라면 기존 것과 유사한 경보 빌더가 훨씬 쉽게 진행될 것입니다. 현재 그래프에 대한 쿼리와 동일한 방식으로 규칙을 구성할 수 있는 한 많은 새로운 지침이 도입되더라도 너무 소홀하지 않고 쉽게 이해할 수 있습니다.

완전히 새로운 언어는 과도하고 너무 복잡할 수 있습니다. mouse=good으로 규칙을 만듭니다.

완전히 새로운 언어를 구축하는 것 외에는 이것이 Grafana가 InfluxDB 쿼리를 작성하기 위해 프런트엔드를 제공하는 방식과 유사하게 Kapacitor, Reimann & Bosun과 같은 기존 경고 플랫폼에 대한 프런트엔드가 될 것이라고 가정했습니다. 예를 들어 무거운 작업은 타사 경고 시스템에서 수행하고 Grafana는 UI를 제공합니다. 아마도 그렇지 않습니까?

IIRC, Grafana는 "배터리는 포함되지만 제거 가능한" 방식을 원합니다. 즉, 경고 엔진이 포함된 독립 실행형으로 작동해야 하지만 기존 플랫폼에도 연결할 수 있어야 합니다.

이메일(SMTP 호스트 공급)과 WebAPI/Webhook과 같은 몇 가지 내장된 방법이 필요하다고 말하고 싶습니다. 그런 다음 나머지는 PagerDuty로의 통합과 같은 플러그인과 함께 제공될 수 있습니다.

@felixbarny 기존 플랫폼에

@GriffReborn 당신은 다른 차원에서 생각하고 있습니다. 내가 언급한 기존 경고 백엔드는 SMTP, PagerDuty 등과 같은 출력을 _이미_ 지원합니다.
https://docs.influxdata.com/kapacitor/v0.13//introduction/getting_started/#a -real-world-example
http://riemann.io/api/riemann.pagerduty.html

이러한 제품은 _이미_ 복잡한 동적 경고를 잘 수행합니다. 그들이 가지고 있지 않은 것은 경고를 구성 및 관리하고 어떤 경고가 활성화되어 있는지 시각적으로 식별하는 등을 위한 멋진 시각적 프론트엔드입니다. 내가 갖고 싶은 것은 기본적으로 구성을 예를 들어 (Grafana 지원) 경고로 푸시하는 프론트엔드 UI입니다. 실제로 모든 작업을 수행하는 선택 시스템.

@thom-nic 동의합니다. 주요 초점은 기존 알림 정보 피드("피드에 구애받지 않음")를 사용할 수 있는 알림 대시보드를 구축하는 것입니다. Grafana가 후원하는 경량 신호 처리 엔진(이상적으로는 독립 실행형)을 만드는 것은 부차적인 문제여야 합니다.

@johnnyshields 는 기존 알림 백엔드의 정보를 표시하는 새 패널을 만드는 것은 원하는 사람이라면 누구나 쉽게 할 수 있습니다. 우리가 하려는 것은 Grafana 사용자가 그래프/단일 통계 패널에서 정의한 메트릭 쿼리에 대한 경고 규칙을 쉽게 정의할 수 있도록 하는 것입니다. 그런 다음 해당 규칙을 예약 및 실행 및 평가하고, 경고 상태를 업데이트하고, 알림을 트리거하는 경고 엔진을 grafana 백엔드에 두십시오.

나는 또한 단순한 모델로 충분해야 하며 오랫동안 기다려온 기능을 가능한 빨리 도입할 것이라고 생각합니다. 모든 grafana는 메트릭을 위한 것이므로 기본 경고로 충분해야 합니다.

@torkelo 솔직히 말해서, 저는 @Dieterbe가 말한 것을 언급했습니다. http://de.slideshare.net/Dieterbe/alerting-in-grafana-grafanacon-2015#50

@felixbarny 그것도 우리가 할 계획입니다. Grafana에 정의된 규칙을 읽기 위해 다른 알림 백엔드용 API를 사용합니다. 그러나 Grafana에서 경고 규칙을 읽고 다른 규칙 실행 엔진으로 변환하는 브리지는 제공하지 않습니다.

이제 우리가 가진 한 가지 아이디어는 다음과 같은 간단한 규칙을 정의하는 것입니다.

그러나 동적 임계값을 갖고 다른 쿼리 또는 동일한 쿼리와 비교할 수 있지만 시간 범위 및 집계는 다릅니다.

또 다른 복잡한 "예측" 쿼리입니다. 쿼리가 추세선을 얻는 데 사용되는 경우 시간이 지남에 따라 이를 예측하고 이에 대해 경고합니다.

두 세계의 최고인 것 같습니다. 그 아이디어를 사랑하십시오! 'Evaluate Against' 기능은 Grafana의 일부입니까, 아니면 TSDB에만 해당합니까?

@felixbarny 그들은 Grafana 경고 규칙 모델의 일부이며 Grafana 경고 규칙 평가 엔진에 의해 처리됩니다.

단일 그래프에 여러 규칙을 첨부할 수 있습니까? 하나의 규칙에서 경고/위험 수준의 단순성을 좋아하며 일부 그래프에는 하나의 경고에 여러 수준이 필요하거나 하나의 그래프에 여러 경고가 필요한 높은 임계값과 낮은 임계값이 모두 있습니다.

복잡한 규칙 기능이 마음에 들지만 다른 그래프를 만들고 간단한 규칙으로 해당 그래프에 경고하면 이 모든 것을 달성할 수 있습니다. 경고 시스템에서 복잡성을 유지하는 이점은 규칙을 실행하는 상황의 이력이 TSDB에 보관된다는 것입니다.

이를 통해 경고를 그래프의 간단한 수평선으로 시각화하고 해당 규칙이 시간이 지남에 따라 어떻게 실행되었는지(또는 실행했는지) 확인할 수 있습니다.

평범한 사람에게는 단순하고 모든 사람에게는 충분히 복잡하며 시각적으로 사물을 이해하는 사람들에게는 접근 가능한 상태로 유지됩니다.

@lorenwest 예, 우리는 일을 단순하게 유지하고 패널당 하나의 경고 규칙만 허용합니다. 그러나 규칙은 여러 시리즈를 반환하는 쿼리를 사용할 수 있으며 기본적으로 규칙을 여러 개로 분할합니다(쿼리가 서버당 시리즈를 반환하는 경우 각 서버를 검사하는 단일 규칙을 가질 수 있음).

복잡한 규칙 기능이 마음에 들지만 다른 그래프를 만들고 간단한 규칙으로 해당 그래프에 경고하면 이 모든 것을 달성할 수 있습니다.

무슨 말인지 잘 모르겠습니다. 다른 그래프는 완전히 다른 쿼리와 비교하여 다른 시간 범위에서 자체와 비교하여 쿼리에 대해 경고하려는 시나리오를 전혀 해결하지 못합니다(다른 쿼리가 데이터베이스에서 동적 임계값을 가져오는 다른 데이터 소스일 수 있음). 이 시나리오는 TSDB에서 또는 규칙을 두 개의 개별 패널에서 두 개의 규칙으로 분할하여 해결할 수 없습니다.

그러나 주요 목표는 간단한 경우를 해결하고 쉽고 직관적으로 만드는 것이지만 최소한 나중에 TSDB 데이터를 다루고 있다는 사실과 서로 다른 쿼리가 서로 다른 데이터 소스를 타겟팅할 수 있음

@lorenwest 가

더 복잡한 경고 모델에서는 임계값이 경고를 발생시키는 위치에 대한 가시적인 지표가 더 이상 없습니다.

단순한 모델을 고수하면 데이터 소스가 기능을 제공한다면 복잡한 모니터링 요구 사항 중 많은 부분을 달성할 수 있습니다. "% 변경 비교"의 경우 오늘 날짜를 이전 날짜와 비교한 흑연 쿼리(다른 그래프)를 작성한 다음 이에 대한 간단한 임계값을 설정할 수 있습니다. 경고를 생성하는 것은 확실히 훨씬 더 복잡한 프로세스이지만 작동합니다.

@torkelo 같은 페이지에 있게 되어 기쁩니다. 이것은 원래 게시물의 설명과 일치합니다.

나는 Grafana에 연결하기 위해 완전히 새로운 경고 플랫폼을 만드는 것을 좋아하지 않습니다. Grafana 경고에서 내가 기대하는 것은 NewRelic을 대체할 수 있는 것이지만 Grafana가 제공하는 놀라운 기능입니다. 내 그래프 중 하나가 임계값에 도달했을 때 경고(이메일, API 등)를 트리거할 수 있다는 것은 금입니다. 인생을 바꾸는 물건.

단순한 임계값 경고도 훌륭한 간단한 솔루션이 될 것입니다.

이 한 가지 규칙을 따르면 황금이 됩니다.

패널에 오버레이하여 시각화할 수 없는 경고를 허용하지 마십시오.

시각화할 수 없다면 너무 복잡합니다. 이러한 복잡성을 구현하는 차트를 작성하고 해당 차트에 대해 경고하십시오. 이것은 경보 작성기(및 소비자)가 자신이 무엇을 하고 있는지 쉽게 볼 수 있도록 하면서 복잡성(좋은 점)을 구현하는 시각화를 구축하도록 강요합니다.

@woodsaj 나는 당신이 경고하는 것과 당신이 보는 것 사이의 연결을 장려하고 싶다는 데 동의합니다. 그것은 우리가 포기에 대해 논의한 적이 없습니다. 브레인스토밍하려는 것은 단일 쿼리 정적 임계값이 어디까지 가는지, v2 of Grafana Alerting 또는 v3에 충분합니까? 그리고 단일 쿼리 및 정적 임계값으로 가능한 경고 규칙 종류의 제한 사항에 대한 토론을 촉발합니다.

현재 TSDB는 어떤 종류의 중첩 쿼리를 수행할 수 있는지에 있어 매우 유연하지 않습니다(예를 들어 시리즈를 자체적으로 비교). Graphite는 중첩 쿼리를 지원하는 유일한 것입니다. 그러나 Graphite조차도 다른 시간 창을 대상으로 하는 두 쿼리를 비교할 수 없습니다(시간 이동은 동일한 창을 이동하지만 크기가 다른 시간 창은 이동하지 않음). 그러나 이것에 대해 더 많이 생각할수록 TSDB 쿼리가 충분히 강력하다면 이 대부분을 TSDB 쿼리에서 해결할 수 있다는 데 동의합니다.

이 토론을 제기하는 주된 이유는 규칙을 모델링하는 방법, 규칙을 구성하는 구성 요소, 포함하는 추상화(쿼리, 시간 창, 집계, 수준 등)를 브레인스토밍하는 것입니다. 미래의 추세를 예측하는 v2 이상의 기능이 풍부한 경고 쿼리에서 동적 임계값을 어떻게 지원할 수 있습니까? 모델 및 규칙 평가 엔진은 어떻게 변경되어야 합니까?

"경고가 패널에 매핑되어야 함"과 관련하여 - 유용한 옵션일 수 있지만 v1의 경우에도 잘못된 설계 제약이 될 수 있다고 생각합니다.

경고의 더 까다로운 측면 중 하나는 범위이며 시각화에 대해 이야기하기 시작하면 문제가 분명해집니다.

나는 범위를 경보가 범위로 ​​다루는 시스템의 표면적/깊이라고 생각합니다. 예를 들어 경고 범위가 다음과 같을 수 있습니다.

• 서비스(애플리케이션 메트릭)
• 서비스를 구성하는 전체 클러스터
• 클러스터의 개별 노드
• 클러스터의 호스트/프로세스
• 프로세스/애플리케이션의 하위 시스템(미들웨어 메트릭)
• 호스트의 하위 시스템(예: 디스크, CPU)(시스템 메트릭)

어떤 계층에 경고해야 하는지에 대한 "정확한" 단일 답변이 있다고 생각하지 않습니다. 때로는 팀, 서비스의 중요성, 일반 인프라(예: 클라우드 대 하드웨어, 클러스터 대 모놀리스) 등에 따라 달라집니다. 따라서 계층화된 범위가 주어지면 경고 계층 구조가 좋은 것처럼 보입니다. 그러나 이러한 계층 구조를 정의하는 것은 일반적으로 유지 관리할 수 있다고 생각하지 않습니다. 많은 작업, 변경 및 종종 실제 시스템에서 예쁜 나무를 만들지 않는 관계가 있습니다. Google의 SRE 도서 공격:

""
Google SRE는 복잡한 종속성 계층 구조에서 제한된 성공만 경험했습니다. 우리는 "데이터베이스가 느리다는 것을 알고 있으면 느린 데이터베이스에 대해 경고하고 그렇지 않으면 웹 사이트가 일반적으로 느리다는 경고"와 같은 규칙을 거의 사용하지 않습니다. 종속성 종속 규칙은 일반적으로 데이터 센터에서 사용자 트래픽을 빼내기 위한 시스템과 같이 시스템의 매우 안정적인 부분과 관련이 있습니다. 예를 들어 "데이터 센터가 소진된 경우 대기 시간에 대해 나에게 경고하지 않음"은 일반적인 데이터 센터 경고 규칙 중 하나입니다. Google 인프라에는 지속적인 리팩토링 속도가 일정하기 때문에 복잡한 종속성 계층 구조를 유지하는 팀은 거의 없습니다.
""

또한 범위와 관련된 경고 유형(예: 이메일 보내기 vs 기록/대시보드에 표시하여 누군가가 아침 라운드를 할 때 처리할 수 있도록 표시)

따라서 Grafana의 경우 내 경고가 다음에 매핑될 수 있습니다.

• 패널
• 패널 그룹
• 대시보드
• 대시보드 그룹(드릴다운이 있을 것으로 예상됨)

때로는 이러한 경고가 알림을 보내도록 하고 다른 경우에는 범위 중 하나에서 Grafana 어딘가에 있는 시각적 표시기(예: 임계값 초과 또는 주석 표시로 상태 변경)가 되기를 원할 것입니다. 회사마다 다르고 회사 내의 그룹/서비스마다 다를 것입니다.

@kylebrandt Grafana 의 경고에 대한 전체 아이디어는 이를 패널 및 시각화에 연결하는 것입니다. 다양한 범위(예: 서비스, 클러스터, 개별 호스트)의 메트릭을 시각화하고 모든 수준 또는 범위에서 경고할 수 있도록 하는 그래프 및 패널이 있는 곳.

경고를 패널에 연결하고 시각화할 수 있는 항목을 확인하지 않으면 다른 수준에서 경고 정의가 중지됩니다. 물론 경고별로 어떤 알림을 사용해야 하는지 지정합니다.

@torkelo 경고 결정은 항상 (true/false) bool로

따라서 $metric > $threshold 는 가장 기본적인 경고이며 메트릭이 임계값을 초과하면 true를 반환합니다. 이는 패널에 잘 맞습니다(메트릭을 시각화하고 패널 내에서 임계값을 시각화). 하지만, 경고 소음을 없애기 위해 범위와 조건은 대부분의 경우 그 이상으로 커지는 경향이 있습니다(보선 작업을 시작할 때 이러한 경우가 소수일 거라고 생각했습니다. 소음을 통제하십시오). 따라서 다음과 같이 말할 수 있습니다.

다음과 같은 경우 경고:

• CPU가 X분 동안 80% 이상입니다.
• 작업 A가 실행되고 있지 않고(CPU를 늘리는 것으로 알고 있고 신경 쓰지 않음) 작업 A가 1시간 이상 실행되고 있지 않습니다.
• Dieter는 지난 24시간 동안 3컵 이상의 스타벅스를 마셨습니다.

따라서 여러 조건이 있을 때 경고만 (True/False) 시각화하는 것은 그다지 유용하지 않습니다. 우리는 각 조건을 시각화해야 합니다(그리고 지원 정보를 위해 더 많은 정보가 필요할 수도 있음).

이러한 모든 조건을 새 메트릭으로 만드는 것은 사실/거짓일 뿐이고 실제로 확인해야 하는 모든 기본 정보이기 때문에 현재 시각화에 실제로 도움이 되지 않습니다. 따라서 metric+threshold를 시각화하는 대신 다른 척도에 있을 수 있는 metric(s) + threshold(s)를 시각화하는 것이 있습니다.

따라서 이 경우 경고는 단일 패널에 매핑 _할 수_ 있지만 시각화 및 경고에 따라 실제로 원하는 것이 아닌 경우가 많습니다. 경고를 구성하는 각 부울 항목에 대한 패널을 사용하여 어느 항목이 트립되었는지 확인하고 싶습니다. 그러나 경고 피로를 피하기 위해 모든 조건의 조합에 대해 하나의 알림만 원합니다.

간단한 부울 논리를 사용하는 일종의 경고 조이너가 이것을 쉽게 만들 수 있을 것 같습니다.

alert1:
  select: CPU is above 80% for X minutes
  output: null
alert2:
  select: Job A is not running
  output: null
alert3:
  select: Job A has being running for more than an hour
  output: send alert
alert4:
  select: Dieter has had more than 3 cups of starbucks in the last 24 hours
  output: null

(alert joiner does simple true/false logic and perhaps can graph it.)
alert5:
  database: alerts
  select: alert1 & alert2 &!alert4
  output: send alert

@torkelo Github에서 alerting_definitions 분기를 가져
또한 "서버 관리"의 "서버 설정" 내에서 "경고: 활성화됨=거짓"을 찾았습니다. 알림 기능에 영향을 줍니까? 사용해야 하는 빌드 또는 런타임 플래그가 있습니까?
조언 부탁드립니다.

최신 코드(ebada26b85d8410142c2942ef7ba78b17e88313c)로 시도하고 경고를 활성화하고 UI를 얻었습니다.

하지만 수많은 오류가 발생했습니다

EROR[06-17|14:38:23] Failed to extract alerts from dashboard  logger=alerting.extractor error="missing query.query"
EROR[06-17|14:38:23] Failed to save alerts                    logger=context userId=1 orgId=1 uname=admin error="Failed to extract alerts from dashboard"

Proyy 및 직접 모드에서 InfluxDB 데이터 소스로 시도했습니다.

예상되는 일입니까?

예, 아직 테스트할 준비가 되지 않았습니다.

알겠습니다.

수시로 업데이트를 추적하겠습니다.
이 분기가 마스터에 병합되어 사용할 준비가 완료될 때까지 기다리는 것이 더 나을 수 있습니까?

예, 아마도 7월 중순쯤 마스터하기 위해 병합하기를 희망합니다.

이에 대한 진행 상황 업데이트가 있습니까?
아직도 7월 중순에 가나요?
이 기능을 최대한 빨리 프로덕션에 도입하면 정말 큰 도움이 될 것입니다!

이메일 알림과 같은 라이트 버전이라도 너무 좋을 것입니다!
진행 상황에 대한 업데이트가 있으면 좋을 것입니다(사용자 지정 알림 시스템을 구현하거나 Grafana에 의존하는 것 중에서 선택해야 하며 두 번째 옵션을 확실히 선호합니다!).
감사합니다

겨울이 왔어요, 그래서 경고합니다 :)

2016년 7월 12일 화요일 오전 1시 41분에 c-val [email protected]에서 다음과 같이 썼습니다.

이메일 알림과 같은 라이트 버전이라도 너무 좋을 것입니다!
진행 상황에 대한 업데이트가 좋을 것입니다(다음 중에서 선택해야 합니다.
사용자 지정 경고 시스템을 구현하거나 Grafana에 의존하고 있습니다.
두 번째 옵션을 선호하십시오!).
감사합니다

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/grafana/grafana/issues/2209#issuecomment -231975390,
또는 스레드 음소거
https://github.com/notifications/unsubscribe/AAY0-eQ6jCI8a-k_U05xbcfFcYuGy4YVks5qU1NDgaJpZM4FJUTl
.

디팍

나는 이것을 "비즈니스 요구 사항"으로 간주하고 "엔터프라이즈 아키텍처" 수준에서 평가하는 것이 좋습니다. 엔터프라이즈 소프트웨어 아키텍처에 사용되는 _일부_ 의 관행과 패턴을 적용하면 민첩한 모델링을 통해 아이디어를 전달할 수 있으며, 이는 이해 관계자와 개발 팀 모두에게 더 높은 품질의 이해를 촉진합니다.

기술과 아키텍처의 비밀 소스에 대해 이야기하기 전에 최소한 다음 사항에 동의해야 합니다.

1. 우리는 "비즈니스 프로세스 관리(BPM)"의 관점에서 우리의 기능을 생각합니다. 그리고
2. "BPML(Business Process Modeling Language)"을 사용하므로 UML과 동일한 위치에서 요구 사항 및 구현 모델링을 시작할 수 있습니다.
3. 우리는 엔터프라이즈 수준의 원칙으로 아키텍처를 정의합니다.

이제 재미있는 부분! 글로벌 규모의 모니터링에 대한 광범위한 경험이 있으므로 다음 사항을 고려하는 것이 좋습니다.

• grafana는 그대로 두십시오. 프레젠테이션 레이어입니다 ! 경고 생성 규칙을 정의하고 모델링하기 위한 워크플로를 추가하려는 경우 괜찮지만 그대로 두십시오. 결국 패널과 플러그인이 제대로 구현된 이유는 무엇입니까?
• 데이터를 원래 있던 위치에 두십시오. 집에 전화를 거는 메트릭은 일류 시민 으로
• 가용성 + 확장성을 설정하려면 이를 위해 특별히 설계된 올바른 프레임워크인 "SOA"(서비스 지향 아키텍처)를 충족해야 합니다. 매우 높은 수준에서 메시지 대기열 프로토콜을 사용하여 "AMQP" 프로토콜을 통해 이벤트 및 메시지를 전송 및 수신할 수 있습니다. 지금은 REST 및 HTTP를 잊어버리십시오. RabbitMQ 또는 ZeroMQ 와 같은 메시지 대기열 서버를 사용하여 데이터 게시자/발신자와 데이터를 처리하는 작업자/수신자가 모두 사용할 수 있는 분산된 내결함성, 고가용성 통신 파이프라인이 있습니다. "엔터프라이즈 서비스 버스"입니다. (ZeroMQ를 설명하는 이 슬라이드 데크를 확인하십시오).
• 이질적이고 연결되지 않은 복합 데이터 모델을 위해 특별히 생성된 쿼리 언어를 사용합니다. "그래프 데이터베이스" 및 " SparQL " 쿼리 인터페이스를 사용하여:

SPARQL을 사용하면 사용자가 "키-값" 데이터 또는 보다 구체적으로 W3C의 RDF 사양을 따르는 데이터라고 하는 것에 대해 쿼리를 작성할 수 있습니다. 따라서 전체 데이터베이스는 "주제-술어-객체" 트리플 세트입니다. 이것은 MongoDB와 같은 일부 NoSQL 데이터베이스에서 "문서-키-값"이라는 용어를 사용하는 것과 유사합니다.
[..]
따라서 SPARQL은 별도의 스키마 정의가 필요하지 않고 스키마가 본질적으로 데이터의 일부인 데이터에 대해 JOIN, SORT, AGGREGATE와 같은 분석 쿼리 작업의 전체 세트를 제공합니다. 그러나 스키마 정보(온톨로지)는 종종 외부적으로 제공되어 다른 데이터 세트가 명확한 방식으로 결합될 수 있도록 합니다. 또한 SPARQL은 그래프와 그림으로 생각할 수 있는 데이터에 대한 특정 그래프 순회 구문을 제공합니다.
..
https://en.wikipedia.org/wiki/SPARQL

Nagios가 한 번도 하지 않았던 Grafana가 우리에게 준 것은 확장성 부족이라는 단일 실패 지점으로 요약됩니다. Grafana는 당신이 말했듯이 "빠르다"고 하지만 메타데이터 레이어가 아니라 시계열 데이터 만 저장하고 처리한다는 사실을 고려 하지 않고 있습니다 ! SparQL의 의미 체계와 Elasticache + 그래프 데이터베이스 엔진의 힘이 필요합니다.

복잡하게 들릴 수도 있습니다. 이 두 페이지보다 훨씬 더 복잡해 질 수 있지만 수년간의 무차별 대입, 시행착오를 방지하고 노이즈를 제거했습니다(예: 엔터프라이즈 아키텍처에는 30개의 디자인 패턴이 있고, uml, etc.., 우리는 이것을 노크할 수 있도록 3에 대해 이야기해야 합니다 -- 지금은

이렇게 하면 기어가 돌아가야 합니다. 잠을 좀 자야 하고( 철저하게) 2부에서 작업 yomateo로 자유롭게 핑을

그 동안 일부 취급:

• SOA를 사용하여 만든 예제 참조 아키텍처입니다 .
• Microsoft Azure Service Fabric: 상시 가동되고 확장 가능한 분산 애플리케이션을 구축하고 운영합니다.

@talbaror 이상적으로는 PIX 방화벽과 같은 에이전트를 사용하여 NAC의 로그 메시지를 캡처하고 rsyslogd 또는 이벤트 처리 서버가 사용하는 프로토콜을 통해 단순히 발송/재생하도록 합니다.

이벤트 처리 서비스 설정이 없는 경우 Snort-Network Intrusion Detector 의 규칙 처리를 사용할 수 있습니다. 도움이 필요하면 저에게 핑(Ping)을 보내주세요.. 저는 SaaS(security-as-a-service) 회사에서 4년을 보냈습니다. ;)

밴시 와 같은 이상 탐지 기능을 통합할 수 있습니까?
시각적 마커 및 경고.

@torkelo 배송 일정에 대한 시장 출시 일정을 알려주시겠습니까?

@johnnyshields 저는 지금 매일 이 작업을 하고 있습니다. 그것은 까다로운 일이며 경고 시스템이 미래에 진화하고 더 풍부해질 수 있도록 기본을 올바르게 하고자 합니다. 제가 작업하고 있는 현재 모델은 정말 좋아 보입니다. 다음 주에 새로운 조건 기반 경고 규칙 모델에 대한 업데이트를 게시할 예정입니다.

일이 순조롭게 진행되면 마스터에 병합하고 2주 이내에 사용할 수 있기를 바랍니다(기능 토글 뒤). 9월에 3.2 릴리스 또는 10월 말에 더 큰 4.0 릴리스인 Grafana의 다음 버전에 대한 날짜는 아직 정해지지 않았습니다.

@torkelo 가능한 한 빨리 알림을 받기를 바랍니다. 그것을 기다리고 있습니다.
쿠버네티스에 grafana 사용하기.

이미 statsd/graphite/grafana가 있고 Grafana 경고 시스템이 첫 번째 경고를 수행할 준비가 되기를 기다리는 다른 사람들을 위해 Seyren: https://github.com /스코발/세이렌

PagerDuty와 쉽게 통합되며 경고 및 오류 임계값을 지정하는 경고를 위해 grafana 대시보드에 이미 있는 그래프 대상을 복사할 수 있습니다.

팀이 알림 기능에 대해 큰 진전을 이룩한 것 같습니다. 저는 "한 가지만 잘하면 된다"는 철학을 믿습니다. 전체 경고 로직을 Grafana에 넣는 것이 최선의 아이디어인지 확신할 수 없습니다. 어쨌든, 나는 grafana 이벤트를 flapjack에 게시하기 위해 작은 노드 js 데몬 "flapjack-grafana-receiver'를 작성했습니다. 아마도 그것을 오픈 소스로 만들 것입니다. 관심 있는 사람?

https://github.com/Charles546/flapjack-grafana-receiver

진행 업데이트!

4월 이후로 최소한 한 사람이 경고에 대해 풀타임으로 일하고 있으며, 많은 재작성으로 인해 진행이 원하는 만큼 빠르지 않았습니다. 초기 버전에 대한 기본 경고 기능을 목표로 하고 있지만 기본 경고 규칙 모델을 올바르게 구축하는 것이 중요하다고 생각하므로 향후 릴리스에서 주요 점검 없이 경고 규칙 정의 및 경고 규칙 평가 엔진을 확장할 수 있습니다.

매우 간단한 경고로 시작하려는 목표는 우리를 옳지 않다고 생각하고 큰 재작성을 필요로 하는 막다른 길을 안내해 주었습니다. 그러나 이제 우리는 다시 정상 궤도로 돌아갔고 훨씬 더 만족스러운 조건 기반 규칙 모델에서 좋은 진전을 이루었습니다.

규칙 정의

새 경고 규칙 모델은 하나 이상의 조건으로 구성됩니다. 조건은 다양한 유형이 될 수 있습니다. 지금은 쿼리 유형만 있습니다. 그러나 나중에 Time of day 또는 Day of week 또는 더 흥미롭게도 Other alert 와 같은 조건을 추가할 수 있습니다(따라서 다른 경고 규칙의 상태를 조건으로 포함할 수 있음).

쿼리 조건은 쿼리와 시간 범위로 구성되며 쿼리가 반환된 각 시리즈에 대해 반환된 모든 데이터 포인트를 가져와 임계값 비교에 사용할 단일 값으로 줄이는 감속기입니다. 리듀서는 미래에 데이터에 대해 선형 회귀를 수행하고 미래 값을 예측하는 "예측"이 될 수도 있습니다.

쿼리 조건의 평가 부분은 보다 크거나 작거나 사이일 수 있습니다. 그래프에서 핸들을 끌어 임계값을 설정할 수 있습니다.

조건 기반 모델은 전체 엔진 점검 없이 향후 경고 규칙을 더욱 강력하게 만들 수 있는 흥미로운 가능성을 많이 제공하며 쿼리 조건에는 확장을 허용하는 이러한 플러그형 구성 요소가 있습니다(params가 있는 감속기 및 params가 있는 평가자).

알림

이번 주에 알림 작업을 진행했으며 모든 것이 함께 이루어지기 시작했습니다!

이메일, 웹훅 및 여유 알림 유형이 있습니다. 느슨한 알림은 꽤 좋아 보입니다 :)

도움을 원하십니까?

이미 테스트하고 피드백을 제공할 수 있으며 코드는 경고 분기에 있으며 구성 파일에서도 활성화해야 합니다.

[alerting]
enabled = true

마스터로 병합

우리는 이것을 마스터하기 위해 병합하고 거기에서 작업을 계속하는 것에 매우 가깝습니다. 나는 여름 방학 전에 이것을 하기를 바랐지만(방금 1주일) 마스터에 병합하기 전에 수행하고 싶은 약간의 SQL 스키마 변경 사항이 여전히 있습니다. 마스터로 병합은 8월 19일까지 이루어집니다. 약속합니다 :) 그 후에는 최신 4.0 야간 빌드에 알림이 제공되므로 버그 및 피드백을 테스트하고 보고하기가 쉬울 것입니다.

무엇이 남아 있습니까?

베타 릴리스에 필요한 여러 기능이 누락되었습니다.

• 더 많은 감속기 및 감속기 변경 기능(현재 평균만 해당)
• 이메일 알림이 쓰레기처럼 보입니다.
• 웹훅에 대한 잠금 스키마
• 경고 목록 페이지 디자인
• 알림 기록 보기
• 그래프의 주석으로 경고 기록 보기
• 경보 스케줄러 및 엔진 안정성
• 부하 분산을 위한 경보 스케줄러 개선(경보가 동시에 실행되지 않도록)
• 경보 스케줄러 클러스터링

이 기능이 너무 오래 걸려서 정말 죄송합니다.

@torkelo 는 베타에서 일정 기간 동안 기계를 유지 관리 모드로 전환할 수 있는 기능을 가지고 있습니다.

@torkelo 업데이트에 감사드립니다. 내가 볼 수 있는 바로는, 이것은 Grafana 내에서 경고를 가하기 위한 것입니다. https://github.com/grafana/grafana/issues/2209#issuecomment -149351263 에 있는 모듈식 과정을 계속 따르고 있습니까?

또한 이 일을 하는 히든 엘프에게 감사드립니다. @Dieterbe가 의심되지만 모르겠습니다.

@RichiH 우리는 그것이 어떻게 될지 확신할 수 없습니다. 우리는 그 의견에서와 같은 시스템을 수행하는 방법을 알아 내려고 노력했지만 그것이 어떻게 작동할지 확신하지 못합니다. 우리는 이제 시간이 지남에 따라 개선될 수 있는 강력한 즉시 사용 가능한 경고 환경에 초점을 맞추고 있습니다. 기존 경고 처리기가 있는 사용자는 잠재적으로 Grafana에서 경고 실행기를 비활성화하고 Grafana가 평가해야 하는 경고를 다른 시스템으로 보내도록 할 수 있습니다. 하지만 해당 통합을 구현하려면 타사 시스템에서 많은 작업이 필요합니다.

@torkelo 제 생각도 같은 맥락이라 여쭤보기로 했습니다.

개인적으로 말하자면, 나는 Prometheus의 경고에 관심이 있지만 Grafana와의 멋진 시각적 통합에 감사드립니다. Prometheus에 의해 저장되고 실행되는 한 규칙을 정의하는 위치는 그다지 신경 쓰지 않습니다.

@bergquist 당신이

안녕하세요 @torkelo -

방금 분기를 가져왔고 ElasticSearch에 대한 경보를 테스트할 때 오류가 발생합니다.

firing false
timeMs 0.225ms
error tsdb.HandleRequest() error Could not find executor for data source type elasticsearch

...ElasticSearch가 아직 지원되지 않는다는 뜻인가요? :cry:

ps 프로세스 출력에서 ​​다음을 얻습니다.

EROR[08-04|09:15:00] Alert Rule Result Error                  logger=alerting.engine ruleId=1 error="tsdb.HandleRequest() error Could not find executor for data source type elasticsearch" retry=nil LOG15_ERROR="Normalized odd number of arguments by adding nil"

@Workshop2 지금까지는 알림을 위해 흑연만 지원하지만 결국에는 Elasticsearch를 지원할 예정입니다. :) 이에 대한 더 나은 오류 메시지를 추가하겠습니다.

쿼리가 데이터를 반환하지 않으면 경고 시스템은 어떻게 작동합니까? 기본적으로 경고를 트리거합니까?
또한 단순한 count 리듀서는 쿼리에 의해 반환된 데이터 포인트의 수를 단순히 반환하는 멋진 것입니다.

@bergquist 사용된 데이터 소스와 관련하여 경고가 투명할 것이라고 생각했습니다. 그라파이트 데이터 소스가 아닌 다른 경고 기능을 미리보기/테스트할 수 있기까지 얼마나 걸립니까? (누구도 좋아하지 않는 '얼마나 ...' 질문을 깨닫습니다. 죄송합니다)

@RichiH 한 가지 옵션은 bosun과 같은 grafana 앱을 만드는 것입니다. https://grafana.net/plugins/bosun-app 그러나 간단한 방법으로 쿼리/대시보드 재사용을 가능하게 하지는 않습니다. promcon에서 그것에 대해 더 이야기합시다. 당신을 만나기를 고대하고 있습니다! :)

처음에는 influxdb도 지원하지 않습니까?

나는 흑연에 대한 특정 경계를 알지 못했습니다. (우리는 또한 유입을 사용하고 있습니다.
엘라스틱서치 ;)

2016년 8월 8일 월요일 오후 2시 18분에 elvarb [email protected]에서 다음과 같이 썼습니다.

처음에는 influxdb도 지원하지 않습니까?

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/grafana/grafana/issues/2209#issuecomment -238218714,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AEKf_4yp6-34PaOE2z4ynSriRxQpjKcvks5qdx59gaJpZM4FJUTl
.

엔리코 컨

수석 시스템 엔지니어

글리스파 GmbH
Sonnenburger Straße 73
10437 베를린, 독일

전화: +49 30 5557130-17
팩스: +49 30 5557130-50
스카이프: 플라이에사엔리코. [email protected]

---

시츠 베를린, AG Charlottenburg HRB 114678B

처음에는 출시 전에 Prometheus를 추가할 것입니다. InfluxDB 또는 Elasticsearch도 마찬가지일 수 있습니다. 알림 예약 및 실행이 백엔드에서 진행 중이고 요청 및 응답 코드가 처음부터(Go에서) 작성되었기 때문에 프론트엔드 데이터 소스 플러그인 코드(js로 작성)를 재사용할 수 없습니다.

우리는 influx를 사용하고 있으며 grafana 통합을 포기하고 경고 생성 및 관리를 위해 간단한 웹 프런트 엔드와 함께 Kapacitor를 사용할 수 있다고 생각합니다.

+1 경고 + InfluxDB.

2016년 8월 8일 월요일 오전 6:01, Thom Nichols [email protected]
썼다:

우리는 influx를 사용하고 있습니다. grafana 통합을 포기하고 사용할 수 있다고 생각합니다.
경고 생성 및 관리를 위한 간단한 웹 프런트 엔드가 있는 Kapacitor.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/grafana/grafana/issues/2209#issuecomment -238228133,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAY0-VP--Ysoxu5IV0hslQrP8cvF5ePSks5qdyi_gaJpZM4FJUTl
.

디팍

데이터 소스 플러그인 구축에 투입한 작업이 클라이언트에서만 유용하다는 것은 유감스러운 일입니다.

다양한 데이터 소스에 대한 경고를 지원하는 즉각적이고 장기적인 작업, go 플러그인 아키텍처 구축 등을 고려할 때 NodeJS에서 경고 서버를 구축하는 것은 거의 동일한 작업량(적어도 적은)이 아니므로 기존 데이터 소스 플러그인?

go 대 nodejs에 대한 의견은 제쳐두고, 이것은 다른 데이터 소스에 대한 경고에 대한 코드 중복을 크게 줄일 수 있습니다.

그리고 노드가 마음에 들지 않는다면 JS 로드 및 실행을 위한 콜아웃 메커니즘이 있을 것입니다.

ElasticSearch에 대한 +1 경고

안녕하세요, 우리는 경고 시스템을 기다리고 있었습니다... OpenTSDB! 우리는 할 수 있습니까?
곧 OpenTSDB용으로 제공되기를 원하십니까? (아마 언제?)

팀에 감사드립니다!

2016-08-08 17:28 GMT+02:00 슬라바 비슈냐코프 알림 @github.com :

ElasticSearch에 대한 +1 경고

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/grafana/grafana/issues/2209#issuecomment -238273405,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ARsY50v7meI_EuzSAJGtvDMDareYKSDhks5qd0sggaJpZM4FJUTl
.

ElasticSearch에 대한 +1 경고
경고 시 스크립트를 실행할 가능성이 있습니까?

도커 이미지에 경고 분기가 아직 있습니까?

1. 경고 쿼리는 쿼리 "A"에 대해서만 작동합니까? 이거 하드코딩인가요?
2. 언제 완전히 작동하는 경고 버전을 기대할 수 있습니까? (19일은 아직 목표)
3. Elasticsearch가 언제 경고와 함께 작동할 것으로 예상할 수 있습니까?

편집하다:

1. 그래프당 알람 규칙을 두 개 이상 추가할 수 있습니까?
2. HTTP 메시지에 경보에 대한 정보를 추가할 수 있습니까? (대시보드/그래프/observed_query/alarm_config/alarm_query/threshold/warn_or_crit/value/observed_timeframe/time_of_occurence)

@DEvil0000

1) 측정항목 탭에 있는 쿼리로 변경할 수 있습니다.
2) 완전히 작동하는 것은 당신이 의미하는 바에 달려 있습니다. 이번 주에 마스터하기 위해 병합할 계획입니다. 그런 다음 사람들은 야간 빌드 테스트를 시작하고 피드백을 제공할 수 있습니다. 2-3주 내 알파 릴리스, 베타 및 안정적인 릴리스는 피드백과 안정화 속도에 따라 달라집니다.
3) Elasticsearch는 까다롭고 응답을 쿼리하고 시계열로 구문 분석하는 데 많은 코드가 필요하므로 Prometheus 및 InfluxDB에 대한 지원이 추가된 후에 나올 것입니다.

@torkelo
나는 Elasticsearch, grafana 및 go lang을 처음 사용합니다. 그리고 이미 고객을 검색했지만 본 적이 있습니까?
https://github.com/olivere/elastic
https://github.com/mattbaird/elastigo
이러한 라이브러리는 노력을 줄일 수 있습니다.

또한 이 일을 하는 히든 엘프에게 감사드립니다. @Dieterbe가 의심되지만 모르겠습니다.

경고는 이제 주로 @torkelo 및 @bergquist (및 @mattttt )입니다. 저는 다가오는 흑연 백엔드 https://github.com/raintank/metrictank에 초점을 맞췄습니다.

이 기능이 발전하는 것을 보게 되어 매우 기쁩니다. 다른 경고 솔루션(Bosun)이 여기에서 정기적으로 사용하기에 충분히 사용자 친화적이지 않기 때문에 OpenTSDB에 대한 지원을 원합니다.

다음 공식 버전에서 알람을 보고 열심히 코딩한 프로그래머들에게 경의를 표하기를 바랍니다.

다음 공식 버전에서 알람을 보고 열심히 코딩한 프로그래머들에게 경의를 표하기를 바랍니다.

@superbool 죄송합니다 이것을 읽을 수 없으며 Google 번역이별로 도움이되지 않았습니다

Merge to master는 8월 19일까지 진행됩니다. 약속합니다 :)

@torkelo ㅎㅎ 다음에 내기할 땐 새로운 데이트가 있나요?

OpenTSDB에 대한 알림이 예약될 것으로 예상할 수 있습니까?
(겸허한) 개발을 격려하기 위한 창립.

2016-08-22 10:05 GMT+02:00 A. Binzxxxxxx 알림 @github.com :

다음 공식 버전에서 알람을 보고 열심히 코딩한 프로그래머들에게 경의를 표하기를 바랍니다.

@superbool https://github.com/superbool 죄송합니다 이 글을 읽을 수 없고
구글 번역은 별로 도움이 되지 않았다

Merge to master는 8월 19일까지 진행됩니다. 약속합니다 :)

@torkelo https://github.com/torkelo 헤헤 다음에 내기할 땐?
새로운 데이트?

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/grafana/grafana/issues/2209#issuecomment -241340597,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ARsY59771TaHEIaqCHbf-4TKWc4OdjVXks5qiVhdgaJpZM4FJUTl
.

@DEvil0000 경고 기능이 다음 안정적인 Grafana 버전에서 게시될 수 있기를 바라며 이 도구를 개발한 모든 사람들에게 경의를 표하고 싶습니다.
죄송합니다, 제 영어가 좋지 않습니다. 제 말을 이해할 수 있기를 바랍니다.

@DEvil0000 계획은 지난 금요일에 병합하는 것이었지만 계획되지 않은 몇 가지 이벤트( https://twitter.com/torkelo/status/766514688997732352 )로 인해 조금 연기해야 ​​했습니다 :) 우리는 아직 할 일이 약간 있습니다.

@torkelo 축하합니다!
@bergquist @torkelo 10월 이전에 Elastic으로 경고해야 합니다(알파는 저에게 적합합니다). 구현을 도와드릴까요? 시작점을 가지려면 몇 가지 정보만 제공하면 됩니다. ;)

경고 분기가 이제 마스터에 병합되었습니다. :들어간 손:

이 문제에서 받은 모든 피드백에 감사드립니다. 여러분 감사합니다 !
향후 토론 및 피드백을 위해 해당 경고 문제에 게시하거나 새

그럼 다음은?

• 알파 릴리스(문서 및 블로그 게시물)
• 커뮤니티에서 피드백을 수집합니다.
• 경고 에 대한 나머지
• 경고와 함께 Grafana 4.0을 출시하십시오.

그것을 시도?

• 구성 에서 경고를 활성화해야 합니다.
• 이제 사이드 메뉴에서 알림을 찾을 수 있습니다.
• 그래프 패널로 이동하여 경고 탭을 선택하여 경고를 추가할 수 있습니다.
• _알림 테스트_ 버튼을 사용하여 알림을 확인하세요.
• 알림을 저장하려면 대시보드를 저장하기만 하면 됩니다.
• /alerting/notifications에 알림을 설정하여 경고 발생에 대한 알림을 받습니다.
• 경고 탭에서 경고에 알리미를 추가합니다.

현재 제한 사항

• 지금까지는 흑연만 지원합니다.
• 이 릴리스의 경우 그래프 패널만 경고를 지원합니다.

예시 대시보드

examples 폴더에서 예제 대시보드를 찾을 수 있습니다.
예제 대시보드는 가짜 흑연 데이터 작성기의 데이터를 기반으로 합니다. 도커 작성 파일에서 흑연과 가짜 데이터 작성기를 시작할 수 있습니다.

cd docker/
./create_docker_compose.sh graphite
docker-compose up

이것은 대략적인 지침으로만 간주되어야 하며 다음 주에 경고에 대한 더 많은 문서를 추가할 것입니다.

즐거운 알림! :칵테일::타다:

@bergquist 축하합니다.

이 기능의 미래에 대해 따를 수 있는 문제가 있습니까?

@워크샵2 https://github.com/grafana/grafana/issues/5858

경고 조건에는 "AND"만 있고 한 패널에 "is above" 또는 "is below"를 추가하거나 이를 지원하는 다른 방법이 있습니까?

"범위 밖에 있음"/"범위 내에 있음" 옵션이 있다고 생각합니다. 하지만 "또는"도 보고 싶습니다.

모두들 안녕! 이 유용한 기능에 기여해 주셔서 대단히 감사합니다.

그것은 나에게 정말 흥미롭지만 많은 경우에 경고 조건에서 "OR"이 필요합니다. 왜냐하면 gragh에서 하나 이상의 경고를 생성할 가능성이 없기 때문입니다.

그 "OR"이 없으면 이런 종류의 그래프에 대한 경고를 생성할 수 없다고 생각합니다.

어떤 아이디어라도? "OR" 옵션을 추가할 계획입니까?

BR

@jmgonzalezp 예, OR도 지원하기를 희망합니다(AND와 OR의 혼합에 대해서는 아직 확실하지 않음)

(카테고리 및 심각도/상태)에 대한 피드백이 필요함을 알리는 2개의 디자인 결정이 남아 있습니다.

다음은 우리의 현재 생각에 대한 문제이며 귀하의 피드백에 정말 감사드립니다.
https://github.com/grafana/grafana/issues/6007

안녕하세요 여러분! grafana의 이러한 훌륭한 기능에 감사드립니다!

이 경고 시스템에 대해 질문이 있습니다. 현재 AWS에서 Auto Scaling 그룹을 사용하여 grafana를 배포하고 있습니다. 여러 머신에서 grafana를 실행하면 문제가 될까요? 내가 언급하는 문제는 여러 grafana 기계에서 여러 개의 동일한 경고가 있습니까? 아니면 grafana가 이미 처리했습니까?

@torkelo @akurniawan 과 같은 질문이 있습니다. 로드 밸런서 1개, 로드 밸런서 뒤에 있는 Grafana 인스턴스 3개, 3개 인스턴스가 모두 공유하는 MySQL DB 1개와 같은 설정을 고려해 보겠습니다. 이러한 유형의 설정에서 Grafana 서버는 경고를 어떻게 처리합니까? 그런 다음 하나의 인스턴스에서만 경고를 활성화해야 합니까, 아니면 Grafana가 경고를 추적하여 여러 노드가 동일한 경고를 확인하고 보내지 않도록 해야 합니까?

@utkarshcmu @akurniawan grafana 내 경고는 아직 HA를 지원하지 않습니다. 우리의 계획은 향후 서버 간 파티션 경고에 대한 지원을 추가하는 것입니다.

@bergquist 답변 감사합니다. :)

@bergquist 이에 대한 InfluxDB 지원이 언제 추가될 예정입니까?

@thisisjaid 이 https://github.com/grafana/grafana/milestone/40으로 판단하면 10일에 여기에 있어야 합니다.

@Dieterbe OpenTSDB에 대한 경고 지원에 대한 ETA가 있습니까?

@sofixa 감사합니다. RTFMing이 아닌 경우 로드맵을 직접 살펴봤어야 했습니다. 그럼에도 불구하고 감사합니다.

@Dieterbe OpenTSDB에 대한 경고 지원에 대한 ETA가 있습니까?

더 이상 경고 작업을 하지 않습니다. @torkelo 또는 @bergquist 가 대답할 수 있습니다.

@torkelo @bergquist

OpenTSDB에 대한 경고 지원을 위한 모든 ETA

@LoaderMick @naveen-tirupattur OpenTSDB 경고가 Grafana에 추가되었으며 다음 릴리스의 일부가 되어야 합니다. 또한 OpenTSDB에 대한 경고는 야간 빌드에서 작동합니다.

influxDB 및 prometheus에 대한 경고 지원을 위한 ETA도 있습니까?

두 데이터 소스에 대한 @nnsaln 경고는 이미 마스터 분기에 있습니다.

(Grafana v4.0.0-pre1 (커밋: 578507a)) OpenTSDB에서 작동하는 경고를 얻을 수 없는 것 같습니다. 이메일 시스템(작동)을 테스트했지만 임계값이 매우 낮은 경우에도 경고가 발생하지 않습니다. 어쨌든 쿼리를 수동으로 실행하고 가져오는 데이터를 볼 수 있습니까?

Grafana v4.0.0-pre1(커밋: 9b28bf2)
오류 tsdb.HandleRequest() 오류 Influxdb가 상태 코드를 반환했습니다. 잘못된 상태 코드: 400 잘못된 요청

@torkelo
'웹훅 경고 알림'이 경고 메트릭, json 또는 양식 유형을 게시할 수 있습니까?

안녕하세요 여러분, Grafana는 템플릿 변수를 사용하는 쿼리에 대한 경고를 지원합니까, 아니면 이에 대한 대상 릴리스가 있습니까?

모두, 4.0 베타를 사용해보십시오. 누락된 것이 있으면 새 문제를 엽니다.

리차드

모바일로 보냈습니다. 나의 간결함을 용서하십시오.

4.0 베타를 시도했지만 여전히 이 오류가 발생합니다.
오류 tsdb.HandleRequest() 오류 Influxdb가 상태 코드를 반환했습니다. 잘못된 상태 코드: 400 잘못된 요청

경고 알림을 저장할 수 없습니다 - 보내기, 저장 후 행 보내기가 다시 공백이 됩니다.

@nnsaln 이메일 주소가 아닌 알림 대상을 채워야 합니다. grafana 사이드 메뉴를 열고 알림 메뉴 옵션 위로 마우스를 가져간 다음 알림 메뉴 옵션을 누르십시오. 여기에서 경고 규칙에서 사용할 수 있는 알림 대상을 설정할 수 있습니다.

경고와 함께 템플릿 변수를 지원할 계획이 있습니까? 그렇다
(또는 세트) 템플릿 변수에 의해 생성된 각 그래프가 해당하는지 이해
다른 그래프로 이동하여 정적 값에 대한 경고를 생성하는 것은
정확하지 않습니다.

2016년 12월 5일 월요일 오전 2시 6분, Tomas Barton [email protected]
썼다:

@nnsaln https://github.com/nnsaln 알림을 작성해야 합니다.
이메일 주소가 아닌 그곳을 대상으로 합니다. grafana 사이드 메뉴를 열고 마우스 오버
알림 메뉴 옵션을 누른 다음 알림 메뉴 옵션을 누르십시오. 거기
경고 규칙에서 사용할 수 있는 알림 대상을 설정할 수 있습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/grafana/grafana/issues/2209#issuecomment-264813888 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAY0-X4UkyVE0MeBlSiYD9892OuruGcVks5rE-I6gaJpZM4FJUTl
.

--
디팍

아니요, 현재 이 작업을 지원하지 않습니다. 먼 미래일 수도 있지만

대시보드의 99%는 템플릿 변수를 사용합니다. 그들은 템플릿으로 디자인되었습니다
"대시보드 폭발" 문제를 피하기 위한 변수.

2016년 12월 5일 월요일 오후 8시 20분, Torkel Ödegaard [email protected]
썼다:

아니요, 현재 이 작업을 지원하지 않습니다. 먼 미래일 수도 있지만

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/grafana/grafana/issues/2209#issuecomment-265056805 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAY0-T9iFrqUcq4KbIECDe526040U6DHks5rFOJ4gaJpZM4FJUTl
.

--
디팍

예, 하지만 일반 탐색 대시보드는 경고 규칙에 대한 대시보드 디자인과 동일하지 않습니다.

지금까지 직관적/이해 가능한 방식으로 템플릿 변수를 지원하는 방법에 대한 제안은 없었습니다. 변수가 있는 경고 쿼리는 무엇을 해야 합니까? 현재 저장된 변수 값으로 보간하시겠습니까? 모든 값을 별도의 규칙으로 취급하고 모든 항목에 대해 상태를 유지해야 합니다. 템플릿 변수를 지원하면 복잡성과 잠재적으로 혼란스러운 동작에 대한 웜의 가능성이 열립니다. 누군가 간단하고 이해할 수 있는 방법을 생각해낸다면 언젠가 추가될 수 있습니다.

그 동안에는 별도의 경고 대시보드를 만드는 데 방해가 되지 않습니다.
경고는 grafana에 새로 추가된 기능입니다. 시간이 지나면 진화할 것이고,
그러나 구현된 짧은 시간에 grafana에 엄청난 가치를 더했습니다.
모든 기여자에게 감사드립니다!

오전 06.12.2016 11:14 nachm. 슈리브 "토르켈 외데고르" <
알림@github.com>:

예, 하지만 일반 탐색 대시보드는 대시보드와 동일하지 않습니다.
경고 규칙을 위한 디자인.

지금까지 템플릿 변수를 지원하는 방법에 대한 제안이 없었습니다.
직관적/이해 가능한 방식으로. 변수로 쿼리를 경고해야 하는 항목
하다? 현재 저장된 변수 값으로 보간하시겠습니까? 해야
모든 값을 별도의 규칙으로 취급하고 모든 등의 상태를 유지합니다.
템플릿 변수는 복잡성과 잠재적으로 웜의 가능성을 열어줍니다.
혼란스러운 행동. 누군가가 생각해 낸다면 언젠가 추가할 수 있을까요?
간단하고 이해하기 쉬운 방법.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/grafana/grafana/issues/2209#issuecomment-265290049 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AEKf_5VldwX2fG-USjnmlMH2qOZIDdKpks5rFd5DgaJpZM4FJUTl
.

+1 토켈.

경고를 상당히 복잡하게 만듭니다.

2016년 12월 6일 화요일 오후 2시 14분, Torkel Ödegaard [email protected]
썼다:

예, 하지만 일반 탐색 대시보드는 대시보드와 동일하지 않습니다.
경고 규칙을 위한 디자인.

지금까지 템플릿 변수를 지원하는 방법에 대한 제안이 없었습니다.
직관적/이해 가능한 방식으로. 변수로 쿼리를 경고해야 하는 항목
하다? 현재 저장된 변수 값으로 보간하시겠습니까? 해야
모든 값을 별도의 규칙으로 취급하고 모든 등의 상태를 유지합니다.
템플릿 변수는 복잡성과 잠재적으로 웜의 가능성을 열어줍니다.
혼란스러운 행동. 누군가가 생각해 낸다면 언젠가 추가할 수 있을까요?
간단하고 이해하기 쉬운 방법.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/grafana/grafana/issues/2209#issuecomment-265290049 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAY0-UgrMH9u7sI-FmPVgFhMVXJBvzTvks5rFd48gaJpZM4FJUTl
.

--
디팍

@bergquist 이 댓글에 대해

grafana 내 경고는 아직 HA를 지원하지 않습니다. 우리의 계획은 향후 서버 간 파티션 경고에 대한 지원을 추가하는 것입니다.

진행 상황을 추적할 수 있는 티켓이 있습니까? 기여할 지점이 있습니까?

그리고 좋은 일을 해주셔서 감사합니다!

장식 꼬리,

<3 그라파나.

템플릿으로 알림에 대한 생각을 공유하려고 했습니다.
대시보드.

2016년 12월 9일 금요일 오전 2:53 Dmitry Zhukov [email protected]
썼다:

@bergquist 이 댓글에 관한 https://github.com/bergquist

grafana 내 경고는 아직 HA를 지원하지 않습니다. 우리의 계획은 추가하는 것입니다
향후 서버 간 파티션 경고 지원

진행 상황을 추적할 수 있는 티켓이 있습니까? 기여할 지점이 있습니까?

그리고 좋은 일을 해주셔서 감사합니다!

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/grafana/grafana/issues/2209#issuecomment-265986808 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAY0-aQXFZUeEfVl0MSQP7FQpMZGIh0mks5rGTMsgaJpZM4FJUTl
.

--
디팍

@torkelo @Dieterbe 마침내 Grafana에 알림 기능이 내장되어 정말 기쁩니다! 프로그래밍 방식으로 경고를 생성하는 권장 방법(있는 경우)은 무엇입니까?

@jaimegago 는 대시보드 API를 사용하여 프로그래밍 방식으로 경고를 생성하고 경고는 패널 및 대시보드와 함께 저장됩니다.

@torkelo 알림 대상은

편집 : 여기에서 나 자신에게 대답하면서 api/alert-notifications 끝점을 찾았습니다. 문서화만 하면 될 것 같아요

물론 이에 대한 http API가 있습니다. 알림 페이지로 이동하여 알림을 추가하고 grafana가 만드는 http API 호출을 확인하십시오.

@torkelo , 프로그래밍 방식으로 경고를 생성하는 데 사용할 수 있는 API가 있습니까(경고 알림 생성 안 함)

@CCWeiZ Alerts는 대시보드 json의 일부입니다. 따라서 경고만이 아닌 경고가 포함된 대시보드만 생성할 수 있습니다.

대시보드 API에 대한 자세한 내용은 http://docs.grafana.org/http_api/dashboard/ 에서 확인할 수 있습니다.

사용 가능한가: 3일 전과 비교하여 값이 증가하지 않는 경우 경고를 설정하고 싶습니다. (요청에 따르면 현재 가치가 있는 경우 - 3일 전 요청 < 100이면 요청이 많지 않다고 말합니다.) 이 작업을 수행하는 방법?