JuJing OBSERVE v3.0: Dynamic Log Sampling, Alert Escalation, and Native OTel Collector Ingestion

v3.0 is a major release built around two themes: cutting cost and cutting noise—cheaper storage, more accurate alerts, and simpler ingestion. The two pain points that drove it are familiar to most operators: full-retention log storage grows linearly with traffic, and alert volume spirals out of control as the number of services increases. Here is the full breakdown of what changed.

Dynamic log sampling: store based on value

Previously logs were either all kept or all dropped; keeping everything is expensive, and dropping everything is a risk nobody wants to take. v3.0 introduces dynamic sampling: by default all logs are received, but a retention policy is applied automatically based on each log's "value"—error logs are kept in full, while normal request logs are downsampled automatically during high-throughput periods. Sampling happens before the write path, so storage costs drop by 30%–50% while error logs remain complete for debugging.

Sampling rules combine level, service, and error rate, for example:

sampling:
  rules:
    - match: level >= "ERROR"
      keep: 1.0
    - match: service == "gateway" AND level == "INFO"
      keep: 0.1
      window: high_qps

Sampling runs at the collection end and takes effect as soon as the config is pushed—no application restart required.

Take a cluster ingesting 500GB of logs a day: INFO lines usually make up more than 70% of that, so with sampling enabled the daily increment can drop below 300GB—a meaningful saving over a year. Roll it out in two steps: observe in staging for a week to confirm error-log coverage is unchanged, then enable it service by service. For logs that must be archived long-term for compliance, exempt those fields from sampling so nothing is lost.

Alert escalation: send the notification to the right person

New multi-level alert escalation: when a rule fires, it first goes to the on-call group; if unacknowledged after N minutes it escalates to a phone call; if still unresolved, it escalates to the manager. Escalation paths can be configured per time window—phone at night, group chat during the day. Combined with the existing silence windows, alerts go from "anyone can see it" to "the person who needs to know will know," so a 3 a.m. page is no longer lost in a flood of group-chat messages. A sample config:

escalation:
  - level: P1
    steps:
      - { after: 0m, channel: group }
      - { after: 5m, channel: phone }
      - { after: 30m, channel: manager }

Escalation ships with deduplication and coalescing by default: a repeated trigger within the escalation window does not re-notify, so the escalation channel itself never gets flooded by the very alert storm it is meant to tame.

Native OTel Collector ingestion

You no longer need to build a sidecar or change application code. Point the OpenTelemetry Collector's exporter at JuJing and send logs, metrics, and traces in one shot. Built-in configuration templates cover the three-stage pipeline—receive, transform, export—out of the box, shrinking onboarding from hours to minutes. Common receivers (OTLP, Prometheus, Filelog), processors (batch, memory limiter, attributes), and exporters are supported, so you can reuse your existing community Collector config and simply point the exporter at JuJing.

Other improvements and fixes

• Index field management UI: manage field indexing visually, no config-file edits needed.
• Query performance: aggregate queries over millions of log lines are roughly 40% faster.
• Fixes: 12 issues resolved, including occasional multiline misalignment, a DM (Dameng) connection-pool leak, and timezone display offsets.

Compatibility and known limitations

v3.0 keeps API and alert-rule formats compatible with v2.x, so existing configurations continue to work unchanged. Known limitations: dynamic sampling currently supports only level- and service-based rules, with trace-rate-linked policies arriving in v3.1; in GMTLS gateway scenarios, some older collection agents must upgrade to 3.0.1 before the handshake succeeds. Check the official compatibility matrix before upgrading.

Upgrade notes

Moving from v2.x to v3.0 requires upgrading the collection agents to 3.x first, then rolling the server upgrade. Online upgrades are supported with no data interruption. Schedule the upgrade for a low-traffic window and watch component health through the platform's own monitoring pages; you can roll back to a v2.x config snapshot at any time. Validate your sampling policy in staging before upgrading so you don't accidentally drop historical logs. Full steps are in the official documentation.

v3.0 in one sentence: store the logs worth keeping with less money, and reach the people worth alerting with fewer notifications.