Monitoring & Logs

MicroFly is built for production observability. It features a native Prometheus metrics exporter, ring-buffered disk logging, real-time log tailing, and automatic process crash recovery.

---

1. Application Logs

MicroFly captures standard output (stdout) and standard error (stderr) from all running workloads, prepends precise ISO-8601 timestamps, and maintains an internal circular ring buffer and persistent log file.

Live Log Streaming

Follow logs in real time (similar to tail -f or heroku logs --tail):

sudo microfly logs -f my-app

Output:

[2026-09-03T10:15:30+02:00] release 20260903T101530-000001 listening on 127.0.0.1:3000 (pid 78912, cold start 218.4ms)
[2026-09-03T10:15:32+02:00] [stdout] Server listening on port 3000
[2026-09-03T10:15:35+02:00] [stdout] GET /api/users - 200 OK (1.2ms)

View the last 50 log entries:

sudo microfly logs -n 50 my-app

Persistent Disk Logging

Every application has a persistent log file on disk: /var/lib/microfly/apps/<app>/app.log

• MicroFly automatically rotates logs when they exceed the configured size limit.
• Log entries are stored in a simple, grep-friendly format suitable for ingestion by Promtail, Vector, or FluentBit.

---

2. Prometheus Metrics

The MicroFly daemon hosts a native Prometheus metrics endpoint bound to loopback at http://127.0.0.1:9090/metrics.

Scraping with Prometheus

Add the following job to your /etc/prometheus/prometheus.yml:

scrape_configs:
  - job_name: 'microfly'
    scrape_interval: 15s
    static_configs:
      - targets: ['127.0.0.1:9090']

Exported Metrics Reference

Metric	Type	Description
microfly_app_status{app="<name>"}	Gauge	Application lifecycle status: 0 = stopped, 1 = running, 2 = scaling / starting.
microfly_http_requests_total{app="<name>",code="<code>"}	Counter	Total proxied HTTP requests segmented by application and response status code.
microfly_http_request_duration_seconds{app="<name>"}	Histogram	Latency histogram for HTTP requests routed through the ingress engine.
microfly_process_memory_bytes{app="<name>"}	Gauge	Current Resident Set Size (RSS) memory consumed by the application process.
microfly_cold_start_duration_ms{app="<name>"}	Gauge	Duration in milliseconds required to awaken a scaled-to-zero workload on request arrival.
microfly_app_oom_events_total{app="<name>"}	Counter	Total Out-Of-Memory (OOM) events triggered by Linux cgroup limits for the application.

---

3. CLI Process & Status Inspection

Application Details

Inspect process PID, assigned port, memory usage, restart count, and active release:

sudo microfly status my-app

Output:

App Name:       my-app
Type:           binary
Status:         running
Active Release: 20260903T101530-000001
Assigned Port:  3000
Process PID:    78912
Memory (RSS):   5.12 MB
Domains:        api.example.com
Restart Count:  0
Restart Policy: on-failure
Scale to Zero:  true (min instances: 0)

Process Snapshot

View all active processes managed across all applications:

sudo microfly ps

---

4. Crash Auto-Recovery

If an application crashes due to a panic, segmentation fault, or an uncaught exception:

1. MicroFly's supervisor detects process termination immediately via systemd unit state notifications.
2. The supervisor records the exit code in the application's audit log.
3. MicroFly restarts the application automatically according to the configured restart_policy (with exponential backoff protection).
4. Ingress requests arriving during recovery are held in a connection buffer until the newly spawned process passes health checks.