Grafana: construindo sistema de alerta para grafana

Eu adoraria ajudar com isso! Minha sugestão seria seguir as diretrizes do estilo nagios. Dessa forma, as ferramentas podem ser facilmente usadas com outras ferramentas de monitoramento. por exemplo, Nagios, Zenoss, Icinga, etc.

O principal aspecto desse recurso é obter a arquitetura básica correta.

Algumas questões que gostaria de explorar
1) Quais componentes são necessários como eles são executados (in proc in grafana, out of proc),
2) Como as coisas devem ser coordenadas.
3) Devemos ignorar o alerta "in stream", (focar apenas no pull baseado)

Aprofundando mais em 1)
Estou preocupado em transformar o grafana-server em um monólito. Gostaria de encontrar uma maneira de separar o grafana-server em serviços que são mais isolados uns dos outros (e podem ser executados inproc ou como processos separados). Esse era o tipo de plano com a abstração do ônibus. Outra opção seria fazer com que o componente de alerta só falasse com a grafana através da API HTTP, pode limitar a integração, não tenho certeza.

Eu concordo com o torkelo. Em minha experiência com outros projetos com tudo "embutido", pode ser bastante complicado solucionar os problemas. Gosto da ideia do serviço rodando externamente, mas uma bela página de configuração em grafana que se comunica com o serviço através da API HTTP para lidar com o gerenciamento de todos os alertas. Além disso, para implantações em grande escala, isso provavelmente acabaria sendo um requisito, pois o desempenho acabaria por degradar (eu teria pelo menos isso como uma opção de configuração).

nós integramos com as configurações atuais de limite do gráfico grafana (que atualmente são apenas para visualização, não para processamento)? se a expressão for uma verificação de limite, poderíamos exibir automaticamente uma linha de limite

Acho que pode ser um bom lugar para começar. Alerta se estiver definido, não se não estiver.

Voltando ao número 1. Acho que se o serviço bosun pudesse rodar separadamente mas ainda tivesse a capacidade de configurar tudo completamente através da grafana isso seria, na minha opinião, o ideal.

Mantenha o trabalho incrível.

A única deficiência que vi com o bosun são as fontes de dados que ele pode usar. Se você pudesse aproveitar a linguagem para expressar alertas de contramão, mas também integrar com fontes de dados existentes que são configuradas por meio da UI grafana regular, certamente seria ideal.

Ser capaz de representar limites de alerta, quando você está perto deles, bem como automaticamente enviar anotações para quando eles forem acionados em minha mente, é uma IU de painel único ideal.

Ansioso pelo trabalho que será feito aqui!

1. Deve usar os limites definidos no Painel para alertar sobre
   Vamos manter as coisas simples; se o Dashboard mostrar a cor de aviso, ele deve estar alertando.
2. Isso provavelmente é algo fora do próprio processo grafana-server.
   ... Algo que usaria a api restante para raspar os painéis e suas configurações e renderizá-los e alertá-los usando um comando externo.
3. Nível de alerta; apenas uma caixa para soltar no editor que este Dashboard deve ser monitorado; e deve ser verificado a cada minuto. Se não houver dados, ele deve continuar por um período, ele ainda deve alertar? (caixa de seleção)

Por último; como dependemos mais de Grafana, admito que estou disposto a dizer 2. pode ser algo pelo qual estaria disposto a pagar.

Estou curioso para saber por que as pessoas acham que isso deveria ser incluído no Grafana?
O Grafana não recebe nem armazena os dados reais, mas "apenas" os visualiza. Em vez disso, qualquer sistema de alerta deve ser baseado nos dados do repositório de métricas.
Se isso estiver realmente integrado ao Grafana, espero que possa ser desabilitado porque aqui já usamos Icinga para alertar, então qualquer tipo de alerta no Grafana iria apenas bagunçar mais a GUI, mesmo que não fosse usado de forma alguma.

Absolutamente correto @dennisjac; Grafana apenas renderiza coisas.

Mas, à medida que mudamos as coisas do lado do servidor, não se trata mais apenas da renderização do cliente; as possibilidades de um processo de trabalho que pode verificar suas métricas e alerta; é menos difícil.

Os dados estão em um banco de dados; desde que seja polvilhado com os dados que lhe dizem para verificar a métrica ...

Algumas pessoas podem concordar ou discordar que não devemos cruzar os riachos e fazer Grafana fazer mais do que visualizá-lo (aproximadamente), mas eu não sou eles.

Na verdade, não me oponho ao recurso para pessoas que desejam que ele seja integrado, mas espero que seja opcional para pessoas que já têm sistemas de monitoramento / alerta disponíveis.

O novo projeto Telegraf (coletor de métricas dos caras do influxdb) também está procurando recursos de monitoramento / alerta que são desagradáveis ​​pelo mesmo motivo. Eu elaborei isso aqui:
https://influxdb.com/blog/2015/06/19/Announcing-Telegraf-a-metrics-collector-for-InfluxDB.html#comment -2114821565

Acho que o torkelo fez um ótimo trabalho ao nos fornecer recursos no Grafana2 que não precisamos habilitar.

No que diz respeito ao influxdb, eles terão que ganhar algum dinheiro de alguma forma; ou fora do suporte de influxdb e serviços profissionais ou produtos para ele.

Este último parece muito mais viável

Outro ângulo sobre isso. Parece haver suporte para pesquisa elástica como um armazenamento métrico para grafana. Bosun pode agora consultar o elasticsearch para dados de log.

Faria sentido ao projetar o sistema de alerta para permitir alertas de dados de log também? Talvez não seja um recurso para a primeira versão, mas algo que pode ser implementado mais tarde.

Também concordo com a ideia de dividir os processos. Tenha a interface do Grafana para visualizar e criar alertas, tenha outra coisa para lidar com os alertas. Ter a API da parte de alerta baseada também permite que outras ferramentas façam interface com ela.

+1 para alertar. Fora do uso do DevOps, os aplicativos desenvolvidos para usuários finais precisam fornecer alertas definidos pelo usuário. É bom ter isso na ferramenta de visualização ...

+1 isso vai fechar o ciclo - a proposta de obter métricas.

Alerta +1 do Grafana + um back-end de dimensionamento horizontal do InfluxDB os tornará o padrão a ser batido para configurações de alerta de métricas

+1 Eu adoraria escalonamento horizontal do alerta em vários nós de grafana.

Seria ótimo se alguém pudesse associar um comportamento do tipo "debounce" a um alerta. Por exemplo, desejo disparar um alerta apenas se o limite definido exceder X por N minutos.

Eu vi isso com algumas das ferramentas de alerta, infelizmente estamos usando o Seyren, que não parece fornecer essa opção. Estamos usando o Grafana para o desenvolvimento de nosso painel e estamos ansiosos para puxar o alerta para o Grafana também. Mantenha o bom trabalho.

Temos dois casos de uso:

• a equipe de infraestrutura cria alertas por meio de ferramentas de provisionamento como de costume na pilha de monitoramento comum (verificação de cluster comum ou verificações de sistema em sistema amigável do nagios)
• desenvolvedores de software criam métricas de aplicativos por meio do Grafana

Adoraríamos ter um sistema de alerta unificado para lidar com alertas, detecção de flaps, escalonamento e contatos. Isso nos ajuda a registrar e correlacionar eventos / operações na mesma fonte de verdade. Muitos sistemas resolveram o problema de alerta. Espero que Grafana possa fazer melhor nisso a longo prazo, a curto prazo, não reinventar os sistemas existentes seria útil em termos de resultados.

Uma sugestão é que a Grafana pode fornecer API para extrair definição de monitoramento (estado de alerta), terceiros podem contribuir com plug-ins de exportação de configuração. Isso seria ideal em nosso caso de uso exportando a configuração do nagios.

Mais importante, eu adoraria ver alguma solução integrada de detecção de anomalias também!

Em 15 de julho de 2015, às 17:40, Pierig Le Saux [email protected] escreveu:

+1 Eu adoraria escalonamento horizontal do alerta em vários nós de grafana.

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

Eu concordo com @activars. Eu realmente não vejo por que uma solução de painel deve lidar com alertas, que são um problema mais ou menos resolvido por muitas outras ferramentas, a maioria bastante maduras. Faça uma coisa e faça-a bem.

IMHO faria mais sentido se concentrar na parte _integração_.

Exemplo: Defina limites de aviso / crítico dinâmicos em grafana (por exemplo, como no exemplo @Dieterbe acima) e forneça uma API (REST?) Que retorna o estado (normal, aviso, crítico) exatamente desse gráfico. Um nagios, icinga, bosun etc. poderia solicitar todos os gráficos habilitados para "monitoramento" (outro recurso da API), iterar através dos estados individuais e fazer os alertas necessários.

No nosso caso, catálogos de serviços e ações definidas são a parte difícil - qual serviço é crítico para o negócio, para onde enviar e-mails, flapping etc. local central (AD, LDAP, Crowd etc.) e integrado ao sistema de alerta.

Também devemos considerar que, ao contrário de uma solução de painel, os requisitos de qualidade para uma ferramenta de alerta podem ser considerados muito mais elevados em termos de confiabilidade, resiliência, estabilidade etc., o que cria um esforço (de teste) que não deve ser subestimado.

E também as verificações não relacionadas à série temporal, como chamar um serviço da web, executar ping em uma máquina, executar scripts personalizados ... você gostaria disso no grafana também? Acho que a adoção do contramestre proporcionaria tudo isso, mas não estou realmente familiarizado com isso.

Por outro lado, posso imaginar como um sistema de alerta simples faria muitos usuários felizes por não terem uma boa alternativa em vigor, mas isso talvez pudesse ser resolvido com alguns exemplos de padrões de integração para outras ferramentas de alerta.

Por mais que eu queira que o Grafana resolva todos os meus problemas, acho que o falkenbt acertou em cheio com esse aqui.

Uma API para expor os dados mencionados, alguns problemas no contramestre e alguns padrões de integração com plataformas de alerta comuns fazem muito sentido.

Parabéns pelo seu novo emprego na raintank @Dieterbe! Eu tenho lido o seu blog há um tempo e você tem algumas ideias realmente boas sobre monitoramento, particularmente em relação às métricas e seu lugar no alerta. Tenho certeza de que você encontrará uma boa maneira de implementar alertas na grafana.

Como você provavelmente concordaria, as pessoas por trás do Bosun estão alertando da maneira certa. O que falta com Bosun são realmente as visualizações. Eu gostaria de ver Bosun por trás da IU do Grafana. Combinar o painel do Grafanas e os alertas do contramestre por trás da mesma interface tornaria uma solução de monitoramento incrível e completa.

Além disso, acho que seria uma pena fragmentar ainda mais a comunidade de monitoramento de código aberto. Suas idéias sobre monitoramento parecem ser realmente compatíveis com as idéias das pessoas por trás do Bosun. Se vocês se unissem, tenho certeza de que o resultado seria ótimo.

Onde eu trabalho, estamos usando o Elastic para logs / eventos e apenas começamos a usar o InfluxDB para métricas. Temos explorado diferentes soluções para monitoramento e, atualmente, estamos nos inclinando para a Bosun. Já estamos usando o Grafana para painéis, mas gostaríamos de acessar todas as nossas informações de monitoramento através da mesma interface, seria ótimo se o Grafana pudesse se tornar essa interface.

Continue com o excelente trabalho e boa sorte!

Em uma tangente relacionada, obtivemos a parte de alerta trabalhando alertando trabalhando integrando grafana com riemann. Foi um bom exercício conhecer o interior da grafana :).

Isso foi mais fácil com riemann, pois a configuração é apenas código clojure. Imagino que essa integração seja mais difícil no Bosun.

Aqui estão algumas imagens dele em ação

As alterações na parte grafana incluíram adicionar um endpoint "/ alerts" e um "/ subscriptions" e fazer com que ele falasse com outra pequena api que fica por cima para que riemann faça o crud.

O bom é o fato de que as mudanças nas definições de alerta são refletidas imediatamente, sem a necessidade de enviar um SIGHUP para riemann. Portanto, habilitar / desabilitar ajustes de período de tempo para mudanças de estado é apenas uma questão de alterá-lo na IU e fazer com que a mudança se propague para riemann.

Ainda não fiz o benchmarking dessa integração, mas não acho que vai ser tão ruim. Vou fazer um blog sobre isso depois de limpar o código e quando ele entrar no ar.

A razão pela qual fizemos isso foi porque as pessoas podem ir em frente e definir esses alertas e notificações de uma interface de usuário muito familiar e não nos incomodar em escrever configurações de riemann :).

@sudharsh, sua implementação parece muito interessante. Você está planejando lançar isso para a natureza?

muitas boas ideias, obrigado a todos.
Inspirados por alguns dos comentários e pelo projeto https://github.com/pabloa/grafana-alerts de @pabloa , decidimos nos concentrar em primeiro lugar na IU e UX para configurar e gerenciar regras de alerta como parte do mesmo fluxo de trabalho de edição de dashboards e painéis. Grafana salvaria essas regras em algum lugar e fornece acesso fácil a elas para que outros scripts ou ferramentas possam buscar as regras de alerta.
Talvez por meio de um arquivo, uma chamada de API, uma seção na configuração do painel ou uma entrada no banco de dados.
(Gosto da ideia de tê-lo como parte da definição do painel em si, para que os projetos de código aberto possam vir com arquivos json do painel grafana para eles, que teriam regras de alerta incluídas, embora não necessariamente ativas por padrão. Por outro lado, tendo-os em um banco de dados parece mais robusto)
De qualquer forma, queremos fornecer acesso fácil para que você possa gerar configuração para qualquer outro sistema que deseja usar, que realmente executa as regras de alerta e processa os eventos. (daqui em diante, irei me referir a isso como um "manipulador").
Tal manipulador pode ser nagios, ou sensu, ou bosun, uma ferramenta que você escreve ou o tornassol alertador-executor que é um manipulador que você pode compilar em grafana que fornece uma integração simples e agradável apoiada por bosun, mas realmente queremos certifique-se de que pode usar qualquer sistema que desejar.

Contanto que seu manipulador suporte a consulta do armazenamento de dados que você usa. começaríamos com um limite estático simples, mas depois também queremos facilitar a escolha de funções de redução, expressões booleanas entre várias condições, etc.

@sudharsh essa é uma abordagem muito boa. Gosto de como sua solução pode se comunicar diretamente com uma API remota, ignorando a etapa intermediária descrita acima (é claro que isso implica que só funciona para um determinado back-end que tentamos evitar) e que pode recarregar automaticamente a configuração. (você está certo, o bosun atualmente não o suporta, mas pode no futuro. FWIW, o manipulador de tornassol lida com isso e usa o mecanismo de avaliação da expressão do bosun). Nunca gostei muito de riemann. Principalmente, tenho me preocupado em adicionar uma linguagem tão diferente à pilha que muitas pessoas não entendem ou podem depurar quando as coisas dão errado. Mas estou muito curioso para aprender mais sobre seu sistema e sobre o código CLJ de Riemann. (Adoraria se minhas suspeitas estiverem incorretas)

@dennisjac sim, seria opcional.
@elvarb existe um tíquete para ES como fonte de dados . na verdade, o objetivo é que, se o grafana suportar a renderização de dados de uma determinada fonte de dados, também deverá suportar a composição de regras de alerta para ele. Quanto à execução / consulta de consultas, é claro que depende de qual manipulador você decidir usar. (para o manipulador de tornassol, começaremos com os mais populares, como grafite e influxdb)
@rsetzer : concordou, é uma boa coisa ser capaz de especificar por quanto tempo um limite deve ser excedido antes de dispararmos
@falkenbt : Eu acredito que muitas coisas podem ser formuladas como um problema de consulta da série temporal (por exemplo, o exemplo dos pings). Mas você está certo, algumas coisas não estão realmente relacionadas à série temporal e estão fora do escopo do que estamos tentando construir aqui. E acho que está tudo bem: queremos fornecer a melhor maneira de configurar e gerenciar alertas em séries temporais e ter como objetivo a integração com outros sistemas que talvez sejam mais otimizados para o caso de "scripts diversos" (como nagios, icinga, sensu, .. .). Quanto a questões como confiabilidade de entrega, escalonamentos etc, você pode conectar um serviço como pagerduty.
@activars & @falkenbt isso parece corresponder às suas expectativas ou o que você acha que poderia ser melhorado especificamente?
@jemilsson obrigado! e é exatamente assim que eu vejo: bosun é ótimo em alertar, mas não é bom em visualização. Grafana é ótimo em visualização e UX, mas não tem alertas. Estou tentando promover uma colaboração que vai crescer com o tempo, acho

Alguém tem alguma ideia sobre que tipo de contexto enviar em notificações como e-mails?
No mínimo, a notificação deve conter uma visualização dos dados que você está alertando, mas deve ser possível incluir outros gráficos relacionados. Aqui, poderíamos usar o backend de renderização de png da grafana ao gerar o conteúdo de notificação. Também estou pensando em aproveitar o recurso de instantâneo da grafana. como quando um alerta é acionado, tire um instantâneo de um determinado painel para contexto.
e talvez esse instantâneo (página html) possa ser incluído no e-mail, ou isso pode ser um pouco demais de dados / complexidade. além disso, os recursos de javascript não estariam disponíveis em clientes de e-mail de qualquer maneira (então você não seria capaz de ampliar os gráficos em um e-mail). Talvez pudéssemos criar um link do e-mail para um instantâneo do painel hospedado.

Eu gosto da abordagem geral do docker - baterias incluídas, mas removíveis. Portanto, uma implementação de alerta básico que pode ser substituída seria uma boa abordagem imho.

influxdb terá suporte para alertar? ou apenas grafite?

Uma coisa que eu gostaria de ver é a ideia de árvores hierárquicas de alerta. Simplesmente, há muitas facetas sendo monitoradas e os estados de alerta independentes têm uma cardinalidade incontrolável. Com uma árvore hierárquica, posso definir todos esses alertas de baixo nível que aumentam para alertas de nível médio que aumentam para alto nível ......

Assim, cada alerta acumulado assume automaticamente a alta gravidade de todos os filhos abaixo dele. Dessa forma, posso ter uma impressão de [e gerenciar] a integridade do sistema com precisão com uma área de superfície de análise muito menor.

Este é um exemplo que peguei emprestado de um documento antigo que escrevi há pouco. Sim, por favor, ria com o uso da palavra "Struts". É OLD ok? Isso apresenta uma hierarquia muito simples para um servidor.

Em algum ponto, o servidor experimenta 75% de utilização sustentada da CPU, então isso coloca esses alertas em um estado de aviso: CPU- # -> CPU -> Host / OS -> Sistema

Se alguém realmente se aplicasse, poderia ficar de olho em um data center inteiro com um único indicador. (sim, não realmente, mas isso serve como um exercício de pensamento)

Por que não usar o farol de grafite ? Acho que dá para mesclar grafite-beacon que é bem leve com grafana.

@felixbarny Gosto dessa terminologia. provavelmente adotaremos esse texto.
@JulienChampseix sim, o manipulador padrão suportaria / dará suporte ao influxdb
@nickman isso é interessante. na verdade, ele está de acordo com o objetivo final que temos em mente, de ser capaz de criar alertas de alto nível que podem incluir / depender de regras e informações de alerta mais refinadas. bosun já faz isso e, a longo prazo, queremos disponibilizar essa funcionalidade por meio de uma interface mais amigável, mas temos que começar de forma mais simples do que isso.
@amirhosseinrajabi parece um projeto legal e acho que fazer o grafite-beacon em um manipulador para os alertas configurados por meio da interface do grafana faria muito sentido.

@Dieterbe é possível ter uma atualização do status atual? para sistema de alerta
para saber qual sistema é compatível (grafite / influxdb)?
qual assinatura disponível? qual tipo de alerta está disponível?
obrigado pela sua atualização.

no momento, estamos fazendo um protótipo de UX / UI. então estamos longe de ser utilizável.

Oi @Dieterbe

há alguma atualização sobre o andamento do sistema de alerta ??

Seria ótimo ter um alerta no Grafana! Ansioso por este recurso. Alguma atualização agora?

@mattttt você pode fornecer uma atualização sobre seu trabalho de UX?

Sim absolutamente. Carregará algumas telas / fluxos de usuários amanhã.

Precisamos de alertas: UI para definição de regra, API para definição de regra e API para notificações de alerta. Assistirá este tópico com interesse. Temos um sistema multilocatário e adoramos a IU e o back-end do Grafana.

Sim, também estou muito interessado e impaciente por ver este novo recurso!
Muito obrigado Matt! ;)

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

Precisamos de alertas: UI para definição de regra, API para definição de regra e API
para notificações de alerta. Assistirá este tópico com interesse.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -135290295.

Há muitos itens se encaixando internamente, mas eu não queria deixar este tópico negligenciado.

Aqui está uma das maquetes de um painel em que estou trabalhando. Isso ilustra a integridade histórica ao longo do tempo, incorporando o status na dica de ferramenta e usando os limites existentes definidos na configuração do painel para configurar o alerta.

Neste exemplo, é um alerta em uma única consulta com várias séries. As dicas de ferramentas são estendidas para mostrar o status no momento do foco.

_Algumas pequenas questões pendentes _: Quantas informações sobre a notificação de alerta devem ser incluídas na dica de ferramenta, se houver - ou essas informações devem ser acessadas em outro lugar em uma visão mais detalhada? Acredito neste último momento, mas vale a pena perguntar em voz alta.

Configuração, telas de alerta, fluxos de usuário estão chegando lentamente. Muito por vir.

@mattttt nice!

Amei a linha verde e vermelha abaixo do gráfico!

Isso está vinculado aos cálculos de tempo de atividade, adoraria ser capaz de ver isso como um número em algum lugar. Totais para todas as consultas e para cada métrica.

Sobre a dica, você está falando sobre as estatísticas que surgem quando você passa o mouse sobre as linhas?

Droga, @mattttt, isso parece incrível. Eu nem me preocuparia em colocar nada na dica de ferramenta. A linha de limite e a barra de integridade do status de alerta na parte inferior são mais do que suficientes.

Mal posso esperar para ver isso quando estiver pronto!

Estou animado para ver que isso está progredindo bem!

Atualmente, usamos Grafana + Bosun + OpenTSDB como nossa pilha de monitoramento e alerta. Eu definitivamente concordo que seria incrível ter o poder de Bosun com a grande UX de Grafana.

Aqui está um exemplo de onde a UX de configuração do Grafana é melhor do que a do Bosun:

Contexto

Nossa pilha de monitoramento é compartilhada entre várias equipes e seus serviços. Um conjunto diferente de serviços é implantado em diferentes clusters / sites com base nas especificações do projeto. Cada equipe / serviço deve assumir a responsabilidade por seus próprios painéis / alertas.

Comparação

Com a API HTTP da Grafana, as equipes podem COLOCAR seus próprios painéis ao implantar seus serviços. Bosun atualmente tem apenas um único arquivo para armazenar a configuração; isso torna difícil o compartilhamento entre diferentes equipes e entre diferentes projetos.

@mattttt @torkelo @Dieterbe alguma ideia para lançar a peça de alerta (ou versão beta)?

echo ^. É uma versão beta ou alfa para isso? Estou pesquisando soluções de alerta, mas adoraria ter algo construído em grafana. Eu poderia fornecer muitos comentários de teste.

O recurso de alerta ainda está alguns meses no futuro, ainda estamos fazendo um protótipo da IU e pensando em maneiras diferentes de implementá-lo, mas o progresso deve ocorrer mais rapidamente nos próximos 2 meses, então saberemos mais

@mattttt , você pretende tornar configuráveis ​​as cores da barra de integridade histórica? Verde e vermelho não combinam muito bem com daltônicos;)

Em relação ao alerta: estou bastante interessado em saber como isso se desenrola. Já estamos coletando e visualizando dados há algum tempo, e alertar é algo que estamos tentando descobrir. Grafana poderia ter um bom lugar lá, especialmente porque as visualizações já estão no lugar. O que eu me pergunto: quanto deve Grafana estar mais ciente de 'entidades' em vez de séries de métricas para alertar? Posso me imaginar querendo alternar automaticamente uma mudança de estado visual (falha na verificação de ping ou http) ou manualmente (fazendo manutenção) para o que no meu caso seria um servidor, além de alertas baseados em métricas.

É interessante ver para onde vai o alerta no Grafana, mas para aqueles de vocês que precisam de algo agora, existem plug-ins nagios como https://exchange.nagios.org/directory/Plugins/System-Metrics/Others/check_graphite_metric/details que pode disparar alertas quando os limites são ultrapassados.

@baaym

O que eu me pergunto: quanto deve Grafana estar mais ciente de 'entidades' em vez de séries de métricas para alertar? Posso me imaginar querendo alternar automaticamente uma mudança de estado visual (falha na verificação de ping ou http) ou manualmente (fazendo manutenção) para o que no meu caso seria um servidor, além de alertas baseados em métricas.

esta é uma boa pergunta e também algo sobre o qual falamos um pouco.
a solução com a qual queremos chegar a curto (e possivelmente também a longo) prazo é fazer com que a grafana não esteja ciente de tais conceitos de nível superior. ou seja, como usuário, você tem o poder de definir alertas em séries de métricas e, a partir dessas regras de alerta, resultados de alerta serão gerados (provavelmente incluindo atributos ou tags dos nomes das séries) a partir dos quais você pode construir quaisquer entidades que desejar. isso é algo que temos que pensar um pouco mais, mas por exemplo

digamos que você definiu um alerta nas linhas de movingAverage(cluster1.web-*.cpu.idle,10) < 20 -> warn . isso verificaria o limite em todos os seus servidores da web em determinado cluster e geraria alertas para quaisquer violações, como movingAverage(cluster1.web-123.cpu.idle,10) is currently 3! .
possivelmente, poderíamos permitir que você dissesse "o primeiro campo é o nome do cluster, o segundo é o nome do host" etc., para que os alertas possam conter informações mais interessantes.
mas a questão é que o _outcome_ de alerta contém as informações de que você precisa para identificar qual entidade está tendo problemas, mas está fora do escopo da grafana. Grafana seria mais a fonte da configuração de regras de alerta, e os painéis de grafana poderiam ser configurados para carregar anotações e o que você quiser para visualizar o estado dos alertas, mas não teria uma noção de conceitos de alto nível, como hosts ou clusters. Eu acho que isso é algo que poderia ser tratado nos manipuladores de alerta

@Dieterbe

Existem dois tipos de preocupações do usuário / organização ao construir o recurso de alerta:

• Como uma startup, onde geralmente não têm tempo para construir sua própria solução de alerta. Tudo dependeria do Grafana para alertar sobre métricas
• Organização de engenharia estabelecida, eles têm ferramentas de alerta existentes construídas internamente, alertas para regras de negócios são construídos com base em outros sinais de alerta granulares (Grafana seria um deles).

A Grafana deve trabalhar com práticas operacionais bem estabelecidas existentes, tê-la fora do ciclo é ignorar o objetivo de alertar - ter uma visão clara da integridade da entidade crítica para o negócio. O alerta é melhor estar centralizado para permitir a construção de um estado claro do ambiente. Seria crítico permitir que usuários avançados usando a API grafana (ou qualquer outra solução) exportassem regras de alerta para outros sistemas.

Ao dizer operacional, cada alerta deve conter opcionalmente um campo de documentação / link para explicar a finalidade dos alertas e comportamento histórico.

@activars acho que concordo com tudo isso. na minha opinião, estamos adotando uma abordagem que promove a inserção de grafana no resto do ambiente (principalmente graças à separação de interesses, com manipuladores conectáveis). você acha que o design proposto pode ser melhorado de alguma forma?

Eu acho que @ deebs031 é um bom argumento que não foi muito abordado "aplicativos desenvolvidos para usuários finais precisam fornecer alertas definidos pelo usuário".
IMHO the graal é o monitoramento baseado em métricas de autoatendimento , no meu caso o Grafana sendo o principal front-end para as pessoas que desejam olhar para as métricas, faria sentido permitir que eles criassem alertas para si mesmos dentro da mesma - vamos encarar isso IMPRESSIONANTE- UI.
Eu pessoalmente fiz alertas Sensu com base em métricas, mas fornecê-los como um autoatendimento não é realmente um pedaço de bolo em comparação com o quão perfeito seria se integrado ao Grafana. Eu também olhei para o Cabot porque ele tinha recursos de visualização, mas não foi construído com o autoatendimento em mente, então não poderia ser usado como está.
Estou do lado "fazer uma coisa bem", mas acho que, no caso particular de alertas de autoatendimento com base em métricas, o pareamento desse recurso com a camada de visualização de métricas faz muito sentido:

• O usuário já está familiarizado com a IU
• O usuário é autenticado para que possa criar alertas para si mesmo ou qualquer esquema de permissões que a autenticação habilite
• O usuário pode ver os gráficos que normalmente são bastante úteis ao criar esses alertas baseados em métricas

slides da minha apresentação grafanacon sobre alertas:
http://www.slideshare.net/Dieterbe/alerting-in-grafana-grafanacon-2015
são meio difíceis de entender sem contexto, o vídeo deve estar online em cerca de uma semana, vou postá-lo quando estiver pronto.

agora começamos a criar protótipos para implementar os modelos de alerta / IU / definições / etc. temos uma boa ideia do fluxo de trabalho principal, embora um grande ponto que ainda estamos tentando descobrir é como deve ser a integração com manipuladores de alerta de terceiros.
nosso pensamento atual é que você será capaz de usar o grafana para definir limites / regras de alerta / definir notificações e para visualizar o estado histórico e atual das regras de alerta.

a suposição é que você deseja usar o software de alerta de sua escolha (bosun / cabot / sensu / nagios / ...)
portanto, haveria uma ferramenta separada que consulta a grafana em sua API http para recuperar todas as regras de alerta. essa ferramenta pode então atualizar sua configuração bosun / cabot / sensu / nagios / ..., para que você possa usar seu software de alerta de escolha para executar e executar os alertas e enviar as notificações.
mas queremos ser capazes de visualizar adequadamente o estado atual e histórico, então ou seu programa de alerta precisaria ser capaz de chamar um script ou um webhook ou algo para informar a grafana sobre o novo estado, ou a grafana teria que consultá-lo. (o que parece nojento, já que a maioria das ferramentas não parece ter uma boa API)
tudo isso é um pouco complicado, mas teria que ser assim para dar suporte às pessoas para as quais é importante que elas continuem capazes de usar o software de alerta de sua escolha, enquanto usam o grafana para definir as regras de alerta e visualizar o estado.

É importante para você poder usar sua ferramenta de alerta de escolha?

a outra coisa que gostaríamos de fazer, também é escrever um executor de alerta simples, que consulta a grafana api por alertas, agenda e os executa, faz as notificações (suportaria email, slack, pagerduty, um script personalizado e provavelmente alguns outros) e atualiza o estado em grafana novamente.
seria bastante fácil de escrever para nós, fácil para você usar e poderíamos ter uma grande interoperabilidade.

O executor de alerta embutido (veja acima) é algo que você acha que seria suficiente para lidar com todas as regras de alerta que você configurou no grafana?

também deseja poder usar vários manipuladores de alerta? que ?

@jaimegago amen;)

Para mim, o número 2 parece melhor porque você pode realmente minimizar o número de coisas que você precisa configurar para que tudo funcione perfeitamente. Em nossa configuração atual, iríamos com isso.

Assim foi dito se todos os outros discordarem;)

Edição rápida: slides incríveis. Se o produto final sair com a mesma qualidade, então é incrível.

+1
Eu concordo que o gerenciador de notificação interno com essas integrações é perfeito! para o caso de uso mais comum.

Ficarei feliz em fazer o Beta Testing :) e os slides serão incríveis!

Acho que o último post de @Dieterbe esclarece um pouco as coisas, mas eu queria postar este diagrama rápido para esclarecer melhor.

Alertar no Grafana é realmente duas coisas, a configuração de alerta de autoatendimento (obrigado @jaimegago , eu não poderia ter falado melhor) e o próprio manipulador.

Enviaremos um gerenciador de alertas Grafana, mas também forneceremos a estrutura para integração com o software de alerta de sua escolha:

1 para construir uma espécie de ponte para outros sistemas de alerta (talvez pudéssemos pensar em implementar algum sistema de plugin de alerta genérico :-))

Você pode adicionar Prometheus também na parte "Manipuladores de alertas externos". A primeira versão do Prometheus alertmanager está em produção em várias empresas e uma reescrita completa está em andamento. O SoundCloud pode usar o Grafana para configurar alertas, mas certamente apenas se o alertmanager do Prometheus for usado como gerenciador de alertas.

@grobie , boa pegada, corrigido no comentário original.

@mattttt @Dieterbe isso é ótimo! Parece que você está no caminho das "baterias incluídas, mas removíveis", que IMHO é o melhor dos dois mundos. Você já pensou em como vai passar os dados de autorização para o gerenciador de alertas? Estou pensando em uma história como esta:
Como um usuário do Grafana, gostaria de ser alertado via _email_ e / ou _pagerduty_ e / ou _foo_ quando (alguma condição criada por meio da IU de alerta do Grafana) acontecer.
Esse usuário só deve ser capaz de enviar alertas para o sistema de notificações para o qual está autorizado, isso é um requisito para o autoatendimento e precisará ser resolvido de alguma forma. Desde o Grafana 2, temos um backend SQL + autenticação / autorização de usuários com integração LDAP, então não parece muito difícil ter esse recurso desde o primeiro dia de alerta?
Com o Sensu (que é a ferramenta que eu conectaria), passar o alvo do alerta (por exemplo, endereço de e-mail) pelo manipulador deve ser bastante direto, não posso dizer sobre os outros.

Olá a todos,
Fico feliz em ver que essa capacidade está aumentando, pois adoro a abordagem de configuração de alerta de autoatendimento.

Pessoalmente, não preciso de um gerenciador de alertas específico. Gostaria de ver um manipulador HTTP POST genérico, que só é acionado assim que um alerta é lançado. Acho que a maioria dos administradores pode construir rapidamente algo que seja capaz de aceitar HTTP e, em seguida, fazer o que for necessário com ele (enviar para nagios, riemann, younameit). Portanto, ficaria feliz com um manipulador HTTP que envia todas as informações sobre um alerta como dados JSON.

Falando em alertar via grafana, vocês planejam adicionar algo como detecção de oscilação? Ou isso é algo que o sistema de monitoramento externo deve cuidar?

Continuem com o bom trabalho, pessoal!

Saúde

Gostaria de ver um manipulador HTTP POST genérico, que só é acionado assim que um alerta é lançado. Acho que a maioria dos administradores pode construir rapidamente algo que seja capaz de aceitar HTTP e, em seguida, fazer o que for necessário com ele (enviar para nagios, riemann, younameit)

portanto, se um alerta for disparado (digamos "web123 has critical cpu idle !, valor 1 inferior ao limite 15") e postarmos esses dados em http, como você lidaria com isso no nagios? você quer dizer que nagios consideraria isso como uma verificação de serviço passiva e, em seguida, nagios enviaria as notificações?

Falando em alertar via grafana, vocês planejam adicionar algo como detecção de oscilação? Ou isso é algo que o sistema de monitoramento externo deve cuidar?

