Comparação do Prometheus com alternativas

janeiro 24, 2024
By Júlia Mascarenhas

Prometheus vs. Graphite

Escopo

O Graphite concentra-se em ser um banco de dados de séries temporais passivo com uma linguagem de consulta e recursos gráficos. Outras preocupações são tratadas por componentes externos.

O Prometheus é um sistema completo de monitoramento e tendências que inclui scraping incorporado e ativo, armazenamento, consulta, gráficos e alertas com base em dados de séries temporais. Ele possui conhecimento sobre como o mundo deve parecer (quais endpoints devem existir, o que padrões de séries temporais indicam problemas, etc.) e ativamente procura por falhas.

Modelo de Dados

O Graphite armazena amostras numéricas para séries temporais nomeadas, de maneira semelhante ao Prometheus. No entanto, o modelo de metadados do Prometheus é mais rico: enquanto os nomes das métricas no Graphite consistem em componentes separados por ponto, que implicitamente codificam dimensões, o Prometheus codifica dimensões explicitamente como pares chave-valor, chamados rótulos, anexados a um nome de métrica. Isso permite fácil filtragem, agrupamento e correspondência por meio desses rótulos por meio da linguagem de consulta.

Além disso, especialmente quando o Graphite é usado em combinação com o StatsD, é comum armazenar apenas dados agregados sobre todas as instâncias monitoradas, em vez de preservar a instância como uma dimensão e poder analisar individualmente instâncias problemáticas.

Por exemplo, armazenar o número de solicitações HTTP para servidores de API com o código de resposta 500 e o método POST para o endpoint  /tracks seria comumente codificado assim no Graphite/StatsD:

stats.api-server.tracks.post.500 -> 93

No Prometheus, os mesmos dados poderiam ser codificados da seguinte maneira (supondo três instâncias de api-server):

api_server_http_requests_total{method=”POST”,handler=”/tracks”,status=”500″,instance=”<sample1>”} -> 34

api_server_http_requests_total{method=”POST”,handler=”/tracks”,status=”500″,instance=”<sample2>”} -> 28

api_server_http_requests_total{method=”POST”,handler=”/tracks”,status=”500″,instance=”<sample3>”} -> 31

Armazenamento

O Graphite armazena dados de séries temporais no disco local no formato Whisper, um banco de dados no estilo RRD que espera que as amostras cheguem em intervalos regulares. Cada série temporal é armazenada em um arquivo separado, e novas amostras sobrescrevem as antigas após um certo período de tempo.

O Prometheus também cria um arquivo local por série temporal, mas permite armazenar amostras em intervalos arbitrários à medida que as raspagens ou avaliações de regras ocorrem. Como as novas amostras são simplesmente anexadas, dados antigos podem ser mantidos por tempo indeterminado. O Prometheus também funciona bem para muitos conjuntos de séries temporais de curta duração e frequentemente alterados.

Resumo

O Prometheus oferece um modelo de dados mais rico e uma linguagem de consulta mais avançada, além de ser mais fácil de ser executado e integrado ao seu ambiente. Se você deseja uma solução em cluster que possa armazenar dados históricos a longo prazo, o Graphite pode ser uma escolha mais adequada.


Prometheus vs. InfluxDB

O InfluxDB é um banco de dados de séries temporais de código aberto, com uma opção comercial para escalabilidade e clusterização. O projeto InfluxDB foi lançado quase um ano depois do início do desenvolvimento do Prometheus, então não pudemos considerá-lo como uma alternativa na época. No entanto, existem diferenças significativas entre o Prometheus e o InfluxDB, e ambos os sistemas são voltados para casos de uso ligeiramente diferentes.

Escopo

Para uma comparação justa, também devemos considerar o Kapacitor em conjunto com o InfluxDB, pois em combinação eles abordam o mesmo espaço de problema que o Prometheus e o Alertmanager.

As mesmas diferenças de escopo que se aplicam ao Graphite neste caso também se aplicam ao InfluxDB. Além disso, o InfluxDB oferece consultas contínuas, que são equivalentes às regras de gravação do Prometheus.

