How to Deploy N9e: A Step‑by‑Step Guide to Unified Observability

Preface

Observability is a common headache for many small and medium companies, manifested in the need to stitch together multiple open‑source tools, isolated ecosystems, and data silos across tracing, logging, and metrics.

Different open‑source software must be assembled to achieve specific functions, e.g., SkyWalking for tracing, ELK for log collection, Grafana + Prometheus for metrics.

Each tool has its own independent stack, making integration difficult.

Data islands exist where tracing, logs, and metrics operate independently without correlation.

N9e does not claim a single‑unified solution yet; it still relies on separate components, but it provides a unified dashboard where these components can be viewed together, although data correlation is not yet implemented.

Why study N9e? Because it is evolving toward tighter integration.

Compared with Grafana, Grafana excels at panel management while N9e focuses on alert rule management.

N9e can route different alert rules to distinct business groups, preventing alert storms in a single channel.

What does N9e look like?

Below is a screenshot of a deployed system.

The dashboard offers:

Alert management

Time‑series metric queries

Log analysis

Tracing

Alert auto‑healing

User management

…

System Architecture

"A thousand words about architecture are useless without understanding it."

N9e provides two deployment models: a centralized aggregation scheme and an edge‑hybrid mixed scheme.

Centralized Aggregation Scheme

Diagram:

A single N9e cluster receives monitoring data from other regions, requiring good network connectivity between the central cluster and the regions.

Central cluster components:

MySQL – stores configuration and alert events.

Redis – stores JWT tokens and machine metadata.

TSDB – time‑series database for metrics.

N9e – core service handling web requests and the alert engine.

LB – load balancer for multiple N9e instances.

Other regions only need to deploy Categraf, which pushes local monitoring data to the central cluster.

This architecture is simple and low‑maintenance but depends on reliable inter‑datacenter network links.

Edge‑Hybrid Mixed Scheme

Diagram:

This scheme complements the centralized model for poor network conditions:

Time‑series DB, forward gateway, and alert engine are deployed in each region, handling local data while still maintaining a heartbeat connection to the central cluster so the central UI can view remote metrics.

If a Prometheus instance already exists, it can be used directly as a data source.

When deploying TSDB, alert engine, and forward gateway at the edge, ensure they can access the shared database for rule synchronization and object registration.

Note: In this scheme, network issues may still affect performance.

Single‑Node Deployment

Why choose a single‑node setup? Deploying components side‑by‑side helps understand N9e’s runtime model.

Tip: The author uses Ubuntu 22.04.1.

Install MySQL

Tip: MariaDB is used for quick installation.

<code># Update package index
sudo apt-get update
# Upgrade packages
sudo apt-get upgrade
# Install MariaDB
sudo apt-get install mariadb-server-10.6</code>

After installation, set a root password:

<code># Connect to the database
sudo mysql
# Grant privileges and set password
GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY '1234';
FLUSH PRIVILEGES;</code>

Install Redis

<code># Update package index
sudo apt-get update
# Upgrade packages
sudo apt-get upgrade
# Install Redis
sudo apt install redis-server</code>

Redis starts automatically.

Install TSDB

Several TSDB options exist (Prometheus, M3DB, VictoriaMetrics, InfluxDB, Thanos). This guide uses VictoriaMetrics.

<code># Download binary package
wget https://github.com/VictoriaMetrics/VictoriaMetrics/releases/download/v1.90.0/victoria-metrics-linux-amd64-v1.90.0.tar.gz
# Extract
tar xf victoria-metrics-linux-amd64-v1.90.0.tar.gz
# Start
nohup ./victoria-metrics-prod &>victoria.log &</code>

Verify the service is listening on port 8428.

Install N9e

<code># Download latest binary package
wget https://github.com/ccfos/nightingale/releases/download/v6.0.0-ga.3/n9e-v6.0.0-ga.3-linux-amd64.tar.gz
# Create directory and extract
mkdir n9e
tar xf n9e-v6.0.0-ga.3-linux-amd64.tar.gz -C n9e/
# List extracted files (example output omitted)</code>

Import the database schema:

<code># Import DB
mysql -uroot -p < n9e.sql</code>

Edit

etc/config.toml

to set the push gateway URL:

<code>[[Pushgw.Writers]]
# Url = "http://127.0.0.1:8480/insert/0/prometheus/api/v1/write"
Url = "http://127.0.0.1:8428/api/v1/write"
</code>

Start the N9e service:

<code># Start service
nohup ./n9e &>n9e.log &
# Verify port 17000 is listening
ss -ntl | grep 17000
</code>

Open

http://127.0.0.1:17000

in a browser and log in with username

root

and password

root.2020

.

Install Categraf

Categraf is a monitoring agent that pushes collected data to the TSDB.

<code># Download
wget https://download.flashcat.cloud/categraf-v0.2.38-linux-amd64.tar.gz
# Extract
tar xf categraf-v0.2.38-linux-amd64.tar.gz
# Enter directory
cd categraf-v0.2.38-linux-amd64/
</code>

Modify

conf/config.toml

to point to N9e:

<code>[[writers]]
url = "http://127.0.0.1:17000/prometheus/v1/write"

[heartbeat]
enable = true
</code>

Start Categraf:

<code>nohup ./categraf &>categraf.log &</code>

Add Data Source

After deployment, no time‑series data appears until a data source is added. In the system settings → Data Sources, add a new source as shown.

Once added, metrics become visible.

The built‑in dashboards can also display host monitoring data.

Conclusion

This article provides an introductory overview of Nightingale (N9e), outlines its overall architecture, and walks readers through a complete 0‑to‑1 installation, helping them gain a clear understanding of its components.

The platform has progressed to version 6, adding features such as ELK and Jaeger integrations, with further updates planned.