Apache HertzBeat: Agentless Monitoring With AI and a Built-In MCP Server

What HertzBeat Actually Solves

Most monitoring tools split metrics, logs, and alerting into separate products that you must stitch together. HertzBeat is an attempt to collapse that pipeline into one Java application. The README describes it as an AI-powered, next-generation real-time observability system that unifies collection, analysis, alerting, and notification. The target user is an engineer who wants to monitor a heterogeneous fleet of databases, caches, operating systems, middleware, web servers, and cloud-native components without deploying an agent on each host. HertzBeat also targets teams that need to expose service status to the public through status pages. The core value proposition is that you configure collection protocols, not agents, and the same platform handles the entire alert lifecycle from threshold rules to message distribution.

Agentless by Design: Protocols Over Daemons

The architecture is built around configurable protocols rather than installed collectors. The README lists Http, Jmx, Ssh, Snmp, Jdbc, and Prometheus as the primary collection mechanisms. You define a monitoring template in a YML file, and HertzBeat uses that template to fetch metrics from the target over the network. This is fundamentally different from agent-based systems like Zabbix or Telegraf, which require you to install and maintain a process on every monitored machine. The trade-off is visible: protocol-based collection works only if the target exposes a reachable endpoint or accepts a management connection. For a database, you open JDBC. For a Linux server, you use SSH. For network gear, you use SNMP. That means credentials and network access become your inventory problem. The README claims you can adapt to a new monitoring type like Kubernetes or Docker simply by configuring a template online, but that assumes the target exposes a compatible protocol. If it does not, you are stuck.

Getting It Running: Docker, Packages, and Collector Clusters

The quick start is a single Docker command. You run apache/hertzbeat with ports 1157 and 1158 exposed, then open http://localhost:1157 and log in with admin/hertzbeat as the default account. Port 1157 is the web UI and API, while 1158 is the manager port that collectors connect to. For horizontal scaling, you deploy separate collector containers. The README gives this example: docker run -d -e IDENTITY=custom-collector-name -e MANAGER_HOST=127.0.0.1 -e MANAGER_PORT=1158 --name hertzbeat-collector apache/hertzbeat-collector. The IDENTITY environment variable sets a unique name for that collector. The MODE variable switches between public and private cluster modes; private mode is for cloud-edge collaboration where collectors sit in isolated networks. For package installs, you download apache-hertzbeat-xx-bin.tar.gz, optionally edit hertzbeat/config/application.yml, then run ./bin/startup.sh. The configuration file is standard Spring Boot style, so you will likely need to adjust database connections and alerting settings before production use.

The AI Hook: What Is Actually Included

The term AI appears in the description and in a feature bullet that mentions HertzBeat AI and built-in MCP Server capabilities. The README does not explain what the AI does beyond intelligent management and analysis. That is a thin claim. MCP, or Model Context Protocol, is a real standard for exposing tools to large language models, but this document gives no example of how you would query HertzBeat through MCP or what an AI interaction looks like. If you are evaluating the AI features for a decision, you need to check the official documentation or the 1.8.0 release notes. The repository layout shows an ai-related directory, but the README does not describe its contents. This is a genuine gap. The AI angle could be a differentiator, but as presented it is mostly a label. For an engineer deciding whether to adopt, the practical value today is the unified alerting and protocol-based collection, not the AI promise.

Unified Alerting and Notification Routing

HertzBeat treats alerting as a central service. It ingests internal alerts from metric thresholds and also accepts external alerts from other sources. The README lists grouping convergence, silence, and suppression as built-in features, which means you can reduce alert noise without writing separate logic. After processing, alerts go out through a wide set of channels: Email, Discord, Slack, Telegram, DingTalk, WeChat, FeiShu, SMS, Webhook, and ServerChan. That breadth is practical for global teams. The design separates collection from alerting, so you can feed alerts from Prometheus or other tools into the same pipeline. The downside is that you now run another alert manager. If you already use Alertmanager, you are adding a second routing layer. HertzBeat's advantage is that it also generates the alerts from its own monitoring, so you get one place to configure rules and one place to see the alert history. That is useful, but it is also a commitment to HertzBeat's rule syntax and its UI for managing silences.

Log Integration: The OTLP Constraint

