From 3228bd692a83327affae8fc0a0b92245c6dbfc59 Mon Sep 17 00:00:00 2001 From: ThiagoGMF Date: Thu, 10 Feb 2022 00:43:53 -0300 Subject: [PATCH 1/3] feat: adding pt-br translation for system metrics page Co-authored-by: Brenda Santos --- .../cluster-administration/system-metrics.md | 169 ++++++++++++++++++ 1 file changed, 169 insertions(+) create mode 100644 content/pt-br/docs/concepts/cluster-administration/system-metrics.md diff --git a/content/pt-br/docs/concepts/cluster-administration/system-metrics.md b/content/pt-br/docs/concepts/cluster-administration/system-metrics.md new file mode 100644 index 0000000000..6b4f5140cb --- /dev/null +++ b/content/pt-br/docs/concepts/cluster-administration/system-metrics.md @@ -0,0 +1,169 @@ +--- +title: Métricas para componentes do sistema Kubernetes +content_type: concept +weight: 60 +--- + + + +Métricas dos componentes do sistema podem dar uma visão melhor do que acontece internamente. Métricas são particularmente úteis para construir _dashboards_ e alertas. + +Componentes do Kubernetes emitem métricas no [formato Prometheus](https://prometheus.io/docs/instrumenting/exposition_formats/). Esse formato é um texto simples estruturado, projetado para que pessoas e máquinas possam lê-lo. + + + +## Métricas no Kubernetes + +Na maioria dos casos, as métricas estão disponíveis no _endpoint_ `/metrics` do servidor HTTP. Para componentes que não expõem o _endpoint_ por padrão, ele pode ser ativado usando a _flag_ `--bind-address`. + +Exemplos desses componentes: + +- {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} +- {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} +- {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} +- {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}} +- {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} + +Em um ambiente de produção, você pode querer configurar o [Servidor Prometheus](https://prometheus.io/) ou algum outro coletor de métricas e disponibilizá-las em algum tipo de banco de dados temporais. + +Observe que o {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} também expõe métricas nos _endpoints_ `/metrics/cadvisor`, `/metrics/resource` e `/metrics/probes`. Essas métricas não possuem o mesmo ciclo de vida. + +Se o seu _cluster_ usa {{< glossary_tooltip term_id="rbac" text="RBAC" >}}, ler as métricas requer autorização por meio de um usuário, grupo ou conta de serviço com um _ClusterRole_ que conceda o acesso ao `/metrics`. + +Por exemplo: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: prometheus +rules: + - nonResourceURLs: + - "/metrics" + verbs: + - get +``` + +## Ciclo de vida da métrica + +métrica alfa → métrica estável → Métrica ultrapassada → métrica oculta → métrica excluída + +A métrica alfa não tem garantias de estabilidade. Essas métricas podem ser modificadas ou deletadas a qualquer momento. + +Métricas estáveis possuem a garantia de que não serão alteradas. Isso significa: + +- Uma métrica estável sem uma assinatura ultrapassada não será deletada ou renomeada. +- O tipo de uma métrica estável não será modificado + +As métricas ultrapassadas estão programadas para exclusão, mas ainda estão disponíveis para uso. +Essas métricas incluem uma anotação sobre a versão em que se tornaram ultrapassadas. + +Por exemplo: + +- Antes de se tornar ultrapassado + + ``` + # HELP some_counter isso conta coisas + # TYPE some_counter contador + some_counter 0 + ``` + +- Depois de se tornar ultrapassado + + ``` + # HELP some_counter (obsoleto desde 1.15.0) isso conta coisas + # TYPE some_counter contador + some_counter 0 + ``` + +Métricas ocultas não são mais publicadas para extração, mas ainda estão disponíveis para uso. Para usar uma métrica oculta, por favor consulte a seção [mostrar métricas ocultas](#mostrar-métricas-ocultas). + +Métricas excluídas não estão mais disponíveis e não podem mais ser usadas. + +## Mostrar métricas ocultas + +Como descrito anteriormente, administradores podem habilitar métricas ocultas por meio de uma _flag_ de linha de comando em um binário específico. Isso pode ser usado como uma saída de emergência para os administradores caso percam a migração das métricas ultrapassadas na última migração. + +A _flag_ `show-hidden-metrics-for-version` usa uma versão para a qual você deseja mostrar métricas ultrapassadas nessa versão. A versão é expressada como x.y, onde x é a versão principal e y a versão secundária. A versão de _patch_ não é necessária mesmo que uma métrica possa ser descontinuada em uma versão de _patch_, o motivo é que a política de descontinuação de métricas é executada na versão secundária. + +A _flag_ só pode usar a versão secundária anterior como seu valor. Todas as métricas ocultas no anterior serão emitidas se os administradores definirem a versão anterior como `show-hidden-metrics-for-version`. A versão muito antiga não é permitida porque viola a política de métricas ultrapassadas. + +Utilize a métrica `A` como exemplo, assumindo que `A` está obsoleto em 1.n. De acordo com a política de métricas ultrapassadas, podemos chegar à seguinte conclusão: + +- Na versão `1.n`, a métrica está ultrapassada, e pode ser emitida por padrão. +- Na versão `1.n+1`, a métrica está oculta por padrão e pode ser emitida via linha de comando `show-hidden-metrics-for-version=1.n`. +- Na versão `1.n+2`, a métrica deve ser removida do código fonte. Não há mais _escape hatch_. + +Se você está atualizando da versão `1.12` para `1.13`, mas ainda depende da métrica `A` ultrapassada em `1.12`, você deve definir métricas ocultas via linha de comando: `--show-hidden-metrics=1.12` e lembre-se de remover essa dependência de métrica antes de atualizar para `1.14`. + +## Desativar métricas do _accelerator_ + +O kubelet coleta métricas do _accelerator_ por meio do cAdvisor. Para coletar essas métricas, para _accelerator_ como as GPUs NVIDIA, o kubelet mantinha uma alça aberta no driver. Isso significava que, para realizar alterações na infraestrutura (por exemplo, atualizar o _driver_), um administrador do _cluster_ precisa interromper o agente kubelet. + +A responsabilidade de colear métricas do _accelerator_ agora pertence ao fornecedor, e não ao kubelet. Os fornecedores devem providenciar um contêiner que colete métricas e as exponha ao serviço de métricas (por exemplo, Prometheus). + +O [`DisableAcceleratorUsageMetrics` _feature gate_](/docs/reference/command-line-tools-reference/feature-gates/) desabilita as métricas coletadas pelo kubelet, com uma [_timeline_ para habilitar esse recurso por padrão](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria). + +## Métricas de componentes + +### Métricas do _kube-controller-manager_ + +As métricas do _controller manager_ fornecem informações importantes sobre o desempenho e a integridade do _controller manager_. +Essas métricas incluem métricas comuns do agente de execução da linguagem Go, tais como a quantidade de _go_routine_ e métricas específicas do _controller_, como latência de requisições etcd ou latência da _API_ dos provedores de serviços de nuvem (AWS, GCE, OpenStack), que podem ser usadas para medir a integridade de um _cluster_ + +A partir do Kubernetes 1.7, métricas detalhadas de provedores de serviços de nuvem estão disponíveis para operações de armazenamento para o GCE, AWS, Vsphere e OpenStack. +Essas métricas podem ser usadas para monitorar a integridade das operações de volumes persistentes + +Por exemplo, para o GCE as seguintes métricas são chamadas: + +``` +cloudprovider_gce_api_request_duration_seconds { request = "instance_list"} +cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"} +cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"} +cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"} +cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"} +cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} +``` + +### Métricas do _kube-scheduler_ + +{{< feature-state for_k8s_version="v1.21" state="beta" >}} + +O _scheduler_ expõe métricas opcionais que relatam os recursos solicitados e os limites desejados de todos os _pods_ em execução. Essas métricas podem ser usadas para criar _dashboards_ de planejamento de capacidade, avaliar os limites de agendamentos atuais ou históricos, identificar rapidamente cargas de trabalho que não podem ser agendadas devido à falta de recursos e comparar o uso atual com a solicitação do _pod_. + +O _kube-scheduler_ identifica as requisições de [recursos e limites](/docs/concepts/configuration/manage-resources-containers/) configurado para cada _Pod_; quando uma requisição ou limite é diferente de zero o _kube-scheduler_ relata uma _timeseries_ de métricas. Essa _timeseries_ é etiquetada por: + +- _namespace_ +- nome do pod +- o nó onde o _pod_ está programado ou uma _string_ vazia caso ainda não esteja programado +- prioridade +- o _scheduler_ atribuído para esse pod +- o nome do recurso (por exemplo, `cpu`) +- a unidade do recurso, se conhecida (por exemplo, `cores`) + +Uma vez que o _pod_ alcança um estado de conclusão (sua `restartPolicy` está como `Never` ou `onFailure` e está na fase de `Succeeded` ou `Failed`, ou foi deletado e todos os contêineres tem um estado de terminado), a série não é mais relatada já que o _scheduler_ agora está livre para agendar a execução de outros _pods_. As duas métricas são chamadas de `kube_pod_resource_request` e `kube_pod_resource_limit`. + +As métricas são expostas no _endpoint_ HTTP `/metrics/resources` e requerem a mesma autorização que o _endpoint_ `/metrics` no _scheduler_. Você deve usar a _flag_ `--show-hidden-metrics-for-version=1.20` para expor essas métricas de estabilidade alfa. + +## Desativando métricas + +Você pode desativar explicitamente as métricas via linha de comando utilizando a _flag_ `--disabled-metrics`. Isso pode ser desejado se, por exemplo, uma métrica estiver causando um problema de desempenho. A entrada é uma lista de métricas desabilitadas (ou seja, `--disabled-metrics=metric1,metric2`) + +## Aplicação de cardinalidade de métrica + +As métricas com dimensões sem limites podem causar problemas de memória nos componentes que elas instrumentam. Para limitar a utilização de recursos você pode usar a opção de linha de comando `--allow-label-value` para dinamicamente configurar uma lista de permissões de valores de _label_ para uma métrica. + +No estágio alfa, a _flag_ pode receber apenas uma série de mapeamentos como lista de permissões de _labels_ para uma métrica. +Cada mapeamento tem o formato `,=` onde `` é uma lista separada por vírgulas de nomes aceitáveis para a _label_ + +O formato geral se parece com: +`--allow-label-value ,=', ...', ,=', ...', ...`. + +Por exemplo: +`--allow-label-value number_count_metric,odd_number='1,3,5', number_count_metric,even_number='2,4,6', date_gauge_metric,weekend='Saturday,Sunday'` + +## {{% heading "whatsnext" %}} + +- Leia sobre o [formato de texto do Prometheus](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) para métricas +- Veja a lista de [métricas estáveis ​​do Kubernetes](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml) +- Leia sobre a [Política de suspensão de uso do Kubernetes](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior) From 80d359f061cd33e0d8b3e20a5f89f4d65fc68d8f Mon Sep 17 00:00:00 2001 From: ThiagoGMF Date: Fri, 18 Feb 2022 22:28:54 -0300 Subject: [PATCH 2/3] adding request changes --- .../cluster-administration/system-metrics.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/pt-br/docs/concepts/cluster-administration/system-metrics.md b/content/pt-br/docs/concepts/cluster-administration/system-metrics.md index 6b4f5140cb..c3fb9e7141 100644 --- a/content/pt-br/docs/concepts/cluster-administration/system-metrics.md +++ b/content/pt-br/docs/concepts/cluster-administration/system-metrics.md @@ -109,10 +109,10 @@ O [`DisableAcceleratorUsageMetrics` _feature gate_](/docs/reference/command-line ### Métricas do _kube-controller-manager_ As métricas do _controller manager_ fornecem informações importantes sobre o desempenho e a integridade do _controller manager_. -Essas métricas incluem métricas comuns do agente de execução da linguagem Go, tais como a quantidade de _go_routine_ e métricas específicas do _controller_, como latência de requisições etcd ou latência da _API_ dos provedores de serviços de nuvem (AWS, GCE, OpenStack), que podem ser usadas para medir a integridade de um _cluster_ +Essas métricas incluem métricas comuns do agente de execução da linguagem Go, tais como a quantidade de _go_routine_ e métricas específicas do _controller_, como latência de requisições etcd ou latência da _API_ dos provedores de serviços de nuvem (AWS, GCE, OpenStack), que podem ser usadas para medir a integridade de um _cluster_. A partir do Kubernetes 1.7, métricas detalhadas de provedores de serviços de nuvem estão disponíveis para operações de armazenamento para o GCE, AWS, Vsphere e OpenStack. -Essas métricas podem ser usadas para monitorar a integridade das operações de volumes persistentes +Essas métricas podem ser usadas para monitorar a integridade das operações de volumes persistentes. Por exemplo, para o GCE as seguintes métricas são chamadas: @@ -134,10 +134,10 @@ O _scheduler_ expõe métricas opcionais que relatam os recursos solicitados e o O _kube-scheduler_ identifica as requisições de [recursos e limites](/docs/concepts/configuration/manage-resources-containers/) configurado para cada _Pod_; quando uma requisição ou limite é diferente de zero o _kube-scheduler_ relata uma _timeseries_ de métricas. Essa _timeseries_ é etiquetada por: - _namespace_ -- nome do pod +- nome do _pod_ - o nó onde o _pod_ está programado ou uma _string_ vazia caso ainda não esteja programado - prioridade -- o _scheduler_ atribuído para esse pod +- o _scheduler_ atribuído para esse _pod_ - o nome do recurso (por exemplo, `cpu`) - a unidade do recurso, se conhecida (por exemplo, `cores`) @@ -147,14 +147,14 @@ As métricas são expostas no _endpoint_ HTTP `/metrics/resources` e requerem a ## Desativando métricas -Você pode desativar explicitamente as métricas via linha de comando utilizando a _flag_ `--disabled-metrics`. Isso pode ser desejado se, por exemplo, uma métrica estiver causando um problema de desempenho. A entrada é uma lista de métricas desabilitadas (ou seja, `--disabled-metrics=metric1,metric2`) +Você pode desativar explicitamente as métricas via linha de comando utilizando a _flag_ `--disabled-metrics`. Isso pode ser desejado se, por exemplo, uma métrica estiver causando um problema de desempenho. A entrada é uma lista de métricas desabilitadas (ou seja, `--disabled-metrics=metric1,metric2`). ## Aplicação de cardinalidade de métrica As métricas com dimensões sem limites podem causar problemas de memória nos componentes que elas instrumentam. Para limitar a utilização de recursos você pode usar a opção de linha de comando `--allow-label-value` para dinamicamente configurar uma lista de permissões de valores de _label_ para uma métrica. No estágio alfa, a _flag_ pode receber apenas uma série de mapeamentos como lista de permissões de _labels_ para uma métrica. -Cada mapeamento tem o formato `,=` onde `` é uma lista separada por vírgulas de nomes aceitáveis para a _label_ +Cada mapeamento tem o formato `,=` onde `` é uma lista separada por vírgulas de nomes aceitáveis para a _label_. O formato geral se parece com: `--allow-label-value ,=', ...', ,=', ...', ...`. From 57a706daba05ea063c788e52fb13704751b467ce Mon Sep 17 00:00:00 2001 From: ThiagoGMF Date: Tue, 22 Feb 2022 10:39:49 -0300 Subject: [PATCH 3/3] adding request changes for system-metrics page --- .../concepts/cluster-administration/system-metrics.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/pt-br/docs/concepts/cluster-administration/system-metrics.md b/content/pt-br/docs/concepts/cluster-administration/system-metrics.md index c3fb9e7141..701c157651 100644 --- a/content/pt-br/docs/concepts/cluster-administration/system-metrics.md +++ b/content/pt-br/docs/concepts/cluster-administration/system-metrics.md @@ -28,7 +28,7 @@ Em um ambiente de produção, você pode querer configurar o [Servidor Prometheu Observe que o {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} também expõe métricas nos _endpoints_ `/metrics/cadvisor`, `/metrics/resource` e `/metrics/probes`. Essas métricas não possuem o mesmo ciclo de vida. -Se o seu _cluster_ usa {{< glossary_tooltip term_id="rbac" text="RBAC" >}}, ler as métricas requer autorização por meio de um usuário, grupo ou conta de serviço com um _ClusterRole_ que conceda o acesso ao `/metrics`. +Se o seu _cluster_ usa {{< glossary_tooltip term_id="rbac" text="RBAC" >}}, ler as métricas requer autorização por meio de um usuário, grupo ou _ServiceAccount_ com um _ClusterRole_ que conceda o acesso ao `/metrics`. Por exemplo: @@ -46,17 +46,17 @@ rules: ## Ciclo de vida da métrica -métrica alfa → métrica estável → Métrica ultrapassada → métrica oculta → métrica excluída +Métrica alfa → Métrica estável → Métrica ultrapassada → Métrica oculta → Métrica excluída A métrica alfa não tem garantias de estabilidade. Essas métricas podem ser modificadas ou deletadas a qualquer momento. Métricas estáveis possuem a garantia de que não serão alteradas. Isso significa: -- Uma métrica estável sem uma assinatura ultrapassada não será deletada ou renomeada. +- Uma métrica estável sem uma assinatura ultrapassada não será deletada ou renomeada - O tipo de uma métrica estável não será modificado As métricas ultrapassadas estão programadas para exclusão, mas ainda estão disponíveis para uso. -Essas métricas incluem uma anotação sobre a versão em que se tornaram ultrapassadas. +Essas métricas incluem uma anotação sobre a versão em que se tornarão ultrapassadas. Por exemplo: @@ -82,7 +82,7 @@ Métricas excluídas não estão mais disponíveis e não podem mais ser usadas. ## Mostrar métricas ocultas -Como descrito anteriormente, administradores podem habilitar métricas ocultas por meio de uma _flag_ de linha de comando em um binário específico. Isso pode ser usado como uma saída de emergência para os administradores caso percam a migração das métricas ultrapassadas na última migração. +Como descrito anteriormente, administradores podem habilitar métricas ocultas por meio de uma _flag_ de linha de comando em um binário específico. Isso pode ser usado como uma saída de emergência para os administradores caso percam a migração das métricas ultrapassadas na última versão. A _flag_ `show-hidden-metrics-for-version` usa uma versão para a qual você deseja mostrar métricas ultrapassadas nessa versão. A versão é expressada como x.y, onde x é a versão principal e y a versão secundária. A versão de _patch_ não é necessária mesmo que uma métrica possa ser descontinuada em uma versão de _patch_, o motivo é que a política de descontinuação de métricas é executada na versão secundária.