Grafana: [기능 요청] 그래프당 여러 알림

구체적인 사용 사례: 각 주요 기능(예: 외부 HTTP 호출 또는 디스크 I/O가 발생하는 위치)에 대해 Prometheus에서 히스토그램을 기록하도록 앱을 계측했으며 이들 중 하나가 느려지면 경고를 표시하고 싶습니다.

현재 그래프와 경고 간의 1:1 관계 때문에 이에 대한 더미 그래프를 정의해야 합니다. 그래프 자체와 같은 위치에 정의된 경고를 유지하는 것이 훨씬 더 논리적입니다.

그리고 당신은 하나의 쿼리에서 그것을 정의할 수 없습니까?

아니; OR 조건 체인은 조잡하고 경고의 단일 이름은 경고의 정확한 원인을 명확하게 식별할 수 없습니다. Some part of service X is failing 라인을 따라 경고를 보내고 싶지 않습니다. 대기 중인 엔지니어는 제 친구가 아닙니다...

별도의 경고 규칙 이름 및 메시지 등을 원하는 경우 경고에 대해 별도의 패널을 갖는 것이 더 합리적입니다.

네, 그게 바로 제가 지금 하고 있는 일입니다. 가까운 장래에 그래프당 여러 경고를 구현하여 이 해결 방법에서 벗어날 가능성이 있습니까?

그것은 매우 가능성이 없다

아마도 엄청난 수요가 있다면 :)

하하 좋아 - 내가 화난 군중을 소란스럽게 할 수 있는지 보겠습니다 ;) 진심으로 ', 정직에 감사드립니다.

좋아, 우리는 2명의 폭도를 가지고 있다 :-) 나는 여러 탱크의 연료 수준을 그래프로 표시하고 있으며 각 탱크에 대해 연료 부족 경고를 설정하고 싶었습니다.

탱크마다 임계값이나 알림이 다릅니다.

정확히. 하나는 285갤런의 난방유 탱크입니다. 탱크가 70갤런 아래로 내려가면 "난방유 부족" 경고를 설정하고 싶었습니다. 다른 하나는 500갤런 프로판 탱크로, 100갤런 아래로 내려가면 "프로판 부족" 경고를 원했습니다. 각각에 대해 단일 통계를 설정했지만 단일 통계에서 경고를 사용할 수 없습니다.

중앙값과 90번째 백분위수 측정항목이 있는 그래프가 있습니다. 각각에 대한 알림을 받고 싶습니다. 이렇게 하려면 각각에 대해 하나의 그래프를 만들어야 합니다. 그런 다음 각각에 대한 경고 및 중요한 경고를 원하면 각각에 대한 두 번째 그래프를 생성해야 합니다.

모니터링할 서비스가 30~40개 있으며 각 서비스에는 2~5개의 주요 메트릭이 있습니다. 여러 고객에 대해 동일한 메트릭을 그래프로 표시하는 그래프가 있으며 고객당 (아직) 알림을 수행할 필요는 없지만 알림을 받고자 하는 메트릭 수에 추가됩니다. 수십 개의 그래프를 만드는 작업의 양이 매우 빠르게 늘어납니다. 현재 프로덕션 환경(및 이전 프로덕션 환경)에서 경고 및 중요한 경고를 표시하고 단일 그래프에 여러 메트릭을 표시하고 이에 대해 경고하는 것이 매우 유용할 것입니다.

이 기능도 보고 싶습니다. 지표가 임계값을 벗어나는 경우의 경고와 데이터 업데이트에 실패한 경우의 또 다른 경고가 좋은 예입니다. 즉, 값이 너무 높아지거나 값이 보고되지 않는 경우입니다. 이는 데이터를 보고하는 모든 항목에서 grafana(또는 백엔드)와의 통신을 방해하는 문제가 발생했음을 표시하는 데 사용할 수 있습니다.

안녕하세요 토르켈로입니다!

기능에 대해 여러 "좋아요"를 받았습니다! 다음 realease =) 를 입력할까요?

@rmsys 는 아마도 어느 시점에서 UX 관점 및 코드 복잡성(및 UX 복잡성) 관점에서 해결하는 데 시간이 걸릴 것입니다. 아직 로드맵에는 없지만 경고 엔진이 더 성숙해지고 이에 대한 UX 디자인이 작동하는 내년에 가능할 것입니다. 밖

여러 경고에 대한 또 다른 좋은 사용 사례는 다른 작업으로 다른 심각도 임계값을 갖는 것입니다. 서버에서 속도가 느려지기 시작하면 이메일로 충분할 수 있지만 속도가 너무 느려지면 관리자에게 호출할 가치가 있습니다.

valid 및 invalid 값이 있는 메트릭을 반환하는 그래프가 있습니다. 이것은 valid 가 너무 낮고 invalid 가 너무 높을 때 발생하는 경고를 생성하기 위해 두 개의 쿼리가 포함된 단일 그래프를 사용할 수 있기 때문에 유용할 것입니다.

또한 경고의 개별 상태를 추적하는 것이 항상 선호되는 것은 아닙니다(최종 사용자는 개별 상태 뒤에 있는 세부 정보를 알아야 하기 때문에).

이게 무슨 말인지 이해가 잘 안가네요. 자세히 알려주실 수 있나요?

그래프당 여러 경고가 작동하고 표시되는 방식을 설명할 수 있습니까? 주석은 무엇을 말하고 패널 제목 옆에 녹색/빨간색 하트가 표시됩니까(2/5 경고 규칙이 실행되는 경우)?

경고 규칙 간에 무언가를 공유하고 싶습니까, 아니면 완전히 격리되어 있습니까(같은 그래프 패널에 있고 동일한 쿼리를 참조할 수 있는 것 외에).

여러 경고 규칙이 있는 경우 임계값을 어떻게 시각화하시겠습니까? 경고 규칙 페이지 및 경고 목록 패널에 별도의 규칙으로 표시됩니까? 그런 다음 경고 탭뿐만 아니라 규칙의 특정 인스턴스로 이동하는 방법이 필요합니다.

Grafana는 시각적 도구이며 경고 규칙 상태를 쉽게 시각화할 수 있도록 경고 규칙을 그래프에 연결하기로 결정했습니다(메트릭, 임계값 및 경고 상태 기록을 통해). 각 그래프가 여러 경고 규칙을 나타낼 수 있도록 하면 이 작업이 매우 복잡해질 것 같아서 이것이 필요한지 잘 모르겠습니다.

singlestat 패널에서 경고 규칙을 지원하는 @rssalerno는 이 문제와 관련이 없는 것 같습니다.

@alex-phillips 시나리오는 개별 경고 규칙을 보다 유연하게 만들어 해결할 수 있는 것처럼 들립니다.

누군가 이것이 좋은 구체적인 예가 있습니까? 어떤 메트릭 및 경고 기록 주석과 관련이 있는지 모르는 2-5개의 임계값이 있는 혼란스러운 그래프로 끝나는 시나리오가 표시되지 않고 어떤 경고 규칙에서 유래했는지도 모릅니다(마우스 오버하지 않음).

그래프당 여러 경고가 작동하고 표시되는 방식을 설명할 수 있습니까? 주석은 무엇을 말하고 패널 제목 옆에 녹색/빨간색 하트가 표시됩니까(2/5 경고 규칙이 실행되는 경우)?

여러 경고 규칙이 개별적으로 주석이 달릴 것이라고 생각합니다. 하트는 색상으로 구분될 수 있습니다. 경고/패널을 구분하기 위해 규칙의 이름을 지정해야 합니다.

경고 규칙 간에 무언가를 공유하고 싶습니까, 아니면 완전히 격리되어 있습니까(같은 그래프 패널에 있고 동일한 쿼리를 참조할 수 있는 것 외에).

일반적으로 그룹에는 공유 임계값이 있어야 하고 그룹이 구현된 경우 이름이 있어야 한다고 생각하지만(https://github.com/grafana/grafana/issues/6557#issuecomment-324363795 참조)

여러 경고 규칙이 있는 경우 임계값을 어떻게 시각화하시겠습니까? 경고 규칙 페이지 및 경고 목록 패널에 별도의 규칙으로 표시됩니까? 그런 다음 경고 탭뿐만 아니라 규칙의 특정 인스턴스로 이동하는 방법이 필요합니다.

규칙이 추가 색상 매개변수를 사용하는 경우 이를 사용하여 임계값을 렌더링할 수 있으며 이와 같이 차별화할 수 있으며 아마도 도구 설명도 필요할 것입니다. 규칙을 토글할 수 있는 것이 유용할 것이며 특정 규칙을 렌더링하는 매개변수가 후자를 처리한다고 생각합니까?

singlestat 패널에서 경고 규칙을 지원하는 @rssalerno는 이 문제와 관련이 없는 것 같습니다.

그가 각 탱크에 대해 별도의 패널을 가지고 있기 때문에 단일 통계 경고가 해당 특정 대시보드에 대한 그의 문제를 해결할 수 있지만 아래 그래프를 참조하고 있음을 알 수 있을 것입니다.

누군가 이것이 좋은 구체적인 예가 있습니까? 어떤 메트릭 및 경고 기록 주석과 관련이 있는지 모르는 2-5개의 임계값이 있는 혼란스러운 그래프로 끝나는 시나리오가 표시되지 않고 어떤 경고 규칙에서 유래했는지도 모릅니다(마우스 오버하지 않음).

주로 #6557 및 #6553을 지원하고 @alex-phillips와 유사한 다중 임계값을 지원하고 싶습니다. 예를 들어 #6557에 대한 한 가지 사용 사례는 여러 임계값과 결합하여 다양한 환경( production , beta , dev 등)에 대해 다르게 경고하는 것입니다. 대부분의 문제를 해결합니다. 여러 규칙 없이 이를 수행하는 더 좋은 방법이 있다면 그것은 나에게 분명하지 않습니다.

@torkelo

그래프당 여러 경고가 작동하고 표시되는 방식을 설명할 수 있습니까? 주석은 무엇을 말하고 패널 제목 옆에 녹색/빨간색 하트가 표시됩니까(2/5 경고 규칙이 실행되는 경우)?

@pdf 에서 제안한 접근 방식이 마음에 듭니다.

또한 주석을 표시하는 접근 방식은 1개 이상의 조건(각각 다른 임계값을 가짐)이 있는 경고 규칙이 있는 현재의 경우와 동일합니다. 그리고 패널 제목 옆의 녹색/빨간색 하트는 빨간색으로 표시됩니다(최소한 하나의 경고가 실행 중인 경우). 이는 경고 규칙의 하나 이상의 조건이 true로 평가되는 현재 시나리오와 유사합니다. 그리고 아마도 제목에 빨간 하트와 함께 숫자(2/5)도 표시될 것입니다.

경고 규칙 간에 무언가를 공유하고 싶습니까, 아니면 완전히 격리되어 있습니까(같은 그래프 패널에 있고 동일한 쿼리를 참조할 수 있는 것 외에).

대부분의 사용 사례에서 이러한 규칙은 규칙 간에 아무 것도 공유하지 않으며 쿼리도 다릅니다.

여러 경고 규칙이 있는 경우 임계값을 어떻게 시각화하시겠습니까? 경고 규칙 페이지 및 경고 목록 패널에 별도의 규칙으로 표시됩니까? 그런 다음 경고 탭뿐만 아니라 규칙의 특정 인스턴스로 이동하는 방법이 필요합니다.

경고 페이지에 별도의 규칙으로 표시됩니다. 경고 탭에는 경고 목록이 정의되어 있을 수 있습니다. 알겠습니다. 알림에서 알림 규칙 URL(알림 ID 또는 인덱스를 캡처해야 함)에 액세스할 때 이 탭에서 특정 알림 규칙을 강조 표시/확장해야 합니다. 쉽게 해결할 수 있을 것 같습니다.

경고 목록 패널에는 변경 사항이 없습니다. 모두 따로따로 보여줍니다. 의미상 각 경고는 별개입니다. 그냥 같은 패널에 배치되었습니다.

누군가 이것이 좋은 구체적인 예가 있습니까? 어떤 메트릭 및 경고 기록 주석과 관련이 있는지 모르는 2-5개의 임계값이 있는 혼란스러운 그래프로 끝나는 시나리오가 표시되지 않고 어떤 경고 규칙에서 유래했는지도 모릅니다(마우스 오버하지 않음).

많은 사람들이 이 기능에 찬성표를 던졌다는 점을 생각하면 분명 유용한 기능일 것입니다. 여러 경고에 대한 지원이 있다면 혼란스러운지 아닌지는 각 사용자의 인식에 달려 있다고 생각합니다. IMHO, 혼란스럽다고 생각하는 사람들은 각 그래프에 대해 별도의 패널을 사용하는 현재 접근 방식을 사용할 것이고, 시각화 및 경고에 동일한 패널을 사용하는 것의 유용성/편의성이 인지된 혼란보다 중요하다고 생각하는 사람들은 다중 경고 방식으로 갈 것입니다. . 물론 UX는 다소 변경될 것입니다.

splunk에는 높음/낮음 경고가 있습니다. grafana에서 여러 경고를 사용할 수 있는 경우 동일한 검색을 사용하고 동일한 검색에 대해 다른 임계값일 뿐입니다.

이 기능에 대해 +1입니다.

이것에 대해 +1. 사용 사례는 다음과 같습니다. 예를 들어 모든 서버에 대한 CPU 사용량이 포함된 하나의 차트를 정의하려고 합니다. 그런 다음 동일한 차트에서 두 개의 숨겨진 메트릭을 만들 것입니다. 하나는 프로덕션 서버의 CPU 사용량이고 다른 하나는 비프로덕션 서버의 CPU 사용량입니다. 이러한 각 메트릭에는 서로 다른 알림 채널과 함께 자체 경고가 있습니다. 이를 수행하기 위해 여러 차트, 패널 또는 대시보드를 만들 필요가 없습니다.

이 기능에 대해 +1입니다.

범주 및 심각도에 관한 다른 문제를 읽고 여기에 왔습니다. 모든 경고가 실행 가능해야 한다는 데 동의합니다. 그러나 "아침에 이 문제를 해결하십시오" 경고와 "시간당 $400 컨설턴트를 최대한 빨리 불러내십시오" 경고 사이에는 차이가 있습니다.

많은 사람들이 언급했듯이 이것은 경고 및 위험 임계값으로 가장 일반적으로 해결됩니다.

기술적으로 이것은 레이블, 패널당 여러 경고, 경고당 여러 임계값 등 다양한 방식으로 구현될 수 있습니다.

분류가 복잡한 경우 혼동과 관련하여 Warning/Critical 설정은 간단히 Red/Yellow를 사용할 수 있습니다. 빨간색이 노란색보다 우선합니다.

더 복잡한 설정의 경우 문제가 되는 시계열을 찾기 위해 마우스를 가져가는 것 외에 다른 옵션은 깜박이는 선/영역/무엇이든 될 수 있습니다. 그러면 올바른 시계열에 쉽게 주의를 끌 수 있습니다.

하지만 대부분의 사용자는 상당히 간단한 경고/치명타 분리에 만족할 것이라고 생각합니다.

이것은 경고 소프트웨어, 특히 서버 모니터링의 경우 절대적으로 필요합니다. 디스크 공간, 메모리, CPU 사용량, 온도, 평균 로드... 모두 임계값이 다른 여러 메시지로 구성된 여러 경고가 필요한 주요 예입니다. 예를 들어 디스크 공간을 사용하십시오. 디스크 사용량이 70%를 초과하는 경우 하나의 경고가 필요하고 디스크 사용량이 90%를 초과하는 경우 다른 경고가 필요합니다.

약간의 예외적인 경우지만 제품이 며칠 동안 판매되지 않으면 경고를 사용하여 알려줍니다. 각 제품을 메트릭으로 사용하므로 메트릭 중 하나가 경고 임계값에 들어갈 때 하나의 경고만 받습니다. 이상적으로는 경고에 경고 임계값에 진입한 추가 메트릭이 표시되는 경우 경고를 수신하는 것이 좋습니다.

또한 템플릿 변수를 사용하여 왼쪽 및 오른쪽 y축에 두 개의 메트릭(볼륨 및 총 마진)을 오버레이하여 선택한 각 제품에 대한 그래프를 반복하고 있습니다. 경고 쿼리가 IN ($sku) 에 대한 $sku 목록 변수를 선택하지 않기 때문에 경고를 사용할 가능성이 없습니다.

이 문제를 해결하기 위해 템플릿 쿼리를 실행하여 관심 있는 모든 sku를 조회하고 경고 쿼리 IN (SELECT skus from interested_product_table) 에 바로 넣는 다른 쿼리 B 를 시도했습니다. 그러나 이렇게 하면 각 그래프의 모든 메트릭에 대해 각 그래프에 대한 경고가 전송되기 시작합니다. 이는 다음을 의미합니다.

Email Alert 1 - metric1,metric2,metric3
Email Alert 2 - metric1,metric2,metric3
Email Alert 3 - metric1,metric2,metric3
Email Alert 4 - metric1,metric2,metric3

Email Alert 5 - metric4
Email Alert 6 - metric4
Email Alert 7 - metric4
Email Alert 8 - metric4

예를 들어 상당히 스팸입니다.

기능이 필수라는 데 전적으로 동의하고 모든 알림이 실행 가능해야 한다는 데 전적으로 동의하지 않습니다.

가장 간단한 예는 경고를 받았을 수 있으며 다음 날 아침과 같이 가능한 한 빨리 조치를 취해야 하는 반면 프로덕션 서버를 수정하기 위해 한밤중에도 일어나야 하는 다른 유형의 경고가 있다는 것입니다.

내 두 센트를 던지고 - 나는 이 기능을 갖고 싶습니다.

다른 하트나 다른 색상의 하트도 필요하지 않습니다(그래프의 모든 경고는 빨간색이면 괜찮음). 다른 이름을 원하는 이메일 알림입니다.

이 기능을 추가해 주세요. 이와 같은 사용 사례의 경우
하나의 그래프에서
값 > X --> 여유가 있는 경우
값 > X+Y --> PD인 경우

여기에는 가능한 경우 수행할 작업을 지정해야 하는 실행 가능한 경고에 대한 정책이 있습니다. 측정항목이 너무 낮거나 너무 높으면 취해야 할 조치가 다릅니다.

예: RDS CPU가 너무 낮습니까? 동작에 대해 여기에서 다른 스택을 확인하십시오. 너무 높은? 인스턴스를 확장합니다.

다른 사람들과 마찬가지로 우리는 또한 서로 다른 임계값에서 서로 다른 유형의 경고를 갖고 싶어합니다.

@jdblack과 유사하게 높은 물 경고 수준과 높은 물 비상 수준을 원합니다. 두 개의 쿼리로 수행할 수 있다는 것을 알고 있지만 직관적이거나 매끄럽지 않습니다.

Autoscaling 시스템에 신호를 보내는 방법으로 Grafana를 사용할 생각이었습니다. 메트릭이 너무 낮으면 축소하라는 메시지가 포함된 웹훅을 보내고, 너무 높으면 확장하라는 메시지와 함께 웹훅을 보냅니다. 여러 경고가 없으면 이것이 가능하지 않다고 생각합니다. 나는 또한 "경고"와 "중요" 임계값에 대한 사용 사례가 일반적이라는 스레드의 다른 사람들과 동의합니다.

경고를 그래프에 연결하는 아이디어를 다시 검토해야 합니까? 경고를 생성할 때 멋진 미리보기 그래프와 함께 경고를 별도로 생성해야 할 수도 있습니다. 이 분리는 그래프 메트릭을 변경할 때 더 많은 작업을 수행하도록 만들 수 있지만 적어도 여러 경고를 만드는 데 더 많은 유연성을 갖게 됩니다.

센서 네트워크에 Grafana + Influx를 사용하려고 했습니다. 대시보드는 경고를 제외하고는 꽤 잘 작동합니다. Sensor123이 특정 임계값을 초과하면 경고를 받아야 합니다. 차트는 필요 없고 경고만 있으면 됩니다. 또한 잠재적으로 1000개의 센서가 있어야 합니다. "모든" 센서가 임계값을 초과하는 경우 경고를 설정할 수 있지만 어떤 센서가 경고하는지 알아야 합니다. 특정 센서를 보기 위해 템플릿 변수로 대시보드를 설정했지만 템플릿 변수에 대한 경고를 추가할 수 없습니다. 테스트를 위해 나는 아무도 보지 않는 추가 대시보드에서 소수의 센서에 대한 소수의 경보를 설정했지만 앞으로는 경보에 대해 다른 솔루션이 필요합니다.

@torkelo , 이에 대한 공식 논평 이후 1년이 가까워지고 있습니다. 경고 시스템이 한동안 사용되지 않았기 때문에 공유할 수 있는 업데이트가 있는지 궁금하십니까?

@MakoSDV 해당 사용 사례에 kapacitor 사용을 고려해야 합니다.

이 기능에 대해 +1; 2단계 경고에도 정말 유용할 것입니다(예: 무언가 > X = 노란색 경고, 무언가 > Y = 빨간색 경고)

알림을 보다 유연하게 만들기 위해 +1

난방 보일러의 온도 그래프를 모니터링합니다. 낮은 온도 임계값은 사소한 것이며 중요하지 않은 알림 채널로 이동해야 하지만 높은 온도는 긴급하고 긴급 채널을 통해 윙윙거려야 합니다. 여러 경고 규칙은 여기에서 많은 의미가 있습니다.

이 문제가 버려진 것처럼 보이는 것은 유감입니다. 우리가 어떻게 개발자의 관심을 끌 수 있는지 아는 사람이 있습니까?

UI 측면에서 보면 재정의가 구현되는 방식으로 경고를 구현하여 UI를 많이 변경하지 않고도 하나 이상의 경고를 허용하는 것이 비교적 쉬울 것입니다.

@Gaibhne 은 다음과 같이 썼습니다.

우리가 어떻게 개발자의 관심을 끌 수 있는지 아는 사람이 있습니까?

지원 비용을 지불하시겠습니까? 심각한 경고 관련 결함에 대해 사용할 수 있는 리소스가 없는 것처럼 보이지만 수년 동안 Github 사용자가 평가한 가장 높은 문제로 남아 있습니다.

이 요청에 대해 +1입니다.

통합 외부 서비스에 대한 요청이 Grafana에서 생성한 그래프의 시간 초과에 대해 앱에 카운터가 설정되어 있습니다.

시간 초과가 몇 번 발생하여 나중에 이에 대해 외부 서비스를 추적할 수 있도록 알고 싶은 경우, 시간 초과가 많은 경우 앱이 대부분의 고객에게 영향을 미쳤을 가능성이 있으므로 응답해야 합니다. 그리고 즉시 처리합니다.

이것도 +1.

현재 그래프에 대해 두 개의 개별 경고를 설정하려고 합니다.

1. _warning_ 수준에 도달한 데이터에 대한 슬랙 메시지
2. _critical_ 수준에 도달한 데이터에 대한 호출기 의무 경고

현재 내가 이해하기로는 이를 수행하려면 동일한 데이터에 대해 두 개의 개별 그래프를 만들어야 합니다. 동일한 그래프에서 여러 개의 서로 다른 경고가 작동하는 것이 더 합리적입니다.

@torkelo 2019년 계획에 대한 업데이트가 있습니까?

+1

표시된 환경 간에 전환하는 변수를 사용하여 여러 클라이언트/환경에 대해 동일한 마이크로서비스를 모니터링하는 대시보드가 ​​있습니다.

클라이언트/환경을 식별할 수 있도록 경고 제목/텍스트에 변수를 사용할 수 있다면 현재의 고통을 줄일 수 있지만 장기적으로는 동일한 그래프를 사용하여 임계값이 다른 별도의 경고를 생성하는 기능을 정말 원합니다.

각 경고에 대해 다른 쿼리를 사용해야 하고 쿼리를 그래프에 표시되지 않도록 설정하는 경우에도 좋을 것입니다.

@itonlytakeswon 에 대해 설명하는 내용도 https://github.com/grafana/grafana/issues/6557 과 관련이 있는 것 같으므로 해당 항목도 추적하고 싶을 수 있습니다. :)

어떻게 이것이 이미 기능이 아닌가?

@jsterling7 은 우리가 원하는 사용 사례를 완벽하게 설명합니다.

@torkelo 모든 기능 릴리스

여러 경고 또는 경고 제목/본문 어딘가에 태그 값을 허용하면 이 문제를 해결할 수 있습니다. 여러 독립 소스가 있는 태그가 지정된 메트릭을 보여주는 단일 그래프가 있고 어느 것이 임계값 아래로 떨어지는지 알고 싶습니다. 나는 지금 이것을 달성하기 위해 필요한 10개의 개별 그래프를 만들고 있는데, 이것은 기능이 누락된 것처럼 느껴지고 장기적으로 유지 관리하기에는 열악합니다.

수요가 많은 것 같은데 이런 기능이 필요한 사람 중 한 명입니다. 나는 거의 grafana를 사랑하지만 갑자기이 제한이 나를 끕니다.

내 사용 사례는 여기에서 참조된 다른 사례 및 #6557 문제와 유사합니다. 단일 템플릿 대시보드에서 모니터링되는 여러 Elasticsearch 클러스터가 있습니다. 개별적으로 경고를 트리거하고 싶습니다. 지금은 하드코딩된 쿼리로 그래프를 생성할 수 없지만 이 경고가 작동하도록 하려면 각 클러스터에 대한 그래프를 생성해야 합니다...

+1, 이것은 우리 환경에 큰 도움이 될 것입니다! 그래프 설정당 노란색/빨간색 '하트' 두 가지 경고만 있어도 빨간색이 트리거되면 노란색이 무시됩니다.

+1 각 조건에 선택적 구성 가능한 경고 알림을 허용하고 특정 조건이 아닌 경우 기본 알림 메시지로 대체할 수 있도록 허용하는 것이 얼마나 사소한지 궁금합니다. 가장 빠른 방법입니다. 제 생각에는 ?

+1 우리에게도 정말 유용할 것입니다. 여러 변수에 대한 템플릿이 있는 대시보드가 ​​많이 있으므로 경고 이름과 경고 알림 모두에 대해 템플릿 대체를 수행하는 것이 좋습니다.

+1, IMO 이것은 모든 모니터링 시스템에 있어야 합니다...경고의 심각도를 식별하고 그에 따라 대응해야 하는 상황이 많이 있습니다. 즉, 동일한 대시보드에서 임계값이 다른 여러 경보를 의미합니다.

나도 +1 - 이것이 이미 존재하지 않는다는 사실에 놀랐습니다!

+1

이 기능은 템플릿 쿼리 지원의 한계와 관련이 있다고 생각합니다.

인스턴스에 템플릿이 있는 쿼리와 유형 레이블이 있는 몇 가지 prometheus 공급 그래프를 설정했습니다. 템플릿 값에 대한 보이지 않는 쿼리를 만들어 템플릿 문제를 해결합니다.

각 템플릿 값에 대해 별도의 알림을 받고 싶지만 일반적인 일률적인 작업+메시지가 포함된 단일 알림으로 제한됩니다. 긴 OR 목록을 사용하여 모든 쿼리에 대해 경고할 수 있지만 이것은 조잡한 느낌입니다.

대안은 경고 소스 역할을 하기 위해 아무도 보지 않는 수많은 패널로 별도의 대시보드를 만드는 것입니다.

여러 경고에 대한 지원을 추가하는 것은 잠재적으로 템플릿 쿼리 경고를 지원하는 첫 번째 단계가 될 수 있을 것 같습니다.

+1. 이것은 필수품입니다!

+1 이것은 매우 유용합니다

@torkelo "별도의 경고 규칙 이름 및 메시지 등을 원할 경우 경고에 대해 별도의 패널을 갖는 것이 더 합리적입니다."

이것은 의미가 없습니다. 사용자에게 유용한 일반 경고 메시지를 보낼 수 있도록 동일한 패널을 여러 번 시각화하도록 요구하는 것은 솔루션이 아닙니다. 기능이어야 하는 것에 대한 해킹이며, 제품의 유용성을 저하시키는 노이즈를 추가합니다.

@torkelo "별도의 경고 규칙 이름 및 메시지 등을 원할 경우 경고에 대해 별도의 패널을 갖는 것이 더 합리적입니다."

이것은 의미가 없습니다. 사용자에게 유용한 일반 경고 메시지를 보낼 수 있도록 동일한 패널을 여러 번 시각화하도록 요구하는 것은 솔루션이 아닙니다. 기능이어야 하는 것에 대한 해킹이며, 제품의 유용성을 저하시키는 노이즈를 추가합니다.

정확히. 패널당 여러 경고에 대해 +1

우리 상황에서는 배터리의 셀 전압을 측정하고 있습니다(배터리당 16셀). 비교를 위해 단일 패널에 16 시리즈를 그래프로 표시하고 각 배터리에 대해 다른 패널을 사용합니다.

패널(그래프)에 대한 단일 경고는 그다지 도움이 되지 않습니다. 경고 전자 메일이 전압 측면에서 범위를 벗어난 셀을 나타내도록 셀당 최소한 하나의 경고를 설정하는 기능이 정말로 필요합니다.

우리의 경우 허용 가능한 전압 범위가 각 셀에 대해 동일하기 때문에 상한 및 하한을 정의하고 개별 셀 범위를 정의된 한계와 연관시킬 수 있으면 좋을 것입니다.

현재 우리는 셀 시리즈에 대해 16 x OR 문을 프로그래밍해야 하고 프로세스의 각 셀에 대한 한계를 (재)정의해야 합니다.

이상적으로는 그래프 패널의 각 셀에 대한 경고 및 중요한 이벤트도 프로그래밍해야 합니다.

사용자가 식별한 요구 사항을 포함하도록 경고 구조를 수정해야 할 때라고 생각합니다. 이러한 요구 사항은 일반적으로 경보를 생성하는 SCADA 시스템에서 구현됩니다. 정말 그냥 논리 엔진이겠죠?

이에 대한 업데이트가 있습니까? 이 기능은 대규모 배포에 꼭 필요한 기능이라고 생각합니다. 특히 예를 들어 스토리지 사용량을 보여주는 단일 그래프를 원하기 때문에 엄청난 양의 그래프가 아닌 70%, 80% 등에 대한 경고를 원합니다.

나는 지금 이것을 우연히 발견했고 아직 이것을 할 방법이 없다는 것에 매우 놀랐습니다 D:

https://github.com/grafana/grafana/pull/20822#issuecomment -561047900에서 이것이 미래에 구현되지 않을 것이며 경고가 대시보드에서 완전히 제거되는 것처럼 들립니다.

이것이 대시보드 json 모델에 어떤 영향을 줍니까? 이 문제에 대해 더 많은 소식이 있을 때 이야기할 수 있는 사람이 있습니까?

정말 필요한 기능이었습니다. 다가오는 상황에 대한 업데이트가 아직 있습니까?

패널당 여러 경고에 대해 +1

이 기능에 대해 +1입니다.

정말 필요한 기능이었습니다. 다가오는 상황에 대한 업데이트가 아직 있습니까?

이 기능이 필요합니다.

3년 후. (요청 건수에도 불구하고) 이것이 구현되지 않은 이유를 알려줄 수 있는 사람이 있습니까?
그것을 구현하는 기술적인 제약 때문입니까? 거절당했어? 할 일이야?
앞서 말했듯이 '기본 기능'인 것 같습니다.
예: 경고를 추가하는 경우 200개의 서버가 있는 대시보드와 시리즈가 있습니다.
200개의 서버 중 하나가 작동하지 않음: 멋지다 이름이 포함된 경고를 수신합니다.
죄송합니다. 새 서버가 작동하지 않습니다. 알림 없음(또는 대시보드를 새로 고쳐야 하거나 24시간 후 알림을 기다려야 합니다.)
이것은 우리가 시리즈의 행별로('전체' 시리즈 대신에) 경고를 받을 수 있도록 확인하는 체크박스처럼 추가할 수 없습니까?
dev, grafana 팀의 누군가가 피드백에 대해 답변할 수 있다면...

알림을 위해 prometheus를 시도하고 대시보드를 수행하기 위해 grafana를 남겨두시겠습니까?

@beastea Grafana를 작동시키기 위해 다른 도구를 설정해야 한다면 Grafana를 사용할 의미가 없습니다. 이 기능이 거기에 존재하고 하나의 도구일 뿐이기 때문에 우리는 Datadog으로 이동하고 있습니다.

@anne-nelson 메트릭 수집기, 메트릭 저장소를 설정해야 하며 적절한 설정을 위해 Grafana가 작동하도록 HA와 함께 놀아야 합니다. 맞죠?
Datadog은 하나의 도구일 뿐만 아니라 이를 숨기고 좋은 작업을 수행합니다. 또한 여전히 datadog과 함께 grafana를 사용할 수 있습니다. https://grafana.com/grafana/plugins/grafana-datadog-datasource

@beastea 그 도구가 무엇인지 잘 모르겠어서 우리가 사용하지 않는 것 같습니다. 우리의 메트릭은 Influx로 전송되며, Grafana 대신 Datadog으로 전송할 것입니다. 직접 보낼 수 있는데 왜 Grafana를 통해 Datadog에 보내나요? 가능한 최소한의 도구를 사용하고 싶습니다.

@anne-nelson 앱에서 메트릭 푸시를 구현할 수 있지만 때로는 일부 시스템 메트릭도 푸시하여 디스크 및 기타 항목에 무슨 일이 일어나고 있는지 알 수 있도록 하는 것이 매우 유용합니다. 이것은 telegraf, collectd 또는 fluentd와 같은 작업을 수행하는 일부 로컬 데몬인 메트릭 수집기가 의미하는 것입니다.
설정의 유입 - 데이터를 조작하기 위해 일부 내부 유입 쿼리 언어를 사용하여 기회를 제공하는 원시 데이터에 대한 웹 UI 프론트엔드로 grafana를 통해 메트릭을 저장하고 검색을 수행할 수 있는 풍부한 기능을 제공하는 것입니다.
Influx 대신 Datadog을 사용하는 경우 정확히 동일한 방식으로 작동합니다. 여기서 Grafana는 데이터 액세스를 위한 UI입니다. 일반 설정에서. 따라서 데이터에 대해 아무 작업도 수행하지 않고 그래프로 표시할 뿐입니다. 그래서 어쨌든 직접 보냅니다.
설명했듯이 inlux로 작업하는 경우 많은 도달 기능을 제공했기 때문에 설명한 문제를 해결하기 위해 kapacitor 또는 Flux를 사용하는 것을 고려하지 않는 경우 grafana는 귀하에게 제공할 수 있으며 여전히 동일한 공급업체에서 제공됩니다. 같은 환경. Flux는 유입 배송 패키지의 일부이기도 합니다.

정말 도움이 될 것입니다.

@beastea 는 아마도 grafana에서 '경고' 기능을 제거하고 사람들을 다른 도구로 마이그레이션하는 것이 더 나을 것입니다(여러 도구의 gaz 공장을 피하기 위해)?
제 말은, OK, 우리는 kapacitor, prometheus 등을 사용할 수 있습니다. 그러나 경고 기능은 이미 Grafana에 존재하므로 제 경우에는 의미가 없습니다.

Btw, 행별로 경고하도록 이 확인란을 추가하는 것을 방지하는 것은 무엇입니까? 아마도 설명이 이해에 도움이 될 것입니다.

@beastea 누군가에게 Grafana를 사용하지 말라고 설득하는 것이 정말 이상한 것 같습니다.

경고가 Grafana의 기능인 한 anthosz가 지적했듯이 그래프에 여러 경고를 추가하는 기능을 기대하는 것이 합리적입니다. 경고에 Grafana를 사용해서는 안 된다고 생각한다면 Grafana에 경고 기능이 없어야 합니다. 많은 사람들이 이 기능을 원하고 많은 경쟁 제품이 이미 제공하고 있음이 분명합니다. 솔직히 왜 이렇게 반대가 많은지 이해가 안됩니다.

@anne-nelson 저는 누군가가 하고 싶은 대로 하지 말라고 설득하려는 것이 아닙니다. 나는 오늘 이미 당신에게 해결책을 제시할 수 있는 다른 방향을 살펴보기 위해 조언을 하려고 합니다.
무엇을 위해 무엇을 사용해야 하는지 지시하는 것이 아니라 오늘 바로 솔루션을 제공할 수 있는 대안을 제시하는 것입니다. 나는 뒤로 미루는 것이 아니라 조언을 하는 것입니다. 제 조언이 도움이 되지 않는다고 생각하신다면 안타깝지만 이것 뿐입니다. 내가 당신을 성가시게 하고 내 충고에 너무 성급한 것 같아 미안합니다.
좋은 시간 보내세요.

@beastea Grafana 에서 일한 수비적인 태도 때문에 추측했습니다. 이 기능은 많은 사람들과 관련이 있으며 기능 요청 시 대체 제품을 제안하는 것은 도움이 되지 않으며 이 토론을 방해합니다. 이것은 스택 오버플로가 아닙니다.

모두가 그냥 두들겨 버릴 수 있습니까? 당신은 잠재적으로 수백 명에게 스팸을 보내고 있습니다. 이것은 생산적이지 않습니다.

추가 소음에 대해 모두 죄송합니다.

@torkelo 이 기능 요청에 대한 업데이트를 제공해 주시겠습니까? 이 주제는 _년_ 동안 열려 있었고 보시다시피 여전히 관심이 있습니다. 최소한 현재 로드맵에 이것이 포함되어 있는지 여부에 대한 일종의 "공식적인" 답변을 얻기 위해 이 주제에 대한 말다툼과 불필요한 잡담을 줄이는 데 도움이 될 수 있습니다. 건배.

이것과 유사한 #6041은 완전히 무시됩니다. 이유가 궁금합니다.

운영 팀이 플랫폼에 새로운 통합을 등록하기 때문에 우리에게는 의미가 있습니다. 자동으로 그래파이트에 메트릭을 보내기 시작합니다. 그리고 grafana에서 단 하나의 패널만이 이 모든 것을 감시합니다.

여러 시스템이 다운되면 첫 번째 시스템에 대한 알림만 받습니다. 그리고 그다지 설명적이지도 않습니다.

하나가 다운되고 두 번째 것도 꺼지면 경고가 다시 발생하지 않습니다.

이에 대한 사용 사례는 prometheus 및 grafana를 통해 다중 창 다중 연소율 경고를 정의하는 것입니다. 이는 Google SRE 핸드북( https://landing.google.com/sre/workbook/chapters/alerting-on-slos/ )에 정의된 대로 SLO 모니터링을 위해 이러한 유형의 경고를 표시하는 표준 관행입니다.

이거 무조건 따라하세요..

나는 또한 Prometheus 경고에서 Grafana 경고로 옮겼고 나는 이것을 절대적으로 고대하고 있습니다!

이전에 Grafana에서 작업한 적이 있는 사람이 이 문제를 해결하는 데 있어 알려진 문제를 나열할 수 있습니까?

@torkelo님 , 이 문제에 대해 알려주실 수 있습니다!

7.x가 경고에 대한 개선 사항이 없는 것을 보고 실망했습니다. 경고가 완전히 제거되어야 한다는 이전 제안은 희망으로 저를 채워주지 않지만, 만약 그렇다면 7.x에서 경고를 제거하는 것은 확실히 되었을 것입니다. 개편의 규모를 감안할 때 논리적입니까?

이것이 구현하기 어려운 이유에 대한 업데이트를 받는 것이 좋습니다. 이 문제가 오랫동안 공개된 _이유_를 이해할 수 있도록 하기 위해서입니다.

@torkelo 안녕하세요.
동일한 요구 사항이 있습니다. 단일 그래프의 단일 메트릭에 대한 여러 경고이지만 여러 서버가 모니터링됩니다.
'/' 파티션에 정의된 여유 공간 메트릭이 있는 ~100개의 서버가 있습니다(예: 그런 메트릭이 수십 개 있기 때문에). 그리고 '/'의 여유 공간이 20% 미만이 되면 각 서버에서 하나의 고유한 경고 알림을 받아야 합니다.
예를 들어 server2가 경고를 발생시키고 사람들이 문제를 해결하는 동안 server4는 동일한 경고를 발생시킵니다. 우리는 알림을 받지 않습니다. 아니면 일부 기능이 누락되었습니까?

메트릭당 서버당 패널을 곱하는 방식은 그렇지 않습니다.
누군가 나에게 조언을 해 줄 수 있습니까? 이것을 가능하게 하는 방법은 무엇입니까?
Grafana(현재 버전은 6.3.5)를 업그레이드해야 합니까? 확장 프로그램을 추가하시겠습니까? 플러그인? 다른 건 없나요?

조언하거나 도움을 줄 수 있는 모든 사람에게 감사하고 감사합니다.

@torkelo 안녕하세요.
동일한 요구 사항이 있습니다. 단일 그래프의 단일 메트릭에 대한 여러 경고이지만 여러 서버가 모니터링됩니다.
'/' 파티션에 정의된 여유 공간 메트릭이 있는 ~100개의 서버가 있습니다(예: 그런 메트릭이 수십 개 있기 때문에). 그리고 '/'의 여유 공간이 20% 미만이 되면 각 서버에서 하나의 고유한 경고 알림을 받아야 합니다.
예를 들어 server2가 경고를 발생시키고 사람들이 문제를 해결하는 동안 server4는 동일한 경고를 발생시킵니다. 우리는 알림을 받지 않습니다. 아니면 일부 기능이 누락되었습니까?

메트릭당 서버당 패널을 곱하는 방식은 그렇지 않습니다.
누군가 나에게 조언을 해 줄 수 있습니까? 이것을 가능하게 하는 방법은 무엇입니까?
Grafana(현재 버전은 6.3.5)를 업그레이드해야 합니까? 확장 프로그램을 추가하시겠습니까? 플러그인? 다른 건 없나요?

조언하거나 도움을 줄 수 있는 모든 사람에게 감사하고 감사합니다.

이 문제는 2017년부터 시작되었습니다(@torkelo의 답변은 🤡 "경보에 대해 별도의 패널을 갖는 것이 더 합리적입니다." 🤡(600개의 서버가 있을 때 서버/경고별로 패널을 만드는 것이 매우 좋습니다) 🤡)입니다.

유일한 방법은 Grafana에서 다른 솔루션으로 마이그레이션하거나 유지 관리할 여러 도구로 gaz 공장을 만드는 것입니다.

@anthosz - 정말 감사합니다. 문제는 환경은 우리의 것이 아니라 고객의 것이기 때문에 내가 주도적으로 이것을 주장하고 앞으로 고객이 "이런 댓가를 지불하지 않을 것"을 극복하기 위해 내가 앞장서서 주장하는 것은 일종의 매우 어려운 작업이 될 것입니다. .
그러나 적어도 '이런 방아쇠/경보를 구성할 가능성이 없습니다.

다시 한번 감사합니다.

_join(목소리, 합창단)_
공기 펌프, 공칭 1.5A 및 유출 펌프 10Amps를 모니터링하는 회로에 전류 센서가 있습니다. 공기 펌프는 연중무휴로 작동하며 유출 펌프는 탱크 수위를 기준으로 요청 시 작동합니다. 모든 것이 정상일 때 전류(I)는 폐수 펌프가 꺼져 있을 때 1.5A이거나 폐수 펌프가 켜져 있을 때 11.5A입니다.

첫 번째 일반적인 고장은 공기 펌프가 고장났을 때 전류가 없거나 배출 펌프가 작동 중임을 감지하는 (Imax < 0.5A 또는 Iavg 9A ~ 11A)에 의해 경고되는 공기 펌프 소진입니다. 시스템 오류를 방지하려면 48시간 이내에 해결해야 합니다. 데이터는 분당 1포인트이며 90분 후에 경고합니다.

동일한 그래프에서 두 번째로 원하는 경보는 (Imax > 14A 또는 Iavg 2A에서 9A 사이) 펌핑해야 할 때 폐수 펌프가 막혔거나 공기가 유입되었음을 나타냅니다. 이것은 3시간 이내에 해결해야 할 수 있는 훨씬 더 긴급한 경고이므로 5분 후에 경고하는 것이 이상적입니다.

두 경고 모두 LoRa를 통해 데이터를 보내는 동일한 원격 전류 센서에서 발생합니다. 여러 경고를 사용하면 동일한 센서에 대해 대시보드 쿼리를 복제하지 않아도 됩니다.

@torkelo 다중 그래프는 많은 사용자가 확장할 수 없습니다. 이렇게 추가하면 될 것 같은데 왜 안 고려하시는지 궁금합니다.

아마도 엄청난 수요가 있다면 :)

@torkelo님 , 수요가 많다고 생각하는 것은 무엇입니까? 96개의 댓글과 250개의 "좋아요"가 어마어마한데요? 이것은 8번째로 많은 댓글이 달린 공개 기능 요청이며 하나의 비공개 기능 요청에만 그보다 더 많은 댓글이 있습니다. 더 많은 :+1: 반응이 있는 3번째 공개 기능 요청이기도 합니다. 로드맵을 입력하려면 무엇이 필요합니까?

@torkelo 아주 간단한 케이스 시나리오가 있습니다.

값이 임계값 아래로 내려가면 값이 (다른) 임계값을 초과할 때의 경고와 다른 경고가 필요합니다.

다음은 다른 시나리오입니다. 정상적인 서버 수를 모니터링할 때 1개의 서버를 잃을 때(10분 이상 걸리지 않는 한 문제가 되지 않는 합법적인 재시작)과 5개의 서버를 잃을 때 다른 경고가 필요합니다.

여기에 또 다른 시나리오가 있습니다. 대기열 증가율이 임계값을 초과하면 다른 경고를 설정하고 대기열 크기 자체가 임계값을 초과하면 다른 경고를 설정하고 싶습니다.

시각화 측면에서 커뮤니티는 처음부터 어떤 솔루션이든 만족할 것이라고 믿습니다. 예를 들어 첫 번째 경고만 시각화합니다(따라서 UI 변경이 필요하지 않음). 어떤 경고가 트리거되었는지 알려주는 수직선으로 모든 경고를 시각화합니다. 특정 시리즈 등 위로 마우스를 가져가면 임계값/경고만 표시합니다.

그냥 내 2 센트.

여보세요!

여기에서 차임벨을 울리고 싶었습니다. 우리(Spotify)도 이것을 필요로 합니다.

우리는 현재 Grafana에서 경고를 소싱하는 자체 경고 엔진과 시계열별로 경고를 실행하고 있습니다. 현재 시계열별 경고 주석을 다시 grafana로 푸시합니다.

따라서 UI 측면에서 경고하는 첫 번째 시계열은 패널/경고가 "경고" 상태로 전환되고 각 후속 경고가 쌓이게 됩니다(상태 기록에는 경고에 대한 여러 업데이트가 표시되고 마찬가지로 여러 변경 사항이 표시됩니다. "확인"으로 돌아가기)

이것이 우리가 항상 경고를 수행하는 방식이므로 "필요"하므로 시계열별 경고에서 멀어지는 것은 ~10,000개의 경고에 대해 엄청난 사회적 변화가 될 것입니다. 우리는 Grafana 기본 알림을 사용 및 채택하고 이를 지원하기 위해 데이터 소스를 업데이트하고 싶습니다.

여기에서 차임벨을 울리고 싶었습니다. 우리(Spotify)도 이것을 필요로 합니다.

그라파나 엔터프라이즈도 사용하셨나요? 개발자를 돕고 동기를 부여할 수 있습니다 =)

우리는 또한 같은 그래프에서 여러 경고를 트리거하는 기능인 이 기능을 보고 싶습니다. "아래" 및 "위" 상태에서 트리거할 수 있는 기능을 제공하고 보다 중요한 임계값 위반에 앞서 실제로 황색 경고가 될 가능성이 있습니다.

우리는 현재 Grafana에서 경고를 소싱하는 자체 경고 엔진과 시계열별로 경고를 실행하고 있습니다. 현재 시계열별 경고 주석을 다시 grafana로 푸시합니다.

@sjoeboo 여기서 주제에서 조금 벗어나지만 공개적으로 사용할 수 있는 것이 있습니까?

@vbichov 아직 , 우리는 알림 엔진을 오픈소스화하고 싶지만, 시간은 유동적입니다. 주석을 통해 경보의 시계열별 추적을 가능하게 하는 (거의 이상적이지 않은) 내부 포크에 있는 패치를 공유할 수 있다고 확신합니다.

참고로 경고 엔진은 현재 TSDB에만 적용됩니다(https://github.com/spotify/heroic).

이 기능에 대해 +1입니다. 이것은 경고/중요와 같은 것입니다. 우리는 삶이 더 나빠지기 전에 경고를 받고 싶습니다. 그런 다음 즉각적인 조치를 취하기 위해 중요한 경고를 받아야 합니다.

사용자의 요청이 3년이 지난 후에도 이것이 구현되지 않았다는 사실에 놀랐습니다.

여러 패널(각 경고에 대해 하나씩)을 만들어야 하는 것은 대시보드를 막히게 하고 새 경고를 추가해야 하는 것보다 훨씬 더 복잡하게 만듭니다.

패널당 하나 이상의 경고를 정의할 수 없는 경우 경고 탭에 1이 표시되는 이유가 항상 궁금합니다. 쿼리 탭에서 이 숫자는 정의된 쿼리 수도 표시합니다. 그래서 나는 항상 이것이 가능하다고 생각했고 이것이 아직 가능하지 않다는 것에 매우 놀랐습니다.

이것이 아직 구현되지 않은 것이 흥미롭습니다. 경고 탭의 "카운트"가 여러 개일 수 있다고 믿게 하기 때문에 오해의 소지가 있다는 점에 동의합니다. 또한 경고 규칙에 따라 패널을 갖는 것은 약간 우스꽝스럽습니다. 즉, 경고용 패널에 불과한 "쓸모 없는" 대시보드가 ​​있다는 의미입니다. 그것은 확실히 지저분한 대시보드이지만 이것을 구현하는 유일한 방법입니다. 주로 이름 및/또는 알림 끝점 조합에 대해 다른 규칙을 가질 수 있도록 하기 위한 것입니다. 한마디로 복잡합니다.

완료 되었습니까?
Grafana 버전 = 4.x

이제 Grafana 버전이 7.x로 이동하고 이 기능을 보지 못했습니다.

완료 되었습니까?
Grafana 버전 = 4.x

이제 Grafana 버전이 7.x로 이동하고 이 기능을 보지 못했습니다.

너무 순진해요😁

이 기능에 대해 +1입니다.
단일 측정항목에 대해

1. 구성 요소가 예상대로 작동하지 않고 2차 라인 지원에 의한 면밀한 모니터링이 필요함을 나타내는 경고 경고
2. 구성 요소가 실패하고 3차 라인 엔지니어링에 대한 콜아웃을 트리거함을 나타내는 오류 경고입니다.
   메트릭을 복제하는 것은 서투르고 모니터링을 위해 대시보드를 혼란스럽게 만듭니다.

많은 간단한 기능이 이 그룹에 의해 지속적으로 거부되었습니다. 다른 많은 기능 요청을 확인하십시오. 이것은 기본적인 것 같습니다.

다른 예를 들겠습니다.

저는 시놀로지를 실행하고 있으며 이에 대해 경고하고 싶습니다. Raid Status의 정상 값은 1입니다. 그러나 Degraded 값은 11이고 Crashed 값은 12입니다. Degraded는 데이터에 계속 액세스할 수 있음을 의미합니다. 충돌은 데이터 손실 가능성이 높음을 의미합니다.

Raid가 성능 저하된 경우 경고를 보내고 Raid가 충돌한 경우 심각한 경보를 보내고 싶습니다.
여러 볼륨과 스토리지 풀이 있고 각각에 대해 여러 그래프를 요구하는 것은 확장할 수 없습니다.

이것은 디스크 공간 사용과 같은 간단한 작업에도 적용할 수 있습니다.
디스크 사용량이 80%에 도달하면 경고를 보내고 디스크 사용량이 90%에 도달하면 위험 경보를 보내고 싶습니다. 각 디스크에 대해 여러 그래프를 수행하는 것은 합리적인 요구가 아닙니다.

그리고 UI에서 이게 어렵다는 댓글이 이해가 안가네요. 대시보드 목록과 유사한 것이 이미 있습니다. 경고 탭을 클릭하면 하단에 "새 경고 생성" 버튼과 함께 경고 규칙 목록이 이름별로 표시되어야 합니다. 각 경고 규칙의 오른쪽에는 "편집", "비활성화" 또는 "삭제" 옵션이 있어야 합니다. 경고를 클릭하거나 편집 버튼을 클릭하면 표시되지만 해당 특정 경고 규칙에 대한 기존 편집 페이지로 이동해야 합니다.

각 디스크에 대해 여러 그래프를 수행하는 것은 합리적인 요구가 아닙니다.

API를 사용하여 대시보드 및 알림 생성/업데이트를 자동화할 수 있습니다. 원하는 경우 주기적으로 쿼리를 실행하여 prometheus(또는 가지고 있는 소스)를 쿼리하는 프로그램을 생성하여 서비스가 대상을 검색하고 자동으로 경고를 생성할 수 있습니다.

이 문제에 대한 엄청난 피드백과 함께 이 기능이 아직 구현되지 않았다는 사실이 놀랍습니다.

저는 Magellan Telescopes에서 시각화 및 경고 엔진으로 Grafana를 사용합니다. 하나의 플롯에 모두 포함할 수 있는 특성을 공유하는 여러 하위 시스템이 있는 경우 문제가 발생하고 하나가 잘못 동작하기 시작하면 내 사용자는 실패한 경고와 발굴을 받아야 합니다.

더미 플롯을 만드는 것은 해결책이 아니라 해결 방법입니다. 이건 기본인듯!

+1 필요한 기능

+1

OP와 똑같은 상황입니다. 이미 구현했어야 하는 기본 기능입니다.

사람들이 가치 있는 것을 추가하지 않고 이 스레드 문제의 스팸을 중지할 수 있습니까?

문제 상단의 반응을 사용하여 관심을 표시하십시오.

https://github.com/grafana/grafana/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc 는 유지 관리자가 스팸을 보내는 사람들보다 "인기 있는" 문제를 주장하는 데 훨씬 더 유용합니다. 문제 설명만 봐도 이미 명확한 정보가 포함된 모든 사람이 받은 편지함과 github 알림을 이메일로 보냅니다.

그것이 너무 기본적인 것이라면 아마도 다른 사람들이 무료로 일하기를 기대하는 모든 불만 제기자 중 누군가가 이것을 스스로 구현하고 풀 리퀘스트를 하거나 메인테이너가 업스트림에서 원하지 않는 경우 자체 포크를 유지해야 할 것입니다.

@thomasf "가치 있는 것을 추가하지 않고 이 스레드 문제의 스팸을 중지할 수 있습니까?" - 당신이 그랬던 것처럼?

메인테이너가 여전히 스레드에 있다면, 새로운 코멘트는 최소한 그것을 상기시켜줍니다. 이 시점에서 유지 관리자가 오랫동안 그것을 구현할 방법이 없으며 사람들은 유지 관리자가 실제로 신경을 쓰는 Datadog과 같은 더 나은 도구로 이동해야 하지만 수백 개의 의견(특히 실제 시나리오가 있는 경우 ) 엄지손가락을 치켜세우는 것보다 훨씬 더 많은 영향을 미칩니다.

메인테이너가 여전히 스레드에 있다면, 새로운 코멘트는 최소한 그것을 상기시켜줍니다. 이 시점에서 유지 관리자가 오랫동안 그것을 구현할 방법이 없으며 사람들은 유지 관리자가 실제로 신경을 쓰는 Datadog과 같은 더 나은 도구로 이동해야 하지만 수백 개의 의견(특히 실제 시나리오가 있는 경우 ) 엄지손가락을 치켜세우는 것보다 훨씬 더 많은 영향을 미칩니다.

또는 업데이트 없이 +1/메시지가 많은 유일한 사람이 아니라 스팸 때문에 유지 관리자가 이 문제에 대한 알림을 수신 거부했을 수 있습니다. Grafana와 DataDog를 비교하지 마십시오(저희는 둘 다의 사용자였으며 DataDog으로 돌아갈 방법이 없습니다).

이것을 얻는 가장 좋은 방법은 기부하는 것입니다(또는 아마도 Grafana Entreprise에 대해 지불)

당신은 매우 잘못되었습니다. 무료 여부는 넣을 수 없습니다
forum/slack/github/feedback 채널로 이동한 다음 무시하세요. 그렇게 생각한다면
소프트웨어를 오픈 소스 라이선스에 두는 것은 "불만 없음"과 "사람
당신의 기능을 위해 무료로 개발할 것입니다" 당신은 다시 매우 잘못되었습니다.
제 경우에는 이 기능으로 그라파나를 10명에게 판매할 수 있다고 설명했습니다.
내 고객. 나를 무시했다는 것은 고객에게 화를 냈다는 의미입니다. 엄청난
이동 아마 그들은 "충분한"돈을 벌고 더 이상 원하지 않습니다. 나는 행복합니다.
그들을 위해....

Il giorno mer 14 ott 2020 alle ore 15:35 Thomas Frössman <
알림@github.com> 스크립트:

사람들이 다음 항목을 추가하지 않고 이 스레드 문제의 스팸을 중지할 수 있습니까?
값?.

문제 상단의 반응을 사용하여 관심을 표시하십시오.

그것이 너무 기본적인 것이라면 아마도 모든 불만 제기자 중 누군가는
다른 사람들이 무료로 작업을 수행하려면 이를 직접 구현해야 합니다.
풀 리퀘스트를 하거나 다음과 같은 경우 자체 포크를 유지합니다.
관리자는 업스트림에서 그것을 원하지 않습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/grafana/grafana/issues/7832#issuecomment-708406018 ,
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AABBIFUYLMIO4WH7LBYQ6FTSKWSLXANCNFSM4DDVAQPQ
.

내가 _모든_ 소프트웨어에 지출할 용의가 있는 금액은 투자에 대해 제공될 것으로 예상할 수 있는 고객 서비스 수준에 정비례합니다. 그것이 "유료 지원"을 제공하는 오픈 소스 제품이든 상용 제품이든 그것은 별로 중요하지 않습니다.

이 문제를 프로젝트 관리자의 엿보기 없이 너무 오랫동안 열어 두는 것은 불행히도 돈을 지출함으로써 어떤 것이 달라질지 여부에 대한 합리적인 의심으로 추론합니다. 소프트웨어를 판매하려는 경우 이를 고려하는 것이 현명할 것입니다.

pull 요청을 하거나 자체 포크를 유지

어디에서 시작해야 하는지에 대한 개발자의 힌트가 있었다면, 단순히 가치가 너무 크기 때문에 해야 하는지 여부에 관계없이 이것을 고려할 것이라고 말하는 것은 저 혼자가 아닐 것입니다. 제공하다. 슬프게도 그것은 사실이 아닌 것 같으며 유지 보수 담당자가 실제로 신경 쓰지 않는 것처럼 보이는 기능을 위해 제품을 리버스 엔지니어링하는 데 거의 관심이 없습니다.

마지막으로 스레드가 닫히거나 잠기지 않는 한 자신의 생각을 말하지 않을 이유가 없습니다. 귀하에게 적합하지 않은 경우 구독을 취소할 수 있습니다. 나는 실제로 이것의 상대적 부조리에 대해 한탄하는 사람들을 읽는 것을 즐깁니다. 😁

8에 대해 계획된 경고 NG(NextGen) 경고는 단일 경고 정의에서 여러 경고 인스턴스를 지원합니다. 따라서 prometheus와 같은 시스템에서 host=* 와 같은 것은 호스트별로 경고를 생성합니다.

https://github.com/grafana/grafana/issues/6983#issuecomment -712915673에 추가된 단일 통계의 맥락에서 이에 대한 몇 가지 일반 정보

우리는 여전히 디자인하고 프로토타입을 만들고 있지만 다음 사항에 대한 몇 가지 초기 생각에 응답합니다.

그래프당 여러 경고

경고 정의는 자체 엔터티이므로 패널에 연결되지 않습니다. 경고 정의에서 여러 경고 인스턴스가 될 수 있습니다. 그러면 패널이 인스턴스 또는 정의를 구독할 수 있습니다. 그래도 좋은 흐름이기 때문에 경고를 생성하기 위해 대시보드 패널에서 멋진 UX 경로를 원할 것이라고 생각합니다.

또한 경고의 개별 상태를 추적하는 것이 항상 선호되는 것은 아닙니다(최종 사용자는 개별 상태 뒤에 있는 세부 정보를 알아야 하기 때문에).

하나의 정의에서 많은 경고가 허용되면 그룹화 방법이 문제가 됩니다(많은 경고에 도달할 수 있으므로). 현재 이것이 Alerting NG와 함께 작동하는 방법에 대한 두 가지 경로가 있습니다.

1. 경고 인스턴스 그룹화를 처리할 수 있는 호출기 또는 경고 관리자와 같은 IRM을 통해 경고 NG를 사용합니다.
2. 더 큰 범위 측정기준으로 그룹화하도록 쿼리를 변경합니다. 예를 들어 $ host=*,cluster=* cluster=* 를 쿼리하는 경우(또는 데이터 소스와 같은 SQL의 경우 그룹화 기준). 또는 데이터 소스가 이 작업을 수행하지 않는 경우 그룹/별 피벗 작업을 허용하기 위해 서버 측 표현식(경고 ng와 함께 제공)에 기능을 추가하려고 합니다. IRM을 사용하지 않고 이메일/슬랙과 같은 서비스로 직접 보내는 경우가 이에 해당합니다.

경고/중요

이것은 더 복잡합니다. WIP 디자인의 경우 기능으로 제거했습니다(적어도 경고 정의의 경우 경고 정의를 복제하고 변경할 수 있는 방법과 심각도로 레이블을 지정하거나 태그를 지정하는 방법이 있을 수 있음)

많은 경우에 매우 유용하기 때문에 이것은 어렵습니다.

• 나에게 경고/중요는 파손/파손 접근 또는 저하/파손과 같은 명확한 용도를 가지고 있습니다.
• 그것들이 없으면 많은 설정이 다른 심각도 수준에 대해 상당한 양의 경고를 반복하게 됩니다.

그렇다면 왜 그것들을 갖지 않기로 결정합니까? 이것은 분명하지 않은 복잡성을 상당히 추가합니다.

• 다른 메트릭에서 오는 임계값(또는 값이 아닌 쿼리 시간의 다른 범위에 대한 임계값)을 지원한다고 가정하면 이제 두 가지 조건을 실행할 수 있습니다.
• 경고 인스턴스의 상태에 대해 최소한 다음을 지원하고 싶습니다.
  
  
  
  • 알 수 없음: 인스턴스가 사라졌습니다.
  
  
  • 오류: 인스턴스에 대한 문제가 있음을 발견했을 쿼리가 깨졌습니다.
  
  
  • 경고: 조건이 true입니다.
  
  
  • 정상. 조건이 사실이 아닙니다
  
  
• 우리는 또한 FOR와 같은 표현을 계속 사용하기를 원합니다. 더 많은 상태를 추가할 때 플래핑이 없는 디자인은 알림을 놓쳤거나 노이즈가 발생하지 않도록 하는 것이 복잡합니다. 일반적으로 상태 머신은 시간이 지남에 따라 버그가 발생하기 쉽고 제대로 하기가 어렵습니다(그런 종류를 좋아하는 경우 TLA/Temporal Logic of actions 검색). 따라서 심각도 수준을 추가하면 예상보다 상태 공간이 늘어납니다. 이는 우리가 의도하지 않은 행동을 하거나 정신적 모델을 갖기가 더 어려운 행동을 할 가능성이 더 높다는 것을 의미합니다.
• 다른 시스템 또는 IRM과의 통합을 모색할 때 심각도에 대한 특정 개념이 있으면 통합이 복잡해질 수 있습니다.

(적어도 경고 정의의 경우 경고 정의를 복제하고 변경하고 심각도로 레이블을 지정하거나 태그를 지정하는 방법이 있을 수 있습니다.

이것은 중요/경고 구분에 대해 완벽하게 수용 가능한 해결 방법입니다. 나는 별도의 임계값을 유지하는 것을 기쁘게 생각합니다. 결합된 경고/심각한 임계값이 있으면 있으면 좋겠지만 문제를 해결하는 것은 아닙니다.

그런 다음 그룹화 방법이 문제가 됩니다(많은 경고를 받을 수 있으므로)

자신의 티켓 양과 알람 생성을 관리하는 것은 사용자의 몫입니다. 알람을 설정하는 경우 각각은 별도의 이메일 또는 알림이어야 합니다. 예를 들어 여러 경보를 하나의 이메일로 그룹화하여 경보 트리거를 기반으로 티켓을 생성하는 자동화된 시스템을 만드는 경우 이를 어렵게 만들거나 귀찮게 만들 수 있습니다. 또한 하나의 이메일에 여러 개의 알람이 표시된다는 것은 각 알람이 자체 이메일 스레드를 가질 수 없다는 것을 의미하며, 사용자가 수동으로 분리해야 하고 새 스레드가 시작됩니다. 대신 스레드가 해당 특정 알람에 포함될 수 있도록 각 알람 트리거에는 자체 알림이 있어야 합니다.

그룹화에 대해 걱정할 필요가 없으므로 이것이 놀라운 디자인을 단순화하기를 바랍니다. 그것은 사용자가 처리할 몫입니다.