Frostmourne: log alerting rebuilt because ElastAlert configurations got expensive

The origin is ElastAlert configuration drift

The README explains the motivation more usefully than the feature list does. After standing up ELK, the team found that for application log monitoring there was ElastAlert and not much else. They started with it, and as the configuration grew, both the management cost and the cost of using it rose, and stability was not satisfying them. So they wrote a simpler system aimed at log monitoring. The stated target audience is a team that already has a log system and a metrics system but no alerting layer to match, and the outcome they describe is that the developers on call learn about a production failure sooner than anyone else. That framing matters, because it sets expectations: this is an internal operations tool, not a general observability product.

One query per alarm, across eleven data sources

The central claim of the feature list is that writing a single data query is enough to set up a monitor. The sources listed are Elasticsearch, HTTP, SkyWalking, Prometheus, InfluxDB, MySQL or TiDB, ClickHouse, SqlServer, Ping, IoTDB and Telnet. Repository topics confirm the stack below that surface: springboot2, vue, vue-element-admin, element-ui, mybatis and mybatis-dynamic-sql, so the backend is a Spring Boot 2 application querying through MyBatis and the frontend is the vue-element-admin admin template. Loki, MongoDB, Redis and Oracle are named as future additions rather than present ones. If your source is not in that list today, the project will not cover it.

Comparison types decide whether a number is an alarm

A monitor computes a value and compares it. The numeric calculation types listed are count, min, max, avg, sum, unique count, percentiles and standard deviation, and Elasticsearch data additionally supports bucketing. Two comparison modes sit on top of that: same period and period over period monitoring, which is the Chinese convention of comparing against the same span last period or last year. HTTP monitoring goes further than a status code, since a JavaScript expression evaluates whether to alarm on the response. Ping and Telnet monitors cover connectivity and port reachability respectively. Together these mean the alarm logic is a query plus a threshold, not a query alone, and the front end provides monitor management, testing, save as, execution logs and message history.

Delivery runs from robot webhooks to SMS, through Freemarker templates

Alerts can be sent by DingTalk robot, WeCom robot, Feishu robot, email, SMS or HTTP, in text or markdown format, and the message body is a Freemarker template with variable placeholders that you manage in the application. Two anti-noise features are worth calling out because they are the ones teams discover after a bad week. Alarm suppression prevents message flooding when one condition keeps re-triggering, and alarm escalation exists so that the parties involved in a failure are not left uninformed for a long time. A detail that pays for itself immediately: alarm messages carry a short link to the log query, so the person receiving a notification lands on the query that produced it instead of searching separately.

Distributed scheduling keeps one noisy monitor from delaying others

The scheduling model described in the feature list is distributed, with every monitor scheduled independently so that they do not affect each other. That is a deliberate answer to the stability complaint that motivated the project: in a single scheduler, one slow query or one stuck job delays every alarm behind it. The same feature list also covers a bundled account, team and department management module, which you can replace with your own internal system, LDAP login integration, and permission control with data isolation so teams do not see each other's monitors. For an organisation with several business units, that isolation is the feature that decides whether the platform is shared or duplicated per team.

The HTTP data source is an SSRF risk the project documents itself

The README carries a security notice that deserves to be quoted rather than summarised. The HTTP data source lets a user define an arbitrary request URL, the system fetches it from the server side, and a custom expression decides whether to alarm. The README calls that out as carrying a potential SSRF risk by design, states the system is positioned as an internal network operations tool, and strongly recommends deploying it only on an internal network and never exposing it to the public internet. It goes further: internal deployment is the baseline and not absolutely safe, because a malicious user could still use the feature to reach or probe other internal services, and on a cloud server you must be careful not to allow access to the cloud platform metadata service. The suggested mitigations are least privilege on configured addresses, firewall rules, a proxy gateway, or network level access control on the deployment host.

Three deployment paths, and a k8s snippet with a typo

The zip path is the simplest: download a release archive, extract it, adjust application.properties and the env file, then start and stop with the bundled scripts. It needs JDK 1.8 and MySQL 5.7.8 or newer. The self build path adds Maven 3.2.x or newer and produces the same zip through the assembly packaging:

mvn -U clean package -DskipTests=true

./scripts/startup.sh

Building the frontend project frostmourne-vue automatically writes assets into the monitor module's resources/dist, so only frostmourne-monitor needs deploying. The Kubernetes path uses three manifests, with parameters in the deployment file and the externally mapped port set in the service file, defaulting to nodePort 30054:

kubectl applt -f frostmourne-monitor-namespace.yaml
kubectl applt -f frostmourne-monitor-deployment.yaml
kubectl apply -f frostmourne-monitor-service.yaml

Note the first two lines: applt is not a kubectl subcommand, so those two lines will fail as written and need correcting to apply before you use them. Before any of this, create the schema: every table's DDL lives in doc/mysql-schema/frostmourne.sql. Passwords are stored in plaintext by default with no encryption, and the README points at the druid ConfigFilter documentation if you need to encrypt them.

Spring Boot 2 on JDK 8 with no release since 2023

The stack is dated in a way that matters for a new adoption decision. The backend is springboot2 and the requirement is JDK 1.8 with MySQL 5.7.8 or newer, so the application runs on a Java version most organisations have already retired. The newest GitHub release is 1.0-RELEASE dated 2023-03-25, preceded by 0.9.1 and 0.9 in September 2022, while the last push to the repository was on 2026-04-17, so commits continue without new tagged releases. The licence is MIT, and the project is hosted on both GitHub and Gitee with an English README alongside the Chinese one. Translation of the interface is not the project's problem: the user facing surface is the vue-element-admin frontend, which is where you will spend your time.

Editorial conclusion

Frostmourne fits an organisation that already runs ELK or Prometheus and wants one query per alarm with a short link back to the log query, plus DingTalk, WeCom, Feishu, email, SMS or HTTP delivery, without maintaining ElastAlert rule files by hand. Do not deploy it as the README warns against: keep it on the internal network only, because the HTTP data source lets a user make the server fetch any URL and evaluate the response with a JavaScript expression. Before installing, read that security notice and the suppression and escalation guides, and confirm your platform can still run Spring Boot 2 on JDK 1.8 against MySQL 5.7.8 or newer, because the newest release is 1.0-RELEASE from 2023-03-25 while the last push was on 2026-04-17.

Frequently asked questions

Official sources

1. AutohomeCorp/frostmourne on GitHub
2. License: MIT
3. Project website
4. README
5. Releases