AI API endpoints не похожи на обычные REST API. Они медленные (2-30 секунд на ответ), дорогие (платишь за tokens), и подвержены rate limiting. Если ваше приложение полагается на OpenAI или Anthropic API, downtime на их стороне означает downtime вашего приложения. И вы узнаете об этом из error'ов в production, если не мониторите.
Мониторинг AI endpoint'ов отличается от мониторинга обычных API. Вам нужно проверять не просто "отвечает ли эндпоинт", но и "обработал ли он мой prompt", "выполнил ли ответ валидацию", "сколько токен'ов мне это стоило". И из-за высокой стоимости, вам также нужно мониторить costs и rate limits перед тем, как они с вами разлетятся.
Почему AI API нужна специальная мониторинг
Медленность
OpenAI GPT-4 обычно отвечает за 5-10 секунд. Иногда за 30 секунд. Если ваш HTTP timeout установлен на 5 секунд (стандарт для обычных API), вы будете получать timeout errors постоянно, даже когда API работает. Нужно установить timeout на 60+ секунд и отслеживать actual latency, чтобы обнаружить замедления.
Стоимость
GPT-4 стоит ~$0.015 за 1000 input tokens и ~$0.06 за 1000 output tokens. Если ваша мониторинг проверка стоит $0.05, а вы проверяете каждую минуту, это $72 в месяц только на мониторинг. Нужна cost tracking, чтобы не пустить затраты из под контроля. И нужна валидация ответов, чтобы убедиться, что API не wasting tokens'ы на ошибки.
Rate limiting
OpenAI ограничивает requests по плану. Free tier: 3 requests/minute. Paid: 3500 requests/minute. Если вы превышаете лимит, API возвращает 429 Too Many Requests. Это не downtime, но это failure для вашего приложения. Нужно мониторить rate limit'ы и alert'ить когда приближаетесь к лимиту.
Quality of response
API может ответить, но ответ может быть garbage. Например, prompt: "Generate me a SQL query to fetch users", ответ: "I can't help with that". Эндпоинт технически работает (возвращает 200), но ответ бесполезен. Нужна keyword валидация: проверять, что ответ содержит expected text'ы (например, "SELECT").
Мониторинг OpenAI API
Health check pattern
OpenAI не предоставляет /health endpoint. Поэтому нужно отправить реальный API call:
Simple prompt: curl -X POST https://api.openai.com/v1/chat/completions -H "Authorization: Bearer $OPENAI_API_KEY" -d '{"model": "gpt-4", "messages": [{"role": "user", "content": "Respond with OK"}], "max_tokens": 10}'
Expected response structure: JSON с "choices" array, первый choice имеет "message" объект с "content". Содержимое должно быть примерно "OK" или похожее.
Keyword validation: ответ должен содержать "OK" (или варианты: "ok", "Okay"). Если ответ "I can't process this", это failure, хоть HTTP 200.
Response time assert: максимум 30 секунд. Если медленнее, something is wrong (either overloaded OpenAI или ваша network).
Frequency: каждые 10 минут (не каждую минуту, иначе стоимость превысит пользу мониторинга). Или используйте separate, дешёвый model (GPT-3.5) для health checks.
Cost optimization: используйте GPT-3.5 вместо GPT-4 для health checks. Примерно в 10 раз дешевле. Сделайте check очень простым (max_tokens=10) чтобы минимизировать tokens.
Мониторинг rate limits
OpenAI возвращает headers с информацией о rate limit'ах. Проверяйте эти headers и alert'ьте, если приближаетесь к лимиту:
Response headers: x-ratelimit-limit-requests, x-ratelimit-remaining-requests, x-ratelimit-remaining-tokens. Парсьте эти и alert'ьте, если remaining \< 10% of limit.
Example: если limit = 1000 requests/minute, alert когда remaining \<= 100. Это даёт вам время среагировать и уменьшить traffic.
Мониторинг Anthropic Claude API
Anthropic выполняет обещания о частоте работы и consistency лучше, чем OpenAI (в целом). Но мониторинг похож:
API endpoint: https://api.anthropic.com/v1/messages
Simple check: POST с простым prompt, max_tokens=10, ожидаем response с "content" array.
Response time: обычно 2-8 секунд (быстрее, чем OpenAI). Если вдруг 20+ сек, алерт.
Rate limits: Anthropic также имеет rate limits по requests и tokens. Проверяйте headers.
Cost: немного дешевле, чем GPT-4, но всё ещё нужна мониторинг.
Мониторинг custom/self-hosted LLM'ов
Если вы self-hosting'ите модель (llama, mistral, др.), мониторинг становится ещё важнее, потому что это ваша ответственность.
Endpoint format: обычно OpenAI-compatible API (если используете vLLM или Text Generation WebUI). Проверяйте POST /v1/chat/completions.
Timeout: зависит от model size. Mistral 7B: 1-3 сек. Llama 70B: 10-30 сек. Установите timeout с запасом.
Memory monitoring: большие модели могут OOM (out of memory). Monitor VRAM usage на хосте — если VRAM near 100%, model скоро crashed'ит.
Concurrency: сколько одновременных requests может обработать? Если больше людей используют, model может queue'ить requests и respond медленнее.
Keyword validation: очень важна. Самохостный model может быть uncalibrated и отдавать бесполезные ответы. Validate, что response содержит expected text'ы.
AtomPing AI Agent Probe
AtomPing имеет встроенный AI Agent Probe check type для мониторинга AI endpoints. Вместо того чтобы писать custom скрипты, вы настраиваете:
Provider: выбираете Anthropic, OpenAI, или custom endpoint.
Endpoint URL: если custom endpoint, даёте адрес.
API Key: зашифрована и хранится securely. Никогда не логируется, только используется в проверке.
Prompt: простой prompt для проверки. Пример: "What is 2+2?"
Expected response: keyword'ы для валидации. Пример: "4" или "four".
Model & tokens: какой model использовать (gpt-4, claude-3, др.), max_tokens для экономии.
Frequency: как часто проверять. Рекомендуется 10+ минут для экономии.
Результаты: response time, token count, cost per check, валидация ответа. Всё в одном dashboard.
Cost tracking
Если вы используете дорогие models (GPT-4, claude-opus), нужно следить за costs. AtomPing AI Cost Monitoring интегрируется с OpenAI и Anthropic API для отслеживания использования в реальном времени.
Setup: даёте readonly API key от OpenAI/Anthropic, AtomPing pulls использование раз в 15 минут. Никогда не отправляет requests от вашего имени, только reads usage.
Tracking: видите breakdown по model'ам (gpt-4, gpt-3.5, claude-opus, др.), по дню, по недели.
Alerts: настраиваете threshold'ы ($100/день, $500/неделю) и alert'ьте, если превышает. Ловите runaway costs ДО того как биллинг удивит вас в конце месяца.
Multiple providers: если используете OpenAI и Anthropic одновременно, видите total costs и breakdown.
Response time baselines
Когда вы мониторите AI endpoint, нужно знать, что нормально, чтобы обнаружить abnormal.
OpenAI GPT-4 (streaming): 500ms-2s до first token, потом ~50ms per token. Total per 100-token response: 5-10 seconds.
OpenAI GPT-3.5: 200ms-1s до first token. Total: 2-5 seconds per response.
Anthropic Claude: 500ms-2s до first token. Total: 3-8 seconds per response.
Self-hosted small (7B): 100-500ms. Total: 1-3 seconds.
Self-hosted large (70B+): 2-5s до first token. Total: 10-30 seconds.
Red flags: если response time внезапно 3x медленнее обычного, API перегружена или есть network issues. Alert на 50% deviation от baseline.
Alerting strategy
Critical alerts: API completely down (returns 5xx или не отвечает), или keyword валидация fails (ответ не содержит expected text). Отправляйте в Slack/email немедленно.
Warning alerts: response time > 2x baseline, или approaching rate limit. Отправляйте в Slack, но не срочно.
Info alerts: cost tracking (daily costs breached threshold), или status page updates от провайдера. Email digest раз в день.
Mute during maintenance: OpenAI иногда делает scheduled maintenance. Можете временно отключить alerts или снизить sensitivity.
Мониторинг provider'а status page
OpenAI status page: status.openai.com
Anthropic status: status.anthropic.com
Большинство поддерживают RSS feed'ы или webhook'и. Мониторинг status page отдельно от health checks полезна, потому что:
Planned maintenance: провайдер предупреждает заранее ("Maintenance on Sunday 10pm UTC"). Вы можете alert клиентам и отключить alerts на это время.
Degradation: "API responding slowly due to high load". Your health check может pass (API отвечает), но status page скажет, что есть problem.
Regional issues: "Issues affecting users in EU". Ваша health check в US может pass, но EU users будут страдать.
Практический пример: GPT-4 мониторинг
Setup в AtomPing:
Check type: AI Agent Probe
Provider: OpenAI
Model: gpt-3.5-turbo (cheaper for health checks)
Prompt: "Respond with OK"
Expected response: "OK"
Max tokens: 5
Timeout: 30 seconds
Frequency: every 15 minutes
Alerts: Slack #ai-team when fails
Cost: примерно $0.001 за check (gpt-3.5, 5 output tokens). 4 checks в час, 96 в день = ~$0.10 в день = ~$3 в месяц на мониторинг. Стоит экономить на production breakage.
Связанные материалы
API Monitoring Guide — мониторинг обычных API endpoints
Response Time Monitoring — обнаружение performance degradation
Health Check Endpoint Design — как создавать good health checks
Complete Uptime Monitoring Guide — общие основы мониторинга
Webhook Monitoring — мониторинг асинхронных callback'ов
AI Cost Monitoring — отслеживание расходов на API
FAQ
What's the difference between monitoring OpenAI API availability vs rate limits?
Availability: is the endpoint up and responding? Rate limits: how many requests can you make per minute/hour/month? Both matter. Endpoint can be up but rate-limited (429 response), meaning your application stops working. Monitor both: health check for availability, and token counting/cost tracking for rate limit warnings.
How do I monitor custom/self-hosted LLM endpoints?
Same as any API: HTTP health check with keyword validation. Send a simple prompt (e.g., 'What is 2+2?'), validate response contains expected text (e.g., 'four' or '4'). Check response time (LLM endpoints are slow—expect 500ms to 30s depending on model size). Monitor at 5-10 minute intervals to catch crashes without overwhelming the endpoint.
Why does my AI API check fail intermittently?
Three common causes: (1) Rate limiting—service is up but rejecting requests due to quota, (2) Model loading—large models take 10-30s to load, timing out your check, (3) Regional latency—some regions to the API endpoint are slow. Use longer timeouts (30s+), implement exponential backoff, and monitor from multiple regions to detect patterns.
How do I validate that an LLM actually processed my prompt?
Keyword-based response validation: send a test prompt with a unique word or phrase, check that response contains it. Example: send prompt 'Respond with TESTWORD12345', validate response contains 'TESTWORD12345'. This ensures the model actually processed your request, not just returned a cached/default response.
What's a normal response time for different LLM API endpoints?
OpenAI GPT-4: 2-10 seconds per response. Anthropic Claude: 2-8 seconds. Self-hosted small models (3-7B): 500ms-3s. Self-hosted large models (30B+): 10-30s. These are TTFB (time to first byte). Set your timeout and alert threshold accordingly. If Claude suddenly takes 30s, something is wrong—alert.
Should I monitor the status page of my LLM provider separately?
Yes. OpenAI status page (status.openai.com), Anthropic status page, etc. These are public and update when there are issues. Monitor the public status page via RSS feed or webhook, so your team sees outages even if your application doesn't try to call the API. Stripe uses this pattern—many SaaS apps monitor their provider's status page independently.