metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cestella <>
Subject [GitHub] metron pull request #779: METRON-1218: Metron REST should return better erro...
Date Fri, 29 Sep 2017 21:21:26 GMT
Github user cestella commented on a diff in the pull request:
    --- Diff: metron-interface/metron-rest/src/main/java/org/apache/metron/rest/controller/
    @@ -45,4 +45,14 @@ private HttpStatus getStatus(HttpServletRequest request) {
         return HttpStatus.valueOf(statusCode);
    +  private String getFullMessage(Throwable ex) {
    +    String fullMessage = ex.getMessage();
    +    Throwable cause = ex.getCause();
    +    while(cause != null) {
    +      fullMessage = cause.getMessage();
    +      cause = cause.getCause();
    +    }
    +    return fullMessage;
    --- End diff --
    Hmm, in the situation that I was in last night while debugging, I was using this patch
and the exception was not logged in metron-rest. I was hunting the same bug as Simon.  I ended
up adjusting this to include the stack trace and that's how I eventually figured it out. 
I'm not entirely certain WHY the error logging wasn't showing up.
    Since this has happened to 2 of us now, could you validate that when you try to use the
alerts-ui and use a sensor that does not have the `alert` nested template (any new sensor),
you get an exception in the log?  It should be something like:
    Caused by: Could not execute
            ... 88 more
    Caused by: Failed to execute phase [query_fetch], all shards failed; shardFailures {[S6cJSn5nSmOpd7Lm2_OF9g][cowrie_index_2017.09.29.05][0]:
nested: SearchParseException[failed to parse search source [{\"from\":0,\"size\":25,\"query\":{\"constant_score\":{\"filter\":{\"bool\":{\"should\":[{\"query_string\":{\"query\":\"*\"}},{\"bool\":{\"must\":[{\"term\":{\"status\":\"active\"}},{\"nested\":{\"query\":{\"query_string\":{\"query\":\"*\"}},\"path\":\"alert\"}}]}}]}}}},\"_source\":{\"includes\":[],\"excludes\":[]},\"sort\":[{\"timestamp\":{\"order\":\"desc\"}}],\"track_scores\":true}]];
nested: QueryParsingException[[nested] failed to find nested object under path [alert]]; }
            at org.elasticsearch.action.ActionListenerResponseHandler.handleException(
            at org.elasticsearch.transport.TransportService$DirectResponseChannel.processException(
            at org.elasticsearch.transport.TransportService$DirectResponseChannel.sendResponse(
            at org.elasticsearch.transport.TransportService$4.onFailure(
    If you can get it to work, then I'm +1.  I absolutely couldn't get it to work with this
PR, but I might've been doing something weird and I worry there's something weird with the
logging level (which I think is at INFO) on metron-rest by default.
    I still, personally, would rather see a stack trace in the error in the UI (since I'd
prefer to *get* a stack trace from users for diagnosing issues and that's where they'll be
looking).  I take @ottobackwards 's point about security, but I still think it's valid and
valuable.  For the moment, I'd just append the multiline string and we can sort it out when
debugging.  Mind you, this would be in addition to in the rest logs.
    I guess the net-net of it is that I want it logged and validated at LEAST one place and
I'd be ok if it were 2 (one to the user and one to the system logs).


View raw message