Summary

Three related changes to make monitor sync more resilient when the destination monitor API is under load, and to make failures easier to diagnose from logs alone.

1. ResourceConfig.max_concurrent — general per-resource-type concurrency cap

New optional field on ResourceConfig. When set to a positive int N, installs an asyncio.Semaphore that limits _apply_resource_cb to at most N in-flight creates/updates of that resource type — independent of the global --max-workers. Left unset by default on every resource; callers opt in per-resource-type when they need tighter throttling than the global worker pool provides.

Motivating shape: at high --max-workers values, the monitor endpoint can be hit hard enough that the destination's edge/proxy layer starts terminating connections before the app finishes responding. A per-resource-type cap lets an operator throttle just monitors (or dashboards, or whichever endpoint they observe struggling) without slowing the whole sync.

2. HTTP _OVERLOAD_STATUSES retry backoff in custom_client.request_with_retry

For HTTP 502 / 503 / 504 / 512, retries now use a 30s / 60s / 120s schedule and honor Retry-After when the server sends one. Previously these codes went through the generic retry_count * 5s schedule (0 / 5 / 10 / 15s), which is too tight to let an overloaded upstream drain — retries refill the queue as fast as it clears.

429 keeps its existing dedicated x-ratelimit-reset path. The retry_timeout total budget still applies. CustomClient.overload_status_counter is exposed so callers can emit a metric on these retry classes if they want long-term dashboarding.

3. Structured error log on monitor create/update failures

monitors.py now emits a WARNING on any 4xx / 5xx create_resource / update_resource failure containing:

• monitor id
• monitor type (metric alert / rum alert / query alert / etc.)
• outbound query string, truncated at 2000 chars with any @application.id: token preserved inline

Previously only the destination's response body was logged (e.g. 400 Bad Request - {"errors":["Invalid query: Check for invalid tags or facets in your query."]}), which doesn't identify WHICH monitor query the validator rejected. The new log line lets an operator jump straight from the failure to the offending query without cross-referencing source-org state.

No behavior change for callers that

• don't set max_concurrent on any resource, AND
• don't hit HTTP {502, 503, 504, 512}

Monitor error logging is additive (WARN-level, doesn't change return values or retry behavior).

Test plan

• pytest tests/unit/ — 781 passing (757 pre-existing + 24 new).
• New test files: test_max_concurrent_semaphore.py, test_overload_backoff.py, test_monitor_error_logging.py.
• Integration cassette re-record if needed.