elasticsearch NEST Elastic查询工作几个小时，然后停止

我对Elasticsearch 5.4和NEST 5.4.0有一个非常奇怪的情况。我编写了一个简单的C#控制台应用程序，每分钟查询一次Elastic，返回点击/文档，并将其存储在Postgres数据库中以供进一步处理。它在几个小时内工作得很好，然后开始返回带有valid.DebugInformation和零文档的查询，但我可以在Kibana开发工具中复制并运行相同的查询并获得结果。当我停止控制台应用程序并重新启动它时，它成功地查询并返回点击，一切正常。下面是代码示例和日志条目。我正试图弄明白为什么它会在一段时间后停止工作。我正在使用带有NEST的.NET核心C#控制台应用程序

我不确定.DebugInformation当时是否返回了有关ES运行状况的任何信息，以查看ES群集当时是否存在与429s类似的问题。我已经查看了elasticsearch.log，它只显示了插入。我不确定是否有地方可以找到查询问题

有人有过鸟巢工作正常然后停止的问题吗

这是一个包含两次运行的查询日志。第一个运行良好并返回9行（由于敏感数据，我删除了样本中的所有行，只有一行除外），然后再次运行，但返回的命中率为零。在我再次重新启动C代码之前，此后的所有查询都没有命中率。相同的开始和结束日期输入，我得到了弹性中的真实数据

2017-09-12 16:41:59.799 -05:00 [Information] Dates: Start 9/12/2017 4:41:00 PM End 9/12/2017 4:42:00 PM
2017-09-12 16:41:59.800 -05:00 [Debug] AlertService._queryErrors: 9/12/2017 4:41:00 PM End 9/12/2017 4:42:00 PM
2017-09-12 16:41:59.811 -05:00 [Debug] AlertService._elasticQueryLogErrors: elasticQuery {
                    "bool": {
                        "filter":
                            [ {
                                "range":
                                { "@timestamp": { "gte": "2017-09-12T21:41:00Z",
                                                    "lte": "2017-09-12T21:42:00Z" }
                                }
                              },
                              {
                                "exists" : { "field" : "error_data" }
                              }
                            ]
                        } }
2017-09-12 16:41:59.811 -05:00 [Debug] AlertService._elasticQueryLogErrors: searchResponse 9 : Valid NEST response built from a successful low level call on POST: /filebeat-%2A/_search
# Audit trail of this API call:
 - [1] HealthyResponse: Node: http://servername:9200/ Took: 00:00:00.0112120
# Request:
{"from":0,"query":{
                    "bool": {
                        "filter":
                            [ {
                                "range":
                                { "@timestamp": { "gte": "2017-09-12T21:41:00Z",
                                                    "lte": "2017-09-12T21:42:00Z" }
                                }
                              },
                              {
                                "exists" : { "field" : "error_data" }
                              }
                            ]
                        } }
# Response:
{"took":7,"timed_out":false,"_shards":{"total":215,"successful":215,"failed":0},"hits":{"total":9,"max_score":0.0,"hits":[{"_index":"filebeat-2017.09.12","_type":"log","_id":"AV54Cdl2yay890uCUru4","_score":0.0,"_source":{"offset":237474,"target_url":"...url...","input_type":"log","source":"....source....","type":"log","tags":["xxx-001","beats_input_codec_plain_applied","@timestamp":"2017-09-12T21:41:02.000Z","@version":"1","beat":{"hostname":"xxx-001","name":"xxx-001","version":"5.4.3"},"host":"xxx-001","timestamp":"09/12/2017 16:41:02","error_data":"EXCEPTION, see detail log"}]}

2017-09-12 16:41:59.811 -05:00 [Debug] AlertService._queryErrors: (result) System.Collections.Generic.List`1[XX.Alerts.Core.Models.FilebeatModel]
2017-09-12 16:41:59.811 -05:00 [Information] ErrorCount: 9

2017-09-12 16:42:00.222 -05:00 [Information] Dates: Start 9/12/2017 4:42:00 PM End 9/12/2017 4:43:00 PM
2017-09-12 16:42:00.222 -05:00 [Debug] AlertService._queryErrors: 9/12/2017 4:42:00 PM End 9/12/2017 4:43:00 PM
2017-09-12 16:42:00.229 -05:00 [Debug] AlertService._elasticQueryLogErrors: elasticQuery {
                    "bool": {
                        "filter":
                            [ {
                                "range":
                                { "@timestamp": { "gte": "2017-09-12T21:42:00Z",
                                                    "lte": "2017-09-12T21:43:00Z" }
                                }
                              },
                              {
                                "exists" : { "field" : "error_data" }
                              }
                            ]
                        } }
2017-09-12 16:42:00.229 -05:00 [Debug] AlertService._elasticQueryLogErrors: searchResponse 0 : Valid NEST response built from a successful low level call on POST: /filebeat-%2A/_search
# Audit trail of this API call:
 - [1] HealthyResponse: Node: http://servername:9200/ Took: 00:00:00.0066742
# Request:
{"from":0,"query":{
                    "bool": {
                        "filter":
                            [ {
                                "range":
                                { "@timestamp": { "gte": "2017-09-12T21:42:00Z",
                                                    "lte": "2017-09-12T21:43:00Z" }
                                }
                              },
                              {
                                "exists" : { "field" : "error_data" }
                              }
                            ]
                        } }
# Response:
{"took":4,"timed_out":false,"_shards":{"total":215,"successful":215,"failed":0},"hits":{"total":0,"max_score":null,"hits":[]}}

2017-09-12 16:42:00.229 -05:00 [Debug] AlertService._queryErrors: (result) System.Collections.Generic.List`1[Q2.Alerts.Core.Models.FilebeatModel]
2017-09-12 16:42:00.229 -05:00 [Information] ErrorCount: 0

这是我的巢穴查询

    public IEnumerable<FilebeatModel> _elasticQueryLogErrors(DateTime startDate, DateTime endDate)
    {
        //var startDateString = startDate.Kind;
        //var endDateString = endDate.Kind;

        var searchQuery = @"{
                ""bool"": {
                    ""filter"":
                        [ {
                            ""range"":
                            { ""@timestamp"": { ""gte"": """ + string.Format("{0:yyyy-MM-ddTHH:mm:ssZ}", startDate.ToUniversalTime()) +
                    @""",
                                                ""lte"": """ + string.Format("{0:yyyy-MM-ddTHH:mm:ssZ}", endDate.ToUniversalTime()) + @""" }
                            }
                          },
                          {
                            ""exists"" : { ""field"" : ""error_data"" }
                          }
                        ]
                    } }";

        var searchResponse = _es.Search<FilebeatModel>(s => s
            .AllTypes()
            .From(0)
            .Query(query => query.Raw(searchQuery)));

        _logger.LogDebug("AlertService._elasticQueryLogErrors: elasticQuery " + searchQuery);

        _logger.LogDebug("AlertService._elasticQueryLogErrors: searchResponse " + searchResponse.Hits.Count + " : " + searchResponse.DebugInformation);

        foreach (var searchResponseHit in searchResponse.Hits)
        {
            searchResponseHit.Source.Id = searchResponseHit.Id;
        }

        return searchResponse.Documents.ToList();
    }

public IEnumerable\u elasticQueryLogErrors（日期时间开始日期、日期时间结束日期）
{
//var startDateString=startDate.Kind；
//var endDateString=endDate.Kind；
var searchQuery=@”{
“bool”：{
“过滤器”：
[ {
“范围”：
{“@timestamp”“：{“gte”“：”“”+string.Format（{0:yyyy-MM-ddTHH:MM:ssZ}），startDate.ToUniversalTime（））+
@""",
“lte”：“+string.Format（“{0:yyyy-MM-ddTHH:MM:ssZ}”，endDate.ToUniversalTime（））+@“}”
}
},
{
“”存在“”：{“”字段“”：“”错误\u数据“”}
}
]
} }";
var searchResponse=_es.Search（s=>s
.AllTypes（）
.从（0）
.Query（Query=>Query.Raw（searchQuery））；
_LogDebug（“AlertService.\u elasticQueryLogErrors:elasticQuery”+searchQuery）；
_LogDebug（“AlertService.\u elasticQueryLogErrors:searchResponse”+searchResponse.Hits.Count+”：“+searchResponse.DebugInformation”）；
foreach（searchResponse.Hits中的var searchResponseHit）
{
searchResponseHit.Source.Id=searchResponseHit.Id；
}
返回searchResponse.Documents.ToList（）；
}

下面是在循环中运行上述代码的类的构造函数。循环可能运行数小时或数天。这可能是我的问题所在，即如何在很长一段时间内构建连接。当我关闭并重新打开应用程序时，在这段时间内运行这些查询，它们运行得很好

    public AlertService(IOptions<ElasticConfig> elasticConfig, AlertsDbContext context, ILogger<AlertService> logger)
    {
        _logger = logger;

        _logger.LogDebug(" *** Entering AlertService");
        string elasticConnectionString = elasticConfig.Value.ConnectionString;
        string defaultIndex = elasticConfig.Value.IndexName;

        var settings = new ConnectionSettings(
                new Uri(elasticConnectionString))
            .ConnectionLimit(-1)
            .DisableDirectStreaming()
            .DefaultIndex(defaultIndex);

        _es = new ElasticClient(settings);
        _context = context;
    }

公共警报服务（IOptions elasticConfig、警报SDBContext上下文、ILogger记录器） { _记录器=记录器； _logger.LogDebug（“***进入AlertService”）； 字符串elasticConnectionString=elasticConfig.Value.ConnectionString； 字符串defaultIndex=elasticConfig.Value.IndexName； var设置=新连接设置( 新Uri（elasticConnectionString）） .连接限制（-1） .DisableDirectStreaming（） .DefaultIndex（默认索引）； _es=新ElasticClient（设置）； _上下文=上下文； }

---

正如Val在评论中指出的那样，我已经确认这是我自己创造的比赛条件，因为内部计时器在呼叫Elastic时缓慢上升。这不是NEST中的bug，只是我的代码和它的时间。我已使用System.Threading.Timer将每次调用调整为一个回调，并且它工作正常。感谢Val的帮助

一条有趣的信息是，您在01:11查询最后一分钟，即从01:10到01:11。但在01:14，您查询下一分钟，即01:14到01:15，这还不能返回任何信息，因为它在未来的那个时刻。因此，问题可能在于如何计算在

范围查询中使用的日期。如果查看日志时间戳和相关范围查询，很明显它们没有正确对齐。欢迎随时更新日志，以更好地反映现实，我们可以再看一看。感谢上传新日志。但是，这个日志再次表明，这与以前的问题完全相同。您正在运行两个查询，一个在16:41:59，另一个在下一秒16:42:00。第一个查询16:41到16:42之间的数据，这是正常的，因为此时您有59秒的数据，但第二个查询16:42:00到16:43:00之间的数据，这是不正常的，因为该范围在当时的未来。我看不出您如何期望第二个查询返回任何内容。为了返回某些内容，第二个查询应在16:43运行：00@dodegaard如果您认为存在种族条件，请随时提出问题进行讨论：感谢Val和Russ Cam的评论。正如Val在我的变量计时和对Elastic的调用中指出的那样，我已经回答了这个问题。NEST工作正常。很高兴您将其排序：+1: