So drucken Sie Fehlerprotokolle in Java-Projekten

1. Ungültige Parameter, die vom oberen System eingeführt wurden. Bei Fehlern, die durch illegale Parameter verursacht werden, können Fehler durch Parameterüberprüfung und Vorbedingungsüberprüfung abgefangen werden. Es gibt zwei Arten von Fehlern, die durch die Interaktion mit der unteren Schicht verursacht werden:

a Das System der unteren Schicht hat erfolgreich verarbeitet, aber die Kommunikation ist fehlgeschlagen, was zu Dateninkonsistenzen zwischen Subsystemen führt ; #🎜🎜 #In diesem Fall kann ein Timeout-Kompensationsmechanismus verwendet werden, um die Aufgabe im Voraus aufzuzeichnen und die Daten später durch geplante Aufgaben zu korrigieren.

Wenn Sie bessere Designpläne haben, können Sie auch eine Nachricht hinterlassen.

b Die Kommunikation war erfolgreich, aber in der Verarbeitung der unteren Ebene ist ein Fehler aufgetreten.

In diesem Fall müssen Sie mit den untergeordneten Entwicklern kommunizieren, um die Interaktion zwischen den Subsystemen zu koordinieren.

Sie müssen entsprechend dem Fehlercode und dem Fehler eine entsprechende Verarbeitung durchführen Beschreibung, die von der unteren Ebene zurückgegeben wird Oder angemessene Erinnerungsinformationen angeben.

In beiden Fällen ist es notwendig, davon auszugehen, dass die Zuverlässigkeit des zugrunde liegenden Systems durchschnittlich ist, und Entwurfsüberlegungen für Fehler anzustellen.

3. Auf dieser Ebene liegt ein Fehler in der Systemverarbeitung vor.

Der Grund für den Fehler in dieser Schicht des Systems:

Ursache eins

: durch Fahrlässigkeit verursacht. Auslassung bedeutet, dass der Programmierer solche Fehler hätte vermeiden können, dies aber nicht getan hat. Zum Beispiel wurde && in & eingegeben, == wurde in =; Grenzfehler, zusammengesetzte Logikbeurteilungsfehler usw. eingegeben. Fahrlässigkeit liegt entweder daran, dass der Programmierer nicht konzentriert genug ist, z. B. weil er müde ist, die ganze Nacht Überstunden macht oder Programme schreibt, während er Besprechungen abhält, oder dass der Programmierer sich beeilt, die Funktion zu implementieren, ohne die Robustheit des Programms zu berücksichtigen.

Verbesserungsmaßnahmen: Verwenden Sie statische Code-Analysetools und Unit-Test-Zeilenabdeckung, um solche Probleme effektiv zu vermeiden.

Grund 2

: Verursacht durch unzureichende Fehler- und Ausnahmebehandlung. Geben Sie beispielsweise eine Frage ein. Bei der Berechnung der Addition zweier Zahlen müssen wir nicht nur das Problem des Berechnungsüberlaufs berücksichtigen, sondern auch die Situation illegaler Eingaben. Bei Ersterem kann es durch Verständnis, Fehler oder Erfahrung vermieden werden, während es bei Letzterem so begrenzt werden muss, dass es innerhalb des Bereichs liegt, den unser IQ kontrollieren kann, beispielsweise durch die Verwendung regulärer Ausdrücke, um illegale Eingaben herauszufiltern. Reguläre Ausdrücke müssen getestet werden. Geben Sie bei rechtswidrigen Eingaben möglichst ausführliche, verständliche und freundliche zeitnahe Informationen, Begründungen und Anregungen an.

Verbesserungsmaßnahmen: Berücksichtigen Sie verschiedene Fehlersituationen und die Ausnahmebehandlung so gründlich wie möglich. Fügen Sie nach der Implementierung des Hauptprozesses einen Schritt hinzu: Berücksichtigen Sie sorgfältig verschiedene mögliche Fehler und Ausnahmen und geben Sie angemessene Fehlercodes und Fehlerbeschreibungen zurück. Jede Schnittstelle oder jedes Modul behandelt effektiv ihre eigenen Fehler und Ausnahmen, wodurch Fehler, die durch komplexe Szeneninteraktionen verursacht werden, effektiv vermieden werden können.

