What this category of data looks like
This data typically originates from Kubernetes APIs, image registries, monitoring systems, and CI pipelines. It is maintained by platform engineers, Kubernetes administrators, and SREs. Daily generated documents include cluster change tickets, namespace quota tables, deployment records, and fault reports. Fields cover cluster node IDs, Pod statuses, image versions, resource quota thresholds, and fault trigger times. Updates run on a daily sync schedule or trigger after each cluster change. Data is stored as structured logs and configuration files, linking full process information for application runtime and cluster orchestration.
What constraints these characteristics impose on the database and operations workflow
Data sources are scattered, and update frequencies adjust dynamically with cluster changes. The database and operations workflow must support access to multi-source structured data, avoiding investigation interruptions caused by reliance on a single data source. Daily documents have strong field correlation. Database configurations must align with cluster quota and deployment record fields, otherwise data matching failures will occur. The high frequency of cluster changes requires database connection pool parameters to adapt to dynamic scaling scenarios, preventing Pod startup failures caused by insufficient connections. The severe consequences of business outages require the database operations workflow to pre-configure fault rollback mechanisms that match the approval process of cluster change tickets.
How to set configurations
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
MONGODB_URI | mongodb://[username]:[password]@[cluster-mongo-svc]:27017/fastgpt?authSource=admin | Adapts to the authentication and access path of clustered MongoDB instances within the container platform, ensuring compliance with cross-namespace database access permissions |
PG_URL | postgresql://[pg-user]:[pg-pass]@[cluster-pg-svc]:5432/fastgpt?sslmode=require | Follows the standard connection format for containerized PostgreSQL instances, enforces SSL encryption to secure data transmission within the cluster |
DB_MAX_LINK | 100–150 connections | Matches the file handle limit and container resource quota of a single Kubernetes node, preventing Pod exceptions caused by exhausted database connections |
REDIS_URL | redis://:[redis-pass]@[cluster-redis-svc]:6379/0 | Adapts to the access address of in-container Redis cache instances, used for storing cluster state cache and temporary fault troubleshooting logs |
| Database backup cycle | Daily 00:00 | Aligns with the daily update frequency of cluster changes, enabling quick recovery to the most recent valid state when a fault occurs |
| Database backup retention days | 7 days | Covers the standard fault troubleshooting and post-mortem cycle, preventing expired backup data from blocking historical issue review |
This configuration scheme is compatible with FastGPT v4.17.0.
Three common misconfigurations
- Phenomenon: Unable to log in to the platform after a version upgrade, with the interface returning a 502 status code. Cause: Environment variables in the container were not updated after modifying MongoDB or PostgreSQL configuration files, so the platform cannot read the correct database connection address.
- Phenomenon: Version upgrade fails in an offline environment, with a prompt indicating inability to pull images. Cause: Upgrade-required images were not pre-uploaded to the private image registry in the container platform, and public image sources are inaccessible.
- Phenomenon: Connection failure occurs after replacing PostgreSQL with another database. Cause: Database connection configuration parameters in the platform were not updated synchronously, so the platform still points to the original database instance.
How to verify correct configuration
- Log in to the container platform's monitoring system, view real-time database connection count metrics, and confirm they do not exceed the configured
DB_MAX_LINKthreshold. - Run database connection test commands inside the container to verify that the configured
MONGODB_URI,PG_URL, andREDIS_URLcan be accessed normally. - Review cluster change tickets and deployment records to confirm that database configuration parameters align with the current cluster's resource quotas and namespace rules.
- Simulate a small-scale cluster change to verify that the platform can successfully write fault troubleshooting logs to the database.
The values provided are common starting points and should be measured against the reader's own samples.
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.