What Log Data for This Category Includes
Log data for the model allocation category comes from model scheduling requests within the platform, downstream model return results, and permission verification records. Logs are generated in real time. A log entry is created immediately after each scheduling request completes. Logs use structured JSON format. Core fields include:
model_allocation_id: Globally unique scheduling identifierrequest_id: Request ID bound to conversation contextassigned_model: Name of the actual assigned modelinput_tokens,output_tokens: Token count values for the callstatus_code: Scheduling status code
Token counts use integer units. Status codes use standard HTTP status codes or custom scheduling exception codes.
Constraints for Conversation Logs and Auditing
Because logs are generated in real time and bound to the request_id and assigned_model fields, the auditing workflow must support single-request tracing. Batch offline scanning cannot replace real-time verification. Anomaly marking must be implemented for the status_code field. Alarms must trigger for exception codes such as 403 (insufficient permissions) and 500 (scheduling failure). Additionally, since fields are bound to conversation context, audit logs must be associated with the corresponding application and session ID. This prevents logs from being disconnected from conversations. Token statistics fields must also undergo cross-verification with token consumption in conversation logs to ensure alignment between scheduling costs and actual consumption.
Configuration Settings
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
audit_log_retention_days | 30–90 days | Meets log retention cycle requirements for financial industry compliance audits |
model_allocation_audit_trigger | on_every_call | Ensures all model scheduling requests are covered and included in audits without omission |
403_error_alert_threshold | ≥1 per hour | Detects abnormal scheduling requests with failed permission checks in a timely manner |
log_field_mapping | {"request_id": "req_id", "assigned_model": "model", "input_tokens": "tokens"} | Unifies field naming rules for cross-system auditing, facilitating association with conversation context |
audit_detail_level | full | Records complete scheduling latency, token consumption, and permission verification information to meet detailed compliance audit requirements |
The parameter values provided on this page are common starting points for configuration. Actual values are affected by data format, data volume, and business rules. Specific issues require individual analysis. It is recommended to test on your own samples before finalizing settings.
Three Common Misconfigurations
- Symptom: Container logs display the
common:code_error.error_message.403error, and the corresponding request is not included in audit logs. Cause:model_allocation_audit_triggeris not set toon_every_call, so scheduling requests with failed permission checks are not fully recorded. - Symptom: The specified model allocation component’s output fields do not appear in the workflow global variable’s conversation history. Cause: The
assigned_model_outputfield is not configured inlog_field_mapping, so component output is not synchronized to audit logs. - Symptom: Conversation history generated during debug preview cannot be cleaned by specified application dimension. Cause: The
audit_log_bind_app_idconfiguration is not enabled, so audit logs are not bound to application IDs, making retrieval or cleaning by application dimension impossible.
How to Verify Correct Configuration
- Initiate a standard model scheduling request, then access the audit log panel. Confirm that a complete log entry containing
model_allocation_idandassigned_modelis generated. - Trigger a model call with insufficient permissions. Confirm that an exception alarm notification is received within the set
403_error_alert_threshold. - View the audit log field mapping. Confirm that the field names in the logs match the mapping rules configured in
log_field_mapping. - Attempt to retrieve audit logs by application ID. Confirm that all model scheduling logs for the corresponding application can be filtered.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-09-14.