Monitoramento do Ollama em produção: logs e alertas com Prometheus

Três e dezessete da manhã. Um alerta vermelho no Slack: Ollama API timeout - service unavailable. O sistema de atendimento estava em produção havia duas semanas e fazia algumas centenas de chamadas por dia. Na implantação, eu tinha configurado apenas o registro básico de logs, sem monitoramento nem alertas. A memória da GPU se esgotou? O processo caiu? Foi um problema de rede? Eu não tinha nenhuma pista. Só consegui restaurar o serviço às seis da manhã.

A falta de monitoramento é uma das principais causas.

Neste artigo, compartilho uma solução completa, desde a configuração de logs até o monitoramento com Prometheus + Grafana e os alertas do AlertManager. Todos os arquivos de configuração podem ser copiados e usados diretamente. Com este roteiro, você consegue montar uma estrutura de monitoramento para produção em cerca de 30 minutos.

Principais desafios do monitoramento em produção

O Ollama é diferente de um serviço web comum. Ele consome muitos recursos. Cada modelo carregado ocupa de 4 a 16 GB somente de memória, segundo testes da Markaicode. Além disso, a inicialização a frio — o carregamento do modelo do disco para a memória — leva de 10 a 30 segundos. Isso significa que, se o serviço cair e reiniciar, o usuário pode esperar meio minuto por uma resposta.

Os principais problemas que enfrentei foram estes:

Vazamentos de memória e esgotamento da GPU. Depois de ficar muito tempo em execução, às vezes o Ollama parece “esquecer” de liberar a VRAM. Já vi uma máquina com 24 GB de VRAM ficar com apenas 2 GB disponíveis após dois dias, e todas as novas requisições passaram a ser recusadas. O problema é que eu não sabia o que estava acontecendo até os usuários reclamarem.

Acúmulo na fila de requisições. A inferência é lenta por natureza, e uma requisição pode levar de 5 a 20 segundos. Se dezenas chegarem ao mesmo tempo, a fila cresce até provocar timeouts. Mas como saber se a fila está se acumulando? Sem métricas, só dá para adivinhar.

Atraso no carregamento de modelos. Ao alternar entre vários modelos, o tempo de carregamento é uma caixa-preta. O usuário não sabe por que a resposta está lenta, e você também não.

Por isso, os objetivos do monitoramento ficam claros: disponibilidade do serviço — o processo ainda está em execução? —, desempenho — quanto tempo a resposta leva? —, uso de recursos — quanta memória da GPU ainda está disponível? — e taxa de erros — quantas requisições falharam? Quando você entende essas quatro dimensões, consegue operar o serviço com segurança.

Testei algumas combinações de ferramentas. Para uma equipe pequena, Prometheus + Grafana é suficiente. Se você precisa rastrear prompts e respostas de LLM, o Langfuse funciona muito bem. Em ambientes corporativos, vale considerar o SigNoz, baseado em OpenTelemetry, que unifica logs, métricas e traces. A seguir, vou me concentrar no Prometheus, por ser a base mais versátil.

Configuração de logs e otimização do serviço systemd

Colocar o Ollama para rodar é fácil, mas, para mantê-lo estável, a primeira tarefa é acertar os logs. Eu já aprendi isso da pior forma: quando surgiu um problema, descobri que nada tinha sido registrado ou que dezenas de gigabytes de logs haviam lotado o disco.

Configuração do serviço systemd

Se você instalou o Ollama diretamente pelo script oficial, ele já criou um serviço systemd. A configuração padrão, porém, é simples demais para produção e precisa de alguns ajustes:

# /etc/systemd/system/ollama.service

[Unit]
Description=Ollama Service
After=network.target

[Service]
Type=simple
User=ollama
Group=ollama

# Diretório de trabalho
WorkingDirectory=/usr/share/ollama

# Variáveis de ambiente
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_MODELS=/data/ollama/models"
Environment="OLLAMA_DEBUG=1"
Environment="OLLAMA_LOG_FORMAT=json"

# Limites de recursos (ajuste ao seu hardware)
LimitNOFILE=65535
LimitNPROC=4096
MemoryMax=32G

# Estratégia de reinicialização automática
Restart=always
RestartSec=10

# Comando de inicialização
ExecStart=/usr/local/bin/ollama serve

# Saída padrão e saída de erros
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Alguns pontos importantes com base na minha experiência:

Restart=always e RestartSec=10: reiniciam automaticamente o processo após uma saída inesperada. A espera de dez segundos dá um tempo para o sistema se recuperar. Certa vez, o esgotamento da memória provocou falhas repetidas; sem esse intervalo, o processo reiniciava sem parar e gerava uma avalanche de logs.

Vultr - Servidor cloud NVMe de alto desempenho, 32 locais globais, deploy Docker com um clique

Ver preços →Anúncio

MemoryMax=32G: limita a memória máxima disponível para o Ollama. Isso é muito importante se a máquina também executa outros serviços. Quando testei sem esse limite, o Ollama consumiu os 64 GB de RAM e nem sequer consegui acessar o servidor por SSH.

OLLAMA_DEBUG=1 e OLLAMA_LOG_FORMAT=json: em produção, recomendo ativar o modo debug para facilitar a investigação de problemas. O formato JSON permite analisar os logs com outras ferramentas.

Depois de alterar a configuração, não se esqueça de recarregá-la:

sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo systemctl enable ollama  # Iniciar automaticamente com o sistema

Configuração de logs em uma implantação com Docker

Com o Docker, é ainda mais fácil deixar o gerenciamento de logs sair do controle. Por padrão, os logs ficam em /var/lib/docker/containers/ e crescem indefinidamente se você não definir limites.

Minha configuração do docker-compose é assim:

# docker-compose.yml
version: '3.8'

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: always
    ports:
      - "11434:11434"
    volumes:
      - ./ollama_data:/root/.ollama
    environment:
      - OLLAMA_HOST=0.0.0.0:11434
      - OLLAMA_DEBUG=1
    deploy:
      resources:
        limits:
          memory: 32G
    logging:
      driver: "json-file"
      options:
        max-size: "100m"
        max-file: "5"

max-size: "100m" limita cada arquivo de log a 100 MB, enquanto max-file: "5" mantém cinco arquivos. No total, os logs ocupam no máximo 500 MB: espaço suficiente sem risco de lotar o disco.

Níveis de log

O Ollama aceita estas variáveis de ambiente:

Eu costumo manter DEBUG ativado. O espaço adicional é pequeno, e os detalhes economizam muito tempo durante uma investigação.

Uso prático do journalctl

Depois de configurar o serviço, consulte os logs com journalctl:

# Acompanhar logs em tempo real
sudo journalctl -u ollama -f

# Exibir as 100 linhas mais recentes
sudo journalctl -u ollama -n 100

# Exibir os logs de hoje
sudo journalctl -u ollama --since today

# Procurar uma palavra-chave específica
sudo journalctl -u ollama | grep -i "error"

# Exportar os logs para um arquivo
sudo journalctl -u ollama --since "2026-04-12 00:00:00" > ollama-debug.log

Uma dica: se você ativou logs em JSON, pode analisá-los com jq:

sudo journalctl -u ollama -o json | jq 'select(.level=="error")'

Assim, você vê apenas os logs de erro e não precisa procurá-los no meio de muitas entradas INFO.

Monitoramento com Prometheus + Grafana

Os logs servem para investigar o que já aconteceu; o monitoramento é o que avisa antes que o problema fique grave. Uso Prometheus + Grafana há mais de dois anos. A configuração dá algum trabalho, mas a combinação é estável, confiável e conta com muitos recursos da comunidade.

Implantação do ollama-exporter

