Solução de problemas

Esta página se aplica à Apigee e à Apigee híbrida.

Confira a documentação da Apigee Edge.

Erro 404 (não encontrado) do Istio

A depuração de um erro 404 (não encontrado) no Istio pode ser frustrante. Esperamos que as informações a seguir sejam úteis para você identificar os problemas.

Conflito de gateway com caractere curinga

Só pode haver uma definição de gateway que use um valor de host curinga "*". Se você tiver implantou qualquer outro elemento que inclua um gateway com caractere curinga, as chamadas do cliente falharão com o status 404.

Exemplo:

$ istioctl get gateways
GATEWAY NAME         HOSTS     NAMESPACE   AGE
bookinfo-gateway     *         default     20s
httpbin-gateway      *         default     3s

Nesse caso, você precisa excluir ou alterar um dos gateways em conflito.

Pesquisar onde a rota está falhando

O Istio é como uma cebola (talvez um Ogro), que tem camadas. Uma maneira sistemática de depurar um erro 404 é de dentro para fora.

Carga de trabalho de back-end

Verifique se é possível acessar a carga de trabalho do arquivo secundário:

kubectl exec $WORKLOAD_POD -c istio-proxy -- curl localhost:80/headers

Arquivo secundário de back-end

Defina o endereço do serviço e receba o endereço IP do pod da carga de trabalho.

SERVICE=httpbin.default.svc.cluster.local:80
  POD_IP=$(kubectl get pod $WORKLOAD_POD -o jsonpath='{.status.podIP}')

Acesse a carga de trabalho pelo arquivo secundário:

kubectl exec $WORKLOAD_POD -c istio-proxy -- curl -v http://$SERVICE/headers --resolve "$SERVICE:$POD_IP"

Se o mTLS do Istio estiver ativado:

kubectl exec $WORKLOAD_POD -c istio-proxy -- curl -v https://$SERVICE/headers --resolve "$SERVICE:$POD_IP" --key /etc/certs/key.pem --cert /etc/certs/cert-chain.pem --cacert /etc/certs/root-cert.pem --insecure

Gateway ou arquivo secundário de front-end

Acesse o serviço pelo gateway:

kubectl -n istio-system exec $GATEWAY_POD -- curl -v http://$SERVICE/header

Se o mTLS do Istio estiver ativado:

kubectl -n istio-system exec $GATEWAY_POD -- curl -v https://$SERVICE/headers --key /etc/certs/key.pem --cert /etc/certs/cert-chain.pem --cacert /etc/certs/root-cert.pem --insecure

Análises ausentes

Se você não visualizar as análises na IU do Analytics, considere estas possíveis causas:

O consumo da Apigee pode demorar alguns minutos.
O registro de acesso do gRPC do Envoy não foi configurado corretamente.
O Envoy não consegue acessar o serviço remoto.
Falha no upload do serviço remoto.

Chave de API ausente ou inválida que não foi rejeitada

Se a validação da chave de API não estiver funcionando corretamente, considere estas possíveis causas:

Proxy direto

Verifique a configuração de ext-authz.

Sidecar

Verifique se o listener está configurado para interceptação.
Verifique a configuração de ext-authz.

Solicitações inválidas estão sendo verificadas e permitidas

Serviço remoto configurado para falha na abertura.
Envoy não configurado para verificações RBAC.

Para informações sobre como resolver esses problemas, consulte o seguinte tópico da documentação do Envoy: Autorização externa (em inglês) e consulte as informações sobre a propriedade failure_mode_allow. Essa propriedade permite alterar o comportamento do filtro em caso de erros.

JWT ausente ou inválido que não foi rejeitado

A causa provável é que o filtro JWT do Envoy não está configurado.

Falha em uma chave de API válida

Causas prováveis

O Envoy não consegue acessar o serviço remoto
Suas credenciais não são válidas
Produto da API da Apigee não configurado para destino e ambiente
O Envoy não tem acesso ao produto da API Apigee

Etapas da solução de problemas

Verificar seu produto de API na Apigee

Ele está ativado em seu ambiente (teste x produção)?
O produto precisa estar vinculado ao mesmo ambiente que o serviço remoto.
Ele está vinculado ao destino que você está acessando?
Verifique a seção Apigee remote service targets. Lembre-se de que o nome do serviço precisa ser um nome de host totalmente qualificado. Se for um serviço do Istio, o nome será algo como helloworld.default.svc.cluster.localcode>, que representa o serviço helloworld no namespace default.
O caminho do recurso corresponde à sua solicitação?
Lembre-se de que um caminho como / ou /** corresponderá a qualquer caminho. Também é possível usar os caracteres curinga "*" ou "**" para fazer a correspondência.
Você tem um app do desenvolvedor?
O produto da API precisa estar vinculado a um app do desenvolvedor para verificar as chaves dele.
O transactionConfigType da API Apigee está definido como remotoservice?
Verifique a configuração do produto da API usando a API Apigee Management e confirme se operationConfigType está definido como remoteservice.

Verificar sua solicitação

Você está transmitindo a chave do consumidor no x-api-key header
Exemplo:
```
curl http://localhost/hello -H "x-api-key: wwTcvmHvQ7Dui2qwj43GlKJAOwmo"
```
Você está usando uma boa chave do consumidor?
Verifique se as credenciais do app que você está usando foram aprovadas para seu produto de API.

Verificar os registros do serviço remoto

Inicie o serviço remoto com a geração de registros em debug level. Consulte Como configurar níveis de registro de serviço remoto.
Use a opção -l debug na linha de comando. Por exemplo:
```
apigee-remote-service-envoy -l debug
```

Tente acessar seu destino e verifique os registros

Verifique os registros de uma linha que tenham esta aparência:

Resolve api: helloworld.default.svc.cluster.local, path: /hello, scopes: []
Selected: [helloworld]
Eliminated: [helloworld2 doesn't match path: /hello]

Como configurar níveis de registro do serviço remoto

Com uma sinalização de linha de comando, é possível iniciar o serviço remoto em um dos seguintes modos de depuração, em ordem detalhada, em que debug é mais detalhado e error é o menor:

debug: o modo de geração de registros mais detalhado.
info: o padrão.
warn
error: modo de geração de registros menos detalhado.

Por exemplo, para iniciar o serviço no nível debug:

apigee-remote-service-envoy -l debug