System Monitoring

Overview

PlantPulse monitoring consists of 3 layers. By using the tools in each layer together, you can detect problems early and respond quickly.

Layer	Responsibility	Frequency
L1 Host/Stack	Container status/health, resource usage, health responses	Every 1~5 min (Auto/Manual)
L2 Platform Built-in	Business metrics by module (throughput, lag, queue depth, JVM)	Real-time
L3 External Monitoring	Long-term trends, alarms, integrated view of multiple hosts	Real-time

Platform Service Modules

PlantPulse consists of multiple service modules starting with the plantpulse- prefix. Modules and containers are not 1:1 — the six application modules each have their own container, while the remaining infrastructure modules run together within one plantpulse-datalake container.

Location	Module
Own Container	plantpulse-server-web · plantpulse-batch-web · plantpulse-warehouse-web · plantpulse-plugin-opcua · plantpulse-plugin-aasx · plantpulse-ha
Inside plantpulse-datalake Container	storage · messaging · analytics · timeseries · workflow · cep · data-gateway · sql · monitor · backup

Container-level status is viewed from the host via bin/status.sh, while module-level status within the datalake is viewed via status.sh inside the container. The «ports» below are the ports opened by the module inside the container; only some of these are exposed to the host → Port Configuration Information

Core Service Modules

Module	Port	Description
plantpulse-server	80 / 443	Web server and administration console, REST API
plantpulse-cep	7400 / 7401	Complex Event Processing engine (Aster CEP)
plantpulse-batch	9500	Batch processing server
plantpulse-data-gateway	5500	Data gateway (HTTP REST-based data inquiry)
plantpulse-datalake-admin-api	4950 (HTTPS)	Administration console API and monitoring agent. The only health port published to the host
plantpulse-warehouse-web	9600	Data warehouse
plantpulse-plugin-opcua	11004 / 11005	OPC-UA server plugin
plantpulse-plugin-aasx	(Not exposed to host)	AASX server plugin
plantpulse-ha	10210	Redundancy recovery daemon
plantpulse-proxy	80 / 443 / 1883 / 1884	Sole entry point for users and equipment

Messaging Modules (plantpulse-messaging)

Service	Port	Description
Kafka	9092	Distributed message streaming
MQTT	1883	IoT lightweight message protocol
MQTT Enterprise	-	MQTT Enterprise Edition

Storage Modules (plantpulse-storage)

Service	Port	Description
Cassandra 6.0	9042	Time series database (CQL)
PostgreSQL	5432	Metadata relational database
Valkey (Redis)	6379	In-memory cache
RustFS	9000	Object storage (S3 compatible)
Neo4j	-	Graph database
RustFS / WeedFS	-	Distributed file system

Analytics Modules (plantpulse-analytics)

Service	Port	Description
Spark Master	7077	Distributed analytics engine
Spark UI	4440	Spark administration console
Kyuubi	10000	Distributed SQL gateway (JDBC/Thrift)
Gravitino	19001	Data catalog
Hadoop	-	Distributed file system
Hive	-	Data warehouse query engine

Time Series Modules (plantpulse-timeseries)

Service	Port	Description
Time series engine	7800	Time series data processing engine
Time series UI	3000	Time series data visualization UI

Workflow Modules (plantpulse-workflow)

Service	Port	Description
Temporal	7233	Distributed workflow engine (Web UI 8233)
Kestra	8380	Workflow orchestration / scheduler

Utility Modules

Module	Description
plantpulse-datalake-cli (pd)	CLI for datalake start/stop/restart, configuration, and node management
plantpulse-setup	Initial setup tool (model, CSV configuration)
plantpulse-backup	Backup service
plantpulse-recovery	Data recovery tool
plantpulse-exporter	Asset data export tool
plantpulse-migrator	Data migration tool (Spark-based)
plantpulse-mirror-maker	Data replication tool
plantpulse-simulator	Data simulator (for testing)
plantpulse-api	REST API client library

Verifying Service Status

First, check the overall stack status from the host.

cd /opt/kopens/plantpulse-platform-docker/bin
./status.sh          # 0 = 정상 / 2 = 비정상
./ops-check.sh       # 헬스 + 최근 critical log

Check the port-level status of infrastructure modules inside the datalake container.

./shell.sh
/opt/kopens/plantpulse-platform/plantpulse-datalake-cli/bin/pd status

Output example:

==============================================================================================================
 PLANTPULSE PLATFORM - ALL SERVICE STATUS
 2026-03-01 12:00:00
==============================================================================================================

<SYSTEM RESOURCE OVERVIEW>
--------------------------------------------------------------------------------------------------------------
 포트   서비스                     상태
--------------------------------------------------------------------------------------------------------------
 9092   PP_MESSAGING[KAFKA]        ● RUNNING
 1883   PP_MESSAGING[MQTT]         ● RUNNING
 9042   PP_STORAGE[CASSANDRA]      ● RUNNING
 5432   PP_STORAGE[POSTGRESQL]     ● RUNNING
 6379   PP_STORAGE[REDIS]          ● RUNNING
 9000   PP_STORAGE[MINIO]          ● RUNNING
 7077   PP_ANALYTICS[SPARK-MASTER] ● RUNNING
 4440   PP_ANALYTICS[SPARK-UI]     ● RUNNING
 10000  PP_ANALYTICS[KYUUBI]       ● RUNNING
 19001  PP_ANALYTICS[GRAVITINO]    ● RUNNING
 7233   PP_WORKFLOW[ENGINE]        ● RUNNING
 8380   PP_WORKFLOW[BATCH]         ● RUNNING
 7800   PP_TIMESERIES[ENGINE]      ● RUNNING
 3000   PP_TIMESERIES[UI]          ● RUNNING
 7400   PP_CEP                     ● RUNNING
 5500   PP_DATA_GATEWAY            ● RUNNING
 4000   PP_SQL                     ● RUNNING
 4950   PP_MONITOR                 ● RUNNING
 60000  PP_AGENT                   ● RUNNING
 80     PP_SERVER                  ● RUNNING
 9500   PP_BATCH                   ● RUNNING
 9600   PP_WAREHOUSE               ● RUNNING
 11004  PP_PLUGIN[OPCUA]           ● RUNNING

App containers are not shown in the list above

The status.sh inside the datalake only monitors the modules within that container. Even if PP_SERVER, PP_BATCH, PP_WAREHOUSE, or PP_PLUGIN appear as STOPPED or are missing entirely, it is not a failure — those apps run in their own containers, and their status is determined by bin/status.sh on the host.

Environment Variables

Host-side values are determined by /opt/kopens/plantpulse-platform-docker/bin/env.sh, and values actually seen by the container are determined by compose/docker-compose.yml. For detailed relationships and priorities, refer to the Environment Variable Reference. Below are the names used inside the container.

Variable	Description	Example
PP_SCHEME	Schema name	PP
PP_MODE	Execution mode	MASTER
PP_HOST_IP	Internal IP	192.168.0.41
PP_SERVICE_IP	Service IP	192.168.0.41
PP_MASTER_IP	Master node IP	192.168.0.41
PP_DATA_DIR	Data directory	/data1/pp-data
PP_TEMP_DIR	Temporary directory	/data1/pp-temp
PP_BACKUP_DIR	Backup directory	/data1/pp-backup
PP_CLUSTER_CORES	Cluster CPU core count	16
PP_CLUSTER_MEMORY_BY_CORE	Memory per core	2G
PP_OPTIONS	Additional options (JSON)	{"use-infra":true,"use-app":true}

Monitoring Targets

The following are the primary targets and items to monitor in the PlantPulse platform. Regularly checking these items helps ensure stable operation.

Target	Monitoring Item
Application Server	CPU, Memory, Disk, Thread
JVM	Heap Memory, GC, Class Loading
PostgreSQL	Connection Pool, Query Performance, Disk
Aster TSDB	Cluster Status, Latency, Compaction
Redis	Memory, Hit Rate, Connection Count
Engine	Pipeline Throughput, Queue Depth, Error Rate
Network	OPC Connection, WebSocket, Latency

Web Console Monitoring

System Monitoring Screen

Path: /monitoring/index

Displays the real-time system status in a dashboard format. If any metric falls outside the "Normal Range" in the table below, it may cause performance degradation and should be investigated.

Metric	Description	Normal Range
CPU Usage	Server CPU load	< 70%
JVM Heap Memory	Heap usage/max	< 80%
Active Threads	Number of operating threads	< 500
MPS (Messages/sec)	Number of messages processed per second	Below set rate limit
Pipeline Queue	Number of messages waiting	< 10,000
DB Connections	Number of active DB connections	< Pool maximum

Server Status

Path: /server/status

Item	Description
Server Uptime	Uptime
Engine Status	RUNNING / STOPPED / ERROR
Last Start Time	Final engine start date and time
Version Information	Platform version

Log Monitoring

Logs are text files that record the operating status of the system. Checking logs when a problem occurs is highly beneficial for identifying the cause.

From the Host — logs.sh

Since there are eight containers, the fastest way to start when you don't know which container has the problem is without arguments.

cd /opt/kopens/plantpulse-platform-docker/bin

./logs.sh                              # 여덟 컨테이너를 시간순으로 한 화면에 (서비스 이름 접두)
./logs.sh plantpulse-server-web -n 200 # 웹 서버 컨테이너
./logs.sh cassandra                    # 데이터레이크 안 컴포넌트 로그 파일
./logs.sh --list                       # 볼 수 있는 대상 전체 (그 시점의 실제 목록)
./logs.sh -f plantpulse-server-web     # 계속 따라가기 (Ctrl-C 로 종료)

By default, it prints the last N lines (default 200) and exits. To follow the logs, append -f.

Log Files Inside the Container

# 웹 서버 — 자기 컨테이너 안에 있습니다
./shell.sh plantpulse-server-web
tail -f /opt/kopens/plantpulse-platform/plantpulse-server/logs/system.log
grep -i "ERROR\|EXCEPTION" /opt/kopens/plantpulse-platform/plantpulse-server/logs/system.log | tail -100

# 인프라 — 데이터레이크 컨테이너 안
./shell.sh
tail -f /opt/kopens/plantpulse-platform/plantpulse-storage/db/cassandra/logs/system.log

To copy logs to the host all at once, use ./tools/copy-log-to-local.sh; for support request bundles, use ./doctor.sh.

Log Levels

Level	Description
INFO	Normal operation information
WARN	Warning messages (performance degradation, retries, etc.)
ERROR	An error occurred (processing failure, connection error, etc.)

Key Log Patterns

If the following log patterns appear, please take the corresponding action:

Pattern	Meaning
Engine started successfully	Engine started normally
Pipeline queue overflow	Pipeline queue exceeded — please check processing speed
Cassandra connection failed	Failed to connect to Aster TSDB — please check cluster status
OPC connection lost	OPC server connection lost — please check network and OPC server
Rate limit exceeded	Throughput exceeded — please adjust the engine.pipeline.ratelimit value

Database Monitoring

Regularly monitoring the status of the database can prevent performance degradation or failure in advance.

PostgreSQL

# 활성 연결 확인
psql -h HOST -U plantpulse -d pp -c "
SELECT count(*) as active_connections
FROM pg_stat_activity
WHERE state = 'active';"

# 느린 쿼리 확인
psql -h HOST -U plantpulse -d pp -c "
SELECT pid, now() - pg_stat_activity.query_start AS duration, query
FROM pg_stat_activity
WHERE state != 'idle' AND now() - pg_stat_activity.query_start > interval '5 seconds'
ORDER BY duration DESC;"

# 테이블 크기 확인
psql -h HOST -U plantpulse -d pp -c "
SELECT relname, pg_size_pretty(pg_total_relation_size(relid))
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC
LIMIT 10;"

Aster TSDB

# 클러스터 상태
nodetool status

# 테이블별 통계
nodetool tablestats pp

# 컴팩션 상태
nodetool compactionstats

# GC 로그 확인
nodetool gcstats

# 지연 히스토그램
nodetool tablehistograms pp tm_tag_point

Aster TSDB Status Codes:

Status	Description
UN	Up / Normal — Normal status
DN	Down / Normal — Node is down
UJ	Up / Joining — Joining the cluster
UL	Up / Leaving — Leaving the cluster