O Ollama não expõe métricas do Prometheus diretamente, então precisamos de um exporter para coletá-las. Eu uso o frcooper/ollama-exporter. Embora o projeto tenha poucas estrelas — 36 —, oferece os recursos necessários.

Há duas formas de implantá-lo: executar o binário diretamente ou usar Docker. Recomendo o Docker:

# Adicione o serviço exporter ao docker-compose.yml
services:
  ollama-exporter:
    image: frazco/ollama-exporter:latest
    container_name: ollama-exporter
    restart: always
    ports:
      - "9101:9101"
    environment:
      - OLLAMA_HOST=ollama:11434  # Aponta para o contêiner do Ollama
    depends_on:
      - ollama

Em seguida, configure o Prometheus:

# prometheus.yml
global:
  scrape_interval: 30s  # Intervalo de coleta; a Markaicode recomenda 30 segundos
  evaluation_interval: 30s

scrape_configs:
  - job_name: 'ollama-exporter'
    static_configs:
      - targets: ['ollama-exporter:9101']
        labels:
          instance: 'ollama-prod'

  # Monitoramento de GPU (para NVIDIA)
  - job_name: 'nvidia-gpu'
    static_configs:
      - targets: ['localhost:9835']

Adicione também o Prometheus ao docker-compose:

services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    restart: always
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'

volumes:
  prometheus_data:

Principais métricas de monitoramento

O ollama-exporter coleta as métricas abaixo. Estas são as mais importantes:

Também há métricas do sistema, que exigem o node-exporter:

• Uso da CPU: node_cpu_seconds_total
• Uso de memória: node_memory_MemAvailable_bytes
• Tráfego de rede: node_network_receive_bytes_total

Configuração do monitoramento de GPU

A GPU é o coração de um serviço de LLM, por isso seu monitoramento precisa estar bem configurado. Eu uso o nvidia_gpu_prometheus_exporter:

# Instalar o exporter de GPU NVIDIA
docker run -d \
  --name nvidia-exporter \
  --restart always \
  -p 9835:9835 \
  --gpus all \
  nvidia/gpu-prometheus-exporter:latest

Ele expõe estas métricas importantes:

• nvidia_gpu_utilization: uso da GPU
• nvidia_gpu_memory_used_bytes: memória de vídeo usada
• nvidia_gpu_memory_free_bytes: memória de vídeo disponível
• nvidia_gpu_temperature: temperatura da GPU

Em um ambiente com várias placas, as métricas incluem o rótulo gpu_id, permitindo exibir cada GPU separadamente no Grafana.

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

Configuração do dashboard no Grafana

A seguir está um JSON de dashboard do Grafana pronto para importar. Salve-o em um arquivo e clique em Import Dashboard no Grafana:

{
  "dashboard": {
    "title": "Ollama Production Monitor",
    "panels": [
      {
        "title": "Request Rate",
        "type": "graph",
        "targets": [
          {
            "expr": "rate(ollama_requests_total[5m])",
            "legendFormat": "Requests/sec"
          }
        ],
        "gridPos": {"x": 0, "y": 0, "w": 12, "h": 6}
      },
      {
        "title": "Error Rate",
        "type": "gauge",
        "targets": [
          {
            "expr": "rate(ollama_requests_failed[5m]) / rate(ollama_requests_total[5m]) * 100",
            "legendFormat": "Error %"
          }
        ],
        "gridPos": {"x": 12, "y": 0, "w": 6, "h": 6}
      },
      {
        "title": "GPU Memory Usage",
        "type": "graph",
        "targets": [
          {
            "expr": "nvidia_gpu_memory_used_bytes / nvidia_gpu_memory_total_bytes * 100",
            "legendFormat": "GPU {{gpu_id}}"
          }
        ],
        "gridPos": {"x": 0, "y": 6, "w": 12, "h": 6}
      },
      {
        "title": "Response Latency P95",
        "type": "stat",
        "targets": [
          {
            "expr": "histogram_quantile(0.95, rate(ollama_request_duration_seconds_bucket[5m]))",
            "legendFormat": "P95 Latency"
          }
        ],
        "gridPos": {"x": 12, "y": 6, "w": 6, "h": 6}
      }
    ]
  },
  "overwrite": true
}