Zum Beispiel wird ein Geschäftsanwendungsfall interaktiv durch das Szenario A.B.C. abgeschlossen. Die tatsächliche Ausführung von A.B ist erfolgreich, aber C schlägt fehl. Zu diesem Zeitpunkt muss B die von C zurückgegebenen angemessenen Codes und Nachrichten zurücksetzen und angemessene Codes und Nachrichten an A zurückgeben. A führt ein Rollback basierend auf der Rückgabe von B durch und gibt vernünftige Codes und Nachrichten zurück an den Kunden. Hierbei handelt es sich um einen segmentierten Rollback-Mechanismus, der erfordert, dass jedes Szenario unter ungewöhnlichen Umständen ein Rollback in Betracht zieht.

Grund 3

: Verursacht durch enge logische Kopplung. Aufgrund der engen Kopplung der Geschäftslogik sind bei der schrittweisen Entwicklung von Softwareprodukten verschiedene logische Beziehungen kompliziert und komplex, was es schwierig macht, die Gesamtsituation zu erkennen, was dazu führt, dass sich die Auswirkungen lokaler Änderungen auf den globalen Bereich ausweiten und unvorhersehbare Probleme verursachen .

Verbesserungsmaßnahmen: Schreiben Sie kurze Funktionen und kurze Methoden, vorzugsweise nicht mehr als 50 Zeilen für jede Funktion oder Methode. Zustandslose Funktionen und Methoden schreiben, schreibgeschützter globaler Zustand, dieselbe Vorbedingung gibt immer das gleiche Ergebnis aus und ändert ihr Verhalten nicht abhängig vom externen Zustand. Definieren Sie angemessene Strukturen, Schnittstellen und logische Segmente, um die Verbindung zwischen Schnittstellen herzustellen So orthogonal und niedrig gekoppelt wie möglich; für die Serviceschicht sollten möglichst einfache und orthogonale Schnittstellen bereitgestellt werden, um Anwendungen modular und lose gekoppelt zu halten und logische Abhängigkeiten zu klären.

In Situationen, in denen eine große Anzahl von Geschäftsschnittstellen miteinander interagiert, müssen die logischen Prozesse und Abhängigkeiten jeder Geschäftsschnittstelle als Ganzes sortiert und optimiert werden. Auch verwandte Unternehmen müssen geklärt werden Schnittstelle, organisiert die Konvertierungsbeziehung zwischen Staaten.

Grund 4

: Verursacht durch falschen Algorithmus.

Verbesserungsmaßnahmen: Trennen Sie zunächst den Algorithmus von der Anwendung. Wenn der Algorithmus über mehrere Implementierungen verfügt, kann dies durch Unit-Tests von Gegenprüfungen, wie z. B. Sortieroperationen, herausgefunden werden. Wenn der Algorithmus über reversible Eigenschaften verfügt, kann dies durch Unit-Tests von reversiblen Prüfungen, wie z. B. Verschlüsselungs- und Entschlüsselungsoperationen, herausgefunden werden .

Ursache fünf

: Parameter desselben Typs werden in der falschen Reihenfolge übergeben. Beispiel: „modifyFlow(int rx, int tx)“, der eigentliche Aufruf lautet „modifyFlow(tx,rx)

Verbesserungsmaßnahmen: Machen Sie den Typ so spezifisch wie möglich.“ Verwenden Sie Gleitkommazahlen, wenn Sie sie verwenden müssen, verwenden Sie Zeichenfolgen, wenn Sie Zeichenfolgen verwenden müssen, und verwenden Sie bestimmte Objekttypen, wenn Sie sie verwenden müssen. Parameter desselben Typs sollten so weit wie möglich gestaffelt werden Um erfüllt zu sein, müssen Sie dies durch Schnittstellentests überprüfen. Die Schnittstellenparameterwerte müssen unterschiedlich sein.

Grund sechs

: Nullzeiger-Ausnahme. Nullzeigerausnahmen treten normalerweise auf, wenn das Objekt nicht korrekt initialisiert wurde oder vor der Verwendung nicht überprüft wurde, ob das Objekt nicht null ist.

