Grafana: [Solicitação de recurso] Vários alertas por gráfico

Caso de uso concreto: eu instrumentei meu aplicativo para gravar um histograma no Prometheus para cada função principal (por exemplo, onde uma chamada HTTP externa ou E/S de disco ocorre) e gostaria de alertar quando qualquer uma delas se tornar lenta.

Atualmente eu tenho que definir gráficos fictícios para isso por causa da relação 1:1 entre gráfico e alerta. Seria muito mais lógico manter os alertas definidos no mesmo local do próprio gráfico.

E você não pode definir isso em uma consulta?

Não; uma cadeia de condições OR é grosseira, e o nome único do Alerta não pode identificar claramente o motivo exato do alerta. Eu definitivamente não quero enviar alertas Some part of service X is failing - engenheiros de plantão não seriam meus amigos...

então faz mais sentido ter painéis separados para os alertas, se você quiser nome e mensagem de regra de alerta separados, etc.

Sim, é exatamente o que estou fazendo no momento. Existe alguma probabilidade de implementar vários alertas por gráfico em um futuro próximo para que eu possa me afastar dessa solução alternativa?

é muito improvável

talvez se houver uma grande demanda por isso :)

haha OK - vou ver se consigo levantar uma multidão enfurecida ;) Sério mesmo, obrigado pela honestidade.

Ok, temos uma multidão de dois :-) Estou representando os níveis de combustível em vários tanques e queria configurar um alerta de combustível baixo para cada tanque.

e cada tanque tem diferentes limites ou notificações?

Exatamente. Um é um tanque de óleo de aquecimento de 285 galões. Eu queria configurar um alerta de "óleo de aquecimento baixo" quando esse tanque ficar abaixo de 70 gals. O outro é um tanque de propano de 500 galões, para isso eu queria um alerta de "propano baixo" quando estiver abaixo de 100 gal. Eu configurei singlestats para cada um, mas os alertas não estão disponíveis em um singlestat.

Eu tenho um gráfico com uma mediana e uma métrica de percentil 90. Eu gostaria de receber um alerta sobre cada um. Para fazer isso, eu tenho que criar um gráfico para cada um. Então, se eu quiser avisos e alertas críticos para cada um, tenho que criar um segundo gráfico para cada um.

Tenho 30 ou 40 serviços para monitorar, cada um com 2 a 5 métricas principais. Eu tenho gráficos onde eu grafo a mesma métrica para vários clientes e, embora eu não precise fazer alertas por cliente (ainda), isso aumenta o número de métricas nas quais eu gostaria de ter alertas. A quantidade de trabalho para criar dezenas de gráficos se expande muito rapidamente. Seria muito útil em meu ambiente de produção atual (e em meus ambientes de produção anteriores) ter avisos e alertas críticos e exibir várias métricas em um único gráfico e alertar sobre elas.

Eu também gostaria de ver esse recurso. Um bom exemplo é um alerta se uma métrica sair de um limite e outro alerta se os dados falharem na atualização. Ou seja, se um valor for muito alto ou se os valores não forem reportados. Isso pode ser usado para mostrar que o que está relatando os dados encontrou um problema que está impedindo a comunicação com o grafana (ou qualquer outro back-end).

Olá Torkelo!

Recebi vários "likes" para o recurso! Entraremos no próximo lançamento =) ?

@rmsys talvez em algum momento, resolvê-lo da perspectiva do UX e da complexidade do código (e complexidade do UX) levará tempo, ainda não está em nenhum roteiro, mas talvez no próximo ano, à medida que o mecanismo de alertas amadurecer mais e um design UX para isso seja trabalhado Fora

Outro bom caso de uso para vários alertas é ter diferentes limites de gravidade com diferentes ações. Se um servidor começar a apresentar lentidão, um e-mail pode ser suficiente, mas se a lentidão se tornar extrema, pode valer a pena chamar o administrador.

Eu tenho um gráfico que retorna uma métrica com o valor de valid e invalid . Isso seria útil para mim porque eu poderia usar um único gráfico contendo duas consultas para criar alertas que disparam quando valid 's são muito baixos e invalid 's são muito altos.

Além disso, rastrear estados separados de um alerta nem sempre é preferível (já que o usuário final precisaria saber os detalhes por trás dos estados individuais) em vez de apenas saber se o alerta é acionado.

Não tenho certeza se entendi o que você quer dizer com isso. Você pode elaborar?

Você pode descrever como vários alertas por gráfico funcionariam e ficariam? O que as anotações diriam e o coração verde/vermelho ao lado do título do painel mostra (se, digamos, 2/5 regras de alerta onde disparar)?

Você gostaria de compartilhar algo entre as regras de alerta ou elas seriam completamente isoladas (além de viver no mesmo painel gráfico e possivelmente se referir às mesmas consultas).

Como você visualizaria os limites quando tivesse várias regras de alerta? Eles apareceriam como regras separadas na página de regras de alerta e no painel da lista de alertas? Então você precisa de uma maneira de navegar para uma instância específica de uma regra e não apenas para a guia de alerta.

O Grafana é uma ferramenta visual e optamos por vincular uma regra de alerta a um gráfico para que o estado da regra de alerta possa ser visualizado facilmente (por meio de métricas, limites e histórico de estado de alerta). Receio que cada gráfico seja capaz de representar várias regras de alerta complicar muito isso e não tenho certeza sobre a necessidade disso.

@rssalerno ter suporte para regras de alerta no painel singlestat parece não estar relacionado a esse problema.

@alex-phillips seu cenário parece que pode ser resolvido tornando as regras de alerta individuais mais flexíveis.

Alguém tem alguns exemplos concretos onde isso seria bom? Apenas não ver um cenário em que isso acabaria em um gráfico confuso com 2-5 limites que você não conhece se relaciona a quais anotações de histórico de métrica e alerta que você também não sabe de qual regra de alerta elas vieram (sem passar o mouse).

Você pode descrever como vários alertas por gráfico funcionariam e ficariam? O que as anotações diriam e o coração verde/vermelho ao lado do título do painel mostra (se, digamos, 2/5 regras de alerta onde disparar)?

Acho que várias regras de alerta seriam anotadas individualmente. Corações podem ser codificados por cores. As regras precisariam ser nomeadas para diferenciação em alertas/painéis.

Você gostaria de compartilhar algo entre as regras de alerta ou elas seriam completamente isoladas (além de viver no mesmo painel gráfico e possivelmente se referir às mesmas consultas).

Geralmente, eu acho que não, embora suspeite que os grupos precisariam ter um limite compartilhado e um nome se fossem implementados (por https://github.com/grafana/grafana/issues/6557#issuecomment-324363795).

Como você visualizaria os limites quando tivesse várias regras de alerta? Eles apareceriam como regras separadas na página de regras de alerta e no painel da lista de alertas? Então você precisa de uma maneira de navegar para uma instância específica de uma regra e não apenas para a guia de alerta.

Se as regras usarem um parâmetro de cor adicional, os limites podem ser renderizados usando isso e diferenciados como tal, provavelmente também deseja uma dica de ferramenta. Ser capaz de alternar regras seria útil, e um parâmetro para renderizar uma regra específica cuida do último, eu acho?

@rssalerno ter suporte para regras de alerta no painel singlestat parece não estar relacionado a esse problema.

Acredito que você descobrirá que ele estava se referindo ao gráfico abaixo, embora, como ele possui painéis separados para cada tanque, o alerta de status único possa resolver seu problema para esse painel específico.

Alguém tem alguns exemplos concretos onde isso seria bom? Apenas não ver um cenário em que isso acabaria em um gráfico confuso com 2-5 limites que você não conhece se relaciona a quais anotações de histórico de métrica e alerta que você também não sabe de qual regra de alerta elas vieram (sem passar o mouse).

Principalmente, gostaria que isso suportasse #6557 e #6553 e para vários limites, semelhantes a @alex-phillips. Por exemplo, um caso de uso que temos para #6557 é alertar de forma diferente para ambientes diferentes ( production , beta , dev , etc), combinados com vários limites que resolver a maioria dos nossos problemas. Se há uma maneira melhor de fazer isso sem várias regras, não é óbvio para mim.

@torkelo

Você pode descrever como vários alertas por gráfico funcionariam e ficariam? O que as anotações diriam e o coração verde/vermelho ao lado do título do painel mostra (se, digamos, 2/5 regras de alerta onde disparar)?

Eu gosto da abordagem sugerida por @pdf

Além disso, a abordagem para mostrar anotações seria a mesma do caso atual, em que você tem uma regra de alerta com > 1 condições (cada uma com um limite diferente). E o coração verde/vermelho ao lado do título do painel seria mostrado como vermelho (se houver pelo menos um alerta disparando), semelhante ao cenário atual em que pelo menos uma condição de uma regra de alerta é avaliada como verdadeira). E provavelmente também mostra o número (2/5) junto com o coração vermelho no título.

Você gostaria de compartilhar algo entre as regras de alerta ou elas seriam completamente isoladas (além de viver no mesmo painel gráfico e possivelmente se referir às mesmas consultas).

Na maioria dos nossos casos de uso, essas regras não compartilhariam nada entre elas e as consultas também são diferentes

Como você visualizaria os limites quando tivesse várias regras de alerta? Eles apareceriam como regras separadas na página de regras de alerta e no painel da lista de alertas? Então você precisa de uma maneira de navegar para uma instância específica de uma regra e não apenas para a guia de alerta.

Eles apareceriam como regras separadas na página de alertas. A aba Alerta, provavelmente teria uma lista de alertas definida. Certo, precisaríamos destacar/expandir a regra de alerta específica nesta guia, quando a url da regra alret (deve capturar o ID ou índice do alerta) é acessada a partir da notificação. Parece ser facilmente solucionável.

No painel da lista de alertas, não haveria nenhuma alteração. Ele mostra todos eles separadamente. Semanticamente, cada alerta é separado. Só que ele foi colocado no mesmo painel.

Alguém tem alguns exemplos concretos onde isso seria bom? Apenas não ver um cenário em que isso acabaria em um gráfico confuso com 2-5 limites que você não conhece se relaciona a quais anotações de histórico de métrica e alerta que você também não sabe de qual regra de alerta elas vieram (sem passar o mouse).

Considerando que muitas pessoas votaram nesse recurso, definitivamente seria um recurso útil. Se tivermos suporte para vários alertas, acho que dependeria da percepção de cada usuário se é confuso ou não. IMHO, aqueles que pensam que é confuso iriam com a abordagem atual de painéis separados para cada gráfico e para aqueles que acham que a utilidade/conveniência de ter o mesmo painel usado para visualização e alerta supera a confusão percebida, seguirá o caminho de vários alertas . Claro que mudaria um pouco o UX

No splunk temos alertas altos/baixos. Se vários alertas no grafana estiverem disponíveis, usaremos apenas a mesma pesquisa, eles são apenas limites diferentes na mesma pesquisa.

+1 para este recurso.

+1 para isso. Nosso caso de uso é o seguinte: Queremos definir um gráfico com, digamos, uso de CPU para todos os nossos servidores. Então, nesse mesmo gráfico, faremos duas métricas ocultas, uma para uso de CPU em servidores de produção e outra para uso de CPU em servidores que não são de produção. Cada uma dessas métricas teria seu próprio alerta, com diferentes canais de notificação. Não queremos ter que criar vários gráficos ou painéis ou painéis para fazer isso.

+1 para este recurso.

Vim aqui lendo algumas das outras questões sobre categorias e gravidades. Concordo que todos os alertas devem ser acionáveis. Mas há uma diferença entre um alerta "conserte isso logo pela manhã" e um alerta "chame o consultor de US$ 400/hora o mais rápido possível".

Como muitos mencionaram, isso é mais comum resolvido pelos limites de Aviso e Crítico.

Tecnicamente, isso pode ser implementado de várias maneiras, rótulos, vários alertas por painel, vários limites por alerta etc.

Em relação à confusão se a categorização for muito complexa, uma configuração de Aviso/Crítico pode simplesmente usar Vermelho/Amarelo. Vermelho substitui Amarelo.

Para configurações mais complexas, outra opção além de passar o mouse para localizar a série temporal ofensiva poderia ser uma linha/área/o que for? Isso poderia chamar a atenção para a série temporal correta facilmente.

Eu acho que a maioria dos usuários ficaria satisfeita com uma separação bastante simples de Aviso/Crítico.

Esta é uma necessidade absoluta para um software de alerta, especialmente para monitoramento de servidor. Espaço em disco, memória, uso de CPU, temperatura, carga média... todos os principais exemplos em que se deseja vários alertas configurados com diferentes mensagens com diferentes limites. Tome espaço em disco, por exemplo. Precisa de um alerta para uso de disco acima de 70%, outro para uso de disco acima de 90%.

Um caso meio extremo, mas estamos usando os alertas para nos notificar se um produto não for vendido em alguns dias. Temos cada produto como uma métrica, o que, por sua vez, significa que recebemos apenas um alerta quando uma das métricas entra no limite de alerta. Idealmente, gostaríamos de receber um alerta se o alerta mostrar que alguma métrica adicional também entrou no limite de alerta.

Também estamos usando vars de modelo para repetir um gráfico para cada produto selecionado com duas métricas sobrepostas (volume e margem bruta) nos eixos y esquerdo e direito. Isso elimina qualquer chance de usar alertas, pois a consulta de alerta não está selecionando a variável de lista $sku para nosso IN ($sku) .

Para contornar isso, tentei ter outra consulta B que apenas executa a consulta de modelo para procurar todos os skus nos quais estamos interessados ​​e coloca isso diretamente na consulta de alerta IN (SELECT skus from interested_product_table) . No entanto, isso começa a nos enviar alertas para cada gráfico para todas as métricas em cada gráfico, o que significa que temos:

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

Por exemplo, que é bastante spam.

Concordo plenamente que o recurso é obrigatório e discordo totalmente que TODAS as notificações devem ser acionáveis.

O exemplo mais simples é que você pode ter alertas que você recebe e precisa tomar alguma ação o mais rápido possível, como na manhã seguinte, enquanto existem outros tipos de alertas que devem fazer você acordar mesmo no meio da noite para consertar servidores de produção.

Jogando em meus dois centavos - eu adoraria ter esse recurso.

Eu nem preciso de corações diferentes ou corações de cores diferentes (vermelho para qualquer alerta no gráfico é bom), são as notificações por e-mail que eu quero nomes diferentes.

Por favor, adicione este recurso. para um caso de uso como este,
de um único gráfico
se valor > X --> folga
if Valor > X+Y --> PD

Temos aqui uma política de alertas acionáveis, onde o alerta deve especificar a ação a ser tomada, se possível. Temos ações diferentes a serem tomadas com base em métricas muito baixas ou muito altas.

Por exemplo: CPU RDS muito baixa? verifique a outra pilha aqui para comportamento. Muito alto? Aumente a escala da instância.

Tal como acontece com outros, também gostamos de ter diferentes tipos de alertas em diferentes limites.

Semelhante ao @jdblack , quero ter um nível de alerta de água alta e um nível de emergência de água alta. Eu sei que posso fazer isso com duas consultas, mas não é tão intuitivo ou liso.

Eu estava pensando em usar o Grafana como forma de sinalizar um sistema de autoscaling. Se a métrica for muito baixa, envie um webhook com uma mensagem para reduzir, se for muito alta, envie um webhook com uma mensagem para reduzir. Sem vários alertas, não acredito que isso não seja possível. Também concordo com outros no tópico que o caso de uso para um "aviso" e um limite "crítico" é comum.

Talvez a ideia de acoplar os alertas a um gráfico deva ser revisitada? Talvez os alertas devam ser criados separadamente, com um bom gráfico de visualização ao criar o alerta. Esse desacoplamento pode torná-lo mais trabalhoso ao alterar uma métrica de gráfico, mas pelo menos teria mais flexibilidade ao fazer vários alertas.

Eu tenho tentado usar o Grafana + Influx para redes de sensores. Os painéis funcionam muito bem, exceto pelos alertas. Preciso ser alertado quando o Sensor123 exceder um determinado limite. Eu não preciso de um gráfico para isso, apenas um alerta. Além disso, eu preciso potencialmente ter 1000s de sensores. Posso configurar um alerta se "qualquer" sensor exceder o limite, mas preciso saber qual (is) está (s) em alerta. Tenho painéis configurados com variáveis ​​de modelo para visualizar um sensor específico, mas não consigo adicionar um alerta para uma variável de modelo. Para testar, acabei de configurar um punhado de alertas para um punhado de sensores em um painel extra que ninguém olha, mas, no futuro, preciso de uma solução diferente para alertas.

@torkelo , Aproximando-se de um ano desde qualquer comentário oficial sobre isso - apenas imaginando se existem atualizações que podem ser compartilhadas agora que o sistema de alertas está disponível há algum tempo?

@MakoSDV você deve considerar o uso de kapacitor para esse caso de uso.

+1 para este recurso; seria muito útil também para alertas de dois níveis (por exemplo: algo > X = alerta amarelo, algo > Y = alerta vermelho)

+1 para tornar o alerta mais flexível

eu monitoro gráficos de temperatura em uma caldeira de aquecimento, o limite de baixa temperatura é trivial e precisa ir para um canal de notificação não crítico, mas a alta temperatura é urgente e precisa zumbir pelo canal urgente. Várias regras de alerta fariam muito sentido aqui.

É uma pena que esta questão pareça abandonada. Alguém sabe como podemos chamar a atenção do desenvolvedor para isso?

Parece que em termos de interface do usuário, seria comparativamente fácil implementar alertas da maneira como as substituições são implementadas, para permitir um ou mais alertas sem muitas alterações na interface do usuário.

@Gaibhne escreveu:

Alguém sabe como podemos chamar a atenção do desenvolvedor para isso?

Pagar pelo suporte, talvez? Parece que não há recursos disponíveis para nenhuma das sérias deficiências relacionadas a alertas, embora eles tenham permanecido os maiores problemas classificados pelo usuário do Github por anos.

+1 para esta solicitação.

Temos um contador configurado em nosso aplicativo para quando uma solicitação a um serviço externo que integramos com o tempo limite para o qual criamos um gráfico no Grafana.

Se houver alguns tempos limite que gostaríamos de saber para que possamos perseguir o serviço externo sobre isso mais tarde, se houver muitos tempos limite, significa que nosso aplicativo provavelmente foi afetado para a maioria dos clientes, por isso precisamos responder e lidar com isso imediatamente.

+1 para isso também.

Atualmente tentando configurar dois alertas separados para um gráfico:

1. Mensagem do Slack para dados que atingem um nível de _warning_
2. Alerta de serviço do pager para dados que atingem um nível _crítico_

Atualmente, ao meu entender, eu teria que criar dois gráficos separados dos mesmos dados para conseguir isso. Faria mais sentido para mim ter vários alertas diferentes atuando no mesmo gráfico.

@torkelo há alguma atualização sobre os planos para isso em 2019?

+1

Temos painéis que monitoram os mesmos microsserviços para vários clientes/ambientes usando uma variável para alternar entre o ambiente exibido.

Nossa dor atual poderia ser reduzida se pudéssemos usar variáveis ​​no título/texto do alerta para que possamos identificar o cliente/ambiente, mas a longo prazo, gostaríamos muito da capacidade de criar alertas separados com diferentes limites usando o mesmo gráfico.

Seria ótimo mesmo se fosse necessário usar uma consulta diferente para cada alerta e apenas definir a consulta para não visível no gráfico.

O que você está descrevendo @itonlytakeswon também parece estar relacionado a https://github.com/grafana/grafana/issues/6557 , então você pode querer acompanhar esse também :)

Como isso ainda não é um recurso?

@jsterling7 descreve perfeitamente nosso caso de uso desejado.

@torkelo Qualquer versão de recurso

Vários alertas ou permitir valores de tag no título/corpo do alerta em algum lugar resolveria isso para nosso uso. Temos um único gráfico mostrando uma métrica marcada com várias fontes independentes e queremos saber qual delas está abaixo do limite. Estou agora fazendo os 10 gráficos separados que precisarei para fazer isso, mas parece um recurso ausente e ruim para manutenção a longo prazo do meu lado.

Parece que é alta demanda, sou um deles que precisa desse tipo de recurso. Eu quase amo grafana, mas de repente essa limitação me desanima.

Meu caso de uso é semelhante a outros mencionados aqui e ao problema #6557. Temos vários clusters elasticsearch monitorados em um único painel de modelo. Eu gostaria de acionar alertas para eles individualmente e agora não posso apenas criar um gráfico com as consultas codificadas, mas ter que criar um gráfico para cada cluster, para que esses alertas funcionem ...

+1, isso ajudaria muito nosso meio ambiente! Mesmo apenas uma configuração de dois alertas de 'coração' amarelo/vermelho por gráfico, onde se o vermelho for acionado, ele substituirá o amarelo.

+1 isso seria ótimo, imaginando o quão trivial seria permitir que cada condição tivesse uma notificação de alerta configurável opcional e, se não fosse por uma condição específica, poderia recorrer a uma mensagem de notificação padrão... maneira mais rápida de fazer isso acontecer eu acho que ?

+1 seria muito útil para nós também. Temos muitos painéis com modelagem em várias variáveis, seria ótimo ter a substituição de modelo feita no nome do alerta e na notificação de alerta.

+1, IMO isso deve estar presente em todos os sistemas de monitoramento... existem muitas situações em que você precisa identificar a gravidade do alerta e reagir de acordo, o que significa vários alertas com diferentes limites no mesmo painel.

+1 de mim também - surpreso que isso já não exista!

+1

Eu acho que esse recurso anda de mãos dadas com a limitação do suporte a consultas de modelo.

Configurei alguns gráficos alimentados pelo Prometheus com consultas que possuem modelos na instância e rótulos de tipo. Contorno o problema do modelo criando consultas invisíveis para os valores do modelo.

Gostaria de alertas separados para cada valor de modelo, mas estou limitado a um único alerta com uma ação + mensagem genérica de tamanho único. Eu posso usar uma longa lista OR para alertar sobre todas as minhas consultas, mas isso parece grosseiro.

Uma alternativa é fazer um painel separado com toneladas de painéis que ninguém olha, apenas para servir como fonte de alerta.

Adicionar suporte para vários alertas parece ser o primeiro passo para oferecer suporte a alertas de consulta de modelo.

+1. Este é um deve ter!

+1 Isso é extremamente útil

@torkelo "então faz mais sentido ter painéis separados para os alertas, se você quiser nome e mensagem de regra de alerta diferente, etc."

Isso não faz nenhum sentido. Exigir que os usuários visualizem o mesmo painel várias vezes apenas para que possam enviar mensagens de alerta não genéricas úteis não é uma solução. É um hack para algo que deveria ser um recurso, e adiciona ruídos que degradam a utilidade do produto.

@torkelo "então faz mais sentido ter painéis separados para os alertas, se você quiser nome e mensagem de regra de alerta diferente, etc."

Isso não faz nenhum sentido. Exigir que os usuários visualizem o mesmo painel várias vezes apenas para que possam enviar mensagens de alerta não genéricas úteis não é uma solução. É um hack para algo que deveria ser um recurso, e adiciona ruídos que degradam a utilidade do produto.

Exatamente. +1 para vários alertas por painel

Em nossa situação, estamos medindo tensões de células em baterias (16 células por bateria). Representamos graficamente a série 16 em um único painel para comparação e temos um painel diferente para cada bateria.

Um único alerta para o painel (gráfico) não é muito útil. Realmente precisamos da capacidade de configurar pelo menos um alerta por célula para que o e-mail de alerta indique quais células estão fora do alcance em termos de voltagem.

Como, no nosso caso, a faixa de tensão aceitável é a mesma para cada célula, seria ótimo poder definir um limite superior e inferior e relacionar as faixas de células individuais a esses limites definidos.

No momento, temos que programar 16 x instruções OR para a série de células e (re)-definir os limites para cada célula no processo - difícil de configurar e um pesadelo de manutenção para modificar.

Idealmente, também deveríamos programar alertas e eventos críticos para cada uma das células no painel do gráfico.

Acho que está na hora de a estrutura de alertas ser modificada para abranger os requisitos que os usuários identificaram. Esses requisitos são comumente implementados em sistemas SCADA que também geram alertas. É realmente apenas um mecanismo lógico, certo?

alguma atualização disso? Eu sinto que esse recurso é obrigatório para implantações maiores. Especialmente porque gostaríamos de ter um único gráfico, por exemplo, mostrando o uso de armazenamento, queremos um alerta para 70%, 80% etc etc, o que não deve ser uma grande quantidade de gráficos.

Acabei de me deparar com isso e estou muito surpreso que não há como fazer isso ainda D:

Vejo aqui https://github.com/grafana/grafana/pull/20822#issuecomment -561047900 que isso não será implementado no futuro e parece que os alertas serão retirados inteiramente dos painéis.

Como isso afetará o modelo json do painel? Alguém pode falar quando haverá mais notícias sobre isso?

Este era um recurso muito necessário. Alguma atualização sobre a próxima situação ainda?

+1 para vários alertas por painel

+1 para este recurso.

Este era um recurso muito necessário. Alguma atualização sobre a próxima situação ainda?

Precisa desse recurso.

3 anos depois.. Alguém pode nos dizer por que isso não é implementado (apesar do número de solicitações)?
É devido a uma restrição técnica para implementá-lo? É rejeitado? Está em afazeres?
Como dito anteriormente, parece um 'recurso básico'.
Exemplo: tenho um dashboard e uma série com 200 servidores, se eu adicionar um alerta:
Um dos 200 servidores está morto: legal recebo o alerta com nome
Ops, um novo servidor está morto: sem alerta (ou precisa atualizar o painel ou esperar o lembrete 24h depois..)
Não é possível adicionar como uma caixa de seleção para marcar para que possamos ser alertados por linha na série (em vez da série 'completa')?
Se alguém da equipe dev, grafana puder responder por um feedback...

Você se importaria de experimentar o prometheus para alertar e deixar o grafana para fazer dashboards?

@beastea Se você precisa configurar outra ferramenta apenas para fazer o Grafana funcionar, não faz sentido usar o Grafana. Estamos migrando para o Datadog porque essa funcionalidade existe lá e é apenas uma ferramenta.

@anne-nelson você tem que configurar o coletor de métricas, armazenamento de métricas e para a configuração adequada ter um jogo com HA em torno dele para fazer o Grafana funcionar, certo?
Datadog não é apenas uma ferramenta, apenas esconde de você e faz um bom trabalho, também, você ainda pode usar grafana com datadog: https://grafana.com/grafana/plugins/grafana-datadog-datasource

