Prometheus : Definição de Storage

Posted on by fabio.reis

Este post é continuação do nosso primeiro post de como instalar o Prometheus .

Observando a imagem abaixo , no último post falamos sobre exporter e o servidor do Prometheus, neste post será apresentadoo as definições de storage.

Por padrão, o Prometheus armazena dados no armazenamento local por 15 dias. Este padrão é definido pelo pela opção –storage.tsdb.retention.time. As soluções de storage geralmente são otimizadas para períodos de retenção muito mais longos.

Conforme documentação do Prometheus :

Se o armazenamento local for corrompido por qualquer motivo, sua melhor opção é desligar o Prometheus e remover todo o diretório de armazenamento. Sistemas de arquivos não compatíveis com POSIX não são suportados pelo armazenamento local da Prometheus, podendo ocorrer danos, sem possibilidade de recuperação. O NFS é apenas potencialmente POSIX, a maioria das implementações não é. Você pode tentar remover diretórios de bloco individuais para resolver o problema, o que significa perder uma janela de tempo com cerca de duas horas de dados por diretório de blocos. Mais uma vez, o armazenamento local da Prometheus não significa que a ferramenta é um long-term storage.

Pelo fato do Prometheus não ter um armazenamento a longo , podemos utilizar integrações para conseguir sair dessas limitações.

1) Integração

O Prometheus trabalha com duas formas quando integrado com alguma solução remota :

  • Prometheus pode gravar amostras que são armazenadas em um URL remoto em um formato padronizado.
  • O Prometheus pode ler (voltar) amostras de dados de um URL remoto em um formato padronizado.

Neste post vamos utilizar o InfluxDb como ferramenta de integração com o Prometheus , porém na documentação do Prometheus existe uma lista com diversas opções de integração.

2) Ambiente de Lab

Vamos utilizar o mesmo ambiente de Lab anterior :

  • Centos7 , 2Gbs Ram e 1 vcpu
  • Server1 -> Prometheus server
  • Server2 e Server3 -> Node Exporter
  • Server2 -> InfluxDb.

Vagrantfile para provisionar o ambiente com o VirtualBox: 

# -*- mode: ruby -*-
# vi: set ft=ruby :

network = '192.168.0'	

nodes = [
{ :hostname => 'server1', :ip => "#{network}.101", :ram => 2048 },
{ :hostname => 'server2', :ip => "#{network}.102", :ram => 2048 },
{ :hostname => 'server3', :ip => "#{network}.103", :ram => 2048 }]

Vagrant.configure("2") do |config|
	nodes.each do |node|
		config.vm.define node[:hostname] do |nodeconfig|
			nodeconfig.vm.box = "centos/7"
                        nodeconfig.vm.box_version = "1803.01"
			nodeconfig.vm.hostname = node[:hostname]
			nodeconfig.vm.network :private_network, ip: node[:ip]
			memory = node[:ram] ? node[:ram] : 512;
			cpu = node[:cpu] ? node[:cpu] : 1;
			nodeconfig.vm.network "forwarded_port", guest: 9090, host: 9090 if node[:hostname] == "server1"
			nodeconfig.vm.network "forwarded_port", guest: 3000, host: 3000 if node[:hostname] == "server1"                 


		nodeconfig.vm.provider :virtualbox do |vb|
		vb.customize [ "modifyvm", :id, "--memory", memory.to_s,]
		end
	end
end
end

Após criar o Vagrantfile execute o comando abaixo para subir o ambiente no Virtualbox 

# vagrant up

Durante o processo de instalação foi desabilitado o firewalld e colocado como permissive o SELINUX de todas os servidores .

[root@guest ~]# vagrant ssh serverX
[vagrant@serverX ~]# sudo su - 
[root@serverX ~]# systemctl stop firewalld
[root@serverX ~]# systemctl disable firewalld
[root@serverX ~]# sed -i 's/SELINUX=enforcing/SELINUX=permissive/g' /etc/selinux/config
[root@serverX ~]# setenforce 0

Arquivo de hosts em todos os servidores . 

192.168.0.101 server1
192.168.0.102 server2
192.168.0.103 server3

