[graylog2] Re: first pipeline attempt not working
Hey!
The static fields are not added by the input, even though the UI makes you
believe they are. In fact they are added during the filter chain execution,
which I from your description runs after the pipeline in your system.
The reason for adding the field later is that at the input level the
message is not actually decoded yet, that happens much later after it has
been journaled.
cheers,
Kay
On Tuesday, 5 July 2016 01:07:53 UTC+2, Jason Haar wrote:
>
> Hi there
>
> I'm trying to get my first pipeline working - without any luck
>
> I have checked and "pipeline processor" is #1 in "Message Processors
> Configuration", and consists of one pipeline, with one stage which contains
> one rule. The rule is
>
> rule "My little pony"
> when
> has_field("dont_like_cricket")
> then
> drop_message();
> end
>
>
> I can see on the "Pipeline overview" page that it's processing the entire
> incoming feed.
>
> What I have is a Syslog Input channel which I have the Input adding the
> field "dont_like_cricket" to every incoming record (ie tagging it as
> different from other Inputs). If I search graylog, I can see the records
> contain the field "dont_like_cricket". But this pipeline never triggers - I
> still see the records that should have been dropped.
>
> My end-game is obviously a little more complicated, but even this doesn't
> work - so 'baby steps' :-)
>
> Any ideas? Also, I really only want this pipeline on one Input channel -
> do they have to be "universal"?
>
> Thanks!
>
> --
> Cheers
>
> Jason Haar
> Information Security Manager, Trimble Navigation Ltd.
> Phone: +1 408 481 8171
> PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
>
--
You received this message because you are subscribed to the Google Groups
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/graylog2/f5985a5e-a9e3-448d-828a-3189ea4c4bd9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[graylog2] Re: Graylog (Invoking external Java Classes from graylog drl file fails with a compilation [class cannot be resolved ]
Hi! It looks like you put the Java source file onto the classpath, which doesn't work. You need to compile it as part of your build (possibly as a graylog plugin, or manually and then adding it to the classpath). The resulting file name ends with .class, not .java. The imports look good to me, but the error message and the classpath you posted indicate that this is the problem. Best regards, Kay On Thursday, 7 April 2016 08:10:12 UTC+2, rajarshi bhattacharjee wrote: > > > > On Wednesday, 6 April 2016 15:20:32 UTC+5:30, rajarshi bhattacharjee wrote: >> >> I am actually new to graylog and frankly not quite aware of how graylog >> is triggering the drools rule engine so it might be a very simple question >> with an obvious solution which is somehow escaping me . >> >> >> I am trying to improve an already existing (drl code) by invoking >> another java class , which is residing within a different directory as >> compared to my drl file. Understood that graylog doesnt allow adding other >> packages definitions( >> https://github.com/Graylog2/graylog2-server/issues/1213) , so tried with >> a direct import by putting the java class in a different directory, but >> when i try to invoke this java class my drl fails with the following >> exception `Rule Compilation error : [Rule name='BPTM logs filter'] >> org/graylog2/rules/Rule_BPTM_logs_filter508671689.java (42:2371) : >> *PropertiesCache >> cannot be resolved* >> >> 2016-04-06 09:11:09,601 WARN : org.graylog2.rules.DroolsEngine - Unable >> to add rules due to compilation errors. >> org.graylog2.rules.RulesCompilationException: Message [id=1, level=ERROR, >> path=r1.drl, line=30, column=0 >> text=Rule Compilation error PropertiesCache cannot be resolved] >> >> Note :PropertiesCache is my java class and my drl file exists in >> different directories. Pretty much its not able to resolve the import and >> fails with compilation error >> >> Any insights would be valuable , >> > > Attached DRL file , along with PropertiesCache.java file (external class i > am trying to invoke) > > Please advice , i am not sure whether this error is due to > environment/drools/or graylog restrictions as i m new to both drools and > graylog and just trying to improve this code from java perspective > -- You received this message because you are subscribed to the Google Groups "Graylog Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to graylog2+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/graylog2/49e29917-78af-40b5-9b4a-376228a665b2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[graylog2] Re: Graylog 1.1.3: Multiple Graylog Servers, API calls timing out, Cluster Falls Over
Hi Alexia! This should work exactly as you configured it, the web interface will connect to both servers in a round robin fashion. The default heap sizes should not cause long GC pauses when faced with moderate load, I doubt that this is the cause of these problems. A couple of things to check: 1) Are there any errors in the server logs? 2) Can you reach the servers via curl from the web interface machine? for both servers: curl -HAccept:application/json http://SVR2_IP_ADDRESS:12900/system/cluster/node 2a) Can you access the API browsers of either servers? They are served under /api-browser on each Graylog server node. 3) Are there any firewalls or other packet filters between the nodes? 4) Can you check the node id files on both servers to verify that they have different uuids? cheers, Kay On Monday, 16 November 2015 15:41:58 UTC+1, Alexia Golez wrote: > > Hi guys > > We have an issue with adding a Graylog server to an existing Graylog > cluster. Basically, we need to add another server to scale out our logging > capabilities. > We're doing this right now on test cluster just to understand what we have > to do in production. > > *Environment* > We have an existing Graylog cluster with the following machines: > >- Graylog web interface box >- Graylog server >- 3 Elasticsearch nodes > > > On the existing Graylog server [or svr1], ismaster=true in its > server.conf and its rest_listen_ip is set to the internal network IP of > 10.x.y.z. > The new Graylog server [svr2] that I am adding into the cluster has > ismaster=false and just like the primary Graylog server its rest_listen_ip > is set to its internal network IP. > > > *Errors* > The existing cluster was operating as expected until we added the second > server - svr2. > > When we start up svr2, the Graylog web interface server appears to see it > and on login to the Graylog admin page, I can see it registered under > System>Nodes. However, after a few minutes, svr2 drops off the Nodes page. > On checking logs of the the Graylog web interface box, I see multiple API > call failures for svr 2 and a few for svr1: > > > > 2015-11-16 13:57:03,273 - [ERROR] - from > org.graylog2.restclient.lib.ApiClient in servernodes-refresh-0 > API call failed to execute. > java.util.concurrent.ExecutionException: java.net.ConnectException: > Connection refused: /SVR2_IP_ADDRESS:12900 to > http://SVR2_IP_ADDRESS:12900/system/cluster/node > at > com.ning.http.client.providers.netty.NettyResponseFuture.abort(NettyResponseFuture.java:342) > > ~[com.ning.async-http-client-1.8.14.jar:na] > at > com.ning.http.client.providers.netty.NettyConnectListener.operationComplete(NettyConnectListener.java:108) > > ~[com.ning.async-http-client-1.8.14.jar:na] > at > org.jboss.netty.channel.DefaultChannelFuture.notifyListener(DefaultChannelFuture.java:431) > > ~[io.netty.netty-3.9.3.Final.jar:na] > at > org.jboss.netty.channel.DefaultChannelFuture.notifyListeners(DefaultChannelFuture.java:422) > > ~[io.netty.netty-3.9.3.Final.jar:na] > at > org.jboss.netty.channel.DefaultChannelFuture.setFailure(DefaultChannelFuture.java:384) > > ~[io.netty.netty-3.9.3.Final.jar:na] > at > org.jboss.netty.channel.socket.nio.NioClientBoss.processSelectedKeys(NioClientBoss.java:109) > > ~[io.netty.netty-3.9.3.Final.jar:na] > at > org.jboss.netty.channel.socket.nio.NioClientBoss.process(NioClientBoss.java:79) > > ~[io.netty.netty-3.9.3.Final.jar:na] > at > org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:318) > > ~[io.netty.netty-3.9.3.Final.jar:na] > at > org.jboss.netty.channel.socket.nio.NioClientBoss.run(NioClientBoss.java:42) > ~[io.netty.netty-3.9.3.Final.jar:na] > at > org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) > > ~[io.netty.netty-3.9.3.Final.jar:na] > at > org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) > > ~[io.netty.netty-3.9.3.Final.jar:na] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > > [na:1.8.0_11] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > > [na:1.8.0_11] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_11] > Caused by: java.net.ConnectException: Connection refused: > /SVR2_IP_ADDRESS:12900 to http://SVR2_IP_ADDRESS:12900/system/cluster/node > at > com.ning.http.client.providers.netty.NettyConnectListener.operationComplete(NettyConnectListener.java:104) > > ~[com.ning.async-http-client-1.8.14.jar:na] > ... 12 common frames omitted > Caused by: java.net.ConnectException: Connection refused: > /SVR2_IP_ADDRESS:12900 > at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) > ~[na:1.8.0_11] > at > sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:712)
[graylog2] Re: upgrading graylog-server from 1.16 to 1.2rc4 totally broke all LDAP access
Hi Jason!
Could you please turn the log level
of org.graylog2.security.ldap.LdapConnector to TRACE?
The easiest way to do so is via the System/Logging section in the API
browser (port 12900 of your graylog server).
That logs all kinds of details about the searches performed and the
entities returned.
With regards to "flat" vs" "hilly" AD topologies, the group search is using
subtree scope, so deeper hierarchies should not be a problem, the same is
true (but this hasn't changed to pre-1.2 versions) for user search. I'm
unsure what changes when AD is trying to flatten the hierarchy, but
apparently the error:
2015-09-08T20:56:40.614-04:00 ERROR [DefaultAttribute]
ERR_04486_VALUE_ALREADY_EXISTS The value '20150728213900.0Z' already exists
in the attribute (dSCorePropagationData)
comes out of the library we use for connecting. I'll check the code to see
if that breaks everything.
If you are interested, the relevant code starts
here:
https://github.com/Graylog2/graylog2-server/blob/1.2/graylog2-server/src/main/java/org/graylog2/security/ldap/LdapConnector.java#L121-121
Please let me know any additional things I need to be able to reproduce
this issue.
Thanks,
Kay
On Wednesday, 9 September 2015 03:07:31 UTC+2, Jason Haar wrote:
>
> Hi there
>
> Says it all really. After upgrading from 1.16 to 1.2rc4, none of the LDAP
> (actually ActiveDirectory) accounts work - even the Admin ones (thankfully
> the standard backdoor "admin" account still works)
>
> I tried logging in with a new LDAP account - it also fails (default user
> mode: Reader). But refreshing the "user" area shows the new account - so
> it's been created even though I can't log in with it. The login page error
> says "sorry those creds aren't valid"
>
> I didn't change the LDAP User Mapping area [ which is set to
> "(&(objectClass=user)(userPrincipalName={0}))" ], but changed the new Group
> Mapping to
>
> (&(objectClass=group)(cn=*))
>
> with "Group Name Attribute" set to "cn". I also used ldapsearch to test
> that filter - it works fine, returning a bunch of groups
>
> However, after filling in that section I go to "LDAP Group Mapping" and it
> says there are no LDAP groups - so something's wrong in the group section
> of the "LDAP Settings". We are running an AD forest and I'm logging in
> using an account from a child domain (we don't have user accounts in the
> parent) - so could this be a recursion problem? However, the logs do show
> evidence of the LDAP query bringing back groups from the child domains - so
> it all looks good as far as I can see
>
> I've turned up the Authentication logging to "debug" and this shows up on
> any LDAP login event. That "ERR_04486_VALUE_ALREADY_EXISTS" is the only
> thing that looks like an error?
>
>
> 2015-09-08T20:56:25.519-04:00 DEBUG [ModularRealmAuthenticator] Realm
> [org.graylog2.security.realm.SessionAuthenticator@79ea39fc] does not
> support token org.apache.shiro.authc.UsernamePasswordToken -
> usern...@domain.name, rememberMe=false. Skipping realm.
> 2015-09-08T20:56:25.520-04:00 DEBUG [ModularRealmAuthenticator] Realm
> [org.graylog2.security.realm.AccessTokenAuthenticator@5d75e8f0] does not
> support token org.apache.shiro.authc.UsernamePasswordToken -
> usern...@domain.name, rememberMe=false. Skipping realm.
> 2015-09-08T20:56:40.614-04:00 ERROR [DefaultAttribute]
> ERR_04486_VALUE_ALREADY_EXISTS The value '20150728213900.0Z' already exists
> in the attribute (dSCorePropagationData)
> 2015-09-08T20:56:41.964-04:00 WARN [UserServiceImpl] User
> usern...@domain.name: No group mapping for ldap group
> 2015-09-08T20:56:41.969-04:00 WARN [UserServiceImpl] User
> usern...@domain.name: No group mapping for ldap group
> 2015-09-08T20:56:41.969-04:00 WARN [UserServiceImpl] User
> usern...@domain.name: No group mapping for ldap group
> 2015-09-08T20:56:41.971-04:00 DEBUG [AuthenticatingRealm] Looked up
> AuthenticationInfo [usern...@domain.name] from doGetAuthenticationInfo
> 2015-09-08T20:56:41.971-04:00 DEBUG [AuthenticatingRealm]
> AuthenticationInfo caching is disabled for info [usern...@domain.name].
> Submitted token: [org.apache.shiro.authc.UsernamePasswordToken -
> usern...@domain.name, rememberMe=false].
> 2015-09-08T20:56:41.973-04:00 DEBUG [AuthenticatingRealm] Looked up
> AuthenticationInfo [null] from doGetAuthenticationInfo
> 2015-09-08T20:56:41.973-04:00 DEBUG [AuthenticatingRealm] No
> AuthenticationInfo found for submitted AuthenticationToken
> [org.apache.shiro.authc.UsernamePasswordToken - usern...@domain.name,
> rememberMe=false]. Returning null.
> 2015-09-08T20:56:41.973-04:00 DEBUG [AuthenticatingRealm] Looked up
> AuthenticationInfo [null] from doGetAuthenticationInfo
> 2015-09-08T20:56:41.973-04:00 DEBUG [AuthenticatingRealm] No
> AuthenticationInfo found for submitted AuthenticationToken
> [org.apache.shiro.authc.UsernamePasswordToken - usern...@domain.name,
> rememberMe=false]. Returning null.
>
[graylog2] Re: Message order in output plugins
Hi! No, that is currently not possible. Because messages are being processed in parallel by multiple threads their order is not guaranteed at the moment. The collector currently does not track the line numbers of the file it reads, which could then be used to sort the messages again. We do have this on our list though: https://github.com/Graylog2/collector/issues/12 Best, Kay On Monday, 7 September 2015 15:40:35 UTC+2, Claus Koell wrote: > > Hi ! > > We are using the new graylog-collector to read from local files from many > servers. This works pretty cool ! We have written > a output plugin that writes the messages to a global share to have the log > files again as files :-) > > The problem now is that the message order is not in that order as in the > source files. > > Is it possible to tell graylog to handle the incoming message in a fifo > style ? > > greets > claus > > > -- You received this message because you are subscribed to the Google Groups "Graylog Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to graylog2+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/graylog2/d91d41d1-b56b-405f-90df-e9970b91ad0b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [graylog2] Re: upgrading graylog-server from 1.16 to 1.2rc4 totally broke all LDAP access
What Drew said, but starting with RC.4 the Group Object Class is Group
Search Filter and needs to be a valid filter:
(objectClass=group)
in the standard case.
On Wednesday, 9 September 2015 16:41:17 UTC+2, Drew Miranda wrote:
>
> Not sure if this helps but...
>
> Search Base DN should be the OU parent where you want any valid users to
> be found for login
> OU=User Accounts,DC=ochsner,DC=org
>
> User Search Pattern should match the username users will input to login
> (&(objectClass=user)(sAMAccountName={0}))
>
> Group Search Base DN can be similar to your user search base DN. The OU
> where your groups live.
> OU=Groups Live Here,DC=ochsner,DC=org
>
> Group Object Class should just be:
> group
>
> Group Name Attribute should just be:
> cn
>
> The example text in red is usually helpful. If you've already got those
> fields set appropriately disregard!
>
>
--
You received this message because you are subscribed to the Google Groups
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/graylog2/d394e1d8-d62a-43fc-b404-920aa0d07e37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[graylog2] Re: LDAP authentication with Graylog 1.2 RC2
Hi! Old users should have been migrated to the new permission system automatically, please check your graylog server log file. It should contain lines like: "INFO [UserPermissionMigrationPeriodical] Migrating permissions to roles for user" You can use roles without LDAP group mapping, yes. Simply create the roles and then assign them to users by hand. LDAP group mapping is supposed to make it easier to integrate but is not required. We have not encountered any problems with group mapping so far, are there any errors in the graylog server log? Best regards, Kay On Tuesday, 8 September 2015 14:20:23 UTC+2, yvesloui...@gmail.com wrote: > > Hi, > > I tried quickly the graylog 1.2 RC2, but I had a bloquant problem with > authentication. > > Does the ldap authentication strategy will change in near future ? > - Can we use ldap authentication with users without ldap group ? > - Can we create groups but not ldap groups ? > > (The old users can't no more connect to graylog-web due to deprecated > permissions) > > Best regards > > Yves Louis ROFORT > -- You received this message because you are subscribed to the Google Groups "Graylog Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to graylog2+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/graylog2/a761e953-bfe2-444b-a8ea-fdf32ed94f66%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[graylog2] Re: elasticsearch version requirements
On Tuesday, 8 September 2015 19:19:05 UTC+2, Mike Daoust wrote: > Is it documented anywhere which versions of elasticsearch are suggested for > graylog? You should run the latest release version, but at least 1.6.x for the security and reliability improvements. Usually we aim to support the latest 2-3 minor versions. Best, Kay -- You received this message because you are subscribed to the Google Groups "Graylog Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to graylog2+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/graylog2/b7c9aa7f-02d0-4db9-9b55-ddf6f5e7fdf2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[graylog2] Re: app.js 404 not found and nothing show in Sources page
Hi! You need to build the Javascript bundle before running `activator dist` by calling ./node_modules/.bin/gulp deploy-prod in javascript/. Check the steps in https://github.com/Graylog2/graylog2-web-interface/blob/master/build_release.sh for reference what we do to build a release. cheers, -k On Monday, 8 June 2015 08:17:44 UTC+2, saeed.rajab...@gmail.com wrote: Hi I clone the 1.0 branch of web interface project from github and then run the 'npm install' command in javascripts folder then run 'activator dist' command and anything is OK. I have a zip archive contains all executable files of the project like release version of the web interface project except public/javascript/build/app.js and I can not see anything in sources page. Where is my fault? How can I fix this? -- You received this message because you are subscribed to the Google Groups graylog2 group. To unsubscribe from this group and stop receiving emails from it, send an email to graylog2+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [graylog2] Re: grok extractors not working
No, this should not be a timezone issue, as the extractors are re-checked every second. Do you have a lot of Grok patterns maybe? On Saturday, 6 June 2015 00:43:46 UTC+2, Jesse Skrivseth wrote: I don't have much new to report other than the observation that it takes *exactly* 2 hours for newly created extractors to take effect. Could this be a clock/timezone issue? All servers are UTC with accurate clocks. What is coming in from NXLog and the devices behind it I cannot guarantee, but I can't think of a reason that would matter. On Monday, June 1, 2015 at 8:30:40 AM UTC-6, Jesse Skrivseth wrote: Thanks to everyone for continuing to pursue this odd issue. Arie - We are using nxlog-ce version 2.9.1347 Kay - I can't seem to recreate the problem (yet) in a test environment, whether 1.0.2 or 1.1.0. There are some (possibly irrelevant) differences between test and production, but I'll mention them anyway. Production is built on Amazon Web Services using the provided 1.0.2 AMIs. Test is running locally from the 1.0.2 OVA images in ESXi. Test and production have different volumes of data coming in and different devices are sending logs. The only place I seem to be having trouble is in production with messages coming from the one network appliance I am focused on at the moment. I haven't had a need to add/update extractors for other devices yet, so I'm not sure if the problem is limited to that one device or is universal for this production instance. I will test more generally, with more devices, and see if I can find a pattern. -- You received this message because you are subscribed to the Google Groups graylog2 group. To unsubscribe from this group and stop receiving emails from it, send an email to graylog2+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [graylog2] Re: grok extractors not working
Jesse, We've just tried to reproduce this issue on 1.1.0-RC.1 but it works as expected. Could you give that a try in a test environment, please? Thanks, Kay On Saturday, 30 May 2015 13:42:52 UTC+2, Bernd Ahlers wrote: Jesse, thank you for the update. I created an issue in GitHub for this with a link to this mailing list thread. https://github.com/Graylog2/graylog2-server/issues/1192 I also started to test with the detailed data you submitted but did not see any problems. I was testing on 1.1.0-rc.1 though. Next step is to test all of this with 1.0.2 (which you are running). I will let you know once I have any updates. Thank you! Bernd Jesse Skrivseth [Fri, May 29, 2015 at 11:41:52AM -0700] wrote: I'm not sure why, but suddenly the extractors are working today without any further action on my part. There seems to be a very long delay between when an extractor is configured and when it is in effect, at least in this environment. Another thing to note is that the data on this input is TLS encrypted GELF via TCP, and the data is coming in from NXLog using GELF_TCP. On Thursday, May 28, 2015 at 3:25:05 PM UTC-6, Kay Röpke wrote: I'm not an expert on the OVAs so I would recommend simply setting up a test instance to check this. Or you can wait until I get to it in the (my) morning ;) -- You received this message because you are subscribed to the Google Groups graylog2 group. To unsubscribe from this group and stop receiving emails from it, send an email to graylog2+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Developer Tel.: +49 (0)40 609 452 077 Fax.: +49 (0)40 609 452 078 TORCH GmbH - A Graylog company Steckelhörn 11 20457 Hamburg Germany Commercial Reg. (Registergericht): Amtsgericht Hamburg, HRB 125175 Geschäftsführer: Lennart Koopmann (CEO) -- You received this message because you are subscribed to the Google Groups graylog2 group. To unsubscribe from this group and stop receiving emails from it, send an email to graylog2+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[graylog2] Re: [ANNOUNCE] Graylog v1.1.0-beta.2 is out
Hi Ankit, The blog post contains links to the log shipper at the very end of the post. You can also access it via its Github repository: https://github.com/Graylog2/collector and https://github.com/Graylog2/collector/releases cheers, Kay On Thursday, 21 May 2015 08:55:53 UTC+2, Ankit Mittal wrote: Hi Lennart, Where i can find the light-weight log collector agent and its setup steps. Regards, Ankit -- You received this message because you are subscribed to the Google Groups graylog2 group. To unsubscribe from this group and stop receiving emails from it, send an email to graylog2+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
