Alibaba Sentinel 1.8.10

In the AWS Marketplace listing, choose Continue to Subscribe, then Continue to Configuration. Pick Alibaba Sentinel 1.8.10 on Ubuntu 24.04 as the software version, select your Region, and choose Launch through EC2. Then choose m5.large, your key pair, a subnet and a security group as described above.

To launch with the AWS CLI instead, replace the values in angle brackets:

aws ec2 run-instances --region <region> --image-id <ami-id-from-the-listing> \
  --instance-type m5.large --key-name <your-key-pair> \
  --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=sentinel-dashboard}]'

Connect over SSH as the ubuntu user, the default user for Alibaba Sentinel 1.8.10 on Ubuntu 24.04:

ssh -i <your-key.pem> ubuntu@<public-ip>

First boot takes a few seconds, and the dashboard needs about fifteen seconds more to start. After that, confirm that the three units are active:

systemctl is-active sentinel-dashboard-firstboot sentinel-dashboard nginx

active active active

The dashboard (the java process) listens on loopback only, and nginx serves port 443:

sudo ss -tlnp | awk 'NR==1 || /java|nginx|sshd/' | awk '{print $1, $4, $6}' | sed -E 's/,pid=[0-9]+,fd=[0-9]+//g'

State Local Peer LISTEN 127.0.0.1:8080 users:(("java")) LISTEN 0.0.0.0:22 users:(("sshd"),("systemd")) LISTEN 0.0.0.0:443 users:(("nginx"),("nginx"),("nginx")) LISTEN [::]:22 users:(("sshd"),("systemd")) LISTEN [::]:443 users:(("nginx"),("nginx"),("nginx"))

Check the release on the image and the Java runtime:

sha256sum /opt/sentinel-dashboard/lib/sentinel-dashboard.jar unzip -p /opt/sentinel-dashboard/lib/sentinel-dashboard.jar BOOT-INF/classes/application.properties | grep '^sentinel.dashboard.version' java -version 2>&1 | head -2

9e0d11bc30006c9f70cde982b456fc7bd03b94ec9ab5c45c034eb66b968ca19e /opt/sentinel-dashboard/lib/sentinel-dashboard.jar sentinel.dashboard.version=1.8.10 openjdk version "17.0.20.1" 2026-08-18 OpenJDK Runtime Environment (build 17.0.20.1+1-1-24.04-Ubuntu)

sudo cat /root/sentinel-dashboard-credentials.txt

The file holds the address the dashboard is served as, which is your instance's public DNS name by default. It also holds the login generated on this instance:

# Sentinel Dashboard 1.8.10 - generated on first boot by sentinel-dashboard-firstboot.service
# This login is unique to this instance; none was baked into the image, and the upstream default
# sentinel/sentinel is refused. Keep this file secret. SENTINEL_DASHBOARD_URL=https://ec2-<public-ip-dashed>.<region>.compute.amazonaws.com/ SENTINEL_DASHBOARD_USER=admin-<8 hex characters> SENTINEL_DASHBOARD_PASSWORD=<32 letters and digits>
#
# Open SENTINEL_DASHBOARD_URL in a browser (self-signed certificate minted on this instance's first boot) # and sign in with the user and password above. # Point Sentinel clients at it with: -Dcsp.sentinel.dashboard.server=https://<this instance's private IP>
# Registration allow list: /etc/nginx/sentinel-registry-allow.conf
# Change the login:
sudo sentinel-set-password
# Change the name it serves as:
sudo sentinel-set-hostname <your-dns-name>
# User guide: https://secureanycloud.com/stacks/alibaba-sentinel-1-8-10/

Open SENTINEL_DASHBOARD_URL in your browser. The certificate is self-signed and generated on your instance, so accept the browser warning once, or install your own certificate (Step 8).

The dashboard's interface is in Chinese, as upstream ships it. On the login page, 用户 is the username field, 密码 is the password field and 登录 signs you in.

After you sign in, the left-hand menu lists every application that has registered. The count of healthy machines out of all machines appears in brackets. Under an application, you find these pages:

• 实时监控: real-time monitoring
• 簇点链路: the resources the client has seen
• 流控规则: flow rules
• 熔断规则: circuit breaking rules
• 热点规则: hot parameter rules
• 系统规则: system rules
• 授权规则: authorisation rules
• 集群流控: cluster flow control
• 机器列表: the machine list

注销 at the top right signs you out.

Each service that uses the Sentinel client library needs three Java system properties, or the same keys in its sentinel.properties. Use the dashboard's private IP address and https://. The Sentinel client accepts the dashboard's self-signed certificate:

-Dcsp.sentinel.dashboard.server=https://<dashboard-private-ip> -Dproject.name=<your-service-name> -Dcsp.sentinel.api.port=8719

The client sends a heartbeat to the dashboard every ten seconds. The dashboard connects back to the client's command port (8719 above) to read metrics and push rules, so the client's security group must allow TCP 8719 from the dashboard.

A heartbeat is a plain HTTPS POST. The command below sends one from the instance's own private address, the way a client would, and registers a machine called demo-service:

H=$(sudo sed -n 's#^SENTINEL_DASHBOARD_URL=https://\([^/]*\)/#\1#p' /root/sentinel-dashboard-credentials.txt)
PRIV=$(hostname -I | awk '{print $1}')
curl -sk --resolve "$H:443:$PRIV" -X POST "https://$H/registry/machine" \
  --data "app=demo-service&ip=$PRIV&port=8719&hostname=$(hostname)&v=1.8.10&version=$(date +%s%3N)"; echo

{"success":true,"code":0,"msg":"success","data":null}

The machine appears straight away under demo-service, 机器列表 (machine list), as healthy (健康):

Create rules per application under 流控规则 and the other rule pages. 新增流控规则 adds a flow rule for a resource, and the dashboard pushes it to the client's command port.

A machine whose heartbeats stop is counted as unhealthy after about a minute. Here it shows as demo-service (0/1), because the demonstration heartbeat above was sent only once. The dashboard can push rules only to machines it can reach:

Rules live in the dashboard's memory and in each client, as upstream designs it. To keep rules across client restarts, configure a rule data source in your services, for example Nacos, Apollo, ZooKeeper or a file, as described in the Sentinel documentation.

Run the checks below. The dashboard answers over HTTPS, and a request for a host name the instance does not serve gets no answer (000). Nothing listens on port 80, the API refuses a caller that has not signed in, and the upstream default login is refused:

H=$(sudo sed -n 's#^SENTINEL_DASHBOARD_URL=https://\([^/]*\)/#\1#p' /root/sentinel-dashboard-credentials.txt)
curl -sk -o /dev/null -w 'dashboard page: %{http_code}\n' --resolve "$H:443:127.0.0.1" "https://$H/"
curl -sk -o /dev/null -w 'unknown host name: %{http_code}\n' -H 'Host: example.com' https://127.0.0.1/ || true
curl -s -o /dev/null -w 'port 80: %{http_code}\n' http://127.0.0.1/ || true
curl -sk -o /dev/null -w 'API without signing in: %{http_code}\n' --resolve "$H:443:127.0.0.1" "https://$H/app/briefinfos.json"
curl -sk --resolve "$H:443:127.0.0.1" -X POST "https://$H/auth/login" --data 'username=sentinel&password=sentinel'; echo

dashboard page: 200 unknown host name: 000 port 80: 000 API without signing in: 401 {"success":false,"code":-1,"msg":"Invalid username or password","data":null}

Your own login works from the command line too. The password is passed to curl from a file, so it never appears on a command line:

H=$(sudo sed -n 's#^SENTINEL_DASHBOARD_URL=https://\([^/]*\)/#\1#p' /root/sentinel-dashboard-credentials.txt)
U=$(sudo sed -n 's/^SENTINEL_DASHBOARD_USER=//p' /root/sentinel-dashboard-credentials.txt)
PWF=$(mktemp);
JAR=$(mktemp)
sudo sed -n 's/^SENTINEL_DASHBOARD_PASSWORD=//p' /root/sentinel-dashboard-credentials.txt | tr -d '\n' > "$PWF" curl -sk --resolve "$H:443:127.0.0.1" -c "$JAR" -X POST "https://$H/auth/login" --data-urlencode "username=$U" --data-urlencode "password@$PWF" | grep -o '"success":true' curl -sk -o /dev/null -w 'API signed in: %{http_code}\n' --resolve "$H:443:127.0.0.1" -b "$JAR" "https://$H/app/briefinfos.json" rm -f "$PWF" "$JAR"

"success":true API signed in: 200

Registration from the internet is refused. The allow list in /etc/nginx/sentinel-registry-allow.conf holds loopback and the private ranges, and every other address gets 403. From a computer outside your VPC, with port 443 open to it, a registration attempt looks like this:

curl -sk -o /dev/null -w '%{http_code}\n' -X POST https://<public-ip>/registry/machine --data 'app=demo-service&ip=203.0.113.10&port=8719' 403

grep -v '^#' /etc/nginx/sentinel-registry-allow.conf

allow 127.0.0.1; allow ::1; allow 10.0.0.0/8; allow 172.16.0.0/12; allow 192.168.0.0/16;

Who can reach /registry/machine? Registration needs no credentials, because Sentinel clients have no way to send them, and the dashboard connects back to whatever address a registration reports. On this image, the endpoint is reachable from your VPC's private ranges only. If other teams or tenants share the VPC, restrict it further. Allow only your application subnets in the dashboard's security group, in the allow list file, or both.