O deploy do último post se encontra dísponível em ansible .

Após provisionar as vms habilite a autenticação por ssh e restart o daemon do ssh em todos os 3 servers. 

[root@serverX ~]#  sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/g' /etc/ssh/sshd_config 
[root@serverX ~]#  systemctl restart sshd

Instale o ansible no server1 

[root@server1 ~]# yum install ansible -y

Clone o git e execute os playbooks digitando a senha para o usuário e sudo conforme apresentado abaixo. 

[root@server1 Ansible]# ansible-playbook -i hosts -Kk promexporter.yml 
SSH password: 
SUDO password[defaults to SSH password]: 


[root@server1 Ansible]# ansible-playbook -i hosts -Kk promserver.yml 
SSH password: 
SUDO password[defaults to SSH password]:

3) Integração com o InfluxDB

No server2 vamos instalar o InfluxDB para observarmos o funcionamento da integração .

Adicione o repo /etc/yum.repos.d/influxdb.repo

[influxdb]
name = InfluxDB Repository - RHEL \$releasever
baseurl = https://repos.influxdata.com/rhel/\$releasever/\$basearch/stable
enabled = 1
gpgcheck = 1
gpgkey = https://repos.influxdata.com/influxdb.key

Instale o InfluxDb 

sudo yum install influxdb 
sudo systemctl start influxdb
sudo systemctl enable influxdb

Vamos criar a base do Prometheus 

[root@server2 ~]# influx 
Connected to http://localhost:8086 version 1.7.7
InfluxDB shell version: 1.7.7

> CREATE DATABASE "prometheus"

> show databases 
name: databases
name
----
_internal
prometheus
>

Conforme apresentado acima foi criado a base do prometheus e listada dentro do InfluxDb .

Seguindo a integração no Prometheus vamos ajustar os parâmetros abaixo no /etc/prometheus/prometheus.yml no server1. 

remote_write:
  - url: "http://server2:8086/api/v1/prom/write?db=prometheus"

remote_read:
  - url: "http://server2:8086/api/v1/prom/read?db=prometheus"

Restart o serviço do Prometheus 

systemctl restart prometheus

No server2 vamos logar no InfluxDB e executar o comando abaixo para ver valores temos para consultarmos por query. 

> use prometheus 
Using database prometheus

> show measurements
name: measurements
name
----
go_gc_duration_seconds
go_gc_duration_seconds_count
go_gc_duration_seconds_sum
go_goroutines
go_info
go_memstats_alloc_bytes
go_memstats_alloc_bytes_total
go_memstats_buck_hash_sys_bytes
go_memstats_frees_total
go_memstats_gc_cpu_fraction
go_memstats_gc_sys_bytes
go_memstats_heap_alloc_bytes
go_memstats_heap_idle_bytes
go_memstats_heap_inuse_bytes
go_memstats_heap_objects
...

Podemos consultar o histórico de uma chave seguindo com a query abaixo 

> select * from go_memstats_alloc_bytes_total ;
name: go_memstats_alloc_bytes_total
time                __name__                      instance           job                   value
----                --------                      --------           ---                   -----
1562550647877000000 go_memstats_alloc_bytes_total 192.168.0.101:9100 node_exporter_server1 146682728
1562550647974000000 go_memstats_alloc_bytes_total 192.168.0.102:9100 node_exporter_server2 146692216
1562550652494000000 go_memstats_alloc_bytes_total localhost:9090     prometheus_master     53310688
1562550652877000000 go_memstats_alloc_bytes_total 192.168.0.101:9100 node_exporter_server1 147691328
1562550652976000000 go_memstats_alloc_bytes_total 192.168.0.102:9100 node_exporter_server2 147737944
1562550657495000000 go_memstats_alloc_bytes_total localhost:9090     prometheus_master     57823176
1562550657877000000 go_memstats_alloc_bytes_total 192.168.0.101:9100 node_exporter_server1 149639280

Vale lembrar que é necessário ter domínio de queries no InfluxDb caso ocorra a integração com o Grafana.

No próximo post será apresentado como ver a métrica no Grafana .

Translate »