Observability

The three signals
Two ways to send data
- Push-based ingestion (recommended)
- Pull-based collection (JuhJuh VMs)
How signals connect
Quick start
Data retention
Rate limits
What to read next
Related

Your application is running. Now you need to know what it is doing. JuhJuh collects logs, metrics, and traces from your services, correlates them, and gives you one place to investigate issues before your users notice them.

Three signals. One platform. No vendor lock-in.

The three signals¶

graph TD
    App[Your Application] -->|logs| L[Log Management]
    App -->|metrics| M[Metrics]
    App -->|traces| T[Distributed Tracing]
    L --> C[Correlated View]
    M --> C
    T --> C
    C --> A[Alerts]
    C --> D[Dashboards]

Logs tell you what happened. A request failed, a user signed up, a background job timed out. Structured log entries with levels, timestamps, and custom attributes flow into JuhJuh where you can search, filter, and drill down.

Metrics tell you how your system is performing right now. CPU usage, request latency, queue depth, error rates. Numbers over time that you can chart, aggregate, and set alert thresholds on.

Traces tell you why something is slow or broken. A single user request might touch your API server, a database, a cache, and two downstream services. Distributed tracing captures that full journey as a chain of spans so you can see exactly where time is spent.

Alerts watch your metrics and notify you when something crosses a threshold. An email, a Slack message, or a webhook fires so your team can respond before a slowdown becomes an outage.

Two ways to send data¶

Push-based ingestion (recommended)¶

Your application sends observability data directly to JuhJuh using HTTP endpoints. This works with any language, any framework, and any hosting environment.

Create an API key in your organization settings
Instrument your application with an OpenTelemetry SDK or send simple JSON
Point the exporter at your JuhJuh ingestion endpoints
Data appears in your dashboards within seconds

Push-based ingestion supports two formats on every endpoint:

Format	Best for
OpenTelemetry (OTLP)	Applications already using OpenTelemetry SDKs. Full spec compliance with automatic attribute extraction
Simple JSON	Quick integration without an SDK. Send a JSON array with the fields you care about

Both formats are auto-detected on every endpoint. No configuration flag needed.

Pull-based collection (JuhJuh VMs)¶

If your application runs on JuhJuh-managed VMs, infrastructure metrics and container logs are collected automatically. JuhJuh connects to your VMs securely and gathers CPU, memory, disk, and network data every 60 seconds. Container logs stream in real time.

No SDK required for infrastructure-level observability on JuhJuh VMs. Push-based ingestion adds application-level signals on top.

How signals connect¶

The real value shows up when signals are correlated. JuhJuh links them automatically.

From	To	How
Trace	Logs	Every log entry can carry a `trace_id`. Search logs by trace to see exactly what happened during a specific request
Error	Trace	Errors captured in traces link back to the full request journey
Metric spike	Trace	Metric alerts can include exemplar trace IDs that point to a real request during the anomaly
Frontend error	Backend trace	Real User Monitoring injects W3C Trace Context headers so browser errors connect to server-side traces

Quick start¶

The fastest path from zero to observability:

Get an API key. Go to your organization's Settings, then API Keys, and create a new key. Copy the key; you will not see it again.
Send a log entry. Test the connection with a single HTTP request:

bash curl -X POST https://your-org.juhjuh.com/api/ingest/logs/ \ -H "Authorization: Bearer jjk_YOUR_KEY" \ -H "Content-Type: application/json" \ -d '{"logs": [{"message": "Hello from my app", "level": "info", "service": "my-service"}]}'

Check the log viewer. Open Observability in your dashboard. Your log entry appears within seconds.
Add more signals. Follow the Instrumentation guide to add metrics and traces using your language's OpenTelemetry SDK.

Data retention¶

Signal	Default retention
Logs	14 days
Metrics	30 days
Traces	14 days
Infrastructure snapshots	30 days
Container metrics	14 days
RUM sessions	Configurable per config

Retention periods are applied automatically. Expired data is permanently deleted in daily cleanup cycles.

Rate limits¶

Each API key allows 200 requests per 60 seconds per endpoint. If you exceed this limit, the endpoint returns a 429 status code. Space out your requests or batch more data per request to stay within limits.

For large-volume ingestion, batch your data. Each endpoint accepts up to 50 items synchronously. Batches larger than 50 items are accepted with a 202 status and processed asynchronously.