DynamoGuard Logs

• DynamoGuard analyze requests flow from the API through the Moderation Server to Model calls
• This document covers how to trace logs for a single analyze call request across all components in the request flow

Request Flow and Logging

When the API makes an analyze request, the request flows through multiple components:

1. API receives the analyze request and generates a request ID (from rTracer.id())
2. API sends the request to Moderation Server with X-Request-ID header containing the API's request ID
3. Moderation Server receives this request ID and uses it as trace_id in its logs
4. A single API analyze call can result in multiple calls to the Moderation Server
5. Each Moderation Server call generates its own worker_request_id (unique UUID) while maintaining the same trace_id (API request ID)
6. Moderation Server makes calls to Models with X-Request-ID header (using the same value from correlation_id)
7. Models receive the X-Request-ID and bind it to request_id in their logs

Request Flow Diagram

┌─────────┐
│ Client  │
└────┬────┘
     │ Analyze Request
     ▼
┌─────────────────────────────────────────────────────────────┐
│                         API                                 │
│  Generates: request_id = "abc-123-def"                      │
│  Logs: log_processed.metadata.reqId = "abc-123-def"         │
└────┬────────────────────────────────────────────────────────┘
     │ POST /analyze
     │ X-Request-ID: abc-123-def
     ▼
┌─────────────────────────────────────────────────────────────┐
│                  Moderation Server                          │
│  Receives: X-Request-ID = "abc-123-def"                     │
│  Logs: trace_id = "abc-123-def"                             │
│        request_id = "worker-001" (unique per call)          │
└────┬────────────────────────────────────────────────────────┘
     │
     ├────────────┬────────────┬────────────┐
     │            │            │            │
     ▼            ▼            ▼            ▼
┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐
│ Model 1 │  │ Model 2 │  │ Model 3 │  │ Model N │
│         │  │         │  │         │  │         │
│Receives:│  │Receives:│  │Receives:│  │Receives:│
│ X-Req-ID│  │ X-Req-ID│  │ X-Req-ID│  │ X-Req-ID│
│ = "abc- │  │ = "abc- │  │ = "abc- │  │ = "abc- │
│ 123-def"│  │ 123-def"│  │ 123-def"│  │ 123-def"│
│         │  │         │  │         │  │         │
│ Logs:   │  │ Logs:   │  │ Logs:   │  │ Logs:   │
│ req_id =│  │ req_id =│  │ req_id =│  │ req_id =│
│ "abc-   │  │ "abc-   │  │ "abc-   │  │ "abc-   │
│ 123-def"│  │ 123-def"│  │ 123-def"│  │ 123-def"│
└────┬────┘  └────┬────┘  └────┬────┘  └────┬────┘
     │            │            │            │
     └────────────┴────────────┴────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────────┐
│                  Moderation Server                          │
│  Response: X-Worker-Request-Id: worker-001                  │
└────┬────────────────────────────────────────────────────────┘
     │
     ▼
┌─────────────────────────────────────────────────────────────┐
│                         API                                 │
│  Response: X-Request-Id: abc-123-def                        │
└────┬────────────────────────────────────────────────────────┘
     │
     ▼
┌─────────┐
│ Client  │
└─────────┘

Key Points:

• The same request ID (abc-123-def) flows through all components
• API logs use: log_processed.metadata.reqId = "abc-123-def"
• Moderation Server logs use:
  • trace_id = "abc-123-def" (same as API request ID)
  • request_id = "worker-001" (unique per Moderation Server call)
• Model logs use: request_id = "abc-123-def" (same as API request ID)
• A single API analyze request can result in multiple Moderation Server calls, each making multiple Model calls

Structured Logging Attributes

API Logs

The API logs include the standard API structured logging attributes. The key attribute for tracing DynamoGuard requests is:

Attribute Name	Description
log_processed.metadata.reqId	The request ID assigned to the incoming analyze request. This is sent to the Moderation Server as X-Request-ID header and is also returned in the response header as X-Request-Id.

Moderation Server Logs

The Moderation Server logs include the following attributes for tracing:

Attribute Name	Description
trace_id	The API request ID received in the X-Request-ID header. This links Moderation Server logs back to the original API request. This same value is passed to Models as X-Request-ID.
request_id	A unique worker request ID (UUID) generated for each individual Moderation Server call. A single API analyze request may result in multiple Moderation Server calls, each with a different request_id but the same trace_id.
otel_trace_id	The OpenTelemetry trace ID for distributed tracing.

Model Logs

The Model logs include the following attributes for tracing:

Attribute Name	Description
request_id	The request ID received from Moderation Server in the X-Request-ID header. This is the same value as the API's request ID (trace_id in Moderation Server logs).

Tracing a Single Analyze Call Request

To trace all logs for a single analyze call from API through Moderation Server to Models:

Step 1: Get the API Request ID

• The API request ID is returned in the response header as X-Request-Id
• You can also find it in API logs using log_processed.metadata.reqId

Step 2: View API Logs

Filter API logs by the request ID to see all API-side logs for the analyze request:

• Use log_processed.metadata.reqId to filter API logs

Step 3: View Moderation Server Logs

Filter Moderation Server logs by trace_id (which equals the API request ID) to see all Moderation Server logs for that analyze request:

• Use trace_id to filter Moderation Server logs
• This will show all Moderation Server calls made as part of that single API analyze request
• Each Moderation Server call will have a different request_id (worker_request_id) but the same trace_id

Step 4: View Model Logs

Filter Model logs by request_id (which equals the API request ID) to see all Model calls made during that analyze request:

• Use request_id to filter Model logs
• This will show all Model calls made by the Moderation Server for that analyze request

Example Flow

1. API receives analyze request → generates request ID: abc-123-def
2. API sends to Moderation Server with X-Request-ID: abc-123-def
3. Moderation Server call #1:
   • trace_id: abc-123-def (from API)
   • request_id: worker-001 (new UUID, unique to this Moderation Server call)
   • Moderation Server calls Model with X-Request-ID: abc-123-def
4. Model call #1:
   • request_id: abc-123-def (from Moderation Server's X-Request-ID header)
5. Moderation Server call #2 (if needed):
   • trace_id: abc-123-def (same API request)
   • request_id: worker-002 (different UUID)
   • Moderation Server calls Model with X-Request-ID: abc-123-def
6. Model call #2:
   • request_id: abc-123-def (same value, from Moderation Server)

To see all logs for this analyze request:

• Filter API logs: log_processed.metadata.reqId = "abc-123-def"
• Filter Moderation Server logs: trace_id = "abc-123-def"
• Filter Model logs: request_id = "abc-123-def"

Key Relationships

• API log_processed.metadata.reqId = Moderation Server trace_id = Model request_id
• This single ID allows you to trace the entire request flow across all components
• Moderation Server request_id (worker_request_id) is unique per Moderation Server call and is used for internal Moderation Server tracing only

Note: For CloudWatch-specific query examples, see the CloudWatch Guide.