Uploaded image for project: 'OpenShift Logging'
  1. OpenShift Logging
  2. LOG-2904

[spike] Investigate vector changes required to enable forwarding to syslog

XMLWordPrintable

    • Log Collection - Sprint 223, Log Collection - Sprint 224

      Summary

      Review vector's open issue related to implementing forwarding to syslog and determine:

      • the state of affairs
      • is there a place for us to contribute

      Acceptance Criteria

      • Summarize syslog findings
      • Create JIRA cards for follow-on work

      Notes

      • There is a syslog source, built on top of a syslog parser crate, which also includes a syslog serializer, which can be used in the new syslog sink
      • There're traits and impls ("base classes") for different types of sinks. The one most closely fitting what the syslog sink needs is SocketSink.
      • The https://issues.redhat.com/browse/LOG-2914 epic carries the follow-up stories for this spike.

            [LOG-2904] [spike] Investigate vector changes required to enable forwarding to syslog

            Aleksandar Lazic added a comment -

            syedriko_sub@redhat.com that sounds quite good, thank for the information.

            Aleksandar Lazic added a comment - syedriko_sub@redhat.com that sounds quite good, thank for the information.

            Sergey Yedrikov added a comment -

            alazic@redhat.com The current thinking is that the syslog sink will be based on the socket sink and will inherit socket's TLS configuration: https://vector.dev/docs/reference/configuration/sinks/socket/#tls. It does allow for a custom CA, via the ca_file variable.

            Sergey Yedrikov added a comment - alazic@redhat.com The current thinking is that the syslog sink will be based on the socket sink and will inherit socket's TLS configuration: https://vector.dev/docs/reference/configuration/sinks/socket/#tls. It does allow for a custom CA, via the ca_file variable.

            Aleksandar Lazic added a comment -

            Hi. It would be very nice to have options to define a secret for customers Certificate Authority, is there such a concept in Vector to have own Certificate Authoritys for TLS connections?

            We have such a config in the current logging setup, for example.

            outputs:
  - name: out-syslog
    secret:
      name: siem-ca
    syslog:
      facility: local1
      rfc: RFC3164
      severity: info
    type: syslog
    url: tls://syslog01.isec.domain.com:1999

            Aleksandar Lazic added a comment - Hi. It would be very nice to have options to define a secret for customers Certificate Authority, is there such a concept in Vector to have own Certificate Authoritys for TLS connections? We have such a config in the current logging setup, for example. outputs: - name: out-syslog secret: name: siem-ca syslog: facility: local1 rfc: RFC3164 severity: info type: syslog url: tls: //syslog01.isec.domain.com:1999

            Sergey Yedrikov added a comment -

            Sergey Yedrikov added a comment -

            Jeffrey Cantrill added a comment -

            syedriko_sub@redhat.com one issue to consider is our existing API which allows for 2 different RFC specs. Assuming we can get syslog impl in vector, it may be that we do not have feature parity (nor want) with fluentd in this regard. We need to support our syslog option as best as possible and drop anything that otherwise does not make sense

            Jeffrey Cantrill added a comment - syedriko_sub@redhat.com one issue to consider is our existing API which allows for 2 different RFC specs. Assuming we can get syslog impl in vector, it may be that we do not have feature parity (nor want) with fluentd in this regard. We need to support our syslog option as best as possible and drop anything that otherwise does not make sense

              syedriko_sub@redhat.com Sergey Yedrikov
              jcantril@redhat.com Jeffrey Cantrill
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: