Grafana: Suporte a alertas para consultas usando variáveis ​​de modelo

+1

1. Qual seria a diferença em relação a usar apenas todos?

+1
Seria bom poder adicionar alertas no servidor com um tempo de vida baixo (escalonamento automático da AWS), registrar automaticamente o servidor no grafana é fácil com o modelo, mas é triste não poder colocar alertas neles

@bergquist é impraticável usar todos, por exemplo, quando você tem mais de uma dúzia de hosts.

Se, por exemplo, apenas alguns deles estiverem falhando (digamos 5), é muito útil receber um email para cada alerta de falha. Desta forma também é muito mais fácil integrar com outras ferramentas que em geral esperam um alerta por métrica.

A abordagem atual (usando todos) é bem legal quando há menos instâncias ou quando você está alertando no nível de serviço (por exemplo, número de trabalhos na fila).

o que @calind disse, eu tenho várias variáveis ​​$ host que estão funcionando bem com o influxDB, mas não com os alertas

+1 também.

Apenas um pensamento, já que você pode consultar com uma variável de modelo, você não seria capaz de fazer a mesma consulta com as métricas de alerta e talvez iterar pelos resultados para ver quais atendem aos critérios de alerta?

@NotSoCleverLogin Seria possível. Mas você gostaria de alterar o comportamento da regra de alerta com base em qual valor de modelo é selecionado?

Usar a opção all para o modelo é a única maneira que faz sentido para mim.

+1

Eu tenho uma configuração de ambientes X com os mesmos componentes em cada ambiente. No momento, estamos usando o prometheus para alertar sobre, por exemplo, uso de CPU/uso de disco, etc. Lá, especificamos um alerta para uma consulta e, quando o alerta é acionado, ele informa apenas de qual ambiente o alerta foi acionado.

Se fizéssemos isso com a variável All, isso funcionaria até certo ponto. Mas, usando o exemplo do @calind , a captura de tela seria preenchida com a tendência de todas as cpus de todos os meus ambientes, e não apenas do ambiente em que eu gostaria de ser informado sobre o referido problema. O gráfico será (ou poderá) ser obscurecido com informações de outros ambientes. Em alguns cenários pode ser interessante comparar cpu em outros ambientes, mas não há garantias de que o que está acontecendo em um ambiente de teste esteja acontecendo em nosso ambiente de produção, etc.

Também estamos analisando a criação de painéis que podem ser usados ​​pelas operações, mostrando anotações para alertas no painel de visão geral "padrão". Dado que usamos variáveis ​​de modelo 'env' para esses tipos de painéis, não é realmente possível fazer isso com a forma como ele está implementado no momento. Eu teria que gerar manualmente (pelo menos até certo ponto) um painel de "sombra" onde os alertas são acionados (o que me faz perder as anotações no painel de visão geral).

Outra coisa que acho que as variáveis ​​de modelo podem ajudá-lo a fazer é rotear os alertas (se você optar por implementar esse recurso) para fontes diferentes (algumas para operações se estiverem em produção, para qa/desenvolvedores se estiverem em ambientes de teste etc).

+1 para alertas de suporte em consultas de modelo.

@bergquist , alguns painéis não têm a opção _All_. Por exemplo, métricas do sistema por collectd (https://grafana.net/dashboards/24). Ter uma opção _All_ certamente não seria prático para, digamos, 10 ou mais servidores. É por isso que a necessidade de iterar através de variáveis ​​de template.

Permitir o uso de Todos é um começo bom e bem-vindo.

No Prometheus, as consultas precisam ser escritas de uma maneira diferente para permitir que Todos:

some.metric{hostname=~"$Hostname"}

Observe o til extra lá, permitindo a pesquisa de expressões regulares (e o curinga em Todos).

Eu não avaliei o possível impacto no desempenho de passar de uma consulta direta para uma consulta de pesquisa regex, mas pelo menos por enquanto isso aparentemente resolveria nossos problemas.

+1

+1

não tenho certeza de como deve ser implementado, apenas sei que é necessário ..

+1
Usamos o Prometheus como a fonte de dados para monitorar nossa infraestrutura Kubernetes para nossos clusters K8S no local e nossos clusters AWS K8S.
Todos os nossos painéis usam variáveis ​​de modelo para a fonte de dados ($Environment), $Instance/Node, $Namespace e $Pod.
Devido à forma como é a Estrutura de Consulta do Prometheus; todas as consultas têm variáveis ​​de modelo; que impede que as Regras de Alerta permitam salvar.
Eu adoraria ver as consultas de variável de modelo adicionadas ao alerting.

+1

+1
Usamos painéis de modelagem para ambiente multi-servidor, que é o caminho lógico (e muitas pessoas usam), então não podemos usar alertas com grafana agora. A única maneira é ter um painel separado sem modelos ou configurar alertas com o próprio prometheus, o que não é fácil.

talvez se houvesse uma opção ou uma maneira simples de salvar/exportar um painel com as variáveis ​​do modelo apoiadas/pré-renderizadas em todos os campos... isso talvez fosse um bom meio caminho até que outra solução fosse encontrada.

+1 para alertas de suporte em consultas de modelo. Atualmente, usamos modelos em todos os nossos painéis, portanto, não podemos aproveitar esse recurso muito legal.

+1, temos muitos painéis de modelo e não podemos usar alertas por enquanto, temos que desduplicar painéis para ter alertas e perdemos o poder de modelo

+1, Quase todos os nossos painéis usam variáveis ​​de modelo (e variáveis ​​de modelo aninhadas).

Gostaríamos de poder definir alertas em painéis repetidos para obter alertas individuais por grupo de variável de modelo, se necessário. Além disso, isso significa que o alerta é dinâmico e não super manual como é agora.

PERIGO: As variáveis ​​em teoria serão boas de se ter, mas precisamos ter em mente que se algum cara entrar no seu painel e alterar o valor e salvar, o alerta resultante será afetado. Não sei se isso é comportamento ok ou não, vai ser complicado.

+1

Ao trabalhar com grafana, parece que a modelagem é incentivada em todos os lugares e parece errado criar um conjunto extra de gráficos sem usar variáveis ​​apenas para usar o recurso de alerta ...

+1 para alertas de suporte em consultas de modelo.
Além disso, descobrimos que, quando usamos o nome da regra em chinês ou o título em chinês, recebemos e-mails anormais com a regra acionada. Por exemplo, esperávamos "个股分时线接口请求时间(getTimeTrend) alert", mas recebemos "ä¸ªè‚¡åˆ†æ—¶çº¿æŽ¥å £è¯·æ±‚æ—¶é—´( getTimeTrend) alert", talvez o charset não esteja correto.

+1 para implementar vars modeladas em alertas

+1

+1 seria uma ótima adição

+1

+1 para implementar vars modeladas em alertas

+1

+1 ansioso por isso

+1

+1

+1

+1

Por favor, pare de escrever +1 !
Todos que se inscreveram nesta edição receberão um e-mail...

Existe um recurso do github apenas para se livrar desses comentários +1 :
https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments

@thetechnick Existe um link no e-mail onde você pode silenciar o tópico e não receber nenhum e-mail. Mas entendo que você queira apenas ser notificado quando o recurso estiver concluído, mas também gosto de resolver o problema para que ele seja resolvido mais cedo :)

Grande progresso no alerta geral.
Para as variáveis ​​de modelo em alertas, também estou perdendo. +1 :D

=
Além disso, pode haver um bug na maneira como o Grafana detecta se a métrica usada em query usa as variáveis ​​do modelo.

Quando você tem uma série que usa as variáveis ​​do template indiretamente, o Grafana não impede você de adicionar aquela série como um alerta. O alerta obviamente não funciona corretamente.

Veja o #K (ele usa #D, que usa #A e #A usa templ. var):

Eu ainda poderia selecioná-lo:

Modelos em todos os lugares, o que significa alertar em nenhum lugar.
Não tenho certeza de como o alerta foi implementado, mas para um gráfico simples a consulta é "traduzida", variáveis ​​de modelo substituídas por valores, antes de fazer uma chamada para a fonte de dados, certo? Então por que não neste caso? De qualquer forma, como dito antes, tendo quase todas as consultas usando variáveis ​​de modelo, o alerta é completamente inútil para mim. Por favor, você poderia implementá-lo para que não tenhamos que mover alertas para fora da Grafana? Muito obrigado!

Acho que devemos reconhecer que alertar com modelos não é trivial e acho que TODAS as opções são o caminho a seguir, porque não queremos que nossos alertas mudem quando alguém estiver usando o painel.
Mas o grafana ainda teria que criar novos alertas se a consulta do modelo retornar novos resultados... o que acontece com frequência à medida que dimensionamos nossos aplicativos.
Isso leva a mais problemas se você estiver usando o InfluxDB, pois muitos de nós estão usando tags/valores de tag, eu acho, e não há filtro de tempo para eles ... .

+1

Apenas permitir especificar a fonte de dados no alerta seria bom para mim. Não quebrará nenhuma lógica e posso especificar pelo menos ambientes de produção e preparação para observar.

ALL é uma opção, com certeza. Mais flexível seria um reconhecimento das variáveis ​​do modelo na consulta e permitir que o usuário defina os valores na configuração da condição de alerta. O melhor, mas complicado, eu acho, seria ter vários alertas (da mesma forma que há várias consultas) para que um alerta diferente pudesse ser configurado para valores de variável de modelo diferentes na consulta. Isso permitiria ao administrador configurar diferentes condições de alerta para diferentes hosts, por exemplo.

Vários perfis de alerta seriam ótimos, mas para uma passagem inicial, apenas fornecer os mesmos seletores de modelo disponíveis no painel de alertas resolveria muitos problemas.

Eu também acho que deve haver uma alternância para cada variável para agregar resultados para essa variável em uma única notificação, isso provavelmente só é ativado para vars de modelo que possuem seleção múltipla ativada. Isso fornece um método simples, mas eficaz, para controlar a verbosidade das notificações - você pode querer notificar apenas uma vez para várias métricas relacionadas, mas notificar para cada host em que qualquer métrica estiver falhando. Ou você pode querer notificar apenas uma vez para uma métrica com falha, não importa quantos hosts sejam afetados.

temos algum marco direcionado para este bug?

Eu tive alguns problemas com o alerta em consultas complicadas e consultas de variáveis ​​de modelo. Eu descobri uma solução fácil, que talvez não seja bonita, mas funciona para o meu caso de uso.
Ele está apenas extraindo a consulta depois que você a construiu, portanto, não há variáveis ​​de modelo e referências #ROW. Isso pode ser óbvio para você, não há ciência de foguetes, mas para mim foi uma mudança de vida.

O que eu faço é preparar uma consulta:

em seguida, extraia-o usando as ferramentas de desenvolvimento do Chrome (copie o valor do parâmetro de destino):

Coloque-o em outra linha (alterne para alternar o modo de edição primeiro):

Configure o alerta:

Voilá!

@siteshbehera Isso não é um bug. É uma solicitação de recurso.

Mas não. Não temos um marco para isso no momento.

o plugin grafana de inteligência artificial deve ser incluído no commit para este recurso.

Aguardando modelos em Alertas também +1

Também sou muito a favor do que o calind forneceu como possível implementação no post de abertura. Parece se encaixar perfeitamente em quantos (inclusive eu) usam painéis de modelos - onde você tem um painel, mas alterna / limita algumas variáveis ​​para examinar manualmente coisas específicas. Acho que o exemplo da variável "servidor" pode ser o mais adequado. Lá, a variável de modelo (sem _all_-value) se tornaria algo não muito diferente de uma "_tab_" no meu painel - posso alternar entre elas para ver diferentes conjuntos de dados. É então fácil supor que, ao configurar um alerta, o alerta existiria para cada "_tab_" possível separadamente.

Aguardando modelos de suporte em Alertas +1

Como usuário anterior do Librato, onde o alerta era parcialmente capaz desse modelo, gostaria de entrar em contato com uma solução igualmente parcial. No Librato cada métrica vem com uma variável 'fonte', e os alertas em um gráfico seriam automaticamente por fonte.

Acho que uma solução igual satisfaria as necessidades aqui levantadas. Ao criar um alerta, você deve poder escolher um único valor de modelo como 'fonte' e essa fonte é mencionada no alerta, todas as outras sendo definidas como 'todos'. Essa solução pelo menos evita o problema de combinatória que você obtém se permitir o uso de várias variáveis ​​de modelo.

Eu mesmo defini um gráfico máximo ou mínimo invisível sobre os dados que estou interessado e faço o alerta nele, não tão poderoso, mas ainda uma solução funcional até que esse problema seja resolvido.

Olá, definitivamente estou procurando por esse recurso, pois, na maioria dos casos anteriores, todos os meus painéis estão usando consultas de modelo para oferecer suporte a vários ambientes (pelo menos).

Existe um local onde o roteiro da grafana está sendo rastreado? Ou de alguma maneira que possamos ver se recursos (como este) serão implementados em um futuro (próximo ou não tão próximo) sem cutucar os mantenedores no github? :)

Maravilhoso esperando ansiosamente por esse

+1

+1

Ainda não temos certeza de como fazer isso.

Acho que reutilizar a variável de modelo selecionada para alertar seria perigoso, pois as pessoas podem optar por visualizar apenas uma opção e esquecer de voltar para All ou algo mais amplo. Eu não me sentiria seguro com tal comportamento. As regras de alerta devem ser extremamente fáceis de entender e raciocinar. Regras explícitas > regras mágicas.

Uma solução para este problema seria ter dois valores para cada variável de template. Um para visualização no painel e outro para alerta. Isso possibilitaria ter sempre a opção mais ampla de alerta e ainda selecionar apenas algumas opções nos gráficos. A conexão desses valores deve ser possível, mas não o comportamento padrão.

Essa solução como cada recurso seria bastante grande e complexo.

Tenho duas propostas de solução.

1. Uma proposta de curto prazo é adicionar uma opção de alerta para que no garph renderizado (aquele que está sendo enviado por e-mail) sejam exibidas apenas as métricas que estão alertando. Isso resolveria a confusão quando o gráfico de alerta contiver dezenas de métricas.

2. Uma solução de longo prazo seria iterar por meio de variáveis ​​de modelo, para que você tenha um alerta distinto para cada combinação de valor de modelo.

Como mencionei em novembro. Para usuários do prometheus, apenas usar 'All' como valor de variável é suficiente se as consultas forem escritas corretamente ( some.metric{hostname=~"$Hostname"} ).

Provavelmente também deve ser muito fácil de implementar.

@bergquist Acho que a opção 2 está indo na direção certa (uma implementação parcial do que sugeri em https://github.com/grafana/grafana/issues/6557#issuecomment-272588490), não parece muito complexo, já que o código para manipular a seleção de var do modelo já existe para o dashboard, e não há necessidade de duplicar a configuração de var, apenas a seleção. Acho que não me incomodaria em conectar a seleção do painel ao alerta na primeira passagem para esse recurso.

resolvi criando uma nova query de métrica apenas para o alerta, sem as variáveis ​​do template e desabilitei (para excluí-lo do gráfico) no Grafana versão v4.1.1.

+1 para implementar vars modeladas em alertas

+1 para implementar vars modeladas em alertas

Isso afeta _todas_ as versões do Grafana? Ou este era um recurso que estava disponível antes? Isso é meio que um problema para mim e não me importaria de instalar uma versão anterior.

O alerta @alejandroandreu foi adicionado na versão 4, nunca funcionou com templates.

+1 para implementar vars modeladas em alertas

Gostaria de poder selecionar/inserir as combinações que os alertas devem avaliar, pois alguns dos ambientes que executo não são ambientes de produção, existem duas maneiras de implementar isso, a primeira é mais explícita, a segunda é mais fácil de configurar.

Insira todas as combinações desejadas manualmente

• Esta configuração deve ser mostrada no painel de configuração do Alerta

Por exemplo, se eu tiver 3 variáveis ​​de template : cloud , region e type , eu preencheria uma tabela assim:

| nuvem | região | tipo |
|-------|------------|------|
| aws | us-leste-1 | prod |
| aws | us-west-1 | prod |
| azul | Centro dos EUA | prod |

A tabela deve ter linha extra para inserir novas linhas e botão de exclusão para cada linha.

Insira os valores possíveis e o Grafana calculará o Produto Cartesiano

• Nota: Esta configuração pode ser inserida no painel de configuração de variável de modelo

| nuvem | região | tipo |
|-------|------------|------|
| aws | us-leste-1 | prod |
| azul | us-west-1 | |
| | Centro dos EUA | |

As combinações que serão criadas para esta entrada são:

• aws us-east-1 prod
• aws us-west-1 prod
• aws Central US prod
• azure us-east-1 prod
• azure us-west-1 prod
• azure Central US prod

Mas o Grafana pode lidar com essa situação "inserindo" a primeira variável ( cloud ), e depois filtrando os valores disponíveis da segunda variável ( region ) até encontrar todas as combinações possíveis (nota - deve ser feito iterativamente para todas as variáveis) . Isso é possível quando as pessoas usam consultas nas tags como esta:

SHOW TAG VALUES WITH KEY = "REGION" WHERE "CLOUD" =~ /$CLOUD/   

E neste caso, as combinações produzidas ficarão boas (que é a mesma da tabela na primeira opção):

• aws us-east-1 prod
• aws us-west-1 prod
• azure Central US prod

Espero que minhas sugestões sejam úteis.

Temos esse problema (fonte de dados OpenTSDB) em um contexto um pouco diferente - se você usar um modelo var para selecionar um intervalo de downsample na métrica, a consulta de alerta falhará com o erro 400. Eu entendo as dificuldades na implementação de uma solução geral, mas estamos vai ter que reprojetar vários painéis existentes para habilitar alertas.

@dbcook soa como um problema distinto para o qual você provavelmente deve registrar um problema separado.

A modelagem é realmente um recurso incrível, assim como o alerta. É melhor tê-los trabalhando juntos sem problemas, em vez de qualquer solução complicada.

@tomekit Obrigado pela solução alternativa, parece promissor enquanto aguardamos a implementação real. No entanto, não consigo encontrar onde extrair a consulta usando as ferramentas de desenvolvimento do Chrome e, portanto, não consigo copiar o valor do parâmetro de destino para a nova consulta. Eu tentei "Inspecionar elemento", mas estou lutando para encontrar "Nome" ou "Cabeçalhos" ou "Dados de formulário" que você mostrou na captura de tela.

Você poderia, por favor, ilustrar os passos para fazer isso? Sua ajuda será muito apreciada!

Obrigado

@mathurj É a guia Rede -> XHR. Ajuda agora?

Em seguida, clique na solicitação "renderizar".

Obrigado @tomekit , posso ver esta página agora, mas não consigo ver nenhuma solicitação chamada "render". No entanto, há outra solicitação sobre a consulta que estou executando, mas ela não possui nenhum parâmetro "destino".

Alguma pista sobre como fazer a solicitação de "renderização"?

@mathurj recebo a solicitação "render", uma vez olhando um dos gráficos no meu painel e clicando em atualizar (canto superior direito).

Tentei, ainda não há solicitação de "renderização" para mim :( E nenhum parâmetro de "destino" também. Obrigado de qualquer maneira por sua ajuda @tomekit . Acho que terei que esperar pela implementação real, que pode demorar um pouco pela aparência de @bergquist @torkelo ?

ok trabalhando com
some.metric{hostname=\~"$Hostname"}
na consulta em si está bom,
mas é minha fonte de dados que é o modelo aqui ...

ambiente=\~"$ambiente"
não parece funcionar... de alguma forma para isso funcionar eu perdi alguma coisa? ou devo me livrar do modelo :disappointed:

+2

esse recurso é especialmente útil ao usar o prometheus como fonte de dados!

Eu preciso disso também, por razões semelhantes às mencionadas acima. Espero que isso funcione como um para cada loop em toda a coleção que o modelo define.

Nós precisamos disso!!! :) 👍

Pessoalmente, também sou a favor desse recurso. Estamos testando mais de um sistema com um conjunto de testes de carga que geram métricas de atraso. Em vez de ter um painel, estamos usando uma variável para alternar entre as fontes de dados que contêm os dados dos vários sistemas, a fim de manter apenas um quadro e não roteirizá-los.
Portanto, um suporte para modelos em alertas seria muito apreciado.

+1
nós também precisamos disso

+1
nós também precisamos disso

+1
nós também precisamos disso

Posso perguntar por que tantos caras "curtem" essas respostas com +1?

@skygragon é essencialmente spam inútil quando existe a opção de marcar com +1 a postagem original. Basta clicar no ícone de polegar para cima no primeiro post.

Variáveis ​​de modelo e alertas são 2 dos melhores recursos do Grafana.
É triste ver que eles são mutuamente exclusivos embora ......

+1

@bergquist sua equipe poderia discutir isso novamente e, com sorte, estabelecer um marco nisso? É o recurso mais solicitado há quase 2 anos e aposto que alguns usuários ficariam felizes em obter esse recurso.

Nenhuma boa solução foi proposta e ainda temos certeza de que isso é uma má ideia, pois está misturando dois recursos que servem a propósitos diferentes. As variáveis ​​de modelagem são usadas para painéis dinâmicos e exploração. As regras de alerta já podem ser feitas para serem dinâmicas com consultas regex/curinga. Misturar esses dois parece uma ideia terrível, pelo menos de maneira compreensível e previsível.

Existem algumas boas razões para suportá-lo de alguma forma limitada, mas não tenho certeza se valerá a pena a extrema complexidade que adicionaria e o custo de desenvolvimento. Mas estamos abertos a ideias, sugestões e PRs.

O problema é que tenho alguns servidores que monitoro E eles são criados dinamicamente pela Amazon, então em um determinado momento não sei quantos servidores estão ativos.

Eu tenho um gráfico modelo que mostra a CPU para cada servidor (por exemplo), então gostaria de alertar lá também.

Mas você está dizendo que eu poderia conseguir o mesmo usando curingas?

@yesman85 bem, claro, depende da sua loja de séries temporais. mas a maioria suporta alguma forma de sintaxe de consulta glob/regex para direcionar várias métricas que seguem um padrão de nomenclatura.

@torkelo Acredito que esta é a primeira vez que essa posição é declarada publicamente. Acho que talvez haja algum mal-entendido aqui - não acredito que os usuários desejem que os valores de modelo selecionados para a saída do painel afetem os alertas, mas que tenham as mesmas seleções de modelo disponíveis ao configurar alertas.

Sugestões de implementação relevantes deste tópico:
https://github.com/grafana/grafana/issues/6557#issuecomment -272588490
https://github.com/grafana/grafana/issues/6557#issuecomment -281049641 (opção 2)

Além disso, questões relacionadas:
https://github.com/grafana/grafana/issues/6041
https://github.com/grafana/grafana/issues/6553
https://github.com/grafana/grafana/issues/6983
https://github.com/grafana/grafana/issues/7252

Essas limitações nos impediram de usar o Grafana para alertar com raiva, porque as únicas maneiras de fazer esse tipo de trabalho atualmente são adicionar um monte de consultas ocultas separadas para alertar ou criar painéis separados para alertar versus exibir . Ambas as opções são um pesadelo de manutenção e limitam o grande potencial que o Grafana tem para fácil configuração de monitoramento e interpretação pelos usuários.

Acho que minha sugestão acima inspirada no alerta baseado na fonte Libratos fornece uma solução limitada, compreensível e previsível que parece cobrir quase todos os problemas mencionados acima.

No grafana, isso se traduziria em poder usar uma e apenas uma variável de modelo para alertar e cada valor nessa variável geraria seu próprio alerta. Você também pode adicionar um regex para filtrar as entradas / saídas nas quais deseja criar alertas.

@pdf Concordo que https://github.com/grafana/grafana/issues/6041 é uma grande limitação, que definitivamente queremos corrigir, mas não está relacionada a esse problema. É ruim que não tenhamos consertado ainda. Concordo, estivemos um pouco com falta de pessoal no lado dos alertas nos últimos dois meses, mas isso mudará em breve!

@danhallin que não é o mesmo, parece que se traduziria em uma consulta no Grafana que visa muitas séries usando caracteres curinga ou expressões glob em sua consulta ou apenas filtra em um conjunto limitado de tags? As regras de alerta do Librato são definidas separadamente dos painéis, não são, então, como isso pode se traduzir em um recurso de filtragem de dados em todo o painel?

maneira de fazer isso que funciona atualmente é adicionar um monte de consultas ocultas separadas para alertas, o que é um pesadelo de manutenção

Entenda que misturar regras de alerta em seus gráficos modelados como esse é um pesadelo. Mas pense que o suporte a variáveis ​​de modelo em alertas pode ser um pesadelo ainda maior. Provavelmente uma pergunta estúpida, mas você não pode criar painéis e gráficos focados em alertas? e deixar os painéis com muitas variáveis ​​de modelo para exploração e solução de problemas? Eu sei que provavelmente há muitos casos em que eles seriam semelhantes, então parece um trabalho duplicado :( O problema com as regras de alerta no contexto de um painel com algumas variáveis ​​​​de modelo é como ele deve funcionar e ser compreensível e como pode até ser implementado em tudo.

Digamos que uma consulta use 2 variáveis ​​de modelo, $A e $B, cada uma com 50 valores. Isso resultaria na avaliação da regra de alerta 2.500 vezes? Quero dizer, se as variáveis ​​são de "valor único", ou seja, as consultas são construídas para funcionar apenas se $A e $B tiverem um único valor, então teríamos que fazer isso. Talvez não seja uma rolha de show, teríamos que explicar que apenas variáveis ​​​​de vários valores são suportadas. Provavelmente há muito mais limitações e detalhes problemáticos que tornarão esse recurso muito difícil de implementar, usar e entender

Mas não sou 100% contra, acho que pode haver uma maneira de fazer isso de forma limitada (como apoiar apenas um
variável multivalorada). Há também o caso de uso de ter várias fontes de dados e poder direcionar uma variável de fonte de dados em sua regra de alerta para reutilizar essas regras de alerta em muitos datacenters/ambientes (que possuem TSDBs separados) esse caso de uso teria que ser resolvido usar uma variável de modelo de fonte de dados como uma consulta de métrica com curingas não pode resolvê-lo.

mas você não pode criar painéis e gráficos focados em alertas? e deixar os painéis com muitas variáveis ​​de modelo para exploração e solução de problemas? Eu sei que provavelmente há muitos casos em que eles seriam semelhantes, então parece um trabalho duplicado :(

Na verdade, editei meu comentário para fazer referência a essa opção (e adicionei alguns outros problemas de pontos problemáticos relacionados a alertas). No entanto, como você identificou, isso significa multiplicar a criação do painel/painel (e manutenção, se todas essas consultas precisarem de uma atualização) pelo número de variações de modelo sobre as quais você deseja alertar e também segregar as anotações de alerta do local em que podem ser mais útil em - um painel de modelo com anotações de alerta pode ser muito útil para fazer correlações, mas não tanto se você tiver que tentar explorar várias guias do navegador e tentar alinhar as coisas.

Digamos que uma consulta use 2 variáveis ​​de modelo, $A e $B, cada uma com 50 valores. Isso resultaria na avaliação da regra de alerta 2.500 vezes? Quero dizer, se as variáveis ​​são de "valor único", ou seja, as consultas são construídas para funcionar apenas se $A e $B tiverem um único valor, então teríamos que fazer isso. Talvez não seja uma rolha de show, teríamos que explicar que apenas variáveis ​​​​de vários valores são suportadas. Provavelmente há muito mais limitações e detalhes problemáticos que tornarão esse recurso muito difícil de implementar, usar e entender

Há duas questões separadas aqui, eu acho. Um _é_ (acredito) intimamente relacionado ao #6041, pois pode haver um desejo de avaliar as condições de alerta individualmente por valores de série/modelo (a alternância agregada que mencionei em um comentário anterior). Se deixarmos isso de lado por enquanto, acredito que a maneira ideal de resolver a maior parte desse problema é permitir várias configurações de alerta por painel e apenas fazer a interpolação variável exatamente da mesma maneira que para a saída do painel: permitir que os usuários selecionem um único ou valores de modelo de vários valores ao configurar consultas de alerta; as consultas serão executadas uma vez por configuração de alerta, com os valores selecionados preenchidos; e os resultados serão interpretados exatamente da mesma maneira que são atualmente. A menos que eu esteja entendendo mal alguma coisa, não vejo isso como um aumento significativo na complexidade e deve ser bastante amigável.

A capacidade de selecionar valores de modelo para simplesmente limitar o escopo de alerta ainda seria útil sem várias configurações de alerta (se ajudar a desenvolver essa funcionalidade nessa ordem), mas seria exponencialmente mais valiosa com várias configurações.

Há também o caso de uso de ter várias fontes de dados e poder direcionar uma variável de fonte de dados em sua regra de alerta para reutilizar essas regras de alerta em muitos datacenters/ambientes (que possuem TSDBs separados) esse caso de uso teria que ser resolvido usar uma variável de modelo de fonte de dados como uma consulta de métrica com curingas não pode resolvê-lo.

Múltiplas configurações/consultas de alerta por painel forneceriam um método para lidar com vários TSDBs, e uma opção pode ser permitir o agrupamento de consultas de alerta, para que as transições de estado ocorram com base no resultado de todas as consultas no grupo (semelhante a como as coisas funcionam atualmente para séries). Não parece muito complicado.

Esta é definitivamente uma necessidade popular. Agora, para alcançar o Alerta, tivemos que mudar
longe do Grafana e crie nossa solução personalizada usando o Graphite's Render
Dados brutos de APIs .. Eu não acho que suporte Alertas em dinâmico/modelado
data é pelo menos complexo usando Graphite ..

Mais um pensamento é,. Por que a seção de alertas do Grafana faz parte do painel
config se isso for considerado complexo. Você pode afastá-lo para separar
Visualização de alertas onde os usuários podem apenas inserir/configurar sua consulta dinâmica,
intervalo, condição de avaliação ali.. Pode ser que isso signifique que nós
não tenha painéis duplicados. Faz sentido?

BR,
Vishwa..

Em 23 de agosto de 2017 08:01, "Peter Fern" [email protected] escreveu:

mas você não pode criar painéis e gráficos focados em alertas?
e deixe os painéis com muitas variáveis ​​de modelo para exploração e
solução de problemas? Eu sei que provavelmente há muitos casos em que eles seriam
semelhante, então parece trabalho duplicado :(

Na verdade, editei meu comentário para fazer referência a essa opção (e adicionei alguns
dos outros problemas de pontos de dor relacionados ao alerta). Como você identificou, porém,
isso significa multiplicar a criação de painéis/painéis (e manutenção, se todos
essas consultas precisam de uma atualização) pelo número de variações de modelo que você deseja
para alertar e também segrega as anotações de alerta do local
eles podem ser mais úteis em - um painel de modelo com anotações de alerta
pode ser muito útil para fazer correlações, mas não tanto se você precisar
tente explorar várias guias do navegador e tentar alinhar as coisas.

Digamos que uma consulta use 2 variáveis ​​de modelo, $A e $B, cada uma com 50
valores. Isso resultaria na avaliação da regra de alerta 2.500 vezes? Quero dizer
se as variáveis ​​são de "valor único", ou seja, as consultas são construídas para funcionar apenas
se $A e $B tiverem um único valor, teríamos que fazer isso. Não é um show
rolha talvez, teríamos que explicar que apenas as variáveis ​​de vários valores são
suportado. Provavelmente há muito mais limitações e detalhes problemáticos
que tornará esse recurso muito difícil de implementar, usar e entender

Há duas questões separadas aqui, eu acho. Um é (eu acredito) de perto
relacionado a #6041 https://github.com/grafana/grafana/issues/6041 , em
que pode haver um desejo de avaliar as condições de alerta individualmente por
valores de série/modelo (a alternância agregada que mencionei em um
Comente). Se deixarmos isso de lado por enquanto, acredito que a forma ideal de resolver
a maior parte desse problema é permitir várias configurações de alerta por painel e
apenas faça a interpolação variável exatamente da mesma maneira que para o painel
output - permite que os usuários selecionem valores de modelo de valor único ou múltiplo quando
configurar consultas de alerta; as consultas serão executadas uma vez por alerta
config, com os valores selecionados preenchidos; e os resultados serão
interpretados exatamente da mesma maneira que são atualmente. A menos que eu seja grosseiramente
entendendo mal alguma coisa, não vejo isso como um aumento significativo na
complexidade e deve ser bastante amigável.

A capacidade de selecionar valores de modelo para simplesmente limitar o escopo do alerta
ainda ser útil sem várias configurações de alerta (se ajudar a desenvolver
essa funcionalidade nessa ordem), mas seria exponencialmente mais valioso
com várias configurações.

—
Você está recebendo isso porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/grafana/grafana/issues/6557#issuecomment-324363795 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AAz1sbIwOT7Xb1MwoDYgZCPz182h2ENxks5sbD62gaJpZM4Kwf5K
.

@danhallin que não é o mesmo, parece que se traduziria em uma consulta no Grafana que visa muitas séries usando caracteres curinga ou expressões glob em sua consulta ou apenas filtra em um conjunto limitado de tags? As regras de alerta do Librato são definidas separadamente dos painéis, não são, então, como isso pode se traduzir em um recurso de filtragem de dados em todo o painel?

Vejo agora que o que estou discutindo é basicamente uma cópia de: https://github.com/grafana/grafana/issues/6041

Eu sou a favor desse pedido de recurso sobre este.

Criamos servidores regularmente e temos painéis de modelos que medem coisas comuns em todos os hosts (mem, hd, cpu, etc). Fazer um painel de "alerta" com gráficos para cada combinação possível é muito tedioso, muitos dos alertas desejados podem ser generalizados para todos os hosts. AFAIKT este problema está pedindo uma maneira de tornar este caso de uso possível e não seria resolvido em # 6041. A menos que eu esteja perdendo alguma coisa.

Fazer um gráfico e alerta para cada combinação não é o que estamos propondo, apenas que sua consulta de alerta use curingas ou regex para cobrir todos os hosts etc. requisitos para solução de problemas e filtragem dinâmica.

Para nosso caso de uso, temos várias instâncias (potencialmente) efêmeras fornecendo processamento de eventos em tempo real - precisaríamos ser alertados se certas métricas geradas pelo aplicativo caírem para 0. No entanto, se as instâncias forem removidas ou interrompidas, elas ainda terão uma métrica nomeada associado a eles que aparece em uma pesquisa de curinga direta que leva a alertas gerados falsamente.

Contornei isso usando uma variável de vários valores com modelo (definida como All) gerada a partir de uma "fonte de dados JSON simples" que contém uma fonte de verdade para quais instâncias devem ser executadas - todas funcionando perfeitamente. Infelizmente, assim que tentei ativar o alerta, fui levado a essa solicitação de recurso :)

Não tenho certeza de quão único é nosso caso de uso específico, mas não tenho certeza de nenhuma outra maneira de alertar sobre isso sem o uso de modelos - por enquanto, precisaremos continuar alertando para esses problemas fora do Grafana (o que é uma pena - somos usuários muito pesados ​​do Grafana!)

+1

Portanto, um caso em que não temos nenhum desses problemas é quando a variável de modelo é um tipo constante. Por exemplo, temos vários painéis que dependem de uma variável constante para limitar os dados desse painel a um recurso específico (o motivo pelo qual não usamos uma variável de vários valores é porque cada painel é diferente o suficiente para justificar configurações diferentes, mas próximo o suficiente para justificar um painel "modelo"). Pelo menos neste caso (variáveis ​​constantes) nada sobre o comportamento de alerta atual precisa mudar.

Alguma novidade sobre este tema?

Oi,

Existe alguma esperança de obter esse recurso? Eu só me pergunto como outros sistemas estão tendo esses recursos, pois eles também devem estar usando um tipo de modelo, pois quando instalamos o agente, ele aparece automaticamente no portal e o alerta também pode ser definido para isso. (Esta é a minha experiência com a New Relic).

@vishwanathh gostei da abordagem de ter uma seção separada para alertas (se estiver sendo complicado tê-lo no painel gráfico) onde podemos colocar nossas consultas apenas para alertar. pois desta forma nossos usuários não verão o painel de espaço reservado (usado para alertar).

Desculpe pelo ruído extra, mas esse seria um ótimo recurso para ter no Grafana.

+1, recurso muito, muito importante!

Além disso, se me permitir modificar a expressão de consulta de métrica do Prometheus para remover a variável do modelo, isso não é viável. Então, acho que esse recurso é o mais importante para o prometheus+grafana pousar em produção!

De qualquer forma, por favor, a equipe pode considerar a prioridade, obrigado!

Com o 5.0 saindo em breve, eu adoraria ver algum foco significativo dado alerta durante a próxima série de lançamentos. Observando as reações do Github, as deficiências relacionadas a alertas parecem ter de longe o maior interesse dos usuários.

Eu sei que houve alguma relutância em lidar com essas coisas devido a preocupações de complexidade de UI/UX, no entanto, não estou convencido de que essas preocupações sejam necessariamente justificadas. Existe algo que nós, como usuários, possamos fazer que possa ajudar a planejar/projetar ou levar esses problemas adiante, exceto solicitações de pull com código real?

@torkelo Isso me ajudou a configurar alertas para todos os meus hosts usando tags e agora cada gráfico de alerta contém várias séries formadas pela combinação de tags. Tudo parecia estar funcionando bem. Mas, analisando os documentos e outros problemas, percebi que, se alguma das séries no gráfico já estiver em estado de alerta, os alertas para outras séries não serão acionados se também cruzarem o limite.

Isso é novamente sendo limitações.

Obrigado.

Alguma novidade sobre esse recurso?

Qual é o esforço de um novo colaborador para adicionar esse recurso?

+1

Permita que variáveis ​​de modelo sejam usadas para notificações de alerta.
+1

+1

Esperamos ser resolvidos.

+1

Eu não quero bater em um cavalo morto aqui, mas estamos tendo o mesmo problema, e eu quero fornecer algum contexto sobre por que as propostas existentes não funcionam em todas as circunstâncias. Também tenho algumas ideias para soluções alternativas, mas por que precisamos de _alguns recursos_ para ajudar a tornar as soluções alternativas suficientes.

Para todos os cenários abaixo, estamos usando uma única variável de modelo: $env

"Por que não apenas criar painéis de alerta?"

Queremos alertar em alguns ambientes diferentes, não apenas na produção. Portanto, agora precisaríamos ter a mesma métrica em _pelo menos_ 3 lugares diferentes (o painel de solução de problemas com todas as métricas, não apenas a métrica para a qual alertamos; o painel de alertas de produção; o painel de alertas de integração). Isso pode sair do controle muito rápido e é propenso a erros do usuário.

Igualmente importante, isso anula grande parte do ganho de anotações automatizadas de alertas. Se eu tiver que ir e voltar do meu painel exploratório para o painel de alertas para ver as anotações de quando um evento começou e quando terminou, isso será bastante tedioso.

Tentativa de Solução

O que fizemos para tentar contornar isso foi adicionar métricas duplicadas _especificamente para alertas_ aos nossos painéis. Portanto, se houver uma métrica sobre a qual desejamos alertar, vamos ao painel e adicionamos métricas explícitas para esses alertas (e as ocultamos).

Nossa lista de séries para um determinado painel que precisa alertar será semelhante a:

Com a série não modelada marcada como oculta. Em seguida, na guia de alerta, definimos limites para _these_ series, não para a variável series.

Problemas com esta solução

Isso não funciona muito embora. Por exemplo:

Como você pode ver, o painel Alertas não nos permite especificar _qual ambiente_ está alertando -- portanto, precisamos detalhar o alerta para descobrir qual ambiente está bloqueado no momento. No entanto, uma correção fácil para isso pode ser apenas permitir que a descrição seja tão detalhada quanto o painel Histórico de alertas que mostra as transições de estado:

Isso é pelo menos um pouco útil, mas mesmo neste painel não há indicação de qual alerta voltou para Healthy (a descrição da captura de tela acima foi derivada do alias que definimos na série se alguém estiver se perguntando como para pelo menos conseguir tanto para aparecer).

Coisas que ajudariam até que esse ticket específico seja resolvido

• Permitir a opção de exibir o alias da série em vez de uma descrição digitada para o alerta (dessa forma, o alias pode pelo menos especificar a variável $ para a qual está alertando)
• Permitir que a transição de estado de volta para saudável também mostre o alias da série (na captura de tela do histórico acima)
• Permitir um valor de legenda para alertas ativos (usando o alias de série que suponho) para um determinado painel

Coisas que não tenho certeza de como consertar

Anotações em gráficos que possuem alertas configurados para vários ambientes/variáveis:

Com isso, não podemos realmente dizer qual alerta está disparando sem entrar no painel. A sugestão de legenda pode ajudar a esclarecer isso, mas não faz muito pela anotação se o $env correto não estiver selecionado (na imagem acima, int está alertando, mas prod é a variável selecionada no painel, então estamos exibindo anotações do alerta int na parte superior do gráfico usando prod .

+1

mais um :)

Pare de marcar este problema com +1. Gera e-mails de spam desnecessários. A capacidade de adicionar uma reação a um comentário de problema do github já existe há algum tempo, e mais de 429 pessoas descobriram como curtir o comentário inicial em vez de enviar spam para todos os inscritos.

Por favor, realmente precisamos desse recurso, gostaríamos de usar o modelo, mas no nosso caso é mais importante ter um sistema de alerta claro. Então, para contornar isso, estamos evitando modelos em nosso painel... é uma bagunça.

Concordo e esse recurso vai nos ajudar muito!!!!

+1 por favor

nós precisamos disso

+1 por favor. É realmente necessário.

@bergquist @torkelo podemos bloquear este problema para parar o spam de +1?