O escopo do Kapacitor combina as regras de gravação do Prometheus, regras de alerta e a funcionalidade de notificação do Alertmanager. O Prometheus oferece uma linguagem de consulta mais poderosa para gráficos e alertas. O Alertmanager do Prometheus adicionalmente oferece funcionalidades de agrupamento, deduplicação e silenciamento.

Modelo de dados / armazenamento

Assim como o Prometheus, o modelo de dados do InfluxDB possui pares chave-valor como rótulos, chamados de tags. Além disso, o InfluxDB possui um segundo nível de rótulos chamados de fields, que são mais limitados em uso. O InfluxDB suporta carimbos de data/hora com resolução de até nanossegundos e tipos de dados float64, int64, bool e string. O Prometheus, por outro lado, suporta o tipo de dados float64 com suporte limitado para strings e carimbos de data/hora com resolução de milissegundos.

O InfluxDB utiliza uma variante de uma árvore de mesclagem estruturada por log para armazenamento, com um log de gravação à frente, particionado pelo tempo. Isso é muito mais adequado para o registro de eventos do que a abordagem de arquivo apenas para séries temporais do Prometheus.

Logs e Métricas e Gráficos, Ah, Meu Deus! descreve as diferenças entre o registro de eventos e o registro de métricas.

Arquitetura

Os servidores do Prometheus funcionam de forma independente entre si e dependem apenas do armazenamento local para suas funcionalidades principais: coleta, processamento de regras e alertas. A versão de código aberto do InfluxDB é semelhante.

A oferta comercial do InfluxDB é, por design, um cluster de armazenamento distribuído, com armazenamento e consultas sendo tratados por muitos nós ao mesmo tempo.

Isso significa que o InfluxDB comercial será mais fácil de escalar horizontalmente, mas também significa que você terá que lidar com a complexidade de um sistema de armazenamento distribuído desde o início. O Prometheus será mais simples de executar, mas em algum momento será necessário dividir os servidores explicitamente ao longo dos limites de escalabilidade, como produtos, serviços, data centers ou aspectos semelhantes. Servidores independentes (que podem ser executados redundantemente em paralelo) também podem proporcionar melhor confiabilidade e isolamento de falhas.

A versão de código aberto do Kapacitor não possui opções embutidas distribuídas/redundantes para regras, alertas ou notificações. A versão de código aberto do Kapacitor pode ser dimensionada por meio de fragmentação manual pelo usuário, semelhante ao Prometheus em si. O Influx oferece o Enterprise Kapacitor, que suporta um sistema de alerta de alta disponibilidade/redundante.

Em contraste, o Prometheus e o Alertmanager oferecem uma opção totalmente de código aberto e redundante, executando réplicas redundantes do Prometheus e utilizando o modo de alta disponibilidade do Alertmanager.

Resumo

Existem muitas semelhanças entre os sistemas. Ambos têm rótulos (chamados de tags no InfluxDB) para suportar eficientemente métricas multidimensionais. Ambos utilizam basicamente os mesmos algoritmos de compressão de dados. Ambos têm integrações extensas, inclusive entre si. Ambos possuem ganchos que permitem estender suas funcionalidades, como analisar dados em ferramentas estatísticas ou realizar ações automatizadas.

Onde o InfluxDB se destaca:

  • Se você está realizando o registro de eventos.

  • A opção comercial oferece clustering para o InfluxDB, o que é especialmente vantajoso para armazenamento de dados a longo prazo.

  • Visão eventualmente consistente dos dados entre réplicas.

Onde o Prometheus se destaca:

  • Se você está principalmente lidando com métricas.

  • Linguagem de consulta mais poderosa, funcionalidades avançadas de alerta e notificação.

  • Maior disponibilidade e tempo de atividade para gráficos e alertas.

O InfluxDB é mantido por uma única empresa comercial seguindo o modelo de núcleo aberto (open-core), oferecendo recursos premium como clustering de código fechado, hospedagem e suporte. O Prometheus é um projeto totalmente de código aberto e independente, mantido por diversas empresas e indivíduos, alguns dos quais também oferecem serviços comerciais e suporte.


Prometheus vs. OpenTSDB

OpenTSDB é um banco de dados distribuído de séries temporais baseado em Hadoop e HBase.

Escopo

As mesmas diferenças de escopo que se aplicam ao Graphite neste caso também se aplicam aqui.

Modelo de dados

O modelo de dados do OpenTSDB é quase idêntico ao do Prometheus: as séries temporais são identificadas por um conjunto de pares chave-valor arbitrários (as tags do OpenTSDB são equivalentes aos rótulos do Prometheus). Todos os dados para uma métrica são armazenados juntos, limitando a cardinalidade das métricas. Existem algumas diferenças menores, no entanto: o Prometheus permite caracteres arbitrários em valores de rótulo, enquanto o OpenTSDB é mais restritivo. Além disso, o OpenTSDB não possui uma linguagem de consulta completa, permitindo apenas agregação simples e operações matemáticas por meio de sua API.

Armazenamento

O armazenamento do OpenTSDB é implementado sobre o Hadoop e o HBase. Isso significa que é fácil dimensionar o OpenTSDB horizontalmente, mas você deve aceitar a complexidade geral de executar um cluster Hadoop/HBase desde o início. 

O Prometheus será mais simples de executar inicialmente, mas exigirá fragmentação explícita assim que a capacidade de um único nó for excedida.

Resumo

O Prometheus oferece uma linguagem de consulta muito mais rica, pode lidar com métricas de maior cardinalidade e faz parte de um sistema de monitoramento completo. Se você já está executando o Hadoop e valoriza o armazenamento a longo prazo mais do que esses benefícios, o OpenTSDB é uma boa escolha.


Prometheus vs. Nagios

Nagios é um sistema de monitoramento que teve origem nos anos 1990 como NetSaint.

Escopo

O Nagios é principalmente voltado para alertas baseados nos códigos de saída de scripts, chamados de “checks”. Há silenciamento de alertas individuais, mas não há agrupamento, roteamento ou deduplicação.

Existem diversos plugins, como por exemplo, encaminhar os poucos kilobytes de dados de desempenho que os plugins podem retornar para um banco de dados de séries temporais, como o Graphite, ou usar o NRPE para executar checks em máquinas remotas.

Modelo de dados

O Nagios é baseado em hosts. Cada host pode ter um ou mais serviços, e cada serviço pode realizar um check.

Não há noção de rótulos ou de uma linguagem de consulta.

Armazenamento

O Nagios não possui armazenamento próprio, além do estado atual do check. Existem plugins que podem armazenar dados para visualização.

Arquitetura

Os servidores Nagios são independentes. Toda a configuração dos checks é feita por meio de arquivos.

Resumo

O Nagios é adequado para monitoramento básico de sistemas pequenos e/ou estáticos, onde a sondagem “blackbox” (caixa preta) é suficiente.

Se você deseja fazer monitoramento “whitebox” (caixa branca) ou possui um ambiente dinâmico ou baseado em nuvem, então o Prometheus é uma boa escolha.


Prometheus vs. Sensu

Sensu é uma canalização de monitoramento e observabilidade de código aberto com uma distribuição comercial que oferece recursos adicionais para escalabilidade. Ele pode reutilizar plugins existentes do Nagios.

Escopo

O Sensu é uma canalização de observabilidade que se concentra no processamento e alerta de dados de observabilidade como uma sequência de Eventos. Ele fornece um framework extensível para filtragem, agregação, transformação e processamento de eventos – incluindo o envio de alertas para outros sistemas e armazenamento de eventos em sistemas de terceiros. As capacidades de processamento de eventos do Sensu têm escopo semelhante às regras de alerta do Prometheus e do Alertmanager.

Modelo de dados

Os Eventos do Sensu representam a saúde do serviço e/ou métricas em um formato de dados estruturados identificado por um nome de entidade (por exemplo, servidor, instância de computação em nuvem, contêiner ou serviço), um nome de evento e metadados opcionais de chave-valor chamados “rótulos” ou “anotações”. O payload do Evento Sensu pode incluir um ou mais points, métricos, representados como um objeto JSON contendo um name, tags (pares chave/valor), timestamp  e value  (sempre um float).

Armazenamento

O Sensu armazena informações de status de evento atuais e recentes e dados de inventário em tempo real em um banco de dados embutido (etcd) ou um SGBD externo (PostgreSQL).

Arquitetura

Todos os componentes de uma implantação do Sensu podem ser agrupados para alta disponibilidade e aumento da taxa de processamento de eventos.

Resumo

Sensu e Prometheus têm algumas capacidades em comum, mas abordam o monitoramento de maneiras muito diferentes. Ambos oferecem mecanismos de descoberta extensíveis para ambientes dinâmicos baseados em nuvem e plataformas de computação efêmera, embora os mecanismos subjacentes sejam bastante diferentes. Ambos oferecem suporte para coletar métricas multidimensionais por meio de rótulos e anotações. Ambos têm integrações extensas, e o Sensu suporta nativamente a coleta de métricas de todos os exportadores do Prometheus. Ambos são capazes de encaminhar dados de observabilidade para plataformas de dados de terceiros (por exemplo, armazenamento de eventos ou TSDBs). Onde Sensu e Prometheus diferem mais é em seus casos de uso.

Onde Sensu se destaca:

  • Se você está coletando e processando dados híbridos de observabilidade (incluindo métricas e/ou eventos).

  • Se você está consolidando várias ferramentas de monitoramento e precisa de suporte para métricas e plugins ou scripts de verificação no estilo Nagios.

  • Plataforma de processamento de eventos mais poderosa.

Onde Prometheus se destaca:

  • Se você está principalmente coletando e avaliando métricas.

  • Se você está monitorando a infraestrutura homogênea do Kubernetes (se 100% das cargas de trabalho que você está monitorando estão no K8s, o Prometheus oferece melhor integração com o K8s).

  • Linguagem de consulta mais poderosa e suporte integrado para análise de dados históricos.

O Sensu é mantido por uma única empresa comercial seguindo o modelo de negócios de núcleo aberto, oferecendo recursos premium como correlação e agregação de eventos de código fechado, federação e suporte. O Prometheus é um projeto totalmente de código aberto e independente, mantido por diversas empresas e indivíduos, alguns dos quais também oferecem serviços comerciais e suporte.


Fonte: https://prometheus.io/docs/introduction/comparison/

Comparação do Prometheus com alternativas

/ Uncategorized / Por

Prometheus vs. Graphite

Escopo

O Graphite concentra-se em ser um banco de dados de séries temporais passivo com uma linguagem de consulta e recursos gráficos. Outras preocupações são tratadas por componentes externos.

O Prometheus é um sistema completo de monitoramento e tendências que inclui scraping incorporado e ativo, armazenamento, consulta, gráficos e alertas com base em dados de séries temporais. Ele possui conhecimento sobre como o mundo deve parecer (quais endpoints devem existir, o que padrões de séries temporais indicam problemas, etc.) e ativamente procura por falhas.

Modelo de Dados

O Graphite armazena amostras numéricas para séries temporais nomeadas, de maneira semelhante ao Prometheus. No entanto, o modelo de metadados do Prometheus é mais rico: enquanto os nomes das métricas no Graphite consistem em componentes separados por ponto, que implicitamente codificam dimensões, o Prometheus codifica dimensões explicitamente como pares chave-valor, chamados rótulos, anexados a um nome de métrica. Isso permite fácil filtragem, agrupamento e correspondência por meio desses rótulos por meio da linguagem de consulta.

Além disso, especialmente quando o Graphite é usado em combinação com o StatsD, é comum armazenar apenas dados agregados sobre todas as instâncias monitoradas, em vez de preservar a instância como uma dimensão e poder analisar individualmente instâncias problemáticas.

Por exemplo, armazenar o número de solicitações HTTP para servidores de API com o código de resposta 500 e o método POST para o endpoint  /tracks seria comumente codificado assim no Graphite/StatsD:

stats.api-server.tracks.post.500 -> 93

No Prometheus, os mesmos dados poderiam ser codificados da seguinte maneira (supondo três instâncias de api-server):

api_server_http_requests_total{method=”POST”,handler=”/tracks”,status=”500″,instance=”<sample1>”} -> 34

api_server_http_requests_total{method=”POST”,handler=”/tracks”,status=”500″,instance=”<sample2>”} -> 28

api_server_http_requests_total{method=”POST”,handler=”/tracks”,status=”500″,instance=”<sample3>”} -> 31

Armazenamento

O Graphite armazena dados de séries temporais no disco local no formato Whisper, um banco de dados no estilo RRD que espera que as amostras cheguem em intervalos regulares. Cada série temporal é armazenada em um arquivo separado, e novas amostras sobrescrevem as antigas após um certo período de tempo.

O Prometheus também cria um arquivo local por série temporal, mas permite armazenar amostras em intervalos arbitrários à medida que as raspagens ou avaliações de regras ocorrem. Como as novas amostras são simplesmente anexadas, dados antigos podem ser mantidos por tempo indeterminado. O Prometheus também funciona bem para muitos conjuntos de séries temporais de curta duração e frequentemente alterados.

Resumo

O Prometheus oferece um modelo de dados mais rico e uma linguagem de consulta mais avançada, além de ser mais fácil de ser executado e integrado ao seu ambiente. Se você deseja uma solução em cluster que possa armazenar dados históricos a longo prazo, o Graphite pode ser uma escolha mais adequada.


Prometheus vs. InfluxDB

O InfluxDB é um banco de dados de séries temporais de código aberto, com uma opção comercial para escalabilidade e clusterização. O projeto InfluxDB foi lançado quase um ano depois do início do desenvolvimento do Prometheus, então não pudemos considerá-lo como uma alternativa na época. No entanto, existem diferenças significativas entre o Prometheus e o InfluxDB, e ambos os sistemas são voltados para casos de uso ligeiramente diferentes.

Escopo

Para uma comparação justa, também devemos considerar o Kapacitor em conjunto com o InfluxDB, pois em combinação eles abordam o mesmo espaço de problema que o Prometheus e o Alertmanager.

As mesmas diferenças de escopo que se aplicam ao Graphite neste caso também se aplicam ao InfluxDB. Além disso, o InfluxDB oferece consultas contínuas, que são equivalentes às regras de gravação do Prometheus.

O escopo do Kapacitor combina as regras de gravação do Prometheus, regras de alerta e a funcionalidade de notificação do Alertmanager. O Prometheus oferece uma linguagem de consulta mais poderosa para gráficos e alertas. O Alertmanager do Prometheus adicionalmente oferece funcionalidades de agrupamento, deduplicação e silenciamento.

Modelo de dados / armazenamento

Assim como o Prometheus, o modelo de dados do InfluxDB possui pares chave-valor como rótulos, chamados de tags. Além disso, o InfluxDB possui um segundo nível de rótulos chamados de fields, que são mais limitados em uso. O InfluxDB suporta carimbos de data/hora com resolução de até nanossegundos e tipos de dados float64, int64, bool e string. O Prometheus, por outro lado, suporta o tipo de dados float64 com suporte limitado para strings e carimbos de data/hora com resolução de milissegundos.

O InfluxDB utiliza uma variante de uma árvore de mesclagem estruturada por log para armazenamento, com um log de gravação à frente, particionado pelo tempo. Isso é muito mais adequado para o registro de eventos do que a abordagem de arquivo apenas para séries temporais do Prometheus.

Logs e Métricas e Gráficos, Ah, Meu Deus! descreve as diferenças entre o registro de eventos e o registro de métricas.

Arquitetura

Os servidores do Prometheus funcionam de forma independente entre si e dependem apenas do armazenamento local para suas funcionalidades principais: coleta, processamento de regras e alertas. A versão de código aberto do InfluxDB é semelhante.

A oferta comercial do InfluxDB é, por design, um cluster de armazenamento distribuído, com armazenamento e consultas sendo tratados por muitos nós ao mesmo tempo.

Isso significa que o InfluxDB comercial será mais fácil de escalar horizontalmente, mas também significa que você terá que lidar com a complexidade de um sistema de armazenamento distribuído desde o início. O Prometheus será mais simples de executar, mas em algum momento será necessário dividir os servidores explicitamente ao longo dos limites de escalabilidade, como produtos, serviços, data centers ou aspectos semelhantes. Servidores independentes (que podem ser executados redundantemente em paralelo) também podem proporcionar melhor confiabilidade e isolamento de falhas.

