MassTransit 3 подавляет элемент host в полезной нагрузке сообщения

Недавно я обновил одно из наших решений с MassTransit 2 до 3, и после обновления мы заметили, что MT 3 добавляет дополнительную информацию о хосте к полезной нагрузке сообщения (деталь опущена):

{
    "messageId": "guid",
    "conversationId": "guid",
    "sourceAddress": "rabbitmq://rabbitserver/source",
    "destinationAddress": "rabbitmq://rabbitserver/destination",
    "messageType": [
        ...
    ],
    "message": {
        ...
    },
    "headers": {},
    "host": {
        "machineName": "...",
        "processName": "...",
        "processId": 1234,
        "assembly": "MassTransit",
        "assemblyVersion": "3.1.2.383",
        "frameworkVersion": "...",
        "massTransitVersion": "3.1.2.383",
        "operatingSystemVersion": "..."
    }
}

Мы хотели бы запретить добавление информации о хосте или переименовать ее, поскольку это вызывает конфликты в нашей системе.

Я рассмотрел создание промежуточного программного обеспечения, как указано здесь: Добавление значений в заголовок в MassTransit. RabbitMq, но, похоже, не может получить доступ к данным, чтобы удалить их, и после быстрого просмотра кода из github я не вижу возможности не отправлять информацию о хосте. Я что-то упускаю или есть способ удалить/переименовать эти данные при публикации сообщения?


masstransit
person Ian Cotterill    schedule 02.02.2016    source источник
comment
Как это конфликтует? Он находится на уровне выше вашего тела сообщения. Суть в том, что добавление возможности отключить его потребует изменения кода.   -  person Chris Patterson    schedule 02.02.2016
comment
Проблема в том, что сообщения потребляются нашим мониторингом, который уже ожидает, что хост будет строкой, а не объектом. Его изменение потребует изменений во всем. Похоже, что сообщение добавляется сериализатором json при создании конверта сообщения json. Можно ли заменить конверт сериализатора/сообщения json по умолчанию?   -  person Ian Cotterill    schedule 02.02.2016
comment
Но если Host является строкой в ​​теле вашего сообщения, она все равно должна быть строкой в ​​теле вашего сообщения. Можете ли вы опубликовать свой контракт на сообщение?   -  person Chris Patterson    schedule 03.02.2016
comment
Проблема не в общественном транспорте или кролике, а в том, что читает elasticsearch, который затем неправильно настраивает индекс. С этой стороны это можно обойти, я просто надеялся, что есть способ запретить отправку.   -  person Ian Cotterill    schedule 03.02.2016
comment
Помогите мне понять. Вы храните свое тело сообщения в ES или ConsumeContext (который включает в себя сообщение)? Похоже, у вас есть путь вперед, но я все же хотел бы понять, как добавление в ConsumeContext повлияло на вашу индексацию в ES. Мы также используем ES, и мы фактически регистрируем весь ConsumeContext, чтобы у нас был InitiatorId, чтобы иметь возможность связывать события вместе, поэтому мне любопытно.   -  person Chris Patterson    schedule 03.02.2016
comment
Извините за медленный ответ - ES, естественно, не моя область, поэтому хотел бы получить немного больше информации, прежде чем отвечать. Мы используем событие из очереди кролика полностью, а затем используем logstash для форматирования сообщения по мере необходимости — иногда удаляя полезную нагрузку, иногда нет. Большинство наших производителей мониторинга добавляют строку хоста в сообщение, поэтому мы ожидаем, что хост будет строкой. Когда мы находим объект, события отбрасываются, так как наш ES ожидает строку. Мы думаем, что можем отсортировать его с помощью logstash, но на данный момент мы не пробовали.   -  person Ian Cotterill    schedule 08.02.2016