【问题标题】:HostingEnviornment.QueueBackgroundWorkItem equivalent for Azure FunctionsAzure Functions 的 HostingEnviornment.QueueBackgroundWorkItem 等效项
【发布时间】:2019-01-28 16:16:23
【问题描述】:

我正在编写一个自定义记录器,用于通过网络将 Azure Functions 中的日志写入目标。这个记录器需要是异步触发的——等待每个日志写入会太慢。但是,我不希望每次主机关闭时都丢失最后几个日志条目。有没有办法注册我的异步操作以使用相当于HostingEnviornment.QueueBackgroundWorkItem 的方式写入日志?

【问题讨论】:

    标签: c# .net azure asynchronous azure-functions


    【解决方案1】:

    AFAIK,Azure Functions 目前没有像 QueueBackgroundWorkItem 这样的东西(现代等价物是 IApplicationLifetime / IHost); Azure Functions 确实在幕后使用了这些,但该级别的配置不适用于最终用户代码。在一般情况下,有 Durable Functions,但仅用于日志记录会有点过头了。

    也许您的日志记录系统需要做一些工作。我有一个 AF,它将其日志流式传输到压缩的 Azure blob。我在返回 AF 结果之前刷新它,到目前为止我对性能感到满意。

    【讨论】:

    • 谢谢斯蒂芬!我也在考虑使用这种方法:在记录器内部跟踪异步操作,并将FlushAsync 方法暴露给消费者,以便在函数完成之前调用。实现有点复杂,因为记录器作为一个单例,可以在函数的多个并发调用之间共享,我只希望一个函数等待其最后一个日志条目的刷新,但它是可行的。
    • 找到了一个相关请求,向ILogger 添加了一个FlushAsync 方法,该方法满足了这一需求:“程序逻辑中有一些点需要知道该点之前的日志事件有在继续之前已提交。这将涉及执行某种Flush 并等待Flush 完成。目前CloseAndFlush()Dispose 只能在应用程序结束时真正调用,因为两者都有效地拆除现有的日志记录管道。如果有办法在中间点Flush,那就太好了。"
    • "向ILogger 添加一个Flush 方法。这将在写入所有挂起的写入时刷新管道并解决。当然,由于可能同时引入新的写入,Flush 表示并发事件的部分顺序,但应该遵守在刷新之前写入的事件的时间因果关系。” Flush an ILogger
    猜你喜欢
    • 1970-01-01
    • 2021-11-16
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2022-10-13
    • 1970-01-01
    • 2022-08-08
    • 1970-01-01
    相关资源
    最近更新 更多