mirror of
https://github.com/infiniflow/ragflow.git
synced 2026-08-01 13:33:48 +08:00
docs: update user guide (#17358)
add model config guide word and picture add teams guide words
This commit is contained in:
YanZhang
@@ -1,52 +0,0 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
slug: /admin_ui
|
||||
sidebar_custom_props: {
|
||||
categoryIcon: LucidePalette
|
||||
}
|
||||
---
|
||||
# Admin UI
|
||||
|
||||
The RAGFlow Admin UI is a web-based interface that provides comprehensive system status monitoring and user management capabilities.
|
||||
|
||||
|
||||
## Accessing the Admin UI
|
||||
|
||||
To access the RAGFlow admin UI, append `/admin` to the web UI's address, e.g. `http://[RAGFLOW_WEB_UI_ADDR]/admin`, replace `[RAGFLOW_WEB_UI_ADDR]` with real RAGFlow web UI address.
|
||||
|
||||
### Default Credentials
|
||||
| Username | Password |
|
||||
|--------------------|----------|
|
||||
| `admin@ragflow.io` | `admin` |
|
||||
|
||||
## Admin UI Overview
|
||||
|
||||
### Service status
|
||||
|
||||
The service status page displays of all services within the RAGFlow system.
|
||||
|
||||
- **Service List**: View all services in a table.
|
||||
- **Filtering**: Use the filter button to filter services by **Service Type**.
|
||||
- **Search**: Use the search bar to quickly find services by **Name** or **Service Type**.
|
||||
- **Actions** (hover over a row to see action buttons):
|
||||
- **Extra Info**: Display additional configuration information of a service in a dialog.
|
||||
- **Service Details**: Display detailed status information of a service in a dialog. According to service's type, a service's status information could be displayed as a plain text, a key-value data list, a data table or a bar chart.
|
||||
|
||||
### User management
|
||||
|
||||
The user management page provides comprehensive tools for managing all users in the RAGFlow system.
|
||||
|
||||
- **User List**: View all users in a table.
|
||||
- **Search Users**: Use the search bar to find users by email or nickname.
|
||||
- **Filter Users**: Click the filter icon to filter by **Status**.
|
||||
- Click the **"New User"** button to create a new user account in a dialog.
|
||||
- Activate or deactivate a user by using the switch toggle in **Enable** column, changes take effect immediately.
|
||||
- **Actions** (hover over a row to see action buttons):
|
||||
- **View Details**: Navigate to the user detail page to see comprehensive user information.
|
||||
- **Change Password**: Force reset the user's password.
|
||||
- **Delete User**: Remove the user from the system with confirmation.
|
||||
|
||||
|
||||
### User detail
|
||||
|
||||
The user detail page displays a user's detailed information and all resources created or owned by the user, categorized by type (e.g. Dataset, Agent).
|
||||
11
docs/administrator/admin/admin_ui/_category_.json
Normal file
11
docs/administrator/admin/admin_ui/_category_.json
Normal file
@@ -0,0 +1,11 @@
|
||||
{
|
||||
"label": "Admin UI",
|
||||
"link": {
|
||||
"type": "generated-index",
|
||||
"description": "Admin UI."
|
||||
},
|
||||
"position": 1,
|
||||
"customProps": {
|
||||
"categoryIcon": "LucidePalette"
|
||||
}
|
||||
}
|
||||
33
docs/administrator/admin/admin_ui/before_you_begin.md
Normal file
33
docs/administrator/admin/admin_ui/before_you_begin.md
Normal file
@@ -0,0 +1,33 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
sidebar_label: "Before You Begin"
|
||||
---
|
||||
|
||||
# Before You Begin
|
||||
|
||||
## Access the Admin UI
|
||||
|
||||
System administrators can access the RAGFlow Admin UI in a browser. The current Admin UI entry point is `/admin`, for example `http://192.168.1.5/admin`.
|
||||
|
||||
After entering the Admin UI, administrators can perform service health checks, maintain user accounts, configure sandboxes, control registration, manage roles and permissions, configure system settings, and configure identity providers. The Admin UI should be exposed only to trusted administrators.
|
||||
|
||||
|
||||
|
||||
Regular users do not need to enter the Admin UI when they use business features such as knowledge bases, chat, Agent, files, and model providers.
|
||||
|
||||
## Initial Administrator Account
|
||||
|
||||
After the first deployment, you can log in with the default administrator account:
|
||||
|
||||
| Field | Value |
|
||||
| --- | --- |
|
||||
| Username | `admin@ragflow.io` |
|
||||
| Default password | `admin` |
|
||||
|
||||
This account is used to initialize the system and create subsequent administrator accounts. It is not recommended as a long-term shared daily operations account.
|
||||
|
||||
After the first login, reset the default password as soon as possible and create separate accounts for different administrators. In daily administration, grant the `Superuser` identity only to users who actually need Admin UI responsibilities.
|
||||
|
||||
## Change the Admin Account Password
|
||||
|
||||
This feature is not available yet.
|
||||
46
docs/administrator/admin/admin_ui/check_system_status.md
Normal file
46
docs/administrator/admin/admin_ui/check_system_status.md
Normal file
@@ -0,0 +1,46 @@
|
||||
---
|
||||
sidebar_position: 2
|
||||
sidebar_label: "Check System Status"
|
||||
---
|
||||
|
||||
# Check System Status
|
||||
|
||||
## Check Whether Services Are Running Normally
|
||||
|
||||
After entering the Admin UI, open the **Service status** page to view the runtime status of RAGFlow and its dependent services. The page displays each service's name, service type, host, port, and current status, so administrators can confirm whether all system components are running normally.
|
||||
|
||||
|
||||
|
||||
When **Status** is `Alive`, the service is running normally. Any other status may affect the corresponding features.
|
||||
|
||||
|
||||
|
||||
| Service name | Main purpose | Possible issues when abnormal | Affected features |
|
||||
| --- | --- | --- | --- |
|
||||
| RAGFlow Server | Core system service responsible for the Web UI, APIs, knowledge bases, Q&A, Agent, and other business features. | The system cannot be accessed, login fails, pages report errors, or all features become unavailable. | Login, knowledge base management, knowledge applications, Agent, model management, system management, and all other features. |
|
||||
| MySQL | Stores business data such as users, knowledge bases, model configurations, and system configurations. | Login fails, knowledge base data cannot be read, configurations cannot be saved, or business data becomes abnormal. | User management, knowledge base management, model configuration, system configuration, and business data reads and writes. |
|
||||
| MinIO | Stores uploaded documents, images, and other object files. | File upload fails, documents cannot be opened, parsing fails, or images cannot be displayed. | File upload, document management, document parsing, file preview, and download. |
|
||||
| Elasticsearch | Builds full-text and vector indexes and provides knowledge retrieval capabilities. | Documents cannot be retrieved, searches return no results, Q&A cannot cite knowledge, or knowledge recall is abnormal. | Full-text retrieval, vector retrieval, hybrid retrieval, knowledge Q&A, and knowledge citation. |
|
||||
| Redis (Valkey) | Provides cache and task status management to improve system runtime efficiency. | Pages respond slowly, sessions become abnormal, or some features run abnormally. | System cache, session management, task status management, and some backend features. |
|
||||
| RabbitMQ | Manages backend asynchronous tasks and sends tasks to executors. | Documents remain in `Waiting for processing`, or backend tasks cannot start. | Asynchronous task scheduling for document parsing, knowledge compilation, Embedding, and index building. |
|
||||
| Task Executor | Executes backend tasks such as document parsing, OCR, Embedding, and index building. | Documents remain in `Parsing`, knowledge cannot be imported, or indexes cannot be built. | OCR, document parsing, Embedding, knowledge ingestion, index building, and other backend processing tasks. |
|
||||
|
||||
## View Service Details
|
||||
|
||||
On the **Service status** page, administrators can view the service `ID`, `Name`, `Service type`, `Host`, `Port`, and `Status`. When `Status` is `Alive`, the service is currently alive.
|
||||
|
||||
Administrators can open service details from **Actions**. Different services display different details. For example, the `mysql` service details show current database connection and process information, including `command`, `db`, `host`, `id`, `info`, `state`, `time`, and `user`. Administrators can use this information to determine whether there are long-running connections, waiting states, or abnormal queries.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Some services also provide an **Extra information** dialog that displays supplementary configuration information. For example, an object storage service may display information such as `store_type` and `user`. This information is mainly used to confirm service configuration.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
If a service's `Status` is not `Alive`, first record its `ID`, `Name`, `Service type`, `Host`, `Port`, and any abnormal information visible in the details dialog or **Extra information**.
|
||||
|
||||
The Admin UI is mainly used to view service status. It does not provide direct troubleshooting entry points for containers, processes, networks, or logs. For further handling, check the corresponding deployment environment, including service runtime status, port connectivity, service logs, and related configurations. After identifying the cause, restart services, adjust configurations, or perform other recovery operations according to your operations process.
|
||||
@@ -0,0 +1,153 @@
|
||||
---
|
||||
sidebar_position: 4
|
||||
sidebar_label: "Configure Code Execution Sandbox"
|
||||
---
|
||||
|
||||
# Configure Code Execution Sandbox
|
||||
|
||||
## Select a Sandbox Provider
|
||||
|
||||
If your organization uses the **Code** component in Agent, administrators must configure the code execution sandbox in **Sandbox settings**.
|
||||
|
||||
The current page supports the following `Provider` options:
|
||||
|
||||
| Provider | Description |
|
||||
| --- | --- |
|
||||
| `Local` | Execute code directly in the current host process. |
|
||||
| `Self-Managed` | Use Daytona or Docker for localized deployment. |
|
||||
| `SSH` | Execute code on a remote machine through SSH. |
|
||||
| `AliyunCodeInterpreter` | Use Alibaba Cloud Function Compute Code Interpreter. |
|
||||
| `E2B` | Use E2B Cloud Code Execution Sandboxes. |
|
||||
|
||||
After selecting a `Provider`, the page displays the corresponding configuration area.
|
||||
|
||||
|
||||
|
||||
**Caution:** Sandbox configuration affects not only connection availability, but also code isolation, network access, file access, and runtime resource limits. In production environments, prefer `Self-Managed`, cloud, or independent remote execution solutions with isolation capabilities. Direct use of `Local` is not recommended.
|
||||
|
||||
| Provider | Applicable scenario | Main characteristics | Recommendation |
|
||||
| --- | --- | --- | --- |
|
||||
| `Local` | Local development and functional debugging | Runs code directly on the current host and is easy to configure. | Recommended only for controlled development and test environments. |
|
||||
| `Self-Managed` | Enterprise intranet and private deployment | Uses a self-managed sandbox service to execute code. Data and runtime environments can be controlled independently. | Suitable for production environments and scenarios with high data security requirements. |
|
||||
| `SSH` | Existing independent execution servers | Executes code on a remote host through SSH. | Suitable for reusing existing servers or custom runtime environments. |
|
||||
| `AliyunCodeInterpreter` | Alibaba Cloud-related services | Uses a cloud service to provide the code execution environment, making elastic scaling easier. | Suitable for organizations already using the corresponding cloud service. |
|
||||
| `E2B` | Fast access to a cloud sandbox | Executes code in an isolated environment provided by E2B. | Suitable for scenarios that need quick use without deployment. |
|
||||
|
||||
## Test and Save Configuration
|
||||
|
||||
When configuring a sandbox, first fill in the connection information and runtime parameters required by the selected `Provider`, then use **Test connection** to verify availability. After the test succeeds, click **Save**.
|
||||
|
||||
## Local Runtime Configuration
|
||||
|
||||
`Local configuration` configures the local code execution environment. The system uses the following configuration when executing code tasks such as Python and Node.js.
|
||||
|
||||
1. Go to **Local Configuration**.
|
||||
2. Configure each parameter according to the actual runtime environment.
|
||||
3. Click **Test connection** to test whether the configuration is correct.
|
||||
4. After the test succeeds, click **Save**.
|
||||
|
||||
| Parameter | Description | Recommendation |
|
||||
| --- | --- | --- |
|
||||
| `Working Directory` | Working directory used during code execution, for temporary files generated during runtime. | Keep the default, or configure a local directory with read and write permissions. |
|
||||
| `Python Binary` | Python executable name or path. | Usually `python3`. If using a virtual environment, enter the full Python path. |
|
||||
| `Node.js Binary` | Node.js executable name or path. | Usually `node`. If installed elsewhere, enter the full path. |
|
||||
| `Max Artifact Size (bytes)` | Maximum allowed size for a single generated file. | Configure according to business needs. The default usually satisfies common use. |
|
||||
| `Max Artifacts` | Maximum number of files allowed in one run. | Keep the default to avoid generating too many temporary files. |
|
||||
| `Max Memory (MB)` | Maximum memory available to a single code run. | Configure according to server resources. Increase it when resources are sufficient. |
|
||||
| `Max Output (bytes)` | Maximum length of console output. | Keep the default to avoid oversized output. |
|
||||
| `Timeout (seconds)` | Maximum runtime for a single code execution. | Set according to the business scenario. The task is terminated automatically after timeout. |
|
||||
|
||||
If Python or Node.js is not installed, or the executable path is wrong, the connection test fails.
|
||||
|
||||
## Self-Managed Configuration
|
||||
|
||||
`Self-Managed` configuration connects to a deployed `SandboxExecutorManager` service for remote sandbox execution. If the code execution service is deployed on an independent server or in a container, complete this configuration.
|
||||
|
||||
1. Go to **Self-Managed Configuration**.
|
||||
2. Configure the code execution service connection information.
|
||||
3. Click **Test connection** to test whether the connection is normal.
|
||||
4. After the test succeeds, click **Save**.
|
||||
|
||||
| Parameter | Description | Recommendation |
|
||||
| --- | --- | --- |
|
||||
| `Executor Manager Endpoint` | Access address of the `SandboxExecutorManager` service. | Enter the HTTP address of the code execution service, such as `http://sandbox-executor-manager:9385` or `http://<SERVER_IP>:9385`. Make sure RAGFlow can access this address. |
|
||||
| `Request Timeout (seconds)` | Timeout for requests to the code execution service. | Configure according to the network environment and code execution duration. The default 30 seconds is sufficient for most cases; increase it for large tasks. |
|
||||
|
||||
`Executor Manager Endpoint` must be the address of a deployed and normally running `SandboxExecutorManager` service.
|
||||
|
||||
`Deployment Defaults` displays the current default deployment parameters of `SandboxExecutorManager`.
|
||||
|
||||
## SSH Configuration
|
||||
|
||||
`SSH` configuration connects to a remote Linux host and executes Python, Node.js, and other code tasks on the remote server. After configuration, the system logs in to the specified server through SSH and executes code in the remote working directory.
|
||||
|
||||
1. Go to **System management > Model service > SSH Configuration**.
|
||||
2. Fill in the remote server connection information.
|
||||
3. Select the authentication method: password authentication or private-key authentication.
|
||||
4. Configure the remote code runtime environment.
|
||||
5. Click **Test connection** to test whether the connection is normal.
|
||||
6. After the test succeeds, click **Save**.
|
||||
|
||||
### SSH Connection Configuration
|
||||
|
||||
| Parameter | Description | Recommendation |
|
||||
| --- | --- | --- |
|
||||
| `SSH Host` | Remote server IP address or host name. | For example, `192.168.1.10` or `server.example.com`. |
|
||||
| `SSH Username` | User name used to log in to the remote server. | Enter a user with code execution permissions, such as `root`, `ubuntu`, or `ragflow`. |
|
||||
| `SSH Port` | Port on which the SSH service listens. | The default is `22`. If the server uses another SSH port, enter the actual port. |
|
||||
|
||||
### Authentication
|
||||
|
||||
The system supports `Password` and `PrivateKey` authentication.
|
||||
|
||||
| Authentication method | Description | Recommendation |
|
||||
| --- | --- | --- |
|
||||
| `Password` | Uses the SSH user password for authentication. | Fill in `SSH Password`. |
|
||||
| `PrivateKey` | Uses an SSH private key for authentication. | Fill in the SSH private key content. If the private key has a password, also fill in the corresponding `Passphrase`. Private-key authentication is recommended in production. |
|
||||
|
||||
### Execution
|
||||
|
||||
| Parameter | Description | Recommendation |
|
||||
| --- | --- | --- |
|
||||
| `Remote Workspace Root` | Working directory on the remote server for temporary files generated during code runs. | Configure a directory with read and write permissions, such as `/tmp` or `/home/ragflow/workspace`. |
|
||||
| `Python Binary` | Python executable name or full path. | Usually `python3`. If using a virtual environment, enter the full Python path. |
|
||||
| `Node.js Binary` | Node.js executable name or full path. | Usually `node`. If installed elsewhere, enter the full path. |
|
||||
| `Max Artifact Bytes` | Maximum allowed size for a single generated file. | Keep the default or adjust according to business needs. |
|
||||
| `Max Artifacts` | Maximum number of files allowed in one run. | Keep the default configuration. |
|
||||
| `Max Output Bytes` | Maximum size of console output. | Keep the default. Output exceeding the limit is truncated. |
|
||||
| `Timeout (seconds)` | Maximum runtime for a single code execution. | The default is 30 seconds. Increase it when execution takes longer. |
|
||||
|
||||
Make sure the remote server has SSH enabled and allows the current user to log in. The configured user must have read and write permissions on the remote working directory and be able to execute Python, Node.js, and other runtime environments. When using private-key authentication, make sure the private key matches the server configuration.
|
||||
|
||||
## Alibaba Cloud CodeInterpreter Configuration
|
||||
|
||||
Alibaba Cloud `CodeInterpreter` configuration connects to Alibaba Cloud CodeInterpreter. The system executes code tasks through this service.
|
||||
|
||||
1. Go to **AliyunCodeInterpreter Configuration**.
|
||||
2. Fill in the connection information for Alibaba Cloud CodeInterpreter.
|
||||
3. Click **Test connection** to test whether the connection is normal.
|
||||
4. After the test succeeds, click **Save**.
|
||||
|
||||
| Parameter | Description | Recommendation |
|
||||
| --- | --- | --- |
|
||||
| `AccessKeyID` | Alibaba Cloud account `AccessKeyID` for authentication. | Enter an `AccessKeyID` with access to the CodeInterpreter service. |
|
||||
| `AccessKeySecret` | Secret corresponding to `AccessKeyID`. | Enter the corresponding `AccessKeySecret` and keep it secure to avoid leakage. |
|
||||
| `AccountID` | Alibaba Cloud account ID. | Enter the current Alibaba Cloud account ID. |
|
||||
| `Region` | Region where the CodeInterpreter service is located. | Enter the actual deployment region, such as `cn-hangzhou`. |
|
||||
| `TemplateName` | Template name used by CodeInterpreter. | Enter the created template name, such as `my-interpreter`. |
|
||||
| `ExecutionTimeout (seconds)` | Maximum runtime allowed for a single code execution. | The default is 30 seconds. Adjust according to business needs. |
|
||||
|
||||
## E2B Configuration
|
||||
|
||||
`E2B` configuration connects to the E2B Cloud code execution service. After configuration, the system executes code tasks through the E2B cloud sandbox.
|
||||
|
||||
1. Go to **E2B**.
|
||||
2. Fill in the E2B service connection information.
|
||||
3. Click **Test connection** to test whether the connection is normal.
|
||||
4. After the test succeeds, click **Save**.
|
||||
|
||||
| Parameter | Description | Recommendation |
|
||||
| --- | --- | --- |
|
||||
| `API Key` | API key provided by E2B Cloud for authentication. | Log in to the E2B platform, create the corresponding API key, and enter it. |
|
||||
| `Region` | Region where the E2B service is located. | Enter the actual region, such as `us`. |
|
||||
| `Request Timeout (seconds)` | Timeout for requests to the E2B service. | The default is 30 seconds. Increase it if the network is slow or execution takes longer. |
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
sidebar_position: 6
|
||||
sidebar_label: "Configure User Roles and Permissions (Enterprise Edition)"
|
||||
---
|
||||
|
||||
# Configure User Roles and Permissions (Enterprise Edition)
|
||||
|
||||
## Maintain Roles
|
||||
|
||||
Enterprise Edition maintains roles and permissions through the **Roles** page. Administrators can view existing roles on this page and create new roles through **New role**.
|
||||
|
||||
The current page displays a permission matrix under each role. Visible resources include `Dataset`, `Chat`, `Agent`, `Search`, `File`, `Team`, `Memory`, and `Model provider`. Visible actions include `Enable`, `Read`, `Write`, and `Share`.
|
||||
|
||||
Administrators should configure roles according to user responsibilities and should not grant ordinary users resource permissions beyond what their work requires.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**Note:** Modifying role permissions affects users' access scope for knowledge bases, chat, Agent, search, files, teams, memory, model providers, and other resources.
|
||||
|
||||
## Assign Roles to Users
|
||||
|
||||
In Enterprise Edition, a user's `Role` can be assigned on the **User management** page. Administrators can click the target user's current `Role` and select a new role from the role list.
|
||||
|
||||
1. Go to the **User management** page.
|
||||
2. Find the target user and open the role dropdown in the `Role` column.
|
||||
3. Select the new role.
|
||||
|
||||
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
sidebar_position: 5
|
||||
sidebar_label: "Control Registration and System Settings (Enterprise Edition)"
|
||||
---
|
||||
|
||||
# Control Registration and System Settings (Enterprise Edition)
|
||||
|
||||
## Enable the Registration Whitelist
|
||||
|
||||
Enterprise Edition can restrict which users are allowed to register through the registration whitelist. To use the registration whitelist, first go to **Settings** and enable **Enable module** in the **Registration whitelist** module. After enabling it, return to **Registration whitelist** to maintain allowed email addresses or rules.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Manage the Registration Whitelist
|
||||
|
||||
Enterprise Edition uses **Registration whitelist** to control which email addresses can register for RAGFlow. When the system needs to restrict the registration scope, administrators can maintain allowed email addresses in **Registration whitelist**. After the whitelist is enabled, email addresses that are not in the whitelist cannot complete registration directly.
|
||||
|
||||
After entering the **Registration whitelist** page, the page displays **Whitelist management**. Administrators can view email addresses that have already been added to the whitelist, along with each record's creation time and update time. The list fields include `Email`, `Create date`, `Update date`, and `Actions`.
|
||||
|
||||
The top of the page provides common maintenance operations:
|
||||
|
||||
| Operation | Description |
|
||||
| --- | --- |
|
||||
| `Search` | Search whitelist records by email address. |
|
||||
| `New user` | Add a single email address. |
|
||||
| `Import Excel` | Import whitelist records in batches. |
|
||||
| `Export Excel` | Export the current whitelist data. |
|
||||
|
||||
The lower-right corner of the page displays the current total number of records, pagination, and page size. To add a single email address, click **New user**, fill in the email address as prompted, and save it. For batch maintenance, prepare an Excel file first and then import it through **Import Excel**. After importing, use search to spot-check whether key email addresses appear in the list.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,84 @@
|
||||
---
|
||||
sidebar_position: 7
|
||||
sidebar_label: "Manage System Settings (Enterprise Edition)"
|
||||
---
|
||||
|
||||
# Manage System Settings (Enterprise Edition)
|
||||
|
||||
## Manage Licenses
|
||||
|
||||
Enterprise Edition system settings include the **License** module, which is used to manage licenses and confirm that the system remains available. The current page displays the license `ID`, `Start time`, `Expiry time`, and `Status`, and provides **Add license**.
|
||||
|
||||
Administrators should regularly check license status and expiration time to avoid license expiration affecting Enterprise Edition capabilities. After adding or updating a license, confirm that `Status` is normal.
|
||||
|
||||
|
||||
|
||||
## Configure System Email
|
||||
|
||||
`SMTP` (Simple Mail Transfer Protocol) configures the system email sending service. After successful configuration, the system can send verification codes, password reset emails, notification emails, and other email messages.
|
||||
|
||||
| Configuration item | Required | Description | Example or recommendation |
|
||||
| --- | --- | --- | --- |
|
||||
| `Server` | Yes | SMTP mail server address. | `smtp.example.com` |
|
||||
| `Port` | Yes | SMTP service port. Keep it consistent with the SSL/TLS configuration. | SSL: `465`; TLS: `587`; no encryption: `25` (generally not recommended). |
|
||||
| `Timeout (seconds)` | Yes | SMTP connection timeout, in seconds. | Keep the default value `10`. |
|
||||
| `Username` | Yes | Email account used for sending mail. | `your-email@example.com` |
|
||||
| `Password` | Yes | Email login password or SMTP authorization code. Some email providers require an authorization code instead of the login password. | Fill in according to your email provider's requirements. |
|
||||
| `Default sender` | Yes | Sender email address displayed when the system sends email. It is recommended to keep it consistent with `Username`. | `noreply@example.com` |
|
||||
| `SSL` | As needed | Whether to enable SSL encrypted connection. | Usually enabled when using port `465`. |
|
||||
| `TLS` | As needed | Whether to enable TLS (STARTTLS) encrypted connection. | Usually enabled when using port `587`. |
|
||||
| `Test connection` | Recommended | After configuration, click **Test connection** to verify that the SMTP service can connect normally. | Save the configuration only after the test succeeds. |
|
||||
|
||||
Different email providers use different server addresses, ports, and authentication methods. Configure SMTP according to the parameters provided by your email provider. Usually, you only need to enable either SSL or TLS. Fill in the configuration according to the email provider's guidance.
|
||||
|
||||
|
||||
|
||||
## Configure System Notifications
|
||||
|
||||
`Notification` manages system notification content and enablement status. Administrators can enter notification content in `Content` and use `Enable` to control whether the notification takes effect. This feature applies to system announcements, maintenance notices, downtime notices, or other information that needs to be displayed uniformly to users.
|
||||
|
||||
1. Go to the **Settings** page.
|
||||
2. Find the **Notification** area.
|
||||
3. Enter the content to display in `Content`.
|
||||
4. Turn on the `Enable` switch.
|
||||
5. Click **Save**.
|
||||
|
||||
|
||||
|
||||
## Set Model Provider Page Visibility Scope
|
||||
|
||||
`ExposeModelProvider` controls whether the model provider page is displayed to non-administrator users. When enabled, non-administrator users can also see the `Model Provider` page entry. When disabled, the page is visible only to users with corresponding management permissions.
|
||||
|
||||
1. Go to the **Settings** page.
|
||||
2. Find the **ExposeModelProvider** area.
|
||||
3. Turn the `Enable` switch on or off according to the enterprise permission policy.
|
||||
4. Click **Save**.
|
||||
|
||||
|
||||
|
||||
## Enable Email Verification
|
||||
|
||||
`EmailVerification` controls the registration email verification code feature. When enabled, the system sends a verification code from the default email account to the user's registration email address to verify that the registration email is genuine.
|
||||
|
||||
1. Go to the **Settings** page.
|
||||
2. Confirm that SMTP has been configured correctly and that **Test connection** passed.
|
||||
3. Find the **EmailVerification** area.
|
||||
4. Turn on the `Enable` switch.
|
||||
5. Click **Save**.
|
||||
|
||||
|
||||
|
||||
## Configure SSO Identity Providers
|
||||
|
||||
`SSO provider` selects a unified login identity provider for the organization. Administrators can choose one identity provider mode from `None`, `Cloud IDP`, and `LDAP`.
|
||||
|
||||
`Cloud IDP` configures a third-party cloud identity provider. The current page provides `Google`, `GitHub`, and `Feishu`. `LDAP` configures an enterprise directory identity provider and is suitable for organizations that use internal directory services.
|
||||
|
||||
1. Go to the **SSO provider** page.
|
||||
2. Select `None`, `Cloud IDP`, or `LDAP` according to the organization's identity management method.
|
||||
3. If you select `Cloud IDP`, enable the corresponding identity provider from `Google`, `GitHub`, and `Feishu`.
|
||||
4. If you select `LDAP`, enable the default LDAP configuration or click **Add** to add a new LDAP configuration.
|
||||
5. Click the settings button on the right side of the corresponding identity provider and fill in the identity provider parameters as required by the page.
|
||||
6. After configuration, verify the login flow with a test account before switching to production use.
|
||||
|
||||
**Note:** Before switching the production identity provider, make sure at least one administrator login method remains available. Otherwise, a configuration error may prevent administrators from entering the Admin UI.
|
||||
110
docs/administrator/admin/admin_ui/manage_user_accounts.md
Normal file
110
docs/administrator/admin/admin_ui/manage_user_accounts.md
Normal file
@@ -0,0 +1,110 @@
|
||||
---
|
||||
sidebar_position: 3
|
||||
sidebar_label: "Manage User Accounts"
|
||||
---
|
||||
|
||||
# Manage User Accounts
|
||||
|
||||
## View and Search Users
|
||||
|
||||
User accounts are managed on the **User management** page. Administrators can view the user list, including `Email`, `Nickname`, `Status`, `User type`, and `Last login time`. The current Enterprise Edition page also displays `Role`.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Use the search box in the upper-right corner to search users by `Email` or `Nickname`. You can also filter `Active` or `Inactive` users by `Status`. In Enterprise Edition, you can also filter users by `Role`.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Create a New User
|
||||
|
||||
To create an account for a new member, go to **User management** and click **New user**. In the dialog, fill in `Email`, `Password`, and `Confirm password`. The current Enterprise Edition page also allows you to select a `Role` when creating a user.
|
||||
|
||||
1. Go to the **User management** page.
|
||||
2. Click **New user**.
|
||||
3. Enter the user's `Email`.
|
||||
4. Enter the initial password.
|
||||
5. Enter the same password again in `Confirm password`.
|
||||
6. In Enterprise Edition, select a `Role` according to the user's responsibilities.
|
||||
7. Click **Confirm** to create the account.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
After creation, return to the user list and confirm that the account appears, and that its status and role match expectations. Then send the login information to the user through a secure channel.
|
||||
|
||||
**Caution:** `Email` must use a valid email format. After email verification is enabled, users must complete email verification before they can use the account normally. If email verification is not enabled, the system only validates the email format.
|
||||
|
||||
When creating a new user, the password and confirmation password must match. The frontend validation for the current create-user form requires at least 6 characters. Password reset requires a new password of at least 8 characters. In production environments, use a stronger unified password policy. In Enterprise Edition, `Role` affects the resources and operations a user can access, so confirm role permissions before creating the account.
|
||||
|
||||
## Disable or Restore an Account
|
||||
|
||||
The `Status` field in the user list controls whether an account can log in to the system.
|
||||
|
||||
| Status | Meaning |
|
||||
| --- | --- |
|
||||
| `Active` | The account is enabled and can log in and use the system normally. |
|
||||
| `Inactive` | The account is disabled. The user cannot log in, but the account and related data are retained. |
|
||||
|
||||
1. Go to the **User management** page and find the target user in the user list.
|
||||
2. In the `Status` column of that user's row, click the current status dropdown and select `Active` or `Inactive` as needed.
|
||||
|
||||
|
||||
|
||||
**Caution:** The currently logged-in administrator cannot disable their own account. Disabling an account does not delete user data; it only prevents the user from logging in. If you need to permanently remove a user, confirm that the account no longer needs to be retained before deleting it.
|
||||
|
||||
## Set Backend Administrator Identity
|
||||
|
||||
`User type` distinguishes `Normal` from `Superuser`. `Normal` is a regular user type. `Superuser` can enter the Admin UI and perform system-level management operations.
|
||||
|
||||
1. Find the target user on the **User management** page.
|
||||
2. Open the selector in the `User type` column.
|
||||
3. Select `Normal` or `Superuser`.
|
||||
4. Wait for the system to submit the change and refresh the user list.
|
||||
|
||||
|
||||
|
||||
**Caution:** The currently logged-in administrator cannot modify their own `Superuser` type in the list.
|
||||
|
||||
## Reset User Passwords
|
||||
|
||||
When a user forgets their password or must be forced to change it, administrators can reset another user's password from **Actions** in the user list. After the reset-password dialog opens, the page displays the target user's `Email` and requires `New password` and `Confirm new password`.
|
||||
|
||||
1. Find the target user on the **User management** page. Hover over the user row to display **Actions**, then click the reset-password button.
|
||||
2. Confirm that the `Email` in the dialog is the target user.
|
||||
3. Enter the new password and confirm it again.
|
||||
4. Click **Change password**.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**Caution:** The currently logged-in administrator cannot reset their own password through list **Actions**.
|
||||
|
||||
## Delete Users
|
||||
|
||||
When a user no longer needs system access and related resources have been handed over, administrators can delete the user from **Actions** in the user list. Before deletion, the page displays a confirmation dialog and shows the `Email` of the user to be deleted.
|
||||
|
||||
1. Find the target user on the **User management** page. Hover over the user row to display **Actions**, then click the delete button.
|
||||
2. Check the user's `Email` in the confirmation dialog.
|
||||
3. Click **Delete** to delete the user.
|
||||
|
||||
|
||||
|
||||
**Caution:** The currently logged-in administrator cannot delete their own account through list **Actions**.
|
||||
|
||||
Deleting a user is a high-risk operation. Before doing it, confirm whether the user's related data, knowledge bases, Agents, files, API keys, and business responsibilities have been handed over. If you only need to temporarily prevent login, change the account status to `Inactive` first.
|
||||
|
||||
## View User Details and Resource Impact
|
||||
|
||||
Click the detail button in **Actions** on the user list to enter the user detail page. The detail page displays the user's `Email`, account status, Enterprise Edition role, `Last login time`, `Create time`, `Last update time`, `Language`, `Is anonymous`, and `Is superuser`.
|
||||
|
||||
The current Enterprise Edition detail page also displays the user's associated `Dataset` and `Agent` resources by resource type. Before disabling, deleting, downgrading `Superuser`, or adjusting an Enterprise Edition role, administrators should check the detail page to confirm whether the user still has important resources or recent login activity.
|
||||
|
||||
|
||||
@@ -0,0 +1,68 @@
|
||||
---
|
||||
sidebar_position: 8
|
||||
sidebar_label: "View Monitoring Dashboard (Enterprise Edition)"
|
||||
---
|
||||
|
||||
# View Monitoring Dashboard (Enterprise Edition)
|
||||
|
||||
## Use Monitoring to View System Monitoring
|
||||
|
||||
Enterprise Edition provides a **Monitoring** page in the Admin UI for viewing system monitoring data and alert status. Administrators can query metrics, view alert rules, check target collection status, and view Prometheus runtime information on this page.
|
||||
|
||||
|
||||
|
||||
## Query Monitoring Metrics
|
||||
|
||||
Select **Query** at the top of the **Monitoring** page to enter the metric query page. The page provides an expression input box. Administrators can enter a Prometheus query expression and click **Execute**.
|
||||
|
||||
Query results can be viewed through **Table**, **Graph**, and **Explain**:
|
||||
|
||||
| View | Description |
|
||||
| --- | --- |
|
||||
| `Table` | View query results in table form. |
|
||||
| `Graph` | View trend charts. |
|
||||
| `Explain` | View an explanation of the query expression. |
|
||||
|
||||
The page also provides `Evaluation time`, which is used to view or adjust the query evaluation time. To query multiple expressions at the same time, click **Add query** to add a new query area.
|
||||
|
||||
1. Go to the **Monitoring** page.
|
||||
2. Select **Query**.
|
||||
3. Enter the query expression in the input box.
|
||||
4. Click **Execute**.
|
||||
5. Switch between **Table**, **Graph**, and **Explain** as needed to view results.
|
||||
6. To add query conditions, click **Add query**.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**Note:** The **Query** page is used to query monitoring metrics, not to modify business data. Query expressions must comply with Prometheus query rules. Complex queries may bring computing overhead, so avoid frequently running high-cost queries in production environments.
|
||||
|
||||
## View Alert Rules and Alert Status
|
||||
|
||||
Select **Alerts** to view alert rules currently configured in Prometheus. The page supports filtering alert groups by `rule group state` and searching rules by `rule name` or `labels`.
|
||||
|
||||
The alerts page displays content by rule group. Each rule group shows the rule group name, rule file path, and current status statistics, such as `INACTIVE` or `FIRING`. Administrators can expand a specific rule to check whether it is currently triggered.
|
||||
|
||||
|
||||
|
||||
**Note:** The **Alerts** page displays alert rules loaded by Prometheus in the current deployment. `INACTIVE` means the rule is not currently triggered. `FIRING` means the rule is currently triggered, and administrators need to further troubleshoot with service status, logs, and the deployment environment. Query expressions must comply with Prometheus query rules. Complex queries may bring computing overhead, so avoid frequently running high-cost queries in production environments.
|
||||
|
||||
## View Prometheus Monitoring Status
|
||||
|
||||
Prometheus provides rich status pages. Administrators can use the **Status** menu to view collection targets, service discovery, rule execution, the time-series database, system configuration, and runtime status. This helps quickly confirm whether the monitoring service is running normally and assists in locating monitoring configuration or collection exceptions.
|
||||
|
||||
| Menu | Function | Main content | Administrator use | Notes |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `Target health` | View the health status of Prometheus collection targets. | Displays collection targets by `Job`, including `Endpoint`, `Labels`, `Last Scrape`, `State`, and other information. `State` is `UP` when target collection is normal. | Confirm whether Elasticsearch, MySQL, Redis, MinIO, RabbitMQ, Prometheus, and other components can be monitored normally. | `Target Health` only indicates metric collection status and does not fully represent business service status. If the status is `DOWN`, check the exporter, network connectivity, scrape address, and Prometheus configuration. |
|
||||
| `Rule health` | View the runtime status of alerting rules and recording rules. | Displays rule groups, rule files, recent execution time (`Last Run`), execution duration (`Took`), execution period (`Every`), and rule status. | Confirm whether rules run at the expected interval and troubleshoot rule exceptions or invalid rules. | `OK` means the latest rule evaluation succeeded. |
|
||||
| `Service discovery` | View Prometheus service discovery results. | Displays each job's `Discovered Labels` and `Target Labels`, and supports viewing the relabeling process. | Troubleshoot abnormal target discovery, incorrect label configuration, or abnormal metric classification. | When a new monitoring target does not take effect, check this page first. |
|
||||
| `Runtime & build information` | View Prometheus runtime environment and build information. | Includes `Version`, `Build Date`, `Go Version`, `Start Time`, `Hostname`, `Storage Retention`, `Configuration Reload`, and other information. | Confirm the current runtime version, startup time, configuration loading status, and storage retention policy. | Commonly used to troubleshoot Prometheus service runtime status. |
|
||||
| `TSDB status` | View the runtime status of the Prometheus time-series database (TSDB). | Includes `Series`, `Chunks`, `Label Pairs`, time range, labels, metrics, memory usage, and other statistics. | View monitoring data scale, storage status, and database runtime status. | The page provides operations such as `Delete Series` and `Clean Tombstones`. It is recommended only for status viewing. Do not execute delete or cleanup operations casually, or historical monitoring data may be lost. |
|
||||
| `Command-line flags` | View the current Prometheus startup parameters. | Displays the configuration file path, listen address, storage path, retention time, query parameters, and other startup parameters. | Check whether the actual Prometheus startup parameters match deployment expectations. | Suitable for troubleshooting configuration file paths, data directories, listen ports, and similar issues. |
|
||||
| `Configuration` | View the currently loaded Prometheus configuration. | Includes complete configuration content such as `global`, `scrape_configs`, `rule_files`, and `alerting`. | Confirm whether scrape jobs, scrape intervals, alert rules, and scrape configurations have been loaded correctly. | This page is for viewing only and does not support online modification. Reload or restart Prometheus after modifying the configuration. |
|
||||
| `Alertmanager discovery` | View Alertmanager instances discovered by Prometheus. | Displays Alertmanager service addresses and connection status. | Confirm whether Prometheus has successfully connected to Alertmanager. | If Alertmanager is not configured, this page may be empty. |
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user