A versão de código aberto do Kapacitor não possui opções embutidas distribuídas/redundantes para regras, alertas ou notificações. A versão de código aberto do Kapacitor pode ser dimensionada por meio de fragmentação manual pelo usuário, semelhante ao Prometheus em si. O Influx oferece o Enterprise Kapacitor, que suporta um sistema de alerta de alta disponibilidade/redundante.

Em contraste, o Prometheus e o Alertmanager oferecem uma opção totalmente de código aberto e redundante, executando réplicas redundantes do Prometheus e utilizando o modo de alta disponibilidade do Alertmanager.

Resumo

Existem muitas semelhanças entre os sistemas. Ambos têm rótulos (chamados de tags no InfluxDB) para suportar eficientemente métricas multidimensionais. Ambos utilizam basicamente os mesmos algoritmos de compressão de dados. Ambos têm integrações extensas, inclusive entre si. Ambos possuem ganchos que permitem estender suas funcionalidades, como analisar dados em ferramentas estatísticas ou realizar ações automatizadas.

Onde o InfluxDB se destaca:

  • Se você está realizando o registro de eventos.

  • A opção comercial oferece clustering para o InfluxDB, o que é especialmente vantajoso para armazenamento de dados a longo prazo.

  • Visão eventualmente consistente dos dados entre réplicas.

Onde o Prometheus se destaca:

  • Se você está principalmente lidando com métricas.

  • Linguagem de consulta mais poderosa, funcionalidades avançadas de alerta e notificação.

  • Maior disponibilidade e tempo de atividade para gráficos e alertas.

O InfluxDB é mantido por uma única empresa comercial seguindo o modelo de núcleo aberto (open-core), oferecendo recursos premium como clustering de código fechado, hospedagem e suporte. O Prometheus é um projeto totalmente de código aberto e independente, mantido por diversas empresas e indivíduos, alguns dos quais também oferecem serviços comerciais e suporte.


Prometheus vs. OpenTSDB

OpenTSDB é um banco de dados distribuído de séries temporais baseado em Hadoop e HBase.

Escopo

As mesmas diferenças de escopo que se aplicam ao Graphite neste caso também se aplicam aqui.

Modelo de dados

O modelo de dados do OpenTSDB é quase idêntico ao do Prometheus: as séries temporais são identificadas por um conjunto de pares chave-valor arbitrários (as tags do OpenTSDB são equivalentes aos rótulos do Prometheus). Todos os dados para uma métrica são armazenados juntos, limitando a cardinalidade das métricas. Existem algumas diferenças menores, no entanto: o Prometheus permite caracteres arbitrários em valores de rótulo, enquanto o OpenTSDB é mais restritivo. Além disso, o OpenTSDB não possui uma linguagem de consulta completa, permitindo apenas agregação simples e operações matemáticas por meio de sua API.

Armazenamento

O armazenamento do OpenTSDB é implementado sobre o Hadoop e o HBase. Isso significa que é fácil dimensionar o OpenTSDB horizontalmente, mas você deve aceitar a complexidade geral de executar um cluster Hadoop/HBase desde o início. 

O Prometheus será mais simples de executar inicialmente, mas exigirá fragmentação explícita assim que a capacidade de um único nó for excedida.

Resumo

O Prometheus oferece uma linguagem de consulta muito mais rica, pode lidar com métricas de maior cardinalidade e faz parte de um sistema de monitoramento completo. Se você já está executando o Hadoop e valoriza o armazenamento a longo prazo mais do que esses benefícios, o OpenTSDB é uma boa escolha.


Prometheus vs. Nagios

Nagios é um sistema de monitoramento que teve origem nos anos 1990 como NetSaint.

Escopo

O Nagios é principalmente voltado para alertas baseados nos códigos de saída de scripts, chamados de “checks”. Há silenciamento de alertas individuais, mas não há agrupamento, roteamento ou deduplicação.

Existem diversos plugins, como por exemplo, encaminhar os poucos kilobytes de dados de desempenho que os plugins podem retornar para um banco de dados de séries temporais, como o Graphite, ou usar o NRPE para executar checks em máquinas remotas.

Modelo de dados

