Estás viendo la documentación de Apigee Edge.
Consulta la documentación de Apigee X.
Las siguientes son preguntas frecuentes:
- Tengo muchos proxies de API. ¿Cuáles son algunos enfoques recomendados para configurar alertas en todos mis proxies de API?
- ¿Qué roles pueden acceder a la supervisión de API?
- ¿Por qué no veo todos los proxies de API que aparecen en la página Recientes?
- ¿Por qué no veo gráficos de latencia en las Rutas?
- Los registros son útiles para identificar los códigos de estado que generan errores, pero ¿cómo puedo identificar los ID de desarrollador que generan las llamadas?
- ¿Puedo supervisar una cadena de proxy?
- ¿Por qué veo el mensaje "no establecido" en los paneles?
- ¿API Monitoring está disponible en la IU clásica o en Edge para la nube privada?
- ¿Qué es una guía?
- ¿Cómo puedo manejar los códigos de error HTTP 429?
Tengo muchos proxies de API. ¿Cuáles son algunos enfoques recomendados para configurar alertas en todos mis proxies de API?
Apigee recomienda los siguientes enfoques:
- Primero, configure alertas para cualquier proxy de API con un umbral específico. Por ejemplo, una tasa de error 4xx del 10% durante 5 minutos. Configure las notificaciones y consulte la página Historial de alertas para supervisar las alertas que se activan. Configura alertas y notificaciones adicionales para proxies de API y servicios de destino específicos. Sigue definiendo mejor las alertas y notificaciones según tus observaciones.
- Pídeles a los equipos responsables de desarrollar APIs que recomienden los porcentajes de errores y los umbrales de latencia al equipo de Operaciones responsable de configurar alertas.
¿Qué roles pueden acceder a la supervisión de API?
Consulta Acerca de las funciones de API Monitoring.¿Por qué no veo todos los proxies de API en la página Recientes?
El panel Recientes solo muestra los proxies de API que tuvieron tráfico en el pasado reciente. No muestra todos los proxies de API de tu organización. El panel de Cronograma te permite ver los datos de todos los proxies de API.¿Por qué no veo gráficos de latencia en Rutas?
Los gráficos de latencia se muestran en el cronograma solo si selecciona una región y un proxy de API, y el intervalo de tiempo no es superior a 7 días.Los registros son útiles para identificar los códigos de estado que generan errores, pero ¿cómo puedo identificar los ID de desarrollador que generan las llamadas?
Los ID de desarrollador no se incluyen en los registros de API Monitoring. Para recuperar los ID de desarrollador, puede ejecutar un informe personalizado.¿Puedo supervisar una cadena de proxy?
Puedes usar un proxy de API como extremo de destino de otro proxy de API para conectar de manera efectiva los dos proxies en una cadena de proxy. Sin embargo, API Monitoring solo registra las solicitudes al primer proxy de la cadena, no al proxy de API que se usa como destino. Consulta Cómo encadenar proxies de API para obtener más información.¿Por qué veo "no establecido" en los paneles?
Si el proxy de la API, la fuente de error, el código de error o la política de errores no tienen un valor o no se pueden determinar, el panel mostrará "not set" como origen. Estos son algunos ejemplos de situaciones que pueden dar como resultado "no establecido":
- Errores relacionados con el cliente
- Códigos de error de HTTP que se anulan con una respuesta exitosa
- Códigos de estado HTTP 2xx (ya que no suelen generar códigos de error)
Para obtener más información sobre la opción "Sin configurar", consulte ¿Qué significa el valor "(no establecido)" de una entidad de análisis?
¿Está disponible API Monitoring en la IU clásica o en Edge para la nube privada?
Actualmente, Apigee API Monitoring solo está disponible para los clientes de Cloud Enterprise de Apigee Edge que usan la IU nueva de Edge.
La supervisión de la API de Apigee no está disponible en la IU clásica de Edge ni en Edge para la nube privada.
¿Qué es una guía?
Cuando configuras una alerta, en el campo de la guía, proporcionas una descripción breve de las acciones recomendadas para resolver las alertas cuando se activan. También puedes especificar un vínculo a tu wiki o página de la comunidad interna donde hagas referencia a las prácticas recomendadas. La información de este campo se incluirá en la notificación.¿Cómo puedo manejar los códigos de error HTTP 429?
La política de cuotas perimetral y la política de SpikeArrest emiten un código de error HTTP 429 cuando se supera una cuota (política de cuotas) o se excede el límite de frecuencia (política de SpikeArrest).Sin embargo, en el panel de alertas, no puede definir una alerta para un código de error HTTP 429. En su lugar, establece una condición de alerta de la Política de administración de tráfico > Cuota > Incumplimiento de la cuota, como se muestra a continuación, o la Política de administración de tráfico > Spike Arrest > Incumplimiento de SpikeArrest:
