[rsyslog] omelasticsearch index warning

Rainer Gerhards rgerhards at hq.adiscon.com
Mon Jan 2 11:54:46 CET 2017


Am 02.01.2017 08:49 schrieb "Radu Gheorghe" <radu.gheorghe at sematext.com>:

Hello,

Sorry for being very late to the party. One could get the version by
doing a GET request on the ES host and looking at the version.number
field. I'm not sure why we need to do that HEAD request, though -
looks like I missed that we're doing that and I missed the reason, too
:(

Trouble is, INDEX/_mapping/TYPE doesn't work properly for 2.x, here's
what I get on 2.4.1:

$ curl -i -XHEAD localhost:9200/logs/system_log
HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Content-Length: 0

$ curl -i -XHEAD localhost:9200/logs/_mapping/system_log
HTTP/1.1 404 Not Found
Content-Type: text/plain; charset=UTF-8
Content-Length: 0

It sounds a bit hacky to me to detect the version and behave
differently, though we'd have to do that *if* this is needed. But
maybe it isn't?


I think that actually is the right thing to do and the prime reason why
versions can be queried.

Question: could you help me getting two different versions integrated into
the testbench, so that we can ensure everything works well in the future?
This involves learning how to install without an OS package, seeing
listener ports etc... I guess nothing result complicated for an ES expert
;-)

I won't be available for that work until around the 11th, but I would
really like to have it, especially as we move into tighter integration of
ES.

Rainer

--
Performance Monitoring * Log Analytics * Search Analytics
Solr & Elasticsearch Support * http://sematext.com/


On Wed, Dec 21, 2016 at 7:30 PM, mostolog--- via rsyslog
<rsyslog at lists.adiscon.com> wrote:
> Thanks for your answers.
>
> I'll also try to have a look on this.
>
> El 21/12/16 a las 17:48, matthew.gaetano escribió:
>
>> Though the examples given are specific modifications for aspects of
>> Elasticsearch 5.X i believe the modification method would be valid for
any
>> version of Elasticsearch supported by omelasticsearch. To be honest I am
>> not
>> familiar with how omelasticsearch interfaces with ES (which is using a
>> json
>> body), where as I am more familiar with the direct head requests to ES.
>>
>>   It is through assumptions and trial/error that this works. And I assume
>> any
>> index related settings could be used.
>>
>> ES version is based on node, so the cluster doesn't have an overall ES
>> version listed (as far as I can tell), so one would have to query the
node
>> that the request is being sent to. Using curl it would be simply:
>>
>> curl -XGET 'localhost:9200'  # where localhost is the ip or hostname of
>> the
>> target ES node.
>>
>> the output looks like:
>> {
>>    "name" : "node_name",
>>    "cluster_name" : "cluster_name",
>>    "cluster_uuid" : "dhB2-TUeRN2LyWmhhN1WJQ",
>>    "version" : {
>>      "number" : "5.0.2",
>>      "build_hash" : "f6b4951",
>>      "build_date" : "2016-11-24T10:07:18.101Z",
>>      "build_snapshot" : false,
>>      "lucene_version" : "6.2.1"
>>    },
>>    "tagline" : "You Know, for Search"
>> }
>>
>> Too filter out the version number use:
>> curl -XGET 'localhost:9200/?filter_path=version.number'
>>
>> output:
>> {
>>    "version" : {
>>      "number" : "5.0.2"
>>    }
>> }
>>
>>
>> Another way to possible check would be to use the node api.
>> curl -XGET
>> 'localhost:9200/_nodes/_local/info?filter_path=nodes.*.version&pretty'
>>
>> output:
>> {
>>    "nodes" : {
>>      "F6UMqjbmQCO5-IqFeKzfDQ" : {
>>        "version" : "5.0.2"
>>      }
>>    }
>> }
>>
>>
>> Note that "_local" equates to the node the request was sent to. Though
>> there
>> are other ways to lookup the nodes based on other attributes this seems
>> easiest. Since its restricted to local we wont need to know the node id
>> and
>> can just use a wildcard. Note that the "&pretty" at the end is to make
the
>> output readable and is not required.
>>
>> Thanks
>>
>> ~Regards
>>
>>
>>
>>
>>
>> -----
>> ~Regards
>>
>> Matthew Gaetano
>> --
>> View this message in context:
>> http://rsyslog-users.1305293.n2.nabble.com/omelasticsearch-index-warning-
tp7591961p7592008.html
>> Sent from the rsyslog-users mailing list archive at Nabble.com.
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>> http://www.rsyslog.com/professional-services/
>> What's up with rsyslog? Follow https://twitter.com/rgerhards
>> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad
>> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you
DON'T
>> LIKE THAT.
>
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
> What's up with rsyslog? Follow https://twitter.com/rgerhards
> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad
of
> sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T
> LIKE THAT.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T
LIKE THAT.


More information about the rsyslog mailing list