Prometheus on Mi&Bee Blog

From Compliance to Real-Time Defense: The Evolution of security-collector-exporter

Thu, 21 May 2026 00:00:00 +0000

The Origin: Compliance Check Hassles

Anyone in operations knows there’s no escaping one hurdle for domestic servers: Cybersecurity Level Protection (GB/T 22239-2019, commonly known as “Level Protection 2.0”). Whether you’re Level 3 or Level 2, auditors come asking about these things:

Is SSH root login disabled? Are password policies compliant?
Is the firewall on? Is SELinux enforcing?
Are there expired accounts? What’s the password validity period?
Which ports are open? Are there high-risk services running?
Are audit logs enabled? How long are they retained?

There are plenty of compliance check tools on the market—search GitHub and you’ll find a bunch: Golin, EvaluationTools, Linux-Security-Compliance-Check, etc. But they all share one limitation: Run once, get a report, done. You check compliance today, and someone changes sshd_config tomorrow, turns off the firewall, installs a backdoor service—you’d never know.

security-collector-exporter v0.3.0: Real-Time Security Monitoring with eBPF

Tue, 19 May 2026 00:00:00 +0000

From Static to Real-Time

The previous article introduced security-collector-exporter v0.1.0 — turning Linux security configuration states into Prometheus metrics. But v0.1.0 is essentially “snapshot-based”: periodically reading /etc, /proc, capturing the static configuration at a single point in time.

There’s an area of security operations that snapshots can’t cover: real-time security events. Someone running a reverse shell, a process escalating privileges, an abnormal network connection, someone loading a kernel module — these events happen and pass; you’d never see them at your next scrape.

From Hashmod to Jump Consistent Hash — stream-metrics-route Hash Algorithm Upgrade

Sat, 16 May 2026 00:00:00 +0000

Introduction

In the previous article, we reviewed the three-year evolution of stream-metrics-route and mentioned that the “dual hashmod scheduling” is the core scheduling mechanism of the entire gateway. However, during continuous production operation, one fatal flaw of hashmod became increasingly obvious—every scaling operation triggers full data redistribution.

This article documents the complete decision process of migrating from hash % N (hashmod) to Jump Consistent Hash: which candidate algorithms were evaluated, why Jump Hash was ultimately chosen, and the specific impact before and after migration.

security-collector-exporter: Monitoring Linux Security Auditing

Thu, 14 May 2026 00:00:00 +0000

Why This Was Built

Anyone managing servers has probably had this experience: compliance audit comes, SSH into machines one by one to check—SSH config correct, SELinux enabled, firewall running, any expired accounts, password policies compliant. A few machines are fine; dozens or hundreds becomes purely manual grunt work.

And the more painful part: none of this has continuous monitoring. You check compliance today, someone changes a config tomorrow, and you’d never know.

VictoriaMetrics Stream Aggregation: Three-Year Review and Current Status (2026)

Tue, 12 May 2026 00:00:00 +0000

Introduction

It’s been exactly three years since the previous article Applying VictoriaMetrics Stream Aggregation for Metrics was published in March 2023. In these three years, the VictoriaMetrics ecosystem has undergone tremendous changes—let’s revisit the issues raised in that blog post, see what the official project has resolved, and where our stream-metrics-route project stands today.

I. Problems We Encountered Three Years Ago

Let’s quickly recap the core issue list from the 2023 blog post:

Replacing VMs with ESP32 for Network Probing — esp32-blackbox Project in Action

Thu, 23 Apr 2026 00:00:00 +0000

Why

I have several LANs in different locations around the city, roughly 10 km apart. To make these networks talk to each other, I used tools like NetBird, ZeroTier, and Cloudflare Tunnel to set up a cross-region virtual LAN.

The network was set up, but how to ensure stability? After all, these tunnels traverse the public internet with varying link quality. The most direct approach is to use Prometheus’s blackbox_exporter for probing — periodic HTTP requests, Pings, DNS queries — feeding results into a time-series database with alert rules, so problems are detected immediately.

Applying VictoriaMetrics Stream Aggregation for Metrics

Mon, 27 Mar 2023 00:00:00 +0000

Community VM Stream Aggregation Capability Analysis and Issues

VictoriaMetrics Open-Source Project Native Capabilities

Stream aggregation in the VictoriaMetrics project was integrated into vmagent starting from version 1.86. For details, refer to: https://github.com/VictoriaMetrics/VictoriaMetrics/issues/3460 From the source code analysis, the stream aggregation capability looks like this:

The core computation code is described in the pushSample function:

go


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


func (as *totalAggrState) pushSample(inputKey, outputKey string, value float64) {
	currentTime := fasttime.UnixTimestamp()
	deleteDeadline := currentTime + as.intervalSecs + (as.intervalSecs >> 1)
again:
	v, ok := as.m.Load(outputKey)
	if !ok {
		v = &totalStateValue{
			lastValues: make(map[string]*lastValueState),
		}
		vNew, loaded := as.m.LoadOrStore(outputKey, v)
		if loaded {
			v = vNew
		}
	}
	sv := v.(*totalStateValue)
	sv.mu.Lock()
	deleted := sv.deleted
	if !deleted {
		lv, ok := sv.lastValues[inputKey]
		if !ok {
			lv = &lastValueState{}
			sv.lastValues[inputKey] = lv
		}
		d := value
		if ok && lv.value <= value {
			d = value - lv.value
		}
		if ok || currentTime > as.ignoreInputDeadline {
			sv.total += d
		}
		lv.value = value
		lv.deleteDeadline = deleteDeadline
		sv.deleteDeadline = deleteDeadline
	}
	sv.mu.Unlock()
	if deleted {
		goto again
	}
}

General Application Analysis of Stream Aggregation

First, let’s look at the time series chart after stream aggregation:

Eyes On You: The 2022 Productization Journey of a Multi-Cloud Heterogeneous Monitoring Platform

Mon, 20 Jun 2022 00:00:00 +0000

In the context of multi-cloud deployment, global networking, and exponential growth in service scale within internet businesses, monitoring platforms have long surpassed the basic “metric collection + alert notification” positioning, becoming the core infrastructure for ensuring end-to-end stability. This article, based on the real evolution of a large-scale internet enterprise monitoring platform, dissects the complete planning and implementation approach for upgrading the monitoring platform from large-scale coverage to productization, usability, and intelligence in 2022.

Monitoring System Enterprise Architecture Evolution — Probing Monitoring

Sat, 12 Dec 2020 00:00:00 +0000

Recap

In “Monitoring System Enterprise Architecture Evolution — Cross-Region Hybrid Cloud”, the monitoring system had gradually matured and evolved toward enterprise-level capabilities. This chapter briefly describes the construction of the probing capability during this period. Below is the development history of this system. During the construction of the monitoring platform, internal monitoring collection alone was insufficient to meet enterprise business needs. Before planning APM development, remote probing with black-box monitoring was also incorporated as a subsystem.

Monitoring System Enterprise Architecture Evolution — Cross-Region Hybrid Cloud

Mon, 12 Oct 2020 00:00:00 +0000

Recap

In “Monitoring System Enterprise Architecture Evolution — First Steps with Prometheus”, the monitoring system had already been upgraded from a single-node architecture to a single IDC distributed architecture. The content of the previous article applies to both VM-based and container-based deployments. Prometheus is a product of the cloud-native era and is commonly used alongside Kubernetes, but Prometheus itself can also replace traditional monitoring solutions like Zabbix in non-Kubernetes environments. In this article, we begin to use Kubernetes deployment to upgrade the entire monitoring system architecture, making it more flexible for cross-region hybrid cloud business scenarios.

Eyes On You: From SRE Principles to Prometheus Monitoring System Implementation

Sat, 20 Jun 2020 00:00:00 +0000

In the context of distributed internet services, high concurrency, and multi-cloud deployment, SRE (Site Reliability Engineering) has become a core role in ensuring service availability, and the monitoring system serves as SRE’s “eyes.” This article starts from SRE core principles, deconstructs the pain points of modern monitoring systems, technology stack selection, Prometheus core principles, and alerting best practices, presenting a practical enterprise-grade monitoring system construction methodology.

SRE Core Principles: Stability is the #1 Metric

SRE’s core is ensuring continuous service stability through engineering practices, focusing on capacity planning, cluster maintenance, fault tolerance, load balancing, and monitoring system construction. There are only 3 core measurement metrics:

Monitoring System Enterprise Architecture Evolution — First Steps with Prometheus

Thu, 12 Dec 2019 00:00:00 +0000

Prometheus is an open-source monitoring and time series database system that has gained widespread adoption in recent years. The official architecture diagram is shown below: This series of articles will gradually understand and deepen various components and concepts through the deployment architecture evolution of Prometheus in an enterprise. First, let’s get a quick overview of this evolution history through the diagram below:

Single Node Architecture

When first getting started with the Prometheus monitoring system, you only need to deploy the Prometheus binary on the server side, using the basic file service discovery configuration file_sd_config to pull metrics from node_exporter for basic host monitoring. Then configure the Prometheus url address as a datasource in Grafana to start viewing monitoring data.