【问题标题】:Celery Redis backend- Make tasks in queue exist as itemsCelery Redis 后端 - 使队列中的任务作为项目存在
【发布时间】:2019-06-28 17:45:27
【问题描述】:

当前设置:celery 在 EC2 节点上的 docker 容器(使用我们的产品代码)上运行,创建和处理任务。我们的后端/代理是 Redis,在 AWS 的 elasticache 中运行。

目标:能够在任何给定时间查看队列大小(类似于花的监控),希望通过 AWS CloudWatch,但不是必需的。任务的内容不相关,因为我熟悉备份 redis 实例,并且可以使用本地工具解析备份以进行任何需要的分析。短期历史数据是非常受欢迎的(CloudWatch 可以追溯到 2 周,并且具有 1 分钟数据点的粒度,这非常好)。

根据我对 Flower 工作原理的了解,由于我们目前实施的安全组/限制数量众多,Flower 无法使用。此外,flower 仅在您在页面上时进行监控,因此不会保存任何历史数据。

Elasticache 已经为 redis 中的项目数量内置了 CloudWatch。在我看来,这似乎是实现目标的最佳途径。但是目前队列代表redis中的一项(无论队列中有多少任务)。以下是解析为 json 的 redis 备份示例:

[{
"1.api_data__cached_api_route.000":"{\"i1\": 0, \"i2\": 1, \"i3\": 0}",
"1.api_data__cached_api_route.001":"{\"i1\": 0, \"i2\": 0, \"i3\": 0}",
"1.api_data__cached_api_route.002":"{\"i1\": 1, \"i2\": 1, \"i3\": 0}",
"staging_event_default":["{\"id\":\"b28b056c-1268-4577-af8a-9f1948860502\", \"task\":{...}}, "{\"id\":\"52668c46-3972-457a-be3a-6e27eedd26e3\", \"task\":{...}}]
}]

Cloudwatch 将其视为 4 个项目、3 个缓存的 api 路由和 1 个队列。即使队列有数千个项目,它仍会显示为 4 个项目。 #(items in queue) 和 #(items in queue AND other cached items) 之间的差异很好,因为这个监控工具将主要用于查看队列是否得到可怕的备份,并且队列的大小将相形见绌缓存的 api 路由数。

要继续这条路线,最简单的答案是如果 celery 有一个配置选项,可以使队列中的每个项目成为自己的 redis 项目。如果有一个简单的修复或配置选项,它似乎是最容易实现的。以下是我们当前的 celery 配置选项:

flask_app.config.update(
  CELERY_BROKER_URL=redis_host,
  CELERY_RESULT_BACKEND=redis_host,
  CELERY_QUEUES=queue_manager.queues,
  CELERY_ROUTES=queue_manager.routes,
  CELERY_DEFAULT_QUEUE=queue_manager.default_queue_name,
  CELERY_DEFAULT_EXCHANGE=queue_manager.default_exchange_name)

_celery = celery.Celery(flask_app.import_name,
  backend=flask_app.config['CELERY_RESULT_BACKEND'],
  broker=flask_app.config['CELERY_BROKER_URL'])

opts = {
  'broker_url': redis_host,
  'result_backed': redis_host,
  'task_queues': queue_manager.queues,
  'task_routes': queue_manager.routes,
  'task_default_queue': queue_manager.default_queue_name,
  'task_default_exchange': queue_manager.default_exchange_name,
  'worker_send_task_events': True,

  'task_ignore_result': True,
  'task_store_errors_even_if_ignored': True,
  'result_expires': 3600,

  'worker_redirect_stdouts': False,
  'beat_scheduler': redbeat.RedBeatScheduler,
  'beat_max_loop_interval': 5
}
_celery.conf.update(opts)

我遇到的另一个选项是celery-cloudwatch-logs,这似乎与我想要实现的目标一致,但似乎更旨在查看每个任务的特定内容,而不是汇总(但是我可能错了)。

如果没有满足目标的完美/简单的解决方案,我将研究 celery-cloudwatch 的分叉/构建以仅上传相关信息。我们的团队继承了目前存在的大部分代码,我对 celery 的工作原理有基本的了解,但并不深入。

提前感谢任何人的想法、cmets 和帮助!

【问题讨论】:

    标签: amazon-web-services redis celery amazon-cloudwatch amazon-elasticache


    【解决方案1】:

    如果有人碰巧遇到它,我会在这里发布我所做的。

    我们已经在应用程序的其他地方安装并配置了 boto3 以进行 S3 访问,因此很容易发布到 CloudWatch。

    我在 Celery 类中添加了一个方法,以使用 redis 模块中的 llen 检查队列长度:

     @staticmethod
      def check_lengths():
        result = {}
        for q in Celery._queues:
          result[q] = Celery._redis.llen(q)
        return result
    

    然后发布到 Cloudwatch 也相当容易:

        namespace = "Celery/Queue"
        metrics = []
        for qname, qlen in data.items():
          metric = {}
          metric["MetricName"] = "ItemsInQueue"
          metric["Dimensions"] = [ {"Name": "QueueName", "Value": qname} ]
          metric["Value"] = qlen
          metric["Unit"] = "Count"
    
          metrics.append(metric)
    
        self.cw_client.put_metric_data(Namespace=namespace, MetricData=metrics)
    

    然后我最终使用 AWS Lambda 在每分钟向一个端点发送网络请求,然后将上述数据发布到 CloudWatch。

    【讨论】:

      【解决方案2】:

      要查看使用 redis 代理的队列的队列长度,只需在 redis 中使用 llen。例如,llen celery

      【讨论】:

      • 我确实遇到了llen,鉴于没有简单的配置更改,我将使用该 redis 命令自己将数据上传到 cloudwatch。我只是希望有一个快速简单的配置选项,以尽可能少地更改代码,而不是构建新架构以按分钟间隔打勾,然后再使用额外架构将数据保存到 CloudWatch。
      猜你喜欢
      • 2015-11-14
      • 2020-05-20
      • 2019-05-15
      • 2020-06-08
      • 2015-06-16
      • 2017-04-02
      • 2020-05-12
      • 2020-08-30
      • 1970-01-01
      相关资源
      最近更新 更多