KJZH001/nezhahq.github.io
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

优化更新中英文文档-常见问题板块

Browse Source
This commit is contained in:
Kris
2024-05-14 00:09:33 +02:00
parent b38e3197fc
commit a8369feb86
14 changed files with 133 additions and 105 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/en_US/guide/q2.md
+4 -4
View File
@@ -1,4 +1,4 @@
#### Let the Agent start/on-line, and the self-test process of the problem
1. Run `//opt/nezha/agent/nezha-agent -s IP/Domin(Panel IP or Domain not connected to CDN):port(Panel RPC port) -p secret(Agent Secret) -d` Check the logs to see if the timeout is due to a DNS problem or poor network
2. `nc -v domain/IP port(Panel RPC port)` or `telnet domain/IP port(Panel RPC port)` to check if it' s a network problem, check the inbound and outbound firewall between the local machine and the panel server, if you can' t determine the problem you can check it with the port checking tool provided by <https://port.ping.pe/>
3. If the above steps work and the Agent is online, please try to turn off SELinux on the panel server. [How to close SELinux？](https://www.google.com/search?q=How+to+disable+SELinux)
# Agent Startup/Online Troubleshooting Process
1. Directly execute `/opt/nezha/agent/nezha-agent -s DashboardIP or non-CDN domain:RPCPort -p AgentKey -d` to check if the logs indicate timeouts due to DNS or poor network conditions.
2. Use `nc -v Domain/IP RPCPort` or `telnet Domain/IP RPCPort` to check for network issues, inspect the inbound and outbound firewalls of the local machine and the panel server. If you cannot determine the issue, you can use the port checking tool provided by <https://port.ping.pe/>.
3. If the above steps indicate no issues but the Agent still does not go online correctly, try disabling SELinux. [How to disable SELinux?](https://www.google.com/search?q=disable+SELINUX)
docs/en_US/guide/q3.md
+21 -21
View File
@@ -1,19 +1,19 @@
#### Reverse Proxy gRPC Port (support Cloudflare CDN)
Use Nginx or Caddy to reverse proxy gRPC
# Reverse Proxy gRPC Port (Supports Cloudflare CDN)
Using Nginx or Caddy to reverse proxy gRPC
- Nginx configuration files
- Nginx Configuration
```nginx
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name data.example.com; # The domain name where the Agent connects to Dashboard
server_name data.example.com; # Your domain that the Agent uses to connect to the Dashboard
ssl_certificate /data/letsencrypt/fullchain.pem; # Your domain certificate path
ssl_certificate_key /data/letsencrypt/key.pem; # Your domain's private key path
ssl_certificate /data/letsencrypt/fullchain.pem; # Path to your domain certificate
ssl_certificate_key /data/letsencrypt/key.pem; # Path to your domain private key
ssl_stapling on;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m; # This line may conflict with other configuration files. If a conflict occurs, please comment out this line
ssl_session_cache shared:SSL:10m; # This might conflict with other configuration files; comment it out if there are conflicts
ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3;
underscores_in_headers on;
@@ -36,10 +36,10 @@ upstream grpcservers {
}
```
- Caddy configuration files
- Caddy Configuration
```
data.example.com:443 { # The domain name where the Agent connects to Dashboard
data.example.com:443 { # Your domain that the Agent uses to connect to the Dashboard
reverse_proxy {
to localhost:5555
transport http {
@@ -49,23 +49,23 @@ data.example.com:443 { # The domain name where the Agent connects to Dashboard
}
```
Dashboard Configuration
Dashboard Configuration
- First login to the Dashboard and enter the admin panel, go to the settings page, fill in the `CDN Bypassed Domain/IP` with the domain name you configured in Nginx or Caddy, for example `data.example.com`, and save it.
- Then open the `/opt/nezha/dashboard/data/config.yaml` file in the panel server and change `proxygrpcport` to the port that Nginx or Caddy is listening on, such as `443` as set in the previous step. Since we have SSL/TLS enabled in Nginx or Caddy, we need to set `tls` to `true`, restart the panel when you are done.
- First, log in to the Dashboard and go to the settings page. In the `Non-CDN Dashboard server domain/IP` field, enter the domain configured in Nginx or Caddy in the previous step, for example, `data.example.com`, and save it.
- Then, on the Dashboard server, open the `/opt/nezha/dashboard/data/config.yaml` file. Modify `proxygrpcport` to the port that Nginx or Caddy is listening to, for example, `443`. Since we enabled SSL/TLS in Nginx or Caddy, set `tls` to `true`. After making these changes, restart the Dashboard.
Agent Configuration
- Log in to the admin panel, copy the one-click install command, and run the one-click install command on the corresponding server to reinstall the agent.
- Log in to the Dashboard management backend, copy the one-click installation command, and execute it on the corresponding server to reinstall the agent.
Enable Cloudflare CDN (optional)
Enabling Cloudflare CDN (Optional)
According to Cloudflare gRPC requirements: gRPC services must listen on port 443 and must support TLS and HTTP/2.
So if you need to enable CDN, you must use port 443 when configuring Nginx or Caddy reverse proxy gRPC and configure the certificate (Caddy will automatically apply and configure the certificate).
According to Cloudflare gRPC requirements: gRPC services must listen on port 443 and must support TLS and HTTP/2.
So, to enable CDN, you must use port 443 when configuring Nginx or Caddy to reverse proxy gRPC and configure the certificate (Caddy will automatically apply and configure the certificate).
- Log in to Cloudflare and select the domain you are using. Go to the `Network` page and turn on the `gRPC` switch, then go to the `DNS` page, find the resolution record of the domain with gRPC configuration, and turn on the orange cloud icon to enable CDN.
- Log in to Cloudflare, select the domain you are using. Go to the `Network` tab and turn on the `gRPC` switch. Then, go to the `DNS` tab, find the DNS record for the domain configured in Nginx or Caddy to reverse proxy gRPC, and enable the CDN by clicking the orange cloud.
After enable `gRPC` at cloudflare, it may not work immediately，so you may need to wait for a while, about 24hour or more. To be test if gRPC work, we can use `curl` and `nezha-agent -d`：
After enabling `gRPC`, it might not be available immediately, and you may need to wait for a while. You can use `curl` and `nezha-agent -d` to verify:
```bash
localhost:~/agent# curl -H "content-type: application/grpc+proto" -H "authorization: Bearer test" https://xxx.xxx.ovh -v
@@ -102,8 +102,8 @@ localhost:~/agent# curl -H "content-type: application/grpc+proto" -H "authorizat
< alt-svc: h3=":443"; ma=86400
<
* Connection #0 to host xxx.xxx.ovh left intact
localhost:~/agent# /opt/nezha/agent/nezha-agent -s xxx.xxx.ovh:443 -p YOUR_KEY --tls -d
localhost:~/agent# /opt/nezha/agent/nezha-agent -s nezha.xxx.xxx:443 -p YOUR_KEY --tls -d
NEZHA@2023-12-20 05:14:00>> 检查更新： 0.15.14
NEZHA@2023-12-20 05:14:01>> 上报系统信息失败： rpc error: code = Unknown desc = EOF # Edit GRPCHost and TLS at /opt/nezha/dashboard/data/config.yaml.
NEZHA@2023-12-20 05:14:01>> 上报系统信息失败： rpc error: code = Unknown desc = EOF # You need to modify the GRPCHost and TLS options in the Dashboard /opt/nezha/dashboard/data/config.yaml
NEZHA@2023-12-20 05:14:01>> Error to close connection ...
```
```
docs/en_US/guide/q4.md
+4 -3
View File
@@ -1,3 +1,4 @@
#### Real-time channel disconnection/online terminal connection failure
+ If you are using a CDN, please make sure that the CDN provider provides WebSocket service and that WebSocket is enabled
+ Confirm that you are using a reverse proxy requires special configuration of the WebSocket for the `/ws` and `/terminal` paths, you can [click here](/en_US/guide/dashboard.html#configure-reverse-proxy) to see the reverse proxy configuration
# Real-Time Channel Disconnection/Online Terminal Connection Failure
- If you are using a CDN, ensure that the CDN provider offers WebSocket services and that WebSocket is enabled.
- Confirm that your reverse proxy rules have special configurations for the `/ws` and `/terminal` paths. You can [click here](/en_US/guide/dashboard.html#configure-reverse-proxy) to view the reverse proxy configuration.
docs/en_US/guide/q5.md
+4 -4
View File
@@ -1,5 +1,5 @@
#### How do I migrate my data to the new server and restore my backups?
# How to Perform Data Migration and Backup Recovery?
1. First use the one-click script and select `Stop Panel`
2. Compress the `/opt/nezha` folder to the same path as the new server
3. Run the one-click script in the new server, select `Launch Panel`
1. Run the one-click script and choose `Stop Dashboard`.
2. On the old server, package the `/opt/nezha` folder, copy it to the same location in the new environment, and extract it.
3. In the new server, run the one-click script and choose `Start Dashboard`.
docs/en_US/guide/q6.md
+10 -11
View File
@@ -1,12 +1,11 @@
#### How to set up a monthly reset of transfer statistics?
In the home page, the traffic statistics will be reset when the server is restarted.
If you want to set the traffic statistics to be reset once a month, you can do it like this:
# How to Reset Traffic Statistics Monthly?
1. Go to the ` Notification` page of the admin panel
2. Refer to [this document](/en_US/guide/notifications.html#special-any-cycle-transfer-notification) to create a monthly transfer statistics notification
3. Return to the home page and you can see the monthly transfer statistics in the `Service` page, where the statistics will not be reset when the server is restarted
::: tip
This method can be set to any period, including and not limited to hourly/daily/weekly/monthly/yearly reset transfer statistics, very flexible!
:::
The traffic statistics on the homepage reset every time the server restarts. To achieve a monthly reset of the traffic counter, you can do the following:
1. Go to the `Notification` page in the management panel.
2. Refer to [this document](/en_US/guide/notifications.html#special-any-cycle-transfer-notification) to create a monthly traffic notification.
3. Return to the homepage and go to the `Services` page, where you can see the monthly traffic statistics. The statistics here will not reset when the server restarts.
::: tip
This method allows you to set any period, including but not limited to hourly, daily, weekly, monthly, or yearly traffic statistics reset, offering great flexibility!
:::
docs/en_US/guide/q7.md
+22 -12
View File
@@ -1,17 +1,27 @@
## Customize Agent
# Custom Agent Monitoring Projects
#### Customize the NIC and hard drive partitions to be monitored
## Customizing Monitored Network Interfaces and Disk Partitions
* Run `/opt/nezha/agent/nezha-agent --edit-agent-config` to select a custom NIC and partition, and then restart Agent
Execute the following command to select custom network interfaces and partitions, then restart the Agent for the changes to take effect:
#### Other Flags
```bash
/opt/nezha/agent/nezha-agent --edit-agent-config
```
Run `./nezha-agent --help` to view supported flags，if you are already using the one-click script, you can edit `/etc/systemd/system/nezha-agent.service`，at the end of this line `ExecStart=` add:
## Other Runtime Parameters
- `--report-delay` System information reporting interval, default is 1 second, can be set to 3 to reduce the system resource usage on the agent side (configuration range 1-4)
- `--skip-conn` Not monitoring the number of connections, if it is a server with a large number of connections, the CPU usage will be high. It is recommended to set this to reduce CPU usage
- `--skip-procs` Disable monitoring the number of processes can also reduce CPU and memory usage
- `--disable-auto-update` Disable **Automatic Update** Agent (security feature)
- `--disable-force-update` Disable **Forced Update** Agent (security feature)
- `--disable-command-execute` Disable execution of scheduled tasks, disallow WebShell (security feature)
- `--tls` Enable SSL/TLS encryption (If you are using nginx to reverse proxy Agent´s grpc connections, and if nginx has SSL/TLS enabled, you need to enable this configuration)
To view the supported parameters, execute:
```bash
./nezha-agent --help
```
If you installed the Agent using the one-click script, you can edit `/etc/systemd/system/nezha-agent.service` and add the following parameters at the end of the `ExecStart=` line:
- `--report-delay`: Controls the interval for reporting system information. The default is 1 second. You can set it to 3 to further reduce the agent's system resource usage (configuration range: 1-4).
- `--skip-conn`: Does not monitor connection counts. Recommended for servers with high connection density or high CPU usage.
- `--skip-procs`: Does not monitor process counts, which can also reduce Agent resource usage.
- `--disable-auto-update`: Disables **automatic updates** for the Agent (security feature).
- `--disable-force-update`: Disables **forced updates** for the Agent (security feature).
- `--disable-command-execute`: Disables the execution of scheduled tasks and the opening of the online terminal on the Agent (security feature).
- `--tls`: Enables SSL/TLS encryption (required if you use nginx to reverse proxy the Agent's gRPC connection and nginx has SSL/TLS enabled).
docs/en_US/guide/q8.md
+23 -16
View File
@@ -1,29 +1,36 @@
## Example Config：
If you encounter issues logging in as an administrator using Github, Gitlab, or Gitee, you may consider switching to Cloudflare Access as the OAuth2 provider.
## Example Configuration:
```yaml
Oauth2:
Admin: 701b9ea6-9f56-48cd-af3e-cbb4bfc1475c
ClientID: 3516291f53eca9b4901a01337e41be7dc52f565c8657d08a3fddb2178d13c5bf
ClientSecret: 0568b67c7b6d0ed51c663e2fe935683007c28f947a27b7bd47a5ad3d8b56fb67
Endpoint: "https://akkia.cloudflareaccess.com"
Endpoint: "https://xxxxx.cloudflareaccess.com"
Type: cloudflare
```
## Config Detail：
## Configuration Description:
| Name | How to Obtain |
|-----------------------|-----------------------------------------------------------------------------|
| Admin | `My Team` -> `Users` -> `<Specific User>` -> `User ID` |
| ClientID/ClientSecret | `Access` -> `Application` -> `Add an Application` <br/> -> `SaaS` -> `OIDC` |
| Endpoint | `Access` -> `Application` -> `Application URL` -> `Only Schema&Domain part` |
| Parameter | Retrieval Method |
|-----------------------|---------------------------------------------------------------------------------|
| Admin | `My Team` -> `Users` -> `<specific user>` -> `User ID` |
| ClientID/ClientSecret | `Access` -> `Application` -> `Add an Application` <br/> -> `SaaS` -> `OIDC` |
| Endpoint | `Access` -> `Application` -> `Application URL` -> `Only keep the protocol and domain, no path` |
### Create SaaS-OIDC application
### Creating a SaaS-OIDC Application
Zero Trust Dashboard: https://one.dash.cloudflare.com
Go to Zero Trust Dashboard: https://one.dash.cloudflare.com
1. `Access` -> `Application` -> `Add an Application`;
2. Select `SaaS`, Input your custom application name in `Application` field，select `OIDC` and click `Add application`;
3. Select `openid`, `email`, `profile`, `groups` in `Scopes` field;
4. Input your CallBack URL in `Redirect URLs` field (e.g. `https://monitor.example.com/oauth2/callback`);
5. Record `Client ID`, `Client Secret` and Schemas&Domain part in `Issuer` (e.g. `https://akkia.cloudflareaccess.com`);
6. Modify Dashboard Config ( location: `/opt/nezha/dashboard/data/config.yaml`), and restart Dashboard service;
1. `My Team` -> `Users` -> `<specific user>` -> Get `User ID` and save it;
2. `Access` -> `Application` -> `Add an Application`;
3. Select `SaaS`, enter a custom application name (e.g., nezha) in `Application`, select `OIDC`, and click `Add application`;
4. In `Scopes`, select `openid`, `email`, `profile`, `groups`;
5. Fill in your CallBack URL in `Redirect URLs`, such as `https://dashboard.example.com/oauth2/callback`;
6. Record the `Client ID`, `Client Secret`, and the protocol and domain part of the `Issuer` URL, such as `https://xxxxx.cloudflareaccess.com`;
7. Edit the Dashboard configuration file (usually located at `/opt/nezha/dashboard/data/config.yaml`), modify the `Oauth2` configuration according to the example configuration, and restart the Dashboard service.
### Authentication Policy Configuration
After completing the Dashboard setup, you also need to configure the authentication policy in the Zero Trust Dashboard: `Access` -> `Applications` -> `<application name>` -> `Policies`. You can choose from over ten SSO authentication methods, including email OTP verification, hardware key verification, etc. For detailed configuration, please refer to the [Cloudflare Zero Trust documentation](https://developers.cloudflare.com/cloudflare-one/).