Repeating the Measurement: What Changed Between Two ZoomEye Snapshots

ZoomEye queries on 26 September 2026 returned 734,693 matches for app="RabbitMQ", 350,891 for app="Elasticsearch", 257,126 for app="MinIO" and 92,859 for app="Apache ZooKeeper". Each figure is close to a value measured in an earlier collection round without being identical, and those differences are the subject of this article.

Context and method

All counts here come from single ZoomEye queries executed through the search API on 26 September 2026 at 00:38 China Standard Time, with page 1, page size 1 and sub_type all. An earlier collection round, run in the same way, produced 735,408 for RabbitMQ, 350,497 for Elasticsearch and 256,552 for MinIO.

Why repeated counts differ

An internet-wide scanner measures a moving population. Hosts appear, disappear and change configuration continuously. A service is installed, an address is reassigned, a device is decommissioned, a firewall rule is tightened or loosened. Any second measurement of the same query will differ from the first, and the size of the difference depends on how quickly the underlying population turns over.
That means a difference of a few hundred on a total of hundreds of thousands is not a trend. It is the expected variation between two samples of a dynamic population. Reporting it as growth or decline overstates what a single pair of measurements can show. A trend requires many measurements at consistent intervals, taken the same way, with the query and the vantage points held constant.

The ZooKeeper comparison

The ZooKeeper figures illustrate a different trap. An earlier article reported 272,927 for ZooKeeper, and the current measurement of app="Apache ZooKeeper" returned 92,859. Those two numbers are not comparable, and the query itself is the reason. A dork that names the product with a different spelling, or that matches a field such as a banner instead of a product label, describes a different set of hosts.
The lesson generalises. Before treating two numbers as a change over time, confirm that the queries were identical. Dork syntax, field selection, sub_type and case sensitivity all affect the result, and the fuzzy and exact match operators behave differently. A count without its query text is not reproducible, and an unreproducible count cannot support a trend claim.

What the numbers do support

They support a statement about scale at a moment in time. RabbitMQ with more than seven hundred thousand matches, Elasticsearch above three hundred fifty thousand, MinIO above two hundred fifty thousand and ZooKeeper approaching one hundred thousand describe an internet in which message brokers, search clusters and object storage endpoints are widely reachable.
For each of these four, the operational question is the same and does not depend on the exact count. Is the service reachable from outside the network that uses it, and is authentication enabled? RabbitMQ and Elasticsearch both support authentication and both have long histories of deployments found without it. MinIO requires credentials for its interface, but exposed consoles still disclose the existence and often the naming convention of the buckets behind them. ZooKeeper was designed for trusted networks and authenticates clients optionally.

Implications and next steps

Record the query text alongside every count, and record the collection time and the sub_type parameter. A number without that context cannot be compared to a later reading, and the comparison is the only thing that turns a measurement into intelligence.
Set a variation threshold before drawing conclusions. For a population in the hundreds of thousands, differences of a fraction of a percent over days are noise. Decide what magnitude would indicate a real change, and only then treat a reading as a signal.
Then use the counts for what they support. They establish that a technology is widely reachable and therefore worth a configuration review. The review itself happens inside the network, against an inventory, and the internet scan only tells you which technologies to look for.

Scope and limitations

These are point-in-time fingerprint counts from ZoomEye's vantage points. They include cloud provider ranges, research networks and honeypot hosts, and they count each reachable node separately, so a single deployment contributes multiple matches. Variations between collection rounds reflect the dynamics of the public internet and the behaviour of the scanner as well as real changes. Nothing here measures exploitation or patching status.

References

• ZoomEye search API results for app="RabbitMQ", app="Elasticsearch", app="MinIO" and app="Apache ZooKeeper", collected 26 September 2026.
• Earlier collection round results for the equivalent dorks, used only for comparison.