Logging loop
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 25/100
- Issue-Typ
- Bug
- Klarheit
- Muss geklärt werden
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- java
- Bereich
- observability
Rechercherichtung
Beginne damit, die Protokollierung von FluentLogger und RawSocketSender ausgehend nachzuverfolgen, und sieh dir anschließend zur Einordnung das verlinkte logback-more-appenders-Problem an. Ein hilfreicher Beitrag müsste eine eindeutig abgestimmte Möglichkeit bieten, die Protokollierungsschleife zu verhindern oder Nachrichten zu drosseln, einschließlich einer Validierung, dass FluentLogger weiterhin relevante Fehler melden kann.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
If FluentLogger is used as an appender with logback (such as https://github.com/sndyuk/logback-more-appenders) then any logging by FluentLogger and related classes such as RawSocketSender can end up creating a nice little logging loop.
For instance, RawSocketSender will log "Created messages" or a message when the buffer is full... all of which get routed back into slf4j and then likely routed right back into FluentLogger for logging....
While the obvious answer is to drop any org.fluentd.logger.* messages that would end up routed to the FluentLogger appender (thereby possibly leaving them routed to other appends) that would then mask any real messages but I wonder if there is a better solution?
I don't have any ideas but figured I'd throw the problem out there and maybe someone would have a good idea.
It may also be helpful to enable some type of throttling on messages--- like if the buffer is full due to a down fluentd.
Also cross posted here: https://github.com/sndyuk/logback-more-appenders/issues/2
- Vorherrschende Sprache
- Java
- Sterne
- 210
- Forks
- 86
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Entwicklungsumgebung
Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus fluent/fluent-logger-java
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 45/100
fluent/fluent-logger-java#100 ·
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 15/100
fluent/fluent-logger-java#99 · 1 Kommentar · 2 Reaktionen ·
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 45/100
fluent/fluent-logger-java#98 · 1 Kommentar ·
-
Null Pointer Exception with slf4j-log4j12-1.7.30 (Fluent-logger incompatible with the new version)Offen
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 42/100
fluent/fluent-logger-java#89 · 3 Kommentare ·
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 25/100
fluent/fluent-logger-java#88 · 1 Kommentar ·
Alle Issues in fluent/fluent-logger-java
Ähnliche Issues
-
status: waiting-for-triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 62/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
Maintainer antworten meist innerhalb von 1 Tag
-
AOT compilation fails for derived delete queries returning SetEvtl. vergeben @ryujungkyun hat das heute übernommen. Offenstatus: waiting-for-triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
spring-projects/spring-data-jpa#4387 ·
Maintainer antworten meist innerhalb von 3 Tagen
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
apache/rocketmq-dashboard#6636 ·
Maintainer antworten meist innerhalb von 3 Tagen