This content is based on FastGPT v4.17.0.
What data for this category looks like
Data sources for this category include service runtime logs collected by logging systems, call chain data from distributed tracing platforms, performance metrics from Metrics systems, and instrumentation data reported by application SDKs. Daily maintained documents include logging collection specifications, tracing guides, metric dictionaries, and dashboard configuration records. Data updates typically occur daily or align with application version iterations. Fields include service identifiers, log levels, trace IDs, metric values, collection times, and additional relevant fields. Some metrics require matching units based on the associated business scenario.
Constraints for permissions and data isolation
Data sources for this category are scattered and diverse, spanning logging systems, distributed tracing platforms, and Metrics systems. Permission checks must cover access permission matching across multiple systems. Data updates happen at high frequency, so permission configurations must sync with daily or version-level data updates. Multiple daily maintained documents correspond to permission boundaries for different business scenarios. Clear accessible document ranges must be defined for different roles. Logs and trace data serve as core clues for fault location. Permission isolation must prevent unauthorized access from causing missing audit trails or delayed fault location. It must also ensure audit logs cannot be altered and can be traced.
How to set configurations
| Configuration Item | Recommended Practice | Rationale |
|---|---|---|
teamId | Assign a unique teamId for each business line, bind to member accounts of the corresponding operations team, use a business line identifier string as the value | Achieve business line-level data isolation, prevent cross-business line log data leaks |
tmbId | Assign a unique tmbId for each dashboard or tracing task, only allow the corresponding responsible individuals to make modifications, use a UUID format string as the value | Ensure configuration for a single observability scenario is only maintained by designated personnel, prevent accidental modifications |
| Team member permission scope | Divide permissions based on bound teamId, only allow members to access log and dashboard data under the corresponding teamId | Align with operations responsibility divisions for business lines, match daily maintenance permission boundaries |
| Audit log retention period | 365 days | Meet audit trail retention requirements for compliance reviews |
| Historical version data isolation | Only allow team members to view historical version documents under the corresponding tmbId | Prevent unauthorized personnel from accessing historical configuration documents, ensure configuration compliance |
| Cross-system authentication verification | Enable authentication verification, only allow accounts that pass SSO to access cross-system observability data | Prevent unauthorized cross-system data leaks |
Three common configuration errors
- Symptom: Historical version documents cannot be linked to the corresponding team. Checking the MongoAppVersion table shows that documents from earlier versions lack the
tmbIdfield. Cause: ThetmbIdfield was not supplemented for historical data during the version upgrade process, leading to permission checks failing to match team scopes. - Symptom: In an internal deployment environment, SSO authentication service connection fails, and logs show authentication requests are rejected. Cause: The correct SSO callback address was not configured, so the platform cannot verify authentication tokens.
- Symptom: After entering a valid account when adding a team member, the system displays the username as invalid. Cause: The permission to add members for the corresponding team was not enabled in the permission configuration, or the account was not bound to the correct
teamIdscope.
How to confirm configurations are properly applied
- Log in with accounts of different permission roles, verify that only log, dashboard, and trace data under the corresponding
teamIdcan be accessed. - View the audit log list, confirm that only authorized personnel can view audit records, and retention periods match preset requirements.
- Attempt to supplement the
tmbIdfield for historical version documents, verify that the documents can be correctly linked to the corresponding team after configuration. - Initiate an SSO authentication request, verify that the deployment environment can complete the authentication process normally.
The values provided are common starting points and should be measured against local sample data.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-10-19.