Config parameters aren't passed through to the shipper output in Beats

[faec]

When ingesting through the shipper via the Beats shipper output, e.g. with a configuration like:

outputs:
  default:
    type: elasticsearch
    log_level: debug
    enabled: true
    hosts: [https://127.0.0.1:9200]
    username: "elastic"
    password: [password]
    bulk_max_size: 4096
    shipper:
      enabled: true

Agent does not pass through bulk_max_size or any other parameters except the ones it synthesizes itself. The config parameters the shipper output receives are:

type
server
ssl.certificate
ssl.key
ssl.certificate_authorities

note that type is not actually a field of the shipper output's config (though it may be used elsewhere in the pipeline). However there are several other fields that are in the shipper output config:

timeout
max_retries
bulk_max_size
ack_polling_interval
backoff.init
backoff.max

and none of these are ever set.

This issue is possibly more for discussion / awareness than an immediate fix, since we might have good reasons not to expose those settings through the agent policy, at least in production. But it also means that right now we have "configuration parameters" on the shipper output that can only be changed by rebuilding with a new hard-coded default, which at a minimum was not obvious to me when I wanted to run tests depending on bulk_max_size :-) So we might want to think about a way to safely expose the full config, at least for internal testing.

[cmacknz]

Hmm, I suspect we'd need to add a shipper section to the agent policy to let us adjust this.

The other option would be to allow changing this by editing the shipper spec file and have it take effect by restarting the agent.

[pierrehilbert]

@cmacknz / @leehinman could we close this one with the new shipper plan?

[cmacknz]

This is still relevant

[blakerouse]

I am confused? Everything under the outputs.default.* would be sent to the shippers output unit for elasticsearch.

[cmacknz]

This about configuring the internal Beat -> Shipper output and the not the Shipper -> ES/LS output. We do not expose a way to configure the internal Beat shipper output today.

[faec]

Followup to this: right now it seems like the most practical way to do this is to include the output policy in both the shipper's output unit and in the output unit of the input component that writes to the shipper. We could then define, internally to the shipper / shipper-output, a certain configuration subtree for the connection writing to the shipper, which can contain the flags discussed here (timeout, backoff, etc) and which would allow us to have advanced configuration flags that affect the Beats shipper-output during troubleshooting or debugging without having to rebuild the whole project with a new flag value. This is a relatively minor change on the Agent side, we would just need to make sure that the Beats shipper output is ready to interpret the new data properly (i.e. that it doesn't try unpacking the policy directly into its own configuration the way it does right now).

[jlind23]

Closing this as the shipper project has been revisited.
cc @ycombinator