AMQP(rabbitmq)识别错误消息的来源 [英] AMQP (rabbitmq) identify origin of bad message

问题描述

在rabbitmq中识别(坏)AMQP消息来源的最佳方法是什么?

What is the best way to identify the origin of a (bad) AMQP message in rabbitmq?

该方案是多个客户端将消息发布到服务器，如果成功，则会将消息发布到扇出交换机(供发布/订阅使用). 客户端也是该队列的订阅者，并且没有自己的应答队列.

The scenario is several clients posts messages to a server which if successful result in messages posted to a fanout exchange (for pub/sub use). The client is also a subscriber to this queue and does not have a reply queue of its own.

如果服务器认为邮件无效，则会对其进行处理并丢弃.

If the server decides a message is invalid it nacks and discards it.

我们还需要另外两件事:

There are two additional things we want:

• 发布一条消息，客户端或监视系统可能会使用该消息说停止向我发送垃圾"
• 记录有关错误消息的诊断信息

什么是合适的策略?

哪些标头字段适合标识邮件的始发者?

还有其他考虑吗?

appid 标头字段可以标识正在发送的应用程序，但仅凭它本身是不够的，因为在一台或多台计算机上可能有多个实例.

The appid header field can identify the sending application but it is not sufficient by itself as there could be multiple instances on one or more machines.

错误的客户端可能会使用 messageid 来标识其发送的消息(客户端可以分配或访问该消息).

A bad client could perhaps use the messageid to identify messages it sent (can this be assigned or accessed by the client).

例如，监视系统(例如prometheus + kubernetes)将需要更多尝试来消除不良的客户端进程.

A monitoring system (e.g. prometheus+kubernetes) would need more to try and kill the bad client process for example.

我假设一种适当的方法是要求客户端设置某些标头字段.

I'm assuming an appropriate approach is to require clients to set certain header fields.

第二，对于不符合我们要求的客户，我们该怎么办?

Secondary to that what can we do for clients that fail don't meet our requirements there?

推荐答案

我对AMQP的经验有限，因此，如果可以的话，请对此进行改进

I have limited experience with AMQP so please improve on this if you can

使用 host + pid 识别进程

appid是自由格式，因此一种方法可能是在其中包含多个应用程序ID.例如

The appid is free form so one approach might be to include more than just the application Id in it. e.g.

appid: applicationid.serverip.pid

这似乎扩展了"app id"的语义，但是

This might seem like stretching the semantics of "app id" but app_id is entirely application defined. An application can identify itself with the "app id" with a simple string comparison.

允许使用任意键值基本属性，因此您可以代替/也可以添加以下属性:

arbitrary key values are permitted on top of the basic properties so you could instead/as well add properties like:

origin-host: serverip
origin-pid: pid

与使用诸如app_id之类的内置"字段相比，这可能需要少量的额外编程工作.与此相关的还有一个小的在线交易"成本(自定义属性被序列化为位置参数在邮件标题中，而不是在关联数组中保存带宽). 相对于解码 appid 字段中的字符串，可能需要进行权衡.

This may require a small additional programming effort over using 'builtin' fields like app_id. There is also a small 'over the wire' cost associated with this (custom properties are serialized as positional arguments in message header instead of associative array to save bandwidth). There may be a trade off with this versus decoding the string in the appid field.

您还可以设置死信交换来保存消息本身，但是消息将需要操作员干预才能使用.因此，我认为这只会对诊断有所帮助.

You could also set up dead letter exchanges to hold the messages themselves but the messages would require operator intervention to make use of. So I think this would only help with diagnostics.

这篇关于AMQP(rabbitmq)识别错误消息的来源的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！