Na prática, o resultado fica mais ou menos assim:

• Canto superior esquerdo: curva da taxa de requisições, que mostra os horários de pico
• Canto superior direito: indicador da taxa de erros, que fica vermelho acima de 5%
• Canto inferior esquerdo: curvas de uso de memória para várias GPUs
• Canto inferior direito: valor da latência P95

Também costumo acrescentar um painel de Tokens/s para comparar a velocidade de inferência entre os modelos.

Configuração da fonte de dados do Grafana

Depois de iniciar o contêiner do Grafana, configure manualmente a fonte de dados Prometheus:

1. Entre no Grafana (o padrão é admin/admin)
2. Acesse Configuration -> Data Sources -> Add data source
3. Selecione Prometheus e informe http://prometheus:9090 no campo URL
4. Clique em Save & Test

Se todos os serviços estiverem no mesmo docker-compose, eles compartilham a rede e você pode usar diretamente o nome do contêiner.

Regras de alerta e configuração do AlertManager

O monitoramento permite enxergar os problemas, mas são os alertas que avisam quando algo exige ação imediata. Eu já cometi o erro de classificar todos os alertas como critical. O celular vibrava dezenas de vezes por dia, até que parei de prestar atenção e quase ignorei um problema real.

Estratégia de níveis de alerta

Divido os alertas em três níveis. Essa lógica foi refinada depois de alguns incidentes:

O princípio fundamental é: os alertas Critical devem ser poucos e causar uma reação imediata.

Regras de alerta do Prometheus

Adicione o arquivo de regras ao prometheus.yml:

rule_files:
  - 'ollama_alerts.yml'

Depois, crie um arquivo separado chamado ollama_alerts.yml:

# ollama_alerts.yml
groups:
  - name: ollama_critical
    rules:
      # Alerta de serviço fora do ar
      - alert: OllamaServiceDown
        expr: up{job="ollama-exporter"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Serviço Ollama fora do ar"
          description: "O exporter do Ollama não responde; o serviço pode ter parado"

      # Alerta de memória da GPU (>95%)
      - alert: GPUMemoryCritical
        expr: nvidia_gpu_memory_used_bytes / nvidia_gpu_memory_total_bytes > 0.95
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Memória da GPU quase esgotada"
          description: "O uso de memória da GPU {{ gpu_id }} passou de 95%; valor atual: {{ $value | humanizePercentage }}"

      # Alerta de alta taxa de erros
      - alert: HighErrorRate
        expr: rate(ollama_requests_failed[5m]) / rate(ollama_requests_total[5m]) > 0.20
        for: 3m
        labels:
          severity: critical
        annotations:
          summary: "Taxa de erros das requisições muito alta"
          description: "A taxa de erros dos últimos cinco minutos passou de 20%; verifique os logs"

  - name: ollama_warning
    rules:
      # Alerta de tempo de resposta
      - alert: SlowResponseTime
        expr: histogram_quantile(0.95, rate(ollama_request_duration_seconds_bucket[5m])) > 60
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Tempo de resposta P95 muito alto"
          description: "95% das requisições estão levando mais de 60 segundos"

      # Aviso de memória da GPU
      - alert: GPUMemoryWarning
        expr: nvidia_gpu_memory_used_bytes / nvidia_gpu_memory_total_bytes > 0.80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Uso elevado da memória da GPU"
          description: "O uso de memória da GPU {{ gpu_id }} passou de 80%"

      # Aviso de taxa de erros
      - alert: ErrorRateWarning
        expr: rate(ollama_requests_failed[5m]) / rate(ollama_requests_total[5m]) > 0.05
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Aumento na taxa de erros das requisições"
          description: "A taxa de erros dos últimos cinco minutos passou de 5%"

Alguns pontos importantes:

• for: Xm: exige que a condição persista por X minutos antes de disparar o alerta, evitando falsos positivos causados por oscilações momentâneas
• Limite de 95% para a GPU: nos meus testes, os problemas começam quase imediatamente depois desse ponto
• A taxa de erros usa rate(): o número absoluto não diz muita coisa; o importante é observar a tendência

Configuração do AlertManager

O AlertManager é responsável por enviar os alertas. Use o arquivo alertmanager.yml:

global:
  resolve_timeout: 5m

# Configuração de roteamento
route:
  group_by: ['severity', 'alertname']
  group_wait: 30s      # Aguarda 30 segundos para reunir alertas do mesmo grupo
  group_interval: 5m   # Intervalo entre alertas do mesmo grupo
  repeat_interval: 3h  # Intervalo para repetir alertas ainda não resolvidos
  routes:
    - match:
        severity: critical
      receiver: 'critical-alerts'
      continue: false
    - match:
        severity: warning
      receiver: 'warning-alerts'
      continue: false
    - match:
        severity: info
      receiver: 'info-alerts'

# Configuração dos destinatários
receivers:
  - name: 'critical-alerts'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK'
        channel: '#ollama-critical'
        send_resolved: true
        title: '{{ .Status | toUpper }}: {{ .CommonAnnotations.summary }}'
        text: '{{ .CommonAnnotations.description }}'

  - name: 'warning-alerts'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK'
        channel: '#ollama-monitor'
        send_resolved: true

  - name: 'info-alerts'
    email_configs:
      - to: '[email protected]'
        send_resolved: true

Como configurar o Webhook do Slack

1. Crie um App no Slack ou use Incoming Webhooks
2. Adicione a URL do Webhook ao campo api_url
3. Recomendo separar os canais: use um canal exclusivo para alertas critical e um canal comum para warning

Também acrescento notificações no celular. Se você usa PagerDuty ou OpsGenie, o AlertManager oferece integração com ambos. Para uma alternativa gratuita, é possível usar um bot do Telegram, cuja configuração também é simples.

Regras de silenciamento e inibição

Às vezes é necessário silenciar alertas temporariamente, por exemplo durante uma manutenção. Isso pode ser feito diretamente na interface do AlertManager:

# Acessar a interface do AlertManager
http://your-server:9093

# Clicar em Silences -> New Silence
# Definir a duração e os rótulos correspondentes

Também é possível usar a API:

curl -X POST http://localhost:9093/api/v1/silences \
  -d '{
    "matchers": [{"name": "alertname", "value": "OllamaServiceDown", "isRegex": false}],
    "startsAt": "2026-04-12T10:00:00Z",
    "endsAt": "2026-04-12T12:00:00Z",
    "createdBy": "admin",
    "comment": "Scheduled maintenance"
  }'

Ferramentas avançadas de monitoramento para LLMs

Prometheus + Grafana é uma solução de uso geral, mas as LLMs têm necessidades específicas: rastreamento de prompts, custos de tokens e avaliação da qualidade das respostas. Essas métricas não são fáceis de obter com ferramentas tradicionais de monitoramento.

Langfuse: rastreamento de LLM e gerenciamento de prompts

O Langfuse é uma plataforma de monitoramento criada especificamente para aplicações com LLM. Tem licença MIT, é open source e pode ser hospedada na sua própria infraestrutura. Entre os recursos estão:

• Rastreamento de cada conversa: registra o prompt de entrada, a saída, a quantidade de tokens e a duração
• Gerenciamento de versões de prompts: permite comparar o resultado antes e depois de uma alteração no prompt
• Avaliação de qualidade: registra feedback dos usuários e avaliações manuais para acompanhar a qualidade das respostas do modelo

A integração é simples, e o Langfuse oferece suporte oficial ao Ollama:

