Sistemas de dados
    Atualizado maio de 2026
    InfluxDB logo

    InfluxDB Monitorização

    Monitorize o débito de gravação do InfluxDB, o desempenho das consultas, as métricas do motor de armazenamento e o estado das políticas de retenção em tempo real, sem necessidade de configuração.

    Iniciar período de avaliação gratuitaVer documentos

    Por que monitorizar InfluxDB?

    O InfluxDB é a principal base de dados de séries temporais para métricas, eventos e análises em tempo real. A monitorização do InfluxDB garante uma ingestão de dados em bom estado, um desempenho ideal das consultas e uma gestão adequada da retenção.

    Deteção automática via Xitogent
    Monitorização da taxa de escrita de pontos
    Acompanhamento do tempo de execução de consultas
    Métricas do motor de armazenamento (TSM)
    Saúde das políticas de retenção
    Monitorização da cardinalidade das séries
    Acompanhamento de compactações
    Intervalos de recolha de 1 minuto
    Limiares de alerta personalizáveis para cada métrica
    Intervalos de recolha de métricas de 1 minuto, prontos a usar
    O que é a monitorização do InfluxDB?

    Monitorização do InfluxDB, explicada

    A monitorização do InfluxDB deteta paragens no débito de escrita, cardinalidade descontrolada de séries (o clássico modo de falha do InfluxDB 1.x/2.x), atrasos na compactação TSM, lentidão de consultas e crescimento do WAL antes que causem perda de ingestão ou timeouts de consulta nos seus dashboards Grafana. Para pipelines de sensores IoT, backends de métricas de aplicações e qualquer implementação da stack TICK, a visibilidade por base de dados é o que separa um alerta em 60 segundos de um incidente de várias horas à procura de pontos de dados em falta. O Xitoring descobre automaticamente o seu InfluxDB, lê o endpoint Prometheus nativo /metrics, e encaminha alertas para Slack, PagerDuty, Telegram ou para a sua equipa de plantão existente.

    Métricas

    O que monitorizamos

    Pontos escritos/s

    Taxa de escrita de pontos de dados.

    Duração das consultas

    Tempo médio de execução das consultas.

    Cardinalidade das séries

    Total de séries temporais únicas.

    Tamanho do armazenamento

    Armazenamento TSM em disco.

    Taxa de compactação

    Throughput de compactação TSM.

    Tamanho da cache

    Utilização da cache de escrita em memória.

    WAL Disk Bytes

    `storage.tsm1.wal.currentSegmentDiskBytes` + `oldSegmentsDiskBytes`. O crescimento do WAL sem consolidação TSM significa que o tempo de recuperação irá disparar no arranque.

    Tamanho de armazenamento em disco

    `storage.tsm1.filestore.diskBytes` + numFiles por shard. Acompanhe em relação à sua política de retenção — contagens elevadas de ficheiros com o mesmo tamanho de dados indicam fragmentação.

    Taxa de HTTP 4xx / 5xx

    `httpd.clientError` + `httpd.serverError` (ou Prometheus `http_api_request_errors_total`). Picos de 4xx assinalam erros de esquema/autenticação do cliente; 5xx assinalam falhas do lado do servidor.

    Ligações / Falhas de autenticação

    `httpd.req` (total de pedidos HTTP), `httpd.authFail` (tentativas de autenticação falhadas), `httpd.pingReq`. Picos de falhas de autenticação sinalizam Telegraf mal configurado ou uma rotação de credenciais mal feita.

    Runtime — Goroutines e GC

    Estatísticas do runtime Go: `runtime.NumGoroutine` (deteção de fugas de goroutines), `runtime.HeapAlloc` (heap ativa), `runtime.NumGC`/`PauseTotalNs` (pressão de GC). Apanhe fugas e regressões no tempo de pausa antes de OOM.

    Escritas de subscrições

    `subscriber.pointsWritten` e `subscriber.writeFailures` — quando o Kapacitor ou pipelines a jusante consomem via subscrições, é assim que apanha a contrapressão.

    Alerta e notificação

    Configurável condições de alerta

    Configure alertas personalizados no seu painel para ser notificado assim que as métricas dInfluxDB ultrapassarem os limites que definiu.

    InfluxDB painel de controlo da configuração dos gatilhos de monitorização

    Throughput de escrita

    aviso

    Dispara em anomalias da taxa de escrita.

    Duração das consultas

    aviso

    Alerta sobre consultas lentas.

    Cardinalidade das séries

    crítico

    Dispara quando a cardinalidade é demasiado elevada.

    Tamanho do armazenamento

    crítico

    Dispara quando o armazenamento excede o limite.

    01

    Importância da monitorização do InfluxDB

    O InfluxDB lida com dados de séries temporais de alta velocidade. Cardinalidade elevada, pressão de escrita e atrasos de compactação podem degradar o desempenho.

    • Acompanhe o throughput de escrita para a saúde da ingestão
    • Monitorize a cardinalidade das séries para prevenir OOM
    • Detete cedo as consultas lentas
    • Garanta que a compactação acompanha o ritmo
    Monitorização do InfluxDB
    Analítica de séries temporais
    02

    Porquê escolher Xitoring

    Monitorização InfluxDB sem configuração.

    • Instalação num único comando
    • Nós globais
    • Dashboard unificado
    • Alertas multicanal
    • Retenção histórica
    Visão geral
    Alertas
    Casos de uso

    Cenários comuns de monitorização do InfluxDB

    Onde o InfluxDB normalmente é executado hoje — e o que pode correr mal se ninguém estiver a monitorizar.

    A base de dados por trás dos dashboards da sua equipa

    Quando os dashboards no Grafana ou noutra ferramenta parecem lentos, a causa é frequentemente a base de dados subjacente — e não o próprio dashboard. Mostramos onde a lentidão realmente reside para que a equipa corrija a coisa certa em vez de perseguir o sintoma.

    Dados a fluir de sensores e dispositivos

    Dispositivos conectados, equipamentos de fábrica e sensores IoT enviam medições a cada segundo de cada dia. Um backup silencioso no pipeline significa perda de dados — e dados perdidos desaparecem para sempre. Monitorizamos o fluxo de ponta a ponta para que uma única leitura perdida levante o alarme.

    Métricas de aplicação e infraestrutura num só lugar

    Quando a mesma base de dados contém métricas de aplicação e métricas de servidor, um problema com a base de dados oculta todos os sinais de uma só vez. Monitorizamos a própria base de dados para que o próprio monitoramento da equipa nunca fique às escuras durante um incidente.

    Antes de começar

    Pré-requisitos para InfluxDB

    Certifique-se de que tem tudo isto pronto — depois disso, a maioria das instalações leva 60 segundos.

    • InfluxDB 1.x ou 2.x em execução no servidor
    • Porta HTTP do InfluxDB acessível a partir do Xitogent (predefinida 8086)
    • Opcional: um token só de leitura se a autenticação do InfluxDB 2.x estiver ativada
    Guia de configuração

    Comece a minutos

    1

    Instalar o Xitogent no seu host InfluxDB

    Instale o leve agente de monitorização Xitogent no host que executa o InfluxDB.

    curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEY
    2

    Confirmar que o InfluxDB é acessível

    Verifique se o InfluxDB está a escutar na sua porta HTTP (predefinida 8086) e é acessível a partir do host que executa o Xitogent. O Xitogent vai pedir o host e a porta durante o integrate — não são necessárias edições de configuração ou exposição de endpoints adicionais.

    sudo xitogent integrate
    3

    Ativar a integração do InfluxDB

    Use o painel do Xitoring ou a CLI para ativar a integração do InfluxDB. O Xitogent deteta automaticamente a sua versão de InfluxDB e começa a recolher métricas de escrita, query e armazenamento.

    4

    Configurar limiares de alerta (opcional)

    Defina limiares personalizados para throughput de escrita, duração de queries ou cardinalidade de séries para apanhar pressão de ingestão e crescimento descontrolado de tags antes que as queries fiquem lentas.

    5

    Confirme que está a funcionar

    Execute este comando no servidor para confirmar que o Xitogent detetou a integração. Em cerca de 30 segundos começam a chegar novas métricas ao seu painel.

    sudo xitogent status
    Comparar

    Está a considerar alternativas?

    Veja como o Xitoring se compara às alternativas para a monitorização de InfluxDB — preços fixos, integrações mais profundas e um único agente que cobre toda a sua stack.

    Ver todas as comparações

    Frequentemente perguntas feitas

    InfluxDB 1.x e 2.x?
    Ambas as versões são compatíveis.
    Impacto?
    Insignificante — lê a partir do ponto final /debug/vars.
    Como deteto problemas de cardinalidade no InfluxDB?
    A cardinalidade de séries é O modo de falha do InfluxDB 1.x/2.x — demasiadas combinações únicas de tags causam OOM e consultas lentas. Execute `SHOW SERIES CARDINALITY` (InfluxQL) ou `import "influxdata/influxdb/v1" v1.cardinality(...)` (Flux), ou leia `database.numSeries` a partir de `_internal`. Configure um alerta para qualquer salto de 50%+ em relação à baseline — é quase sempre uma explosão de valores de tag por um campo de alta cardinalidade não intencional (IDs de pedido, timestamps como tags, IDs de utilizador).
    O que é a base de dados _internal no InfluxDB?
    `_internal` é a base de dados especial onde o InfluxDB 1.x escreve as suas próprias métricas — mesmo armazenamento TSM dos dados de utilizador, consultável via `USE _internal` + `SHOW MEASUREMENTS`. Contém medições como `write`, `queryExecutor`, `tsm1_engine`, `tsm1_cache`, `tsm1_wal`, `httpd`, `runtime`, `database`, `shard`. No InfluxDB 2.x, isto passou para o bucket `_monitoring` (configurado pelo template Monitoring). Na 3.0, o endpoint Prometheus `/metrics` é a superfície canónica.
    Como monitorizo as compactações do InfluxDB?
    As compactações TSM fundem pequenos ficheiros de WAL/cache em ficheiros maiores e otimizados em três níveis (L1/L2/L3) mais compactações totais. Vigie `storage.tsm1.compactions.cacheCompactionDuration`, `tsmLevel{1,2,3}CompactionQueue` (profundidade da fila — diferente de zero significa backlog) e `tsmLevel{1,2,3}CompactionDuration`. Uma fila a crescer com taxa de escrita normal = compactor a ficar para trás = degradação iminente das consultas. Aumente a escala ou reduza a taxa de escrita.
    Qual a diferença entre a monitorização do InfluxDB 1.x, 2.x e 3.0?
    A 1.x usa InfluxQL + stack TICK, expõe `/debug/vars` e a base de dados `_internal`, e corre o motor de armazenamento TSM/TSI. A 2.x usa Flux + tasks, expõe `/metrics` (Prometheus) e o bucket `_monitoring`, com o mesmo TSM/TSI por baixo. A 3.0 é a nova arquitetura FDAP — motor de consultas DataFusion, armazenamento Parquet em object stores, removeu totalmente o limite de cardinalidade e suporta SQL a par com InfluxQL (o Flux está em modo de manutenção). O Xitogent deteta automaticamente a versão e adapta-se.
    Como deteto lentidão de consultas no InfluxDB?
    Acompanhe `queryExecutor.queryDurationNs` (tempo médio de consulta) e `queriesActive` (consultas em execução concorrentes). Picos durante refreshes de dashboards são esperados; crescimento sustentado significa que as consultas estão a ficar mais lentas (muitas vezes devido a cardinalidade ou a backlog de compactação). Ative o registo de consultas lentas (`log-queries-after = '5s'` em `influxdb.conf` para 1.x) para captar infratores específicos para investigação.
    Como monitorizo o armazenamento TSM do InfluxDB?
    O TSM (Time-Structured Merge tree) é o motor de armazenamento em disco para 1.x/2.x. Monitorize `storage.tsm1.filestore.diskBytes` (tamanho total em disco) e `numFiles` (contagem de ficheiros — números elevados com os mesmos bytes = fragmentação). Combine com `storage.tsm1.cache.cachedBytes` (buffer de escrita em memória) e o tamanho do WAL. Crescimento sustentado do WAL sem consolidação TSM = problema no compactor; numFiles a inchar = retenção/compactação não acompanha as escritas.
    Esta integração afetará o desempenho do InfluxDB?
    Sem impacto mensurável. O Xitogent lê do endpoint Prometheus nativo `/metrics` (ou das views de consulta `_internal` / `_monitoring`) num intervalo de 1 minuto — o mesmo mecanismo leve que as próprias ferramentas da InfluxData usam. Sem instrumentação injetada no percurso de escrita ou no motor de consultas.

    Comece a monitorizar InfluxDB hoje

    Configure em menos de 60 segundos. Não é necessário cartão de crédito. Estatísticas completas desde o primeiro dia.

    Iniciar período de avaliação gratuita

    Continue a explorar

    Relacionado Integrações