|
| 1 | +# Advanced Filtering for Kubewatch |
| 2 | + |
| 3 | +## Overview |
| 4 | + |
| 5 | +The advanced filtering feature allows Kubewatch to filter out irrelevant Kubernetes events before sending them to Robusta, significantly reducing the performance impact on the Robusta system. This feature is particularly useful when monitoring large Kubernetes clusters where many events are generated but only a subset are actually relevant. |
| 6 | + |
| 7 | +## Configuration |
| 8 | + |
| 9 | +The filtering mechanism is controlled via the environment variable `ADVANCED_FILTERS`: |
| 10 | + |
| 11 | +```bash |
| 12 | +export ADVANCED_FILTERS=true # Enable advanced filtering |
| 13 | +export ADVANCED_FILTERS=false # Disable advanced filtering (default) |
| 14 | +``` |
| 15 | + |
| 16 | +When not set, the feature defaults to `false` (disabled), maintaining backward compatibility. |
| 17 | + |
| 18 | +## Filtering Rules |
| 19 | + |
| 20 | +When advanced filtering is enabled, the following rules are applied: |
| 21 | + |
| 22 | +### Event Resources (api/v1/Event and events.k8s.io/v1/Event) |
| 23 | + |
| 24 | +- **Sent**: |
| 25 | + - Warning events that are Created |
| 26 | + - Any event with Reason "Evicted" (regardless of Type - Normal or Warning) |
| 27 | +- **Filtered**: |
| 28 | + - Normal events (unless Reason is "Evicted") |
| 29 | + - Warning events with Update or Delete operations |
| 30 | + |
| 31 | +### Job Resources |
| 32 | + |
| 33 | +- **Always Sent**: |
| 34 | + - Create events |
| 35 | + - Delete events |
| 36 | + |
| 37 | +- **Conditionally Sent** (Update events): |
| 38 | + - When the Job spec changes |
| 39 | + - When the Job fails (status condition contains "Failed") |
| 40 | + |
| 41 | +- **Filtered**: Update events without spec changes or failures |
| 42 | + |
| 43 | +### Pod Resources |
| 44 | + |
| 45 | +- **Always Sent**: |
| 46 | + - Create events |
| 47 | + - Delete events |
| 48 | + |
| 49 | +- **Conditionally Sent** (Update events): |
| 50 | + - When the Pod spec changes |
| 51 | + - When any container (including init containers) has restartCount > 0 |
| 52 | + - When any container is waiting with reason "ImagePullBackOff" |
| 53 | + - When the Pod is evicted |
| 54 | + - When any container is terminated with reason "OOMKilled" |
| 55 | + |
| 56 | +- **Filtered**: Update events without any of the above conditions |
| 57 | + |
| 58 | +### All Other Resources |
| 59 | + |
| 60 | +All events for resources not explicitly mentioned above (e.g., Deployments, Services, ConfigMaps, etc.) are sent without filtering. |
| 61 | + |
| 62 | +## Implementation Details |
| 63 | + |
| 64 | +The filtering logic is implemented in the `pkg/filter` package and integrated into the CloudEvent handler. The filter evaluates each event before it's sent to Robusta, checking the resource type and event characteristics against the defined rules. |
| 65 | + |
| 66 | +### Key Components: |
| 67 | + |
| 68 | +1. **Filter Package** (`pkg/filter/filter.go`): Contains the core filtering logic |
| 69 | +2. **CloudEvent Handler Integration**: The filter is initialized and used in the CloudEvent handler |
| 70 | +3. **Environment Variable**: `ADVANCED_FILTERS` controls whether filtering is active |
| 71 | + |
| 72 | +## Usage Example |
| 73 | + |
| 74 | +### Kubernetes Deployment |
| 75 | + |
| 76 | +```yaml |
| 77 | +apiVersion: apps/v1 |
| 78 | +kind: Deployment |
| 79 | +metadata: |
| 80 | + name: kubewatch |
| 81 | +spec: |
| 82 | + template: |
| 83 | + spec: |
| 84 | + containers: |
| 85 | + - name: kubewatch |
| 86 | + image: kubewatch:latest |
| 87 | + env: |
| 88 | + - name: ADVANCED_FILTERS |
| 89 | + value: "true" |
| 90 | + - name: KW_CLOUDEVENT_URL |
| 91 | + value: "https://your-robusta-endpoint" |
| 92 | +``` |
| 93 | +
|
| 94 | +### Docker Run |
| 95 | +
|
| 96 | +```bash |
| 97 | +docker run -d \ |
| 98 | + -e ADVANCED_FILTERS=true \ |
| 99 | + -e KW_CLOUDEVENT_URL=https://your-robusta-endpoint \ |
| 100 | + kubewatch:latest |
| 101 | +``` |
| 102 | + |
| 103 | +## Testing |
| 104 | + |
| 105 | +To run the filter tests: |
| 106 | + |
| 107 | +```bash |
| 108 | +cd pkg/filter |
| 109 | +go test -v |
| 110 | +``` |
| 111 | + |
| 112 | +## Performance Impact |
| 113 | + |
| 114 | +With advanced filtering enabled, you can expect: |
| 115 | + |
| 116 | +- **Reduced Network Traffic**: Fewer events sent to Robusta |
| 117 | +- **Lower CPU/Memory Usage**: Robusta processes fewer irrelevant events |
| 118 | +- **Improved Signal-to-Noise Ratio**: Only meaningful events are forwarded |
| 119 | + |
| 120 | +## Debugging |
| 121 | + |
| 122 | +When debugging is enabled (log level set to debug), filtered events are logged with details about why they were filtered: |
| 123 | + |
| 124 | +``` |
| 125 | +DEBU[0001] Filtering out Event resource - type: Normal (only Warning events are sent) |
| 126 | +DEBU[0002] Filtering out Pod update event - no significant changes detected |
| 127 | +``` |
| 128 | + |
| 129 | +## Migration Guide |
| 130 | + |
| 131 | +1. **Test in Development**: Enable filtering in a development environment first |
| 132 | +2. **Monitor Metrics**: Compare the number of events before and after enabling filtering |
| 133 | +3. **Gradual Rollout**: Enable filtering on a subset of Kubewatch instances before full deployment |
| 134 | +4. **Verify Coverage**: Ensure important events are still being captured |
| 135 | + |
| 136 | +## Troubleshooting |
| 137 | + |
| 138 | +### Events Not Being Received |
| 139 | + |
| 140 | +If expected events are not reaching Robusta after enabling filtering: |
| 141 | + |
| 142 | +1. Check the ADVANCED_FILTERS environment variable is set correctly |
| 143 | +2. Review the filtering rules to ensure your use case is covered |
| 144 | +3. Enable debug logging to see which events are being filtered |
| 145 | +4. Temporarily disable filtering to confirm it's the cause |
| 146 | + |
| 147 | +### All Events Still Being Sent |
| 148 | + |
| 149 | +If filtering appears to have no effect: |
| 150 | + |
| 151 | +1. Verify ADVANCED_FILTERS is set to "true" (string value) |
| 152 | +2. Check Kubewatch logs for "Advanced filtering is ENABLED" message |
| 153 | +3. Ensure you're using the CloudEvent handler (filtering only works with CloudEvent handler) |
| 154 | + |
| 155 | +## Future Enhancements |
| 156 | + |
| 157 | +Potential improvements to the filtering system: |
| 158 | + |
| 159 | +- Configurable filtering rules via configuration file |
| 160 | +- Per-resource-type filtering toggles |
| 161 | +- Custom filtering expressions |
| 162 | +- Filtering statistics and metrics |
0 commit comments