神级开源,一站式、轻量级、低门槛、零侵入的 Java 应用全方位监控平台,开箱即用!!!

神级开源,一站式、轻量级、低门槛、零侵入的 Java 应用全方位监控平台,开箱即用!!!

一、前言

Java 应用开发的同学都知道,项目上线后,日志可视化查询、接口性能监控、慢请求分析、调用链监控、JVM 可视化监控是一件非常重要的事。
市面上对于上对于日志的可视化查询、接口的性能监控、调用链监控、JVM 的可视化监控都有常用的方案。

  • 日志可视化查询:ELK/EFK。
  • JVM 可视化监控与接口性能:Actuator + Prometheus + Grafana。
  • 调用链监控:PingPoint、Skywalking、Zipkin 等。

不过对于很多开发者来说,这中间存在大量繁琐的配置过程,且具备一定的使用学习门槛,部署成本与运维成本也比较高。

而对于大多数中小型企业或者个人开发者来说,并不想要这么大的投入,但又想要对应用做全方位的监控管理该怎么办?

小编今天要介绍的就是这样一款可免费使用的 Java 应用全方位监控平台。一站式、轻量级、低门槛、零侵入,开箱即用。

旨在于以极简、高效的方式,在一个平台上实现 Java 应用的日志采集与可视化查询、接口性能监控、慢请求分析、调用链监控、JVM 可视化监控。

二、软件介绍

zero-observer + zero-log = Java 应用一站式监控

官网地址:https://kuafucv.com

1. 系统架构

主要分为客户端和服务端两个部分。

2. 采集客户端【zero-log】

旨在提供低门槛、少配置、轻量级、无侵入的方式实现应用日志、接口性能、调用链、JVM 指标的自动采集与上报。
  • 基于 logback 实现自动采集代码中通过 log.error、log.warn、log.info、log.trace 方式输出的日志。
  • 采集各个接口的性能数据。
  • 采集方法调用链数据。
  • 采集 JVM 运行时各项指标。

3. 服务端【zero-observer】

收集客户端采集插件采集的客户端数据,并提供开箱即用的可视化与管理功能。

4. 功能介绍

功能实现情况
登录认证
仪表盘统计
应用日志采集
应用控制台日志
应用日志列表检索
接口性能监控
接口慢请求分析
CPU 监控
物理内存监控
堆内存监控
非堆内存监控
Eden区监控
Survivor区监控
OldGen区监控
Metaspace区监控
线程监控
GC监控
调用链监控

仪表盘

应用日志

控制台日志

应用日志查询

应用日志详情

接口性能监控

慢请求分析

调用链监控

JVM 监控



三、服务端部署

zero-observer 数据存储使用的是 mysql 与 elasticsearch,mysql 存储的是系统数据,elasticsearch 存储的是日志数据。
所以需要自行安装 mysql 与 elasticsearch。

1. Mysql 初始化脚本

创建数据库:zero_observer,执行脚本。

CREATE TABLE `app_log_growth_trend` ( `id` bigint(20) NOT NULL, `create_time` datetime NOT NULL, `app` varchar(255) NOT NULL, `env` varchar(50) NOT NULL, `level` varchar(10) NOT NULL, `statistic_time` datetime NOT NULL, `log_count` int(11) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `app_log_total_growth_trend` ( `id` bigint(20) NOT NULL, `create_time` datetime NOT NULL, `statistic_time` datetime NOT NULL, `log_count` bigint(20) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `app_log_level_statistic` ( `id` bigint(20) NOT NULL, `create_time` datetime NOT NULL, `app` varchar(255) NOT NULL, `env` varchar(50) NOT NULL, `level` varchar(10) NOT NULL, `statistic_time` datetime NOT NULL, `log_count` int(11) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `app_env_instance` ( `id` bigint(20) NOT NULL, `create_time` datetime NOT NULL, `app` varchar(255) NOT NULL, `env` varchar(50) NOT NULL, `ip` varchar(50) NOT NULL, `port` varchar(5) NOT NULL, `hostname` varchar(255) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `app_log_statistic` ( `id` bigint(20) NOT NULL, `create_time` datetime NOT NULL, `app_log_statistic_counter_id` bigint(20) NOT NULL, `app` varchar(255) NOT NULL, `env` varchar(50) NOT NULL, `statistic_time` datetime NOT NULL, `log_count` bigint(20) NOT NULL DEFAULT '0', `slow_request_count` bigint(20) NOT NULL DEFAULT '0', `error_count` bigint(20) NOT NULL DEFAULT '0', `warn_count` bigint(20) NOT NULL DEFAULT '0', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `app_log_statistic_counter` ( `id` bigint(20) NOT NULL, `create_time` datetime NOT NULL, `statistic_time` datetime NOT NULL, `statistic_status` int(11) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `system_config` ( `id` bigint(20) NOT NULL COMMENT '主键', `create_time` datetime NOT NULL COMMENT '创建时间', `key_code` varchar(50) NOT NULL COMMENT 'key编码', `key_name` varchar(50) DEFAULT NULL COMMENT 'key 名称', `key_value` varchar(255) NOT NULL COMMENT 'key值', `enabled` int(11) NOT NULL DEFAULT '1' COMMENT '是否启用', PRIMARY KEY (`id`) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; INSERT INTO `system_config` (`id`, `create_time`, `key_code`, `key_name`, `key_value`, `enabled`) VALUES (1, '2025-07-19 23:56:06', 'app_log_storage_days', '应用日志存储天数', '3', 1); CREATE TABLE `users` ( `id` bigint(20) NOT NULL, `create_time` datetime NOT NULL, `account` varchar(100) NOT NULL, `pwd` varchar(255) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `token_info` ( `id` bigint(20) NOT NULL, `create_time` datetime NOT NULL, `subject` varchar(100) NOT NULL, `token` varchar(255) NOT NULL, `expire_time` datetime NOT NULL, `expire_timestamp` bigint(20) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `license` ( `id` bigint(20) NOT NULL, `create_time` datetime NOT NULL, `content` text NOT NULL, `remark` text DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `request_monitor_statistic` ( `id` bigint(20) NOT NULL, `create_time` datetime NOT NULL, `statistic_date` int(11) NOT NULL, `app` varchar(255) NOT NULL, `env` varchar(50) NOT NULL, `uri` varchar(255) NOT NULL, `executeCount` int(11) DEFAULT NULL, `rtAvg` float DEFAULT NULL, `rtMax` int(11) DEFAULT NULL, `rtMin` int(11) DEFAULT NULL, `slow_count` int(11) DEFAULT 0, `slow_avg` float DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `request_mapping` ( `id` bigint(20) NOT NULL, `create_time` datetime NOT NULL, `app` varchar(255) NOT NULL, `env` varchar(50) NOT NULL, `ip` varchar(50) NOT NULL, `port` varchar(5) NOT NULL, `hostname` varchar(255) NOT NULL, `uri` varchar(255) DEFAULT NULL, `method` varchar(10) DEFAULT NULL, `handler_method` varchar(255) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; ALTER TABLE app_env_instance ADD online INT NULL; ALTER TABLE app_env_instance ADD last_heartbeat DATETIME NULL; ALTER TABLE request_monitor_statistic ADD req_method varchar(10) NULL; CREATE TABLE `app_env` ( `id` bigint(20) NOT NULL, `create_time` datetime NOT NULL, `app` varchar(255) NOT NULL, `env` varchar(50) NOT NULL, `gene` varchar(20) NOT NULL, `signature` varchar(100) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `sys_lock` ( `id` bigint(20) NOT NULL, `create_time` datetime NOT NULL, `lock_name` varchar(100) NOT NULL, `status` INT NOT NULL, `last_heartbeat` datetime DEFAULT NULL, `holder` varchar(255) DEFAULT NULL, `holder_id` varchar(255) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; 

2. Docker 部署

拉取镜像

docker pull registry.cn-hangzhou.aliyuncs.com/kuafucv/zero-observer:2.0.0 

启动容器

docker run -itd -p 8080:8080 --name zero-observer \ -e TZ=Asia/Shanghai \ -e ES_IP=127.0.0.1 \ -e ES_PORT=9200 \ -e ES_USERNAME=es \ -e ES_PASSWORD=es \ -e MYSQL_IP=127.0.0.1 \ -e MYSQL_PORT=3306 \ -e MYSQL_USERNAME=root \ -e MYSQL_PASSWORD=123456 \ registry.cn-hangzhou.aliyuncs.com/kuafucv/zero-observer:2.0.0 
参数解析:TZ:时区,默认 Asia/ShanghaiES_IP:elasticsearch 的 ipES_PORT:elasticsearch restapi 的端口ES_USERNAME:elasticsearch 用户名,无则不填即可ES_PASSWORD:elasticsearch 密码,无则不填即可MYSQL_IP:mysql 的ipMYSQL_PORT:mysql 端口MYSQL_USERNAME 用户名MYSQL_PASSWORD 密码

启动成功后,浏览器访问:http://127.0.0.1:8080/zero-observer/

默认用户密码:admin/123456

四、SpringBoot 应用接入

1. 引入 maven 依赖

<dependency><groupId>io.github.kuafucv</groupId><artifactId>zero-log-spring-boot-starter</artifactId><version>2.0.0</version></dependency>

2. 配置 application.yml

zero: log: server-url: http://127.0.0.1:8080/zero-observer 
注意:serverUrl 为 zero-observer 服务访问地址,该属性值为 http://ip:port/zero-observer

3. 启动类添加注解

启动类添加 @EnableZeroLog 注解

@SpringBootApplication@EnableZeroLogpublicclassApplication{publicstaticvoidmain(String[] args){SpringApplication.run(Application.class, args);}}

4. 启动服务

启动 Java 服务,等待日志自动上报至 zero-observer ,前往 zero-observer 查看对应数据。

更多内容请参考官网:https://kuafucv.com

Read more

Flutter 三方库 m_map 的鸿蒙化适配指南 - 实现具备嵌套合并与动态路径查找的增强型 Map 处理、支持端侧复杂配置项的高阶变换实战

Flutter 三方库 m_map 的鸿蒙化适配指南 - 实现具备嵌套合并与动态路径查找的增强型 Map 处理、支持端侧复杂配置项的高阶变换实战

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 m_map 的鸿蒙化适配指南 - 实现具备嵌套合并与动态路径查找的增强型 Map 处理、支持端侧复杂配置项的高阶变换实战 前言 在进行 Flutter for OpenHarmony 的复杂配置管理、动态 UI 属性注入或大型 JSON 报表解析开发时,原生 Dart 的 Map 往往显得过于基础。如何优雅地实现两个深度嵌套 Map 的递归合并?如何通过“点号路径(Dot Notation)”快速访问深层属性?m_map 是一款专为 Map 处理性能与灵活性优化的增强库。本文将探讨如何在鸿蒙端构建极致、敏捷的键值对处理模型。 一、原直观解析 / 概念介绍 1.

Flutter for OpenHarmony:Flutter 三方库 redux_epics — 优雅管理鸿蒙状态管理中的异步副作用(适配鸿蒙 HarmonyOS Next ohos)

Flutter for OpenHarmony:Flutter 三方库 redux_epics — 优雅管理鸿蒙状态管理中的异步副作用(适配鸿蒙 HarmonyOS Next ohos)

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net。 Flutter for OpenHarmony:Flutter 三方库 redux_epics — 优雅管理鸿蒙状态管理中的异步副作用(适配鸿蒙 HarmonyOS Next ohos) 在构建大型跨平台应用时,状态管理的严谨性直接决定了项目的可维护性。Redux 以其单向数据流和不可变状态锁定了许多开发者的心。然而,纯粹的 Redux 加速器(Reducer)必须是同步且无副作用的函数,这给处理异步网络请求、文件读写等副作用带来了挑战。 在 Flutter for OpenHarmony 开发中,redux_epics 结合 RxDart 的强大处理能力,为我们提供了一个基于“流”的副作用管理方案。今天,我们将实战如何利用 Epics 在鸿蒙应用中优雅地编排复杂的异步生命周期。 一、为什么需要 Epics? 1.

Flutter 组件 test_reflective_loader 适配鸿蒙 HarmonyOS 实战:反射装载矩阵,构建规模化测试的自动化分发中枢

Flutter 组件 test_reflective_loader 适配鸿蒙 HarmonyOS 实战:反射装载矩阵,构建规模化测试的自动化分发中枢

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 test_reflective_loader 适配鸿蒙 HarmonyOS 实战:反射装载矩阵,构建规模化测试的自动化分发中枢 前言 在鸿蒙(OpenHarmony)生态迈向大规模企业级应用、涉及深度组件解耦与多维功能验证的背景下,如何通过标准化的框架降低测试样板代码(Boilerplate)的维护成本,已成为决定项目迭代质效的“深水区工程”。在鸿蒙设备这类强调 AOT 编译性能与严苛环境隔离的移动终端上,如果依然依赖传统的手工挂载单元测试用例,由于由于随着业务规模膨胀而呈几何级增长的维护量,极易由于由于人为疏漏导致核心路径的测试脱节。 我们需要一种能够在开发期利用反射特性自动探测用例、支持面向对象继承复用且具备高度声明式语义的测试装载方案。 test_reflective_loader 为 Flutter 开发者引入了基于反射的测试组织范式。它允许通过定义标准的测试类(Test Classes),并在运行时自动识别带有特定前缀的测试

Flutter 组件 dartframe 的适配 鸿蒙Harmony 实战 - 极简主义后端框架集成、多端逻辑复用与业务解耦重构方案

Flutter 组件 dartframe 的适配 鸿蒙Harmony 实战 - 极简主义后端框架集成、多端逻辑复用与业务解耦重构方案

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 dartframe 的适配 鸿蒙Harmony 实战 - 极简主义后端框架集成、多端逻辑复用与业务解耦重构方案 前言 在 Flutter 生态不断向桌面和服务器端扩展的今天,寻找一个轻量、灵活且对 Dart 原生特性挖掘深化的框架,已成为全栈开发者的追求。dartframe 正是这样一款倡导“极简、快速、模块化”的通用型 Dart 开发框架,它不依赖于繁重的第三方库,力求给开发者最直观、最清爽的编码体验。 当我们站在鸿蒙系统(OpenHarmony)适配的门槛上,审视这类框架时,其最大的魅力在于:它能让我们在鸿蒙端复用那一套被验证过的、纯粹的 Dart 业务逻辑块,同时轻松剥离那些高度依赖平台、环境的副作用代码。 本文将带你深度剖析如何通过 dartframe 在鸿蒙应用中实现高效的“多端同构”开发模式,