No handlers could be found for logger "elasticsearch" about elasticsearch-py

[honzakral]

Hi Chen,

that is not an error from elasticsearch - it's just a message from the logging module informing you that you don't have logging configured. If you don't want logging it's nothing to be worried about.

Although the code should work like this I strongly recommend you use keyword arguments to all es client methods es.indices.exists_type(index=resource_index, doc_type=resource_type) for foward compatibility in case the arguments change order (which would happen for example if index became optional).

Hope this helps,
Honza

[cynosureabu]

Thanks much Honza!

[jmehnle]

This should actually be addressed in the elasticsearch module. According to the docs of the logging module a library that uses logging.getLogger should add a NullHandler default handler to its top-level logger to avoid generating No handlers could be found for logger "elasticsearch" errors.

[davidawad]

has anything happened with this? Can confirm issue is still present

[honzakral]

@davidawad thanks for jumping in. I do not see this as an issue (as I expressed in #169). I see however, that other people view it as one. Could you please elaborate what is bothering you about the message?

I am sorry if I seem obtuse (specially to @jmehnle), I just don't feel comfortable fixing something until I fully understand why it is an issue. I am by no means saying that you are wrong or that your opinion is not valid. Thanks for your patience.

[davidawad]

no big deal, it's only a problem because it prints a message to STDOUT everytime a python script using the module is run. Here's some code for example, running this gives that message.

import elasticsearch
from elasticsearch_dsl import Search, Q
from datetime import datetime

# relevant docs 
# http://stackoverflow.com/questions/24753569/what-causes-elasticsearch-exceptions-connectionerror-connectionerror-error/24753577#24753577

#   http://xx.xx.xx.xx:9200/   -- shibly's instance 
#   http://elasticsearch-dsl.readthedocs.org/ 
#    http://elasticsearch-py.readthedocs.org/en/latest/api.html

es = elasticsearch.Elasticsearch([{u'host': u'104.236.45.15', u'port': b'9200'}])
print es.indices.exists_alias('foo')

es.index(index="david", doc_type="test-type", id=42, body={"any": "data", "timestamp": datetime.now()})

client = es

s = Search(using=client, index="my-index") \
    .filter("term", category="search") \
    .query("match", title="python")   \
    .query(~Q("match", description="beta"))

s.aggs.bucket('per_tag', 'terms', field='tags') \
    .metric('max_lines', 'max', field='lines')

response = s.execute()

for hit in response:
    print(hit._meta.score, hit.title)

for tag in response.aggregations.per_tag.buckets:
    print(tag.key, tag.max_lines.value)



print "success"

[davidawad]

not before a glorious exception call stack

[honzakral]

@davidawad the IP address you originally posted (I edited it out) has a publicly accessible elasticsearch instance running, that is dangerous and may very well lead to remote code execution by attackers. We highly recommend that you never expose your cluster to the outside world without protection of at least a proxy.

[honzakral]

If it's just the message appearing I actually personally consider that a feature since it brings attention to the fact that we have a logger defined. What do you think?

The exception stack is most likely just a result of querying an index that doesn't exist, at least that is the exception I am getting from running this script.

[jmehnle]

The issue is not so much any message being printed, it's a message being printed that looks like a code error, something that the user code is doing wrong. Which is not the case.

[davidawad]

@honzakral oh, of course, this is a junk instance for testing some of my scripts.

[filippog]

any news/activity on this? personally I think the module should follow logging recommendation to set a top level nullhandler and not mess with users' stdout

[honzakral]

@filippog I don't understand, we are adding the NullHandler for python versions 2.7 - 3.2 where this is an issue. For later versions we are following the recommendation stated explicitly in the documentation (0) (emphasis mine):

If the using application does not use logging, and library code makes logging calls, then (as described in the previous section) events of severity WARNING and greater will be printed to sys.stderr. This is regarded as the best default behaviour.

Also nothing should be ever printed on stdout, the logging uses stderr. Or am I missing something?

Thanks

0 - https://docs.python.org/3/howto/logging.html#configuring-logging-for-a-library

[filippog]

ah my bad! I was confused by the issue history, the null handler is indeed there in the last version -- all good, sorry for the noise 👍