cloudfoundry / cloudfoundry/loggregator-agent-release

Clarify source type for drain error messages in app log stream

Open
#719 6 comments 0 reactions 0 assignees View on GitHub

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_fetcher emitted only with LGR. 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

  1. Are there existing automations, dashboards, or alerting rules that depend on filtering by SYS or LGR source type for these messages?
  2. If not, should syslog drain errors use LGR, SYS, or both?
  3. Should the existing dual-emit in syslog_connector.go also be aligned for consistency?

References

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.