Monitoring Lioran S3
A storage service that only tells you “running” or “dead” is not especially cooperative.
Lioran S3 V1 Pre-Alpha exposes health, system diagnostics, performance information, and Prometheus-style metrics.
The project is developed by Lioran Developer Solutions under Lioran Group, led by Swaraj Puppalwar.
Health endpoint
Basic liveness:
curl https://storage.example.com/health
A load balancer or orchestrator can use this as a simple probe.
Driver health
const health =
await client.health();
console.log(health);
Use it during startup diagnostics or deployment verification.
System information
const info =
await client.systemInfo();
console.log(info);
The system information API is useful for inspecting runtime/storage configuration without SSHing into the box for every question.
Performance API
const perf =
await client.systemPerformance();
console.log(perf);
This can expose storage-side write latency and throughput information.
Metrics
const metrics =
await client.metrics();
console.log(metrics);
The metrics endpoint uses Prometheus text exposition.
Typical categories include:
- request counts
- HTTP latency
- throughput
- active uploads
- object counts
CLI health
liorans3 system health
CLI system info
liorans3 system info
CLI performance
liorans3 system performance
Alias:
liorans3 system perf
CLI metrics
Raw:
liorans3 system metrics
JSON-friendly mode where supported:
liorans3 system metrics --json
Doctor
The broader diagnostic command is:
liorans3 doctor
doctor is intended to help inspect:
- local configuration
- selected profile
- credential availability
- connectivity
- server reachability
- common setup failures
Credentials should remain masked in diagnostic output.
A practical monitoring stack
A small deployment can look like:
Lioran S3
|
+--> /health
|
+--> /metrics
|
v
Prometheus
|
v
Grafana
Your application monitoring should also track client-side symptoms.
Server metrics alone will not tell you that:
- DNS is failing from one region
- a reverse proxy changed timeout behavior
- clients are retrying too aggressively
- users are saturating a single network path
Alerts worth having
At minimum:
- node unreachable
- health probe failing
- low disk space
- rapid storage growth
- elevated write latency
- elevated error rate
- authentication failure spike
- multipart failure spike
- unusual bandwidth saturation
Disk alerts
Storage infrastructure deserves two different disk alarms:
Headroom
Warn before the server's own low-watermark rejects writes.
Growth rate
Alert if free space is disappearing much faster than normal.
Capacity planning is easier when you know both current fullness and slope.
Benchmarking
The TypeScript SDK repository also includes benchmark tooling for write, read, and mixed workloads.
Benchmarks are useful for regression detection, but do not turn one throughput number into a universal product claim.
Record:
- CPU
- RAM
- disk type
- filesystem
- durability mode
- concurrency
- object sizes
- TLS/reverse proxy path
- network topology
- software version
Without the test environment, benchmark numbers become decorative numerology.
JSON output for automation
CLI automation should prefer:
liorans3 ... --json
Then:
liorans3 bucket ls --json | jq '.'
Machine-readable output lets CI reason about data instead of terminal formatting.
Pre-alpha operations
V1 Pre-Alpha is specifically the phase where observability is valuable because behavior is still being exercised under increasingly realistic workloads.
Measure first.
Optimize second.
Guessing is cheaper only until it reaches production.
Top comments (0)