isso também é algo em que precisamos pensar mais. Isso pode ficar confuso e se as pessoas usarem algo como pagerduty ou flapjack, eles podem usar isso para agregar eventos / suprimir duplicatas, então estamos procurando se podemos evitar a implementação disso no manipulador de grafana, embora possamos ter que fazer. Observe também que, como você será capaz de definir alertas em expressões de consulta de métricas arbitrárias, terá muito poder para levar em consideração dados anteriores na expressão real e, assim, poderá criar um sinal mais robusto na expressão que não muda de estado com tanta freqüência.

portanto, se um alerta for disparado (digamos "web123 tem cpu crítica ociosa !, valor 1 inferior ao limite 15") e fizermos uma postagem> http desses dados, como você lidaria com isso no nagios? você quer dizer que nagios iria considerá-lo como uma verificação de serviço passiva e, em seguida, nagios enviaria as notificações?

Tipo de. Na verdade, estou ansioso pelo alerta da grafana para me livrar dos nagios. Usando o manipulador HTTP, você precisa configurar verificações passivas para que nagios possa enviar os resultados lá. Mas eu gostaria de ter a grafana como a única fonte onde você pode configurar o alerta. Em nosso caso, as pessoas que têm permissão para adicionar alertas são o administrador do sistema real, que também configuraria as verificações no nagios.

Com o handler http a grafana teria tudo o que precisamos para isso: um painel para monitoramento em tempo real, uma API, fácil configuração de alertas e um handler http onde podemos encaminhar alertas para nosso sistema interno de notificação.

Saúde

Embora eu possa ver a lógica dessa estratégia de integração, não posso deixar de pensar que é um pouco exagero. Pelo que entendi (e pelo que pude ler no tópico), a única razão pela qual a maioria dos usuários do Grafana continua usando uma tecnologia de alerta autônoma é que o Grafana não propõe uma. Portanto, não seria mais "enxuto" focar primeiro na parte do Alerta Grafana e desenvolvê-lo como um componente que se comunica com o resto da pilha por meio da API, para que outros contribuidores possam imitar o comportamento e criar adaptadores específicos mais tarde?

tl; dr: concentrando-se primeiro na construção de suas próprias "baterias", a Grafana teria um sistema de alerta completo, que mais tarde pode evoluir para um serviço de integração com ferramentas de alerta de terceiros.

Preocupação menor, se isso não tiver sido resolvido. O sistema de alerta tradicional não se adapta bem à infraestrutura em nuvem, porque os recursos são muito dinâmicos (provisionados e destruídos). Os alertas sobre métricas devem oferecer suporte ao recurso tentador ou de agrupamento (com substituição de exceções, às vezes as cargas de trabalho são diferentes). Um alerta de modelo ou agrupado deve ser capaz de descobrir um novo conjunto de grupos.

Obrigado pela atualização! No meu caso de uso, o alerta integrado no Grafana é tudo de que preciso neste momento. Tenho esperado pacientemente e impacientemente pelo alerta de Grafana.

Como prometi no IRC, aqui está nosso caso de uso para isso:

Temos um aplicativo Rails legado que searches our logs para patterns e tem um
API HTTP para responder se um determinado pattern cruzou seu thresholds e
portanto, tem um status de {OK,WARNING,CRITICAL} .

Threshold pode ser:

• um status de CRITICAL se pattern existir.
• que status é WARNING se pattern for encontrado mais de X vezes
  e status é CRITICAL se encontrado mais de Y vezes.
• se pattern tem menos de 1 hora, então status tem OK ,
  menos de 3 horas status é WARNING e, caso contrário, status é
  CRITICAL .

Se eu entendi esse recurso corretamente, o Grafana oferecerá suporte para esse uso
padrão (via Logstash e Elasticsearch, é claro) quando esse recurso e
a fonte de dados Elasticsearch está totalmente implementada?

@Dieterbe @mattttt seus slides e maquetes parecem absolutamente incríveis! Esta é realmente uma virada de jogo.
Para mim, o gerenciador de alertas interno da Grafana seria o que atenderia melhor às nossas necessidades.
Razões:

• Autoatendimento - Muito importante . Nossos usuários disseram em alto e bom som que desejam criar alertas de ponta a ponta dentro do Grafana.
• Fluxo de trabalho unificado - quero minimizar as peças móveis, não aumentá-las. Como @Dieterbe apontou, um manipulador de alerta de terceiros exigiria pelo menos 4 etapas,
• Integração total e sem dependência de infraestrutura de alerta de terceiros.

Algumas preocupações:

• Quais são os limites de verificação de frequência?
• Como ele lida com a frequência de pesquisa que é muito rápida para obter os dados de volta? Registrar, alertado e enfileirado ou descartado?
• Para dimensionamento, estamos preocupados com o fato de que o Grafana pode não ser capaz de acompanhar o grande número de verificações, a frequência rápida e, especialmente, a latência entre as fontes de dados que provavelmente precisaremos adicionar / dimensionar os servidores Grafana para oferecer suporte a alertas internos. Eu sei disso porque precisamos de várias instâncias do manipulador de alertas de terceiros agora. Nesse caso, como poderíamos atribuir ou enfileirar verificações de limite perfeitamente em um cluster de servidores Grafana, especialmente se as verificações forem da mesma fonte de dados? A partir da experiência do usuário, gostaria que os usuários criassem limites perfeitamente por meio de um cluster de servidores Grafana com balanceamento de carga, sem que os usuários acessem uma instância específica "atribuída" do Grafana para uma verificação específica.
• Para notificações, isso suportaria algum tipo de arquitetura de plug-in para que as notificações possam ser facilmente desenvolvidas e integradas? Em geral, precisamos de algo que possa realizar POSTs HTTP. Isso é mais comum com os gostos de PagerDuty, xMatters, VictorOps, Opsgenie, etc. Cada um requer um formato ligeiramente diferente, autenticação, etc. Como mencionado anteriormente neste tópico, talvez um manipulador HTTP POST genérico funcione que enviaria para um serviço HTTP personalizado capaz de fazer o que você quiser com ele. Como alternativa, um recurso de script personalizado também deve funcionar.
• Presumo que os limites possam ser definidos, recuperados e obter violações por meio de uma API. Eu acho que isso seria útil

Acho que é ideal ser capaz de integrar alertas aos sistemas de alerta existentes. Existem alguns problemas difíceis e feios, como a detecção de flaps, conforme mencionado, que foram resolvidos e parece um desperdício reinventar tudo desde o início. Eu odiaria ver isso enterrado sob o peso do recurso creep.

Mas não acho que isso realmente precise ser uma integração forte em todos esses manipuladores de alerta. Uma API boa e bem documentada deve permitir que as pessoas familiarizadas com esses sistemas se integrem com pouco esforço. Portanto, o slide com 'grafana api -> handler' é o que me parece atraente.

Scott

Olá a todos - estou chegando atrasado a esta discussão, mas tenho algum conhecimento neste tópico e sou o desenvolvedor-chefe de uma das ferramentas que tentou resolver o problema de alerta. Nossa ferramenta, StatsAgg , é comparável a programas como o bosun. StatsAgg visa cobrir alertas flexíveis, suspensões de alertas e notificações e é bastante maduro / estável neste ponto (embora a API não esteja pronta).

De qualquer forma, algumas reflexões sobre o tema do alerta:

• Alerta por métricas individuais é uma merda. Eu trabalho em uma empresa que gerencia milhares de servidores e ter que criar / configurar / gerenciar alertas separados para cada série métrica de '% de espaço livre em disco' é logisticamente inviável. As ferramentas de monitoramento corporativo geralmente unem várias séries de métricas com expressões regulares (ou apenas expressões curinga). StatsAgg foi construído na mesma premissa; várias séries de métricas são vinculadas e, em seguida, o grupo de métricas tem as verificações de limite de alerta executadas contra ele por um único 'alerta'. Em escala, esse tipo de capacidade é uma necessidade.
• Se alguém aceitar minha afirmação anterior de que uma ferramenta de alerta não deve alertar sobre métricas individuais, segue-se que a ferramenta deve ter um mecanismo para obter rapidamente uma lista de métricas de qualificação e valores de métricas. Muitas ferramentas dependem dos armazenamentos de dados de consulta para obter a lista de métricas e valores de métricas, e esta solução francamente não funciona muito bem em escala. A lógica de alerta, por sua natureza, precisa ser executada com frequência (a cada X segundos ou à medida que cada novo ponto de dados de qualificação entra). Os armazenamentos de dados (grafite, opentsdb, influxdb, etc) simplesmente não foram construídos para lidar com consultas constantes de 'me dê a lista atual de métricas que estão em conformidade com este padrão' e 'mostre-me os últimos valores X para essas métricas Y'. Eles não têm a linguagem de API / consulta apropriada ou simplesmente não conseguem lidar com a carga. Para ser claro, estou falando sobre escalas de execução de lógica de alerta em relação a 10.000 séries de métricas quando há 10.000.000 de séries de métricas disponíveis no armazenamento de dados. Este não é o caso de uso de todos, mas é da minha empresa.
• Descobri que lidar com o problema por meio do processamento de fluxo é a única maneira viável de resolver os problemas levantados por meu último ponto. É por isso que o StatsAgg foi criado para ficar na frente do armazenamento de dados. A lógica de alerta pode ser executada nas métricas sem tocar no armazenamento de dados, e as métricas apenas passam para o armazenamento de dados. Os principais conceitos desta abordagem são que 1) alertas recém-criados não podem / não usarão valores métricos antigos / arquivados para avaliação de alerta 2) se o programa de processamento de fluxo (ex-StatsAgg) falhar, os pontos de dados não o farão no armazenamento de dados 3) os valores de métrica necessários para avaliação de alerta são armazenados na memória, o que pode ser uma preocupação com a estabilidade do servidor. 4) o programa de processamento de fluxo deve ser capaz de desconstruir e reconstruir as métricas de entrada (o que o InfluxDB não facilitou no ano passado ...). Mesmo com esses conceitos, essa solução funcionou muito bem para minha empresa e em uma escala muito grande. Às vezes, tivemos mais de 200.000 séries de métricas ao vivo, médias de 30k + métricas de entrada / s, centenas de alertas que avaliam milhares de séries de métricas e um servidor rodando StatsAgg que mal se esforça. O tempo todo, o armazenamento de dados não é consultado.

Essas são as principais coisas que gostaria de mencionar. Existem muitos outros aspectos importantes para alertar também (notificações, suspensões, etc), mas essas soluções são fáceis de implementar, uma vez que a arquitetura do problema principal foi resolvida. Sei que a escala de nossas necessidades não é a mesma do usuário médio, mas espero que todos possam apreciar essa perspectiva.

Eu gostaria de sugerir o lançamento com um gerenciador de notificação que pode enviar dados para Alerta: https://github.com/guardian/alerta

Alerta tem uma API REST muito sã para receber notificações.

Eu prefiro uma implementação enxuta de grafana apenas!
Acho que vale a pena reavaliar depois que todos já tiveram experiência com esse recurso no típico fantástico Grafana UX.

Haverá muitos casos complexos e / ou sistemas back-end personalizados com os quais as pessoas vão querer se integrar. Você pode ver muitos neste tópico, a maioria de código aberto, mas há muitos produtos comerciais por aí também! Não se preocupe com manipuladores individuais - será um rato inteiro e você sempre estará em modo de captura

Eu recomendo fortemente implementar apenas dois tipos de manipuladores. Um é definitivamente o HTTP POST, será a ferramenta mais versátil e flexível. O outro é o script customizado, para que os usuários possam implementar a integração com sua ferramenta específica de escolha. O modelo de plug-in não é ruim, mas força o uso de uma linguagem de plug-in específica, o que é limitante. Scripts externos são melhores - contanto que você passe para um script todos os detalhes do script podem ser escritos em qualquer linguagem - script de shell, Python, etc.

Estou com @ 007reader

Eu concordo. Desde que sejam fornecidos métodos de integração comuns, a implementação customizada pode ser um projeto ou implantação separada.

Por exemplo, o lançamento recente do CloudWatch é decente, no entanto, eu adoraria fazê-lo como um projeto separado por apenas métricas selecionadas síncronas para armazenamento alternativo. Isso nos dará retenção total em vez de apenas 2 semanas de dados.

ei todo mundo,
meu vídeo de apresentação grafanacon está online!
está em https://www.youtube.com/watch?v=C_H2ew8e5OM
acho que vai esclarecer muito, embora como você pode ver. os detalhes das integrações ainda precisam ser descobertos e também foi um tópico que muitas pessoas queriam discutir. (embora o tempo fosse limitado e eu pedi às pessoas que continuassem a conversa aqui para que todos pudessem participar)

@simmel sim exatamente. você usaria uma consulta ES e definiria uma regra sobre isso.
@activars re agrupamento e descoberta, acho que muito disso vai depender de sua fonte de dados, mas os requisitos mais comuns devem ser atendidos se você usar algo como grafite ou ES que eu sei que são muito bons em "descoberta automática" de métricas / séries nunca vistas anteriormente / documentos que correspondem à expressão dada (com curingas) para grafite ou consulta (para ES). não tenho certeza sobre as outras fontes. seu comentário sobre a necessidade de aplicar exceções às regras é mais complicado, provavelmente precisaremos abordar isso em algum momento, mas acho que podemos esperar até que as coisas estejam mais claras e mais estabelecidas. talvez possamos evitar precisar disso de alguma forma.
A frequência
@sknolin se bem entendi, na sua opinião, a grafana faria o agendamento de alertas, execução, acionar ganchos de notificação, etc, mesmo quando usando outro sistema como nagios / bosun. então qual seria exatamente o papel do sistema externo (nagios / bosun / ...). isso também parece semelhante ao que @Crapworks estava falando.
@ jds86930 StatsAgg parece bastante interessante. Acho que aqui também faria sentido uma integração com a grafana. Eu acho que o processamento de fluxo é uma abordagem válida que tem um lugar como uma alternativa para consultas repetidas. mas o último é apenas mais simples para começar e apenas mais simples em geral, eu acho. Mas ambos devem ser apoiados. Então, sim, no grafana você será capaz de configurar padrões / consultas que correspondam a um espectro de dados e, potencialmente, cobrir novas séries / dados à medida que se tornam ativos. em nossa visão, porém, você apenas aproveitaria qualquer funcionalidade que sua fonte de dados tenha (por exemplo, o grafite é muito bom nisso com seus curingas, expressões glob, etc. e dados ricos de elasticsearch e modelo de consulta), ou se alguém usasse grafana + StatsAgg, eles poderiam basta usar StatsAgg para resolver isso. Você está dizendo que a própria grafana deve fazer algo específico aqui? Eu acho que se sua fonte de dados não for rápida o suficiente, resolva o problema da fonte de dados. obtenha algo mais rápido, que tenha cache para metadados métricos, talvez um servidor de memória na frente ou processamento de fluxo. mas de qualquer forma, no que diz respeito a Grafana, não mudaria muito do que eu posso pensar?
@blysik sim parece interessante. tantas ferramentas de alerta que devemos integrar com :) para ser claro, você gosta da ideia de gerenciar regras de alerta e visualizá-las na grafana da forma como foi apresentado até agora, mas você deseja usar o alerta para cuidar das notificações ? O alerta seria o lugar principal onde você analisa o estado de seus alertas (parece uma coisa razoável a se fazer), mas quero ter certeza de que entendi perfeitamente como você vê a integração.

@ 007reader , @shanielh , @activars só para ficar claro, essa integração via um post ou script HTTP genérico, qual seria o objetivo. dizer ao sistema externo "há uma nova regra, aqui está a consulta, os limites, a frequência, etc. agora vá por favor execute-a"? ou seria a grafana quem executava as regras e depois atualizava os sistemas externos com o novo estado?

@blysik sim parece interessante. tantas ferramentas de alerta que devemos integrar com :) para ser claro, você gosta da ideia de gerenciar regras de alerta e visualizá-las na grafana da forma como foi apresentado até agora, mas você deseja usar o alerta para cuidar das notificações ? O alerta seria o lugar principal onde você analisa o estado de seus alertas (parece uma coisa razoável a se fazer), mas quero ter certeza de que entendi perfeitamente como você vê a integração.

Correto. Alerta está se transformando em nosso hub de notificações. Todo tipo de coisa enviando alertas para ele. Por exemplo: scripts personalizados, Cabot, Zenoss, vCenter e talvez Grafana. Isso dá aos ops um único lugar para ver todos os alertas. E esse é o único lugar que direciona as notificações ao engenheiro do oncall.

@sknolin https://github.com/sknolin se bem entendi, em seu
view, grafana faria o agendamento de alerta, execução, gatilho
ganchos de notificação, etc, mesmo ao usar outro sistema como
nagios / bosun. então qual seria exatamente o papel do sistema externo
(nagios / contramestre / ...). isso também parece semelhante ao que @Crapworks
https://github.com/Crapworks estava falando.

Acho que não expliquei bem. Não é isso que eu quero, grafana não
fazendo todas essas coisas. @Crapworks (divertido de digitar) é falar passivamente
verificações de serviço, eu apenas usaria a sondagem ativa.

Então, tudo que eu quero é uma API onde eu possa ler o status dos alertas de grafana.
Os sistemas externos fazem todo o resto.

Isso não significa que se de alguma forma não se tornou um grande general
ferramenta de alerta que eu não usaria. Exatamente o que eu faria agora.

Scott

@sknolin

Então, tudo que eu quero é uma API onde eu possa ler o status dos alertas de grafana.

como esse status seria atualizado na grafana? qual processo estaria executando alertas e atualizando o status na grafana?

Cada vez que é pesquisado, o grafana atualiza o status de alerta, com algum tipo de intervalo de cache para lidar com vários sistemas que o pesquisam.

