# EaseProbe: one Go binary that checks services and then tells somebody

> A standalone health checker with fourteen probe types, thirteen notification channels and SLA reporting, written in Go. The README calls it lightweight, and the dependency list argues with that in public.

**megaease/easeprobe** — A simple, standalone, and lightweight tool that can do health/status checking, written in Go.

- Repository: https://github.com/megaease/easeprobe
- Stars: 2,295 · Forks: 240
- Language: Go
- License: Apache-2.0
- Published: 2026-10-08 · Updated: 2026-10-08 · Language: en
- Canonical page: https://hysenlabs.com/projects/megaease-easeprobe

## Three jobs behind one binary

The README organizes the tool into three responsibilities, and the directory layout in the tree matches that organization closely. There is a probe directory, a channel directory, a report directory and a notify directory, plus cmd, conf, daemon, metric, eval, web and helm at the root. If you want to know where a feature lives before reading the manual, that layout is the fastest answer.

Probe is the checking half. Notify is the delivery half. Report and Metrics is the part where check results become numbers, and it is the piece that separates EaseProbe from a curl loop with a mail command.

The project description calls it a simple, standalone and lightweight tool. Standalone is accurate: it is one Go binary with a configuration file. Lightweight is arguable, and the module file is the evidence. The direct requirements include the AWS SDK for Go, the MongoDB driver, the Kafka client, the PostgreSQL driver, the MySQL driver, the Redis client, the Zookeeper client, a Memcache client, a WebSocket library, three HTML and XML query libraries, an expression evaluator, a cron scheduler, two Prometheus and web frameworks, and a mail library. That is a dependency footprint of a much larger tool than the description implies.

This is not an argument against the project. It is an argument for reading go.mod before you decide that a single binary means a small supply chain surface. A monitoring agent with database drivers inside it is a different risk profile from one with only HTTP and TCP clients.

## Fourteen probe types and what each one actually checks

The probe list is the substance of the tool, and the README is specific about what each one does rather than vague about checking health.

The network checks are HTTP, TCP, Ping, TLS and SSH. HTTP checks the status code, supports mutual TLS, HTTP Basic Auth, custom request headers and bodies, and can evaluate the response body with XPath. TCP checks whether a connection can be established at all. Ping checks reachability. TLS connects to a port and can optionally validate the certificate for revocation or expiry, which catches a class of outage that a plain TCP check misses entirely. SSH runs a remote command and supports a bastion or jump host.

The shell and host checks are where it stops looking like a health checker. Shell runs a command and checks the result, so you can write a check that is not one of the fourteen types. Host runs an SSH command on a remote machine and reports CPU, memory and disk usage, which means a load threshold and an availability threshold live in the same tool and produce the same notification.

The client checks are the seven native ones, and each names the exact command it sends: MySQL runs SHOW STATUS, Redis runs PING, Memcache runs version or validates a given key and value pair, MongoDB performs a ping, Kafka lists all topics, PostgreSQL runs SELECT 1, and Zookeeper runs get on the root path. All of them support mutual TLS and data checking.

That last detail is why the native clients exist at all. A connection that succeeds proves the port is open, not that the service answers. Listing Kafka topics or reading a Memcache value proves the service is functioning.

## Notification channels and the edge-triggered default

Thirteen delivery targets are documented: Slack, Discord, Telegram, Microsoft Teams, email, AWS SNS, WeChat Work, DingTalk, Lark, SMS through three providers, a log file or syslog, a shell command, and RingCentral. The last two are the interesting ones because they make the notification layer a general escape hatch. The README points at a shell script example for the shell target, so you can call whatever your existing paging tooling is.

Two notes come with the list. Syslog is unsupported on Windows, which follows from there being no syslog on that platform rather than from a design decision. And the default alerting mode is edge-triggered, which means a notification fires when the status changes rather than on every failing check. If you want level-triggered behavior with a different interval and a maximum notification count, the README refers you to the manual section on alerting interval.

That default is the right one for paging and the wrong one for a dashboard. An edge-triggered system is silent while a service stays down, which is what you want at 3am and what you do not want when someone asks why last Tuesday looked fine on a chart. EaseProbe addresses the second need separately, in the SLA reporting layer.

## SLA reporting and the Prometheus endpoint that shares a port

EaseProbe keeps history, and that is where it goes beyond alerting. Four related capabilities live here.

SLA report notify sends a daily, weekly or monthly report through the same notify channels you already configured, so a status summary reaches the same Slack channel as the page. SLA live report serves an HTML report at the root of a local port and a JSON version at an API path. SLA data persistence writes the accumulated data to a YAML file under the working directory, configurable in the settings section. Prometheus metrics exposes the same data as metrics on that port.

Here is the detail that will make you read the manual. The live report and the Prometheus metrics endpoint are documented as listening on the same port, 8181, with the HTML at one path and the metrics at a /metrics path. The README even gives one example address using a hostname of easeprobe rather than localhost, which suggests the container or service name is what you would normally use.

Two consequences follow. Because it serves both, this is a network-exposed service that returns availability data, and the README does not document any authentication on it. Before you bind it beyond a trusted network, check the manual for what protects that port. And because the data file defaults to a path under the current working directory, running the binary from an unexpected directory silently starts a new history file rather than failing.

## Building it and the Go version contradiction

Three acquisition paths are offered: a release binary for your platform, the published container image, or a build from source.

```shell
$ make
```

The README says use make and that the executable lands under the build and bin directory. The Makefile in the repository confirms it and shows more. The build runs go mod tidy first, sets CGO_ENABLED to zero, and stamps the version into the binary from the most recent git tag, so a build from a checkout without tags produces a binary with an empty version string. It also strips symbols and links statically.

Before that command, the README asks for Go 1.21 or newer and attributes the requirement to generics support. The module file says something different.

```
go 1.24.0

toolchain go1.24.1
```

Both statements are in the repository. A 1.21 toolchain will refuse this module outright, so the README is out of date on this point rather than describing a minimum with headroom. If you hit a version error during go mod tidy, this is why.

The Makefile also carries a container target that builds from a Dockerfile in the resources directory.

```
sudo DOCKER_BUILDKIT=1 docker build -t megaease/easeprobe -f resources/Dockerfile .
```

The sudo prefix and the absolute path interpolation in the original are both worth noting if you plan to run this in CI, where sudo usually does not exist. The helm directory at the repository root suggests a chart exists for Kubernetes deployments, which is the more conventional route for running this in a cluster.

## Where EaseProbe is the wrong tool

The honest comparison is with what you already run. A Prometheus installation with an alertmanager already probes HTTP endpoints on a schedule, already evaluates expressions, already sends to Slack, PagerDuty and email, and already keeps history you can graph. EaseProbe overlaps most of that and adds two things alertmanager does not: SLA reporting framed as availability percentages delivered on a schedule, and the native database clients with real command checks rather than only HTTP health endpoints.

If your checks are all HTTP endpoints and you have Prometheus, adopting EaseProbe adds a second monitoring system to keep running. If your checks include reading a Memcache value or listing Kafka topics, or if you want an SLA number in an email every Monday, EaseProbe does something your current stack may not.

There is also a scaling limit worth being explicit about. The configuration model is a single process with one configuration file, and the architecture is a daemon with a scheduler. That is a good fit for tens to hundreds of checks on one host. It is not a distributed probe fleet, and there is no sharding story in the README. Very large estates are the wrong shape for this design, and the manual is where you would find out whether that has changed.

## Conclusion

Adopt EaseProbe when you want availability numbers and paging from one process that you can drop on a single host, and when your checks are the kind a person wrote down rather than the kind a cluster operator maintains. Do not adopt it if you already run a Prometheus with alertmanager rules, because the notification layer will duplicate what your existing rules already do. Verify one thing before you build the dashboard around it: the README asks for Go 1.21 or newer while go.mod declares go 1.24.0 with a toolchain line pinning 1.24.1, so check what your build host actually has before you blame your own setup when the build fails.

## FAQ

### How do I install EaseProbe?

Three routes are documented: download a release binary for your platform, run the published container image, or build from source with make, which produces the executable under the build and bin directory. The README asks for Go 1.21 or newer, but the go.mod file declares go 1.24.0 with a toolchain line for 1.24.1, so check your toolchain version first.

### What can EaseProbe monitor?

HTTP, TCP, Ping, TLS, Shell, SSH and Host checks, plus native clients for MySQL, Redis, Memcache, MongoDB, Kafka, PostgreSQL and Zookeeper. Each native client runs a real command such as SELECT 1 or a Kafka topic listing rather than only testing that a port accepts connections.

### Which notification channels does EaseProbe support?

Slack, Discord, Telegram, Microsoft Teams, email, AWS SNS, WeChat Work, DingTalk, Lark, SMS through Twilio, Vonage and YunPian, a log file or syslog, an arbitrary shell command, and RingCentral. Alerting is edge-triggered by default, meaning a notification fires on a status change rather than on every failing check.

## Sources

- [Issues](https://github.com/megaease/easeprobe/issues)
- [License: Apache-2.0](https://github.com/megaease/easeprobe/blob/main/LICENSE)
- [megaease/easeprobe on GitHub](https://github.com/megaease/easeprobe)
- [README](https://github.com/megaease/easeprobe/blob/main/README.md)
- [Releases](https://github.com/megaease/easeprobe/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/megaease-easeprobe