mirror of
https://github.com/fleetdm/fleet
synced 2026-05-24 09:28:54 +00:00
aaac4b1dfe
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #38889 PLEASE READ BELOW before looking at file changes Before converting individual files/packages to slog, we generally need to make these 2 changes to make the conversion easier: - Replace uses of `kitlog.With` since they are not fully compatible with our kitlog adapter - Directly use the kitlog adapter logger type instead of the kitlog interface, which will let us have direct access to the underlying slog logger: `*logging.Logger` Note: that I did not replace absolutely all uses of `kitlog.Logger`, but I did remove all uses of `kitlog.With` except for these due to complexity: - server/logging/filesystem.go and the other log writers (webhook, firehose, kinesis, lambda, pubsub, nats) - server/datastore/mysql/nanomdm_storage.go (adapter pattern) - server/vulnerabilities/nvd/* (cascades to CLI tools) - server/service/osquery_utils/queries.go (callback type signatures cascade broadly) - cmd/maintained-apps/ (standalone, so can be transitioned later all at once) Most of the changes in this PR follow these patterns: - `kitlog.Logger` type → `*logging.Logger` - `kitlog.With(logger, ...)` → `logger.With(...)` - `kitlog.NewNopLogger() → logging.NewNopLogger()`, including similar variations such as `logging.NewLogfmtLogger(w)` and `logging.NewJSONLogger(w)` - removed many now-unused kitlog imports Unique changes that the PR review should focus on: - server/platform/logging/kitlog_adapter.go: Core adapter changes - server/platform/logging/logging.go: New convenience functions - server/service/integration_logger_test.go: Test changes for slog # Checklist for submitter If some of the following don't apply, delete the relevant line. - [x] Changes file added for user-visible changes in `changes/`, `orbit/changes/` or `ee/fleetd-chrome/changes`. - Was added in previous PR ## Testing - [x] Added/updated automated tests - [x] QA'd all new/changed functionality manually <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Refactor** * Migrated the codebase to a unified internal structured logging system for more consistent, reliable logs and observability. * No user-facing functionality changed; runtime behavior and APIs remain compatible. * **Tests** * Updated tests to use the new logging helpers to ensure consistent test logging and validation. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|---|---|---|
| .. | ||
| README.md | ||
| schedule.go | ||
| schedule_test.go | ||
| testing_utils.go | ||
schedule: the Fleet cron job machinery
Fleet has several pieces of functionality that are implemented as cron jobs, which run on a
schedule. Package schedule implements the machinery needed for queueing and running these jobs.
List of cron jobs
See server/fleet/cron_schedules.go for a list of the currently implemented cron jobs and information about what they do.
Cron jobs are created and registered in the cmd/fleet package because they have to be run at
server start. The actual implementation of the cron job logic is usually elsewhere however,
typically in a service layer method (and related datastore methods).
How to add a new cron job
See this PR for a nice example of how to add a simple cron job.
- Do you need a new cron job? You can add sub-jobs to an existing cron job; for example, if
you're adding some functionality for cleaning up unused data, you might want to implement it as a
sub-job in the
cleanups_then_aggregationcron. - Add a cron job name. If you determine that you do need a new cron job, create a descriptive name in cron_schedules.go. Make sure you leave a comment explaining what the job does.
- Implement your functionality. Do this wherever it makes sense. In the example PR, the
functionality exists in the
server/mdm/maintainedapps/ingest.gofile. However, you'll most likely implement a service layer method and related datastore layer methods. - Add a function that returns a
*schedule.Scheduleincmd/fleet/cron.go. This function will be used to register your cron job so it can actually run. This function should call whatever you implemented in step 3. This is also where you can set the interval on which your cron job will run. - Register the cron job in
cmd/fleet/serve.go. You'll usecronSchedules.StartCronScheduleto register the cron job by passing it an anonymous function that calls the function you wrote in step 3.