Instalação e configuração do operador de monitoramento Kubernetes
Sugerir alterações
PDFs
O Data Infrastructure Insights oferece a coleção Operador de Monitoramento do Kubernetes para Kubernetes. Navegue até Kubernetes > Collectors > Kubernetes Collector para implantar um novo operador.
Antes de instalar o operador de monitoramento do Kubernetes
Consulte "Pré-requisitos"a documentação antes de instalar ou atualizar o Operador de Monitoramento do Kubernetes.
Instalando o Operador de Monitoramento do Kubernetes
-
Insira um nome de cluster e um namespace exclusivos. Se você a atualizar é de um operador Kubernetes anterior, use o mesmo nome de cluster e namespace.
-
Uma vez que eles são inseridos, você pode copiar o snippet de comando de download para a área de transferência.
-
Cole o snippet em uma janela bash e execute-o. Os ficheiros de instalação do Operador serão transferidos. Observe que o snippet tem uma chave exclusiva e é válido por 24 horas.
-
Se você tiver um repositório personalizado ou privado, copie o trecho opcional Image Pull, cole-o em um shell bash e execute-o. Depois que as imagens tiverem sido puxadas, copie-as para o seu repositório privado. Certifique-se de manter as mesmas tags e estrutura de pastas. Atualize os caminhos em operator-deployment.yaml, bem como as configurações do repositório docker em operator-config.yaml.
-
Se desejar, revise as opções de configuração disponíveis, como proxy ou configurações de repositório privado. Você pode ler mais sobre "opções de configuração".
-
Quando estiver pronto, implante o Operador copiando o snippet de aplicação kubectl, baixando-o e executando-o.
-
A instalação prossegue automaticamente. Quando estiver concluído, clique no botão Next.
-
Quando a instalação estiver concluída, clique no botão Next. Certifique-se também de excluir ou armazenar com segurança o arquivo operator-secrets.yaml.
Se estiver usando um proxy, leia sobre configurando proxy.
Se você tiver um repositório personalizado, leia sobre usando um repositório docker personalizado/privado.
Componentes de monitoramento do Kubernetes
O monitoramento do Kubernetes do Data Infrastructure Insights é composto por quatro componentes de monitoramento:
-
Métricas do cluster
-
Desempenho de rede e mapa (opcional)
-
Registos de eventos (opcional)
-
Análise de mudança (opcional)
Os componentes opcionais acima são ativados por padrão para cada coletor do Kubernetes; se você decidir que não precisa de um componente para um coletor específico, você pode desativá-lo navegando para Kubernetes > coletores e selecionando Modificar implantação no menu "três pontos" do coletor à direita da tela.
O ecrã mostra o estado atual de cada componente e permite desativar ou ativar componentes para esse coletor, conforme necessário.
Atualização para o operador de monitoramento mais recente do Kubernetes
Determine se existe um AgentConfiguration com o Operador existente (se o seu namespace não for o NetApp-monitoring padrão, substitua o namespace apropriado):
kubectl -n netapp-monitoring get agentconfiguration netapp-monitoring-configuration Se existir uma configuração AgentConfiguration:
-
Instale O operador mais recente sobre o operador existente.
-
Certifique-se de que está puxando as imagens mais recentes do recipiente se estiver a utilizar um repositório personalizado.
-
Se o AgentConfiguration não existir:
-
Anote o nome do cluster conforme reconhecido pelo Data Infrastructure Insights (se o namespace não for o monitoramento padrão do NetApp, substitua o namespace apropriado):
kubectl -n netapp-monitoring get agent -o jsonpath='{.items[0].spec.cluster-name}' * Crie uma cópia de segurança do Operador existente (se o seu namespace não for o NetApp-monitoring predefinido, substitua o namespace apropriado):kubectl -n netapp-monitoring get agent -o yaml > agent_backup.yaml * <<to-remove-the-kubernetes-monitoring-operator,Desinstalar>> O operador existente. * <<installing-the-kubernetes-monitoring-operator,Instale>> O operador mais recente.
-
Use o mesmo nome de cluster.
-
Depois de baixar os arquivos YAML do Operador mais recentes, coloque as personalizações encontradas no Agent_backup.yaml para o operador-config.yaml baixado antes de implantar.
-
Certifique-se de que está puxando as imagens mais recentes do recipiente se estiver a utilizar um repositório personalizado.
-
Parando e iniciando o Operador de Monitoramento do Kubernetes
Para parar o operador de monitoramento do Kubernetes:
kubectl -n netapp-monitoring scale deploy monitoring-operator --replicas=0 Para iniciar o operador de monitoramento do Kubernetes:
kubectl -n netapp-monitoring scale deploy monitoring-operator --replicas=1
Desinstalação
Para remover o operador de monitoramento do Kubernetes
Observe que o namespace padrão para o Operador de Monitoramento do Kubernetes é "NetApp-monitoring". Se você tiver definido seu próprio namespace, substitua esse namespace nesses e todos os comandos e arquivos subsequentes.
As versões mais recentes do operador de monitoramento podem ser desinstaladas com os seguintes comandos:
kubectl -n <NAMESPACE> delete agent -l installed-by=nkmo-<NAMESPACE> kubectl -n <NAMESPACE> delete clusterrole,clusterrolebinding,crd,svc,deploy,role,rolebinding,secret,sa -l installed-by=nkmo-<NAMESPACE>
Se o operador de monitoramento foi implantado em seu próprio namespace dedicado, exclua o namespace:
kubectl delete ns <NAMESPACE> Se o primeiro comando retornar "nenhum recurso encontrado", use as instruções a seguir para desinstalar versões mais antigas do operador de monitoramento.
Execute cada um dos seguintes comandos em ordem. Dependendo da sua instalação atual, alguns desses comandos podem retornar mensagens "objeto não encontrado". Essas mensagens podem ser ignoradas com segurança.
kubectl -n <NAMESPACE> delete agent agent-monitoring-netapp kubectl delete crd agents.monitoring.netapp.com kubectl -n <NAMESPACE> delete role agent-leader-election-role kubectl delete clusterrole agent-manager-role agent-proxy-role agent-metrics-reader <NAMESPACE>-agent-manager-role <NAMESPACE>-agent-proxy-role <NAMESPACE>-cluster-role-privileged kubectl delete clusterrolebinding agent-manager-rolebinding agent-proxy-rolebinding agent-cluster-admin-rolebinding <NAMESPACE>-agent-manager-rolebinding <NAMESPACE>-agent-proxy-rolebinding <NAMESPACE>-cluster-role-binding-privileged kubectl delete <NAMESPACE>-psp-nkmo kubectl delete ns <NAMESPACE>
Se uma restrição de contexto de segurança foi criada anteriormente:
kubectl delete scc telegraf-hostaccess
Sobre o Kube-State-metrics
O Operador de Monitoramento do Kubernetes do NetApp instala suas próprias métricas de estado do kube para evitar conflitos com outras instâncias.
Para obter informações sobre métricas Kube-State, "esta página"consulte .
Configurar/personalizar o Operador
Essas seções contêm informações sobre como personalizar a configuração do operador, trabalhar com proxy, usar um repositório docker personalizado ou privado ou trabalhar com o OpenShift.
Opções de configuração
As configurações mais comumente modificadas podem ser configuradas no recurso personalizado AgentConfiguration. Você pode editar esse recurso antes de implantar o operador editando o arquivo operator-config.yaml. Este arquivo inclui exemplos comentados de configurações. Consulte a lista de "definições disponíveis" para obter a versão mais recente do operador.
Você também pode editar esse recurso depois que o operador tiver sido implantado usando o seguinte comando:
kubectl -n netapp-monitoring edit AgentConfiguration Para determinar se a versão implantada do operador suporta AgentConfiguration, execute o seguinte comando:
kubectl get crd agentconfigurations.monitoring.netapp.com Se você vir uma mensagem "erro do servidor (NotFound)", seu operador deve ser atualizado antes de poder usar o AgentConfiguration.
Configurando o suporte Proxy
Há dois lugares onde você pode usar um proxy em seu locatário para instalar o Operador de Monitoramento do Kubernetes. Estes podem ser os mesmos ou sistemas proxy separados:
-
Proxy necessário durante a execução do snippet de código de instalação (usando "curl") para conetar o sistema onde o snippet é executado ao seu ambiente Data Infrastructure Insights
-
Proxy necessário pelo cluster do Kubernetes de destino para se comunicar com seu ambiente Data Infrastructure Insights
Se você usar um proxy para um ou ambos, para instalar o Monitor operacional Kubernetes, primeiro você deve garantir que o proxy esteja configurado para permitir uma boa comunicação com o ambiente Insights da infraestrutura de dados. Se você tiver um proxy e puder acessar o Data Infrastructure Insights do servidor/VM a partir do qual deseja instalar o Operador, o proxy provavelmente estará configurado corretamente.
Para o proxy usado para instalar o Monitor operacional Kubernetes, antes de instalar o Operador, defina as variáveis de ambiente http_proxy/https_proxy. Para alguns ambientes proxy, você também pode precisar definir a variável no_proxy environment.
Para definir a(s) variável(s), execute as seguintes etapas em seu sistema antes de instalar o Operador de Monitoramento do Kubernetes:
-
Defina a(s) variável(s) de ambiente https_proxy e/ou http_proxy para o usuário atual:
-
Se o proxy que está sendo configurado não tiver Autenticação (nome de usuário/senha), execute o seguinte comando:
export https_proxy=<proxy_server>:<proxy_port> .. Se o proxy que está sendo configurado tiver Autenticação (nome de usuário/senha), execute este comando:
export http_proxy=<proxy_username>:<proxy_password>@<proxy_server>:<proxy_port>
-
Para que o proxy usado para que o cluster do Kubernetes se comunique com o ambiente Data Infrastructure Insights, instale o Operador de Monitoramento do Kubernetes depois de ler todas essas instruções.
Configure a seção proxy do AgentConfiguration no operator-config.yaml antes de implantar o Operador de Monitoramento do Kubernetes.
agent:
...
proxy:
server: <server for proxy>
port: <port for proxy>
username: <username for proxy>
password: <password for proxy>
# In the noproxy section, enter a comma-separated list of
# IP addresses and/or resolvable hostnames that should bypass
# the proxy
noproxy: <comma separated list>
isTelegrafProxyEnabled: true
isFluentbitProxyEnabled: <true or false> # true if Events Log enabled
isCollectorsProxyEnabled: <true or false> # true if Network Performance and Map enabled
isAuProxyEnabled: <true or false> # true if AU enabled
...
...
Usando um repositório docker personalizado ou privado
Por padrão, o operador de monitoramento do Kubernetes coletará imagens de contentor do repositório Data Infrastructure Insights. Se você tiver um cluster do Kubernetes usado como destino para monitoramento e esse cluster estiver configurado para extrair apenas imagens de contentor de um repositório ou Registro de contentor personalizado ou privado do Docker, configure o acesso aos contentores necessários pelo Operador de Monitoramento do Kubernetes.
Execute o "trecho de recebimento de imagem" do bloco de instalação do Operador de Monitoramento do NetApp. Esse comando fará login no repositório Data Infrastructure Insights, extrairá todas as dependências de imagem do operador e fará logout do repositório Data Infrastructure Insights. Quando solicitado, insira a senha temporária do repositório fornecida. Este comando transfere todas as imagens utilizadas pelo operador, incluindo as funcionalidades opcionais. Veja abaixo quais recursos essas imagens são usadas.
Funcionalidade do operador principal e monitoramento do Kubernetes
-
monitoramento de NetApp
-
ci-kube-rbac-proxy
-
ci-ksm
-
ci-telegraf
-
distroless-root-user
Registo de eventos
-
ci-fluente-bit
-
ci-kurein-event-exporter
Desempenho de rede e mapa
-
ci-net-observador
Envie a imagem do docker do operador para o seu repositório docker privado/local/empresarial de acordo com suas políticas corporativas. Certifique-se de que as tags de imagem e os caminhos de diretório para essas imagens em seu repositório sejam consistentes com os do repositório Data Infrastructure Insights.
Edite a implantação do operador de monitoramento no operator-deployment.yaml e modifique todas as referências de imagem para usar seu repositório Docker privado.
image: <docker repo of the enterprise/corp docker repo>/ci-kube-rbac-proxy:<ci-kube-rbac-proxy version> image: <docker repo of the enterprise/corp docker repo>/netapp-monitoring:<version>
Edite o AgentConfiguration no operator-config.yaml para refletir o novo local de repo do docker. Crie uma nova imagePullSecret para o seu repositório privado, para obter mais detalhes consulte https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
agent: ... # An optional docker registry where you want docker images to be pulled from as compared to CI's docker registry # Please see documentation link here: link:task_config_telegraf_agent_k8s.html#using-a-custom-or-private-docker-repository dockerRepo: your.docker.repo/long/path/to/test # Optional: A docker image pull secret that maybe needed for your private docker registry dockerImagePullSecret: docker-secret-name
Instruções do OpenShift
Se você estiver executando no OpenShift 4,6 ou superior, você deve editar o AgentConfiguration em operator-config.yaml para ativar a configuração runPrivileged:
# Set runPrivileged to true SELinux is enabled on your kubernetes nodes runPrivileged: true
O OpenShift pode implementar um nível adicional de segurança que pode bloquear o acesso a alguns componentes do Kubernetes.
Tolerações e taints
O NetApp-ci-telegraf-ds, o NetApp-CI-Fluent-bit-ds e o NetApp-CI-NET-Observer-L4-DS DaemonSets devem agendar um pod em cada nó do cluster para coletar corretamente os dados em todos os nós. O operador foi configurado para tolerar alguns taints conhecidos. Se você tiver configurado quaisquer taints personalizados em seus nós, impedindo assim que os pods sejam executados em cada nó, você poderá criar uma tolerância para essas taints ."Em AgentConfiguration" Se você tiver aplicado taints personalizados a todos os nós do cluster, também será necessário adicionar as tolerâncias necessárias à implantação do operador para permitir que o pod do operador seja agendado e executado.
Saiba mais sobre o Kubernetes "Taints e Tolerations".
Uma Nota sobre Segredos
Para remover a permissão do Operador de Monitoramento do Kubernetes para exibir segredos em todo o cluster, exclua os seguintes recursos do arquivo operator-setup.yaml antes de instalar:
ClusterRole/netapp-ci-<namespace>-agent-secret-clusterrole ClusterRoleBinding/netapp-ci-<namespace>-agent-secret-clusterrolebinding
Se for uma atualização, exclua também os recursos do cluster:
kubectl delete ClusterRole/netapp-ci-<namespace>-agent-secret-clusterrole kubectl delete ClusterRoleBinding/netapp-ci-<namespace>-agent-secret-clusterrolebinding
Se a análise de mudança estiver ativada, modifique o AgentConfiguration ou operator-config.yaml para descomentar a seção de gerenciamento de alterações e inclua kindsToIgnoreFromWatch: '"segredos"' na seção Gerenciamento de alterações. Observe a presença e a posição de aspas simples e duplas nesta linha.
# change-management: ... # # A comma separated list of kinds to ignore from watching from the default set of kinds watched by the collector # # Each kind will have to be prefixed by its apigroup # # Example: '"networking.k8s.io.networkpolicies,batch.jobs", "authorization.k8s.io.subjectaccessreviews"' kindsToIgnoreFromWatch: '"secrets"' ...
Verificando assinaturas de imagem do Operador de Monitoramento do Kubernetes
A imagem para o operador e todas as imagens relacionadas que ele implanta são assinadas pelo NetApp. Você pode verificar manualmente as imagens antes da instalação usando a ferramenta de cografia ou configurar um controlador de admissão do Kubernetes. Para obter mais detalhes, consulte "Documentação do Kubernetes".
A chave pública usada para verificar as assinaturas de imagem está disponível no bloco de instalação do Operador de Monitoramento em Opcional: Carregue as imagens do operador para o seu repositório privado > chave Pública de assinatura de imagem
Para verificar manualmente uma assinatura de imagem, execute as seguintes etapas:
-
Copie e execute o snippet de recebimento de imagem
-
Copie e insira a senha do repositório quando solicitado
-
Armazenar a chave Pública de assinatura de imagem (dii-image-signing.pub no exemplo)
-
Verifique as imagens usando o cosign. Consulte o exemplo a seguir de uso de cosign
$ cosign verify --key dii-image-signing.pub --insecure-ignore-sct --insecure-ignore-tlog <repository>/<image>:<tag>
Verification for <repository>/<image>:<tag> --
The following checks were performed on each of these signatures:
- The cosign claims were validated
- The signatures were verified against the specified public key
[{"critical":{"identity":{"docker-reference":"<repository>/<image>"},"image":{"docker-manifest-digest":"sha256:<hash>"},"type":"cosign container image signature"},"optional":null}]
Solução de problemas
Algumas coisas para tentar se você encontrar problemas para configurar o operador de monitoramento do Kubernetes:
| Problema: | Tente isto: |
|---|---|
Não vejo um hiperlink/conexão entre o meu volume persistente do Kubernetes e o dispositivo de armazenamento de back-end correspondente. Meu volume persistente do Kubernetes é configurado usando o nome de host do servidor de armazenamento. |
Siga as etapas para desinstalar o agente Telegraf existente e reinstalar o agente Telegraf mais recente. Você precisa estar usando o Telegraf versão 2,0 ou posterior, e o storage de cluster do Kubernetes precisa ser monitorado ativamente pelo Data Infrastructure Insights. |
Estou vendo mensagens nos logs que se assemelham ao seguinte: E0901 15 352:21 v1:39,962145 1 k8s reflector.go:178] k8s.io/kube-State-metrics/internal/store/builder.go:352: Falha ao listar *v1.MutatingWebhookConfiguration: O servidor não conseguiu encontrar o recurso solicitado E0901 15:k8s:43,168161 1 reflector.go:178] 21.io/kube-State-State-lease |
Essas mensagens podem ocorrer se você estiver executando o kube-State-metrics versão 2.0.0 ou superior com versões do Kubernetes abaixo de 1,20. Para obter a versão do Kubernetes: Kubectl version para obter a versão do kube-State-metrics: Kubectl get deploy/kube-State-metrics -o jsonpath leases' para evitar que essas mensagens aconteçam, os usuários podem modificar sua implantação do kube-State-metrics para desativar os seguintes: Mutatinghookhookhooks |
Vejo mensagens de erro do Telegraf semelhantes às seguintes, mas o Telegraf inicia e executa: Oct 11 14:23:41 ip-172-31-39-47 systemd[1]: Iniciou o agente de servidor orientado a plug-in para relatar métricas no InfluxDB. Oct 11 14:23:41 ip-172-31-39-47 telegraf[1827]: Tempo 2021-10-11T14:23:41Z" não foi possível criar o diretório de cache. /Etc/telegraf/.cache/floco de neve, err: Mkdir /etc/telegraf/.CA che: Permissão negada. Ignorado. Func"gostonflake.(*defaultLogger).Errorf" file "log.go:120" Oct:10 ip-23-41Z-39-47 telegraf[1827]: 2021" 31"erro de 11 14:23:41:172". Abra /etc/telegraf/.cache/floco de neve/ocsp_response_cache.json: nenhum arquivo ou diretório desse tipo de arquivo ou diretório.(*defaultLogger).Errorf" arquivo "log.go:120 23" Oct 2021 41Z:10 ip-172-31-39-47 telegraf[1827]: 11 14-23:41 A iniciar o Telegraf 1.19.3 |
Este é um problema conhecido. "Este artigo do GitHub"Consulte para obter mais detalhes. Enquanto o Telegraf estiver ativo e em execução, os usuários podem ignorar essas mensagens de erro. |
No Kubernetes, meu(s) pod(s) Telegraf está relatando o seguinte erro: "Erro no processamento de informações de mountstats: Failed to open mountstats file: /Hostfs/proc/1/mountstats, error: Open /hostfs/proc/1/mountstats: Permission denied" |
Se o SELinux estiver habilitado e aplicando, provavelmente impedirá que o(s) pod(s) Telegraf acesse o arquivo /proc/1/mountstats no nó Kubernetes. Para superar essa restrição, edite a configuração do agentConfiguration e ative a configuração RUNGED Privileged. Para obter mais detalhes, consulte "Instruções do OpenShift"a . |
No Kubernetes, meu pod Telegraf ReplicaSet está relatando o seguinte erro: [inputs.prometheus] erro no plugin: Não foi possível carregar o par de chaves /etc/kupere/pki/etcd/Server.crt:/etc/kuGES/pki/etcd/Server.key: Open /etc/kuurge/pki/etcd/Server.crt: nenhum arquivo ou diretório |
O pod Telegraf ReplicaSet destina-se a ser executado em um nó designado como mestre ou para o etcd. Se o pod ReplicaSet não estiver sendo executado em um desses nós, você receberá esses erros. Verifique se seus nós master/etcd têm manchetes neles. Se o fizerem, adicione as tolerâncias necessárias ao Telegraf ReplicaSet, telegraf-rs. Por exemplo, edite o ReplicaSet… kubectl edite rs telegraf-RS …e adicione as tolerâncias apropriadas à especificação. Em seguida, reinicie o pod ReplicaSet. |
Tenho um ambiente PSP/PSA. Isso afeta meu operador de monitoramento? |
Se o seu cluster Kubernetes estiver em execução com a Política de Segurança do Pod (PSP) ou a admissão de Segurança do Pod (PSA), você deverá fazer o upgrade para o Operador de Monitoramento do Kubernetes mais recente. Siga estes passos para atualizar para o Operador atual com suporte para PSP/PSA: 1. Desinstalar o operador de monitoramento anterior: kubectl delete agent-monitoring-NetApp -n NetApp-monitoring kubectl delete ns NetApp-monitoring kubectl delete crd agents.monitoring.NetApp.com kubectl delete clusterrole agent-manager-role agent-proxy-role agent-rolebinding cluster-rolebinding.-rolebinding 2. Instale a versão mais recente do operador de monitorização. |
Deparei-me com problemas ao tentar implementar o Operador e tenho PSP/PSA em utilização. |
1. Edite o agente usando o seguinte comando: Kubectl -n <name-space> edit Agent 2. Marque "Segurança-política-ativada" como "falsa". Isso desativará as políticas de Segurança do Pod e a admissão de Segurança do Pod e permitirá que o Operador implante. Confirme usando os seguintes comandos: Kubectl Get PSP (deve mostrar a Política de Segurança Pod removida) kubectl get all -n <namespace> |
grep -i psp (deve mostrar que nada é encontrado) |
Erros "ImagePullBackoff" vistos |
Esses erros podem ser vistos se você tiver um repositório docker personalizado ou privado e ainda não tiver configurado o Operador de Monitoramento do Kubernetes para reconhecê-lo adequadamente. Leia mais sobre a configuração para repositório personalizado/privado. |
Estou tendo um problema com a implantação do meu operador de monitoramento e a documentação atual não me ajuda a resolvê-lo. |
Capture ou anote a saída dos comandos a seguir e entre em Contato com a equipe de suporte técnico. kubectl -n netapp-monitoring get all kubectl -n netapp-monitoring describe all kubectl -n netapp-monitoring logs <monitoring-operator-pod> --all-containers=true kubectl -n netapp-monitoring logs <telegraf-pod> --all-containers=true |
Os pods NET-Observer (Workload Map) no namespace Operator estão em CrashLoopBackOff |
Esses pods correspondem ao coletor de dados do mapa de workload para observabilidade de rede. Tente estes: • Verifique os logs de um dos pods para confirmar a versão mínima do kernel. Por exemplo: ---- [ci-tenant-id":"your-tenant-id","Collector-cluster":"your-k8s-cluster-name","ambiente":"prod","nível":"erro","msg":"falhou na validação. Razão: A versão 3.10.0 do kernel é menor que a versão mínima do kernel de 4.18.0","Time":"2022-11-09T08:23:08Z" ---- • os pods do Net-Observer requerem que a versão do kernel do Linux seja pelo menos 4.18.0. Verifique a versão do kernel usando o comando "uname -r" e certifique-se de que eles são > 4.18.0 |
Os pods estão em execução no namespace do operador (padrão: Monitoramento NetApp), mas nenhum dado é exibido na IU para mapa de workload ou métricas do Kubernetes em consultas |
Verifique a configuração de hora nos nós do cluster K8S. Para uma auditoria precisa e relatórios de dados, é altamente recomendável sincronizar a hora na máquina do agente usando o Network Time Protocol (NTP) ou o Simple Network Time Protocol (SNTP). |
Alguns dos pods net-observer no namespace Operador estão no estado pendente |
NET-Observer é um DaemonSet e executa um pod em cada nó do cluster k8s. • Observe o pod que está no estado pendente e verifique se ele está enfrentando um problema de recurso para CPU ou memória. Certifique-se de que a memória e a CPU necessárias estão disponíveis no nó. |
Estou vendo o seguinte em meus logs imediatamente após instalar o Operador de Monitoramento do Kubernetes: [inputs.prometheus] erro no plugin: Erro ao fazer solicitação HTTP para http://kube-state-metrics.<namespace>.svc.cluster.local:8080/metrics: Get http://kube-state-metrics.<namespace>.svc.cluster.local:8080/metrics: Dial tcp: Lookup kube-State-metrics.<namespace>.svc.cluster.local: nenhum host |
Normalmente, essa mensagem só é vista quando um novo operador é instalado e o pod telegraf-rs está ativo antes do pod ksm estar ativo. Essas mensagens devem parar quando todos os pods estiverem em execução. |
Não vejo nenhuma métrica sendo coletada para os CronJobs do Kubernetes que existem no meu cluster. |
Verifique a versão do Kubernetes (isto é |
Depois de instalar o operador, os pods telegraf-ds entram em CrashLoopBackOff e os logs do pod indicam "su: Authentication failure". |
Edite a seção telegraf em AgentConfiguration e defina dockerMetricCollectionEnabled como false. Para obter mais detalhes, consulte o "opções de configuração". … spec: … telegraf: … - Name: docker run-mode : - DaemonSet substituições: - Chave: DOCKER_UNIX_SOCK_PLACEHOLDER valor: unix:////run/docker.Sock … … |
Vejo mensagens de erro repetitivas semelhantes às seguintes nos meus logs do Telegraf: E! [Agent] erro ao gravar em outputs.http: Post "/https://<tenant_url>/rest/v1/Lake/ingest/influxdb": Prazo de contexto excedido (Client.Timeout excedido enquanto aguarda cabeçalhos) |
Edite a seção telegraf em AgentConfiguration e aumente outputTimeout para 10s. Para obter mais detalhes, consulte o "opções de configuração". |
Estou faltando dados involvedobject para alguns Registros de eventos. |
Certifique-se de que seguiu os passos indicados na "Permissões" secção acima. |
Por que estou vendo dois pods de operador de monitoramento em execução, um chamado NetApp-CI-monitoring-operator-<pod> e o outro chamado Monitoring-operator-<pod>? |
A partir de 12 de outubro de 2023, o Data Infrastructure Insights refatorou a operadora para melhor atender nossos usuários; para que essas alterações sejam totalmente adotadas, você retire o operador antigo deve e instale o novo. |
Os eventos do meu kualves pararam inesperadamente de reportar ao Data Infrastructure Insights. |
Recuperar o nome do pod de exportador de eventos: `kubectl -n netapp-monitoring get pods |
grep event-exporter |
awk '{print $1}' |
sed 's/event-exporter./event-exporter/'` |
Estou vendo POD(s) implantado(s) pelo Operador de Monitoramento do Kubernetes travarem devido a recursos insuficientes. |
Consulte o Operador de Monitoramento do Kubernetes "opções de configuração"para aumentar os limites de CPU e/ou memória conforme necessário. |
Uma imagem ausente ou uma configuração inválida fez com que os pods de métricas de estado do NetApp-ci-kube falhassem na inicialização ou se preparassem. Agora o StatefulSet está preso e as alterações de configuração não estão sendo aplicadas aos pods NetApp-CI-kube-State-metrics. |
O StatefulSet está em um "quebrado" estado. Depois de corrigir quaisquer problemas de configuração, salte os pods NetApp-CI-kube-State-metrics. |
Os pods de métricas de estado do NetApp-ci-kube falham ao iniciar depois de executar uma atualização do Operador do Kubernetes, lançando o ErrImagePull (falha ao puxar a imagem). |
Tente redefinir os pods manualmente. |
"Evento descartado como sendo mais antigo do que maxEventAgeSeconds" mensagens estão sendo observadas para o meu cluster Kubernetes em Log Analysis. |
Modifique o Operador agentConfiguration e aumente o event-exporter-maxEventAgeds (ou seja, para 60s), event-exporter-kubeQPS (ou seja, para 100) e event-exporter-kubeBurst (ou seja, para 500). Para obter mais detalhes sobre essas opções de configuração, consulte a "opções de configuração" página. |
Telegraf avisa ou trava por causa de memória bloqueável insuficiente. |
Tente aumentar o limite de memória bloqueável para o Telegraf no sistema operacional/nó subjacente. Se aumentar o limite não for uma opção, modifique a configuração do agente NKMO e defina desprotegido como true. Isto instruirá o Telegraf a não tentar reservar páginas de memória bloqueadas. Embora isso possa representar um risco de segurança, pois segredos descriptografados podem ser trocados para o disco, ele permite a execução em ambientes onde não é possível reservar memória bloqueada. Para obter mais detalhes sobre as opções de configuração desprotegidas, consulte a "opções de configuração"página. |
Vejo mensagens de aviso do Telegraf que se assemelham às seguintes: W! [Inputs.diskio] não é possível reunir o nome do disco para "vdc": Erro ao ler /dev/vdc: nenhum arquivo ou diretório |
Para o Operador de Monitoramento do Kubernetes, essa mensagem de aviso é benigna e pode ser ignorada com segurança. Alternativamente, edite a seção telegraf em AgentConfiguration e defina runDsPrivileged como true. Para obter mais detalhes, consulte "opções de configuração do operador"a . |
Meu pod fluente-bit está falhando com os seguintes erros: [2024 10/16 14/10/16 14 16:16 2024 23:23] [error] [/src/fluent-bit/plugins/in_tail/tail_fs_inotify.c:360 errno.24] muitos arquivos abertos [2024/10/16 14:16:23] [error] falha na inicialização tail,0 [Engine] [input] |
Tente alterar suas configurações fsnotify no cluster: sudo sysctl fs.inotify.max_user_instances (take note of setting) sudo sysctl fs.inotify.max_user_instances=<something larger than current setting> sudo sysctl fs.inotify.max_user_watches (take note of setting) sudo sysctl fs.inotify.max_user_watches=<something larger than current setting> Reinicie o Fluent-bit. Observação: Para tornar essas configurações persistentes entre as reinicializações do nó, você precisa colocar as seguintes linhas em /etc/sysctl.conf fs.inotify.max_user_instances=<something larger than current setting> fs.inotify.max_user_watches=<something larger than current setting> |
Informações adicionais podem ser encontradas na "Suporte" página ou no "Matriz de suporte do Data Collector".