Skip to content

refactor: logging standardisation - #207

Merged
beeme1mr merged 30 commits into
open-feature:mainfrom
james-milligan:logging
Nov 22, 2022
Merged

beeme1mr merged 30 commits into
open-feature:mainfrom
james-milligan:logging

Conversation

@james-milligan

@james-milligan james-milligan commented Nov 7, 2022

Copy link
Copy Markdown
Contributor

This PR

  • introduce logging service to wrap zap logs
  • standardise logging pattern across services

Related Issues

#184

Notes

Follow-up Tasks

How to test

Signed-off-by: James Milligan <james@omnant.co.uk>
Signed-off-by: James Milligan <james@omnant.co.uk>
Signed-off-by: James Milligan <james@omnant.co.uk>
Signed-off-by: James Milligan <james@omnant.co.uk>
Signed-off-by: James Milligan <james@omnant.co.uk>
Signed-off-by: James Milligan <james@omnant.co.uk>
Signed-off-by: James Milligan <james@omnant.co.uk>
Signed-off-by: James Milligan <james@omnant.co.uk>
@james-milligan

Copy link
Copy Markdown
Contributor Author

This fails on benchmarking however I believe this is to be expected with the addition of the new logs

@toddbaert

toddbaert commented Nov 9, 2022

Copy link
Copy Markdown
Member

This fails on benchmarking however I believe this is to be expected with the addition of the new logs

@james-milligan @skyerus @AlexsJones @beeme1mr this comment made me wonder:

Could we implement async logging? We want flagd to be as low-latency as possible - I think it would be nice to make all the logging async. It looks like logrus doesn't support this out of the box, but there's a more-or-less standard solution:

sirupsen/logrus#725

@toddbaert

Copy link
Copy Markdown
Member

@james-milligan this is a good start!

@AlexsJones

Copy link
Copy Markdown
Member

This fails on benchmarking however I believe this is to be expected with the addition of the new logs

@james-milligan @skyerus @AlexsJones @beeme1mr this comment made me wonder:

Could we implement async logging? We want flagd to be as low-latency as possible - I think it would be nice to make all the logging async. It looks like logrus doesn't support this out of the box, but there's a more-or-less standard solution:

sirupsen/logrus#725

I am not really sure if it's going to be worth it as long as we can disable logging if required. I don't mind checking it out though.

Signed-off-by: James Milligan <james@omnant.co.uk>
Signed-off-by: James Milligan <james@omnant.co.uk>
Signed-off-by: James Milligan <james@omnant.co.uk>
Signed-off-by: James Milligan <james@omnant.co.uk>
Signed-off-by: James Milligan <james@omnant.co.uk>
Signed-off-by: James Milligan <james@omnant.co.uk>
Signed-off-by: James Milligan <james@omnant.co.uk>
Signed-off-by: James Milligan <james@omnant.co.uk>
Signed-off-by: James Milligan <james@omnant.co.uk>
Signed-off-by: James Milligan <james@omnant.co.uk>
Signed-off-by: James Milligan <james@omnant.co.uk>
Signed-off-by: James Milligan <james@omnant.co.uk>
Signed-off-by: James Milligan <james@omnant.co.uk>
@james-milligan
james-milligan marked this pull request as ready for review November 16, 2022 16:03
Signed-off-by: James Milligan <james@omnant.co.uk>
Signed-off-by: James Milligan <james@omnant.co.uk>
@AlexsJones

Copy link
Copy Markdown
Member

Is this ready to review @james-milligan , should we just ignore the benchmark?

@james-milligan

james-milligan commented Nov 17, 2022

Copy link
Copy Markdown
Contributor Author

Is this ready to review @james-milligan , should we just ignore the benchmark?

yes its ready for revie, I think we should ignore the benchmark, it may even be worthwhile updating the benchmark to be more inline with the e2e tests so we can view performance impacts across the full flag evaluation process, not just across the span of the connect service.

If we do find that performance becomes an issue we can introduce an option to noop the logging service for specific loggers, e.g. silence request logs and only show configuration changes, which would also bypass the setting of values in the logger

