# Webfunny Monitor: self-hosted frontend APM and product analytics in one Node.js stack

> Webfunny Monitor bundles frontend monitoring, backend APM and a business event-tracking system into a single self-hosted deployment. Here is what the repository actually contains, how to start it with Docker, and where it stops being the right tool.

**a597873885/webfunny_monitor** — 【免费社区版】【企业版】Webfunny是一款集全链路监控和用户行为分析（埋点）系统于一体的大数据分析系统，我们致力于解决线上的疑难杂症和精细化分析业务数据；监控系统面向技术、埋点系统面向业务，两者配合使用，相得益彰。

- Repository: https://github.com/a597873885/webfunny_monitor
- Website: https://www.webfunny.com/
- Stars: 5,303 · Forks: 882
- Language: JavaScript
- License: Apache-2.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/a597873885-webfunny-monitor

## What Webfunny Monitor bundles that single-purpose tools do not

The README describes three subsystems shipped in one repository: a frontend monitoring system for engineering teams, an APM backend monitoring system for backend and operations teams, and an event-tracking system for business teams. The frontend side covers PV and UV traffic, error aggregation with SourceMap resolution, page and API performance waterfalls, remote debugging of a user's console, localStorage and cookies, session recording, and alert rules delivered by email or webhook. The APM side reports P99, P95 and P50 response times, distributed tracing, slow SQL filtering at 100ms, 200ms and 500ms thresholds, and a service topology graph. The tracking side offers funnel and retention cards, visual point-and-click event definition for product managers, a reusable field repository, and Excel or API export.

The audience is therefore split. A frontend team that only wants JavaScript error grouping is over-served by the APM and event modules. A product team that wants funnel analysis without an engineering owner for the infrastructure gets both, but also inherits the operational work. The repository topics list apm, front-end-monitor, burying-point and topology, which matches that three-part scope.

One caveat on the marketing claims. The README states support for hundred-million-scale daily active users and a cluster edition. The repository does contain webfunny_cluster.js and webfunny_cluster_test.js, so a clustered entry point exists in the tree. Whether a given deployment reaches that scale depends on your database and node count, and the README does not give a sizing table.

## How the cluster entry point, initialization scripts and pm2 fit together

The package is named webfunny_monitor_cluster and its main field points at app.js. The runtime entry point for production is webfunny_cluster.js, started through pm2 rather than plain node. That is the first architectural fact worth knowing: process supervision is assumed, not optional.

Before the cluster starts, a bootstrap step runs a sequence of initialization scripts. The bootstrap script in package.json chains config.init.js, alarm.init.js, interceptor.init.js, util.cus.js, sso.init.js, other.init.js and selfMonitor.init.js from the webfunny_init directory. These generate configuration, alarm, interceptor and SSO resources. The production script then runs initResource.js, flushes pm2, starts the cluster, saves the process list and tails the logs. A restart script deletes the pm2 process, flushes and re-runs production, which is the documented way to pick up changes.

The publish scripts split the backend by server type: center, monitor, event, logger, apm and file. That naming maps onto the three product surfaces plus shared services, so a deployment can be described as a set of logical servers rather than one monolith. The repository also carries OTEL_MIGRATION.md and OTEL_USAGE_GUIDE.md at the top level, which indicates an OpenTelemetry path exists alongside the native collection, though the README itself does not walk through it.

A single-server variant exists: publish_single.js and a publish_single script. If you do not want the cluster topology, that is the branch to read.

## Installing Webfunny Monitor with Docker and reaching the first dashboard

The README points to a hosted deployment document for the full Docker instructions and does not reproduce the compose file inline, so treat the commands below as the shape of the build rather than a complete recipe. The Dockerfile in the repository is explicit about the base image and the exposed ports.

The image is built on node:16.20.2-slim. That pins you to Node.js 16, which is a real constraint for anyone standardizing on a newer runtime. The build installs pm2 globally, copies the tree into /app, runs npm install, then runs npm run bootstrap, and finally sets the container timezone to Asia/Shanghai.

```dockerfile
FROM node:16.20.2-slim
RUN npm install pm2 -g
COPY . /app
WORKDIR /app
RUN npm install
RUN npm run bootstrap
EXPOSE 9010
EXPOSE 9011
CMD npm run prd
```

Two ports are published: 9010 and 9011. The container command is npm run prd, which expands to initResource.js, a pm2 flush, pm2 start webfunny_cluster.js, pm2 save and pm2 logs. Because the last step tails logs, the container foreground stays attached to pm2 output, which is what you should expect to see in docker logs.

If you prefer to run it directly on a host with Node.js 16 and pm2 available, the production script is the same one the container calls.

```bash
npm install
npm run bootstrap
npm run prd
```

After startup, the reader should look for the cluster process in pm2 and for the dashboard on one of the two exposed ports. The README does not state which port serves the UI and which serves the collector, so verify that against the deployment document before opening firewall rules.

## The release cadence is slower than the commit history suggests

The repository is not archived, and the last push was on 2026-09-20, so the codebase is being touched. The releases tell a different story. The most recent tagged release is 3.1.60 (3.1.60-stable), dated 2023-04-30. Before that, 3.1.19 and 3.1.17 land in late 2022. That is a gap of more than three years between the newest tag and the newest commit.

For an operator this matters in a specific way. If you deploy from a tag, you are deploying 2023 code. If you deploy from main, you are deploying unreleased code with no version to cite in an incident review. The repository offers no documented rollback procedure, and the README does not describe how to move between versions or how database migrations are handled across upgrades. The restart scripts assume you are replacing a running pm2 process on the same host, not reverting a schema.

There is also a licence mismatch worth flagging. The repository LICENSE is Apache-2.0, while the package.json license field says ISC. Those are different terms. The README links to a pricing page where a community edition is described as private-deployment, free and aimed at individuals, and where source purchase is mentioned for customization. Which terms apply to your use is a question for the project, not something the repository settles on its own.

## Where a hosted or single-purpose tool is the better choice

The clearest alternative for the frontend-error half is Sentry. The difference is not feature parity, it is who runs the pipeline. Sentry's hosted offering removes the pm2 process, the Node.js 16 pin and the two open ports from your plate, and it ships a documented release cadence. Webfunny Monitor instead asks you to own the ingestion endpoint, the database behind the APM store and the upgrade path, in exchange for keeping all collected data inside your own network and for having the event-tracking module in the same installation.

If your actual need is only product funnels and retention, a dedicated analytics product will fit better than a monitoring stack that grew a tracking module. The reverse also holds: if you only want distributed tracing for backend services, the OTEL documents in this repository suggest you would be adopting a larger system to get a narrower capability, and a tracing-first backend is the more direct route.

The honest boundary is team size. A single frontend engineer who wants error grouping will spend more time on pm2, Docker and the initialization scripts than on reading stack traces. Webfunny Monitor pays off when one team owns the infrastructure and several teams consume the dashboards.

## Frequently asked questions about Webfunny Monitor

The entries below are answered from the repository contents only. Where the repository is silent, the answer says so rather than guessing.

## Conclusion

Adopt Webfunny Monitor if you need frontend errors, backend traces and product funnels in one self-hosted place, and you are comfortable running a Node.js 16 stack with pm2 and two exposed ports. Do not adopt it if you need a vendor-supported release cadence or a documented rollback path. Before committing, verify the community-edition licence terms on the pricing page and confirm that the Docker image reaches a healthy dashboard on your own host.

## FAQ

### What runtime does Webfunny Monitor require?

The Dockerfile builds on node:16.20.2-slim and installs pm2 globally, so the documented container path assumes Node.js 16 and a pm2-supervised cluster process. The package scripts start webfunny_cluster.js through pm2 rather than plain node.

### Which ports does Webfunny Monitor expose?

The Dockerfile exposes 9010 and 9011. The repository does not state which of the two serves the dashboard and which serves data collection, so that has to be confirmed against the deployment document.

### Can I deploy Webfunny Monitor without Docker?

Yes. The package scripts run npm install, npm run bootstrap and npm run prd on a host with Node.js and pm2, and npm run restart deletes the pm2 process, flushes it and re-runs production.

### Is Webfunny Monitor free to self-host?

The README describes a community edition as private-deployment, free and aimed at individuals, and mentions purchasing source for customization. The repository LICENSE is Apache-2.0 while package.json declares ISC, so the applicable terms need to be confirmed with the project.

## Sources

- [a597873885/webfunny_monitor on GitHub](https://github.com/a597873885/webfunny_monitor)
- [License: Apache-2.0](https://github.com/a597873885/webfunny_monitor/blob/main/LICENSE)
- [Project website](https://www.webfunny.com/)
- [README](https://github.com/a597873885/webfunny_monitor/blob/main/README.md)
- [Releases](https://github.com/a597873885/webfunny_monitor/releases)

---

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