-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Add support for environment variable injection in logstash plugin configuration #3944
Comments
As a workaround, you can use a template tool (m4, sed, etc) to achieve On Sunday, September 20, 2015, Fabien Baligand notifications@github.com
|
Thanks for your reply @jordansissel. |
Given the robustness of logstash configuration files I am a bit surprised there is not a cleaner way to do this. All of our logstash instances are containerized within Docker, getting our various containers to talk to eachother is done via Docker's container linking.. they provide you with some environmental variables so your containers can find each other. That said, even if something like M4 was suitable for configuration preprocessing in a grammar as expressive as logstash's (it isn't) .. it would be difficult (messy at best) to hook the preprocessor into the various container deployment and orchestration systems. Your containers will be expected to be built ahead of time and be environment agnostic. Typically getting all the context they need at runtime from the environment variables. @fbaligand The solution I have today uses the environment filter, but it is not ideal because it is including all of the environment vars in the message. Maybe you found a better way? filter {
...
environment {
add_field_from_env => {
"MY_ENV_ADDR" => "MY_ENV_PROD_PORT_12285_TCP_ADDR"
"MY_ENV_PORT" => "MY_ENV_PROD_PORT_12285_TCP_PORT"
}
}
}
...
output {
http {
codec => "json"
http_method => "post"
url => "http://%{MY_ENV_ADDR}:%{MY_ENV_PORT}/..."
}
} Is there a way to specify local fields i.e.: not to be included in final output, but used for transit through the pipeline? Or maybe there is a syntax for defining fields to namespace them? There might be a way to do what I am trying to do in the logstash world, just haven't found it. I did notice in grok there is a more robust declaration grammar for property access, I.E.: %{SYNTAX:SEMANTIC:CAST} .. I could see something like %{[NAMESPACE :]FIELD_NAME} being pretty useful and backwards compatibility being maintained. Could provide a few default namespacs like ENV, LOCAL.. and anything else useful. Example below: filter {
...
mutate {
add_field => {
"LOCAL:SCHEMA" => "https" # Not included in output
"LOCAL:VAR_NAME" => "LOCAL_VALUE" # Not included in output
"GLOBAL_ENV_ADDR" => "%{ENV:ADD_TO_ALL}" # Included in output
"GLOBAL_NAME" => "GLOBAL_VALUE" # Included in output
}
}
}
...
output {
if [LOCAL:VARNAME] ... {
http {
codec => "json"
http_method => "post"
url => "%{LOCAL:SCHEMA}://%{ENV:MY_ENV_PROD_PORT_12285_TCP_ADDR}:%{ENV:MY_ENV_PROD_PORT_12285_TCP_PORT}/..."
}
}
} Just food for thought. Thanks. -Chris |
@cstockton this is an argument in favor of having the environment filter put all of those variables into the |
@cstockton and @fbaligand - Could you review logstash-plugins/logstash-filter-environment#5 and let us know what you think? |
@cstockton and @fbaligand - I think @jordansissel meant logstash-plugins/logstash-filter-environment#5 (the pull request) |
lol, failure on my part. Good catch, @untergeek ! |
environment plugin is useful for some cases, but not for all. That's why a native env variable injection pre-processing in logstash would be very welcome ! |
Regarding environment plugin enhancement (using @metadata), this sounds to me as an excellent idea ! |
thanks a lot @jordansissel this certainly fixes my use case, I responded with a little feedback in addition at logstash-plugins/logstash-filter-environment#5 (comment) |
Thanks for the improvement in environment plugin @untergeek ! Regarding this issue now, it's still relevant to address all cases that are not covered by environment plugin (input plugin properties, int plugin properties, and all plugin properties that do not support dynamic field injection). |
@fbaligand That is a good point, I could see input plugins needing access to environmental variables for setting up listeners. I think it would be pretty clean to denote
|
That's an interesting option !
|
the I'm still not really in favor of this yet since m4/puppet/etc seems so simple to me. I don't want to dump this as something we force ops folks to solve, but I'm also not sure about the added burdens of additional syntax in the config file. Carry this knowing that we are working on clustering and other concepts for logstash that will outlive the lifetime of a single logstash-process, so in the clustered world, configuring via environment variables feels quite weird. I think it's weird because I really want configuration with one interface, not multiple, and with clustering, the configuration comes from some central authority, and using environment variables complicates that - who evaluates the env vars? Each node? Just the central authority? If each node, now you have two sources of configuration instead of just one. Thoughts? |
@jordansissel To take example from spring or log4j 2, both of them support multiple sources when resolving |
I see where you are going with that @jordansissel .. I am not sure what kind of architecture would stay up to speed as logstash grows. The first thing to pop into my head would be some sort of "variable/field" providers. Then you could create etcd, environment, or even a swagger api provider. Given the fact that variable providers would be a form of input, maybe it could be done via inputs.. I don't know anything about the plugin systems API but maybe it would be robust enough already to do this through plugins today. Below is an example of something that would be pretty nice for me with the disclaimer that I've only been working with logstash for a few weeks.. so it may not be idiomatic or align at all with logstash's long term goals/vision so sorry in advance if it's some sort of butchery :p I.E. input {
env { }
etcd { prefix => "_ETCD", url => "http://%{ETCD_ADDR}:%{ETCD_PORT}/v2/keys", ttl => 60 } # ETCD_ADDR is from environment, no prefix
syslog { port => "%{_ETCD_SYSLOG_LISTEN_PORT}" }
tcp { port => "%{_ETCD_FOO_LISTEN_PORT}" }
} The main thing is it seems that "properties / variables" throughout logstash's configuration seem to always be bound to the event. However users like me, (incorreclty perhaps?) are trying to get non-event bound static attributes resolved at compile time.. while forseeing cases where call time resolved attributes feel inevitable. There is of course other ways to achieve both of those two things though. It all depends if you think it is dirty and wrong, or glorious for someone to do this: output {
if [@metadata][product] in [_ETCD_ENABLED_PRODUCTS] {
elasticsearch { ... } } } |
I like the idea of having an
Not sure how easy it would be to add this, but to me it's either this, or make the |
Up to me, it is really easier that logstash core itself pre-process ${MYVAR} tokens just before injecting result value in the plugin property. (Using the example configuration format I put in issue) |
@suyograo @jordansissel @acchen97 @cstockton @untergeek I like very much their ability to have a default value or to support array value. |
…on in logstash plugin configuration
Chiming in to support the idea of implementing this similar to beats. |
@mikeholczer |
I understand, but it feels like this assumes your method for starting logstash is immutable, which isn't true. Your "start logstash" procedure can include generating the config before executing My general concern here is that I don't think environment variables are a good solution for this, especially when I consider the Logstash roadmap. Environment variables can only be communicated once to a given process, at the start. They can never be altered outside the process. This immutability of runtime-configuration is counter to one existing feature as well as one future feature. The existing feature is automatic configuration reloads - with reloading, you cannot ever change the environment variable even though the configuration files themselves can be changed. If you try to use environment variables for configuration settings, you will be required to do a full restart of Logstash in order to change these values. The future feature is centralized configuration (with ability to change the configuration after startup). For the same reason as config reloading that we have, today, I feel environment variable immutability will make this not valuable, or at the very least, not something most users would use (I won't speak for all users, though). Logstash is intended to be a long-running process, and with our progress towards making Logstash more configurable while running, introducing partial immutability (environment variables) feels like a step backwards. |
+1; in my use-case I'm baking an AMI separately from where the instance will actually run, so the env I need to inject ( |
Hi @jordansissel, Firstable, environment variable is a really common and standard way to parameterize servers, tools, ...
Secondary, numerous frameworks process environment variable injection ; this is a common feature. Thirdly, elasticsearch itself has this feature since a long time (https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-configuration.html#node-name). Fourth, in a first step, we could only have environment variable injection. Finally, up to me, for all these reasons, this is really a key feature and absolutely not a step backwards. |
I stumbled on this issue because I need to do exactly what @ip2k mentioned - I want to use the EC2 instance ID as a parameter for a Logstash plugin. It would be awesome if the config file supported environment var interpolations. |
#4710 is merged and supports this feature. |
Based on the implementation for environment variable injection (elastic#3944), the delimiter for the default value in sprintf interpolation is changed to ":" (KEY_NODE_DEFAULT_DELIMITER).
works with jdbc input plugin like a charm :D |
Nice :) |
It would be great to support environment variable injection in logstash configuration, like this :
It would be very useful to have a logstash configuration independent from its environment. And so, have the same logstash configuration among different environments (dev, test, prod, ...)
Numerous frameworks support such a feature like spring or log4j.
The text was updated successfully, but these errors were encountered: