Pulse Monitor runs entirely within your existing infrastructure. No new servers. No external cloud services. No vendor lock-in beyond what you already run.
Register any combination of server types. Each uses its own purpose-built collector — no generic polling, no guesswork.
WLST/T3-based collector. Pulls per-managed-server CPU, heap, threads, lifecycle, and JDBC data sources. Supports trust-store scanning, MDB tracking, and FTP-based log download.
Reads JVM and thread details from manager/text/vminfo and enriches with connector/request counters from manager/status?XML=true. FTP used for log analysis. No JMX exposure required.
Pulls pod and node summary from the kube-apiserver via /api/v1/pods and /api/v1/nodes. Namespace-scoped or cluster-wide. Uses a ServiceAccount bearer token — no privileged access needed. Log analysis skipped by policy for K8s.
Calls the Docker Engine HTTP API — /containers/json, /info, per-container inspect and one-shot stats. Dashboard shows an eight-section engine view: host overview, container list, memory/PIDs, network and disk I/O, mount inventory, and topology hints. Up to 200 containers per run.
No infra collector — exists so the log analyzer can poll any generic FTP location for arbitrary .log / .txt / .out files. Set Server Health Check = NO for this type.
Most monitoring tools require you to open firewall ports, install cloud connectors, or send telemetry to third-party servers. Pulse Monitor does none of that.
Deployed as a standard Java EE web application to the same WebLogic cluster you already manage. No new runtime needed.
All Pulse data lives in your Oracle DB — the same database that hosts your SOA and MDS schemas. No extra database licence required.
All communication is internal. Pulse calls the WebLogic admin server and your Oracle DB — nothing leaves your data centre.
Pulse Monitor deploys as a standard WAR to the same WebLogic domain it monitors. It reuses your existing server infrastructure, JDBC connection pools, and JNDI naming — no separate middleware tier.
All Pulse tables are created in your existing Oracle schema. Configuration, alerts, deployment records, metric snapshots, log analysis results, and certificate data are all stored and queryable via standard SQL.
Metric collection scripts bundled inside the application connect to your server infrastructure on a configurable schedule. No agents, no JMX exposure beyond the admin port you already use.
The Qiyara chatbot and AI log analytics are powered by LangChain4j. The LLM key is configured per environment in your properties file and never transmitted outside your infrastructure.
Application server host
HTTP Manager collector
REST kube-apiserver
Docker Engine HTTP API
Composite monitoring
OSB deploy & monitor
All persistence
Configurable AI key
Pulse Monitor was built from the ground up for organisations with strict data sovereignty requirements. Every metric, log entry, alert, and configuration record stays inside your Oracle database behind your firewall.
Security controls include layered request hardening, role-based menu access, CSRF protection on all mutating actions, TLS enforcement with HSTS, CIDR-aware forwarded header trust, and a bounded LRU rate limiter with a separate stricter cap for login — all configurable per environment.
See the security modelOne WAR file. Your WebLogic server. Your Oracle database. Get started in an afternoon.