Diagnose / Inspektion
Sammlung von Diagnoseskripten für den Verdacht auf Störungen bzw. Fehlverhalten.
Das folgende Vorgehen gilt für native Boxen (bin/ps.sh, bin/log-viewer.sh). Container-Modus:
bash /opt/kopens/install/bin/status.sh # 한 줄 상태
bash /opt/kopens/install/bin/health.sh # 종합 헬스 (exit 0/1)
bash /opt/kopens/install/bin/logs.sh -f tomcat # 로그 follow
sudo bash /opt/kopens/install/bin/doctor.sh # 진단 일괄 tarball (support escalation)
Details: Betriebsleitfaden Container-Modus + /opt/kopens/install/RUNBOOK.md.
1. Schrittweises Diagnosevorgehen
# 1. 누가 죽었나?
$PE_HOME/bin/ps.sh
# 2. 어디가 시끄러운가?
$PE_HOME/bin/log-viewer.sh
# (실시간 — Ctrl+C 로 빠져나옴)
# 3. Cassandra 의심
$PE_HOME/bin/node-info.sh
# 4. Disk 의심
df -h /data1
du -sh $PE_HOME/*/log/* /data1/* 2>/dev/null | sort -h | tail -20
# 5. 다 안 맞으면 — 안전하게 단계적 재시작
$PE_HOME/bin/restart.sh # 1차: Tomcat 만
# 그래도 이상 시
$PE_HOME/bin/stop.sh
$PE_HOME/bin/start.sh # 2차: 전체
# 그래도 이상 시
sudo $PE_HOME/bin/reboot.sh # 3차: OS 재부팅 (최후의 수단)
2. Achtung — log-viewer.sh nicht in nicht-interaktiven Shells aufrufen
log-viewer.sh ist eine endlose tail -f. Wird es in nicht-interaktiven Umgebungen wie CI / cron aufgerufen, endet die SSH-Sitzung nie. Nur in einer interaktiven Shell verwenden.
3. log-viewer.sh — gesammeltes Log-Tail
$PE_HOME/bin/log-viewer.sh
7 Logs in Echtzeit auf einem Bildschirm:
- Tomcat (
server/logs/catalina.out) - timeseries-engine
- Cassandra (
db/logs/system.log) - HiveMQ (
mqtt/log/hivemq.log) - Node-RED (
node/log/node-red.log) - Redis cache
- Sonstige
Beenden mit Ctrl+C. Das Werkzeug, das im Störungsfall als Erstes ausgeführt wird.
4. ps.sh
$PE_HOME/bin/ps.sh
Liste der laufenden Java-Prozesse anhand des Schlüsselworts plantpulse. Im Normalzustand müssen alle folgenden sichtbar sein:
| Prozess | Bedeutung | PID-Umgebungsvariable |
|---|---|---|
apache.cassandra.service.CassandraDaemon | Cassandra | cassandra.pid |
hivemq.jar | MQTT | (keine) |
plantpulse.timeseries.engine.Main | Zeitreihen-Engine | (keine) |
org.apache.catalina.startup.Bootstrap | Tomcat | CATALINA_PID |
node-red (Node.js) | Node-RED | (keine) |
Fehlt einer, ist die betreffende Komponente abgestürzt — mit start.sh oder dem bin/start.sh der jeweiligen Sub-Komponente wieder starten.
5. node-info.sh — Cassandra-Status
$PE_HOME/bin/node-info.sh
Typische Ausgabe (nodetool info):
ID : 8a4d...
Gossip active : true
Native Transport active: true
Load : 1.21 GiB
Generation No : 1778176430
Uptime (seconds) : 1234
Heap Memory (MB) : 824.10 / 2048.00
| Prüfpunkt | Bedeutung |
|---|---|
Native Transport active : true | Client-Port 9042 im Listen-Zustand |
Heap > 80% | OOM steht bevor — Daten bereinigen / Heap vergrößern |
Load überschreitet 80 % der Festplatte | sstable bereinigen (node-cleanup.sh) oder Speicher erweitern |
6. node-cql.sh — cqlsh interaktiv
$PE_HOME/bin/node-cql.sh
cqlsh -u cassandra -p ... wird automatisch ausgeführt und verbindet sich mit dem Keyspace pe. Gedacht für die manuelle Datenprüfung — direkte INSERT/UPDATE im laufenden Betrieb werden nicht empfohlen (Cache nicht aktualisiert, Replikation inkonsistent usw.).
Häufig verwendete Abfragebeispiele:
USE pe;
SELECT count(*) FROM app_tag;
SELECT opc_id, opc_type FROM app_opc;
DESCRIBE TABLE app_tag;
7. network-speed-test.sh
$PE_HOME/bin/network-speed-test.sh
Lädt speedtest.py von product.kopens.io herunter und führt es aus, um die Geschwindigkeit des externen Netzes zu messen. Bei langsamer Leitung dauert auch das Upgrade länger — Diagnose vor dem Upgrade.
8. Häufige Fallstricke — Übersicht
| Symptom | Ursache / Abhilfe |
|---|---|
Nach restart.sh sind OPC-Verbindungen 0/N | Selten auftretende Race-Bedingung beim Start. restart.sh erneut aufrufen |
Nach clean.sh bricht die SSH-Sitzung plötzlich ab | /tmp/* entfernt auch das SSH-Socket — über eine andere Sitzung neu verbinden |
Download während upgrade.sh schlägt fehl | Externes Netz / product.kopens.io prüfen. network-speed-test.sh |
start.sh hängt sehr lange ([4] DB START) | Cassandra-Commitlog-Rückgewinnung — üblicherweise 30 s+ Wartezeit. Endet es trotzdem nicht, db/logs/system.log prüfen |
| Nur Tomcat stürzt wiederholt ab | Möglicherweise OOM — OutOfMemoryError / Heapdump-Verzeichnis in server/logs/catalina.out prüfen |
| Node-RED verschwindet nach dem Deploy | userDir beschädigt. Die Wiederherstellung erfolgt konstruktionsbedingt aus der Master-Kopie in $PE_HOME/node/conf — node/bin/start.sh synchronisiert automatisch |
| Gateway von außen nicht erreichbar | Firewall (firewall-cmd --list-all oder iptables -L) / SELinux-Richtlinie / Router-NAT prüfen |
9. Weiterführende Informationen
- Bei Speicherplatzmangel: Aufräumen / Bereinigen
- Szenarien zur schrittweisen Störungsdiagnose: Betriebsszenarien
- Monitoring (REST-Metriken): Monitoring (Betreiber/REST)