Redis

# Redis 상태 확인
redis-cli -a 설치-시-변경 INFO

# 메모리 사용량
redis-cli -a 설치-시-변경 INFO memory

# 키 수 확인
redis-cli -a 설치-시-변경 DBSIZE

# 슬로우 로그
redis-cli -a 설치-시-변경 SLOWLOG GET 10

JMX Monitoring

Note: JMX (Java Management Extensions) is a technology that allows the internal state of Java applications to be monitored from the outside. PlantPulse provides over 150 attributes through JMX.

JMX Connection

# JMX 포트 활성화 (setenv.sh에 추가)
export JAVA_OPTS="$JAVA_OPTS \
  -Dcom.sun.management.jmxremote \
  -Dcom.sun.management.jmxremote.port=9090 \
  -Dcom.sun.management.jmxremote.ssl=false \
  -Dcom.sun.management.jmxremote.authenticate=false"

JMX MBean

• ObjectName: plantpulse:name=MBean
• Category: 12 categories including engine, cache, storage, network, pipeline, cep, scheduler, monitoring, etc.

Key JMX Attributes

Attribute	Description
engine.status	Engine status
engine.uptime	Uptime
pipeline.queue.size	Pipeline queue size
pipeline.mps	Number of messages processed per second
cache.tag.count	Number of cached tags
storage.cassandra.status	Aster TSDB connection status

Codahale Metrics

Note: Codahale Metrics is a library used to collect performance metrics of an application. PlantPulse collects over 70 metrics, which can be viewed at the /admin/tool/metrics path.

Metric Types

Type	Description
Counter	Cumulative counter (event count, error count, etc.)
Timer	Measures processing time (average, p95, p99)
Histogram	Shows the distribution of values (queue depth, batch size)
Gauge	Shows the value at the current point in time (active connections, memory)

Standard Health Check API

Web app / plugin services provide a health check endpoint GET /api/health based on the common platform specification. For major web apps (server / batch / cep / sql / data-gateway), this endpoint signifies readiness — it does not report UP simply because the process (context) is alive, but returns UP only when the internal engine / core dependencies are normal and ready to receive traffic (Platform design decision, 2026-06).

curl -fsS http://127.0.0.1:9500/api/health
# 준비 완료:           200 {"status":"UP","service":"plantpulse-batch-web","ts":1765500000000,"checks":{"timer":true,"redis":true}}
# 기동 진행 중:         503 {"status":"STARTING",...}
# 기동 후 의존성 다운:   503 {"status":"DEGRADED",...,"checks":{...}}

• readiness — Reports 200 UP only when ready. If booting is in progress, it reports 503 STARTING; if some dependencies go down after booting is complete, it reports 503 DEGRADED.
• No dependency ping — The checks only read in-memory status flags already maintained by each service (no live DB queries / network pings — polling does not load the data store).
• Anonymous access — Can be called without authentication (for operational inspection / automated deployment verification).
• Cache forbidden — Headers of the Cache-Control: no-cache series are always included.
• Response fields include status / service (artifact name) / ts (epoch ms) + the checks (detailed check per service) of the readiness-promoted service.

Service	Health URL	Meaning	checks / Notes
server	http://HOST:80/api/health	readiness	engine — Engine lifecycle status (UP only when previous stage booting is complete RUNNING)
batch	http://HOST:9500/api/health	readiness	timer (Batch pipeline operation) / redis (InMemory connection)
cep	http://HOST:7400/api/health	readiness	engine (CEP engine+consumer+recovery complete) / redis (InMemory connection)
sql	https://HOST:4001/api/health	readiness	database_manager (DB manager initialization complete) — Provided via HTTPS
data-gateway	http://HOST:5500/api/health	readiness	database / inmemory / query_log — This path is excluded from HTTPS enforcement (CONFIDENTIAL), allowing localhost HTTP probes
warehouse (s3 service)	http://HOST:9600/api/health	readiness	temporal — Temporal worker registration status. If not registered, reports STARTING + 503 (Normal for 503 immediately after boot as web server starts first and worker follows). Includes 3 common fields + system/JVM metrics
plugin — AAS V3	http://HOST:8090/api/health	liveness	Not promoted to readiness
plugin — OPC-UA Browse UI	http://HOST:12780/api/health	liveness	Port is set via opc.ua.browser.ui.port (Default 12780)

There are two purposes.

1. Operational Inspection — Manual verification, readiness probes for crontab / external monitoring.
2. CI Deployment Auto-verification — The deploy:dev job polls this URL (DEPLOY_HEALTH, 240 seconds) after deployment to verify booting (refer to setup and deployment guide). Since it means readiness, 503 during boot is normal, and polling waits for the transition to UP.

Role Distinction: plantpulse-datalake-admin-api (:4950) is an infrastructure monitoring agent that collects and exposes host / JVM / module metrics, while /api/health is a readiness endpoint provided by each web app itself. They are complementary, not redundant.

In a container environment, since the compose healthcheck already determines the readiness of each app, operators can receive the determination of all eight containers in one line via bin/status.sh.

Health Check Script

By utilizing health check scripts, you can automatically verify if the platform's primary services are operating normally.

Automated Health Check

Below is an example script that automatically checks the status of major services:

#!/bin/bash
# healthcheck.sh

# 표준 헬스체크 (GET /api/health)
BODY=$(curl -fsS -m 5 http://localhost/api/health 2>/dev/null)
case "$BODY" in
  *'"status":"UP"'*) : ;;  # 정상
  *) echo "[ALERT] PlantPulse server is not responding: ${BODY:-no response}"
     # 알림 발송 로직 추가
     ;;
esac

# PostgreSQL 체크
pg_isready -h HOST -p 5432 -U plantpulse
if [ $? -ne 0 ]; then
    echo "[ALERT] PostgreSQL is not responding"
fi

# Cassandra 체크
nodetool status | grep -q "^UN"
if [ $? -ne 0 ]; then
    echo "[ALERT] Cassandra node is down"
fi

# Redis 체크
redis-cli -a 설치-시-변경 ping | grep -q "PONG"
if [ $? -ne 0 ]; then
    echo "[ALERT] Redis is not responding"
fi

You can register this in crontab to execute it periodically:

# 5분마다 헬스체크
*/5 * * * * /opt/scripts/healthcheck.sh >> /var/log/plantpulse-healthcheck.log 2>&1

PlantPulse Dashboard Monitoring Dashboard

Platform monitoring is visually provided through the PlantPulse Dashboard. Access URL: http://localhost:3000/

Note: PlantPulse Dashboard is a data visualization tool bundled with the platform, displaying various PlantPulse metrics through graphs and charts. Five default dashboards are provided under the PLANTPULSE folder.

---

1. PlantPulse - Server

The core dashboard for grasping the overall status of the platform server at a glance.

SUMMARY

Panel	Type	Description
VERSION	Stat	Platform version information
Server Start Date	Stat	Initial engine start date and time
CPU Load	Gauge	Server CPU usage
Memory Usage	Gauge	Server memory usage
Messages per Second	Stat	Message reception rate (MPS)
Total Storage Count	Stat	Cumulative stored data count
Network Latency	Stat	Message reception network latency (ms)
Diagnostics	Stat	Diagnostic event status

SERVER-METRICS

Panel	Type	Description
CACHE / MQTT / KAFKA / WEBSOCKET / DATABASE / TSE	Stat	Connection status of each service
Server CPU Usage	Graph	Time series trend of CPU usage
Server Memory Usage	Graph	Time series trend of memory usage
JAVA Heap Usage	Graph	JVM heap memory usage
Data DISK R/W Status	Graph	Disk read/write traffic
Messages Received by Protocol	Graph	Reception volume by protocol (OPC, MQTT, Kafka, etc.)
Message Reception Network Latency	Graph	Network latency time series
Total Message Reception	Graph	Cumulative message reception volume
Messages Received BY 1SEC	Graph	Message reception trend per second
Pipeline Waiting Queue	Graph	Pipeline queue depth
Pipeline Offload Queue Size	Graph	RocksDB offload queue
Pipeline Validation Failures	Graph	Number of validity verification failures
Pipeline Worker Processing Time	Graph	Worker processing time
Timeout Message Backup Processing	Graph	Number of timeout message backups
Pipeline Collector	Graph	Collector operation status
Storage Save Buffer	Graph	Save buffer size
Streaming Processing Count	Graph	WebSocket streaming throughput
Streaming Operating Thread Count	Graph	Streaming active threads
Streaming Waiting Queue Count	Graph	Streaming queue waiting count
Storage Save Count	Graph	DB save count
Storage Batch Count	Graph	Batch save count
Storage Worker Count	Graph	Number of save workers
DDS Processing Count	Graph	Kafka DDS distribution count
Async Thread Active Count	Graph	Active async execution threads
Async Thread Pool Size	Graph	Thread pool size
Diagnostics Error Count	Graph	Trend of diagnostic errors
Logging Exception	Graph	Exception log occurrence trend
GC Time	Graph	JVM GC duration
DISK Usage	Graph	Disk usage trend

---

2. PlantPulse - Data Lakehouse

Dashboard for monitoring the performance and status of the database and storage layers.

DATA-GATEWAY

Panel	Description
TOTAL_QUERY	Total number of queries
QPS	Query throughput per second (Gauge)
QUERY_LATENCY	Query latency time series
QUERY_LATENCY_MAX	Maximum query latency
SUCCESS / ERROR	Success and failure counts

CACHE (REDIS)

Panel	Description
CLIENTS	Number of Redis client connections
ALLOCATOR	Memory allocator status
KEY_COUNT	Number of stored keys
FRAGMENTATION	Memory fragmentation ratio

CEP

Panel	Description
JAVA_HEAP_USED	CEP engine heap memory
EVENT_INGESTION_RATE	Event ingestion rate
EQL_CPU_TIME	No value provided — CEP does not measure CPU time per statement
EQL_MAP_COUNT	Number of deployed EQL statements
EVENT_INGEST_DIFF	Event ingestion difference
EVENT_DELAY_HISTOGRAM	Event delay distribution
CEP_STATEMENT_MATCH_RATE	Statement matching ratio
EQL_STATEMENT_OUTPUT_RATE	Statement output ratio

META-STORE (POSTGRES)

Panel	Description
TOTAL_CONNECTIONS	Total number of connections
QUERY_LATENCY	Query latency
TOTAL_READS_HITS	Number of read hits
TOTAL_DB_SIZE	Total DB size

EVENT-STORE (CASSANDRA)

Panel	Description
NATIVE_CLIENT	Native client connections
LATENCY	Read/write latency
READ_PER_SECONDS / WRITE_PER_SECONDS	Reads/writes per second
HEAP / DIRECT_MAPPED_MEMORY	JVM memory
CACHE / CACHE_HIT_RATE	Cache and hit rate
TOTAL_DATA_SIZE	Total data size
MEMTABLE	Memtable status
COMPACTION / COMPACTION_BYTES	Compaction status
TABLE_COMPACTIONS / TABLE_SSTABLE_COUNT	Compaction and SSTable by table
BLOOM_FILTER_FALSE_RATIO	Bloom filter false positive rate
TABLE_READ_LATENCY / TABLE_RANGE_LATENCY / TABLE_WRITE_LATENCY	Latency by table
PENDINGS / FLUSH / THREAD_POOL	Pending, flush, thread pool
STATEMENT / COMMITLOG / EXCEPTION / MUTATION	Internal metrics
COMPRESSION / TOTAL_SSTABLE	Compression and SSTable status

TIMESERIES-STORE (TSE)

Panel	Description
TSE_MEMORY	Time series engine memory
TSE_HTTP_TIME	HTTP response time
TSE_DATASTORE	Datastore status
TSE_QUEUE_PROCESS_COUNT	Queue processing count

ANALYTICS-STORE (SPARK)

Panel	Description
MEMORY_USED	Spark memory usage
CONNECTION	Connection count
OPERATION	Number of operations
REQUEST_RATE	Request rate

---

3. PlantPulse - Edge Gateway

Dashboard for monitoring edge device status, PLC connections, and data reception.

Summary Panel

Panel	Description
Total Edge Gateways	Number of registered edge gateways
Power (Normal/Anomaly)	Count of normal and anomaly power statuses
PLC	Number of PLC connections
Total Data Volume	Total size of collected data
Total Reception Sum per Second	Total reception sum of all edges per second (Gauge)
Max Data Reception Latency	Maximum reception latency (ms) (Gauge)
Log	Log status

PLC STATUS

Panel	Description
PLC Ping Failure Count	Trend of PLC connection ping failures
PLC Connected / Disconnected	Trend of PLC connection status
PLC Value Read Success Count	Trend of data read successes
PLC Data Read Failure Count	Trend of data read failures
System Error Count Trend	Trend of system errors

DATA POINT

Panel	Description
Total Transmission SUM(MPS) per Second	Total transmission sum of all edges per second
Point Transmission Count	Trend of point transmission counts
Transmitted Point Bytes	Transmitted data bytes
Min/Avg/Max Reception Latency	Reception latency distribution

EDGE H/W

Panel	Description
CPU	Edge device CPU usage
Memory	Memory usage
Disk (SSD)	Disk usage
Network Upload/Download	Network traffic
Temperature	Device temperature

---

4. PlantPulse - Statistics

Dashboard for tracking long-term statistics such as daily data growth and system resource peaks. Useful for identifying long-term growth trends.

Panel	Description
Total Data Volume	Total stored data size
Daily Total Data Volume	Daily data volume trend
Daily Message Transmission	Daily message transmission count
Daily Data Increase	Daily data growth trend
Message Reception Count	Message reception count trend
Average/Max Network Latency	Network latency statistics
SSTABLE Increase	Aster TSDB SSTable growth trend
Max DB Client Connections	Maximum DB connections
Max Async Thread Executions	Async processing peak
Max JAVA GC Time	Maximum GC duration
Max CQL Prepared Statements	Maximum CQL Prepared Statement count
Max Partition Size	Aster TSDB maximum partition size
Min JAVA Heap Free Space	Minimum JVM heap free space
Max Async Thread Waiting Count	Maximum async queue wait
Max Memory Buffer Size	Maximum memory buffer
Backup Message Processing Count	Backup processing count

---

5. PlantPulse - Messaging

Dashboard for monitoring the status of MQTT, Kafka, and WebSocket message brokers.

SUMMARY

Panel	Description
MQTT / KAFKA / WEBSOCKET	Connection status of each broker
CPU	Server CPU usage
JAVA_HEAP	JVM heap usage
NETWORK_READ_BYTES	Network reception bytes

MQTT

Panel	Description
CPU_USED	MQTT broker CPU (Gauge)
MEMORY_USED	Memory usage
CONNECTIONS	Client connection count
NETWORK IN/OUT	Network input/output
GC_COUNT / GC_TIME_MS	GC count and duration
THREAD_COUNT	Thread count
INCOMING / OUTGOING	Received and sent message counts
RETAINED_COUNT	Number of Retained messages
SUBSCRIPTIONS	Number of subscriptions
TOTAL_MESSAGE	Total message count

KAFKA

Panel	Description
CPU_USED	Kafka broker CPU (Gauge)
MEMORY_USED	Memory usage
GLOBAL_TOPIC	Global topic status
NETWORK IN/OUT	Network input/output
TOPIC_BYTE_IN/OUT_PER_SEC	Bytes per second by topic
MESSAGE_PER_SEC_MEAN_RATE / 1M_RATE	Message throughput per second
NETWORK_REQUEST_FETCH	Number of Fetch requests
OFFLINE_PARTITION_COUNT	Number of offline partitions
ACTIVE_CONTROLLER_COUNT	Number of active controllers

WEBSOCKET

Panel	Description
CPU_USED	WebSocket server CPU (Gauge)
MEMORY_USED	Memory usage
CONNECTION_COUNT	WebSocket connection count
ENQUEUE / DEQUEUE	Queue input/output counts

---

Monitoring Tool Integration

ELK Stack

You can build a log search and analysis environment by collecting container logs through a Filebeat → Logstash → Elasticsearch → Kibana pipeline. Consider adopting this if you wish to efficiently manage logs in a large-scale operational environment. Container standard output is collected via the docker logging driver, and file logs inside containers are collected via host mount (PLANTPULSE_LOG_DIR).