Redis Caching & PubSub
Relevant source files
The following files were used as context for generating this wiki page:
Redis serves as a critical infrastructure component in Fleet, providing high-performance caching and real-time Publish/Subscribe (PubSub) capabilities. It is primarily utilized for managing ephemeral data such as live query results and host-specific metadata that requires frequent, low-latency access.
The system leverages Redis to offload volatile data from the primary MySQL database, ensuring that real-time operations—like monitoring live host status or processing distributed osquery results—do not impact the performance of persistent storage. Fleet supports standard Redis as well as compatible alternatives like Valkey.
Sources: articles/deploy-fleet-on-kubernetes.md, server/datastore/redis/redis.go
Live Query Results PubSub
Fleet uses Redis PubSub to handle the distribution of live query results from hosts to the requesting users. This mechanism allows the Fleet server to subscribe to specific channels corresponding to query executions and receive updates asynchronously as hosts report back.
Real-time Flow
When a live query is initiated, the server establishes a subscription to a Redis channel unique to that query ID. As hosts provide results, those results are published to the channel and forwarded to the subscriber.
The diagram shows the asynchronous flow of live query data using Redis as the message broker.
Sources: server/pubsub/redis_query_results.go:20-80
Key Structures
The live query system is encapsulated in the redisQueryResultStore struct, which maintains a connection pool to Redis.
| Component | Description |
|---|---|
redisQueryResultStore | Manages PubSub operations for live query results. |
HealthCheck | Verifies the status of the Redis connection for query results. |
QueryID | A unique identifier used as the Redis channel name. |
Sources: server/pubsub/redis_query_results.go:14-35
Host Caching
The HostCache system facilitates rapid access to host status and metadata. By caching host details in Redis, Fleet reduces the load on MySQL for frequent "check-in" operations performed by the osquery agents.
Cache Logic
The system implements a combined mysqlredis datastore where MySQL acts as the source of truth and Redis acts as a high-speed cache for specific host attributes.
Flow demonstrating the lookaside caching strategy for host metadata.
Sources: server/datastore/mysqlredis/host_cache.go:10-50
Configuration Parameters
Host caching behavior is controlled via environment variables and configuration files, particularly when deploying via Helm or Terraform.
| Parameter | Default Key | Description |
|---|---|---|
| Address | cache.address | The DNS or IP address of the Redis/Valkey instance. |
| Database | cache.database | The Redis logical database index (defaults to 0). |
| Password | redis-password | Secret key used for Redis authentication. |
Sources: articles/deploy-fleet-on-kubernetes.md
Redis Pool Management
Fleet utilizes a connection pool to manage interactions with Redis efficiently. This prevents the overhead of creating new connections for every command and ensures thread-safe operations across the server's concurrent processes.
Implementation Details
The Pool struct in the Redis package wraps a redigo pool. It provides methods for executing commands and managing the lifecycle of Redis connections.
Class relationship showing how PubSub stores utilize the underlying connection pool.
Sources: server/datastore/redis/redis.go:10-25, server/pubsub/redis_query_results.go:14-25
Connection Handling
The pool implementation handles:
- Creation: Establishing connections to the Redis endpoint.
- Validation: Ensuring connections are active before use.
- Cleanup: Properly closing connections to prevent resource leaks.
Sources: server/datastore/redis/redis.go:30-60
Static Content Build Caching
During the website build process, Fleet uses internal caching mechanisms to handle large YAML datasets, such as the Standard Query Library and Policy Library. While these are baked into the Sails app configuration, the build script simulates data gathering that mirrors Redis-like storage for contributor profiles and query metadata.
Data Processing Steps
- Read source YAML (e.g.,
docs/queries.yml). - Parse documents into JSON objects.
- Fetch and cache contributor profile data from the GitHub API.
- Inject the compiled dataset into the app's configuration (
.sailsrc).
Sources: website/scripts/build-static-content.js:35-150
Infrastructure Deployment
When deploying Fleet to Kubernetes, Redis is defined as a mandatory dependency alongside MySQL. Fleet provides sub-charts for local testing but recommends managed services for production.
Helm Configuration Example
cache:
address: fleet-cache-valkey:6379
database: "0"
usePassword: true
secretName: redis
passwordKey: redis-password
Sources: articles/deploy-fleet-on-kubernetes.md
Valkey Support
Fleet officially supports Valkey as a Redis-compatible alternative. Valkey is often used in the Fleet Helm chart to provide the caching layer due to its open-source governance.
Sources: articles/deploy-fleet-on-kubernetes.md
Summary
The Redis Caching and PubSub system is integral to Fleet's scalability. By managing live query distribution through PubSub and host metadata through caching, it ensures the platform remains responsive under heavy endpoint loads. The use of managed connection pools and flexible configuration options allows it to be deployed effectively across various environments, from local Docker setups to enterprise-grade Kubernetes clusters.