cloudfoundry / cloudfoundry/loggregator-agent-release
Clarify source type for drain error messages in app log stream
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 14
- Forks
- 34
- Avg merge
- 7h 6m
- Merged PRs (30d)
- 2
Description
Context
PR #633 adds an AppLogStream that emits error messages to app developers when their syslog drain is misconfigured (#579). The current implementation emits two log lines per error — one with source type LGR and one with SYS:
logclientOption := loggregator.WithAppInfo(appID, "LGR", "")
appLogStream.logClient.EmitLog(message, logclientOption)
logclientOption = loggregator.WithAppInfo(appID, "SYS", appLogStream.sourceIndex)
appLogStream.logClient.EmitLog(message, logclientOption)
This was copied from syslog_connector.go's emitLoggregatorErrorLog, which used it specifically for dropped message notifications. The new AppLogStream is used more broadly (validation errors, connectivity issues, etc.).
Problem
- Duplication: Every error produces two identical log lines in the app's log stream, which is confusing for app developers.
- Historical precedent: The old
filtered_binding_fetcheremitted only withLGR. The dual pattern appears specific to the syslog connector's dropped-message alerts, not a general convention.
Proposal
Emit a single log line per error using LGR with sourceIndex for traceability:
logclientOption := loggregator.WithAppInfo(appID, "LGR", appLogStream.sourceIndex)
appLogStream.logClient.EmitLog(message, logclientOption)
Open Questions
- Are there existing automations, dashboards, or alerting rules that depend on filtering by
SYSorLGRsource type for these messages? - If not, should syslog drain errors use
LGR,SYS, or both? - Should the existing dual-emit in
syslog_connector.goalso be aligned for consistency?
References
- PR: #633 | Issue: #579
- Discussion thread
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading PR #633 and its discussion, then inspect syslog_connector.go and the historical filtered_binding_fetcher.go behavior. Determine whether AppLogStream errors should emit LGR, SYS, or both, including whether syslog_connector.go should change. Done means the decision is documented and the resulting log stream behavior is consistent without unintended downstream impact.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend, observability
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100