Vejo o ponto que isso ainda requer que a grafana faça lógica para os alertas e apresente-a. Então pensando nisso, não, eu não preciso de alertas de nenhum tipo.

Acho que poderia fazer qualquer alerta necessário se conseguisse recuperar o valor atual de uma métrica em um painel gráfico. Por exemplo, onde derivamos uma taxa da soma de várias métricas de contador e a representamos graficamente, seria bom pesquisar o valor atual com o sistema de monitoramento. Talvez isso seja totalmente factível agora e eu estou apenas sendo obtuso.

Scott

@Dieterbe O último:

grafana ser a coisa executando as regras e depois atualizando os sistemas externos com novo estado

@Dieterbe Concordo que pesquisar a fonte de dados (Graphite, OpenTSDB, etc) usando a sintaxe de consulta nativa da fonte de dados é mais simples / fácil e provavelmente a maneira mais rápida de obter alguma forma de alerta nativamente no Grafana. Para muitas pessoas, esse tipo de solução vai atender às suas necessidades, e acho que essa é a melhor solução para a implementação inicial do Grafana (na minha opinião). Meu ponto principal é que há um limite máximo para configuração e desempenho de alerta que será difícil superar com o modelo de 'pesquisa da fonte de dados'.

Em termos de direções que Grafana poderia seguir para soluções de alerta de longo prazo, eu pude ver algumas opções:

• Trabalhe com os mantenedores do armazenamento de dados para construir APIs mais rápidas / melhores para o caso de uso de alerta. Não gosto dessa opção porque muitos desses projetos se movem em um ritmo mais lento (meses a anos) e eles podem não aceitar alguns / todos os pedidos de aprimoramento. Eles provavelmente também querem codificar na linguagem nativa de seus armazenamentos de dados, que nem sempre são linguagens rápidas (ex-Grafite em python).
• Crie camadas de processamento de fluxo / armazenamento em cache para cada armazenamento de dados como projetos raintank separados. Acho que, em última análise, isso teria um resultado melhor do que tentar persuadir os vários mantenedores do armazenamento de dados a criar soluções para seus projetos. Isso também permitiria que você continuasse a expandir o trabalho que já está fazendo (usando os mecanismos de consulta do armazenamento de dados existentes). Você pode até construir suas próprias APIs personalizadas nas camadas de processamento de fluxo / cache que podem simplificar a sintaxe de consulta do Grafana para o armazenamento de dados.
• Fique com a solução nativa na qual você está trabalhando e faça com que funcione bem. Ferramentas de terceiros como StatsAgg, bosun, etc estarão disponíveis para casos de uso que são mais exigentes / especializados / complexos. Ter o Grafana integrado com essas ferramentas seria definitivamente um benefício adicional para o usuário, mas acrescentaria uma complexidade não trivial ao Grafana. Dito isso, parece que você pode acabar fazendo isso de qualquer maneira (estou vendo 'Alertando back-ends' no slide 35 da sua apresentação agora). Pessoalmente, estou aberto para implementar um conjunto de APIs amigável ao Grafana no StatsAgg; teríamos apenas que descobrir como são as APIs e obter um esboço da documentação do protocolo da API. Sinta-se à vontade para me enviar uma mensagem / e-mail se desejar discutir algum desses assuntos.

Olá a todos,

@Dieterbe Acabei de assistir sua apresentação e o material está incrível. Eu realmente aprecio que você esteja tentando construir um sistema de alerta da maneira "certa", usando muitas contribuições da comunidade! Obrigado!

Também quero deixar meu ponto um pouco mais claro, pois não acho que era óbvio o que eu estava tentando dizer. EU _NÃO_ exijo que a grafana esteja ciente de qualquer outro sistema de monitoramento como Nagios, Icinga, Bosun, etc. Na verdade, só preciso disso:

• A incrível interface do usuário que você mostrou em sua apresentação ou o que quer que pareça quando está completamente acabada
• Um manipulador HTTP POST genérico (como algumas outras pessoas aqui também sugeriram) que é completamente configurável (darei um exemplo mais tarde)

O fluxo de eventos em que estou pensando:

• Você visualiza seus dados em grafana
• Você adiciona limites para alertar em grafana
• Assim que um limite é excedido, o manipulador HTTP POST é acionado
• A partir daí, o trabalho da grafanas está feito

Como @mgravlin e @ 007reader mencionados, a maioria dos serviços de notificação e alerta usa HTTP POST, exigindo diferentes tipos de dados. Então, a coisa mais genérica que eu poderia pensar é deixar o usuário definir seus dados e cabeçalhos POST, para que você possa alimentar vários sistemas com um manipulador, usando modelos diferentes. Exemplo de pseudocódigo:

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

Fornecer ao usuário variáveis ​​suficientes para usar aqui será poderoso o suficiente para alimentar uma tonelada de back-ends.

E, novamente, com esse tipo de manipulador, qualquer administrador de sistema com algum conhecimento de codificação pode construir seu próprio receptor de postagem http e transformar como quiser, por exemplo, back-ends de feed que não entendem postagem de http.

Como não tem estado, ele também pode ser escalado horizontalmente. Basta colocar um balanceador de carga na frente do back-end / api / qualquer que seja e pronto.

Pelo menos, isso resolveria a maioria / quase todos os meus problemas;)

Saúde

Obrigado por construir este recurso. Existe uma data de lançamento aproximada para isso?

torkelo disse ROUGHLY 3 meses no IRC.
Se eu o entendi corretamente, essa é uma estimativa muito aproximada e deve ser tratada como tal.

Estou animado com a capacidade de fazer alertas com a grafana. Acho que esse é o único recurso que está impedindo o grafana de ser a ferramenta de monitoramento definitiva.

Se você tiver uma versão alfa / beta antecipada, eu adoraria testar e fornecer feedback antecipado com dados de produção.

++

Eu 2 rs

+1

Em seg, 16 de nov de 2015 às 21:03, Jing Dong [email protected]
escreveu:

Se você tiver uma versão alfa / beta antecipada, eu adoraria testar e dar mais cedo
feedback com dados de produção.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -157202686.

+1
Se você tiver uma versão alfa / beta antecipada, eu adoraria testar e fornecer feedback antecipado com dados de produção.

+1 me 2

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

+1
Se você tiver uma versão alfa / beta antecipada, eu adoraria testar e dar o mais cedo possível
feedback com dados de produção.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -158661279.

+1

ótimo ver todos os + 1s, mas FWIW eles não são realmente necessários. já sabemos que é o novo recurso mais aguardado e, assim que tivermos um progresso tangível, o código aparecerá em um branch separado com o qual todos podem brincar. Aliás, também estamos trazendo mais pessoas para trabalhar em tempo integral na grafana, então fiquem ligados, todos :)

Sim, por favor, há 484 pessoas "assistindo" esta edição. Cada vez que você "marca com +1", 484 pessoas recebem uma notificação por e-mail. Basta se inscrever para receber uma notificação e ela será uma indicação de seu interesse pelo assunto.

+1>; P

Na segunda-feira, 30/11/2015 às 10:33:52-0800, Vadim Chekan escreveu:

Sim, por favor, há 484 pessoas "assistindo" esta edição. Cada vez que você "marca com +1", 484 pessoas recebem uma notificação por e-mail.

Sory, sei que vocês estão trabalhando muito nisso. Existe alguma linha de tempo para o primeiro lançamento?

Eu ficaria mais do que feliz em poder configurar métricas e limites de alerta (por meio da interface da web ou API) e um cronjob / daemon Grafana que verifica essas métricas e faz um HTTP POST com JSON ou invoca um script com JSON em stdout. Seria _extremamente_ simples para os indivíduos escreverem um script python simples que passasse essas informações para Pagerduty, Slack, IRC, SMS, e-mail ou qualquer outro.

Embora eu aprecie muito a conveniência, não acho que seja o trabalho da Grafana integrar-se totalmente com ferramentas de terceiros e preferiria ver uma implementação minimalista mais cedo do que uma bem elaborada mais tarde.

Eu concordo totalmente com @anlutro . Forneça algo simples para começar. O mais interessante para mim é permitir que as próprias pessoas definam alertas simples (self-service). O Grafana não deve tentar substituir as soluções de alerta / escalonamento existentes.

Também concordo com @anlutro . Mas, em vez de apenas fornecer uma API simples, tenha a parte de alerta capaz de lidar com plug-ins personalizados que interagem com a API. Dessa forma, o pacote básico pode incluir e-mail, pagerduty e alguns outros que a comunidade pode adicionar conforme necessário. Semelhante a como os plug-ins Logstash são tratados agora.

+1

Alguma notícia sobre o sistema de alerta? Alguma estimativa?

+1

+1
Vale mencionar que o mecanismo de hits e histerese funciona nos alertas do collectd como um conceito a ser considerado.

Você já pensou em recursos de alerta avançados, como detecção de anomalias, detecção de correlação, detecção de causa raiz, etc?

+1. Alerta como um subsistema de plug-in - essa seria a solução mais flexível. Não há necessidade de adicionar tantos recursos dentro do grafana se houver muitos projetos que podem fazer isso melhor no backend.

@Dieterbe @torkelo Seria ótimo ter até mesmo uma estimativa muito aproximada sobre isso. Pessoalmente, tenho esperado desde que o alerta de autoatendimento baseado em métricas é um recurso muito necessário no meu caso e estou convencido de que o Grafana é o front-end de usuário certo para ele. O problema é que já se passaram 6 meses e não houve nenhuma atualização do ETA ou mesmo um comentário de um de vocês por um bom tempo, então estou começando a ter pensamentos contraproducentes do tipo "vou ter que hackear algo". ..Se eu pudesse saber se vai demorar mais 6 meses versus mais algumas semanas, eu poderia tomar uma decisão muito mais informada.

Obrigado!

+1
Em 18 de janeiro de 2016, 21:54, "Jaime Gago" [email protected] escreveu:

@Dieterbe https://github.com/Dieterbe @torkelo
https://github.com/torkelo Seria ótimo ter até mesmo um
"guesstimate" sobre isso. Pessoalmente, tenho estado segurando desde as métricas
o alerta de autoatendimento com base é um recurso muito necessário no meu caso e estou
convencido de que Grafana é a interface de usuário certa para isso. O problema é que agora é
há 6 meses e não houve nenhuma atualização do ETA ou mesmo um comentário de um dos
por um bom tempo, então estou começando a ter "Eu só vou ter que
hackear algo "pensamentos contraproducentes ... Se eu pudesse saber se é
vai demorar mais 6 meses versus mais algumas semanas, eu poderia ganhar muito
decisão mais bem informada.

Obrigado!

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -172722684.

+1

+1

@jaimegago realmente sinto muito por não ter atualizado aqui sobre nosso progresso ou falta de progresso neste assunto. Achávamos que teríamos tempo para dedicar a isso, mas sempre acabava sendo pressionado porque algo com maior prioridade atrapalhava.

Em setembro, comecei a trabalhar no suporte da fonte de dados Elasticsearch, que se tornou a base para uma versão 2.5 focada na fonte de dados. Depois disso, o problema com maior classificação no Grafana desde a v1 foi um painel de mesa e, especialmente após o suporte do Elasticsearch, senti uma pequena versão com uma mesa painel era mais importante do que alertar, de modo que se tornou a base para 2.6.

Ultimamente, temos muitos usuários e empresas querendo se integrar mais com o Grafana, o que nos levou a trabalhar na melhoria da API e dos recursos do plugin, o que resultou em outro adiamento para este problema. Lamento muito que tenhamos comunicado isso tão mal. Sempre tivemos a ambição de começar LOGO, mas EM BREVE foi pressionado continuamente :(

Mas há esperança! Expandimos o time focado em Grafana em tempo integral, em dezembro @bergquist se juntou e em fevereiro estaremos recebendo reforço mais uma vez. Não posso oferecer um HEC, mas esse ainda é um problema de alta prioridade e queremos começar o mais rápido possível. Queremos que esse recurso seja o título do Grafana 3.0.

@torkelo Obrigado pela atualização; Não posso dizer que estou feliz, mas pelo menos sabemos onde estamos.

Uma questão restante é se 2.x obterá mais lançamentos pontuais ou se 3.x será o próximo lançamento. ;)

@RichiH com relação a outro lançamento pontual, não tenho certeza, mas é provável que outro lançamento pontual antes do 3.0 seja lançado em fevereiro.

@torkelo Muito obrigado por nos fornecer uma atualização detalhada.

talvez isso já esteja no roteiro, se não, considere adicionar o "POST" a partir da notificação.
Assim, podemos enviar o alerta para um sistema diferente para processá-los, como kafak

1 para notificações SNMP!

+1 Acho que esse é o maior recurso que falta no Grafana para torná-lo uma ferramenta de monitoramento de produção viável (e a melhor da classe).

+1

Qualquer administrador (@Dieterbe?) Disponível para bloquear comentários sobre este problema de não-colaborador? Portanto, só obteremos conteúdo interessante sobre o avanço do recurso, e não aqueles +1 inúteis ...

Caso você não conheça esse recurso, aqui está o link para o documento ad hoc do GitHub .

Obrigado: coração:

@Mayeu uh, como um dos "não colaboradores" que contribuiu com mais de um +1 para esta edição e em outros lugares não acho que deixar essa questão para colaboradores seja o caminho a percorrer. Basta criar um filtro inteligente em seu e-mail ;-).

Eu também acho que os + 1s preenchem um propósito, mostrando a quantidade e o spread dos juros para isso (e em outros lugares).
O que está faltando, talvez, é um botão +1 na IU que ocuparia a mesma função, mas sem todas as notificações para todos os assinantes .. então, uma solicitação de recurso para @github.

Estamos mudando de assunto e esta é a primeira e a última vez que escreverei sobre isso.

Quem estiver interessado neste assunto deve se inscrever no canto superior direito; isso o manterá informado e você não enviará e-mail para todos.

Quanto ao sistema de votação para evitar o acúmulo de +1, consulte https://github.com/dear-github/dear-github - 27 dias desatualizado e nenhuma reação do GitHub.

+1

Alguma notícia sobre isso?

Acho que ainda não há notícias sobre esse assunto. Mas uma coisa boa sobre o próximo lançamento do Grafana é:

Grafana será capaz de entregar aplicativos / plug-ins personalizados. Então, podemos escrever nossos próprios plug-ins / aplicativos de alerta personalizados e importá-los para o Grafana. Escrever esses pequenos aplicativos / plug-ins será uma vitória rápida enquanto se espera por um grande recurso de alerta.

Gosto da ideia de configurar alertas no mesmo lugar da visualização. Mocks incríveis em https://www.youtube.com/watch?v=C_H2ew8e5OM, mas há alguma data sobre quando será lançado?

bom vídeo, obrigado!

algum feedback.

estou feliz com a ideia de limites lineares simples e consultas personalizadas avançadas

notificadores mais úteis:

• exec - pode usar algo como ssh ou sendmail
• webhooks - o usuário pode usar um webcgi para pegar web-hooks para fazer coisas ...
• email - dispara um email simples com um despejo json dos dados de notificação.
• plugins ... não são realmente necessários

api para puxar o estado de alertas ... parece uma má ideia,
no entanto, api para puxar configuração de alerta em um formato json básico pode ser bom.
esse dump json pode ser transformado em algo que outros sistemas possam considerar útil para transformar.

Não tenho certeza se isso é desaprovado ou não .. Não foi possível encontrar um link de doação em qualquer lugar, mas que tipo de contribuição seria necessária para obter isso na v3 até o final do mês. Poderíamos realmente usar este recurso, mas nossos recursos estão atados ATM

+1

+1

Esse é um recurso muito necessário para nós aqui do Mercado de Trabalho.

Os alertas apresentados são lançados?

Não
Na quinta-feira, 25 de fevereiro de 2016 às 23h13 kskaran94 [email protected] escreveu:

Os alertas apresentados são lançados?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -189143056.

Seria seguro presumir que o recurso de alertas será lançado no verão?

_suspensa intensifica_
Em 26 de fevereiro de 2016 10:23, "Ian Ha" [email protected] escreveu:

Seria seguro presumir que o recurso de alertas será lançado no
verão?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -189320869.

alguma notícia sobre isso?

+1

Seria bom ter já +1, as pessoas já estão esperando o ano inteiro ou até mais.

: +1: eu gosto. Obrigado pelo vídeo e pela apresentação, @Dieterbe. Está disponível para teste / primeiros usuários?

@torkelo, você anunciou

Queremos que esse recurso seja o título do Grafana 3.0

Mas olhando para o changelog do branch não lançado do 3.0 (1), nenhuma menção é feita sobre o alerta, devo começar a chorar ou o plano ainda é ter o recurso Alerting the 3.0 headline?

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

Decidimos trabalhar no sistema de plugins do grafana 3 para que possamos liberar o grafana 3 e, em seguida, começar a trabalhar no alerta, em vez de adiar desnecessariamente o grafana 3.

@Dieterbe Não posso dizer que estou feliz, mas faz sentido. O acompanhamento óbvio é se há algo semelhante ao ETA para alertar; e se é um recurso confirmado e confirmado para 3.1.

Além disso, como uma solução alternativa, http://alerta.io/ faz parte do que eu quero que Grafana faça; as pessoas que estão esperando por esse recurso podem querer experimentá-lo.

Existe uma especificação para o plugin? Pode ser bom construir algo no
comunidade para lidar com alertas para coincidir com o lançamento da versão 3?

Beth
Em 16 de março de 2016, 8h44, "Richard Hartmann" [email protected]
escreveu:

@Dieterbe https://github.com/Dieterbe Não posso dizer que estou feliz, mas que
faz sentido. O acompanhamento óbvio é se há algo semelhante ao ETA para
alertando; e se é um recurso confirmado e confirmado para 3.1.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -197214149

