Object Storage Service:Monitoramento, diagnóstico e solução de problemas

Utilize o monitoramento, os logs do OSS e ferramentas de terceiros para atingir os seguintes objetivos:

• Acompanhe a integridade e o desempenho do OSS em tempo real com notificações de alerta.

• Obtenha métodos e ferramentas eficazes para localizar problemas.

• Resolva problemas no OSS utilizando os guias de solução de problemas deste tópico.

Este tópico aborda:

• Service monitoring: Use o monitoramento do OSS para acompanhar a integridade e o desempenho do service.

• Tracking and diagnosis: Diagnostique problemas correlacionando dados de monitoramento e arquivos de log.

• Troubleshooting: Cenários comuns de problemas e métodos de resolução.

Monitoramento do service

• Monitore a integridade geral

  • Disponibilidade e taxa de requisições válidas

    A disponibilidade e a taxa de requisições válidas medem a estabilidade do sistema e a atividade do usuário. Uma taxa abaixo de 100% indica falhas nas requisições.

    Essa taxa pode cair temporariamente abaixo de 100% durante otimizações do sistema, como migração de partição. O mecanismo de nova tentativa do SDK do OSS lida automaticamente com essas falhas intermitentes.

    Se a taxa estiver abaixo de 100%, verifique as estatísticas de distribuição de requisições ou os detalhes do status das requisições para identificar os tipos e as causas dos erros.

    Em alguns cenários, é esperado que a taxa fique abaixo de 100%. Por exemplo, verificar se um objeto existe retorna um erro 404 caso o objeto não seja encontrado.

    Configure regras de alerta para acionar notificações quando a taxa cair abaixo do seu limiar.

  • Total de requisições e requisições válidas

    Esta métrica reflete o status do sistema pelo volume total de acessos. Uma discrepância entre requisições válidas e totais indica falhas.

    Monitore flutuações na contagem de requisições, especialmente picos ou quedas repentinas. Configure regras de alerta no Alert service user guide para receber notificações em tempo hábil.

  • Estatísticas de distribuição de status de requisição

    Quando a disponibilidade ou a taxa de requisições válidas estiver abaixo de 100% (ou quando as requisições válidas não corresponderem ao total), visualize a distribuição de status das requisições para determinar os tipos de erro. OSS monitoring metrics reference.

• Monitore os detalhes do status das requisições

  Os detalhes do status das requisições oferecem uma visão mais granular do que as estatísticas de distribuição, permitindo monitorar tipos específicos de requisição em profundidade.

• Monitore o desempenho

  O service de monitoramento fornece as seguintes métricas de desempenho:

  • Latência média, incluindo latência média de ponta a ponta (E2E) e latência média do servidor

    A latência E2E inclui o processamento da requisição, a transmissão da resposta e o tempo de rede. A latência do servidor abrange apenas o processamento no lado do servidor. Se a latência E2E apresentar picos, mas a latência do servidor permanecer estável, o problema provavelmente está relacionado à rede, e não a uma falha no sistema do OSS.

  • Latência máxima, incluindo latência E2E máxima e latência máxima do servidor

  • Classificação de operações de requisições bem-sucedidas

  • Tráfego

    As métricas de tráfego mostram o uso de recursos de rede no nível de usuário ou bucket em cenários de rede pública, rede privada, back-to-origin de CDN e replicação entre regiões.

  Todas as métricas, exceto tráfego, são categorizadas por tipo de operação de API:

  • GetObject

  • HeadObject

  • PutObject

  • PostObject

  • AppendObject

  • UploadPart

  • UploadPartCopy

  A classificação de operações de requisições bem-sucedidas também monitora a contagem de requisições para:

  • DeleteObject

  • DeleteObjects

  Fique atento a mudanças repentinas nas métricas de desempenho, como picos de latência ou desvios sustentados da linha de base. Configure regras de alerta para notificar a equipe quando as métricas ultrapassarem os limiares definidos.

• Monitore a medição

  Atualmente, o monitoramento do OSS suporta medição para tamanho do bucket, tráfego de saída público, requisições do tipo Put e requisições do tipo Get. Não há suporte para tráfego de saída de replicação entre regiões, tráfego de saída de CDN, regras de alerta e recuperação de medição via OpenAPI.

  O OSS coleta dados de medição com granularidade horária. Utilize a visualização de monitoramento do bucket para analisar tendências de uso de recursos e estimar custos.

  O OSS também fornece estatísticas mensais de consumo de recursos nos níveis de usuário e bucket, atualizadas a cada hora.

  Os itens faturáveis e os métodos de faturamento do OSS estão descritos em Metering and billable items.

  Nota

  Os dados de medição no service de monitoramento são fornecidos com base no melhor esforço e podem diferir da sua fatura real. Consulte o User Center para obter informações precisas de faturamento.

Rastreamento e diagnóstico

• Diagnostique problemas

  • Diagnostique o desempenho

    Estabeleça uma linha de base de desempenho para o seu cenário de negócios. Problemas de desempenho podem decorrer da carga do service OSS, da configuração TCP do cliente ou de gargalos de rede. Use as métricas de monitoramento para identificar as causas raiz e, em seguida, verifique os logs para obter detalhes.

    Em resumo: defina uma linha de base, use métricas de monitoramento para restringir a causa e examine os logs para obter detalhes.

  • Diagnostique erros

    Quando uma requisição falha, o cliente recebe uma mensagem de erro e o service de monitoramento registra o tipo de erro. Verifique os logs do lado do servidor, do lado do cliente e da rede para obter detalhes. Os códigos de status HTTP e os códigos de erro do OSS indicam o motivo da falha.

    Os detalhes das respostas de erro estão documentados em OSS error responses.

  • Use o recurso de logging

    O OSS oferece logging no lado do servidor para registrar logs detalhados das requisições.

    Ative esse recurso seguindo Configure logging e Configure access logging.

  • Use ferramentas de logging de rede

    Quando os logs do lado do servidor não tiverem detalhes suficientes, capture o tráfego entre cliente e servidor com ferramentas de logging de rede. Você também pode usar o Simple Log Service para investigar. Wireshark é uma ferramenta comum para visualizar dados de protocolo no nível de pacote. Instale o Wireshark. Use Wireshark.

• Rastreamento e diagnóstico E2E

  Correlacione logs do cliente, da rede e do lado do servidor para identificar as causas raiz. O OSS atribui um RequestID exclusivo a cada requisição para correlacionar logs. Use carimbos de data/hora para restringir o escopo dos logs e identificar eventos relacionados.

  • RequestID

    O RequestID aparece em diferentes campos de log:

    • Nos logs do lado do servidor do OSS, o RequestID está na coluna "Request ID".

    • Em rastreamentos de rede (como fluxos de dados capturados pelo Wireshark), o RequestID aparece como o valor do cabeçalho x-oss-request-id na mensagem de resposta.

    • Na versão mais recente do Java SDK, chame getRequestId no objeto Result para requisições bem-sucedidas ou em OSSException para requisições com falha.

  • Carimbo de data/hora

    Ao pesquisar logs do lado do servidor usando carimbos de data/hora do lado do cliente, adicione ou subtraia 15 minutos para compensar possíveis diferenças de horário.

Solução de problemas

• Problemas comuns de desempenho

  • Alta latência média de ponta a ponta (E2E) com baixa latência média do servidor

    As possíveis causas incluem:

    • Resposta lenta da aplicação cliente

      • Número limitado de conexões ou threads disponíveis

        • Use comandos relevantes para verificar o status das conexões do sistema e ajuste os parâmetros do kernel.

        • Verifique se há gargalos de recursos no lado do cliente, aumente o número de threads simultâneas conforme necessário e otimize o código do cliente.

      • Recursos insuficientes, como CPU, memória ou largura de banda de rede

        Utilize uma ferramenta de monitoramento de recursos para verificar gargalos. Otimize o código ou escale horizontalmente os recursos.

    • Problemas de rede

      Utilize o Wireshark para investigar problemas de rede.

    • Baixa latência média E2E e baixa latência média do servidor, mas alta latência de requisição do cliente

      Uma alta latência no lado do cliente geralmente indica um atraso antes que a requisição chegue ao servidor. Investigue o motivo desse atraso.

      Possíveis causas:

      • Número limitado de conexões ou threads disponíveis

        • Verifique o status das conexões do sistema e ajuste os parâmetros do kernel.

        • Verifique se há gargalos de recursos no lado do cliente, aumente o número de threads simultâneas conforme necessário e otimize o código do cliente.

      • A requisição do cliente é tentada novamente várias vezes

        Verifique os logs do cliente para investigar o motivo das novas tentativas. Utilize também o Wireshark para investigar problemas de rede.

        • Analise os logs do cliente. Logs detalhados indicam se houve uma nova tentativa. Por exemplo, no OSS Java SDK, pesquise pelas seguintes mensagens de log no nível WARN ou INFO. A presença desses logs indica que pode ter ocorrido uma nova tentativa.

          [Server]Unable to execute HTTP request:
            or
            [Client]Unable to execute HTTP request:

        • Se o nível de log do cliente estiver definido como DEBUG, pesquise pela seguinte mensagem de log no OSS Java SDK. Se essa mensagem existir, ocorreu uma nova tentativa.

          Retrying on

    • Alta latência média do servidor

      Possíveis causas de alta latência do servidor para uploads ou downloads:

      • Muitos clientes acessam frequentemente o mesmo objeto pequeno

        Verifique os logs do lado do servidor e considere ativar o CDN ou ajustar as permissões de acesso.

      • Fatores internos do sistema

        Forneça os logs do cliente e entre em contato com o suporte técnico para obter assistência.

    • Erros do lado do servidor

      • Aumentos temporários

        Ajuste a política de nova tentativa do cliente e utilize um mecanismo de backoff adequado.

      • Aumento permanente de erros

        Forneça os logs do cliente e entre em contato com o suporte técnico para obter assistência.

    • Erros de rede

      Um erro de rede (HTTP 499) ocorre quando o cliente encerra a conexão antes que o servidor retorne uma resposta. Causas comuns:

      • O servidor detecta uma conexão inativa antes de processar a requisição.

      • O cliente fecha a conexão enquanto o servidor ainda está processando a requisição.

      Se o cliente fechar ativamente a conexão, investigue o código do lado do cliente. Se a conexão de rede for perdida, use o Wireshark para diagnosticar problemas de conectividade.

    • Erros do lado do cliente

      • Aumento nas requisições com erro de autorização do cliente

        Causas comuns para o aumento de erros 403:

        • Nome de domínio do bucket incorreto

          • Se você acessar o bucket diretamente usando um nome de domínio de terceiro ou segundo nível, o bucket pode não estar na região indicada por esse nome de domínio. Por exemplo, um bucket na região China (Hangzhou) acessado via Bucket.oss-cn-shanghai.aliyuncs.com. Verifique a região do bucket e corrija o nome de domínio.

          • Se a aceleração de CDN estiver ativada, verifique se o domínio de origem do CDN corresponde ao nome de domínio de terceiro nível do seu bucket.

          • Um erro 403 de um cliente JavaScript geralmente indica um problema de configuração de CORS. Verifique as configurações de CORS do seu bucket e corrija-as conforme necessário. Cross-origin resource sharing.

        • Problemas de controle de acesso

          • Ao usar um AccessKey primário, verifique se ele está configurado corretamente e é válido.

          • Para acesso de usuário RAM, verifique se o AccessKey correto está sendo usado e se o usuário tem permissões para as operações necessárias.

          • Para acesso com token temporário STS, verifique se o token não expirou. Solicite um novo token, se necessário.

          • Se o controle de acesso estiver configurado, verifique se você possui as permissões necessárias para o bucket ou objeto de destino.

        • Expiração de URL

          Para acesso via URL assinada, um erro 403 repentino geralmente significa que a URL expirou.

        • Ferramentas de desenvolvedor do OSS (OSS FTP, ossbrowser, cliente do console OSS) podem retornar erros 403 para usuários RAM. Verifique se o AccessKey está correto e se o usuário RAM possui as permissões GetService e outras necessárias.

      • Aumento nas requisições com erro de "recurso não encontrado" do cliente

        Um erro 404 indica que o recurso solicitado não existe. Causas comuns para o aumento de erros 404:

        • Lógica da aplicação que verifica a existência de objetos (por exemplo, doesObjectExist no Java SDK) gera um valor de retorno false quando o objeto não é encontrado, mas o servidor gera uma requisição 404. Esse comportamento é esperado.

        • O objeto foi excluído pelo cliente ou por outro processo. Verifique os logs do lado do servidor para encontrar operações de exclusão no objeto.

        • Perda de pacotes de rede aciona uma nova tentativa. Por exemplo, uma resposta de exclusão bem-sucedida é perdida, fazendo com que o cliente tente novamente e receba um erro 404. Identifique erros 404 causados pela rede verificando tanto os logs do cliente quanto os do servidor:

          • Verifique os logs da aplicação cliente para encontrar requisições de nova tentativa.

          • Verifique os logs do lado do servidor para determinar se existem duas operações de exclusão para o objeto e se a primeira operação de exclusão retornou um código de status HTTP na faixa 2xx.

      • Baixa taxa de requisições válidas e alto número de outros erros do cliente

        A taxa de requisições válidas é a proporção de respostas 2xx/3xx em relação ao total de requisições. "Outros erros do cliente" excluem erros 5xx (servidor), 499 (rede), 403 (autorização), 404 (não encontrado) e 408 ou 400 com código de erro do OSS RequestTimeout (timeout).

        Verifique os logs do lado do servidor para identificar os tipos de erro e use OSS error responses para determinar as causas e resolver os problemas.

      • Aumento anormal na capacidade de armazenamento

        Se a capacidade de armazenamento aumentar anormalmente sem um aumento correspondente nos uploads, o problema geralmente está relacionado à limpeza. Investigue sob dois aspectos:

        • A aplicação cliente usa um processo periódico de limpeza. Para investigar:

          1. Verifique se a taxa de requisições válidas diminuiu, o que pode indicar falhas nas requisições de exclusão que impedem a limpeza.

          2. Verifique os tipos de requisição com erro para identificar a causa. Por exemplo, o token STS usado para limpeza pode ter expirado.

        • Regras de ciclo de vida lidam com a limpeza automatizada. Verifique se as regras de ciclo de vida do bucket estão configuradas conforme esperado via console ou API. Verifique os logs do lado do servidor para obter detalhes sobre modificações. Se as regras estiverem corretas, mas não forem aplicadas, entre em contato com o administrador do sistema OSS.

      • Outros problemas do service de armazenamento

        Para problemas não cobertos acima, use os seguintes métodos de diagnóstico:

        1. Verifique o service de monitoramento do OSS para detectar desvios do comportamento da linha de base. Determine se o problema é temporário ou permanente e quais operações são afetadas.

        2. Pesquise mensagens de erro relevantes nos logs do lado do servidor usando os dados de monitoramento como orientação.

        3. Se os logs do lado do servidor forem insuficientes, examine os logs do cliente ou use o Wireshark para investigar problemas de rede.