DEV Community: tom

Why Does Every AI Agent Still Look Like `while (true) { ... }`?

tom — Tue, 18 Aug 2026 16:08:34 +0000

Open any agent codebase today — Claude Code, Codex, Pi, most of the open-source ones — and you'll find the same skeleton. Something like:

let state = {};
while (true) {
  const plan = await llm.plan(state);
  const results = await runTools(plan);
  state = updateState(state, results);
  if (isDone(state)) break;
}

It's the natural first design. The model is the brain, the loop is the heart, and state is whatever bag of objects you've accumulated. It works great for demos.

But after you start living with one of these agents for a while, the same cracks show up everywhere.

The cracks in the loop

Interruption is a hack. If the user kills the process mid-turn, or a tool hangs, or the model asks for clarification, you've got this awkward half-finished iteration sitting in state. You either throw it away or patch it in place. Either way the state is lying to you about what actually happened.

Retries are special cases. A tool fails? Write a try/catch around it, maybe retry, maybe pass the error to the model, remember to add it to state. After a few months you've got a dozen ad-hoc branches for "what if this turn didn't finish cleanly."

Parallel tool calls are awkward. The model wants to call read and grep at the same time. Now your loop has to either sequence them or spawn promises and reassemble the result before the next llm.plan(). Again, more state to manage.

You can't rewind. state is a pile of mutable objects. You can't branch from an earlier point in the conversation without reconstructing it by hand. You can't replay what the model actually saw. Good luck debugging a long session.

These aren't implementation details. They're the direct result of the while(true) shape: one mutable state object that tries to stand in for the entire history of the conversation.

What if the log is the state?

A few months ago I started building a personal agent, Pizza, with a different premise: the log is the source of truth, and the state is just a projection of that log.

Every message, tool call, result, and file edit becomes one row in an EventStore:

CREATE TABLE events (
  sequence INTEGER PRIMARY KEY,
  event_id TEXT,
  type TEXT,
  payload_json TEXT,
  caused_by TEXT,
  thread_id TEXT,
  ...
);

The runtime doesn't hold state in memory. It reads the tail of this log, dispatches the next event to a handler, and appends the result back. A "turn" is a state transition, not another loop iteration.

The UI, the LLM context, and the session tree are all just queries over the same log. If you want to see what happened, you read the events. If you want to branch the conversation, you start a new thread_id from an earlier sequence. If you want to replay, you re-apply the events.

Other things that fall out of the log

Once you commit to the event log being the source of truth, a bunch of otherwise hard features stop being special cases.

No "new chat" button

There's no hard boundary between tasks. You can keep talking to the same workspace for days, weeks, or years — every previous message, edit, and tool call is still there as an event you can query. The agent manages its own context by projecting the tail of the log, not by asking you to start over with a blank chat. Think of it like a long-running thread with a friend who remembers everything.

One CLI tool, not a JSON menu

Instead of a long list of read_file / write_file / grep / git tools, the model gets one cli tool. Built-in commands like read, write, and edit are handled by structured internal handlers, but everything else — grep, sed, git, npm, python, ls — gets passed straight to the user's shell. The model has to learn shell, but it also gets to compose real pipelines. And because every cli invocation is one event, the log stays consistent: one row for read, one row for git diff, one row for npm test.

Git-like session tree

Because every message is an event with a caused_by pointer, the conversation is already a tree. You can fork from any earlier message, rewind, branch, and continue. It's not a bolt-on undo stack; it's just how the data is shaped.

Same runtime for every interface

The TUI, the desktop app, the JSON-RPC server, and the one-shot CLI all consume the same SessionFacade event stream. They're different projections of the same log. If you start a session in the terminal and later open the desktop app, it's the same event stream.

Agents can `tell` each other

One Pizza agent in workspace A can send a tell event to an agent in workspace B. Workspace B's agent handles the task in its own event log and writes a result back. The actual project files and context from B never leak into A's log — only the tell request and its response are events.

It can even fix itself (if you enable it)

There's an opt-in skill called pizza-self-optimization that reads the local event log as evidence, forks the Pizza repo, reproduces a bug from the log, writes a test, and opens a PR. It only works because the event log is a reproducible record of what the agent actually did.

The trade-offs nobody wants to admit

Event sourcing isn't free. You now have a real database in the hot path. You have to think about replay cost, log size, and snapshotting. If a session has a few thousand events, rebuilding the context from the log on every fork gets slow; you'll want periodic materialized snapshots. I don't have that yet, but it's clearly the next piece.

You also lose the simplicity of "just keep a big state object in memory." If your runtime needs to know something, it has to be in an event. Anything outside the log is an invisible side effect and a bug waiting to happen.

Not a panacea, but not the only shape either

The while(true) pattern is still the right default for a lot of agents. It's simple, it runs, and it fits in a tutorial. But if you want long-running sessions, branching conversations, multi-agent collaboration, and the ability to audit or replay what the agent actually did, it starts to feel like the wrong abstraction.

The EventStore approach has its own costs, but it makes the hard things — forks, replays, multi-agent collaboration, debugging — into ordinary database operations. That was the bet I made with Pizza, and so far it's the part of the design that's held up best.

If you're curious, the code is open source at github.com/tomsun28/pizza. Feedback and arguments welcome.

Monitoring SpringBoot2 Metrics with HertzBeat in 5 minutes

tom — Tue, 28 Mar 2023 16:01:42 +0000

Use the open source real-time monitoring tool HertzBeat to monitor and alarm the SpringBoot2 application, and it will be done in 5 minutes!

HertzBeat Intro

HertzBeat is an open source, real-time monitoring tool with custom-monitor and agentLess.

Monitor+Alerter+Notify all in one. Support monitoring web service, database, os, middleware, cloud-native, network and more.

More flexible threshold rule(calculation expression), timely notification delivery by Discord Slack Telegram Email DingDing WeChat FeiShu Webhook SMS.

We make protocols such as Http, Jmx, Ssh, Snmp, Jdbc configurable, and you only need to configure YML online to collect any metrics you want.

Do you believe that you can immediately adapt a new monitoring type such as K8s or Docker just by configuring online?

HertzBeat's powerful custom-define, multi-type support, easy expansion, low coupling, hope to help developers and micro teams to quickly build their own monitoring system.

Github: https://github.com/dromara/hertzbeat

Monitoring SpringBoot2 Metrics with HertzBeat in 5 minutes

Prerequisite, you already have SpringBoot2 application environment and HertzBeat environment.

HertzBeat Installation and deployment documentation

1. The `actuator` indicator endpoint is exposed on the SpringBoot2 application side, which will provide metrics endpoints data.

Open SpringBoot Actuator Endpoint to expose metrics health env indicator interface

management:
   endpoints:
     web:
       exposure:
         include:
           - 'metrics'
           - 'health'
           - 'env'
     enabled-by-default: on

After restarting, test whether the access indicator interface ip:port/actuator has response json data as follows:

{
   "_links": {
     "self": {
       "href": "http://localhost:1157/actuator",
       "templated": false
     },
     "health-path": {
       "href": "http://localhost:1157/actuator/health/{*path}",
       "templated": true
     },
     "health": {
       "href": "http://localhost:1157/actuator/health",
       "templated": false
     },
     "env": {
       "href": "http://localhost:1157/actuator/env",
       "templated": false
     },
     "env-toMatch": {
       "href": "http://localhost:1157/actuator/env/{toMatch}",
       "templated": true
     },
     "metrics-requiredMetricName": {
       "href": "http://localhost:1157/actuator/metrics/{requiredMetricName}",
       "templated": true
     },
     "metrics": {
       "href": "http://localhost:1157/actuator/metrics",
       "templated": false
     }
   }
}

Add SpringBoot2 application monitoring in the HertzBeat monitoring ui

Click to add SpringBoot2 monitoring

Path: Menu -> Application Service Monitoring -> SpringBoot2 -> Add SpringBoot2 Monitoring

Configure the parameters required for new monitoring SpringBoot2

Fill in the SpringBoot2 application peer IP, service port (default 8080), account password, etc. on the monitoring page, and finally click OK to add.
For other parameters such as collection interval, timeout period, etc., please refer to the help document https://hertzbeat.com/docs/help/

Complete ✅, now we have added the monitoring of the SpringBoot2 application, check the monitoring list to see our additions.

Click Operation->Monitoring Details Icon of the monitoring list item to browse the real-time monitoring indicator data of the SpringBoot2 application.

Click Monitoring History Details TAB to browse the historical monitoring indicator data chart of the SpringBoot2 application📈.

DONE! Done! It doesn't require us to deploy agents or various cumbersome operations, isn't it very simple

Just one step to configure the IP port on the HertzBeat monitoring page and add SpringBoot2 application monitoring

Through the above, we have completed the monitoring of the SpringBoot2 application. We can check the status and availability of various indicators of the SpringBoot2 application at any time in HertzBeat.

Of course, it is impossible to manually check the indicators in real time. Monitoring is often accompanied by alarm thresholds. When the performance indicators of the SpringBoot2 application exceed our threshold or the SpringBoot2 application itself is abnormal, we can promptly notify our corresponding person in charge. The person in charge receives the notification and handles it. , this is a complete monitoring and alarm process.

Next, we will demonstrate step by step how to configure the threshold alarm notification in the HertzBeat system. When the indicators of the SpringBoot2 application are abnormal, we will be notified in time

3. Add SpringBoot2 application indicator threshold alarm in HertzBeat system

Configure an alarm threshold for an important indicator

Path: Menu -> Threshold Rules -> Add Threshold

Select the configured indicator object. SpringBoot2 application monitoring mainly focuses on stack memory threads and other related indicators. For example, we set the threshold for the indicator threads -> threads. When the number of threads in the runnable state is greater than At 300 an alert is issued.
Here we configure to send an alarm when size, state of equals(state, "runnable"") && size>300 of this indicator, the alarm level is warning alarm, which will be triggered three times, specifically As shown below.

Add message notification recipients

Configure the receiver to let the alarm message know who to send and how to send it.

Path: Menu -> Alarm Notification -> Alarm Recipient -> Add New Recipient

Message notification methods support email, DingTalk, WeChat Work, Feishu, WebHook, SMS, etc. Here we take the commonly used DingTalk as an example.

Refer to this Help Documentation https://hertzbeat.com/docs/help/alert_dingtalk to configure the robot on DingTalk and set the security custom keyword HertzBeat, get the corresponding access_token value.
Configure the receiver parameters in HertzBeat as follows.

【Alarm Notification】->【New Recipient】->【Select DingTalk Robot Notification Method】->【Set DingTalk Robot ACCESS_TOKEN】->【OK】

Configure the associated alarm notification strategy ⚠️ [Add notification strategy] -> [Associate the recipient just set] -> [OK]

Configure the alarm notification policy to bind the alarm message with the receiver, so that you can decide which alarms to send to whom.

Finished, now wait for the warning message to come. ding ding ding ding

[HertzBeat warning notification]
Alarm target object: springboot2.threads.size
Affiliated monitoring ID: 483783444839322
Belonging monitoring name: SPRINGBOOT2_localhost
Alarm level: warning alarm
Alarm trigger time: 2023-03-22 21:13:44
Content details: The springboot2 service's runnable state threads num is over 300, now is 444.

Summary

This practical article took us to experience how to use the open source real-time monitoring tool HertzBeat to monitor SpringBoot2 application indicator data. We can find that HertzBeat, which integrates monitoring-alarm-notification, is more convenient in operation and use, just click a little on the page The SpringBoot2 application can be included in the monitoring and alarm notification, and the tedious operations of deploying multiple components and writing configuration files are no longer needed.

Only one docker command is needed to install and experience heartbeat:

docker run -d -p 1157:1157 --name hertzbeat tancloud/hertzbeat

More powerful

Through the simple steps above, we have realized the monitoring of SpringBoot2, but the built-in indicators in it do not meet the needs. Can we customize and monitor more indicators of SpringBoot2? The answer is of course yes, through Monitoring Definition->SpringBoot2 on the page, you can customize and modify the performance indicators you want to monitor by editing the following YML configuration file at any time.

What is HertzBeat?

HertzBeat is an open source, real-time monitoring tool with custom-monitor and agentless.

Monitor+Alerter+Notify all in one. Support monitoring web service, database, os, middleware, cloud-native, network and more.

More flexible threshold rule(calculation expression), timely notification delivery by Discord Slack Telegram Email DingDing WeChat FeiShu Webhook SMS.

We make protocols such as Http, Jmx, Ssh, Snmp, Jdbc configurable, and you only need to configure YML online to collect any metrics you want.

Do you believe that you can immediately adapt a new monitoring type such as K8s or Docker just by configuring online?

HertzBeat's powerful custom-define, multi-type support, easy expansion, low coupling, hope to help developers and micro teams to quickly build their own monitoring system.

⛄ Supported

Site Monitor, Port Availability, Http Api, Ping Connectivity, Jvm, SiteMap Full Site, Ssl Certificate, SpringBoot, FTP Server
Mysql, PostgreSQL, MariaDB, Redis, ElasticSearch, SqlServer, Oracle, MongoDB, Damon, OpenGauss, ClickHouse, IoTDB, Redis Cluster
Linux, Ubuntu, CentOS, Windows
Tomcat, Nacos, Zookeeper, RabbitMQ, Flink, Kafka, ShenYu, DynamicTp, Jetty, ActiveMQ
Kubernetes, Docker
Huawei Switch, HPE Switch, TP-LINK Switch, Cisco Switch
and more for your custom monitoring.
Notifications support Discord Slack Telegram Mail Pinning WeChat FlyBook SMS Webhook.

Github: https://github.com/dromara/hertzbeat

Gitee: https://gitee.com/dromara/hertzbeat

Monitoring Linux Using Open Source Real-Time Monitoring Tool HertzBeat

tom — Wed, 22 Mar 2023 15:15:26 +0000

Use the open source real-time monitoring tool HertzBeat to monitoring and alarm Linux, and it will be done in 5 minutes!

Introduction to HertzBeat

HertzBeat is an open source, easy-to-use and friendly real-time monitoring tool that does not require Agent and has powerful custom monitoring capabilities.

Integrate monitoring-alarm-notification, support monitoring of application services, databases, operating systems, middleware, cloud native, etc., threshold alarms, alarm notifications (email WeChat Dingding Feishu SMS Slack Discord Telegram).
It configurable protocol specifications such as Http, Jmx, Ssh, Snmp, Jdbc, etc. You only need to configure YML to use these protocols to customize and collect any indicators you want to collect. Do you believe that you can immediately adapt to a new monitoring type such as K8s or Docker just by configuring YML?
HertzBeat's powerful customization, multi-type support, easy expansion, and low coupling, hope to help developers and small and medium teams quickly build their own monitoring tools.

Github: https://github.com/dromara/hertzbeat

Get Linux Monitoring Done in HertzBeat in 5 Minutes

Prerequisites, you already have a Linux environment and a HertzBeat environment.

HertzBeat Installation and deployment documentation

Add monitoring of the Linux operating system to the monitoring page of the open source monitoring tool HertzBeat

Click Add Linux Monitoring

Path: Menu -> Operating System Monitoring -> Linux Operating System -> Add Linux Operating System Monitoring

Configure the parameters required for new monitoring Linux

Fill in the Linux peer IP, SSH port (default 22), account password, etc. on the monitoring page, and finally click OK to add.
For other parameters such as collection interval, timeout period, etc., please refer to the help document https://hertzbeat.com/docs/help/mysql/

Complete ✅, now we have added the monitoring of Linux, check the monitoring list to see our added items.

Click Operation->Monitoring Details Icon of the monitoring list item to browse the real-time monitoring indicator data of Linux.

Click Monitoring History Details TAB to browse the historical monitoring indicator data chart of Linux📈.

DONE! Done! To sum up, it only takes one step

On the HertzBeat monitoring page, configure the IP port account password and add Linux monitoring

Through the above two steps, we have completed the monitoring of Linux. We can view the monitoring details and indicators in HertzBeat at any time to observe its service status.
Of course, just looking at it is definitely not perfect. Monitoring is often accompanied by alarm thresholds. When Linux performance indicators exceed our expectations or are abnormal, we can promptly notify our corresponding person in charge. The person in charge receives the notification and handles the problem. It is a complete monitoring and alarm process.

Next, we will demonstrate step by step how to configure threshold alarm notifications in the HertzBeat system, so that when Linux indicators are found to be abnormal, they will be notified to us in time

3. Add Linux indicator threshold alarm in HertzBeat system

Configure an alarm threshold for an important indicator

Path: Menu -> Threshold Rules -> Add Threshold

Select the configured indicator object. Linux monitors mainly related indicators such as cpu, memory, disk, network performance, etc. For example, we set the threshold for the indicator CPU utilization cpu -> usage. When the Linux cpu utilization is greater than 90% When a warning is issued.
Here we configure to send an alarm when the usage>90 of this indicator cpu, the alarm level is Warning Alarm, which will be triggered after three times, as shown in the figure below.

Add message notification recipients

Configure the receiver to let the alarm message know who to send and how to send it.

Path: Menu -> Alarm Notification -> Alarm Recipient -> Add New Recipient

Message notification methods support email, DingTalk, WeChat Work, Feishu, WebHook, SMS, etc. Here we take the commonly used DingTalk as an example.

Refer to this Help Documentation https://hertzbeat.com/docs/help/alert_dingtalk to configure the robot on DingTalk and set the security custom keyword HertzBeat, get the corresponding access_token value.
Configure the receiver parameters in HertzBeat as follows.

【Alarm Notification】->【New Recipient】->【Select DingTalk Robot Notification Method】->【Set DingTalk Robot ACCESS_TOKEN】->【OK】

Configure the associated alarm notification strategy ⚠️ [Add notification strategy] -> [Associate the recipient just set] -> [OK]

Configure the alarm notification policy to bind the alarm message with the receiver, so that you can decide which alarms to send to whom.

Finished, now wait for the warning message to come. ding ding ding ding

[HertzBeat warning notification]
Alarm target object: linux.cpu.usage
Affiliated monitoring ID: 483783444839382
Belonging monitoring name: Linux_182.33.34.2
Alarm level: warning alarm
Alarm trigger time: 2023-02-15 21:13:44
Content details: The linux cpu usage is too high. now is 95.

Summary

This practical article took us to experience how to use the open source real-time monitoring tool HertzBeat to monitor Linux indicator data. We can find that HertzBeat, which integrates monitoring-alarm-notification, is more convenient in operation and use. Linux can be included in the monitoring and alarm notification, and there is no need to deploy multiple components and write configuration files.

Only one docker command is needed to install and experience heartbeat:

docker run -d -p 1157:1157 --name hertzbeat tancloud/hertzbeat

More powerful

Through the simple steps above, we have realized the monitoring of linux, but the built-in indicators in it do not meet the needs. Can we customize and monitor more indicators of Linux? The answer is of course yes, through Monitoring Definition->Linux on the page, you can customize and modify the performance indicators you want to monitor by editing the following YML configuration file at any time.

What is Hertz Beat?

HertzBeat Hertz Beat is a real-time monitoring and alarm system with powerful custom monitoring capabilities and no Agent required. Monitoring of application services, databases, operating systems, middleware, cloud native, etc., threshold alarms, and alarm notifications (email, WeChat, Dingding, Feishu, SMS, Discord, Slack, Telegram).

We make protocol specifications such as Http, Jmx, Ssh, Snmp, Jdbc configurable, and you only need to configure YML to use these protocols to customize and collect any indicators you want to collect.
Do you believe that you can immediately adapt to a new monitoring type such as K8s or Docker just by configuring YML?

The powerful customization of HertzBeat, multi-type support, easy expansion, and low coupling, hope to help developers and small and medium-sized teams quickly build their own monitoring tools.

Github: https://github.com/dromara/hertzbeat
Gitee: https://gitee.com/dromara/hertzbeat

⛄ Supported

Website Monitoring, Port Availability, Http Api, Ping Connectivity, Jvm, SiteMap, Ssl Certificate, SpringBoot, FTP Server
Mysql, PostgreSQL, MariaDB, Redis, ElasticSearch, SqlServer, Oracle, MongoDB, Dameng, OpenGauss, ClickHouse, IoTDB
Linux, Ubuntu, CentOS, Windows
Tomcat, Nacos, Zookeeper, RabbitMQ, Flink, Kafka, ShenYu, DynamicTp, Jetty, ActiveMQ -Kubernetes, Docker
and more for your custom monitoring.
Notification support Discord Slack Telegram Mail DingTalk WeChat Feishu SMS Webhook.

HertzBeat - An open-source monitoring system with custom and agentless.

tom — Mon, 22 Aug 2022 07:09:52 +0000

Hi everyone!

Very happy to be able to recommend an open source project here.

Hertzbeat is an open-source, real-time monitoring system with custom-monitor and agentless. Support web service, database, os, middleware and more.

github: https://github.com/dromara/hertzbeat

home: https://hertzbeat.com/en/

Very welcome to use and give us a star! Thanks!!!!

A security framework that focus on the protection of rest api

tom — Mon, 08 Mar 2021 16:37:05 +0000

Hi everyone! After 22 versions, I'm excited to announce that the JVM security framework for REST APIs, Sureness, is officially GA.

sureness - welcome to use and star. Thanks!

📫 Background

In the mainstream web architecture, how to protect the restful api provided by the back-end through effective and fast authentication has become particularly important.

For existing frameworks, whether it is apache shiro which does not natively support rest, or deeply bound spring, the slower performance and steep learning curve of spring security are not our ideal framework.

Ever since sureness was born, we hope to solve these, provide a restful api, no framework dependency, can dynamically modify permissions, multiple authentication policies, faster, easy to use and extend security framework.

🎡 Introduction

Sureness is a new, permission project which we learn from apache shiro and add some ideas to create it.

Authentication for restful api, based on RBAC, mainly focused on the protection of restful api.

No specific framework dependency(support springboot, quarkus, javalin, ktor and more).

Support dynamic modification of permissions.

Support websocket, mainstream http container(servlet and jax-rs).

Supports JWT, Basic Auth, Digest Auth... Can extend custom supported authentication methods.

High performance due dictionary matching tree.

Good extension interface, demo and document.

The low configuration of sureness, easy to expand, and not coupled with other frameworks, enables developers to quickly and safely protect their projects in multiple scenarios.

🔍 Compare

~	sureness	shiro	spring security
multi framework support	support	support need modify	not support
restful api	support	support need modify	support
websocket	support	not support	not support
path match	dictionary matching tree	ant match	ant match
annotation support	support	support	support
servlet	support	support	support
jax-rs	support	not support	not support
dynamic modification of permissions	support	support need modify	support need modify
performance	fast	slower	slower
learning curve	simple	simple	steep

📈 Benchmark

Benchmark test shows sureness to lose 0.026ms performance compared to frameless application, shiro lose 0.088ms, spring security lose 0.116ms.

In contrast, sureness basically does not consume performance, and the performance (TPS loss) is 3 times that of shiro and 4 times that of spring security.

The performance gap will be further widened as the api matching chain increases.

Detail see Benchmark Test

✌ Framework Sample Support

[x] sureness integration springboot sample(configuration file scheme) sample-bootstrap
[x] sureness integration springboot sample(database scheme) sample-tom
[x] sureness integration quarkus sample sample-quarkus
[x] sureness integration javalin sample sample-javalin
[x] sureness integration ktor sample sample-ktor
[x] sureness integration spring webflux sample sample-spring-webflux
[x] more samples todo

DEV Community: tom

Why Does Every AI Agent Still Look Like `while (true) { ... }`?

The cracks in the loop

What if the log is the state?

Other things that fall out of the log

No "new chat" button

One CLI tool, not a JSON menu

Git-like session tree

Same runtime for every interface

Agents can tell each other

It can even fix itself (if you enable it)

The trade-offs nobody wants to admit

Not a panacea, but not the only shape either

Monitoring SpringBoot2 Metrics with HertzBeat in 5 minutes

Use the open source real-time monitoring tool HertzBeat to monitor and alarm the SpringBoot2 application, and it will be done in 5 minutes!

HertzBeat Intro

Monitoring SpringBoot2 Metrics with HertzBeat in 5 minutes

Prerequisite, you already have SpringBoot2 application environment and HertzBeat environment.

1. The actuator indicator endpoint is exposed on the SpringBoot2 application side, which will provide metrics endpoints data.

Add SpringBoot2 application monitoring in the HertzBeat monitoring ui

3. Add SpringBoot2 application indicator threshold alarm in HertzBeat system

Finished, now wait for the warning message to come. ding ding ding ding

Summary

More powerful

What is HertzBeat?

⛄ Supported

Monitoring Linux Using Open Source Real-Time Monitoring Tool HertzBeat

Use the open source real-time monitoring tool HertzBeat to monitoring and alarm Linux, and it will be done in 5 minutes!

Introduction to HertzBeat

Get Linux Monitoring Done in HertzBeat in 5 Minutes

Prerequisites, you already have a Linux environment and a HertzBeat environment.

Add monitoring of the Linux operating system to the monitoring page of the open source monitoring tool HertzBeat

3. Add Linux indicator threshold alarm in HertzBeat system

Finished, now wait for the warning message to come. ding ding ding ding

Summary

More powerful

What is Hertz Beat?

⛄ Supported

HertzBeat - An open-source monitoring system with custom and agentless.

A security framework that focus on the protection of rest api

📫 Background

🎡 Introduction

🔍 Compare

📈 Benchmark

✌ Framework Sample Support

Agents can `tell` each other

1. The `actuator` indicator endpoint is exposed on the SpringBoot2 application side, which will provide metrics endpoints data.