@Dieterbe Acho que também seria bom ter a capacidade de criar notificações no lado do cliente. Por exemplo, mensagens de voz em monitor público com painel, então você não precisa olhar para o painel para saber se há algum problema. Como alertas sonoros do Zabbix. Para este propósito, escrevi um código JavaScript simples que verifica um painel específico e, se houver algum problema, ele me notifica usando a API de fala da Web . Por enquanto, funciona muito bem para mim.

Que tal usar o Kapacitor como backend para alertas, sua linguagem de script é simples e realmente poderosa? Ou que tal suporte para vários back-ends de alerta, e ter abstração sobre isso.

Agora que o 3.0 foi lançado, estou muito animado para ter um alerta na grafana. Os alertas farão da grafana a ferramenta definitiva.

Olá @Dieterbe ,

Como posso ver nesta versão https://github.com/raintank/grafana (que você disse que tem o pacote de alerta), o repo agora está obsoleto e diz que todo o novo desenvolvimento está acontecendo em https: // github. com / raintank / worldping-api. Isso me faz pensar se esse recurso de alerta ainda está sendo desenvolvido ou foi planejado e alterado para outra coisa (como o worldPing, que não se parece com o que estamos discutindo aqui).

Olá @minhdanh , o objetivo sempre foi adicionar alertas "corretamente" em grafana, não apenas como um hack em um fork específico do raintank, que é o repo ao qual você está se referindo (e que cobriu apenas um domínio muito restrito de qualquer maneira, embora possa fazer sentido reutilizar parte desse código assim que começarmos a trabalhar em um planejador / executor, que esse repo tinha). É por isso que temos trabalhado muito para tornar o grafana tão plugável para o próximo lançamento do grafana 3. (e, como resultado disso, nos permitiu mover nossas próprias necessidades para um aplicativo autônomo, que é a API mundial à qual você está se referindo).
Ficou muito claro que, como primeira etapa, devemos apenas construir a IU para gerenciar as regras de dentro de seus painéis e painéis grafana e expô-los por meio de algum tipo de API, para que os plug-ins possam usá-los para executá-los. Esta será a maneira mais rápida de iniciar o alerta. as "baterias incluídas no agendador / executor" viriam depois e podem reutilizar parte do código a que você se referiu.

de qualquer forma, primeiro faremos a UI de gerenciamento em grafana e exporemos as regras por meio da API, e partiremos daí.

Obrigado @dieterbe.

Como sempre, há a questão de um cronograma aproximado, mesmo que seja apenas "não
antes de X ".

Eu entendo o quão irritante esta questão pode ser, portanto, a formulação no
segunda parte. Espero que você entenda como é frustrante esperar pelo outro
lado da cerca pode ser.

Richard

Enviado por celular; desculpe minha brevidade.

Olá a todos,

Espero que o raintank não tenha problemas em dizê-lo aqui, mas recentemente solicitamos quase um mês de horas dedicadas à codificação do raintank para trabalhar nos alertas. Então, por que isso ainda não resultará no recurso de alerta final, devemos ver algo chegando em breve para estabelecer a base para o alerta em grafana. Se outras empresas seguirem nossa abordagem ou também indivíduos que investem algum dinheiro nesse assunto, isso deve acelerar ainda mais as reflexões e as prioridades.

@flyersa , muito obrigado pela contribuição! Como podemos colocar dinheiro também?

Jon

Olá a todos,

Sei que muitos estão ansiosos por esse recurso e tenho o prazer de informar que a equipe começou a trabalhar nele. Explicamos nossos motivos para o atraso no blog de anúncio da versão beta do

Estaremos liberando alertas em duas fases. A primeira fase permitirá que os usuários definam seus alertas e limites na IU do Grafana. Grafana também irá expor essas definições de alerta em uma API HTTP para agendadores de terceiros e back-ends de alerta. Na segunda fase, forneceremos o serviço de back-end para consumir e atuar sobre essas definições, para uma solução totalmente integrada.

Esperamos que a primeira fase seja lançada em questão de semanas.

Estamos tentando equilibrar lucratividade com velocidade e agradecemos MUITO o suporte comercial de nossos clientes, como @flyersa. Se outras pessoas quiserem oferecer suporte ao desenvolvimento desse recurso e do Grafana em geral, considere adquirir um plano de suporte . Isso nos ajudará a desenvolver um ótimo software que seja 100% open source.

Estaremos trabalhando em estreita colaboração com todos os clientes com suporte conforme implementamos o recurso e nos certificando de que ele atenda bem às suas necessidades.

-raj dutt | ceo / cofundador | raintank

Olá @ nopzor1200 ,

Obrigado por sua atualização. Você tem uma estimativa de quando o alerta estará disponível?

Obviamente, é impossível se comprometer em uma data específica, mas um prazo será muito apreciado (semanas, meses etc).

10x!

Oi pessoal, muito animado por isso. É assim que pretendo usar isso, se alguém puder verificar se é um padrão padrão / compatível, eu agradeceria.

• Cada host que desejo monitorar emite "Cheques". Um "cheque" consiste em:
  
  
  
  • o nome do host
  
  
  • o carimbo de data / hora
  
  
  • o estado, que é 0 = OK, 1 = AVISO ou 2 = CRÍTICO
  
  
• Essas verificações podem vir de uma variedade de fontes arbitrárias (scripts de shell + cron, statsd / collectd, verificações do Nagios, etc.) e serão acumuladas no Elasticsearch. A mesma verificação pode ter configurações diferentes em hosts diferentes, mas isso será opaco para o Grafana.
• Vou configurar o Grafana para se conectar ao Elasticsearch e alertar quando qualquer verificação vinda de qualquer host tiver um valor de estado> = 1.
• Se novos hosts ingressarem no cluster, não haverá configuração necessária no Grafana; O Grafana simplesmente verá qualquer ponto de dados no estado 1 ou 2, independentemente de onde ele veio.
• Se um host morre repentinamente e para de transmitir verificações, precisamos detectar isso. Para lidar com isso, quando um host é inicializado, ele registra uma verificação mestre com o status "ON", e o valor só vai para "OFF" quando é interrompido normalmente. Desta forma, posso procurar quaisquer hosts "ON" que não tenham emitido verificações nos últimos X segundos.
• Em geral, não usarei alertas baseados em limite em dados de série temporal em Graphana. Em outras palavras, não irei "verificar se o uso da CPU> 80%" dentro do próprio Grafana, mas sim, o Grafana receberá uma verificação de "Estado de uso da CPU" (0/1/2) e alerta em 1 ou 2 estados.

Ei @johnnyshields ,

Parece muito bom, mas em vez de "0 = OK, 1 = AVISO ou 2 = CRÍTICO", por que não usar uma definição de nível padrão? O usado pelo syslog é praticamente um padrão de fato para essas coisas:

• Valor -> Gravidade
• 0 -> Emergência
• 1 -> Alerta
• 2 -> Crítico
• 3 -> Erro
• 4 -> Aviso
• 5 -> Aviso
• 6 -> Informativo
• 7 -> Depurar

E tem uma configuração (global?) Para dizer à grafana qual nível considerar como um limite de alerta.

Diante disso, eu adicionaria as seguintes alterações à sua postagem:

• alertar quando qualquer verificação proveniente de qualquer host tiver o valor de estado> = CONFIGURABLE_ALERT_LEVEL.
• O Grafana simplesmente verá qualquer ponto de dados no estado> = CONFIGURABLE_ALERT_LEVEL, independentemente de onde veio
• O Grafana receberá um nível de verificação de "Estado de uso da CPU" e um alerta se configurado de acordo.

@brunorey obrigado, faz sentido!

Os níveis e estados de log são duas coisas diferentes. Você poderia ter uma mensagem de registro 6-Informativa, mas como algo pode estar em um estado 6-Informativo?

Estados de OK, WARN e CRITICAL são aceitáveis ​​e podem ser muito bons para aqueles que se preocupam apenas com OK e CRITICAL. Adicionar mais estados aumenta a confusão, a menos que seu significado seja universalmente compreendido, e sugiro limitar a 3.

Com relação apenas aos alertas de "CPU state> = WARN" vs. "CPU> 80%", proponho que algumas pessoas desejem manter seus estados de 3 níveis em um banco de dados de série temporal para que possam ver como o estado mudou ao longo do tempo. Essas pessoas irão alertar com base em seus dados de série temporal de estado. Outros vão querer alertar sobre o valor bruto da CPU sendo superior a 80%. A questão é que alertar os dados da série temporal é a única coisa necessária.

O motivo pelo qual estou escolhendo a razão de estados de log de inteiro em vez de usar os dados da série temporal diretamente é que quero ser capaz de controlar o que é considerado um alerta em cada nó.

Por exemplo, servidores de trabalho rotineiramente têm CPU perto de 100%, e isso não é um problema - eu quero que eles funcionem a todo vapor em todos os núcleos. Mas os servidores web não devem ter CPU acima de 20%. Portanto, se eu fizesse uma CPU genérica> 80%, ela seria muito alta para as redes e muito baixa para os trabalhadores. (Este é apenas um caso).

@johnnyshields Eu não entendo por que você não usaria alertas baseados em limite em dados de série temporal, IMO é onde está o valor realmente forte (único?) de adicionar alertas a grafana / grafite. Seu estilo de "cheques" soa melhor para algo simples como monit - eu perdi algo aqui?

Conforme explicado acima, tenho muitos servidores com funções diferentes e os limites são diferentes por servidor. Em última análise, é uma questão de saber se os limites são definidos no Grafana ou no próprio servidor, acho que o servidor é mais fácil no meu caso.

Além disso, algumas verificações são "sim ou não", por exemplo, o processo X está em execução, faz um ping para a porta Y responder, etc.

Entendido. Às vezes, determinar esses estados é simples (> 80%) e às vezes é complexo. Quando são complexos, alguns códigos determinam os níveis e os enviam para um banco de dados TS. Essa é uma prática comum, onde os dados são transformados em informações. Meu ponto é, não há diferença de um sentido de alerta.

Se você precisar de regras complexas para seus alertas, não as crie no mecanismo de alerta, mas sim no pipeline de TS para criar novos dados de TS e alerte isso.

Simplifique o sistema de alerta. Oculte a complexidade no pipeline de TS.

A vantagem de criar novos dados de TS em um pipeline em comparação com um sistema de alerta baseado em regras é que mantém os alertas visuais e simples para as pessoas que estão configurando e recebendo os alertas. Há uma visualização que pode ser enviada por e-mail ou sms mostrando apenas o que foi alertado - mesmo que seja um gráfico de estado simples onde eles veem que o estado passou de WARN para CRITICAL 20 minutos atrás.

Eu acho que se você quiser controlar o que é considerado digno de alerta por host / função, você está tão bem em adicionar lógica ao que é considerado WARN e o que é considerado CRIT quanto adicionar 8 camadas de granularidade à gravidade do alerta.

Quase todos os outros sistemas de alerta modernos parecem ter convergido para OK / WARN / CRIT e, embora provavelmente seja em parte por querer compatibilidade com as verificações do Nagios, acho que a ideia de apenas querer mantê-lo simples é mais importante. Se o Grafana fizer o mesmo, a integração com outros serviços de alerta / monitoramento será mais fácil. Por exemplo, no meu caso eu provavelmente acabaria alimentando o Grafana com alertas para o Sensu, que então enviaria um e-mail, slack message ou qualquer outra coisa. Sensu tem apenas OK / WARN / CRIT, então qualquer granularidade a mais seria desperdiçada.

O nível de alerta de log de concordância parece excesso de engenharia. OK, Warn, Crit provavelmente faz o trabalho na maioria dos casos.

Em limites de alertas, adoraria poder fazer alertas baseados em desvio padrão. Eles são mais úteis na prática imo.

Em 12 de maio de 2016, às 8:49 AM, RWhar [email protected] escreveu:

@johnnyshields Eu não entendo por que você não usaria alertas baseados em limite em dados de série temporal, IMO é onde está o valor realmente forte (único?) de adicionar alertas a grafana / grafite. Seu estilo de "cheques" soa melhor para algo simples como monit - eu perdi algo aqui?

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente ou visualize-o no GitHub

Pessoalmente, estou ansioso para alertar usando dados de TS existentes alimentados em grafite como entrada, especialmente agregando estatísticas de métricas de aplicativos (via StatsD) dentro de intervalos de tempo especificados.

Além disso, seria bom ter uma opção em que alertas pudessem ser acionados no limite e intervalos especificados além do limite - por exemplo, definir limite de alerta "rpl_delay" 200 int 50 - causaria alertas em 200, 250, 300 etc. sem o precisa especificar manualmente os níveis de limite adicionais.

@johnnyshields Não entendo a diferença entre 1 = WARN ou 2 = CRITICAL. O alerta é acionado ou não acionado. Você está acima de 80% ou não está acima de 80%. Portanto, vejo apenas dois estados 0 e 1.
Também seria bom ter um alerta mais inteligente, onde você pode detectar que esteve acima de 80% por 5 minutos direto, de forma que você não seja alertado sobre picos temporários. Ainda mais avançados são coisas como a movimentação dos limites, em que, por exemplo, você monitora o tráfego do seu site e obtém uma quantidade X de tráfego, que aumenta lentamente, digamos 1% ao mês, mas de repente você obtém um pico de 10% no tráfego em um hora. Você também gostaria de ser capaz de monitorar o oposto, de uma queda repentina no tráfego. Algo semelhante a https://github.com/etsy/skyline, já que o Skyline foi extinto.

Pessoal, minha postagem aqui não era sobre o número preciso de estados de alerta a serem usados ​​- eu estava perguntando de forma mais geral "O Grafana oferecerá suporte a estados enumerados como um caso de uso de alerta?"

Uma vez que há desacordo sobre o número ideal (Nagios usa 3, syslog usa 7, algumas pessoas gostam de 2, etc.), o Grafana deve suportar um número arbitrário de estados.

Apenas reafirmando o que disse antes, acredito que deve haver apenas dois estados para cada alerta disparado 1 ou não disparado 0. Se você quiser saber se está chegando perto de um limite, faça um limite adicional para o valor mais baixo.

A razão para WARN vs. CRITICAL é que as ações que você executa são diferentes. Um grupo de pessoas e ações geralmente são notificados no WARN e um grupo diferente / ações diferentes no CRITICAL.

Essa é uma diferenciação muito valiosa, que eu não gostaria de abandonar com um sistema 0-1.

@lorenwest se quiser uma verificação diferente para um limite diferente, crie um limite adicional para esse grupo separado.
portanto, cada limite é 0 ou 1.
Por exemplo, outro motivo pelo qual você deseja que o alerta seja configurado dessa forma é quando você deseja um e-mail quando o limite for maior que 70%, mas uma página quando você estiver acima de 80%. Exatamente como você deseja grupos separados. WARN vs. CRITICAL tem muita ambiguidade.

@doanerock isso faz sentido. Permitir um número arbitrário de alertas em qualquer métrica ou evento de TS permite maior flexibilidade. Isso simplifica a definição de alerta por não ter várias ações para vários níveis.

tão:

• as métricas podem ter um número arbitrário de estados (incluindo valores decimais / série temporal)
• métricas podem ter várias ações de alerta anexadas à mesma métrica
• cada alerta é um booleano verdadeiro ou falso - é acionado ou não.

para dar um exemplo:

• Eu tenho uma certa métrica com valores 0 = OK, 1 = AVISO, 2 = CRÍTICO
• Eu configuro 3 alertas:
  
  
  
  • se valor = 1, mostra uma bandeira amarela em meu painel
  
  
  • se valor = 2, mostra uma bandeira vermelha em meu painel
  
  
  • se valor> = 1, envie-me um e-mail
  
  

Olá a todos,

Não sei se é o lugar certo para perguntar sobre este tópico, mas tentarei de qualquer maneira em relação ao próximo módulo de alerta Grafana.
Em nossa organização, temos todos os nossos sensores de alertas de segurança alimentando Logstash / Elasticsearch para eventos e usamos o Yelp / elastalert para executar alertas com certos padrões com os seguintes critérios:

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

Além disso, quando os critérios de alerta são detectados, executamos um script python externo com argumentos que passam argumentos de Elastalert para o script com informações como campo de IP de origem / destino, campo de evento e carimbo de data / hora, e nosso sistema NAC cuida disso.

Agora olhando para o módulo de alerta do Grafana Upcoming e com o Elasticsearch como fonte de dados, eu me pergunto se o módulo de alerta do Grafan será possível cooperar da mesma forma que o Elastalert e eventualmente substituí-lo pelas informações fornecidas acima.
Por favor informar

Obrigado

Eu sei que a equipe da grafana está trabalhando arduamente nisso, e este tópico é longo, mas eu quero salientar que o Kapacitor acabou de mesclar um recurso que irá facilitar muito o desenvolvimento de aplicativos de configuração de alerta de front-end: influxdata / kapacitor # 577

Pelo que eu entendo, o objetivo do lado do Grafana é tornar o back-end de alerta plugável (da mesma forma que o Grafana suporta várias lojas TSDB), mas gostaria de mencionar na esperança que o Kapacitor obtenha suporte de primeira classe quando a funcionalidade de alerta do Grafana for lançada. Parece um ótimo ajuste, assim como InfluxDB + Grafana.

@ thom-nic obrigado pela dica Kapacitor é exatamente o que estou procurando ...

Riemann também é ótimo e muito poderoso. telegraf -> riemann (alertando) -> influxdb <- grafana

Estamos progredindo no branch alerting_definitions.