Verbesserungsmaßnahmen: Überprüfen Sie bei Konfigurationsobjekten, ob sie erfolgreich initialisiert wurden. Überprüfen Sie vor dem Abrufen des Entitätsobjekts zur Verwendung, ob es nicht null ist.

Ursache sieben: Netzwerkkommunikationsfehler. Netzwerkkommunikationsfehler werden normalerweise durch Netzwerkverzögerungen, Überlastung oder Blockaden verursacht. Bei Netzwerkkommunikationsfehlern handelt es sich in der Regel um Ereignisse mit geringer Wahrscheinlichkeit, aber Ereignisse mit geringer Wahrscheinlichkeit führen wahrscheinlich zu großflächigen Ausfällen und Fehlern, die schwer zu reproduzieren sind.

Verbesserungsmaßnahmen: Erstellen Sie INFO-Protokolle am Endpunkt des vorherigen Subsystems bzw. am Eintrittspunkt des nächsten Subsystems. Der Zeitunterschied zwischen den beiden gibt einen Hinweis.

Grund 8: Transaktions- und Parallelitätsfehler. Die Kombination aus Transaktionen und Parallelität kann leicht zu Fehlern führen, die nur sehr schwer zu lokalisieren sind.

Verbesserungsmaßnahmen: Für gleichzeitige Vorgänge im Programm, die Shared-Variablen und wichtige Statusänderungen beinhalten, müssen INFO-Protokolle hinzugefügt werden.

Wenn es einen effektiveren Weg gibt, hinterlassen Sie bitte eine Nachricht, um darauf hinzuweisen.

Grund 9: Konfigurationsfehler.

Verbesserungsmaßnahmen: Erkennen Sie beim Starten der Anwendung oder beim Starten der entsprechenden Konfiguration alle Konfigurationselemente, drucken Sie das entsprechende INFO-Protokoll aus und stellen Sie sicher, dass alle Konfigurationen erfolgreich geladen werden.

Ursache zehn: Fehler, die durch Unkenntnis des Geschäfts entstehen. In mittleren und großen Systemen sind einige Geschäftslogiken und Geschäftsinteraktionen relativ komplex. Die gesamte Geschäftslogik kann im Gehirn mehrerer Entwicklungsstudenten vorhanden sein, und das Verständnis aller ist unvollständig. Dies kann leicht zu Fehlern bei der geschäftlichen Codierung führen.

Verbesserungsmaßnahmen: Entwerfen Sie durch Diskussion und Kommunikation mit mehreren Personen korrekte Geschäftsanwendungsfälle und schreiben und implementieren Sie Geschäftslogik basierend auf Geschäftsanwendungsfällen Anwendungsfälle müssen vollständig archiviert werden; geben Sie die Voraussetzungen, die Verarbeitungslogik, die Nachprüfung und die Vorsichtsmaßnahmen des Geschäfts an. Wenn sich das Geschäft ändert, müssen die Geschäftsnotizen gleichzeitig aktualisiert werden. Geschäftsanmerkungen sind wichtige Dokumente für Geschäftsschnittstellen und spielen eine wichtige Caching-Rolle für das Geschäftsverständnis.

Ursache 11: Fehler aufgrund von Designproblemen. Beispielsweise weist die synchrone serielle Methode Probleme mit der Leistung und der langsamen Reaktion auf, während die gleichzeitige asynchrone Methode die Probleme mit der Leistung und der langsamen Reaktion lösen kann, jedoch versteckte Gefahren für die Sicherheit und Korrektheit mit sich bringt. Der asynchrone Ansatz wird zu Änderungen im Programmiermodell führen und neue Probleme wie das asynchrone Senden und Empfangen von Nachrichten mit sich bringen. Die Verwendung von Cache kann die Leistung verbessern, es treten jedoch Probleme bei Cache-Updates auf.

Verbesserungsmaßnahmen: Entwurfsunterlagen verfassen und sorgfältig prüfen. Das Designdokument muss den Hintergrund, die Anforderungen, die zu erreichenden Geschäftsziele, die zu erreichenden Geschäftsleistungsindikatoren, mögliche Auswirkungen, allgemeine Designideen und detaillierte Pläne beschreiben und die Vorteile, Nachteile und möglichen Auswirkungen des Plans durch Tests und Akzeptanz vorhersehen. Stellen Sie sicher, dass die Änderungen vorgenommen werden. Die Designlösung erfüllt die Geschäftsziele und Geschäftsleistungskennzahlen.

Ursache Zwölf: Fehler durch unbekannte Details verursacht. Zum Beispiel Pufferüberlauf und SQL-Injection-Angriffe. Aus funktionaler Sicht gibt es kein Problem, aber aus Sicht der böswilligen Nutzung gibt es Lücken. Wenn Sie beispielsweise die Jackson-Bibliothek für die JSON-String-Analyse auswählen, treten standardmäßig Analysefehler auf, wenn dem Objekt neue Felder hinzugefügt werden. Die Annotation @JsonIgnoreProperties(ignoreUnknown = true) muss dem Objekt hinzugefügt werden, um korrekt auf Änderungen zu reagieren. Wenn Sie andere JSON-Bibliotheken wählen, tritt dieses Problem möglicherweise nicht auf.

Verbesserungsmaßnahmen: Einerseits ist es notwendig, Erfahrungen zu sammeln, andererseits Sicherheitsprobleme und Ausnahmen zu berücksichtigen und ausgereifte und streng getestete Bibliotheken auszuwählen.

GRUND DREIZEHN: Fehler, die im Laufe der Zeit auftreten. Es ist nicht ungewöhnlich, dass Lösungen, die in der Vergangenheit großartig erschienen, in aktuellen oder zukünftigen Szenarien unhandlich oder sogar nutzlos werden. Beispielsweise galten Verschlüsselungs- und Entschlüsselungsalgorithmen in der Vergangenheit möglicherweise als perfekt, sollten jedoch nach dem Knacken mit Vorsicht verwendet werden.

Verbesserungsmaßnahmen: Achten Sie auf Änderungen und Neuigkeiten zur Schwachstellenbehebung und korrigieren Sie veraltete Codes, Bibliotheken und Verhaltensweisen umgehend.

Grund 14: Hardwarebezogene Fehler. Zum Beispiel Speicherlecks, unzureichender Speicherplatz, OutOfMemoryError usw.

Verbesserungsmaßnahmen: Erhöhen Sie die Leistungsüberwachung wichtiger Indikatoren wie CPU/Speicher/Netzwerk des Anwendungssystems.

Häufige Fehler, die im System auftreten:

• Der Entitätsdatensatz in der Datenbank existiert nicht und Sie müssen angeben, um welche Entität oder Entität es sich handelt Bezeichner: #🎜 🎜🎜#

  # Die Entitätskonfiguration ist falsch. Sie müssen angeben, welche Konfiguration das Problem aufweist und welche die richtige Konfiguration sein sollte.
• Die Entitätsressource erfüllt nicht die Bedingungen. Sie müssen angeben, was die aktuelle Ressource ist und welche Ressourcenanforderungen bestehen Für den Entitätsvorgang müssen Sie angeben, welche Voraussetzungen erfüllt sein müssen.

• , müssen Sie angeben, welche Nachprüfungen erfüllt werden müssen und wie der aktuelle Status ist; Leistungsproblem und wie kann es in Zukunft optimiert werden?

Im Allgemeinen treten Fehler, die schwer zu lokalisieren sind, an relativ niedrigen Stellen auf. Da die unterste Ebene bestimmte Geschäftsszenarien nicht vorhersagen kann, sind die angezeigten Fehlermeldungen relativ allgemein.

Dies erfordert die Bereitstellung möglichst vieler Hinweise auf den oberen Ebenen des Unternehmens. Der Fehler muss dadurch verursacht werden, dass bei der Interaktion mehrerer Systeme oder Schichten die Voraussetzungen auf einer bestimmten Schicht des Stapels nicht erfüllt sind. Versuchen Sie beim Programmieren sicherzustellen, dass alle notwendigen Voraussetzungen in jeder Schicht des Stapels erfüllt sind, vermeiden Sie so weit wie möglich die Übergabe falscher Parameter an die unterste Schicht und fangen Sie Fehler so weit wie möglich auf der Geschäftsschicht ab.

Die meisten Fehler werden durch eine Kombination von Gründen verursacht. Aber jeder Fehler muss seine Ursache haben. Führen Sie nach der Fehlerbeseitigung eine eingehende Analyse durch, wie die Fehler aufgetreten sind und wie Sie verhindern können, dass sie erneut auftreten. Mit harter Arbeit kann man Erfolg haben, aber nur durch Nachdenken kommt man voran! Empfehlung: Javas elegante Protokollierung: log4j-Praxiskapitel

So schreiben Sie Fehlerprotokolle, die die Fehlerbehebung erleichtern

Grundprinzipien der Fehlerprotokollierung :

1. so vollständig wie möglich . Jedes Fehlerprotokoll beschreibt vollständig: welcher Fehler in welchem ​​Szenario aufgetreten ist, welcher Grund (oder mögliche Gründe), wie er behoben werden kann (oder Lösungstipps); #Seien Sie so konkret wie möglich

   . Wenn beispielsweise die NC-Ressourcen nicht ausreichen, auf welchen spezifischen Ressourcenmangel bezieht sich dies direkt über das Programm? Bei allgemeinen Fehlern wie VM NOT EXIST muss das Szenario angegeben werden, in dem er auftritt kann spätere statistische Arbeiten erleichtern.

2. So direkt wie möglich

   . Das ideale Fehlerprotokoll sollte es den Menschen ermöglichen, die Ursache und die Lösung auf den ersten Blick zu erkennen, anstatt mehrere Schritte durchlaufen zu müssen, um die wahre Ursache zu finden.

3. Bestehende Erfahrungen direkt in das System integrieren

   . Alle gelösten Probleme und Erfahrungen sollten möglichst freundlich in das System integriert werden, um neuen Mitarbeitern bessere Tipps zu geben und nicht woanders vergraben zu werden.

4. Das Layout sollte ordentlich und ordentlich sein und das Format sollte einheitlich und standardisiert sein

   . Dichte, aufsatzartige Protokolle sind herzzerreißend anzusehen, ziemlich unfreundlich und für die Fehlerbehebung unbequem.

5. Verwenden Sie mehrere Schlüsselwörter, um die Anfrage eindeutig zu identifizieren

   , und heben Sie die Schlüsselwörter hervor: Zeit, Entitätsidentifikation (z. B. VM-Name) und Operationsname .

6. Grundlegende Schritte zur Fehlerbehebung:

   Melden Sie sich beim Anwendungsserver an – > Öffnen Sie die Protokolldatei – > Suchen Sie den Speicherort des Fehlerprotokolls -> Befolgen Sie die Hinweise im Fehlerprotokoll, um Probleme zu beheben, zu bestätigen und zu lösen.

Unter ihnen:

Von der Anmeldung bis zum Öffnen der Protokolldatei

. Da es mehrere Anwendungsserver gibt, ist es unpraktisch, sich einzeln anzumelden, um sie anzuzeigen. Es ist notwendig, ein Tool zu schreiben und es auf der AG zu platzieren, um alle Serverprotokolle direkt auf der AG anzuzeigen und sogar die erforderlichen Fehlerprotokolle direkt herauszufiltern.

1. Standort des Fehlerprotokolls

   . Das aktuelle Layout der Protokolle ist dicht gepackt, was das Auffinden der Fehlerprotokolle erschwert. Im Allgemeinen können Sie zunächst „time“ verwenden, um den Speicherort am Anfang des Fehlerprotokolls zu lokalisieren, und dann die Kombination aus Entitätsschlüsselwort und Operationsname verwenden, um den Speicherort des Fehlerprotokolls zu sperren. Obwohl das Auffinden von Fehlerprotokollen basierend auf der Anforderungs-ID traditioneller ist, erfordert es zunächst das Auffinden der Anforderungs-ID und ist nicht beschreibend. Es ist am besten, den Speicherort des Fehlerprotokolls direkt anhand von Zeit-/Inhaltsschlüsselwörtern zu lokalisieren.

2. 3. Analysieren Sie das Fehlerprotokoll

   . Der Inhalt des Fehlerprotokolls sollte direkter und klarer sein, deutlich darauf hinweisen, dass er mit den Merkmalen des aktuell zu untersuchenden Problems übereinstimmt, und wichtige Hinweise geben.

Normalerweise besteht das Problem bei Programmfehlerprotokollen darin, dass der Protokollinhalt nur auf der Grundlage des aktuellen Codekontexts verstanden werden kann. Er sieht prägnant aus, ist jedoch immer unvollständig in einem halbenglischen Format geschrieben Wenn Sie den Codekontext verlassen, ist es schwer zu verstehen. Was genau steht darin? Sie müssen darüber nachdenken oder sich den Code ansehen, um zu verstehen, was das Protokoll bedeutet. Handelt es sich hier nicht um selbstverschuldetes Leid? Erweiterung: Beschreiben Sie im Detail die Mainstream-Java-Protokollierungstool-Bibliothek

Zum Beispiel:

if ((storageType == StorageType.dfs1 || storageType == StorageType.dfs2)                  && (zone.hasStorageType(StorageType.io3) || zone.hasStorageType(StorageType.io4))) {  // 进入dfs1 和dfs2 在io3 io4 存储。  } else {        log.info("zone storage type not support, zone: " + zone.getZoneId() + ", storageType: "  + storageType.name());        throw new BizException(DeviceErrorCode.ZONE_STORAGE_TYPE_NOT_SUPPORT);  }

zone Welcher Speichertyp sollte nicht unterstützt werden? 🎜🎜#

Das Fehlerprotokoll sollte klar beschreiben können, was passiert ist, auch wenn Sie den Kontext des Codes verlassen.

Darüber hinaus können Sie, wenn Sie die Gründe direkt im Fehlerprotokoll klar erläutern können, auch bei der Erstellung von Inspektionsprotokollen einiges an Aufwand sparen.

In gewisser Weise kann das Fehlerprotokoll auch ein sehr nützliches Dokument sein, das verschiedene illegale Anwendungsfälle aufzeichnet.

Der Inhalt des aktuellen Programmfehlerprotokolls weist möglicherweise die folgenden Probleme auf:

1 Das Fehlerprotokoll gibt die Fehlerparameter und den Inhalt nicht an: #🎜 🎜#

catch(Exception ex){        log.error("control ip insert failed", ex);        return new ResultSet<AddControlIpResponse>(  ControlIpErrorCode.ERROR_CONTROL_IP_INSERT_FAILURE);  }

gibt nicht die Kontroll-IP an, bei der das Einfügen fehlgeschlagen ist. Wenn Sie das Kontroll-IP-Schlüsselwort hinzufügen, ist es einfacher, den Fehler zu suchen und zu sperren.

Ähnliche sind:

log.error("Get some errors when insert subnet and its IPs into database. Add subnet or IP failure.", e);

Es wird nicht angegeben, zu welchem ​​Subnetz und zu welchen IPs es gehört. Es ist erwähnenswert, dass Sie einige zusätzliche Dinge tun müssen, um diese anzugeben , was möglicherweise erforderlich ist. Hier müssen Leistung und Debugbarkeit abgewogen werden.

解决方案：使用 String.format("Some msg to ErrorObj: %s", errobj) 方法指明错误参数及内容。

这通常要求对 DO 对象编写可读的 toString 方法。

2.错误场景不明确：

log.error("nc has exist, nc ip" + request.getIp());

在 createNc 中检测到 NC 已经存在报错。但是日志上没有指明错误场景， 让人猜测，为什么会报NC已存在错误。

可以改为

log.error("nc has exist when want to create nc, please check nc parameters. Given nc ip: " + request.getIp());  log.error("[create nc] nc has exist, please check nc parameters. Given nc ip: " + request.getIp());

类似的还有：

log.error("not all vm destroyed, nc id " + request.getNcId());

改成

log.error("[delete nc] some vms [%s] in the nc are not destroyed. nc id: %s", vmNames, request.getNcId());

解决方案：错误消息加上 when 字句， 或者错误消息前加上 【接口名】, 指明错误场景，直接从错误日志就知道明白了。

一般能够知道 executor 的可以加上 【接口名】， service 加上 when 字句。

3.内容不明确, 或不明其义：

if(aliMonitorReporter == null) {          log.error("aliMonitorReporter is null!");  } else {         aliMonitorReporter.attach(new ThreadPoolMonitor(namePrefix, asynTaskThreadPool.getThreadPoolExecutor()));  }

改为：

log.error("aliMonitorReporter is null, probably not initialized properly, please check configuration in file xxx.");

类似的还有：

if (diskWbps == null && diskRbps == null && diskWiops == null    && diskRiops == null) {        log.error("none of attribute is specified for modifying");        throw new BizException(DeviceErrorCode.NO_ATTRIBUTE_FOR_MODIFY);  }

改为

log.error("[modify disk attribute] None of [diskWbps,diskRbps,diskWiops,diskRiops] is specified for disk id:" + diskId);

解决方案：更清晰贴切地描述错误内容。

4.排查问题的引导内容不明确：

log.error("get gw group ip segment failed. zkPath: " + LockResource.getGwGroupIpSegmnetLockPath(request.getGwGroupId()));

zkPath ? 如何去排查这个问题？我该去找谁？到哪里去查找更具体的线索？

解决方案：加上相应的背景知识和引导排查措施。

5.错误内容不够具体细致：

if (!ncResourceService.isNcResourceEnough(ncResourceDO,    vmResourceCondition)) {        log.error("disk space is not enough at vm's nc, nc id:" + vmDO.getNcId());        throw new BizException(ResourceErrorCode.ERROR_RESOURCE_NOT_ENOUGH);  }

究竟是什么资源不够？目前剩余多少？现在需要多少？值得注意的是， 要指明这些要额外做一些事情， 可能会稍微影响性能。这时候需要权衡性能和可调试性。

解决方案：通过改进程序或程序技巧， 尽可能揭示出具体的差异所在， 减少人工比对的操作。

6.半英文句式读起来不够清晰明白，需要思考来拼凑起完整的意思：

log.warn("cache status conflict, device id "+deviceDO.getId()+" db status "+deviceDO.getStatus() +", nc status "+ status);

改为:

log.warn(String.format("[query cache status] device cache status conflicts between regiondb and nc, status of device '%s' in regiondb is %s , but is %s in nc.", deviceDO.getId(), deviceDO.getStatus(), status));

解决方案：改为自然可读的英文句式。

总结起来， 错误日志格式可以为：

log.error("[接口名或操作名] [Some Error Msg] happens. [params] [Probably Because]. [Probably need to do].");  log.error(String.format("[接口名或操作名] [Some Error Msg] happens. [%s]. [Probably Because]. [Probably need to do].", params));

或

log.error("[Some Error Msg] happens to 错误参数或内容 when [in some condition]. [Probably Because]. [Probably need to do].");  log.error(String.format("[Some Error Msg] happens to %s when [in some condition]. [Probably Because]. [Probably need to do].", parameters));

[Probably Reason]. [Probably need to do]. 在某些情况下可以省略；在一些重要接口和场景下最好能说明一下。

每一条错误日志都是独立的，尽可能完整、具体、直接说明何种场景下发生了什么错误，由什么原因导致，要采用什么措施或步骤。

问题：

1.String.format 的性能会影响打日志吗？

一般来说， 错误日志应该是比较少的， 使用 String.format 的频度并不会太高，不会对应用和日志造成影响。

2.开发时间非常紧张时， 有时间去斟酌字句吗？

建立一个标准化的内容格式，将内容往格式套，可以节省斟酌字句的时间。

3.什么时候使用 info, warn , error ?

•  info 用于打印程序应该出现的正常状态信息， 便于追踪定位；

•  warn 表明系统出现轻微的不合理但不影响运行和使用；

•  error 表明出现了系统错误和异常，无法正常完成目标操作。

错误日志是排查问题的重要手段之一。当我们编程实现一项功能时， 通常会考虑可能发生的各种错误及相应原因：

要排查出相应的原因， 就需要一些关键描述来定位原因。

这就会形成三元组：

错误现象 -> 错误关键描述 -> 最终的错误原因。

需要针对每一种错误尽可能提供相应的错误关键描述，从而定位到相应的错误原因。

Das obige ist der detaillierte Inhalt vonSo drucken Sie Fehlerprotokolle in Java-Projekten. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!