# Exemplo de integração em Python
from langfuse import Langfuse
import requests

langfuse = Langfuse(
    public_key="pk-xxx",
    secret_key="sk-xxx",
    host="https://cloud.langfuse.com"  # Ou o endereço da sua instância
)

# Registrar cada chamada
trace = langfuse.trace(
    name="ollama-chat",
    input={"prompt": user_prompt},
    metadata={"model": "llama3.1"}
)

response = requests.post(
    "http://localhost:11434/api/generate",
    json={"model": "llama3.1", "prompt": user_prompt}
)

trace.update(
    output=response.json()["response"],
    metadata={"tokens": response.json().get("eval_count", 0)}
)

Você pode implantar uma versão auto-hospedada do Langfuse com Docker:

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

services:
  langfuse-server:
    image: langfuse/langfuse:latest
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgres://user:pass@db:5432/langfuse
      - NEXTAUTH_SECRET=your-secret

Se você usa LangChain, a integração é ainda mais fácil, pois o Langfuse oferece um callback handler oficial.

SigNoz: monitoramento unificado com OpenTelemetry

O SigNoz é uma plataforma de observabilidade baseada em OpenTelemetry que reúne logs, métricas e traces em um único lugar. A vantagem é não precisar manter separadamente três sistemas, como Prometheus, Jaeger e ELK.

Para aplicações com LLM, o rastreamento do SigNoz é especialmente útil: ele mostra o caminho completo de uma requisição, desde a entrada na API, passando pela inferência do modelo, até a consulta ao banco de dados.

A implantação do SigNoz exige mais recursos; recomendo pelo menos 4 GB de memória. O projeto oferece uma instalação pronta com Docker Compose:

git clone https://github.com/SigNoz/signoz.git
cd signoz/deploy/docker
docker compose up -d

Recomendações para escolher as ferramentas

Estas são minhas sugestões para diferentes cenários:

Hoje eu uso Prometheus + Grafana + Langfuse. O Prometheus cuida das métricas de infraestrutura, enquanto o Langfuse monitora a camada da aplicação com LLM. Essa separação de responsabilidades deixa tudo mais claro.

Considerações finais

Depois de tudo isso, a principal mensagem é simples: não espere um incidente para pensar em monitoramento.

Aquela madrugada às três me levou a montar esta solução completa. Meu serviço Ollama já está em execução há mais de um ano. Nesse período, recebi alguns alertas de memória da GPU, mas consegui agir ainda no nível Warning e nunca mais fui acordado no meio da noite.

O custo para montar esta solução não é alto. Organizei todos os arquivos de configuração para que você possa baixá-los e usá-los diretamente:

• Configuração do serviço systemd
• Implantação completa com Docker Compose (Ollama + Exporter + Prometheus + Grafana)
• Regras de alerta do Prometheus
• Modelo de configuração do AlertManager
• JSON do dashboard do Grafana

O repositório complementar no GitHub está no fim do artigo. Quem já conhece essas ferramentas consegue colocar tudo em funcionamento em 20 minutos; para iniciantes, cerca de meia hora.

Como próximos passos, recomendo:

1. Comece com Prometheus + Grafana e coloque as métricas básicas para funcionar
2. Observe os dados por três a cinco dias e conheça os intervalos normais
3. Ajuste os limites de alerta de acordo com a sua realidade
4. Se precisar rastrear prompts, acrescente o Langfuse

O monitoramento exige um investimento inicial, mas traz benefícios contínuos. Espero que você não precise aprender essa lição com um incidente às três da manhã, como aconteceu comigo.

Repositório dos arquivos de configuração: github.com/yourname/ollama-monitoring-config (link de exemplo; substitua pelo endereço real na implantação)

Artigos da série:

• Guia completo para implantação local do Ollama — primeiro artigo da série
• Otimização de desempenho do Ollama na prática — prévia do próximo artigo