Crie relatórios personalizados para o operador de medição

O operador de medição é o faturamento e relatórios sobre o uso de recursos do sistema no nível do cluster Kubernetes, bem como no contexto de pods e namespaces individuais. Depois de instalar esse operador, o administrador recebe uma série de consultas prontas para, por exemplo, rastrear como os nós ou pods de cluster individuais estão usando CPU ou memória.







Para gerar o relatório necessário com uma frequência especificada, basta escrever um recurso de Relatório personalizado correspondente.



Cenários de uso



Relatórios de medição personalizados são necessários, por exemplo, nos seguintes casos:



  1. OpenShift, , (worker nodes) . . CPU , , -, , .
  2. OpenShift. Metering, , , , . , , , .
  3. Além disso, em uma situação com clusters públicos, o departamento de operações seria útil para ser capaz de manter registros no contexto de equipes e departamentos pelo tempo operacional total de seus pods (ou por quanto recursos de CPU ou memória foram gastos nele). Em outras palavras, estamos novamente interessados ​​em informações sobre quem é o proprietário deste ou daquele sub.


Para resolver esses problemas no cluster, basta criar alguns recursos personalizados, o que faremos a seguir. A instalação do operador de medição está além do escopo deste artigo, portanto, consulte a documentação de instalação, se necessário . Você pode aprender mais sobre como usar os relatórios de medição padrão na documentação relacionada .



Como funciona a medição



Antes de criar ativos personalizados, vamos dar uma olhada em Medição um pouco. Depois de instalado, ele cria seis tipos de recursos personalizados, dos quais nos concentraremos no seguinte:



  1. ReportDataSources (RDS) - Este mecanismo permite que você especifique quais dados estarão disponíveis e podem ser usados ​​em ReportQuery ou recursos de Relatório personalizados. O RDS também permite que você extraia dados de várias fontes. No OpenShift, os dados são extraídos do Prometheus, bem como de recursos ReportQuery (RQ) personalizados.
  2. ReportQuery (rq) – SQL- , RDS. RQ- Report, RQ- , . RQ- RDS-, RQ- Metering view Presto ( Metering) .
  3. Report – , , ReportQuery. , , , Metering. Report .


Muitos RDS e RQ estão disponíveis fora da caixa. Como estamos principalmente interessados ​​em relatórios de nível de nó, consideraremos aqueles que o ajudarão a escrever suas consultas personalizadas. Execute o seguinte comando durante o projeto "openshift-metering":



$ oc project openshift-metering
$ oc get reportdatasources | grep node
node-allocatable-cpu-cores
node-allocatable-memory-bytes
node-capacity-cpu-cores
node-capacity-memory-bytes
node-cpu-allocatable-raw
node-cpu-capacity-raw
node-memory-allocatable-raw
node-memory-capacity-raw 


Aqui, estamos interessados ​​em dois RDS: node-capacity-cpu-core e node-capput-capacity - capacity-raw, uma vez que queremos obter um relatório sobre o consumo de CPU. Vamos começar com node-capacity-cpu-core e executar o seguinte comando para ver como ele coleta dados do Prometheus:



$ oc get reportdatasource/node-capacity-cpu-cores -o yaml
<showing only relevant snippet below>
spec:
  prometheusMetricsImporter:
query: |
   kube_node_status_capacity_cpu_cores * on(node) group_left(provider_id) max(kube_node_info) by (node, provider_id)


Aqui, vemos uma solicitação do Prometheus que busca dados do Prometheus e os armazena no Presto. Vamos executar a mesma solicitação no console de métricas do OpenShift e ver o resultado. Temos um cluster OpenShift com dois nós de trabalho (cada um com 16 núcleos) e três nós mestres (cada um com 8 núcleos). A última coluna, Valor, contém o número de núcleos atribuídos ao nó.







Assim, os dados são recebidos e armazenados nas tabelas do Presto. Agora vamos ver os recursos personalizados do reportquery (RQ):



$ oc project openshift-metering
$ oc get reportqueries | grep node-cpu 
node-cpu-allocatable                    
node-cpu-allocatable-raw                
node-cpu-capacity                       
node-cpu-capacity-raw                   
node-cpu-utilization              


Aqui, estamos interessados ​​no seguinte RQS: node-cpu-capacity e node-cpu-capacity-raw. Como o nome sugere, essas métricas contêm dados descritivos (por quanto tempo um nó está em execução, quantos processadores ele alocou, etc.) e dados agregados.



