Skip to content

Observability, Alerting, and Automated Throttle Escalation [LOW] #1643

Open

Description

@HayimShaul

Description
Instrument every Signer and Verifier service operation with metrics (call rate, latency, error rate, cache hit/miss ratio) and expose them via the existing token/core/common/metrics infrastructure. Define alert thresholds that trigger automated responses -- such as temporarily blocking a caller or reducing its quota -- when anomalous call volumes are detected. Comprehensive audit logging of caller identity, operation type, and outcome provides the forensic trail needed to detect abuse early, attribute it to a specific principal, and tune throttling policies over time.

Activity

  1. added this to the Q2/26 milestone on May 3, 2026
  2. SurbhiAgarwal1 commented on May 14, 2026

    @SurbhiAgarwal1
    Contributor

    Hi @HayimShaul, I would like to work on this issue.

    After reviewing the current metrics infrastructure and the Security By Design epic, my understanding is that the goal here is to introduce lightweight but extensible observability and automated defensive throttling around Signer and Verifier operations.

    Proposed approach:

    • Instrument Signer and Verifier service operations using the existing token/core/common/metrics infrastructure.

    • Capture metrics such as:

      • request/call rate
      • operation latency
      • success/error counts
      • cache hit/miss ratio
      • throttle escalation events
    • Introduce middleware/interceptor-style wrappers so instrumentation remains decoupled from business logic.

    • Add structured audit logging for:

      • caller identity/principal
      • operation type
      • timestamp
      • outcome/error
      • escalation/throttle action applied
    • Define configurable anomaly thresholds (burst rate, sustained error rate, excessive retries, etc.) through policy/configuration instead of hardcoded values.

    • Implement an initial automated escalation mechanism that can:

      • temporarily reduce quotas
      • apply cooldown windows
      • temporarily block abusive callers
      • emit alerting metrics/events for operators
    • Keep the escalation logic extensible so future integrations with external monitoring/alerting systems can be added without changing core service logic.

    I’ll first review the existing metrics abstractions and identify the best integration points before proposing concrete implementation changes.

  3. modified the milestones: Q2/26, Q3/26 on Jun 2, 2026
  4. added 5 commits that reference this issue on Aug 4, 2026
    d7f9b1b
    746cbae
    2933b99
    c199202
    52bce9e
  5. added a commit that references this issue on Aug 18, 2026
    1e0b204
  6. 17 remaining items

  7. added a commit that references this issue on Sep 23, 2026
    19e6c3a
  8. added a commit that references this issue on Sep 23, 2026
    4606958
  9. added 7 commits that reference this issue on Sep 23, 2026
    71159b4
    3fcaf0f
    bd50b5b
    7c63f60
    b89646f
    023c006
    af111cb
  10. modified the milestones: Q3/26, Q4/26 on Oct 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

Type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions