Github user cestella commented on a diff in the pull request:
https://github.com/apache/metron/pull/779#discussion_r141971177
--- Diff:
metron-interface/metron-rest/src/main/java/org/apache/metron/rest/controller/RestExceptionHandler.java
---
@@ -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: org.apache.metron.indexing.dao.search.InvalidSearchException:
Could not execute search
at
org.apache.metron.elasticsearch.dao.ElasticsearchDao.search(ElasticsearchDao.java:170)
at
org.apache.metron.elasticsearch.dao.ElasticsearchMetaAlertDao.search(ElasticsearchMetaAlertDao.java:190)
at
org.apache.metron.rest.service.impl.SearchServiceImpl.search(SearchServiceImpl.java:53)
... 88 more
Caused by: Failed to execute phase [query_fetch], all shards failed;
shardFailures {[S6cJSn5nSmOpd7Lm2_OF9g][cowrie_index_2017.09.29.05][0]:
RemoteTransportException[[node1][192.168.66.121:9300][indices:data/read/search[phase/query+fetch]]];
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.search.AbstractSearchAsyncAction.onFirstPhaseResult(AbstractSearchAsyncAction.java:206)
at
org.elasticsearch.action.search.AbstractSearchAsyncAction$1.onFailure(AbstractSearchAsyncAction.java:152)
at
org.elasticsearch.action.ActionListenerResponseHandler.handleException(ActionListenerResponseHandler.java:46)
at
org.elasticsearch.transport.TransportService$DirectResponseChannel.processException(TransportService.java:855)
at
org.elasticsearch.transport.TransportService$DirectResponseChannel.sendResponse(TransportService.java:833)
at
org.elasticsearch.transport.TransportService$4.onFailure(TransportService.java:387)
at
org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:39)
```
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).
---
