Repository navigation
Use globally defined log attribute key names across all services and packages #3290
Description
Description
Due to the lack of top-level definitions of constants for common (and possibly not-quite-so-common) log attribute key names across all packages and services, we are at risk of using different names for attributes.
That, in turn, can be detrimental when logs are ingested by log aggregation systems, since they prevent effectively performing search queries across those attributes (for example a userid).
Having different names of such attributes would require performing a query such as
http_response_code:500 AND (username:alan OR userid:alan OR userID:alan)
instead of just using
http_response_code:500 AND username:alan
Recommendation
Recommendation would be to implement a top-level package, or use pkg/log to define such constants that can be reused across all services.
For example, having a pkg/log/logconst.go file:
package log
const (
UserId = "userid" // the internal user identifier
UserName = "username" // the short name of the user
)Then those could be reused across services when logging:
logger.Error().Err(err).Str(log.UserId, ...).Str(log.UserName, ...).Msg("failed to find user in LDAP")
Activity
[-]Use globally defined log attribute names across all services and packages[/-][+]Use globally defined log attribute key names across all services and packages[/+]rhafer commentedon Aug 13, 2026
@pbleser-oc Sounds like a great idea. I like that.
Bonus would be if we had helpers for constructing sublogger that already added common fields (like requestid, tracedid, userid where applicable) consistantly to every log message. Similar to what we're already doing in the graph service (https://github.com/opencloud-eu/opencloud/blob/main/services/graph/pkg/service/v0/users.go#L44), but more generic.
pbleser-oc commentedon Aug 13, 2026
That does sound like a good idea indeed, part of this issue could also be to seek out some common patterns and implement them in
pkg/log/to encourage reuse.pbleser-oc commentedon Aug 13, 2026
There's also a few things I implemented in the
groupwarebranch, of which I would pick this one for convenience:log.From()To create a logger with preset attributes more naturally (or rather in a less obscure way), since it's a really common operation across all services:
instead of (currently):
(will discuss the "safe logging" in another issue: #3301)
pbleser-oc commentedon Nov 11, 2026
Some numbers from the current
main(39493c1), to show how far the spellings have drifted apart.Across all services and
pkg/, the user id alone is logged asuserid(54 times),userID(20) anduserId(7).In the graph service alone, there are 92 different keys, among them:
groupid(5),groupID(2),groupId(1)memberID(4),memberid(2),memberId(1)body(20),Body(10)originalDN,newDN,memberDN,teacherDN,entryDNnext touserDn,classDnandgroupdnOne thing to keep in mind when we get to it: renaming keys changes the log output, so saved queries, dashboards and alerts that filter on the old names would need to be adapted. That's probably worth a note in the release notes, and could be done service by service.
schweigisito commentedon Nov 11, 2026
Not to forget
tenantIdbeing able to filter by tenants and create dedicated log streams for a specific tenant