Skip to content

Implement Centralized Logging and Audit System for Bot & LLM Pool #7

@ruvasqm

Description

@ruvasqm

Description:
This issue focuses on establishing a comprehensive logging and audit system for our Discord bot and the LLM API Key Pool Manager service. The goal is to provide transparency to users about their donated keys' usage, enable robust debugging, and ensure verifiable proof of system operations. All logs will be structured, sent to AWS CloudWatch, and a specific Discord command will allow users to query their key's usage.

Acceptance Criteria:

  • All critical events from both the Discord bot and the LLM API Key Pool Manager service are captured as structured logs.
  • Logs are consistently formatted (e.g., JSON) with relevant metadata.
  • All application logs are successfully sent to AWS CloudWatch Logs.
  • The /llm_api_audit Discord command functions correctly, allowing a user to view their donated key's usage.
  • The audit output for /llm_api_audit includes:
    • Current daily/monthly usage vs. limits for their key.
    • A paginated list of recent LLM requests made using their key.
    • For each request: timestamp, LLM model used, tokens consumed, a sanitized summary of the request, and a direct link to the Discord message/interaction where it occurred.
  • No sensitive information (raw API keys, full prompts/responses) is ever logged or exposed in the audit.
  • Audit data is stored persistently in the SQLite database.

Tasks:

  1. Database Schema Definition (SQLite):

    • Define key_usage_logs table:
      • id (PK)
      • llm_api_key_id (INTEGER - FK to llm_api_keys.id from Issue Comandos de repositorios añadidos #1)
      • timestamp (DATETIME)
      • llm_model (TEXT - e.g., 'gpt-4', 'claude-3-opus')
      • tokens_prompt (INTEGER)
      • tokens_completion (INTEGER)
      • discord_user_id (TEXT - ID of the user who initiated the Discord command)
      • discord_channel_id (TEXT)
      • discord_message_id (TEXT)
      • discord_guild_id (TEXT - needed to construct message URL)
      • request_summary (TEXT - a short, sanitized summary of the prompt, e.g., "Chat interaction", "Image generation prompt")
      • response_metadata_summary (TEXT - e.g., "Success", "Rate limited", "Error")
  2. Structured Logging Implementation:

    • Integrate a structured logging library into both the Discord bot and the LLM API Key Pool Manager service.
    • Define a standard set of log fields (e.g., timestamp, service, level, message, event_type, request_id, discord_user_id, llm_key_id_used, tokens_used).
    • Ensure sensitive data is redacted or not logged at all.
  3. AWS CloudWatch Logs Integration:

    • Configure both services to send their structured logs to AWS CloudWatch Logs.
    • Set up distinct Log Groups (e.g., /discord-bot/logs, /llm-pool-manager/logs).
    • Ensure the EC2 instance's IAM role has the necessary permissions to write to CloudWatch Logs.
  4. Audit Data Capture:

    • LLM API Key Pool Manager:
      • Log every LLM request made, including the llm_api_key_id used, token counts, and relevant Discord context (discord_user_id, channel_id, message_id, guild_id).
      • Log key management events (key added, removed, status changes, limit resets).
      • Persist these audit-specific logs to the key_usage_logs SQLite table.
    • Discord Bot:
      • Ensure the bot passes discord_user_id, channel_id, message_id, guild_id to the LLM API Key Pool Manager service for every LLM-related interaction.
  5. /llm_api_audit Discord Command Implementation:

    • Develop the Discord bot command handler for /llm_api_audit.
    • When invoked, query the llm_api_keys table for the user's donated key (using owner_discord_id).
    • Query the key_usage_logs table for entries associated with that llm_api_key_id.
    • Format the output clearly, including current usage, limits, and the paginated list of recent activities.
    • Construct Discord message URLs using https://discord.com/channels/<guild_id>/<channel_id>/<message_id>.
  6. Data Retention Policy:

    • Define and implement a data retention policy for key_usage_logs (e.g., keep for 3 months, then archive/delete). This is important for privacy.
  7. Security Review:

    • Thoroughly review all logging points to ensure no sensitive data is accidentally logged.
    • Ensure the audit command only reveals data pertaining to the requesting user's donated key.

Dependencies:

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions