如何使用logstash从日志中获取匹配'n'次的行集

Question

我有一个日志跟踪，我试图从中获取与我的 grok enter code here 匹配的行集

日志：

CNTR0020E: EJB threw an unexpected (non-declared) exception during invocation of method "getCustomerDashBoardCVAHistoricalDataRequestCount" on bean "BeanId(cva-admin-ear#vis-ejb-cva-4.20.0.0-SNAPSHOT.jar#CustomerDashboardServiceBean, null)". Exception data: java.lang.RuntimeException: com.ibm.websphere.naming.CannotInstantiateObjectException: Exception occurred while the JNDI NamingManager was processing a javax.naming.Reference object. [Root exception is com.ibm.websphere.ejbcontainer.AmbiguousEJBReferenceException: The short-form default binding 'za.co.sb.archiving.midtier.ejb.HistoricalDataRequestBusinessServiceRemote' is ambiguous because multiple beans implement the interface : [channel-frontendEAR#channel-biz-ejb-3-4.20.0.0-SNAPSHOT.jar#HistoricalDataRequestBusinessServiceBean, nbol-rest-0_0_1-20150729_102930-10_war#nbol-rest-0.0.1-20150729.102930-10.war#HistoricalDataRequestBusinessServiceBean]. Provide an interface specific binding or use the long-form default binding on lookup.]
    at za.co.sb.channel.cva.customerdashboard.midtier.pojo.CustomerDashboardVisServicePojo.getRequestBusinessService(CustomerDashboardVisServicePojo.java:355)
    at za.co.sb.channel.cva.customerdashboard.midtier.pojo.CustomerDashboardVisServicePojo.getHistoricalDataRequestCount(CustomerDashboardVisServicePojo.java:282)
    at za.co.sb.channel.cva.customerdashboard.midtier.pojo.CustomerDashboardVisServicePojo.getCustomerDashBoardHistoricalDataRequestCount(CustomerDashboardVisServicePojo.java:249)
    at za.co.sb.channel.cva.customerdashboard.midtier.ejb.CustomerDashboardServiceBean.getCustomerDashBoardCVAHistoricalDataRequestCount(CustomerDashboardServiceBean.java:49)
    at za.co.sb.channel.cva.customerdashboard.midtier.ejb.EJSLocal0SLCustomerDashboardServiceBean_7d8a7f63.getCustomerDashBoardCVAHistoricalDataRequestCount(EJSLocal0SLCustomerDashboardServiceBean_7d8a7f63.java)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at za.co.sb.midtier.processservice.ProcessServiceImpl.callService(ProcessServiceImpl.java:770)
    at za.co.sb.midtier.processservice.ProcessServiceImpl.retrieveResultData(ProcessServiceImpl.java:1151)
    at za.co.sb.midtier.processservice.ProcessServiceImpl.process(ProcessServiceImpl.java:248)
    at za.co.sb.midtier.processservice.ProcessServiceBean.process(ProcessServiceBean.java:63)
    at za.co.sb.midtier.processservice.EJSRemote0SLCustomerAdminProcessService_450d08b4.process(EJSRemote0SLCustomerAdminProcessService_450d08b4.java)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
Caused by: com.ibm.websphere.naming.CannotInstantiateObjectException: Exception occurred while the JNDI NamingManager was processing a javax.naming.Reference object. [Root exception is com.ibm.websphere.ejbcontainer.AmbiguousEJBReferenceException: The short-form default binding 'za.co.sb.archiving.midtier.ejb.HistoricalDataRequestBusinessServiceRemote' is ambiguous because multiple beans implement the interface : [channel-frontendEAR#channel-biz-ejb-3-4.20.0.0-SNAPSHOT.jar#HistoricalDataRequestBusinessServiceBean, nbol-rest-0_0_1-20150729_102930-10_war#nbol-rest-0.0.1-20150729.102930-10.war#HistoricalDataRequestBusinessServiceBean]. Provide an interface specific binding or use the long-form default binding on lookup.]
    at com.ibm.ws.naming.util.Helpers.processSerializedObjectForLookupExt(Helpers.java:1103)
    at com.ibm.ws.naming.util.Helpers.processSerializedObjectForLookup(Helpers.java:796)
    at com.ibm.ws.naming.jndicos.CNContextImpl.processBoundObjectForLookup(CNContextImpl.java:2876)
    at com.ibm.ws.naming.jndicos.CNContextImpl.processResolveResults(CNContextImpl.java:3973)
    at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1875)
    at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1776)
    at com.ibm.ws.naming.jndicos.CNContextImpl.lookupExt(CNContextImpl.java:1433)
    at com.ibm.ws.naming.jndicos.CNContextImpl.lookup(CNContextImpl.java:615)
    at com.ibm.ws.naming.util.WsnInitCtx.lookup(WsnInitCtx.java:165)
    at com.ibm.ws.naming.util.WsnInitCtx.lookup(WsnInitCtx.java:179)
    at org.apache.aries.jndi.DelegateContext.lookup(DelegateContext.java:161)
    at

Grok 模式：CUSTOM_ZACOSB (?:\A*at za.co.sb.{5}?)

在过滤器中的使用：

grok{
    match => ["ParseContent","%{CUSTOM_ZACOSB:ProjectLocation}"]
    add_tag => "ProjectLocation"
}

输出：“ProjectLocation”=>“在 za.co.sb.chan”

预期输出：

at za.co.sb.channel.cva.customerdashboard.midtier.pojo.CustomerDashboardVisServicePojo.getRequestBusinessService(CustomerDashboardVisServicePojo.java:355)
    at za.co.sb.channel.cva.customerdashboard.midtier.pojo.CustomerDashboardVisServicePojo.getHistoricalDataRequestCount(CustomerDashboardVisServicePojo.java:282)
    at za.co.sb.channel.cva.customerdashboard.midtier.pojo.CustomerDashboardVisServicePojo.getCustomerDashBoardHistoricalDataRequestCount(CustomerDashboardVisServicePojo.java:249)
    at za.co.sb.channel.cva.customerdashboard.midtier.ejb.CustomerDashboardServiceBean.getCustomerDashBoardCVAHistoricalDataRequestCount(CustomerDashboardServiceBean.java:49)
    at za.co.sb.channel.cva.customerdashboard.midtier.ejb.EJSLocal0SLCustomerDashboardServiceBean_7d8a7f63.getCustomerDashBoardCVAHistoricalDataRequestCount(EJSLocal0SLCustomerDashboardServiceBean_7d8a7f63.java)

有人可以指出我在哪里做错了。这将有很大帮助。我只想要那五行不休息，我的过滤器能够找到内容但它不会更进一步。如果我修改它捕获整个日志，这是我不想要的。

Answer 1

看起来您没有将多行堆栈跟踪滚动到单个消息中以供 logstash 处理。 Filebeat 和 logstash 都具有多行功能。一旦你有一条消息，你就可以调整你的正则表达式。