To narrow access to your application subnets, replace the 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 lines with one allow <cidr>; line per subnet. Keep the loopback lines. Then reload nginx:

sudo nano /etc/nginx/sentinel-registry-allow.conf
sudo nginx -t && sudo systemctl reload nginx

The certificate was generated on this instance and names its own addresses:

H=$(sudo sed -n 's#^SENTINEL_DASHBOARD_URL=https://\([^/]*\)/#\1#p' /root/sentinel-dashboard-credentials.txt)
echo | openssl s_client -connect 127.0.0.1:443 -servername "$H" 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName

subject=CN = ec2-<public-ip-dashed>.<region>.compute.amazonaws.com, O = sac X509v3 Subject Alternative Name: DNS:ec2-<public-ip-dashed>.<region>.compute.amazonaws.com, IP Address:<public-ip>, IP Address:<private-ip>, DNS:ip-<private-ip-dashed>.ec2.internal, IP Address:127.0.0.1, DNS:localhost

The dashboard runs unprivileged in a sandbox, bound to loopback with its own command port switched off. Neither the dashboard, nginx nor the first-boot service can reach the instance metadata service. First boot proves this on every instance:

systemctl show sentinel-dashboard -p User -p ProtectSystem -p NoNewPrivileges -p IPAddressDeny
systemctl show nginx -p IPAddressDeny tr '\0' '\n' < /proc/$(systemctl show -p MainPID --value sentinel-dashboard)/cmdline | grep -E '^-D(server.address|server.port|csp.sentinel.api.port)|^-Xm'
sudo journalctl -u sentinel-dashboard-firstboot -o cat --no-pager | grep -E 'IMDS|Serving'

IPAddressDeny=fd00:ec2::254/128 169.254.169.254/32 168.63.129.16/32 User=sentinel ProtectSystem=strict NoNewPrivileges=yes IPAddressDeny=fd00:ec2::254/128 169.254.169.254/32 168.63.129.16/32 -Xms256m -Xmx1024m -Dserver.address=127.0.0.1 -Dserver.port=8080 -Dcsp.sentinel.api.port=-1 [<timestamp>] sentinel-firstboot: IMDS_EGRESS_BLOCKED: 169.254.169.254 refused inside sentinel-dashboard-firstboot.service [<timestamp>] sentinel-firstboot: Serving as ec2-<public-ip-dashed>.<region>.compute.amazonaws.com

nginx passes the dashboard a fixed host name and the real client address from the connection, never values a client sent:

grep -E 'proxy_set_header (Host|X-Forwarded-For|X-Real-IP)' /etc/nginx/sites-available/sac-sentinel

proxy_set_header Host $sentinel_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr;

Point a DNS record at the instance, then set the name the dashboard is served as. This creates a new self-signed certificate for the name, plus the instance's own addresses. It also updates nginx and the URL in /root/sentinel-dashboard-credentials.txt, and keeps the name across reboots:

sudo sentinel-set-hostname <your-domain>

To use a certificate from your own certificate authority instead, copy it over the generated pair and reload nginx. Running sentinel-set-hostname again replaces it with a self-signed one:

sudo install -m 0644 <your-domain>.crt /etc/nginx/ssl/sentinel.crt
sudo install -m 0600 <your-domain>.key /etc/nginx/ssl/sentinel.key
sudo nginx -t && sudo systemctl reload nginx

sentinel-set-password writes a new login to /etc/sentinel-dashboard/auth.env, which is readable by root only and handed to the dashboard by systemd, never on a command line. It records the login in /root/sentinel-dashboard-credentials.txt and restarts the dashboard.

Run it without arguments for a new random password. Alternatively, pass your own password (24 to 64 letters and digits) on stdin, or change the username with --user:

sudo sentinel-set-password printf '%s\n' '<your-new-password>' | sudo sentinel-set-password --stdin sudo sentinel-set-password --user <new-username>

• Memory. The dashboard's heap is capped at 1 GiB (SENTINEL_HEAP_MAX in /etc/sentinel-dashboard/sentinel-dashboard.conf), which suits m5.large and t3.medium. For many applications and machines, raise the cap and run sudo systemctl restart sentinel-dashboard.
• Logs. Read journalctl -u sentinel-dashboard and /var/log/sentinel-dashboard/sentinel-dashboard.log. nginx logs every request with the real client address in /var/log/nginx/access.log. The dashboard logs an error each time it cannot reach a registered machine's command port, which is normal for machines that have gone away.
• Restarts. Machines re-register within ten seconds of a dashboard restart, and rules already pushed stay in the clients.
• Updates. Unattended upgrades apply Ubuntu and OpenJDK security updates. The dashboard itself is the jar in /opt/sentinel-dashboard/lib.