O Nagios é baseado em hosts. Cada host pode ter um ou mais serviços, e cada serviço pode realizar um check.

Não há noção de rótulos ou de uma linguagem de consulta.

Armazenamento

O Nagios não possui armazenamento próprio, além do estado atual do check. Existem plugins que podem armazenar dados para visualização.

Arquitetura

Os servidores Nagios são independentes. Toda a configuração dos checks é feita por meio de arquivos.

Resumo

O Nagios é adequado para monitoramento básico de sistemas pequenos e/ou estáticos, onde a sondagem “blackbox” (caixa preta) é suficiente.

Se você deseja fazer monitoramento “whitebox” (caixa branca) ou possui um ambiente dinâmico ou baseado em nuvem, então o Prometheus é uma boa escolha.


Prometheus vs. Sensu

Sensu é uma canalização de monitoramento e observabilidade de código aberto com uma distribuição comercial que oferece recursos adicionais para escalabilidade. Ele pode reutilizar plugins existentes do Nagios.

Escopo

O Sensu é uma canalização de observabilidade que se concentra no processamento e alerta de dados de observabilidade como uma sequência de Eventos. Ele fornece um framework extensível para filtragem, agregação, transformação e processamento de eventos – incluindo o envio de alertas para outros sistemas e armazenamento de eventos em sistemas de terceiros. As capacidades de processamento de eventos do Sensu têm escopo semelhante às regras de alerta do Prometheus e do Alertmanager.

Modelo de dados

Os Eventos do Sensu representam a saúde do serviço e/ou métricas em um formato de dados estruturados identificado por um nome de entidade (por exemplo, servidor, instância de computação em nuvem, contêiner ou serviço), um nome de evento e metadados opcionais de chave-valor chamados “rótulos” ou “anotações”. O payload do Evento Sensu pode incluir um ou mais points, métricos, representados como um objeto JSON contendo um name, tags (pares chave/valor), timestamp  e value  (sempre um float).

Armazenamento

O Sensu armazena informações de status de evento atuais e recentes e dados de inventário em tempo real em um banco de dados embutido (etcd) ou um SGBD externo (PostgreSQL).

Arquitetura

Todos os componentes de uma implantação do Sensu podem ser agrupados para alta disponibilidade e aumento da taxa de processamento de eventos.

Resumo

Sensu e Prometheus têm algumas capacidades em comum, mas abordam o monitoramento de maneiras muito diferentes. Ambos oferecem mecanismos de descoberta extensíveis para ambientes dinâmicos baseados em nuvem e plataformas de computação efêmera, embora os mecanismos subjacentes sejam bastante diferentes. Ambos oferecem suporte para coletar métricas multidimensionais por meio de rótulos e anotações. Ambos têm integrações extensas, e o Sensu suporta nativamente a coleta de métricas de todos os exportadores do Prometheus. Ambos são capazes de encaminhar dados de observabilidade para plataformas de dados de terceiros (por exemplo, armazenamento de eventos ou TSDBs). Onde Sensu e Prometheus diferem mais é em seus casos de uso.

Onde Sensu se destaca:

  • Se você está coletando e processando dados híbridos de observabilidade (incluindo métricas e/ou eventos).

  • Se você está consolidando várias ferramentas de monitoramento e precisa de suporte para métricas e plugins ou scripts de verificação no estilo Nagios.

  • Plataforma de processamento de eventos mais poderosa.

Onde Prometheus se destaca:

  • Se você está principalmente coletando e avaliando métricas.

  • Se você está monitorando a infraestrutura homogênea do Kubernetes (se 100% das cargas de trabalho que você está monitorando estão no K8s, o Prometheus oferece melhor integração com o K8s).

  • Linguagem de consulta mais poderosa e suporte integrado para análise de dados históricos.

O Sensu é mantido por uma única empresa comercial seguindo o modelo de negócios de núcleo aberto, oferecendo recursos premium como correlação e agregação de eventos de código fechado, federação e suporte. O Prometheus é um projeto totalmente de código aberto e independente, mantido por diversas empresas e indivíduos, alguns dos quais também oferecem serviços comerciais e suporte.


Fonte: https://prometheus.io/docs/introduction/comparison/

Experimente agora, grátis!