HertzBeat is not a full log management system. The README says the logging platform integrates multiple log sources through the OTLP protocol. That means you must have a way to export logs in OTLP format, which typically requires an agent or a gateway like the OpenTelemetry Collector. So the agentless promise does not extend to logs. If you want to centralize logs, you still need to run an exporter somewhere. The README does not mention log storage, retention, or query capabilities. It only says unified logging platform. That is a red flag for anyone expecting Loki or Elasticsearch functionality. For metrics and alerts, HertzBeat is self-contained. For logs, it is a receiver that depends on external shippers. If your environment already produces OTLP, this integration is convenient. If not, you are introducing a new pipeline component.

Custom Monitoring: The YML Template System

The most distinctive feature is the ability to define a new monitoring type by writing a YML template. The README gives the example of adapting to Kubernetes or Docker by configuring online. The protocol definitions for Http, Jmx, Ssh, Snmp, Jdbc, and Prometheus are all configurable. This means you can collect any metric that is reachable through one of those protocols without writing Java code. The trade-off is that you must understand the protocol and the target's data model. For JDBC, you write SQL queries in the template. For Prometheus, you specify the endpoint and query. The flexibility is real, but it shifts work from developers to operators who must craft YML. The documentation is not in the README, so you would need to consult the project's official docs to learn the template schema. This is a powerful feature for teams with unusual monitoring targets, but it is also a learning curve.

Limitations and Wrong Tool Cases

HertzBeat is the wrong tool if your primary need is log analysis. The OTLP-only ingestion and lack of detail on query capabilities make it a poor substitute for a dedicated log store. It is also not ideal for teams that want a pure Prometheus setup, because HertzBeat introduces its own alerting and UI layers on top of Prometheus-compatible collection. The README claims Prometheus compatibility, but that likely means it can scrape Prometheus endpoints, not that it replaces PromQL or the Prometheus ecosystem. Another limitation is the AI feature maturity. If you are adopting solely for the AI or MCP server, you should wait until the documentation catches up. The default account admin/hertzbeat is a security concern if you forget to change it. The README does not mention how to change it, but it is an obvious first step. Finally, the cluster mode adds operational complexity. Running collectors in public or private mode requires you to manage identities and network routes, which is a real cost.

Alternatives: Zabbix, Prometheus, and the Agentless Comparison

Zabbix is the most direct alternative because it also covers metrics, alerting, and notifications in one platform. The difference is that Zabbix traditionally uses agents, though it also supports agentless checks via SNMP and IPMI. HertzBeat leans harder on protocol-based collection and modern protocols like Prometheus and OTLP. Zabbix has a longer track record and a larger template library, but its configuration model is older. Prometheus plus Grafana is another alternative. Prometheus handles metrics collection and alerting via Alertmanager, but it does not do logs or status pages out of the box. You would add Loki and a status page tool. HertzBeat bundles all of that, but you lose the vast ecosystem of Prometheus exporters. If you already run Prometheus exporters, HertzBeat can scrape them, but you are still moving to a new alerting UI. For teams that want minimal moving parts, HertzBeat's all-in-one approach is attractive. For teams that want best-of-breed components, the separate tools are more flexible.

Maintenance and Upgrade Considerations

HertzBeat is an Apache project under the Apache-2.0 license, which means you can use it commercially without per-seat fees, and you have patent protection from the Apache grant. The release cadence is active, with 1.8.0 in January 2026, 1.7.3 in August 2025, and 1.7.2 in June 2025. That suggests roughly two to three releases per year, which is a moderate upgrade pace. The project is not archived and has a default branch of master. Maintenance cost depends on whether you use the Docker image or the package. Docker upgrades are a matter of pulling a new image and migrating data, but the README does not describe a migration path. The application.yml file is the main configuration surface, so you will need to track changes between versions. The collector cluster mode means you must upgrade collectors and the manager in a coordinated way. The README does not state whether versions must match, but that is a common requirement in such architectures. Check the release notes for breaking changes before upgrading.

Editorial conclusion

Adopt HertzBeat if you need an agentless, self-hosted observability platform that combines metrics, logs, alerting, and status pages, especially if you value protocol-driven customization and AI assistance. Skip it if you require deep log analysis or already run a mature Prometheus/Grafana stack, because HertzBeat's log integration is OTLP-only and its AI features are still evolving. Before committing, verify the 1.8.0 release notes for MCP Server details, test the YML protocol templates against your target systems, and confirm that the collector cluster mode meets your network isolation needs.

Official sources

1. apache/hertzbeat on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases