Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New component: syslog exporter #17982

Closed
2 tasks
rnishtala-sumo opened this issue Jan 24, 2023 · 11 comments
Closed
2 tasks

New component: syslog exporter #17982

rnishtala-sumo opened this issue Jan 24, 2023 · 11 comments
Labels
Accepted Component New component has been sponsored Stale

Comments

@rnishtala-sumo
Copy link
Contributor

rnishtala-sumo commented Jan 24, 2023

The purpose and use-cases of the new component

In order to send messages from a device to a remote syslog server, one needs a syslog agent. Most Linux operating systems ship with a syslog agent and if one is not available, one can be easily installed. The two most common syslog agents used on Linux systems today are rsyslog and syslog-ng

The syslog protocol is the standard for remote message logging. Syslog agents are flexible enough to handle more than just logs messages, for example monitoring configuration files, JSON files, and SNMP traps.

OpenTelemetry seems to already have a syslog receiver, a syslog exporter/forwarder would be useful to send messages to a third party syslog server.

Example configuration for the component

  • endpoint (address of the syslog server (default: 127.0.0.1))
  • transport (transport to use (tcp|udp) (default: udp))
  • port (514/1514)
extensions:
  file_storage/syslog:
    #directory: /var/lib/storage/syslog
    directory: /tmp/otc
    timeout: 10s

exporters:
  syslog:
    protocol: tcp
    port: 514
    endpoint: 127.0.0.1

    # for below described queueing and retry related configuration please refer to:
    # https://github.com/open-telemetry/opentelemetry-collector/blob/main/exporter/exporterhelper/README.md#configuration
    retry_on_failure:
      # default = true
      enabled: true
      # time to wait after the first failure before retrying;
      # ignored if enabled is false, default = 5s
      initial_interval: 10s
      # is the upper bound on backoff; ignored if enabled is false, default = 30s
      max_interval: 40s
      # is the maximum amount of time spent trying to send a batch;
      # ignored if enabled is false, default = 120s
      max_elapsed_time: 150s

    sending_queue:
      # default = false
      enabled: true
      # number of consumers that dequeue batches; ignored if enabled is false,
      # default = 10
      num_consumers: 20
      # when set, enables persistence and uses the component specified as a storage extension for the persistent queue
      # make sure to configure and add a `file_storage` extension in `service.extensions`.
      # default = None
      storage: file_storage/syslog
      # maximum number of batches kept in memory before data;
      # ignored if enabled is false, default = 5000
      #
      # user should calculate this as num_seconds * requests_per_second where:
      # num_seconds is the number of seconds to buffer in case of a backend outage,
      # requests_per_second is the average number of requests per seconds.
      queue_size: 10000
receivers:
  filelog:
    start_at: beginning
    include:
    - /other/path/**/*.txt

service:
  telemetry:
      logs:
        level: "debug"
  extensions:
    - file_storage/syslog
  pipelines:
    logs:
      receivers: 
        - filelog
      exporters:
        - syslog

Telemetry data types supported

  • Messages in syslog format (RFC5424)

Is this a vendor-specific component?

  • This is a vendor-specific component
  • If this is a vendor-specific component, I am proposing to contribute this as a representative of the vendor.

Sponsor (optional)

No response

Additional context

No response

@rnishtala-sumo rnishtala-sumo added the needs triage New item requiring triage label Jan 24, 2023
@atoulme atoulme added Sponsor Needed New component seeking sponsor and removed needs triage New item requiring triage labels Jan 24, 2023
@rnishtala-sumo
Copy link
Contributor Author

Hello there, one of our customers want the syslog exporter/forwarder for otel and contributing this to upstream seemed like the way to go. Please let me know any initial thoughts/suggestions and interest in being a sponsor.

@atoulme
Copy link
Contributor

atoulme commented Jan 27, 2023

Thank you for your interest. Please bring this to the next SIG meeting for discussion and to find a sponsor. Feel free to engage on the CNCF slack as well. Please see this document to participate in the SIG meeting: https://docs.google.com/document/d/1r2JC5MB7GupCE7N32EwGEXs9V_YIsPgoFiLP4VWVMkE/edit

@djaglowski
Copy link
Member

This is an interesting proposal and would likely be a valuable addition to the collector. However, I have a few questions:

  • Will this support the same protocols as the syslog receiver, namely rfc3164 and rfc5424?
  • What is the mapping from OTel's log data model to syslog? I expect this would vary by rfc protocol.
  • Are you willing to ensure compatibility with the syslog receiver? This may involve making sensible updates to that receiver as necessary to ensure we are able to use the collector as a syslog forwarder. That is, we will need to ensure that the exporter & receiver have equivalent capabilities and can preserve data integrity when used together.

@andrzej-stencel
Copy link
Member

Will this support the same protocols as the syslog receiver, namely rfc3164 and rfc5424?

Yes, this is the intended outcome.

What is the mapping from OTel's log data model to syslog? I expect this would vary by rfc protocol.
Are you willing to ensure compatibility with the syslog receiver?

Yes, we want to ensure compatibility with the Syslog receiver. The assumption is that data ingested with the Syslog receiver can be exported by the Syslog exporter and that the exporter's output is equal to the receiver's input (assuming both use the same syslog protocol, for example both use rfc3164). I suppose this covers what you describe as "using the collector as syslog forwarder", right? I agree that this requires that both Syslog receiver and exporter evolve in sync.

@rnishtala-sumo please keep me honest here.

@djaglowski
Copy link
Member

I suppose this covers what you describe as "using the collector as syslog forwarder", right?

👍 You said it much better than I did.

@djaglowski
Copy link
Member

I'm willing to sponsor this based on @astencel-sumo's responses.

@djaglowski djaglowski added Accepted Component New component has been sponsored and removed Sponsor Needed New component seeking sponsor labels Feb 8, 2023
@github-actions
Copy link
Contributor

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

@github-actions
Copy link
Contributor

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

@github-actions github-actions bot added the Stale label Jun 12, 2023
@djaglowski
Copy link
Member

Closed by #19647

@oppokui
Copy link

oppokui commented Jan 24, 2024

How can I forward kubernetes pod logs to syslog exporter? The k8s log is not syslog format.

I tried the following pipeline, it didn't work. I didn't find any syslog processor or formatter too.

    exporters:
      syslog:
        endpoint: 23.21.46.218
        network: udp
        port: 5140
        protocol: rfc5424
        retry_on_failure:
          enabled: true
          initial_interval: 10s
          max_elapsed_time: 150s
          max_interval: 40s
        sending_queue:
          enabled: true
          num_consumers: 20
          queue_size: 10000
        timeout: 1s
    receivers:
      filelog:
        exclude: []
        include:
        - /var/log/pods/*/*/*.log
        include_file_name: false
        include_file_path: true
    service:
      extensions: {}
      pipelines:
        logs:
          exporters:
          - syslog
          receivers:
          - filelog

Any suggestion?

@atoulme
Copy link
Contributor

atoulme commented Jan 24, 2024

Please open a new issue and describe what didn't work. Please attach logs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Accepted Component New component has been sponsored Stale
Projects
None yet
Development

No branches or pull requests

5 participants