[NoBrainer] Using Graylog2 REST API via PowerShell

Graylog2 comes with a very limited alerting feature where you can basically only create alerts based on a single field. However, and thus far I can follow the motivation of the developers, nearly every larger company already has some kind of alerting solution in place, so why the bother to duplicate some functionality that would probably not be used anyway.
Instead Graylog2 provides a means via its REST API to get a list of all alerts (or query for a specific one) so that you can take approriate actions within your favourite alerting/monitoring solution. Makes some kind of sense to me.

So in order to query the REST API (for which you do not seem to get any documentation except when you are in reach of a Graylog2 system) youcan use the “api-browser” which is supposed to run on port 12900 (per default). However, in my installation this did not work and with some investigation I found out that the IP address was configured to use the localhost address. But after sudo-changing it to “rest_listen_uri=0.0.0.0:12900” in “/etc/graylog2.conf” (and with the help of a “reboot”) I was able to access the api documentation via “http://graylog2-ipaddress:12900/api-browser” just fine (hint: there is also a link to the API available in the “System | Nodes” menu).

The menu quite ok (not too much reason why and what the APIs are for, but just the mere contents – but in a RESTful world the API is supposed to be self-explanatory anyway, I guess) and even allows you to create and executes requests on the fly, as you can see in the following figures.

Graylog2 api-browser

Graylog2 api-browser


Graylog2 api-browser

Graylog2 api-browser

With this little bit of information we are ready to excercise some PowerShell code to make a query or two. Logging in to Graylog2 is not neccessary as we can supply our credentials via Basic Authentication. Se we just get our credentials in a PSCredential object and Invoke-RestMethod will do the REST (no pun intended):

PS > $Uri = "http://192.168.174.134:12900/";
PS > $cred = Get-Credential admin # your secret password here ...
PS > $r = Invoke-RestMethod ({0}streams" -f $Uri) -Credential $cred
PS > $r

total streams
----- -------
    1 {@{id=53d27df0e4b0c452f4998528; title=default; description=default s...

PS > $r.streams[0] # streams is actually an array so be careful
id              : 53d27df0e4b0c452f4998528
title           : default
description     : default stream
created_at      : 2014-07-25T15:55:28.993Z
creator_user_id : admin
rules           : {}
disabled        : True

PS > $r.streams.id
53d27df0e4b0c452f4998528

The HTTP layer would then look similar to this:

GET http://192.168.174.134:12900/streams HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT; Windows NT 6.1; en-US) WindowsPowerShell/3.0
Authorization: Basic ZWRnYXI6c2Nobml0dGVuZml0dGljaA==
Host: 192.168.174.134:12900

HTTP/1.1 200 OK
Content-Type: application/json
X-Runtime-Microseconds: 2745
Content-Length: 199

{
  "total":1,
  "streams":
    [{
    "id":"53d27df0e4b0c452f4998528",
    "title":"default",
    "description":"default stream",
    "created_at":"2014-07-25T15:55:28.993Z",
    "creator_user_id":"admin",
    "rules":[],
    "disabled":true
    }]
}

You can then query an alert or check its condition easy like this:

# $r.streams[0].id is taken from first example
PS > $r1 = Invoke-RestMethod ("{0}streams/{1}/alerts/check" -f $Uri, $r.streams[0].id) -Credential $cred
PS > $r1

total_triggered results calculated_at
--------------- ------- -------------
              0 {}      2014-07-25T17:32:45.466Z

Querying configured inputs is also quite easy:

# $r.streams[0].id is taken from first example
PS > $r1 = Invoke-RestMethod ("{0}system/inputs" -f $Uri, $r.streams[0].id) -Credential $cred
PS > $r1

total inputs
----- ------
    1 {@{id=fb5ef226-83a1-40ef-8ed3-8554dc8105df; message_input=; state=ru...

PS > $r1.inputs

id                                   message_input                       state   started_at
--                                   -------------                       -----   ----------
fb5ef226-83a1-40ef-8ed3-8554dc8105df @{static_fields=; title=gelfhttp... running 2014-07-25T09:23:34.191-07:00

PS > $r1.inputs[0].message_input

static_fields   :
title           : gelfhttp
persist_id      : 53d27aebe4b0c452f49981de
global          : False
name            : GELF HTTP
input_id        : 53d27aebe4b0c452f49981de
started_at      : 2014-07-25T15:42:35.827Z
attributes      : @{port=12201; bind_address=0.0.0.0; recv_buffer_size=10485760}
creator_user_id : admin
type            : org.graylog2.inputs.gelf.http.GELFHttpInput

So with a couple of lines PowerShell you can query and work with Graylog2 completely remotely without the need to write an “App” or do more inside the product than neccessary. The information you retrieved via the API can then be imported or processed within your favourite monitoring/alerting solution. Quite flexible …

Trackbacks

  1. […] So we setup to push the plugin code to our Git repository from where drone.io would build it on every commit. Once commited we would run a docker build and start our automated testing via the Graylog2 API and our PowerShell modules (as quickly described in Sending Gelf messages to Graylog2 via PowerShell and Using Graylog2 REST API via PowerShell). […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: