Improve Beholder Logger #1280
Improve Beholder Logger #1280
Conversation
bolekk
commented
Jun 19, 2025
bolekk
commented
- Don't drop errors
- Protect against blocking calls
1. Don't drop errors 2. Protect against blocking calls
bolekk
force-pushed
the
chore/beholder-logger-cleanup
branch
from
7b379a2 to
eb095e7
Compare
| @@ -146,3 +253,8 @@ func getLabelMap(keysAndValues ...any) map[string]string { | |||
| } | |||
| return labels | |||
| } | |||
|
|
|||
| func getBeholderCallContext() (context.Context, context.CancelFunc) { | |||
There was a problem hiding this comment.
i thought the entire point of chip was to guarantee delivery of beholder logs.
i understand the technical reason for a timeout.
but, i am concerned this is shortcutting the product requirements and expectations.
what am i missing?
There was a problem hiding this comment.
Not logs - events. Logs will be delivered on a best-effort basis.
(there is a small subtlety here that the emitter is currently packing logs into an event and I can't remember if that is going to change or if that event will be treated differently, maybe @patrickhuie19 can clarify)
There was a problem hiding this comment.
IIUC otel treats logs and events as one kind of thing on the same stream
There was a problem hiding this comment.
Based on what I understood from @hendoxc and Mathew, Beholder Client will select a different endpoint to send the data to, under the hood.
There was a problem hiding this comment.
All logs use the BaseMessage proto format and go over the custom message endpoint.
There was a problem hiding this comment.
So is it OK to merge? :)