@beastea Não tenho certeza de quais são essas ferramentas, então não acho que as estamos usando. Nossas métricas são enviadas para o Influx, vamos enviá-las apenas para o Datadog em vez do Grafana. Por que eu enviaria coisas para o Datadog via Grafana quando posso enviá-las diretamente? Eu quero usar o menor número possível de ferramentas.

@anne-nelson você pode implementar o push de métricas em seu aplicativo, mas às vezes isso é muito útil para que algumas das métricas do sistema sejam enviadas também para que você possa saber o que está acontecendo com seus discos e outras coisas. Isso é o que quero dizer com coletor de métricas, algum daemon local que faz essas coisas, como telegraf, collectd ou fluted.
Influxo em sua configuração - é uma coisa que armazena métricas e oferece uma rica capacidade de fazer pesquisas via grafana como um frontend de interface do usuário da web para os dados brutos que lhe dão uma chance usando alguma linguagem de consulta de influxo interna para manipular seus dados.
No caso de ter Datadog em vez de Influx, funciona exatamente da mesma forma. Grafana aqui -é uma interface do usuário para acesso aos dados. Em uma configuração geral. Portanto, ele não faz nada com seus dados, apenas os apresenta em gráficos. Então você de qualquer maneira enviá-los diretamente.
Caso, como você descreveu, você esteja trabalhando com inlux, por que não é considerado o uso de kapacitor ou fluxo para resolver o problema que você descreveu, pois eles fornecem muitos recursos de alcance, o grafana pode oferecer a você e eles ainda são do mesmo fornecedor e gostam do mesmo ambiente. O fluxo é até mesmo uma parte do pacote de envio de influxo.

Será realmente útil.

@beastea então provavelmente é melhor remover o recurso 'alertas' no grafana e migrar as pessoas para outra ferramenta (para evitar uma fábrica de gaz de várias ferramentas)?
Quer dizer, ok, podemos usar kapacitor, prometheus, etc. Mas o recurso de alerta já existe no Grafana, então não faz sentido no meu caso.

Btw, o que é impedir adicionar esta caixa de seleção para ter alerta por linha? Provavelmente uma explicação pode ajudar a entender.

@beastea Parece muito estranho que você esteja tentando convencer alguém a não usar o Grafana.

Como anthosz apontou, desde que o alerta seja um recurso do Grafana, é razoável esperar a capacidade de adicionar vários alertas a um gráfico. Se você acha que não devemos usar o Grafana para alertas, o Grafana não deveria ter alertas como um recurso. É claro que muitas pessoas querem esse recurso e que muitos produtos concorrentes já o oferecem. Sinceramente, não entendo por que há tanta resistência a isso.

@anne-nelson Não estou tentando convencer ninguém a não fazer o que eles gostariam de fazer. Estou tentando dar um conselho para dar uma olhada na direção diferente que já pode te oferecer uma solução hoje.
Não estou ditando o que você deve usar para quê, estou oferecendo uma alternativa que pode lhe dar uma solução ainda hoje. Eu não estou empurrando de volta, eu estou dando-lhe um conselho. Se você acha que meu conselho não é útil, então é uma pena, mas é isso. Lamento que você esteja sentindo que estou incomodando você e que sou muito insistente com meus conselhos.
Divirta-se.

@beastea Eu presumi, devido à sua defesa, que você trabalhava para a Grafana. Esse recurso é relevante para muitas pessoas, e sugerir produtos alternativos em uma solicitação de recurso não ajuda e atrapalha essa discussão. Isso não é stackoverflow.

Todo mundo pode simplesmente derrubá-lo? Você está enviando spam para centenas de pessoas, isso não é produtivo.

Desculpem o ruído adicional todos.

@torkelo você se importaria de nos dar uma atualização sobre essa solicitação de recurso? Este tópico está aberto há vários _anos_ e como você pode ver ainda tem interesse. No mínimo, pode ajudar a reduzir as disputas e conversas desnecessárias sobre este tópico para obter algum tipo de resposta "oficial" sobre se isso está incluído ou não no roteiro atual. Felicidades.

Este e #6041 que é semelhante são completamente ignorados. Eu quero saber porque.

Para nós faz sentido, pois nossa equipe de operações registra novas integrações em nossa plataforma. Começamos automaticamente a enviar métricas para o grafite. E apenas um painel em grafana assiste a tudo isso.

Quando vários sistemas ficam inativos, recebemos apenas o alerta para o primeiro. E também não muito explicativo.

Quando um está inoperante, e um segundo também se apaga, o alerta não dispara novamente.

O caso de uso que tenho para isso é para definir alertas de taxa de queima múltipla de várias janelas via prometheus e grafana. Esta é uma prática padrão ter alertas desse tipo para monitoramento de SLOs, conforme definido no manual do Google SRE em https://landing.google.com/sre/workbook/chapters/alerting-on-slos/

Uma necessidade absoluta, por favor, acompanhe isso ..

Eu também mudei do alerta do Prometheus para o alerta do Grafana e estou absolutamente ansioso por isso!

Alguém que já trabalhou no Grafana pode listar os desafios conhecidos para lidar com isso?

Ei @torkelo , talvez você possa nos esclarecer sobre esse assunto!

Decepcionante ver que o 7.x não teve nenhuma melhoria no alerta - a sugestão anterior de que o alerta deveria ser removido completamente não me enche de esperança, mas se esse fosse o caso, certamente removê-lo no 7.x teria sido lógica dada a escala da reformulação?

Seria ótimo receber algum tipo de atualização sobre por que isso é tão difícil de implementar, apenas para que possamos entender _por que_ esse problema está em aberto há tanto tempo.

@torkelo Olá.
Eu tenho a mesma necessidade - vários alertas para uma única métrica em um único graf, mas com vários servidores sendo monitorados.
Eu tenho ~ 100 servidores com métrica definida de espaço livre na partição '/' (por exemplo - pois tenho dezenas dessas métricas). E preciso receber uma notificação de alerta única e exclusiva em CADA servidor se o espaço livre em '/' for inferior a 20%.
Atualmente isso não acontecerá, se, por exemplo, o server2 lançar um alerta, e enquanto os caras estiverem trabalhando para resolver o problema, o server4 lançará o mesmo alerta - não seremos notificados. Ou estou perdendo alguma funcionalidade?

A forma de multiplicação de painéis por servidor por métrica não é o caminho.
Alguém poderia me dar uma dica, como tornar isso possível?
Devo atualizar meu Grafana (a versão atual é 6.3.5)? Adicionar algumas extensões? Plug-ins? Algo mais?

Agradeço e agradeço a todos que puderem aconselhar ou ajudar.

