Monitoramento Kubernetes com Telegraf Operator
Configurando o monitoramento de um cluster Kubernetes usando o Telegraf Operator:
Pré-requisitos
- Cluster Kubernetes em execução
1. Instalando o telegraf-operator no seu cluster Kubernetes e configurando o ambiente:
A versão atualizada do telegraf-operator pode ser instalada usando o arquivo a seguir do InfluxData. Verifique o link para configuração do telegraf-operator.
Faça o download e o deploy do arquivo a seguir:
O ClusterRole cluster-admin no ClusterRoleBinding em dev.yml não pode ser alterado, pois se refere a um ClusterRole padrão no Kubernetes.
Caso não exista o ClusterRole cluster-admin criar e fazer deploy de um cluster role usando o arquivo abaixo:
ClusterRole:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
annotations:
rbac.authorization.kubernetes.io/autoupdate: "true"
labels:
kubernetes.io/bootstrapping: rbac-defaults
name: cluster-admin
rules:
- apiGroups:
- "*"
resources:
- "*"
verbs:
- "*"
- nonResourceURLs:
- "*"
verbs:
- "*"Caso queira alterar as permissões para somente leitura, ou para somente o monitoramento de pods* use dessa forma:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
annotations:
rbac.authorization.kubernetes.io/autoupdate: "true"
labels:
kubernetes.io/bootstrapping: rbac-defaults
name: cluster-admin
rules:
- apiGroups:
- "*"
resources: ["pods"]
verbs:
- "*"
- nonResourceURLs:
- "*"
verbs: ["get", "list", "watch"]O uso da regra em "resources" para monitorar apenas os pods* não permite o monitoramento do cluster inteiro. Impedindo assim, o uso do plugin Kubernetes da documentação "Monitoramento de Recursos de Pods"
Configuração do ambiente:
1. Configurar as classes Telegraf:
O arquivo classes.yml define as classes Telegraf que serão usadas para reportar dados para o InfluxDB e para a saída padrão. Substitua <simon_dbworker_ip>(ceritifque-se que seja o. IP da instância DB Worker), <database>, <hostname> e <cluster> pelos valores desejados.
Faça apenas os download do arquivo a seguir, não faça o deploy, ele precisará de ser alterado primeiro:
Exemplo de um arquivo classes.yml:
apiVersion: v1
kind: Secret
metadata:
name: telegraf-operator-classes
namespace: telegraf-operator
stringData:
# basic classes that can be used to develop telegraf-operator ; these classes
# report to InfluxDB v1 in same cluster as well as to stdout for convenience
app: |+
[[outputs.influxdb]]
urls = ["<simon_dbworker_ip>:8086"]
database = "metrics"
[global_tags]
ci_ref_id = "<ci_ref_id>"
hostname = "<hostname>"- [[outputs.influxdb]]: Configuração do plugin de saída para enviar métricas ao InfluxDB.
- urls: O URL do servidor InfluxDB onde as métricas serão enviadas. Substitua <simon_dbworker_ip> pelo endereço IP ou hostname do seu servidor InfluxDB.
- database: O nome do banco de dados InfluxDB onde as métricas serão armazenadas.
- username: O nome de usuário para autenticação no InfluxDB.
- password: A senha para autenticação no InfluxDB.
- skip_database_creation: Se true, impede o Telegraf de tentar criar o banco de dados se ele não existir.
- [global_tags]: Configuração de tags globais que serão adicionadas a todas as métricas coletadas pelo Telegraf.
- ci_ref_id: Identificador de referência de integração contínua. O identificador do servidor pode ser localizada no detalhamento do IC na infraestrura.
- Caso o cluster seja virtual, é aconselhado utilizar o ci_ref_id do Intelligence Instance do Simon.
-
Em vermelho(somente o número) - hostname: Nome do host de onde as métricas estão sendo coletadas pelo valor real.
2. Configurar uma coleta customizada para um Plugin do Telegraf:
Coloque o campo annotations no arquivo yaml de um pod já existente, onde se deseja coletar metricas, para colocar um side car do telegraf.
No arquivo a seguir define em um Statefulset, Deployment ou Pod já existente, o campo annotations, onde é preciso configurar um plugin que será monitorado pelo Telegraf fora do escopo global, que foi configurado no classes.yaml à cima. Essa configuração servirá para coletar a metricas de um pod exclusivo ou mais. Assim, evitando conflitos nas chamadas ou erros no envio de metricas globais (classes.yaml).
Substitua os valores de name, namespace, serviceName, app, inputs.plugin_nome, urls, limits-cpu e limits-memory pelos valores desejados. Verifique os possíveis plugins de input e configurações neste link.
O "telegraf.influxdata.com/class: app" devera ser configurado de acordo com o nome da configuração no classes.yaml na linha 9 como mostrado no item 1.
Exemplo de um arquivo redis.yaml:
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: redis
namespace: telegraf-operator
spec:
selector:
matchLabels:
app: redis
serviceName: redis
template:
metadata:
labels:
app: redis
annotations:
telegraf.influxdata.com/inputs: |+
[[inputs.redis]]
servers = ["tcp://localhost:6379"]
telegraf.influxdata.com/class: app
telegraf.influxdata.com/env-fieldref-NAMESPACE: metadata.namespace
telegraf.influxdata.com/path: /redis_status # (exemplo de input)
telegraf.influxdata.com/limits-cpu: '750m'
# limite de memoria invalida será ignorada
telegraf.influxdata.com/limits-memory: '800x'
spec:
containers:
- name: redis
image: redis:alpineObs: Este yaml file podes ser usado também para verificar o container telegraf-operator contido nesse pod usando o comando a seguir.
3. Aplicar as configurações:
Aplique as configurações usando o comando kubectl apply -f <arquivo.yml> para cada um dos arquivos YAML.
Deploy dos Pods e Contexto Kubernetes:
Certifique-se de que o contexto correto do kubectl esteja definido e sendo utilizado, caso contrário, ira falhar:
kubectl config use-context telegraf-operator-nome
kubectl apply -f dev.yml
kubectl apply -f classes.yml
kubectl apply -f plugin_nome.yml
kubectl describe pod --namespace=<namespace> <pod_name> Acesso aos logs do deploy:
kubectl logs -f -n <namespace> <pod_name> -c telegrafLinks: Telegraf Operator:
Plugins: