Planetscale Traffic Control Recommendations

planetscale/skills/planetscale-traffic-control-recommendations

作者 planetscale999045cfbad7无许可证133 个星标收录于 2026年10月8日更新于 2026年10月8日仓库昨天更新

Build a safe recommendation plan for PlanetScale Postgres Database Traffic Control budgets and rules without applying them.

仅含说明DevOps & Cloud
AI 生成的概览

为 PlanetScale Postgres 流量控制预算和规则提供建议方案,仅做规划,不实际应用。

功能
该技能为 PlanetScale Postgres 数据库流量控制预算和规则生成建议方案。它会检查现有预算、查询模式、查询标签、应用路由、作业以及事件情况,然后针对代理、导出、后台作业、第三方集成和已知高开销查询指纹等流量切片提出预算建议。每项建议包含目标分支、模式、规则类型、理由、安全风险、测试计划、回滚计划和审批要求,并在结尾声明未创建、更新、删除或强制执行任何预算或规则。
适用场景
当你需要规划保护 PlanetScale Postgres 关键流量免受失控查询、流量高峰、批处理作业、代理或第三方集成影响的护栏时使用。它适用于提出并评审预算建议而非直接应用的咨询场景。仅适用于 PlanetScale Postgres。
运行要求
需要 PlanetScale Postgres,并能查看现有预算和规则、Insights 查询模式、查询标签、应用路由和作业以及事件或异常信息。该技能不包含脚本,也不会做任何更改;建议需经操作人员批准后才能应用。

Database Traffic Control recommendations

Purpose

For PlanetScale Postgres, recommend Traffic Control budgets and rules that protect critical traffic from runaway queries, traffic spikes, batch jobs, agents, and third-party integrations. Do not create or change budgets without approval.

Preconditions

Run this skill only for PlanetScale Postgres.

Before recommending rules, inspect:

  • Current budgets and rules.
  • Insights query patterns.
  • Current query tags.
  • Application routes and jobs.
  • Known critical paths.
  • Known expensive non-critical paths.
  • Active incidents or recent anomalies.

If query tags are missing, recommend tagging first unless a fingerprint-specific rule is clearly needed for an immediate known offender.

Candidate traffic slices

Look for:

  • Exports.
  • Reports.
  • Search endpoints.
  • Admin dashboards.
  • Backfills.
  • Workers and queues.
  • Webhooks from third-party systems.
  • BI tools.
  • Agent-generated read queries.
  • High-frequency polling.
  • Known expensive query fingerprints.
  • Customer-triggered endpoints with high variance.

Budget modes

Recommend in this order:

  1. warn mode first for normal rollout.
  2. Observe warnings and false positives.
  3. Tune tags, fingerprints, and thresholds.
  4. Move to enforce only with explicit approval and an emergency rollback path.

Do not recommend starting directly in enforce unless there is an active incident and the operator explicitly asks for emergency mitigation.

Rule strategy

Prefer tag-based rules when tags are stable and bounded:

  • source=agent
  • source=bi
  • feature=export
  • feature=report
  • route=/admin/reports
  • job=DailyBackfill
  • service=analytics-worker

Use fingerprint rules when:

  • A specific known query pattern is dangerous.
  • Tagging is missing or unreliable.
  • The query source is hard to attribute.

Use a separate budget for each materially different traffic class.

Do not combine unrelated traffic in one budget because it hides who is consuming the budget.

Suggested default budgets

Use these as recommendation patterns, not as values to apply blindly.

Agent budget

Target: queries tagged source=agent or source=mcp.

Intent: prevent agents from starving application traffic.

Mode: start in warn.

Recommendation: agents should prefer replicas and read-only scopes. Writes require human approval.

Export/reporting budget

Target: feature=export, feature=report, or specific report route/job.

Intent: keep customer-triggered reporting from consuming all database resources.

Mode: start in warn; consider enforce after observation.

Background job budget

Target: worker service, queue, or job tags.

Intent: prevent backfills and retries from starving interactive traffic.

Mode: warn first; enforce only after confirming queue backpressure behavior.

Third-party integration budget

Target: source=integration, partner-specific bounded tags, or route templates for inbound integration calls.

Intent: isolate unpredictable partner behavior.

Mode: warn first.

Known fingerprint budget

Target: specific expensive query fingerprint.

Intent: contain a known pathological query while code or schema fixes are developed.

Mode: warn first unless emergency.

“Each tag value” strategy

When PlanetScale supports applying a budget separately for each unique value of a selected tag, recommend it for bounded tags such as:

  • application
  • service
  • route when normalized
  • job
  • feature
  • source

Do not recommend it for unbounded tags such as user IDs, request IDs, raw tenant IDs, emails, UUIDs, or raw URLs.

Limits and caveats to include

Every recommendation must explain:

  • Traffic Control limits resource use; it does not replace query tuning.
  • It is not a web application firewall.
  • It does not replace application-level rate limits.
  • Limits are guardrails, not exact guarantees for every failure mode.
  • Bad tags create bad rules.
  • Enforce mode can reject queries and affect application behavior.

Output format

For each proposed budget:

  • Budget name.
  • Target branch.
  • Mode: off, warn, or enforce.
  • Matched traffic slice.
  • Rule type: tag, fingerprint, keyspace, query kind.
  • Proposed tags or fingerprint.
  • Limit rationale.
  • Queries seen in Insights that justify it.
  • Safety risk.
  • Test/observe plan.
  • Rollback plan.
  • Approval requirement.

End with:

“No Traffic Control budgets or rules have been created, updated, deleted, or enforced.”

来源与署名

来源:planetscale/skills位于planetscale-traffic-control-recommendations提交999045c

许可证: 无许可证

内容归原作者所有。SourceWeft 从公开仓库中收录这些内容。

举报或申请下架