@torkelo Olá.
Eu tenho a mesma necessidade - vários alertas para uma única métrica em um único graf, mas com vários servidores sendo monitorados.
Eu tenho ~ 100 servidores com métrica definida de espaço livre na partição '/' (por exemplo - pois tenho dezenas dessas métricas). E preciso receber uma notificação de alerta única e exclusiva em CADA servidor se o espaço livre em '/' for inferior a 20%.
Atualmente isso não acontecerá, se, por exemplo, o server2 lançar um alerta, e enquanto os caras estiverem trabalhando para resolver o problema, o server4 lançará o mesmo alerta - não seremos notificados. Ou estou perdendo alguma funcionalidade?

A forma de multiplicação de painéis por servidor por métrica não é o caminho.
Alguém poderia me dar uma dica, como tornar isso possível?
Devo atualizar meu Grafana (a versão atual é 6.3.5)? Adicionar algumas extensões? Plug-ins? Algo mais?

Agradeço e agradeço a todos que puderem aconselhar ou ajudar.

Esta edição está aberta desde 2017 (E a ​​resposta do @torkelo é 🤡 "faz mais sentido ter painéis separados para os alertas" 🤡 (muito legal criar um painel por servidor/alerta quando temos 600 servidores) 🤡).

Parece que o único jeito é migrar do Grafana para outra solução ou criar uma fábrica de gaz com várias ferramentas para manter.

@anthosz - muito obrigado. A questão é o fato do ambiente não ser nosso, mas dos clientes, então seria uma tarefa muito difícil para mim insistir nisso para o meu lead e para ele superar o "não vai pagar por isso" dos clientes .
No entanto, pelo menos tenho alguns fatos dizendo 'não há possibilidade de organizar tais acionadores/alarmes - desta forma'.

Obrigado novamente.

_juntar(voz, coro)_
Eu tenho um sensor de corrente em um circuito monitorando uma bomba de ar, 1,5 Amps nominal e uma bomba de efluente 10Amps nominal. A bomba de ar funciona 24 horas por dia, 7 dias por semana, a bomba de efluentes funciona sob demanda com base nos níveis do tanque. Quando tudo está ok, a corrente (I) é 1,5A quando a bomba de efluentes está desligada ou 11,5A quando a bomba de efluentes está ligada.

A primeira falha comum é a queima da bomba de ar, que é alertada por (Imax < 0,5A ou Iavg entre 9A a 11A), que detecta nenhuma corrente ou a bomba de efluente funcionando quando a bomba de ar morreu. Isso deve ser resolvido dentro de 48h para evitar falhas no sistema. Os dados são de 1 ponto por minuto, alertas após 90 minutos.

O segundo alerta desejado no mesmo gráfico é (Imax > 14A ou Iavg entre 2A a 9A) que indica bomba de efluente entupida ou com ar em linha quando deveria estar bombeando. Este é um alerta muito mais urgente que pode precisar ser abordado dentro de 3 horas, portanto, alerta após 5 minutos seria o ideal.

Ambos os alertas são do mesmo sensor remoto de corrente enviando dados por LoRa. Vários alertas simplificariam e evitariam que eu duplicasse uma consulta de painel para o mesmo sensor.

Os gráficos múltiplos do @torkelo simplesmente não são escaláveis ​​para muitos usuários. Isso parece uma coisa tão simples de adicionar e estou curioso por que vocês não estão considerando isso?

talvez se houver uma grande demanda por isso :)

Ei @torkelo , o que você considera uma grande demanda? 96 comentários e 250 "curtidas" no seu comentário é enorme? É a 8ª solicitação de recurso aberto mais comentada e apenas uma solicitação de recurso fechado tem mais comentários do que isso. É também o 3º pedido de recurso aberto com mais :+1: reações. O que é necessário para entrar no roteiro?

@torkelo Eu tenho um cenário de caso muito simples.

Eu preciso de um alerta diferente se o valor ficar abaixo do limite, do que o alerta para quando o valor ultrapassar um limite (diferente).

Aqui está um cenário diferente. Quando monitoro a contagem de servidores íntegros, preciso de alertas diferentes quando perco 1 servidor (reinicialização legítima que não é um problema, a menos que leve mais de 10 minites), versus perder 5 servidores.

Aqui está mais um cenário. Gostaria de definir um alerta diferente se a taxa de aumento em uma fila estiver acima de um limite e um alerta diferente se o próprio tamanho da fila ultrapassar um limite.

Em termos de visualização, acredito que a comunidade ficaria feliz com qualquer solução para começar. por exemplo, visualize apenas o primeiro alerta (portanto, não são necessárias alterações na interface do usuário). Visualize todos os alertas com linhas verticais que, ao passar o mouse, informam qual alerta foi acionado. Apenas mostre limites/alertas quando você passar o mouse sobre uma série específica, etc.

Apenas meus 2 centavos.

Olá!

Queria falar aqui que nós (Spotify) precisamos disso também.

Atualmente, executamos nossos próprios alertas de origem do mecanismo de alerta do Grafana e alertas por série temporal. Atualmente, enviamos as anotações de alerta por série temporal de volta ao grafana.

Assim, em termos de interface do usuário, a primeira série temporal a alertar faz com que o painel/alerta entre no estado "Alertando", e cada alerta subsequente apenas se acumula (o histórico de estado mostrará várias atualizações "para" alertando e, da mesma forma, várias alterações voltar para "ok")

Nós "precisamos" disso, pois é assim que sempre fizemos alertas, portanto, afastar-se dos alertas por série temporal seria uma grande mudança social, para alertas de ~ 10 mil. Gostaríamos muito de usar e adotar o alerta nativo do Grafana e atualizar nossa fonte de dados para suportá-lo.

Queria falar aqui que nós (Spotify) precisamos disso também.

Você também usou a empresa Grafana? Talvez possa ajudar/motivar os desenvolvedores =)

Gostaríamos também de ver esse recurso, a capacidade de acionar vários alertas do mesmo gráfico. Dar a capacidade de acionar em um estado "abaixo" e "acima" e ter a possibilidade de ter o que seria efetivamente um aviso âmbar antes de uma violação de limite mais importante

Atualmente, executamos nossos próprios alertas de origem do mecanismo de alerta do Grafana e alertas por série temporal. Atualmente, enviamos as anotações de alerta por série temporal de volta ao grafana.

@sjoeboo um pouco fora do tópico aqui, mas há algo disponível publicamente?

@vbichov ainda não , queremos abrir o código do mecanismo de alerta, embora o prazo esteja em fluxo. tenho certeza de que poderia compartilhar um patch que temos em nosso fork interno (dificilmente ideal) para permitir o rastreamento de alertas por série de tempo por meio de anotações.