Comment thread pkg/eval/json_evaluator.go
Comment thread pkg/logger/logger.go Outdated
Comment thread pkg/logger/logger.go Outdated
Comment thread pkg/logger/logger.go Outdated
Signed-off-by: James Milligan <james@omnant.co.uk>
Comment thread pkg/sync/kubernetes/kubernetes_sync.go
Comment thread pkg/logger/logger.go
@toddbaert

Copy link
Copy Markdown
Member

This fails on benchmarking however I believe this is to be expected with the addition of the new logs

@james-milligan @skyerus @AlexsJones @beeme1mr this comment made me wonder:
Could we implement async logging? We want flagd to be as low-latency as possible - I think it would be nice to make all the logging async. It looks like logrus doesn't support this out of the box, but there's a more-or-less standard solution:
sirupsen/logrus#725

I am not really sure if it's going to be worth it as long as we can disable logging if required. I don't mind checking it out though.

Ya I think I agree. If we can disabling the logging in hot paths (evaluation) but keep it in less hot but important path (flag updates) that's fine with me. I think that will happen on a subsequent PR, cc @james-milligan

@toddbaert
toddbaert self-requested a review November 17, 2022 17:39
Comment thread cmd/start.go Outdated
Signed-off-by: James Milligan <james@omnant.co.uk>
Comment thread pkg/logger/logger.go
Signed-off-by: James Milligan <james@omnant.co.uk>
Signed-off-by: James Milligan <james@omnant.co.uk>
@toddbaert

Copy link
Copy Markdown
Member

Is this ready to review @james-milligan , should we just ignore the benchmark?

yes its ready for revie, I think we should ignore the benchmark, it may even be worthwhile updating the benchmark to be more inline with the e2e tests so we can view performance impacts across the full flag evaluation process, not just across the span of the connect service.

If we do find that performance becomes an issue we can introduce an option to noop the logging service for specific loggers, e.g. silence request logs and only show configuration changes, which would also bypass the setting of values in the logger

I'm in favor of merging this and creating a new issue for a noop logger for evaluations that can be configured to still log update events.

@beeme1mr
beeme1mr merged commit 418b9ef into open-feature:main Nov 22, 2022
@james-milligan
james-milligan deleted the logging branch March 23, 2023 10:58
raphael-wigoutschnigg-dt pushed a commit to open-feature-forking/flagd that referenced this pull request Mar 11, 2025
Signed-off-by: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
jonathannorris added a commit that referenced this pull request Jul 20, 2026
…edback

- github.com/sigstore/sigstore-go v1.1.4 -> v1.2.2 in test/integration
  (medium, alert #260)
- js-yaml ^4.1.1 -> ^4.2.0 and vite ^6.4.2 -> ^6.4.3 in playground-app
  (medium/high, alerts #207, #199, #200); lockfile already resolved these
  transitively, this pins the direct specifiers to match
- Root-cause fix for a regression introduced by the prior
  testcontainers-go v0.41.0 -> v0.43.0 bump: v0.43.0's modules/compose
  changed DockerContainer.MappedPort's signature (nat.Port -> string),
  which is incompatible with go-sdk-contrib/tests/flagd/v2@v2.0.2's
  testframework (pinned, no newer version exists) and broke
  `go vet`/`go test` compilation in test/integration (go build alone
  didn't catch it since _test.go files aren't compiled by `go build`).
  Reverted testcontainers-go and testcontainers-go/modules/compose to
  v0.41.0 (API-compatible) while keeping the already-patched transitive
  containerd/containerd/v2 v2.2.5 and other bumps pinned via explicit
  go.mod requires, so alerts #189, #192-#196 remain resolved without
  reintroducing the vulnerable containerd version.
- Add ReadTimeout to the flagd-proxy metrics server's http.Server per
  CodeRabbit review feedback on this PR: ReadHeaderTimeout alone only
  bounds header parsing, leaving the plain HTTP/h2c port open to
  slow-client (Slowloris-style) resource exhaustion.

Still unresolvable: github.com/docker/docker (alerts #151, #152, #184,
#185, #186) remains at v28.5.2+incompatible in test/integration. No
version >= 28.5.2 (including the advisory's referenced 29.3.1 for
alert #152) is published under the legacy github.com/docker/docker
import path in the Go module proxy; moby now ships new majors under
github.com/moby/moby/v2, which this module graph cannot switch to
without deeper dependency surgery.

Signed-off-by: Jonathan Norris <jonathan.norris@dynatrace.com>
toddbaert pushed a commit that referenced this pull request Jul 20, 2026
…edback

- github.com/sigstore/sigstore-go v1.1.4 -> v1.2.2 in test/integration
  (medium, alert #260)
- js-yaml ^4.1.1 -> ^4.2.0 and vite ^6.4.2 -> ^6.4.3 in playground-app
  (medium/high, alerts #207, #199, #200); lockfile already resolved these
  transitively, this pins the direct specifiers to match
- Root-cause fix for a regression introduced by the prior
  testcontainers-go v0.41.0 -> v0.43.0 bump: v0.43.0's modules/compose
  changed DockerContainer.MappedPort's signature (nat.Port -> string),
  which is incompatible with go-sdk-contrib/tests/flagd/v2@v2.0.2's
  testframework (pinned, no newer version exists) and broke
  `go vet`/`go test` compilation in test/integration (go build alone
  didn't catch it since _test.go files aren't compiled by `go build`).
  Reverted testcontainers-go and testcontainers-go/modules/compose to
  v0.41.0 (API-compatible) while keeping the already-patched transitive
  containerd/containerd/v2 v2.2.5 and other bumps pinned via explicit
  go.mod requires, so alerts #189, #192-#196 remain resolved without
  reintroducing the vulnerable containerd version.
- Add ReadTimeout to the flagd-proxy metrics server's http.Server per
  CodeRabbit review feedback on this PR: ReadHeaderTimeout alone only
  bounds header parsing, leaving the plain HTTP/h2c port open to
  slow-client (Slowloris-style) resource exhaustion.

Still unresolvable: github.com/docker/docker (alerts #151, #152, #184,
#185, #186) remains at v28.5.2+incompatible in test/integration. No
version >= 28.5.2 (including the advisory's referenced 29.3.1 for
alert #152) is published under the legacy github.com/docker/docker
import path in the Go module proxy; moby now ships new majors under
github.com/moby/moby/v2, which this module graph cannot switch to
without deeper dependency surgery.

Signed-off-by: Jonathan Norris <jonathan.norris@dynatrace.com>
toddbaert pushed a commit that referenced this pull request Jul 20, 2026
…edback

- github.com/sigstore/sigstore-go v1.1.4 -> v1.2.2 in test/integration
  (medium, alert #260)
- js-yaml ^4.1.1 -> ^4.2.0 and vite ^6.4.2 -> ^6.4.3 in playground-app
  (medium/high, alerts #207, #199, #200); lockfile already resolved these
  transitively, this pins the direct specifiers to match
- Root-cause fix for a regression introduced by the prior
  testcontainers-go v0.41.0 -> v0.43.0 bump: v0.43.0's modules/compose
  changed DockerContainer.MappedPort's signature (nat.Port -> string),
  which is incompatible with go-sdk-contrib/tests/flagd/v2@v2.0.2's
  testframework (pinned, no newer version exists) and broke
  `go vet`/`go test` compilation in test/integration (go build alone
  didn't catch it since _test.go files aren't compiled by `go build`).
  Reverted testcontainers-go and testcontainers-go/modules/compose to
  v0.41.0 (API-compatible) while keeping the already-patched transitive
  containerd/containerd/v2 v2.2.5 and other bumps pinned via explicit
  go.mod requires, so alerts #189, #192-#196 remain resolved without
  reintroducing the vulnerable containerd version.
- Add ReadTimeout to the flagd-proxy metrics server's http.Server per
  CodeRabbit review feedback on this PR: ReadHeaderTimeout alone only
  bounds header parsing, leaving the plain HTTP/h2c port open to
  slow-client (Slowloris-style) resource exhaustion.

Still unresolvable: github.com/docker/docker (alerts #151, #152, #184,
#185, #186) remains at v28.5.2+incompatible in test/integration. No
version >= 28.5.2 (including the advisory's referenced 29.3.1 for
alert #152) is published under the legacy github.com/docker/docker
import path in the Go module proxy; moby now ships new majors under
github.com/moby/moby/v2, which this module graph cannot switch to
without deeper dependency surgery.

Signed-off-by: Jonathan Norris <jonathan.norris@dynatrace.com>
toddbaert added a commit that referenced this pull request Jul 20, 2026
## Summary

Resolves all cleanly patchable open Dependabot security alerts (28 of
33). The remaining 5 have no available patched version for their legacy
import path — see below.

## Dependabot Alerts Resolved

| Alert | Package | Severity | Fix |
|-------|---------|----------|-----|
| #260 | `github.com/sigstore/sigstore-go` | **medium** | Bumped to
v1.2.2 in `test/integration` |
| #247-#259 (13 alerts) | `golang.org/x/crypto` |
**critical/high/medium** | Already resolved on `main` (v0.52.0+);
carried through the rebase |
| #207 | `js-yaml` | **medium** | Bumped to `^4.2.0` in `playground-app`
|
| #206, #202, #201 | `golang.org/x/net` | **medium** | Bumped to
v0.55.0/v0.56.0 across `flagd`, `core`, `flagd-proxy`,
`test/integration`, and related test modules |
| #200, #199 | `vite` | **medium/high** | Bumped to `^6.4.3` in
`playground-app` |
| #197 | `@babel/core` | **low** | Forced `>=7.29.6` via npm override in
`playground-app` |
| #189, #192-#196 | `github.com/containerd/containerd/v2` |
**high/medium** | Bumped to v2.2.5 in `test/integration` (kept on
`testcontainers-go` v0.41.0 — see note below) |
| #190 | `js-cookie` | **high** | Forced `>=3.0.7` via npm override in
`playground-app` |

**Note on containerd fix:** an earlier revision of this branch bumped
`testcontainers-go` to v0.43.0 to reach patched `containerd/v2`, but
that also changed `DockerContainer.MappedPort`'s signature in a way
that's incompatible with `go-sdk-contrib/tests/flagd/v2@v2.0.2` (pinned;
no newer version exists) — breaking `go vet`/`go test` compilation in
`test/integration` (not caught by `go build` alone, since it doesn't
compile `_test.go` files). Reverted `testcontainers-go` to v0.41.0
(API-compatible) while keeping `containerd/containerd/v2` pinned at
v2.2.5 via an explicit `go.mod` require — standard Go MVS, no `replace`
directive needed.

## Unresolvable Alerts

**`github.com/docker/docker`** (#151, #152, #184, #185, #186) in
`test/integration`: pinned at `v28.5.2+incompatible`. No version ≥ that
(including the advisory's referenced `v29.3.1` for #152) exists under
the legacy `github.com/docker/docker` import path in the Go module proxy
— moby now ships new majors under `github.com/moby/moby/v2`. Transitive
dependency of testcontainers/buildx/compose; unresolvable until those
upstreams migrate.

| Alert | Package | Severity | Reason |
|-------|---------|----------|--------|
| #186 | `github.com/docker/docker` | **high** | No patched version in
Go module proxy |
| #185 | `github.com/docker/docker` | **medium** | No patched version in
Go module proxy |
| #184 | `github.com/docker/docker` | **high** | No patched version in
Go module proxy |
| #152 | `github.com/docker/docker` | **high** | Advisory's patched
version (29.3.1) not published for this import path |
| #151 | `github.com/docker/docker` | **medium** | No patched version in
Go module proxy |

## Other changes

- Added `ReadTimeout` to the flagd-proxy metrics server's `http.Server`
(`flagd-proxy/pkg/service/server.go`) per CodeRabbit review feedback,
hardening the plain HTTP/h2c port against slow-client resource
exhaustion.

## Verification

- `make test`, `make build`, and `go vet` pass across all Go modules
(`core`, `flagd`, `flagd-proxy`, `flagd-proxy/tests/loadtest`,
`test/zero-downtime-flagd-proxy`).
- `test/integration`: `go build ./...`, `go vet ./...`, and `go test`
(compile-only; actual container run needs a Docker daemon) all pass.
- `playground-app`: `npm run build` succeeds; `npm install
--package-lock-only --dry-run` reports up to date.

---------

Signed-off-by: Jonathan Norris <jonathan.norris@dynatrace.com>
Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
Co-authored-by: Todd Baert <todd.baert@dynatrace.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants