Common installation methods include:

• Binary deployment
• Docker Compose deployment
• Helm deployment

We recommend the binary method first, for the following reasons:

• Nightingale is a single binary file with very few dependencies, making management straightforward. Most people are familiar with systemd, so just using systemd to manage the Nightingale process is sufficient.
• The Docker Compose method has slightly worse performance than the binary method, and it requires additional Docker-related knowledge. Image pulling issues caused by network restrictions in China can also be painful at times.
• The Helm method is used to deploy on Kubernetes, but a monitoring system is a P0-level system. When everything else is down, monitoring must not go down. If deployed on Kubernetes, when Kubernetes fails, monitoring also fails. At that point, other teams may come complaining that you did not plan ahead.

Regardless of the installation method, after installation, the default Nightingale username is root and the password is root.2020. The default listening port for Nightingale is 17000, and the port used by n9e-edge in edge mode is 19000.

If you use edge mode, please make sure to read the Edge Mode in Nightingale Architecture chapter.

FAQ

Cannot query monitoring data

1. Follow the video tutorials to check the configuration.
2. If Prometheus is used as the time-series database (TSDB), data may be unavailable because the remote write receiver is not enabled. In this case, WARNING logs will appear in Nightingale’s logs, indicating that requests to Prometheus’s /api/v1/write interface return 404. The logs will also print the response from Prometheus, suggesting which command-line startup parameters should be added to Prometheus. Typically, newer Prometheus versions require the --web.enable-remote-write-receiver parameter, while older versions require --enable-feature=remote-write-receiver. Restart Prometheus after adding the parameter.

FAQ

Q1: What are the hardware requirements for n9e?

A:

• Small scale (< 100 machines): A single 4C8G machine running the full stack is sufficient;
• Medium scale (100-1000 machines): A separate database + 2 n9e Servers of 8C16G;
• Large scale (1000+): Distributed deployment — n9e-server + n9e-edge + standalone time-series database.

Q2: What are the required dependent components?

A:

• MySQL 5.7+ / PostgreSQL 14+ (metadata);
• Redis 5+ (cache + distributed lock);
• A time-series database (any of Prometheus / VictoriaMetrics / TDengine, etc.).

Q3: Can SQLite be used?

A: For demos / single-user testing, yes. For production it is strongly discouraged — SQLite is not suitable for multi-process access, and concurrent writes from the alert engine will cause issues.

References

• Binary Deployment
• Docker Compose Deployment
• Helm Deployment
• Configuration Reference