uma nota, o mecanismo de alerta, agora, é específico para o nosso TSDB (https://github.com/spotify/heroic)

+1 para este recurso. isso é algo como um aviso/crítico. Queremos receber um aviso antes que a vida esteja piorando. Então devemos receber alertas críticos para tomar medidas imediatas.

Estou surpreso que isso não tenha sido implementado após 3 anos de solicitações dos usuários.

Ter que criar vários painéis (um para cada alerta) acaba entupindo um painel e torna a adição de novos alertas muito mais complicada do que deveria ser

Eu sempre me pergunto por que há um 1 mostrado na guia de alertas se você não pode definir mais de um alerta por painel. Na aba de consultas este número também mostra o número de consultas definidas. Então eu sempre pensei que isso seria possível e estou bastante surpreso que isso ainda não esteja disponível.

Interessante que isso ainda não foi implementado. Concordo que a "contagem" na guia de alerta é enganosa, pois leva a acreditar que pode haver vários. Além disso, ter um painel por regra de alerta é um pouco ridículo, pois isso significa que tenho um painel "inútil" que nada mais é do que painéis para alertas. É um painel bagunçado, com certeza, mas é a única maneira de implementar isso. Principalmente, é para que eu possa ter regras diferentes para nomes e/ou combinação de endpoints de notificação. É complicado para dizer o mínimo.

Isso foi feito?
Versão Grafana = 4.x

Agora a versão do Grafana vai para 7.xe não vi esse recurso

Isso foi feito?
Versão Grafana = 4.x

Agora a versão do Grafana vai para 7.xe não vi esse recurso

Tão ingênuo😁

+1 para este recurso.
Em uma única métrica eu gostaria

1. Um alerta de aviso para indicar que um componente não está se comportando conforme o esperado e precisa de monitoramento próximo pelo suporte de 2ª linha
2. Um alerta de erro para indicar que um componente está falhando e acionar chamadas para a engenharia de 3ª linha.
   Duplicar a métrica é desajeitado e torna nossos painéis confusos para monitoramento.

Tantos recursos simples são constantemente negados por este grupo, verifique os muitos outros pedidos de recursos... isso parece algo básico.

Vou dar outro exemplo.

Eu corro uma sinologia e gostaria de alertar sobre isso. Raid Status tem um valor normal de 1. No entanto, também tem um valor Degraded de 11 e um valor de Crashed de 12. Degraded significa que os dados ainda estão acessíveis. Crashed significa alta chance de perda de dados.

Quero enviar um aviso se o Raid for Degradado e um alarme crítico se o Raid for Crashed.
Eu tenho vários volumes e pools de armazenamento e exigir vários gráficos para cada um não é escalável.

Isso também pode ser aplicado a algo tão simples quanto o uso do espaço em disco.
Desejo enviar um aviso se o uso do disco atingir 80% e um alarme crítico se o uso do disco atingir 90%. Fazer vários gráficos para CADA um dos meus discos não é uma pergunta razoável.

E não entendo o comentário de que isso é difícil na interface do usuário. Você já tem algo semelhante que é uma lista de Dashboards. Quando você clica na guia Alerta, ela deve mostrar uma lista de regras de alerta por nome com um botão "Criar novo alerta" na parte inferior. Cada regra de alerta deve ter uma opção "editar", "desativar" ou "excluir" à direita. Ao clicar no alerta ou no botão de edição, você deve ser direcionado para a página de edição existente que é mostrada, mas para essa regra de alerta específica.

Fazer vários gráficos para CADA um dos meus discos não é uma pergunta razoável.

Você pode usar a API para automatizar a criação/atualização de painéis e seus alertas. Se você quiser, pode criar um programa que consulte o prometheus (ou qualquer fonte que você tenha) executando consultas periodicamente para obter um serviço de descoberta de destinos e criar alertas automaticamente para eles.

Incrível que esse recurso ainda não tenha sido implementado, com o enorme feedback que esse problema tem.

Eu uso o Grafana como nosso mecanismo de visualização e alertas nos Telescópios Magellan. Se eu tiver vários subsistemas que compartilham características que merecem que eles estejam todos em 1 lote, quando surge um problema e um começa a se comportar mal, meus usuários precisam receber um aviso enigmático e cavar que está falhando.

Criar gráficos fictícios é uma solução alternativa, não uma solução. Isso parece básico!

+1 recurso necessário

+1

Exatamente a mesma situação do OP. Recurso básico que já deveria ter sido implementado.

As pessoas podem parar de enviar spam para este tópico sem adicionar nada de valor?.

Use as reações na parte superior da edição para sinalizar interesse.

https://github.com/grafana/grafana/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc é infinitamente mais útil para um mantenedor afirmar quais problemas são "populares" do que pessoas enviando spam todos enviam e-mails e notificações do github com informações que já estão claras apenas olhando a descrição do problema.

Se é tão básico, talvez alguém de todos os reclamantes que apenas espera que outras pessoas trabalhem de graça para eles deve implementar isso sozinho e fazer um pull request ou manter seu próprio fork se os mantenedores não quiserem no upstream.

@thomasf "As pessoas podem parar de enviar spam para este tópico sem adicionar nada de valor?" - Assim como você fez?

Se os mantenedores ainda estiverem no tópico, novos comentários pelo menos os lembrarão disso. Neste ponto, parece meio inútil, não há como os mantenedores implementá-lo depois de tanto tempo e as pessoas realmente deveriam mudar para ferramentas melhores como o Datadog, onde os mantenedores realmente se importam, mas centenas de comentários (particularmente quando eles têm cenários reais ) tem muito mais impacto do que apenas um polegar para cima.

Se os mantenedores ainda estiverem no tópico, novos comentários pelo menos os lembrarão disso. Neste ponto, parece meio inútil, não há como os mantenedores implementá-lo depois de tanto tempo e as pessoas realmente deveriam mudar para ferramentas melhores como o Datadog, onde os mantenedores realmente se importam, mas centenas de comentários (particularmente quando eles têm cenários reais ) tem muito mais impacto do que apenas um polegar para cima.

Ou talvez os mantenedores tenham cancelado a notificação sobre este problema por causa do spam, que não é o único com muitos +1/mensagem sem atualização. Por favor, não compare Grafana e DataDog (nós éramos usuários de ambos, não há como voltar ao DataDog)

A melhor maneira de conseguir isso é contribuir (ou provavelmente pagar pela Grafana Entreprise)

Você está muito muito errado. Gratuito ou não você não pode colocar um
forum/slack/github/feedback channel e ignore-o. Se você acha que
colocar um software em licença de código aberto significa "sem reclamações" e "as pessoas
irá desenvolver para seus recursos gratuitamente" você está novamente muito, muito errado.
meu caso eu expliquei a eles que com esses recursos eu posso vender grafana a dez
clientes meus. O me ignorou, significa que está chateado com um cliente. Excelente
mover provavelmente eles fazem dinheiro "suficiente" e eles não querem mais, estou feliz
para eles....

Dia 14 de outubro de 2020 todas as 15:35 Thomas Frössman <
[email protected]> tem script:

As pessoas podem parar de enviar spam para este tópico sem adicionar nada de
valor?.

Use as reações na parte superior da edição para sinalizar interesse.

Se é tão básico, talvez alguém de todos os reclamantes que apenas espera
outras pessoas para fazer o trabalho de graça para eles devem implementar isso por conta própria
e fazer um pull request ou manter seu próprio fork se o
os mantenedores não querem isso no upstream.

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/grafana/grafana/issues/7832#issuecomment-708406018 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AABBIFUYLMIO4WH7LBYQ6FTSKWSLXANCNFSM4DDVAQPQ
.

A quantidade de dinheiro que estou disposto a gastar em _qualquer_ software é diretamente proporcional ao nível de atendimento ao cliente que posso antecipar que será fornecido pelo meu investimento. Seja um produto de código aberto que oferece "suporte pago" ou um produto comercial, isso realmente não importa.

Ter esse problema em aberto por tanto tempo sem um pio dos mantenedores do projeto, infelizmente, extrapola para um sentimento razoável de dúvida sobre se algo seria diferente gastando dinheiro. Se você está tentando vender software, provavelmente é aconselhável considerar isso.

fazer um pull request ou manter seu próprio fork

Se houvesse uma dica dos desenvolvedores sobre por onde começar, tenho certeza de que não estou sozinho em dizer que consideraria isso, independentemente de achar que deveria ou não, simplesmente devido à enorme quantidade de valor que seria providenciar. Infelizmente, esse não parece ser o caso e tenho pouco interesse em tentar fazer engenharia reversa do produto para um recurso com o qual os mantenedores parecem não se importar.

Por fim, a menos que o tópico esteja fechado/bloqueado, não vejo razão para alguém não falar o que pensa. Você tem permissão para cancelar a inscrição se isso não combina com você. Na verdade, gosto de ler as pessoas lamentando o relativo absurdo disso. 😁

Alerta O alerta NG (NextGen) planejado para 8 oferecerá suporte a várias instâncias de alerta a partir de uma única definição de alerta. Então, algo como host=* com um sistema como o prometheus criará alertas por host.

Algumas informações gerais sobre isso no contexto de estatísticas únicas adicionadas a https://github.com/grafana/grafana/issues/6983#issuecomment -712915673

Ainda estamos projetando e prototipando, mas para responder a alguns pensamentos iniciais sobre as coisas:

Vários alertas por gráfico

A definição de alertas serão suas próprias entidades, portanto, não serão vinculadas a um painel. De definições de alerta podem se tornar várias instâncias de alerta. Em seguida, um painel pode assinar instâncias ou definições. Imagino que ainda vamos querer um bom caminho de UX do painel Dashboard para criar alertas, porque esse é um bom fluxo.

Além disso, rastrear estados separados de um alerta nem sempre é preferível (já que o usuário final precisaria saber os detalhes por trás dos estados individuais) em vez de apenas saber se o alerta é acionado.

Uma vez que muitos alertas de uma definição são permitidos, então como eles devem ser agrupados se torna um problema (já que é possível obter muitos alertas). Atualmente, vejo dois caminhos de como isso funcionaria com o Alerting NG:

1. Use NG de alerta com um IRM como pagerduty ou alertmanager que pode manipular o agrupamento de instâncias de alerta.
2. Altere sua consulta para agrupar por uma dimensão de escopo maior. Então, por exemplo, se consultar cluster=* em vez de host=*,cluster=* (ou agrupar por fontes de dados como sql). Como alternativa, pretendo adicionar funcionalidade às expressões do lado do servidor (com alerta ng) para permitir operações de grupo/por pivô se a fonte de dados não fizer isso. Esse seria o caso ao não usar um IRM e enviar diretamente para serviços como email/slack.

aviso/crítico

Este é mais complicado. Para o design WIP, eu o removi como um recurso (pelo menos para uma definição de alerta, talvez tenha uma maneira de duplicar a definição de alerta, alterá-la e, de alguma forma, rotulá-la/etiquetá-la com gravidade)

Isso é difícil, porque em muitos casos, é muito útil:

• Para mim, aviso/crítico tem usos claros: aproximando-se de quebrado/quebrado, ou degradado/quebrado.
• Sem eles, muitas configurações acabarão repetindo uma quantidade razoável de alertas para diferentes níveis de gravidade.

Então, por que decidir não tê-los? Ele adiciona um pouco de complexidade não óbvia:

• Supondo que você queira dar suporte aos seus limites provenientes de outra métrica (ou que seus limites sejam diferentes intervalos de tempo de consulta, não valores), agora há duas condições a serem executadas.
• Para os estados de instâncias de alerta, no mínimo, quero oferecer suporte:
  
  
  
  • Desconhecido: uma instância desapareceu
  
  
  • Erro: a consulta que teria descoberto que há um problema sobre as instâncias está quebrada
  
  
  • Alerta: A condição é verdadeira
  
  
  • Normal. A condição não é verdadeira
  
  
• Também queremos continuar a ter expressões semelhantes para FOR. Ao adicionar mais estados, o design para não ter oscilações resulta em notificações perdidas ou ruído é complicado. Em geral, as máquinas de estado ao longo do tempo são muito propensas a bugs e são difíceis de acertar (procure TLA / Lógica Temporal de ações para saber mais se você gosta desse tipo de coisa). Portanto, adicionar níveis de gravidade aumenta o espaço de estado mais do que se poderia imaginar. O que significa que é mais provável que tenhamos comportamentos não intencionais, ou comportamentos para os quais é mais difícil ter um modelo mental.
• Ao procurar a integração com outro sistema ou IRMs, ter noções específicas sobre gravidade pode complicar a integração.

(pelo menos para uma definição de alerta, talvez tenha uma maneira de duplicar a definição de alerta, alterá-la e, de alguma forma, rotulá-la/etiquetá-la com gravidade

Esta é uma solução perfeitamente aceitável para a diferenciação crítica/aviso. Estou mais do que feliz em manter limites separados. Ter um limite combinado de aviso/crítico seria bom, mas não é um problema.

então como eles devem ser agrupados se torna um problema (já que se pode obter muitos alertas)

Cabe ao usuário gerenciar seu próprio volume de tickets e geração de alarmes. Se você estiver configurando alarmes, cada um deve ser um e-mail ou notificação separada. Pense dessa maneira, se você criar um sistema automatizado para gerar tickets com base no disparo de alarmes, agrupar vários alarmes em um e-mail, por exemplo, tornaria isso difícil ou apenas desagradável. Além disso, vários alarmes aparecendo em um e-mail significa que cada alarme não pode ter seu próprio encadeamento de e-mail, ele precisaria ser separado manualmente pelos usuários e novos encadeamentos iniciados. Em vez disso, cada disparo de alarme deve ter sua própria notificação para que os encadeamentos possam ser contidos nesse alarme específico.

Espero que isso simplifique o design alarmante, pois você não deve se preocupar com o agrupamento. Isso fica a critério do usuário.