ElasticSearch problem (Re: [Bro-Commits] [git/bro] master: Merge remote-tracking branch 'origin/fastpath' (c66c6d7))

Pushed updates now, but the external tests produce new reporter
messages (and thus fail right now):

  1258831173.687091 Reporter::ERROR conn/Log::WRITER_ELASTICSEARCH: ElasticSearch server may not be accessible. (empty)
  1258831173.687091 Reporter::WARNING conn/Log::WRITER_ELASTICSEARCH: HTTP operation with elasticsearch server timed out at 2000 msecs. (empty)
  1258831173.687091 Reporter::ERROR conn/Log::WRITER_ELASTICSEARCH: Received a non-successful status code back from ElasticSearch server, check the elasticsearch server
  1258850622.799571 Reporter::ERROR stats/Log::WRITER_ELASTICSEARCH: ElasticSearch server may not be accessible. (empty)
  1258850622.799571 Reporter::WARNING stats/Log::WRITER_ELASTICSEARCH: HTTP operation with elasticsearch server timed out at 2000 msecs. (empty)
  1258850622.799571 Reporter::ERROR stats/Log::WRITER_ELASTICSEARCH: Received a non-successful status code back from ElasticSearch server, check the elasticsearch serve
  1258853364.046653 Reporter::ERROR dns/Log::WRITER_ELASTICSEARCH: ElasticSearch server may not be accessible. (empty)
  1258853364.046653 Reporter::WARNING dns/Log::WRITER_ELASTICSEARCH: HTTP operation with elasticsearch server timed out at 2000 msecs. (empty)
  1258853364.046653 Reporter::ERROR dns/Log::WRITER_ELASTICSEARCH: Received a non-suc

I don't think these should be there in the standard configuration, as
it's not supposed to use elasticsearch. Seth?

Robin

The tuning/logs-to-elasticsearch script isn't being loaded is it? I'm surprised to see that warning.

  .Seth

Ah, turns out it is: the tests load test-all-policy.bro, to which I
just added that script back (because, well, it's supposed to load all
scripts we have).

But shouldn't logs-to-elasticsearch depend on some other kind of
configuration before it tries to do anything? Like configuring an ES
server to talk to?

Robin

The default is pre-configured (localhost:9200). I suspect we shouldn't load anything from the tuning/ directory in default tests.

  .Seth

That would require restructuring some of the tests. Also, I do prefer
having everything loaded. I see the problem here though.

We could add the reporter.log to the baseline for now until we've
figured out something better. But are they stable, or may the
specifics look different everytime?

Here's another idea: how about adding a way to disable the stuff in
logs-to-elasticsearch even if loaded? Like by redefing the ES server
to an empty string? That's something we could then add to the tests
that load everything.

Robin

The default is pre-configured (localhost:9200). I suspect we shouldn't load anything from the tuning/ directory in default tests.

That would require restructuring some of the tests. Also, I do prefer
having everything loaded. I see the problem here though.

We could add the reporter.log to the baseline for now until we've
figured out something better. But are they stable, or may the
specifics look different everytime?

Here's another idea: how about adding a way to disable the stuff in
logs-to-elasticsearch even if loaded? Like by redefing the ES server
to an empty string? That's something we could then add to the tests
that load everything.

Another idea: testing/external/scripts/diff-all has a quick hack (that I'm not really sure works right still) for getting around the case where GeoIP support isn't enabled and shows up as a reporter message. Maybe that can be updated to also ignore lines regarding ElasticSearch.

    Jon

I guess it could, but that's not really much nicer ... I can see
eventuallu having more of these optional scripts that do something
that might cause artefacts depending on config/capabilities.

How about as a general policy we say that any script that may cause
trouble when simply loaded on top of a standard configuration must
have a way to be disabled. We then add a script
disable-problematic-analyses.bro (or so :slight_smile: to the external tests, and
this script sets all those relevant options.

(Hmm ... We might be able to achieve the same effect with some
@unloads, but not sure I want to rely on that odd feature ...)

I can think of one more alternative: split test-all-policy.bro into
two parts, all the scripts that are fine to load with the external
tests and those which aren't.

Robin

I noticed that we already have script like that (testing-setup.bro),
it just wasn't loaded late enough to help here. So I changed that and
added a check to the ES script that if the server is not set, it
doesn't do anything. That does the trick.

Robin