feat: new logging type customOutputs #229
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…monitoring type This is a set of changes that allow the monitoring stack to be configured to send metrics to a remote Prometheus receiver, both with our current Prometheus monitoring type and with a new PrometheusAgent type that deploys a more minimal Prometheus intallation only for scraping and sending metrics. - Add `remoteWrite` section to prometheus' configuration in the scheam, so Prometheus can be set up to send metrics to a remote receiver. - Add prometheusAgent as monitoring type, as an alternative to prometheus+remoteWrite, allowing to have a "minimal" monitoring stack capable of sending metrics to a remote Prometheus receiver. Notice that this mode does not allow for querying the local Prometheus instance (so no local Grafana dashboards) or having local alerting set up. - Add migrations for switching between Prometheus and Prometheus Agent, and to and from `none`. - Update documentation with the new features
add a new customOutputs logging type that allows to choose where to ship the logs via setting the .spec field of the Output and ClusterOutput objects instead of harcoding them to Loki or OpenSearch. - added new type to the schema - added new customOutputs field to the spec.distribution.modules.logging field with options to configure the outputs - added new constraints to the schema - updated the schema docs - updated kustomize base for logging - added migrations for the new logging type
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Important
This PR is branched from the #228 one because there were changes to the same files, so I branched from there to avoid conflicts.
You will see changes from the PR #228 included in this one until the PR #228 is merged.
Intro
This is a set of changes that introduce a new
customOutputslogging type that allows configuring the Logging stack to ship the logs to a custom (remote or not) server instead of sending them to a local OpenSearch or Loki deployment.This new type still has the advantages of a out-of-the box integration with the rest of the distribution and sane defaults, so all logs will be scraped as before with the same logical separation (infra, ingress, kubernets, etcd, etc., i.e.
Flows). The user needs to specify theOutputandClusterOutputsspecs via new configuration options in the furyctl.yaml file and the rest will be taken care of.Changes in this PR
customOutputslogging type to the schemaspec.distribution.modules.logging.customOutputssection for the needed fields (one for eachOutputandClusterOutputspec) to configure the new type.{loki, opensearch, none} <-> customOutputs).fixes https://github.com/sighupio/product-management/issues/496