Was ist PM2? Node.js Anwendungen im Betrieb verwalten

Was ist PM2?

PM2 ist ein Prozessmanager für Node.js Anwendungen. Er startet Ihre App im Hintergrund, startet sie nach einem Absturz neu, sammelt die Logs, verteilt die Last auf mehrere CPU Kerne und fährt sie nach einem Serverneustart wieder hoch. Alles steuern Sie über ein einziges Kommandozeilenwerkzeug.

Eine Node.js Anwendung ist normalerweise ein einzelner Prozess. Wenn dieser Prozess einen Fehler meldet und sich beendet, ist Ihre Website offline. Deshalb überwacht PM2 den Prozess dauerhaft und startet ihn neu. Daher bleibt eine App, die um Mitternacht abstürzt, nicht bis zum Morgen down.

Wer nach was ist PM2 sucht, fragt meist zweierlei: Ist die Einrichtung schwer, und brauche ich das wirklich? Die Einrichtung dauert nämlich nur einen Befehl. Ob Sie es brauchen, hängt allerdings von der Bedeutung der App ab. Ein Testprojekt kann im Terminal laufen, aber eine Website mit echtem Kundenverkehr braucht einen Prozessmanager.

Wir sind ein Team für digitales Marketing und Webentwicklung, kein Hostinganbieter. Zudem folgt dieser Leitfaden der Dokumentation von PM2, Node.js und systemd. Probieren Sie jeden Befehl zunächst auf einer Testkopie aus und gehen Sie erst dann live.

Die Installation von Node.js und die Übertragung der App auf den Server behandeln wir hier nicht. Stattdessen beginnt dieser Beitrag, wenn die App schon auf dem Server läuft, und konzentriert sich auf den Betrieb. Wenn Sie wissen möchten, was Code auf der Serverseite ist, lesen Sie unseren Beitrag zum Thema Backend.

Was ist PM2, und warum reicht der Befehl node nicht aus?

Wenn Sie im Terminal node app.js eingeben, bleibt die App an diese Sitzung gebunden. Bricht Ihre SSH Verbindung ab oder schließen Sie das Fenster, endet der Prozess meist. Wirft die App einen Fehler und beendet sich, startet sie niemand neu.

Auf einer Live Website ist beides daher nicht akzeptabel. Außerdem soll die App nach einem Neustart des Servers von allein starten. PM2 schließt genau diese Lücken:

• Erstens führt er die App unabhängig von Ihrer Sitzung im Hintergrund aus.
• Zweitens startet er einen abgestürzten Prozess automatisch neu.
• Drittens bringt er die App beim Hochfahren des Servers zurück.
• Schließlich sammelt er Logs an einer Stelle und lässt Sie diese live verfolgen.

Anders gesagt: PM2 ändert Ihren Code nicht. Stattdessen legt er eine Betriebsebene um den Code. Wenn das Entwicklerteam und die Person am Server verschieden sind, dient diese Ebene als gemeinsame Sprache.

Wie starten Sie eine App mit PM2?

Laut der offiziellen PM2 Dokumentation installieren Sie PM2 global mit npm. Danach übergeben Sie die Einstiegsdatei Ihrer App und starten sie. Die folgenden Befehle sind Beispiele, daher ersetzen Sie Datei und App Namen durch Ihre eigenen.

npm install pm2@latest -g
pm2 start app.js --name example-app
pm2 list
pm2 logs example-app

Der erste Befehl installiert PM2. Anschließend startet der zweite die App und schickt sie in den Hintergrund. Der dritte listet alle Apps auf, die PM2 verwaltet. Der vierte zeigt die Logs dieser App live.

Beim Start können Sie weitere Optionen angeben. Zum Beispiel beschreibt die Dokumentation --watch, das bei Dateiänderungen neu startet, und --max-memory-restart, das den Prozess bei einer Speichergrenze erneuert. Beide betrachten wir daher weiter unten.

Außerdem kann eine globale Installation zusätzliche Rechte verlangen. Haben Sie diese nicht, oder nutzen Sie Shared Hosting, dann erzwingen Sie die Installation nicht. Fragen Sie stattdessen Ihren Anbieter, wie er Node.js Apps betreibt.

Was ist der Unterschied zwischen start, restart, reload, stop und delete?

Diese fünf Befehle sehen auf den ersten Blick ähnlich aus, verhalten sich aber verschieden. Vor allem der Unterschied zwischen restart und reload zählt auf einer Live Website. Zum Beispiel hilft ein kurzer Vergleich nach den offiziellen Beschreibungen.

Die praktische Folgerung ist einfach. Möchten Sie eine App nur anhalten, dann nutzen Sie stop. Greifen Sie zu delete nur dann, wenn sie aus der Liste verschwinden soll, sonst entfernen Sie die App versehentlich.

Was ist eine Ecosystem Datei, und wie schreiben Sie eine?

Lange Kommandozeilenoptionen jedes Mal zu merken, ist nämlich mühsam. Deshalb erlaubt PM2, Ihre Einstellungen in einer Konfigurationsdatei zu sammeln. Die Dokumentation nennt sie ecosystem.config.js, und der Befehl pm2 ecosystem erzeugt eine Vorlage.

Die Datei exportiert ein Objekt mit einem Array namens apps. In der Praxis schreiben Sie pro App ein Objekt. Das kurze Beispiel unten nutzt die Feldnamen aus der Dokumentation.

module.exports = {
  apps: [{
    name: "example-app",
    script: "./app.js",
    cwd: "/srv/example-app",
    instances: 1,
    exec_mode: "fork",
    max_memory_restart: "300M",
    env: { NODE_ENV: "development" },
    env_production: { NODE_ENV: "production" }
  }]
}

Sie starten die Datei mit pm2 start ecosystem.config.js. Außerdem lohnt es sich, die Datei zusammen mit dem Projekt in der Versionsverwaltung zu halten. So kann Ihr Team jede Änderung nachvollziehen.

Außerdem kann das Array apps mehrere Objekte enthalten. Zum Beispiel definieren Sie das Web Frontend und einen Hintergrundjob als getrennte Apps in einer Datei. Dann starten Sie beide mit einem Befehl und erneuern bei Bedarf nur eine davon.

Die Dokumentation erwähnt außerdem einen Abschnitt für das Deployment in der Ecosystem Datei. Konkret stehen dort SSH Angaben, Git Verweise und Befehle vor oder nach einem Release. Die Auslieferung von Code ist ein eigenes Thema, daher lassen wir sie hier aus.

Welche Einstellungen der Ecosystem Datei sind am wichtigsten?

Die Dokumentation listet allerdings viele Felder. Unten sehen Sie die, die Sie im Alltag am häufigsten anfassen. Betrachten Sie die Werte als Beispiele und wählen Sie sie passend zu Ihrer App.

• name: Der App Name in PM2, den Sie in Befehlen verwenden.
• script: Der Pfad zur Einstiegsdatei der App.
• cwd: Das Arbeitsverzeichnis, in dem die App startet.
• instances und exec_mode: Die Zahl der Prozesse sowie fork oder cluster.
• autorestart: Startet die App nach einem Absturz neu. Laut Dokumentation ist der Standard true.
• watch: Lädt die App bei Dateiänderungen neu.
• max_memory_restart: Erneuert den Prozess über einer Speichergrenze, zum Beispiel "150M".
• error_file, out_file und log_date_format: Ort der Logdateien und Zeitformat.

Deshalb empfehlen wir nicht, watch im Live Betrieb einzuschalten. Denn Dateien wie Uploads oder Logs ändern sich ständig, daher startet die App grundlos neu. Auf dem Entwicklungsrechner ist es dennoch praktisch.

Wie verwalten Sie Umgebungsvariablen und Produktionseinstellungen?

Laut Dokumentation enthält das Feld env die Standardvariablen. Die Felder env_production und env_development enthalten Werte für eine bestimmte Umgebung. Auf dem Live Server starten Sie die App so:

pm2 start ecosystem.config.js --env production

Dieselbe Datei dient also für Test und Live. Es gelten also nur die Werte der gewählten Umgebung. Zudem sparen Sie sich das Kopieren von Code zwischen Umgebungen.

Was ist PM2 aus Sicht der Umgebungen? Er ist ein Werkzeug, das eine App mit verschiedenen Einstellungen aus einer einzigen Datei betreibt. Prüfen Sie dennoch einmal, welche Variable der Code in welcher Umgebung liest, bevor Sie live gehen.

Schreiben Sie jedoch keine Passwörter, API Schlüssel oder Datenbankzugänge in die Ecosystem Datei und laden Sie diese nicht in ein Repository. Weil diese Datei meist in die Versionsverwaltung wandert, sehen alle mit Zugriff ihren Inhalt. Stattdessen halten Sie Geheimnisse in einer geschützten Quelle auf dem Server.

Wenn Ihnen der Umgang mit Geheimnissen zu heikel ist, planen Sie ihn gemeinsam mit der Person, die den Server betreibt. Ein schlecht verwalteter Schlüssel kann nämlich allein schon eine ernste Lücke sein. Unser Beitrag zu den OWASP Top 10 fasst die häufigen Fehler zusammen.

Was ist der Cluster Modus, und wann setzen Sie ihn ein?

Standardmäßig läuft eine Node.js App auf einem einzigen Kern. Hat Ihr Server vier Kerne, bleiben also womöglich drei ungenutzt. Der Cluster Modus von PM2 nutzt das eingebaute Node.js Modul cluster und verteilt Ihre App auf mehrere Kerne. Ihren Code müssen Sie dafür nicht ändern.

pm2 start app.js -i max

Laut Dokumentation nutzt der Wert 0 oder max für instances alle CPUs. Der Wert -1 bedeutet alle CPUs minus eins. Zuletzt startet eine feste Zahl genau so viele Prozesse.

Die Node.js Dokumentation sagt, dass das Modul cluster Verbindungen auf allen Plattformen außer Windows reihum auf die Worker verteilt. Zudem teilen sich alle Worker denselben Port. Sie brauchen dafür also weder einen zweiten Port noch einen zusätzlichen Load Balancer.

Auf einer kleinen Website reicht daher oft ein Prozess. Denken Sie an den Cluster Modus erst, wenn Sie hohe Last oder viel CPU Verbrauch sehen. Messen Sie zuerst, vervielfachen Sie dann.

Die Zahl der Prozesse ändern Sie im laufenden Betrieb mit dem Befehl pm2 scale aus der Dokumentation. Zum Beispiel setzt pm2 scale example-app 2 die Zahl der Worker dieser App auf zwei. Das ist eine der stärksten Antworten auf die Frage was ist PM2: Sie ändern die Kapazität, ohne Code zu schreiben.

Warum muss Ihre App im Cluster Modus zustandslos sein?

Die PM2 Dokumentation nennt eine klare Bedingung für den Cluster Modus: Die App muss zustandslos sein. Das heißt, Sitzungen, WebSocket Verbindungen und lokale Daten dürfen nicht im Prozessspeicher liegen. Der Grund ist einfach, denn zwei Anfragen hintereinander können bei verschiedenen Prozessen landen.

Zum Beispiel hält der erste Prozess eine Nutzersitzung im Speicher, und die zweite Anfrage trifft einen anderen Prozess. Der Nutzer wirkt dann abgemeldet. In einem Onlineshop bedeutet das einen leeren Warenkorb, und verlorene Conversions folgen direkt daraus.

Die Lösung ist also, gemeinsamen Zustand aus den Prozessen auszulagern. Die Dokumentation nennt dafür externe Speicher wie Redis oder MongoDB. Redis und Memcached erklären wir in unserem Beitrag zum Caching, daher wiederholen wir das hier nicht.

Ist Ihre App nicht zustandslos, sprechen Sie vor dem Cluster Modus mit Ihren Entwicklern. Kurz gesagt ist das eher eine Architekturentscheidung als eine PM2 Einstellung.

Wie klappt ein Update ohne Ausfall mit reload?

Laut PM2 Dokumentation startet reload die Prozesse im Cluster Modus nacheinander neu. Während also ein Prozess neu startet, bedienen die anderen weiter Anfragen. Der Befehl restart dagegen beendet den Prozess sofort und erzeugt ihn neu, was eine kurze Lücke verursachen kann.

pm2 reload example-app

Die Dokumentation beschreibt reload im Cluster Kontext. Im fork Modus gibt es nur einen Prozess, daher nehmen Sie keinen Betrieb ohne Ausfall an, ohne ihn in Ihrer Umgebung zu testen. Wir empfehlen dafür deshalb eine Testumgebung.

Zudem zählt auch das Aufräumen beim Beenden. Die Dokumentation rät, das Signal SIGINT abzufangen und zum Beispiel Datenbankverbindungen zu schließen. Somit bleiben weniger halbfertige Vorgänge zurück.

Dennoch löst reload weder eine Änderung des Datenbankschemas noch eine unverträgliche Codeversion von allein. Zwei Versionen laufen eine Weile nebeneinander, deshalb müssen Ihre Änderungen abwärtskompatibel bleiben.

Wo speichert PM2 Logs, und wie lesen Sie sie?

Laut Dokumentation schreibt PM2 Logs standardmäßig in den Ordner $HOME/.pm2/logs. Dann zeigt der Befehl pm2 logs alle live an. Außerdem können Sie einen App Namen angeben, um nur eine App zu verfolgen.

pm2 logs
pm2 logs example-app
pm2 logs --lines 200

Beim Start legt -o die Ausgabedatei fest und -e die Fehlerdatei. Die Option --time fügt jeder Zeile einen Zeitstempel hinzu. Im Cluster Modus führt --merge-logs die Logs aller Prozesse in einer Datei zusammen.

Beim Debuggen schauen Sie also zuerst in die Fehlerdatei. Die letzten Zeilen vor einem Absturz zeigen oft die Ursache. Außerdem können Sie unser Tool zur Logfile Analyse nutzen, wenn Sie Zugriffslogs prüfen möchten.

Brauchen Sie maschinenlesbare Ausgabe, hilft die Option --json von pm2 logs aus der Dokumentation. Dann übergeben Sie Logzeilen leichter an ein Analysewerkzeug oder ein Skript. Prüfen Sie jedoch den Inhalt, bevor Sie rohe Logs an einen Drittdienst schicken.

Schreiben Sie nie Passwörter oder personenbezogene Daten in Logs. Solche Daten bleiben oft jahrelang unbemerkt in Dateien. Außerdem entsteht dadurch ein unnötiges Risiko nach der DSGVO.

Wie verhindern Sie, dass Logdateien die Festplatte füllen?

Logs wachsen ständig. Ohne Rotation füllen die Dateien eines Tages die Festplatte, und die App stürzt ab. Dieses stille Risiko übersieht man leicht.

Die Dokumentation beschreibt zwei Wege. Der erste ist das Community Modul pm2-logrotate:

pm2 install pm2-logrotate

Der zweite Weg nutzt das Rotationswerkzeug des Systems. Laut Dokumentation erzeugt der Befehl sudo pm2 logrotate mit der Option -u und Ihrem Benutzernamen eine Konfiguration unter /etc/logrotate.d/pm2-benutzername, mit wöchentlicher Rotation und Kompression. Dabei ersetzen Sie den Platzhalter durch Ihren eigenen Benutzernamen.

Der Befehl pm2 flush leert alle Logdateien. Deshalb setzen Sie ihn mit Bedacht ein, wenn Sie die Historie behalten möchten. Die Dokumentation sagt außerdem, dass Sie das Logging auf die Festplatte abschalten, indem Sie out_file und error_file auf /dev/null setzen. Wir raten davon ab, denn es erschwert die Fehlersuche.

Wie startet pm2 startup die App nach einem Neustart wieder?

Ein Server kann für Wartung oder ohne Vorwarnung neu starten. Dann endet auch PM2. Der Befehl pm2 startup erkennt Ihr Init System und erzeugt ein Skript, das PM2 beim Hochfahren startet.

Laut Dokumentation gibt der Befehl eine sudo Zeile aus. Diese Zeile kopieren Sie und führen sie genau so aus. Danach speichern Sie die aktuelle App Liste mit pm2 save.

pm2 startup
pm2 save

Laut Dokumentation stellt pm2 resurrect die gespeicherte Liste von Hand wieder her, und pm2 unstartup entfernt die ganze Einrichtung. Die automatische Wiederherstellung beim Hochfahren stützt sich also auf diese gespeicherte Liste.

Ein wichtiges Detail: Führen Sie pm2 save erneut aus, sobald Sie eine App hinzufügen oder löschen. Sonst kommt nach einem Neustart die alte Liste zurück. Das zu vergessen, gehört zu den häufigsten Überraschungen.

Die Dokumentation sagt, dass PM2 das Init System selbst erkennt. Unterstützt werden unter anderem systemd, upstart, launchd, openrc, rcd und systemv. Die meisten aktuellen Linux Distributionen nutzen systemd, daher sehen Sie meist ein systemd Skript. Kurz gesagt erledigt PM2 den Systemstart nicht selbst, sondern hinterlegt einen Eintrag im Mechanismus des Betriebssystems.

Warum erneuern Sie startup nach einem Node.js Update?

Das Startup Skript nutzt den Node.js Pfad vom Zeitpunkt der Einrichtung. Die Warnung der Dokumentation ist klar: Führen Sie nach einem Node.js Update zuerst pm2 unstartup aus und danach erneut pm2 startup. So nutzt PM2 die aktuelle Programmdatei.

Überspringen Sie diesen Schritt, wirkt zunächst alles normal. Allerdings sucht PM2 nach einem Neustart womöglich den alten Pfad, und die App startet nicht. Der Ausfall tritt genau dann auf, wenn Sie am wenigsten damit rechnen.

Mit den Optionen -u und --hp können Sie laut Dokumentation auch unter einem anderen Benutzer laufen. Unser Rat lautet, die App nicht als root auszuführen. Nutzen Sie stattdessen einen eingeschränkten Benutzer, der nur für diese App existiert.

Ein Node.js Update kann außerdem Ihre Abhängigkeiten betreffen. Testen Sie das Update daher zuerst auf einer Testkopie. Die aktuelle stabile Version prüfen Sie auf der Node.js Website.

Wie überwachen Sie eine App mit PM2?

PM2 bringt einige eingebaute Werkzeuge zur Überwachung mit. Der Befehl pm2 list fasst den Zustand zusammen. Der Befehl pm2 monit öffnet ein Live Dashboard im Terminal. Mit pm2 describe lesen Sie die Details eines Prozesses.

• pm2 list: Zeigt den Status aller Apps.
• pm2 monit: Bietet ein Live Dashboard im Terminal.
• pm2 describe 0: Zeigt die Details von Prozess Nummer null.
• pm2 plus: Laut Dokumentation eine getrennte Weboberfläche, die mehrere Server überwacht.

Die Einstellung max_memory_restart ist ein Sicherheitsnetz. Sie erneuert eine App mit Speicherleck, sobald sie die Grenze überschreitet. Das Leck behebt sie allerdings nicht, sie verdeckt nur das Symptom. Die eigentliche Korrektur müssen Ihre Entwickler leisten.

Jemand muss die Überwachung verantworten. Notieren Sie, wer auf eine Warnung schaut und wen Sie um Hilfe bitten. Denn zu wissen, was ist PM2, genügt nicht; Sie müssen auch wissen, wen die App informiert, wenn sie nachts um drei abstürzt. Schon eine einfache Kontaktliste macht einen großen Unterschied.

Auch der Blick von außen zählt. Ein Prozess kann laufen, während die Website nicht antwortet. Mit unserem Tool zur Frage ist die Seite down prüfen Sie, ob Ihre Seite von außen erreichbar ist.

Was ist PM2, und ist er dasselbe wie systemd?

Teilweise. Beide halten einen Prozess am Leben und starten ihn nach einem Absturz neu. Allerdings ist systemd das Init System von Linux selbst, während PM2 nur für Node.js geschrieben wurde. Dieser Unterschied prägt Ihre Wahl.

Zusammengefasst bietet PM2 Node.js Entwicklern Komfort, während systemd eine einheitliche Verwaltung für jeden Dienst liefert. Beide für dieselbe App zu betreiben, ist meist unnötig.

Wie betreiben Sie dieselbe Node.js App mit systemd?

Möchten Sie PM2 nicht nutzen, kann systemd allein genügen. Sie schreiben eine Servicedatei. Das Beispiel unten nutzt Feldnamen aus der systemd Dokumentation, während Pfade und Benutzername Annahmen sind.

[Unit]
Description=Example Node.js app
After=network.target

[Service]
User=exampleuser
WorkingDirectory=/srv/example-app
ExecStart=/usr/bin/node app.js
Restart=on-failure
RestartSec=5
Environment=NODE_ENV=production

[Install]
WantedBy=multi-user.target

Laut Handbuch ist der Standard von Restart gleich no, der Dienst startet also nach einem Absturz nicht neu. Deshalb tragen Sie on-failure oder always ein. RestartSec ist die Wartezeit vor dem Neustart.

Den Pfad der Programmdatei node finden Sie mit command -v node. Nachdem Sie die Servicedatei abgelegt haben, nutzen Sie systemctl daemon-reload und systemctl enable mit der Option --now. Danach lesen Sie die Logs mit journalctl und der Option -u.

Statt Geheimnisse in die Servicedatei zu schreiben, laden Sie sie mit EnvironmentFile aus einer Datei, einem Verwandten der Einstellung Environment. Beschränken Sie die Datei so, dass nur der Dienstbenutzer sie lesen kann. Halten Sie sie außerdem aus Ihrem Repository heraus.

Wie entscheiden Sie zwischen PM2, systemd und Docker?

Die richtige Wahl hängt von Ihrem Team und Ihrer Infrastruktur ab. Für eine kleine Node.js App auf einem Server ist PM2 eine schnelle und vertraute Antwort. Läuft auf dem Server schon vieles, bringt systemd eine einheitliche Verwaltung.

Packen Sie die App in einen Container, ändert sich das Bild. Docker hat eigene Neustart Richtlinien und verlagert den Prozessmanager meist aus dem Container. Details finden Sie in unserem Docker Leitfaden, wir wiederholen sie hier nicht.

• Ein Server und ein Team mit Node.js Schwerpunkt: PM2 genügt meist.
• Gemischte Dienste und ein Team mit Systemadministrator: Denken Sie an systemd.
• Mehrere Umgebungen und wiederholbare Einrichtung: Prüfen Sie Container.

Was immer Sie wählen, beantworten Sie drei Fragen. Startet die App nach einem Absturz neu? Startet sie beim Hochfahren des Servers? Füllen die Logs die Festplatte? Können Sie nicht dreimal mit Ja antworten, ist die Einrichtung unvollständig.

Diese drei Fragen gelten für jedes Werkzeug. Berücksichtigen Sie außerdem, was Ihr Team kennt. Wer das System um Mitternacht rettet, sollte das Werkzeug kennen, und oft ist genau dieses die bessere Wahl. Selbst die fortschrittlichste Einrichtung ist ein Risiko, wenn sie niemand versteht.

Wann überlassen Sie PM2 besser Ihrem Hostinganbieter?

Seien wir ehrlich: Sie müssen nicht alles selbst tun. Haben Sie bei Shared Hosting oder einem verwalteten Tarif keinen Serverzugriff, versuchen Sie nicht, PM2 zu installieren. Unterstützt Ihr Anbieter Node.js, nutzen Sie diese Unterstützung.

Selbst auf einem VPS sind manche Entscheidungen bei Fachleuten sicherer. Firewall, SSL, Benutzerrechte und Backups stehen an erster Stelle. Eine falsche Einstellung kann die Website lahmlegen oder offenlegen.

• Sprechen Sie mit Ihrem Anbieter darüber, die App hinter einen Reverse Proxy zu stellen, statt sie direkt freizugeben.
• Zu Zertifikat und Erneuerung lesen Sie unseren Beitrag zum SSL Zertifikat.
• Ändern Sie die Datenbankstruktur live nicht ohne Backup; unsere Backup Strategie hilft dabei.
• Sehen Sie einen Angriff oder ungewöhnlichen Verkehr, bitten Sie Ihren Hostinganbieter sofort um Hilfe.

Haben Sie noch kein Hosting gewählt, listet unser Beitrag zur Auswahl von Webhosting die Kriterien auf. Hängen Sie Ihrer Supportanfrage Logauszüge und Ihre bisherigen Schritte an.

Das ist keine Schwäche, sondern eine sinnvolle Arbeitsteilung. Ihre Zeit in Marketing und Produkt zu stecken, ist oft produktiver, als die Serversicherheit selbst zu tragen. Zu wissen, was ist PM2 und wie er arbeitet, hilft Ihnen im Gespräch mit dem Anbieter, heißt aber nicht, dass Sie alles selbst tun müssen.

Wie wirkt sich ein App Ausfall auf Ihr Marketingbudget aus?

Es klingt technisch, aber ein Ausfall trifft das Marketing direkt. Landet ein Klick auf eine kaputte Seite, ist das Budget verloren. Außerdem gewinnt der Besucher einen schlechten ersten Eindruck von Ihrer Marke.

Ein schneller und stabiler Server gehört auch zur Sucherfahrung. Wie die Ladezeit das SEO beeinflusst und wie die Ladezeit im Onlineshop den Umsatz beeinflusst, behandeln wir in eigenen Beiträgen. PM2 steht am Ende dieser Kette: Läuft die App oder nicht?

Vor einer großen Kampagne empfehlen wir daher diese Prüfung:

1. Testen Sie, ob die App nach einem Absturz von allein neu startet.
2. Starten Sie den Server neu und prüfen Sie, ob die App von selbst läuft.
3. Kontrollieren Sie die Größe des Logordners und die Rotation.
4. Messen Sie die Website von außen mit einem Werkzeug.

Die Liste ist kurz, verhindert aber die meisten teuren Überraschungen am Kampagnentag. Für breitere Unterstützung bei Software und Infrastruktur sehen Sie sich unsere individuelle Softwareentwicklung an.

Welche Fehler passieren mit PM2 am häufigsten?

Die Liste unten sammelt Fehler, die aus dem Missverständnis dokumentierter Funktionen entstehen. Alle sind vermeidbar.

• pm2 save vergessen: Die App kommt nach einem Neustart nicht zurück.
• Node.js aktualisieren, ohne startup zu erneuern: Das Startskript behält den alten Pfad.
• watch im Live Betrieb einschalten: Es verursacht unnötige Neustarts.
• Keine Logrotation einrichten: Die Festplatte läuft voll, und die App stoppt.
• Eine App mit Zustand im Cluster Modus betreiben: Sitzungen gehen verloren.
• Geheime Schlüssel in die Ecosystem Datei schreiben: Sie können ins Repository gelangen.
• Die App als root betreiben: Eine mögliche Lücke betrifft den ganzen Server.

Nutzen Sie diese Liste als Checkliste. Prüfen Sie jeden Punkt einzeln in Ihrer eigenen Einrichtung.

Teams bemerken diese Fehler meist nach dem ersten Ausfall. Ein Team, das von Anfang an weiß, was ist PM2 und was er leistet, kann dieselben Prüfungen ohne Ausfall machen. Kurz gesagt ist die günstigste Wartung die Prüfung im Voraus.

Welche Schritte gehen Sie vor dem Einsatz von PM2?

Kleine, geordnete Schritte sind der sicherste Weg. Der Ablauf unten fasst die Abschnitte oben zu einem Plan zusammen. Probieren Sie jeden Schritt zunächst in einer Testumgebung aus.

1. Starten Sie die App mit pm2 start unter einem Namen und prüfen Sie sie mit pm2 list.
2. Verlegen Sie die Einstellungen in eine Ecosystem Datei und starten Sie mit --env production.
3. Schalten Sie bei Bedarf den Cluster Modus über instances ein, nachdem Sie geprüft haben, dass die App zustandslos ist.
4. Richten Sie den Start beim Hochfahren mit pm2 startup und pm2 save ein.
5. Richten Sie die Logrotation ein und beobachten Sie die Plattenbelegung.
6. Starten Sie den Server einmal neu und prüfen Sie, dass alles zurückkehrt.

Den letzten Schritt überspringen viele. Doch die echte Sicherheit ist, dass die App nach einem echten Neustart von allein zurückkommt. Betrachten Sie die Einrichtung erst als fertig, wenn Sie das gesehen haben.

Zusammengefasst lautet die praktische Antwort auf was ist PM2: eine Betriebsebene, die Ihre Node.js App am Leben hält, überwacht und leicht aktualisierbar macht. Richten Sie sie gut ein, erlebt die Website weniger Ausfälle. Lassen Sie sie weg, erfahren Sie beim ersten Absturz davon.