When running a support bundle, we want to know how long each operation
(collect, redact, analyze) takes. This commit adds a new trace exporter
that records the start and end times of each operation, and then prints
a summary of the execution. The summary is also stored in the support
bundle.
Related to #923
* adding dedup for in cluster collectors
* add tests
* return collector as is whenever marshalling to json fails
---------
Co-authored-by: Evans Mungai <evans@replicated.com>
introduces a new option to limit the size of a pod log when added to the bundle. This will make sure the support bundle will not grow to an unacceptable size and thus might contain information that is too old.
The maximum size of a pod log in a bundle is set by default to 5MB, and can be changed if we decide upon the need.
BREAKING CHANGE: any logs that are collected by the logs collector are now limited by default to 5MB unless a different size limit is specified. Folks expecting log files larger than that to be collected without truncation will need to adjust their support bundle specs.
Fixes: #878
* feat(redactors): Run redactors on an existing support bundle
Add redact subcommand to support-bundle to allow running redactors on an
existing bundle to creating a new redacted bundle.
The command will be launched like so
support-bundle redact <redactor urls> --bundle support-bundle.tar.gz
Fixes: #705
The symlinking logs feature led to a regression where symlinks of
unhealthy pods were overwritting logs in the support bundle. This
fix allows the cluster resources collector to instruct the logs
collector not to symlink logs, which in turn ensures logs are not
overwritten.
Fixes: #908
* add dedup for cluster resources collector
* restructure both collect.go in both pkg/supportbundle and pkg/preflight to be more similar for eventual refactor
For a postgres collector spec targeting a server configured to accept
(m)TLS connections we need to pass in the necessary parameters in order
to successfully connect to the server. Both preflight and support bundle
specs use this collector.
This change allows us to pass in the necessary TLS parameters via inlined
TLS configuration or via a secret reference.
Fixes#747
feat(collectors): Add mTLS parameters to the redis collector
For a redis collector spec targeting a redis server configured to accept
(m)TLS connections we need to pass in the necessary TLS parameters in order
to successfully connect to the server. Both preflight and support bundle
specs use this collector.
This change allows us to pass in the necessary TLS parameters via inlined
TLS configuration or via a secret reference.
Fixes#746
TL;DR
-----
Updates Sysctl collector and analyzer for virtual memory parameters
Details
-------
Adds supoort for virtual memory parameters to the Sysctl collector and
analyzers. I uncovered this writing a pre-flight for a Helm chart that
includes ECK as a subchart. Since ECK requires a specific minimum value
for `vm.max_map_count` I wanted to use the Sysctl analyzer to check for
the expected value, but wasn't able to because of the limited values it
collected. I also learned that Sonarqube expects the same parameter to
be increased, so it seemed like a general enough requirement to add it
in.
The code updates the collector to collect values under `/proc/sys/vm`
and adds tests to the analyzer to based on the ECK requirements. Making
the tests pass required adding operators to the when expression, since
the existing code only allowed for `=`, `==`, and `===`. The when
expression now supports `>`, `<`, `>=`, and `<=`.
All tests pass.
* feat(collectors): Store all pod logs in cluster-resources directory
All pod logs collected by the logs collector will now be stored in
/cluster-resources/pods/logs/[namespace]/[pod]/[container].log. This
will provide consistency and allow sbctl to find the logs when we run
`kubectl logs <pod>`. To allow backwards compatibility, symlinks of the
log files will be created in the current expected locations.
Closes: #744
This change ensures that the clusterResources collector runs prior to any others
in order to not collect info on pods that collectors run during collection.
Additionally centralizes functions that are common to all collection to make future
maintenance simpler.
Fixes: #767
Due to deprecation of the API at `policy/v1beta1` for `PodDisruptionBudgets` and `batch/v1beta1` for `CronJobs`, updated cluster_resources.go to accommodate using either apiVersion v1 & v1beta1
When troubleshooting an issue we want to see and check the `PodDisruptionBudget` for any application. As we currently do not have that 'standard' output in our support bundle, this PR serves as an implementation of providing one with an overview of `PodDisruptionBudget` on a per-namespace basis.
After creating a support bundle, the output can be reviewed by checking out `../cluster-resources/pdb/*.json`
- [Release notes](https://github.com/google/periph/releases)
updated-dependencies:
- dependency-name: periph.io/x/periph
dependency-type: direct:production
update-type: version-update:semver-minor
Module periph.io/x/periph has moved from 3.6.8 to re-arrange locations
in 3.7.2. This reworks to take advantage of the new format.