Os dois RDS e dois RQS nos quais estamos interessados ​​estão interconectados pela seguinte cadeia:



node-cpu-capacity (rq) <b>uses</b> node-cpu-capacity-raw (rds) <b>uses</b> node-cpu-capacity-raw (rq) <b>uses</b> node-capacity-cpu-cores (rds)


Relatórios Customizáveis



Agora vamos escrever nossas próprias versões personalizadas de RDS e RQ. Precisamos alterar a solicitação do Prometheus para que exiba o modo do nó (mestre / trabalhador) e o rótulo do nó correspondente, que indica a qual equipe este nó pertence. O modo de operação do nó está contido na métrica kube_node_role Prometheus, consulte a coluna de função:







E todos os rótulos atribuídos ao nó estão contidos na métrica kube_node_labels do Prometheus, onde são formados usando o modelo label_. por exemplo, se um nó tiver um rótulo node_lob, na métrica do Prometheus ele será exibido como label_node_lob.







Agora só temos que modificar a consulta original usando essas duas consultas do Prometheus para obter os dados de que precisamos, como este:



 ((kube_node_status_capacity_cpu_cores * on(node) group_left(provider_id) max(kube_node_info) by (node, provider_id)) * on(node) group_left (role) kube_node_role{role='worker'}) * on(node) group_right(provider_id, role) kube_node_labels


Agora vamos executar esta consulta no console de métricas OpenShift e garantir que ela retorne dados por rótulos (node_lob) e por funções. Na figura abaixo, este é, primeiramente, label_node_lob, assim como a função (está lá, só não apareceu na captura de tela):







Portanto, precisamos escrever quatro recursos personalizados (você pode baixá-los na lista abaixo):



  1. rds-custom-node-capacity-cpu-cores.yaml - Especifica uma solicitação Prometheus.
  2. rq-custom-node-cpu-capacity-raw.yaml - refere-se à solicitação da etapa 1 e dá saída aos dados brutos.
  3. rds-custom-node-cpu-capacity-raw.yaml - refere-se ao RQ da etapa 2 e cria um objeto de exibição no Presto.
  4. rq-custom-node-cpu-capacity-with-cpus-labels.yaml - refere-se ao RDS da cláusula 3 e dados de saída levando em consideração as datas de início e término inseridas do relatório. Além disso, as colunas de função e rótulo são extraídas para o mesmo arquivo.


Depois de criar esses quatro arquivos yaml, vá para o projeto openshift-metering e execute os seguintes comandos:



$ oc project openshift-metering
$ oc create -f rds-custom-node-capacity-cpu-cores.yaml 
$ oc create -f rq-custom-node-cpu-capacity-raw.yaml
$ oc create -f rds-custom-node-cpu-capacity-raw.yaml 
$ oc create -f rq-custom-node-cpu-capacity-with-cpus-labels.yaml


Agora resta apenas escrever um objeto Relatório personalizado que fará referência ao objeto RQ da etapa 4. Por exemplo, você pode fazer isso conforme mostrado abaixo para que o relatório seja executado imediatamente e retorne dados de 15 a 30 de setembro.



$ cat report_immediate.yaml
apiVersion: metering.openshift.io/v1
kind: Report
metadata:
  name: custom-role-node-cpu-capacity-lables-immediate
  namespace: openshift-metering
spec:
  query: custom-role-node-cpu-capacity-labels
  reportingStart: "2020-09-15T00:00:00Z"
  reportingEnd: "2020-09-30T00:00:00Z"
  runImmediately: true

$ oc create -f report-immediate.yaml


Depois de executar este relatório, o arquivo de resultado (csv ou json) pode ser baixado do seguinte URL (basta substituir DOMAIN_NAME pelo seu próprio):



metering-openshift-metering.DOMAIN_NAME / api / v1 / reports / get? Name = custom-role-node-cpu- capacity-hourly & namespace = openshift-metering & format = csv



Como você pode ver na captura de tela do arquivo CSV, ele contém role e node_lob. Para obter o tempo de atividade do nó em segundos, divida node_capacity_cpu_core_seconds por node_capacity_cpu_cores:







Conclusão



O operador de medição é uma coisa legal para clusters OpenShift implantados em qualquer lugar. Ao fornecer uma estrutura extensível, permite criar recursos personalizados para gerar os relatórios desejados. Todos os códigos-fonte usados ​​neste artigo podem ser baixados aqui .



All Articles