Agora temos um modelo de regra de alerta simples que você pode definir na IU e via API HTTP. Você pode buscar regras, mudanças de regra, estados de regra via API HTTP. O agendamento de regras de alerta simples e a execução de consultas e a execução de regras também estão começando a se encaixar.

Uma coisa que é um grande ponto de interrogação para mim agora é se o modelo de alerta atual é muito simples e um beco sem saída. Com isso, quero dizer que estender o modelo de regra de alerta no futuro exigirá mudanças extensas.

Modelo de regra atual:

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

Este modelo de armazenamento é representado na IU e na tabela real do banco de dados. Meu medo é que esse modelo de regra simples não tire proveito dos dados de série temporal bem o suficiente. Você não pode especificar limites dinâmicos (onde os próprios limites são resultados de uma consulta). Claro isso
poderia ser adicionado posteriormente, mas exigiria um modelo de regra e mecanismo de execução muito diferentes.

Portanto, minha ideia é descartar esse modelo simples e chegar a um novo modelo mais complexo e dinâmico que possa mais tarde suportar várias consultas em diferentes intervalos de tempo.

Consulta Simples:

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

// agora para um alerta que usa um limite dinâmico com base em seus valores passados

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

Agora você pode questionar isso afirmando que estamos reinventando o Grafite aqui, e expressões como essa devem ser tratadas pelo TSDB. Mas nenhum TSDB oferece suporte a cálculos com consultas para intervalos de tempo diferentes (timeShift muda apenas o mesmo intervalo de tempo). Alguns problemas com limiares dinâmicos é como visualizá-lo. Também pode tornar a regra de alerta mais divorciada do que é realmente visualizado no painel.

Não tenho certeza de como deve ser a GAL (Grafana Alerting Language). Devem ser apenas cadeias de expressão em que cada parte pode ser uma consulta que retorna uma ou mais séries (cada série agregada até um ponto) e, em seguida, uma função opcional de subtração ou porcentagem que pode ser comparada com outra consulta. A expressão inteira resulta em um valor que pode ser usado com os níveis de operador e crítico / aviso para obter o estado de alerta.

Ou a expressão deve conter o operador e os níveis?

Outras opções iriam para a linguagem de programação completa e:

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

return percentDiff(last5minAvg, last24Avg)
"

@torkelo :

1. você está arquitetando isso como um componente autônomo? No final das contas, você está construindo um processador de sinal semelhante ao
2. da mesma forma, a grafana terá a opção de não usar o mecanismo de sinal acima, mas sim receber um sinal 0/1/2 de uma fonte de terceiros, como um plugin do Nagios, dos quais muitos já existem?

** = concedido Kapicator usa processamento de fluxo de série de tempo enquanto seu é um mecanismo baseado em polling, mas ainda emite um sinal.

Obrigado por solicitar contribuições.

Minha opinião é manter os alertas da grafana simples, e a melhor medida de simplicidade é a visualização. Se você não consegue visualizar o alerta como uma linha em um gráfico TS existente, é muito complexo.

Deixe a complexidade para o gráfico TS. Se o alerta tiver necessidades maiores, crie outro conjunto de dados de TS com base nessas necessidades e coloque o alerta em um gráfico desses dados.

Se você tem apenas um princípio orientador, é exigir uma visualização simples do alerta.

O outro problema é "quantos alertas devo configurar"? Este tópico foi discutido neste tópico, e eu sou da opinião que assim que você começa a colocar vários alertas em um alerta (aviso, erro, aviso alto, erro baixo, etc), você começa a perder flexibilidade. Avisos e erros são coisas diferentes - eles têm níveis diferentes, pessoas diferentes se preocupam com eles e têm métodos de notificação diferentes.

Mantenha os alertas simples e permita que as pessoas coloquem vários alertas em um gráfico.

Acho que o nº 3677 (Transformações genéricas nos resultados da consulta de série temporal) seria muito útil aqui. Com essas funções independentes de TSDB, você pode criar um "gráfico de alerta" complexo onde pode usar limites de valor fixo simples para aviso, crítico, etc.

O modelo de regra de alerta simples seria tudo o que é necessário então. A complexidade é então "escondida" na criação e combinação dos gráficos.

Sou totalmente a favor de manter as coisas simples. Não sou dev, sou mais light-touch-dev-ops e gostaria de poder entregar minha plataforma Grafana / Graphite para minha equipe de administradores gerenciar. Sendo esse o caso, um construtor de alertas semelhante ao existente será muito mais fácil de usar. Não será muito complicado se ele introduzir um monte de novas instruções, desde que as regras ainda possam ser construídas da mesma forma que as consultas para gráficos atualmente são, será fácil de entender.

tl; dr uma linguagem totalmente nova pode ser um exagero e muito complexo. Construindo regras com mouse = good.

Sem construir uma linguagem totalmente nova, presumi que isso seria em grande parte um front-end para as plataformas de alerta existentes, como Kapacitor, Reimann & Bosun, semelhante a como o Grafana fornece um front-end para compor consultas do InfluxDB. por exemplo, o trabalho pesado é feito por um sistema de alerta de terceiros e a Grafana fornece a IU. Talvez não seja o caso?

IIRC, Grafana quer seguir o caminho "baterias incluídas, mas removíveis". Ou seja, deve funcionar de forma independente com um mecanismo de alerta incluído, mas também deve ser conectável às plataformas existentes.

Eu diria que ele precisa vir com alguns métodos embutidos - e-mail (fornecer host SMTP) e WebAPI / Webhook. Então, o resto pode vir com plug-ins, como integração no PagerDuty.

@felixbarny você poderia descrever o que quer dizer plugável a plataformas existentes? É claro que as notificações de alerta serão integradas a muitas ferramentas de alerta existentes. Mas para outros sistemas lidar com o agendamento e execução de regras de alerta pode ser complicado, seria possível, basta ler as regras da API Grafana HTTP. Mas isso exigiria muito código para lidar com o agendamento e a execução da regra. Mas, é claro, forneceremos uma opção para apenas definir as regras no Grafana e para outro sistema ler as regras constantemente e executá-las

@GriffReborn você está pensando em um nível diferente. Os back-ends de alerta existentes que mencionei _already_ oferecem suporte a saídas como SMTP, PagerDuty etc:
https://docs.influxdata.com/kapacitor/v0.13//introduction/getting_started/#a -real-world-example
http://riemann.io/api/riemann.pagerduty.html

Esses produtos _já_ fazem alertas dinâmicos complexos. O que eles não têm é um frontend visual agradável para configurar e gerenciar alertas, identificando visualmente quais alertas estão ativos, etc. O que eu gostaria de ter é uma interface de usuário de frontend que basicamente empurra configurações para, por exemplo, seu alerta (compatível com Grafana) sistema de escolha que faz todo o trabalho.

@ thom-nic eu concordo. O foco principal deve ser a construção de um painel de alerta que possa usar feeds de informações de alerta existentes ("agnóstico de feed"). Fazer um mecanismo de processamento de sinal leve patrocinado pela Grafana (idealmente como um autônomo) deve ser uma preocupação secundária.

@johnnyshields criar novos painéis que mostram informações de back-ends de alerta existentes é fácil para qualquer pessoa que queira fazer isso. O que estamos tentando fazer é tornar mais fácil para os usuários do Grafana definirem regras de alerta em suas consultas de métrica que eles definem nos painéis de gráfico / únicoestat. Em seguida, tenha um mecanismo de alerta no back-end da grafana que agenda, executa e avalia essas regras, atualiza o estado de alerta, dispara notificações etc.

Eu também acho que o modelo simples deve ser suficiente e também resultará em ter o recurso tão esperado o mais rápido possível. Em todos os grafana é para métricas, o alerta básico deve ser suficiente.

@torkelo para ser honesto, não estou muito familiarizado com plataformas de alerta como o bosun e não sei como uma integração adequada poderia ser especificamente. Eu estava me referindo a coisas que @Dieterbe disse, por exemplo em sua apresentação Grafanacon: http://de.slideshare.net/Dieterbe/alerting-in-grafana-grafanacon-2015#50

@felixbarny bem, isso é o que planejamos fazer também. Ter APIs para outros back-ends de alerta usarem para ler as regras definidas no Grafana. Mas não forneceremos a ponte que lê as regras de alerta do Grafana e as traduz para outro mecanismo de execução de regras.

Então, uma ideia que temos agora é definir regras simples como esta

Mas também ser capaz de ter limites dinâmicos e comparar com outra consulta ou a mesma consulta, mas intervalo de tempo e agregação diferente.

Outra consulta complexa de "previsão". Quando uma consulta é usada para obter uma linha de tendência, faça uma previsão no tempo e alerte sobre isso.

Parece o melhor dos dois mundos. Amei essa ideia! As funções 'Avaliar contra' fazem parte do Grafana ou são específicas do TSDB?

@felixbarny eles fazem parte do modelo de regra de alerta Grafana e serão processados ​​pelo mecanismo de avaliação de regra de alerta Grafana.

Você será capaz de anexar várias regras a um único gráfico? Gosto da simplicidade dos níveis de advertência / crítico em uma regra, e alguns gráficos têm limites altos e baixos que exigiriam vários níveis em um alerta ou vários alertas em um gráfico.

E embora eu goste da funcionalidade de regras complexas, tudo isso pode ser alcançado construindo um gráfico diferente e alertando nesse gráfico com uma regra simples. O benefício de manter a complexidade fora do sistema de alerta é que o histórico das circunstâncias que fazem com que a regra seja acionada é mantido no TSDB.

Isso permite visualizar um alerta como uma linha horizontal simples em um gráfico e ver como essa regra teria (ou disparou) ao longo do tempo.

Ele continua alertando simples para a pessoa média, complexo o suficiente para todos e acessível para aqueles que entendem as coisas visualmente.

@lorenwest sim, vamos manter as coisas simples e permitir apenas uma regra de alerta por painel. Mas uma regra pode usar uma consulta que retorna muitas séries, o que basicamente dividirá a regra em várias (então você pode ter uma única regra que verificará cada servidor, se a consulta retornar uma série por servidor).

E embora eu goste da funcionalidade de regras complexas, tudo isso pode ser alcançado construindo um gráfico diferente e alertando nesse gráfico com uma regra simples.

Não sei o que você quer dizer aqui. Outro gráfico não resolve de forma alguma o cenário em que você deseja alertar sobre uma consulta em comparação a si mesmo em um intervalo de tempo diferente, em comparação com outra consulta inteiramente (talvez a outra consulta seja outra fonte de dados que busca limites dinâmicos de um banco de dados). Esse cenário não pode ser resolvido no TSDB ou apenas dividindo a regra em duas regras em dois painéis separados.

Mas nosso objetivo principal é resolver o caso simples e torná-lo fácil e intuitivo, mas também queremos, pelo menos mais tarde, suportar algumas regras de alerta mais complexas que realmente tiram vantagem do fato de você estar lidando com dados TSDB e também do fato que consultas diferentes podem ter como alvo diferentes fontes de dados

Acho que o que @lorenwest estava

Com um modelo de alerta mais complexo, não há mais um indicador visível de onde os limites resultariam em um alerta.

Permanecendo com o modelo simples, você poderia cumprir muitos dos requisitos de monitoramento complexos, desde que a fonte de dados fornecesse o recurso. Para a "mudança percentual comparada a", você poderia construir uma consulta de grafite (gráfico diferente) que comparasse o dia atual com o anterior e, em seguida, definir limites simples nisso. Certamente é um processo muito mais complicado para criar alertas, mas funciona.

Ainda bem que estamos na mesma página @torkelo. Isso se encaixa com a descrição do post original.

Não gosto de criar uma plataforma de alerta totalmente nova para vincular ao Grafana. O que espero do Grafana alertando é algo que substitua o NewRelic, mas com o incrível poder que o Grafana traz. Ser capaz de disparar um alerta (seja e-mail, API de qualquer coisa) quando um dos meus gráficos atinge um limite ... isso é OURO. Coisas que mudam a vida.

Mesmo alertas de limite simples seriam uma solução simples e agradável.

Se você seguir esta regra, terá sucesso:

Nunca permita um alerta que não pode ser visualizado pela sobreposição em um painel.

Se você não consegue visualizar, é muito complexo. Construa um gráfico que incorpore essa complexidade e alerte nesse gráfico. Isso nos força a construir visualizações que incorporam essa complexidade (uma coisa boa), enquanto mantém fácil para o criador de alertas (e consumidor) ver no que eles estão se metendo.

@woodsaj Concordo que queremos encorajar a ligação entre o que você alerta e o que você vê, isso é algo que nunca discutimos abandonar. O que estamos tentando fazer é saber até onde vão os limites estáticos de uma única consulta. Eles são bons o suficiente para a v2 do Grafana Alerting ou v3? E para iniciar uma discussão sobre quais limitações no tipo de regras de alerta são possíveis com uma única consulta e limites estáticos.

Atualmente, os TSDBs são muito inflexíveis no tipo de consultas aninhadas que você pode fazer (compare uma série com ela mesma, por exemplo). O grafite é o único que oferece suporte a consultas aninhadas. Mas mesmo o Graphite não pode comparar duas consultas que visam janelas de tempo diferentes (a mudança de tempo apenas muda a mesma janela, mas não janela de tempo de tamanhos diferentes). Porém, quanto mais penso sobre isso, mais concordo que a maior parte disso pode ser resolvido na consulta TSDB, já que ela é poderosa o suficiente.

O principal motivo para levantar esta discussão é fazer um brainstorm de como modelar a regra, quais são os componentes que a constituem, quais abstrações ela contém (consulta, janela de tempo, agregação, níveis, etc.). Como podemos oferecer suporte a limites dinâmicos na v2 ou mais consultas de alerta com muitos recursos que prevêem tendências no futuro. Como o modelo e o mecanismo de avaliação de regras precisam ser alterados?

Com relação a "Devem ser mapeados os alertas para painéis" - acho que pode ser uma opção útil, mas seria uma restrição de design ruim, mesmo para v1.

Acho que um dos aspectos mais complicados do alerta é o escopo, e quando você começa a falar sobre visualização, o problema se torna aparente.

Eu penso no escopo como a área de superfície / profundidade de um sistema que um alerta cobre como o escopo. Portanto, por exemplo, seus alertas podem ter o escopo:

• Serviços (métricas de aplicativo)
• Clusters inteiros que compõem um serviço
• Nós individuais em um cluster
• Hosts / processos em um cluster
• Subsistema de processos / aplicativos (métricas de middleware)
• Subsistemas de hosts (ou seja, disco, cpu) (métricas do sistema)

Não acredito que haja uma única resposta "correta" sobre a camada sobre a qual devemos alertar. Às vezes, depende das equipes, da importância do serviço, da infraestrutura geral (ou seja, nuvem versus hardware, cluster versus monólito), etc ... Portanto, dados escopos em camadas, uma hierarquia de alerta parece boa. Mas não acho que definir essas hierarquias seja geralmente sustentável. É muito trabalho, mudanças e freqüentemente há relações que não contribuem para árvores bonitas nos sistemas do mundo real. Agressão do livro SRE do Google:

"" "
O Google SRE obteve sucesso apenas limitado com hierarquias de dependência complexas. Raramente usamos regras como "Se eu sei que o banco de dados está lento, alerta para um banco de dados lento; caso contrário, alerta para o site geralmente lento". As regras dependentes de dependência geralmente pertencem a partes muito estáveis ​​de nosso sistema, como nosso sistema para drenar o tráfego do usuário de um datacenter. Por exemplo, "Se um datacenter estiver esgotado, não me alerte sobre sua latência" é uma regra comum de alerta de datacenter. Poucas equipes no Google mantêm hierarquias de dependência complexas porque nossa infraestrutura tem uma taxa constante de refatoração contínua.
"" "

Também relacionado ao escopo está o tipo de alerta (ou seja, enviar um e-mail vs registrá-lo / mostrá-lo no painel para alguém lidar quando estiver fazendo suas rondas matinais)

Portanto, para Grafana, meus alertas podem ser mapeados para:

• Um painel
• Um Grupo de Painéis
• Um painel de controle
• Um grupo de painéis (que imagino que teria detalhamentos)

Às vezes, vou querer que esses alertas enviem uma notificação, outras vezes, quero que sejam apenas um indicador visual em algum lugar do Grafana em um dos escopos (ou seja, limiar cruzado ou mudanças de estado como marcadores de anotação). Vai ser diferente para diferentes empresas e até mesmo diferentes grupos / serviços dentro de uma empresa.

@kylebrandt toda a ideia com o alerta no Grafana é amarrá-lo a painéis e visualizações. Onde você pode ter gráficos e painéis que visualizam métricas com escopo diferente (como serviços, clusters, hosts individuais) e com isso você pode alertar em qualquer nível ou escopo.

Não ver como vincular um alerta a um painel e algo que pode ser visualizado deixará de definir alertas em diferentes níveis. E, claro, você especificará por alerta quais notificações devem ser usadas.

@torkelo A decisão de alertar sempre se

Portanto, $metric > $threshold é o alerta mais básico e retorna verdadeiro se a métrica exceder o limite, é claro. Isso se encaixa perfeitamente em um painel (visualize a métrica e visualize o limite dentro de um painel). Mas, para eliminar o ruído de alerta, o escopo e as condições tendem a crescer além disso na maioria dos casos (quando começamos a trabalhar no Bosun, pensei que esses casos seriam a minoria, não tanto, se você quiser controlar o ruído). Então, você pode dizer algo como:

Alerta se:

• CPU está acima de 80% por X minutos
• O Trabalho A não está em execução (sabemos que aumenta a CPU e não nos importamos) e o Trabalho A não está em execução há mais de uma hora
• Dieter bebeu mais de 3 xícaras de starbucks nas últimas 24 horas (porque quando ele tem mais, ele faz coisas bobas que aumentam a CPU e não queremos alertar sobre isso)

Portanto, visualizar apenas o alerta é (Verdadeiro / Falso) quando há várias condições não é tão útil. Precisamos visualizar cada condição (e talvez até mais algumas para informações de apoio).

Transformar todas essas condições em uma nova métrica não ajuda muito na visualização no momento, porque seria apenas Verdadeiro / Falso e o que você realmente precisa ver são todas as informações subjacentes. Portanto, o que temos em vez de visualizar métrica + limite é visualizar métrica (s) + limite (s) que podem estar em escalas diferentes.

Portanto, neste caso, sim, o Alerta _pode_ mapear para um único painel, mas dependendo da visualização e do alerta, existem muitos casos em que isso não é realmente o que se desejaria. Eu gostaria de um painel para cada um dos itens booleanos que compõem o alerta, para ver quais deles dispararam - mas para evitar a fadiga do alerta, quero apenas uma notificação para a combinação de todas as condições.

parece que algum tipo de junção de alerta com lógica booleana simples pode tornar isso fácil.

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

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

@torkelo Eu puxo o branch construo de acordo com as instruções. Mas, infelizmente, não consigo ver nenhuma guia "Alerta" (apresentada acima) no painel Gráfico.
Além disso, encontrei "alerting: enabled = false" na "Configuração do servidor" de "Administração do servidor". Isso afeta o recurso de alerta? Existe algum sinalizador de build ou runtime que devo usar?
Conselho por favor.

Tentei com o código mais recente (ebada26b85d8410142c2942ef7ba78b17e88313c), habilitei o alerta e consegui a IU.

Mas tenho muitos erros

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

Eu tentei com fontes de dados InfluxDB, em modo proyy e direto.

É algo esperado?

Sim, ainda não está pronto para teste.

OK bom saber.

Vou rastrear atualizações de tempos em tempos.
Pode ser melhor esperar que esse branch seja mesclado no master, então está pronto para usar?

sim, esperamos mesclá-lo para dominar talvez meados de julho lá sobre

Você tem uma atualização de progresso sobre isso?
Você ainda vai atingir meados de julho?
Ter esse recurso em produção o mais rápido possível seria uma grande ajuda!

Mesmo uma versão leve com alerta apenas por e-mail, seria ótimo!
Seria ótimo atualizar seu progresso (preciso escolher entre implementar um sistema de alerta personalizado ou depender do Grafana e, definitivamente, prefiro a segunda opção!).
Obrigado galera

O inverno chegou, o alerta também :)

Na terça-feira, 12 de julho de 2016 às 01h41, c-val [email protected] escreveu:

Mesmo uma versão leve com alerta apenas por e-mail, seria ótimo!
Seria ótimo ter uma atualização sobre o seu progresso (preciso escolher entre
implementando um sistema de alerta personalizado ou contando com o Grafana, e eu definitivamente
prefira a 2ª opção!).
Obrigado galera

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -231975390,
ou silenciar o tópico
https://github.com/notifications/unsubscribe/AAY0-eQ6jCI8a-k_U05xbcfFcYuGy4YVks5qU1NDgaJpZM4FJUTl
.

Deepak

Eu consideraria isso um "requisito de negócios" e aconselharia que fosse avaliado em um nível de "arquitetura corporativa". Ao aplicar _algumas_ práticas e padrões usados ​​para Arquitetura de Software Corporativo, você será capaz de comunicar suas ideias por meio de modelagem ágil que, por sua vez, promove uma maior qualidade de entendimento para os interessados ​​e para a equipe de desenvolvimento.

Antes de começarmos a falar sobre o molho secreto da tecnologia e da arquitetura, precisamos concordar com pelo menos o seguinte:

1. Pensamos em nossos recursos em termos de "Business Process Management (BPM)"; e
2. Usamos a "Business Process Modeling Language (BPML)" para que possamos começar a modelar os requisitos e implementações no mesmo lugar com a UML.
3. Definimos nossa arquitetura com uma disciplina de nível empresarial.

Agora a parte divertida! Tendo uma vasta experiência com monitoramento em escala global, recomendo que levemos em consideração o seguinte:

• Deixa a grafana em paz, ela é a camada de apresentação ! Se você deseja adicionar um fluxo de trabalho para modelagem e definição de regras para gerar alertas, tudo bem, mas deixe por isso mesmo. Afinal, é por isso que os painéis e plugins foram implementados certo?
• Deixe os dados onde deveriam estar. As métricas que são chamadas para casa devem ser tratadas como cidadãos de primeira classe e armazenar seus valores de forma persistente é a prioridade SUPERIOR. Seja em um cache, documentdb, tsdb ou sql server, não importa. A tolerância a falhas está implícita ... com as "seleções de tecnologia" corretas sendo feitas para a arquitetura, é claro).
• Para nos configurar para disponibilidade + escalabilidade, precisamos usar as estruturas certas que foram projetadas especificamente para isso: atender à Arquitetura Orientada a Serviços ("SOA"). Em um nível muito alto, podemos usar o protocolo de fila de mensagens para transmitir e receber eventos e mensagens através do protocolo "AMQP". Esqueça REST e HTTP ... por enquanto. Usando um servidor de fila de mensagens como RabbitMQ ou ZeroMQ , temos um este conjunto de slides explicando ZeroMQ).
• Use uma linguagem de consulta criada especificamente para modelos de dados compostos díspares, não vinculados. Usando um "banco de dados gráfico" e a interface de consulta " SparQL ":

O SPARQL permite que os usuários escrevam consultas em relação ao que pode ser vagamente chamado de dados de "valor-chave" ou, mais especificamente, dados que seguem a especificação RDF do W3C. Todo o banco de dados é, portanto, um conjunto de triplos "sujeito-predicado-objeto". Isso é análogo ao uso de alguns bancos de dados NoSQL do termo "valor-chave do documento", como MongoDB.
[..]
SPARQL, portanto, fornece um conjunto completo de operações de consulta analítica, como JOIN, SORT, AGGREGATE para dados cujo esquema é intrinsecamente parte dos dados, em vez de exigir uma definição de esquema separada. No entanto, as informações do esquema (a ontologia) geralmente são fornecidas externamente, para permitir que diferentes conjuntos de dados sejam unidos de maneira inequívoca. Além disso, o SPARQL fornece sintaxe de travessia de gráfico específica para dados que podem ser considerados um gráfico e fig.
..
https://en.wikipedia.org/wiki/SPARQL

Lembre-se, o que Grafana nos deu e que o Nagios nunca fez se resume a um único ponto de falha: falta de escalabilidade. Grafana é "rápido", como você diz, mas você não está levando em consideração o fato de que está apenas armazenando e processando dados de série temporal - não também a (s) camada (s) de metadados ! Precisamos da semântica do SparQL e do poder do (s) mecanismo (s) de banco de dados de gráficos Elasticache +.

Pode parecer complexo ... o que pode facilmente ser muito mais complexo do que essas duas páginas, mas eu salvei você de anos de força bruta, tentativa e erro e eliminei o ruído (ou seja: existem 30 padrões de design para arquitetura corporativa, 12 para uml, etc., só precisamos falar sobre 3 para sermos capazes de derrubar isso - por enquanto)

Isso deve fazer as engrenagens girarem .. Eu preciso dormir um pouco (puxei uma noite toda) e irei trabalhar na Parte 2. Sinta-se à vontade para me enviar um ping para

Enquanto isso, algumas guloseimas:

• Um exemplo de arquitetura de referência que criei usando SOA .
• Microsoft Azure Service Fabric: Crie e opere aplicativos sempre ativos, escalonáveis ​​e distribuídos.

@talbaror Idealmente, você capturaria as mensagens de log do NAC usando um agente como um firewall PIX e as enviaria / reproduzia simplesmente por rsyslogd ou qualquer protocolo usado pelo servidor de processamento de eventos.

Se você não tem um serviço de processamento de eventos configurado, você pode usar o processamento de regras do Snort - Network Intrusion Detector . Envie-me um ping se precisar de ajuda. Passei 4 anos em uma empresa de segurança como serviço;)

Você pode integrar a detecção de anomalias como o banshee ?
Com marcadores visuais e alertas.

@torkelo, por favor, dê-nos uma marcação a mercado no cronograma para o envio.

@johnnyshields Estou trabalhando nisso todos os dias. É uma coisa complicada e realmente quero acertar os fundamentos para que o sistema de alerta possa evoluir e se tornar mais rico no futuro. O modelo atual com o qual estou trabalhando está muito bom, postará atualizações na próxima semana sobre o novo modelo de regra de alerta baseado em condições.

Espero mesclá-lo com o master e tê-lo disponível (atrás da alternância de recursos) dentro de 2 semanas se tudo correr bem. Ainda não temos uma data definida para a próxima versão do Grafana, seja um lançamento 3.2 em setembro ou um lançamento maior 4.0 no final de outubro.

@torkelo Espero receber o alerta o mais rápido possível. Esperando por isso.
Usando grafana para kubernetes.

Para outras pessoas que já possuem statsd / grafite / grafana e estão apenas esperando o Sistema de Alerta Grafana estar pronto para fazer os primeiros alertas, encontrei uma ótima alternativa para usar entretanto, Seyren: https://github.com / scobal / seyren

Ele se integra facilmente com o PagerDuty e você pode simplesmente copiar os destinos do gráfico que você já tem em seus painéis grafana para alertar especificando os limites de aviso e erro.

Parece que a equipe está fazendo um grande progresso no recurso de alerta. Eu acredito na filosofia "fazer apenas uma coisa, mas fazê-la bem". Não tenho muita certeza se colocar toda a lógica de alerta dentro do Grafana é a melhor ideia. De qualquer forma, acabei de escrever um pequeno node js daemon "flapjack-grafana-receiver 'para postar eventos grafana no flapjack. Provavelmente irei abri-lo. Alguém interessado?

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

Atualização do progresso!

Pelo menos uma pessoa está trabalhando em tempo integral em alertas desde abril. O progresso não foi tão rápido quanto gostaríamos devido a muitas reescritas. Embora estejamos visando recursos de alerta básicos para a versão inicial, sentimos que é importante obter o modelo de regra de alerta fundamental certo para que possamos expandir a definição da regra de alerta e o mecanismo de avaliação da regra de alerta em versões futuras sem uma grande revisão.

O objetivo de começar com um alerta muito simples nos levou a alguns becos sem saída que não pareciam certos e exigiu grandes reescritas. Mas agora estamos de volta ao caminho certo e fazendo um bom progresso em um modelo de regra baseado em condições com o qual estamos muito mais felizes.

Definição de regra

O novo modelo de regra de alerta é composto por uma ou mais condições. As condições podem ser de diferentes tipos. No momento, há apenas um tipo de consulta. Mas podemos adicionar posteriormente Condições como Time of day , ou Day of week , ou mais interessante Other alert (para que você possa incluir o estado de outra regra de alerta como uma condição).

A condição da consulta é composta por uma consulta e intervalo de tempo, um redutor que pegará todos os pontos de dados retornados para cada série que a consulta retornou e os reduzirá a um único valor a ser usado na comparação de limites. O redutor também pode ser, no futuro, uma "previsão" que faz uma regressão linear dos dados e prevê um valor futuro.

A parte de avaliação da condição de consulta pode ser maior que, menor que, entre etc. Você poderá arrastar alças no gráfico para definir limites.

O modelo baseado em condições oferece muitas possibilidades interessantes para tornar as regras de alerta mais poderosas no futuro sem uma revisão total do motor. Além disso, a condição de consulta tem esses componentes conectáveis ​​que permitirão a extensão (redutor com parâmetros e avaliador com parâmetros).

Notificações

Na semana passada, estivemos trabalhando nas notificações e as coisas estão começando a se encaixar!

Temos os tipos de notificação por email, webhook e slack. A notificação de folga parece muito boa :)

Quer ajudar?

Você já pode testar e fornecer feedback, o código reside no branch de alerta e você também precisa habilitá-lo no arquivo de configuração com.

[alerting]
enabled = true

Merge to master

Estamos muito perto de fundir isso para masterizar e continuar o trabalho lá. Eu esperava fazer isso antes das minhas férias de verão (acabei de sair 1 semana), mas ainda há algumas pequenas alterações no esquema SQL que gostaria de fazer antes de mesclar para master. Merge to master VAI acontecer em 19 de agosto, eu prometo :) Depois disso, o alerta estará na última compilação noturna 4.0, então será fácil para você testar e relatar bugs e feedback.

O que resta?

Há uma série de recursos ausentes que desejamos para uma versão beta.

• Mais redutores e capacidade de alterar o redutor (apenas média agora)
• Notificação de e-mail parece uma merda
• Esquema de bloqueio para webhook
• Design para a página da lista de alertas
• Ver histórico de alerta
• Visualize o histórico de alertas como anotações no gráfico
• Agendador de alertas e estabilidade do motor
• Melhorias no agendador de alertas para distribuir a carga (para que os alertas não sejam executados ao mesmo tempo)
• Clustering do agendador de alertas

Lamento muito que este recurso esteja demorando tanto.

@torkelo tenha a capacidade de colocar as máquinas em modo de manutenção por um determinado período no beta.

@torkelo Obrigado pela atualização. Pelo que posso ver, isso é voltado para ter alertas dentro do Grafana. Você ainda está seguindo o curso modular apresentado em https://github.com/grafana/grafana/issues/2209#issuecomment -149351263?

Também graças a quem quer que sejam os elfos ocultos que estão trabalhando nisso. Suspeito de @Dieterbe , mas não sei.

@RichiH , não temos certeza de como isso funcionará, tentamos descobrir como fazer um sistema como aquele comentário, mas não temos certeza de como funcionará. Estamos focados agora em uma experiência de alerta forte e pronta para uso, que pode se tornar melhor com o tempo. Os usuários com o gerenciador de alerta existente podem potencialmente desativar o executor de alerta no Grafana e fazer com que o Grafana envie o alerta que precisa ser avaliado para outro sistema. No entanto, seria necessário muito trabalho em sistemas de terceiros para implementar essa integração.

@torkelo Meus pensamentos estavam na mesma linha, por isso decidi perguntar.

Pessoalmente falando, me preocupo com o alerta de Prometheus, mas gostaria de uma boa integração visual com Grafana. Não me importo muito onde defino as regras, desde que sejam armazenadas e executadas pelo Prometheus.

@bergquist Como você estará na promcon, sentar e conversar sobre possíveis abordagens pode fazer sentido. Se você quiser, vou cutucar os desenvolvedores de Prometheus sobre qual horário seria melhor. Pode haver ou não um momento de silêncio para sentar na noite anterior e / ou após a limpeza; Eu posso te avisar se você quiser.

Olá @torkelo - parece ótimo.

Acabei de retirar seu branch e quando testo um alarme para ElasticSearch recebo o erro

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

... isso significa que ElasticSearch ainda não é compatível: cry:

ps na saída do processo, recebo o seguinte:

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

@ Workshop2 , só suportamos grafite para alertas até agora, mas apoiaremos Elasticsearch eventualmente :) Acrescentarei uma mensagem de erro melhor para isso.

Como o sistema de alerta se comportará se a consulta não retornar dados? Irá disparar um alerta por padrão?
Além disso, um redutor count simples seria legal, pois simplesmente retornaria o número de pontos de dados retornados por uma consulta.

@bergquist Achei que o alerta seria transparente em relação à fonte de dados usada. Quanto tempo antes de podermos começar a visualizar / testar o recurso de alerta em outra fonte de dados de grafite? (Eu percebo 'quanto tempo ...' perguntas de que ninguém gosta, desculpe)

@RichiH Uma opção é criar um aplicativo grafana como o bosun faz. https://grafana.net/plugins/bosun-app Mas isso não permite a reutilização de consulta / painel de forma simples. Vamos conversar mais sobre isso na promcon. Ansioso para conhecê-lo! :)

Nenhum suporte influxdb inicialmente também?

eu não sabia seu limite específico para grafite :( Também estamos usando influxo e
elasticsearch;)

Na segunda-feira, 8 de agosto de 2016 às 14h18, elvarb [email protected] escreveu:

Nenhum suporte influxdb inicialmente também?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -238218714,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AEKf_4yp6-34PaOE2z4ynSriRxQpjKcvks5qdx59gaJpZM4FJUTl
.

Enrico Kern

Engenheiro-chefe de sistema

glispa GmbH
Sonnenburger Straße 73
10437 Berlim, Alemanha

tel .: +49 30 5557130-17
fax: +49 30 5557130-50
skype: flyersaenrico. [email protected]

---

Sitz Berlin, AG Charlottenburg HRB 114678B

Apenas no início, provavelmente adicionaremos o Prometheus antes do lançamento. Talvez o InfluxDB ou o Elasticsearch também, uma vez que o agendamento e a execução do alerta estão acontecendo no backend, o código de solicitação e resposta foi escrito do zero (em Go), o código do plugin de origem de dados do frontend (escrito em js) não pode ser reutilizado.

Estamos usando influx, acho que podemos abrir mão da integração grafana e usar o Kapacitor com um front-end web simples para criar e gerenciar alertas.

+1 Alerta + InfluxDB.

Na segunda-feira, 8 de agosto de 2016 às 6:01, Thom Nichols [email protected]
escreveu:

Estamos usando influxo, acho que podemos abrir mão da integração e uso da grafana
Kapacitor com um front-end web simples para criar e gerenciar alertas.

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -238228133,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAY0-VP--Ysoxu5IV0hslQrP8cvF5ePSks5qdyi_gaJpZM4FJUTl
.

Deepak

É uma pena que o trabalho que colocamos na construção de plug-ins de fonte de dados só seja útil no cliente.

Considerando o trabalho imediato e a longo prazo de suporte ao alerta para diferentes fontes de dados, construção de uma arquitetura de plug-in go etc, não seria quase a mesma quantidade de trabalho (se não menos) para construir o servidor de alerta em NodeJS, para que ele pudesse usar o existente plugins da fonte de dados?

Deixando de lado as opiniões sobre go vs. nodejs, isso poderia reduzir significativamente a duplicação de código para alertar em diferentes fontes de dados.

E se você realmente não gosta do node, aposto que há um mecanismo de chamada em go para carregar e executar JS.

Alerta de +1 para ElasticSearch

Olá, estamos aguardando o sistema de alerta para ... OpenTSDB! Nós podemos
espera obtê-lo em breve para OpenTSDB? (Talvez quando?)

Muito obrigado à equipe!

08/08/2016 17:28 GMT + 02: 00 Slava Vishnyakov [email protected] :

Alerta de +1 para ElasticSearch

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -238273405,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ARsY50v7meI_EuzSAJGtvDMDareYKSDhks5qd0sggaJpZM4FJUTl
.

Alerta de +1 para ElasticSearch
Teria a possibilidade de executar um script sob alerta?

Vocês já têm o branch de alerta em uma imagem docker?

1. As consultas de alerta estão funcionando apenas para a consulta "A"? Isso é codificado?
2. Quando podemos esperar uma versão de alerta totalmente funcional? (19 ainda é o alvo)
3. Quando podemos esperar que o Elasticsearch funcione com alertas?

Editar:

1. Posso adicionar mais de uma regra de alarme por gráfico?
2. Posso adicionar algumas informações sobre o alarme à mensagem HTTP? (painel / gráfico / observado_query / alarm_config / alarm_query / threshold / warn_or_crit / value / observado_timeframe / time_of_occurence)

@ DEvil0000

1) Você pode mudar para qualquer consulta que tenha na guia de métricas.
2) Funcionando totalmente, depende do que você quer dizer. Planejamos mesclá-lo para masterizar esta semana. Então, as pessoas podem começar a testar a compilação noturna e dar feedback. Versão alfa dentro de 2-3 semanas, versão beta e estável depende do feedback e da rapidez com que pode se tornar estável
3) Elasticsearch é complicado, requer muito código para consultar e analisar a resposta em séries temporais, então provavelmente virá depois que o suporte para Prometheus e InfluxDB for adicionado

@torkelo
Eu sou novo em elasticsearch, grafana e go lang. E acho que você já procurou clientes, mas já viu?
https://github.com/olivere/elastic
https://github.com/mattbaird/elastigo
Essas libs podem reduzir o esforço.

Também graças a quem quer que sejam os elfos ocultos que estão trabalhando nisso. Suspeito de @Dieterbe , mas não sei.

Os alertas agora são principalmente @torkelo e @bergquist (e @mattttt ). Mudei o foco para nosso próximo back-end de grafite, https://github.com/raintank/metrictank

Estou muito feliz em ver esse recurso progredindo. Adoraria ter suporte para OpenTSDB, pois outras soluções de alerta (Bosun) não seriam amigáveis ​​o suficiente para uso regular aqui.

Espero ver o alarme na próxima versão oficial e prestar homenagem aos programadores que trabalharam duro para codificar.

Espero ver o alarme na próxima versão oficial e prestar homenagem aos programadores que trabalharam duro para codificar.

@superbool, desculpe, não consigo ler isso e a tradução do Google não foi muito útil

Merge to master VAI acontecer em 19 de agosto, eu prometo :)

@torkelo hehe da próxima vez que apostar. Existe uma nova data?

Podemos esperar que o alerta para OpenTSDB seja agendado? Podemos encontrar
(modesto) fundando para encorajar dev.

22/08/2016 10:05 GMT + 02: 00 A. Binzxxxxxx [email protected] :

Espero ver o alarme na próxima versão oficial e prestar homenagem aos programadores que trabalharam duro para codificar.

@superbool https://github.com/superbool desculpe não posso ler isso e
a tradução do google não foi muito útil

Merge to master VAI acontecer em 19 de agosto, eu prometo :)

@torkelo https://github.com/torkelo hehe da próxima vez, aposto. Existe um
Nova data?

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -241340597,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ARsY59771TaHEIaqCHbf-4TKWc4OdjVXks5qiVhdgaJpZM4FJUTl
.

@ DEvil0000 Espero que o recurso de alerta possa ser publicado na próxima versão estável do Grafana, e gostaria de prestar uma grande homenagem a todos os que desenvolvem a ferramenta.
Desculpe, meu inglês não é muito bom, espero que você possa entender minhas palavras

@ DEvil0000 O plano era a fusão na última sexta-feira, mas devido a alguns eventos não planejados (https://twitter.com/torkelo/status/766514688997732352), tivemos que adiar um pouco :) Ainda temos algumas coisas menores a fazer.

Parabéns @torkelo !
@bergquist @torkelo Eu preciso alertar com elástico antes de outubro (alfa seria bom para mim). Posso ajudar vocês a implementá-lo? Você só precisa me fornecer algumas informações para ter um ponto de partida;)

O branch de alerta agora foi mesclado ao master. : raised_hands:

Agradecemos todos os comentários que recebemos sobre este problema. Obrigado a todos vocês !
Para discussões e comentários futuros, poste no problema de alerta correspondente ou crie um novo. Isso nos ajuda a organizar e priorizar nosso trabalho futuro. Estou fechando este tíquete em favor dos novos. Mas fique à vontade para manter a discussão nesta edição.

Então o que vem depois?

• Versão alfa (documentos e postagem do blog)
• Obtenha feedback da comunidade.
• Continue trabalhando nas questões restantes
• Libere o Grafana 4.0 com alerta.

Experimente?

• Você tem que habilitar o alerta na configuração .
• Agora você pode encontrar alertas no menu lateral.
• Você pode adicionar um alerta acessando um painel de gráfico e selecionando a guia de alerta.
• Use o botão _Teste alert_ para verificar o seu alerta.
• Para salvar o alerta basta salvar o painel.
• Configure a notificação / alerta / notificações para ser notificado sobre o disparo de alertas.
• Adicione o notificador a um alerta na guia de alerta.

Limitações atuais

• Até agora, só oferecemos suporte a grafite.
• Para esta versão, apenas o painel gráfico tem suporte para alertas.

Painéis de exemplo

Você pode encontrar painéis de exemplo na pasta de exemplos.
Os painéis de exemplo são baseados nos dados de nosso gravador de dados de grafite falso. Você pode iniciar o grafite e o gravador de dados falsos a partir de nossos arquivos docker-compose.

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

Isso deve ser considerado apenas um guia aproximado e adicionaremos mais documentação sobre alertas nas semanas seguintes.

Feliz alerta! : cocktail:: tada:

Parabéns @bergquist .

Há algum problema que possamos acompanhar sobre o futuro desse recurso?

@ Workshop2 https://github.com/grafana/grafana/issues/5858

Há apenas um "E" e não um "OU" nas Condições de alerta para adicionar "está acima de" OU "está abaixo" em um painel ou há outra maneira de oferecer suporte a isso?

Acho que há uma opção "está fora do intervalo" / "está dentro do intervalo". Mas também gostaria de ver um "ou".

Olá a todos! Muito obrigado por sua contribuição nesta funcionalidade útil.

É realmente interessante para mim, mas em muitos casos eu precisaria de um "OU" nas condições de alerta porque não há possibilidade de criar mais de um alerta em um gragh.

Acho que sem esse "OU" não poderei criar alertas para este tipo de gráfico:

Qualquer ideia? Você está planejando adicionar uma opção "OU"?

BR

@jmgonzalezp sim, esperamos oferecer suporte a OR também (ainda não tenho certeza sobre a combinação de AND e OR)

Temos 2 decisões de design restantes para alertar que adoraríamos receber algum feedback (categorização e gravidade / estado).

Aqui está o problema com nossos pensamentos atuais e realmente apreciaríamos seus comentários.
https://github.com/grafana/grafana/issues/6007

Olá a todos! Obrigado por esse ótimo recurso na grafana!

Tenho uma pergunta sobre este sistema de alerta. Atualmente, estamos usando o grupo de escalonamento automático no AWS para implantar o grafana. Isso seria um problema se eu executasse o grafana em várias máquinas? O problema que estou me referindo é: haveria vários alertas iguais de várias máquinas grafana? Ou a grafana já cuidou disso?

@torkelo Tenho a mesma pergunta que @akurniawan. Vamos considerar esta configuração: 1 balanceador de carga, 3 instâncias Grafana atrás do balanceador de carga, 1 banco de dados Mysql que todas as 3 instâncias compartilham. Como os servidores Grafana lidarão com os alertas neste tipo de configuração? Devemos habilitar os alertas apenas em uma instância ou o Grafana mantém o controle dos alertas para que vários nós não verifiquem e enviem os mesmos alertas?

@utkarshcmu @akurniawan alertando dentro da grafana ainda não suporta HA. Nosso plano é adicionar suporte para particionar alertas entre servidores no futuro.

@bergquist Obrigado pela resposta. :)

@bergquist Qualquer ETA ativado quando o suporte ao InfluxDB será adicionado para isso?

@thisisjaid a julgar por este https://github.com/grafana/grafana/milestone/40 deve estar aqui no dia 10.

@Dieterbe Qualquer ETA para alertar o suporte para OpenTSDB?

@sofixa Obrigado, deveria ter olhado o roteiro eu mesmo, caso não RTFMing. Apreciado, no entanto.

@Dieterbe Qualquer ETA para alertar o suporte para OpenTSDB?

eu não trabalho mais em alertas. talvez @torkelo ou @bergquist possam responder.

@torkelo @bergquist

Qualquer ETA para alertar o suporte para OpenTSDB

@LoaderMick @ naveen-tirupattur Alerta de OpenTSDB adicionado ao Grafana, deve fazer parte da próxima versão. Além disso, o alerta para OpenTSDB está funcionando nas compilações noturnas.

Qualquer ETA para alertar o suporte para influxDB e prometheus também?

O alerta

Não consigo obter o alerta funcionando com OpenTSDB com (Grafana v4.0.0-pre1 (commit: 578507a)). Testei o sistema de e-mail (funcionando), mas os alertas simplesmente não disparam, mesmo quando tenho um limite muito baixo. Existe alguma maneira de executar as consultas manualmente e ver os dados que está puxando?

Grafana v4.0.0-pre1 (commit: 9b28bf2)
error tsdb.HandleRequest () error Influxdb retornou statuscode código de status inválido: 400 Bad Request

@torkelo
A 'notificação de alerta do webhook' pode postar a métrica de alerta, json ou tipo de formulário?

Olá pessoal, o Grafana oferecerá suporte a alertas para consultas usando variáveis ​​de modelo ou existe uma versão alvo para isso?

Todos, por favor, tente 4.0 beta; se algo estiver faltando, abra novos números.

Richard

Enviado por celular; desculpe minha brevidade.

Eu tentei 4.0 beta, mas ainda recebo este erro
error tsdb.HandleRequest () error Influxdb retornou statuscode código de status inválido: 400 Bad Request

Não consigo salvar notificações de alerta - enviar para, depois de salvar, a linha enviar para ficou em branco novamente

@nnsaln Você deve preencher o alvo de notificação lá, não o endereço de e-mail. Abra o menu lateral grafana e passe o mouse sobre a opção de menu Alerta, em seguida, clique nas opções do menu Notificações. Lá você pode configurar um alvo de notificação que pode ser usado a partir de suas regras de alerta.

Existe algum plano para oferecer suporte a variáveis ​​de modelo junto com alertas? eu faço
entender cada gráfico gerado por uma (ou conjunto) variável de modelo corresponde
para um gráfico diferente e, portanto, gerar alerta contra um valor estático é
incorreto.

Na segunda-feira, 5 de dezembro de 2016 às 2h06, Tomas Barton [email protected]
escreveu:

@nnsaln https://github.com/nnsaln Você deve preencher a notificação
almeje lá, não o endereço de e-mail. Abra o menu lateral grafana e passe o mouse sobre
a opção de menu Alerta e, em seguida, clique nas opções do menu Notificações. Lá
você pode configurar um alvo de notificação que pode ser usado a partir de suas regras de alerta.

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-264813888 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAY0-X4UkyVE0MeBlSiYD9892OuruGcVks5rE-I6gaJpZM4FJUTl
.

-
Deepak

Não, atualmente não há suporte para fazer isso. Talvez em um futuro distante, mas

99% dos painéis usam variáveis ​​de modelo. Eles foram projetados com um modelo
variáveis ​​para evitar o problema de "explosão do painel".

Na segunda-feira, 5 de dezembro de 2016 às 20:20, Torkel Ödegaard [email protected]
escreveu:

Não, atualmente não há suporte para fazer isso. Talvez em um futuro distante, mas

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-265056805 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAY0-T9iFrqUcq4KbIECDe526040U6DHks5rFOJ4gaJpZM4FJUTl
.

-
Deepak

Sim, mas um painel de exploração genérico não é o mesmo que um design de painel para regras de alerta.

Até agora não houve uma proposta de como oferecer suporte a variáveis ​​de modelo de uma forma intuitiva / compreensível. O que a consulta de alerta com variável deve fazer? Interpolar com o valor da variável salva atual, com tudo? Deve tratar cada valor como uma regra separada e manter o estado para cada etc. Variáveis ​​de modelo de suporte abre uma lata de vermes para a complexidade e comportamento potencialmente confuso. pode ser adicionado algum dia se alguém vier com uma maneira simples e compreensível.

Nesse ínterim, nada o impede de criar painéis de alerta separados.
O alerta é novo e uma grande adição ao grafana. Vai evoluir com o tempo,
mas no curto tempo em que foi implementado, agregou um grande valor à grafana,
e obrigado a todos os contribuidores por isso!

Am 06.12.2016 11:14 nachm. schrieb "Torkel Ödegaard" <
notificaçõ[email protected]>:

Sim, mas um painel de exploração genérico não é o mesmo que um painel
design para regras de alerta.

Até agora não houve uma proposta de como oferecer suporte a variáveis ​​de modelo
de forma intuitiva / compreensível. O que deve alertar a consulta com variável
Faz? Interpolar com o valor da variável salva atual, com tudo? Deveria
trate cada valor como uma regra separada e mantenha o estado para cada etc.
variáveis ​​de modelo abre uma lata de vermes para a complexidade e potencialmente
comportamento confuso. pode ser adicionado algum dia se alguém vier com um
maneira simples e compreensível.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-265290049 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AEKf_5VldwX2fG-USjnmlMH2qOZIDdKpks5rFd5DgaJpZM4FJUTl
.

+1 Torkel.

Isso torna o alerta bastante complicado.

Na terça - feira, 6 de dezembro de 2016 às 14h14, Torkel Ödegaard
escreveu:

Sim, mas um painel de exploração genérico não é o mesmo que um painel
design para regras de alerta.

Até agora não houve uma proposta de como oferecer suporte a variáveis ​​de modelo
de forma intuitiva / compreensível. O que deve alertar a consulta com variável
Faz? Interpolar com o valor da variável salva atual, com tudo? Deveria
trate cada valor como uma regra separada e mantenha o estado para cada etc.
variáveis ​​de modelo abre uma lata de vermes para a complexidade e potencialmente
comportamento confuso. pode ser adicionado algum dia se alguém vier com um
maneira simples e compreensível.

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-265290049 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAY0-UgrMH9u7sI-FmPVgFhMVXJBvzTvks5rFd48gaJpZM4FJUTl
.

-
Deepak

@bergquist sobre este comentário

alertar dentro da grafana ainda não suporta HA. Nosso plano é adicionar suporte para alertas de partição entre servidores no futuro

Existe um tíquete para acompanhar o progresso? Alguma filial para contribuir?

E muito obrigado pelo bom trabalho!

Kern,

<3 grafana.

Eu estava apenas tentando compartilhar ideias sobre alertas com modelo
painéis.

Na sexta-feira, 9 de dezembro de 2016 às 2h53, Dmitry Zhukov [email protected]
escreveu:

@bergquist https://github.com/bergquist em relação a este comentário

alertar dentro da grafana ainda não suporta HA. Nosso plano é adicionar
suporte para particionar alertas entre servidores no futuro

Existe um tíquete para acompanhar o progresso? Alguma filial para contribuir?

E muito obrigado pelo bom trabalho!

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-265986808 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAY0-aQXFZUeEfVl0MSQP7FQpMZGIh0mks5rGTMsgaJpZM4FJUTl
.

-
Deepak

@torkelo @Dieterbe É incrível finalmente ter o alerta embutido no Grafana! Qual é a maneira recomendada (se houver) de criar alertas programaticamente?

@jaimegago para criar alertas de forma programática, use a API do painel, os alertas são salvos junto com um painel e painel.

@torkelo E quanto aos alvos de notificações (por exemplo, criar um novo e-mail de notificação via API)?

editar: respondendo a mim mesmo aqui, encontrei o endpoint api / alert-notifications. Acho que só precisa ser documentado

Claro que existe uma api http para isso, basta ir à página de notificações de alerta, adicionar uma notificação e verificar a chamada de api http que grafana faz

@torkelo , existe alguma API que pode ser usada para criar alerta (não criar notificação de alerta) programaticamente

@CCWeiZ Alerts é uma parte do painel json. Portanto, você só pode criar um painel que contenha alertas, não apenas alertas.

Você pode ler mais sobre a api do painel em http://docs.grafana.org/http_api/dashboard/

está disponível: Eu quero configurar um alerta para se um valor se comparar a 3 dias atrás, o valor não está aumentando. (diz as solicitações, se agora valor - 3 dias atrás solicitações <100, então dizemos que não há muitas solicitações.). Como fazer isso?