First of all, thank you to the entire Xray-core team for the incredible work you've put into this project. Xray-core has become one of the most powerful and flexible networking tools available today.

Special thanks to @RPRX for the continuous development and long-term maintenance of the project. Your dedication and hard work are sincerely appreciated.

Motivation

I'd like to propose a possible redesign of the current Observatory implementation.

At the moment, Observatory and BurstObservatory provide similar functionality with different capabilities. Since both components ultimately focus on outbound latency measurement, maintaining two separate implementations and configuration structures may introduce unnecessary complexity for both users and future maintenance.

My suggestion is to merge their capabilities into a single, more flexible Observatory implementation that can cover both use cases through configuration.

Proposed Configuration

Existing Fields

subjectSelector

• Remains unchanged.
• A list of outbound tags to be monitored.

url

• Target URL used for latency measurement.
• Example:

https://www.google.com/generate_204

connectivity

• Keep the current behavior of BurstObservatory.

New Fields

concurrency (int32)

Specifies how many latency measurements can run concurrently.

• Minimum value: 1
• 1 = Sequential execution
• N = Execute N latency measurement requests simultaneously

request_timeout

Timeout for each latency measurement request.

• Unit: seconds

interval

Interval between execution rounds.

• Unit: milliseconds

Behavior:

• If concurrency = 1, this is the delay between consecutive requests.
• If concurrency = 50, fifty requests are executed concurrently, then after interval, the next batch of fifty requests begins.

This provides precise control over probing frequency without unnecessarily increasing system or network load.

sleep

The amount of time the observatory waits after completing an entire monitoring cycle before starting the next cycle.

This clearly separates the delay between individual request batches (interval) from the delay between complete monitoring cycles (sleep).

Observatory API Service

It would also be very useful if Observatory were exposed as a service similar to other Xray services, allowing it to be managed dynamically through the existing API.

Possible API capabilities could include:

• Updating Observatory configuration without restarting Xray.
• Starting or stopping the Observatory process.
• Retrieving the latest latency measurement results.
• Querying current (and optionally historical) latency information for monitored outbounds.

This would significantly improve integration with management panels, automation tools, and external monitoring systems.

Expected Benefits

• Unify Observatory and BurstObservatory into a single, more flexible implementation.
• Simplify configuration and reduce duplicated functionality.
• Provide configurable concurrency and scheduling.
• Improve extensibility for future enhancements.
• Enable better integration with external management software through the API.
• Potentially reduce maintenance overhead by consolidating similar functionality into one component.

Thank you again for your continuous work on Xray-core.

This is only a proposal intended to start a discussion. I'd be interested to hear your thoughts on whether this direction would make sense for the project, and I'm happy to help further refine the idea if it's considered worthwhile.