Specifying "server_attributes"

[Stephan202]

When using the Scalyr Agent, in /etc/scalyr-agent-2/agent.json one can define zero or more server_attributes. After a cursory inspection of the scalyr-logback implementation it seems to me this project does not provide equivalent functionality. Did I perhaps miss this, or would it be possible to add such support? For example, the logstash-logback-encoder allows one to configure "Global Custom Fields" inside logback.xml; that's exactly the kind of thing I'm looking for.

[steve-scalyr]

When initializing the Scalyr library, try adding an EventAttributes argument to the Events.init call: Events.init("...API key...", maxBufferRam, null, new EventAttributes("field1", "value1", "field2", "value2", ...) ); This argument functions in the same way as the agent's server_attributes. Cheers, Steve

…

On Sun, Mar 19, 2017 at 7:30 AM, Stephan Schroevers < ***@***.***> wrote: When using the Scalyr Agent, in /etc/scalyr-agent-2/agent.json one can define zero or more server_attributes. After a cursory inspection of the scalyr-logback implementation it seems to me this project does not provide equivalent functionality. Did I perhaps miss this, or would it be possible to add such support? For example, the logstash-logback-encoder <https://github.com/logstash/logstash-logback-encoder> allows one to configure "Global Custom Fields" inside logback.xml; that's exactly the kind of thing I'm looking for. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABDJehHoS0efYPFN3Ym15KAPOISWaFaEks5rnTvzgaJpZM4Mhv_B> .

[Stephan202]

@steve-scalyr, thanks, that works. Though it does mean duplicating the API key etc. inside the code, at a point before Logback is initialized. (The settings specified in logback.xml will basically be ignored, because second and subsequent calls to Events#init are NO-OPs.)

I'm not so familiar with the Logback internals, but I might try to contribute config-level support for this feature. Would you guys be interested? Also, for us to switch to this appender we'd need some of the functionality proposed in #6; are there plans that get that PR or something equivalent merged?

[steve-scalyr]

Yes, it would be great to have configuration support for server attributes – if you'd like to contribute that, we'd be happy to merge it. Thanks! #6 <#6> has some nice features, but since it changes existing behavior, it probably needs to be tweaked to make the new features optional. I'm not sure why the PR has been languishing. Cheers, Steve

…

On Sun, Mar 19, 2017 at 9:01 AM, Stephan Schroevers < ***@***.***> wrote: @steve-scalyr <https://github.com/steve-scalyr>, thanks, that works. Though it does mean duplicating the API key etc. inside the code, at a point before Logback is initialized. (The settings specified in logback.xml will basically be ignored, because second and subsequent calls to Events#init are NO-OPs.) I'm not so familiar with the Logback internals, but I might try to contribute config-level support for this feature. Would you guys be interested? Also, for us to switch to this appender we'd need some of the functionality proposed in #6 <#6>; are there plans that get that PR or something equivalent merged? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABDJeqEN7eimNROhX6vqJqhaqhxCpmccks5rnVFLgaJpZM4Mhv_B> .