nrpe check for graylog-api fails with 307 redirect

Bug #1878411 reported by Michał Ajduk
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Graylog Charm
New
Medium
Unassigned

Bug Description

Graylog is running correctly but the API check charm reports false positive.

graylog version: 3.0.1

The nrpe check for graylog API checks url at 127.0.0.1:9000/api:
root@graylog-3:~# /usr/lib/nagios/plugins/check_http -I 127.0.0.1 -p 9000 -u /api -s cluster_id
HTTP CRITICAL: HTTP/1.1 307 Temporary Redirect - string 'cluster_id' not found on 'http://127.0.0.1:9000/api' - 230 bytes in 0.004 second response time |time=0.004246s;;;0.000000;10.000000 size=230B;;;0

This fails with temporary redirect:
< HTTP/1.1 307 Temporary Redirect
< Location: http://127.0.0.1:9000/

Graylog is listening so it is graylog process sending the redirect:
root@graylog-3:~# netstat -lntp | grep 9000
tcp6 0 0 :::9000 :::* LISTEN 3873/java

The check does not seem to use the credentials created in Graylog.

Related branches

Revision history for this message
Diko Parvanov (dparv) wrote :

managed to reproduce; issues is that query must be issued to http:/127.0.0.1:9001/api and not to http:/127.0.0.1:9000/api

Changed in charm-graylog:
status: New → Triaged
assignee: nobody → Diko Parvanov (dparv)
status: Triaged → In Progress
Revision history for this message
Paul Goins (vultaire) wrote :

Diko, are you sure you were running with channel=3/stable? I don't think port 9001 will even have a listener if running Graylog 3. The REST API was supposed to be served on the same port as the web interface in GL3, which should be port 9000.

Changed in charm-graylog:
importance: Undecided → Medium
Revision history for this message
Diko Parvanov (dparv) wrote :

Used default config that comes with the charm which is channel=2/stable

Using 3/stable the issue is still there (redirect + and cat be fixed by changing the NRPE check as follows:

/usr/lib/nagios/plugins/check_http -I 127.0.0.1 -p 9000 -u /api/cluster -s cluster_id -a admin:ADMIN_PASSWORD

So I am guessing it would be either better to check for channel and set different NRPE checks or change the default to 3/stable and comment that 2/stable is no longer supported by the charm.

Revision history for this message
Xav Paice (xavpaice) wrote :

I've been unable to reproduce this with the current release and both Graylog 2 and 3. Noting that the bug report is for graylog version: 3.0.1, which listens on port 9000 only.

This is the result from my test machine:

root@juju-3b6299-9:/etc/nagios/nrpe.d# /usr/lib/nagios/plugins/check_http -k Accept:\ application/json -I 127.0.0.1 -p 9000 -u /api -s cluster_id
HTTP OK: HTTP/1.1 200 OK - 447 bytes in 0.007 second response time |time=0.007178s;;;0.000000;10.000000 size=447B;;;0

Could you maybe share the bundle and charm version that was used to generate this issue?

Changed in charm-graylog:
status: In Progress → Incomplete
assignee: Diko Parvanov (dparv) → nobody
Revision history for this message
Michał Ajduk (majduk) wrote :

I have just reproduced this issue.

Charmed version 4.

App Version Status Scale Charm Store Rev OS Notes
graylog 3.0.1 active 1 graylog jujucharms 4 ubuntu

Version:
  graylog:
    charm: cs:~llama-charmers-next/graylog-4

This is the default version included in the templates.

Revision history for this message
Michał Ajduk (majduk) wrote :

The provlem was intermittent with this release so I believe that was due to a charm update.

Revision history for this message
Nikita Koltsov (nkoltsov) wrote :

I faced exactly the same issue when set graylog to use https charm version is 51 and the issue is still there.

https://git.launchpad.net/charm-graylog/tree/src/reactive/graylog.py#n1323 127.0.0.1 is hardcoded and when apache with https is enabled graylog automatically redirect to config[web_endpoint_uri] which is causing check to fail.

Changed in charm-graylog:
status: Incomplete → New
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.