Re-evaluate exposing additional events as part of SC integration

[gbiellem]

Hi Particles

Looking at https://github.com/Particular/ServiceControl/tree/develop/src/ServiceControl/Contracts there are a plethora of events that are published however the current ServiceControl Contracts nuget only exposes 5 of them for external integration.

The current nuget also only supports full framework. Any chance it can be updated and published as .net standard rather than full framework?

• [x] Update https://docs.particular.net/samples/servicecontrol/events-subscription/
• [x] Update https://docs.particular.net/servicecontrol/contracts PR: https://github.com/Particular/docs.particular.net/pull/5289
• [x] Show integration into alerting for example on Azure

[SzymonPobiega]

Hey @gbiellem

We didn't intend to publish these events to the outside world. Most of them are now only handled in-memory any way. Do you need any specific ones available?

Regarding the .NET standard support, let me raise a separate issue and it will be handled in the next release. We missed that aspect :-(

[SzymonPobiega]

Issue https://github.com/Particular/ServiceControl/issues/1446 raised

[gbiellem]

Hi @SzymonPobiega,

What i was specifically after were the MessageFailureResolvedByRetry and MessageFailureResolvedManually events.

[SzymonPobiega]

@gbiellem If I remember correctly we were had some concerns related to worst-case volume of these messages (the throughput of the MessageFailureResolvedByRetry can be as high as the audit ingestion). But that's something we might want to re-evaluate now that we moved to V7 of NSB and the transports are much faster.

[SzymonPobiega]

@gbiellem are you fine with me editing the title to reflect this better?

[gbiellem]

@SzymonPobiega Go for it

[gbiellem]

@SzymonPobiega I think you goofed in the rename. You've already opened an issue for ,Net Core support ( #1446). I think you meant to rename this to address reevaluating the exposed events.

[seanfarmar]

related to this and the SC PR depends on this being merged: https://github.com/Particular/ServiceControl.Contracts/issues/32

[seanfarmar]

Opened a PR for

• Contracts https://github.com/Particular/ServiceControl.Contracts/pull/40
• SC publishing them https://github.com/Particular/ServiceControl/pull/2465
• Updated documentation https://github.com/Particular/docs.particular.net/pull/5289

If we have more time I can look at

• building an Azure sample
• Incorporating the new events in https://docs.particular.net/samples/servicecontrol/events-subscription/

[seanfarmar]

New contracts done: https://github.com/Particular/ServiceControl.Contracts/pull/46 Contracts release draft: https://github.com/Particular/ServiceControl.Contracts/releases/tag/untagged-16a0073ba76443932dd6

[seanfarmar]

PR for ServiceControl: https://github.com/Particular/ServiceControl/pull/2465

[seanfarmar]

updated docs PR https://github.com/Particular/docs.particular.net/pull/5289

[seanfarmar]

Working with @tmasternak on an Azure Application Insights sample

[seanfarmar]

@tmasternak and I have a PR in progress on docs: https://github.com/Particular/docs.particular.net/pull/5289

It includes updates to the current docs and a new sample showing Azure App Insights integration

[seanfarmar]

From Slack @mikeminutillo's summary:

To summarize the conversation:

• We already publish 1 event for every failed message
• Now, if you retry, we will publish 1 additional event for every failed message
• If you archive, then we batch those notification events
• If every message is retried once, we double the number of events published
• On most transports, this won't matter much
  • For any with some kind of subscription storage (native or message-driven), we will see that there are no subscribers for these new messages and not bother publishing them
  • For any with native pub-sub, we will publish the message to the broker regardless. This puts more pressure on the broker.
  • For RabbitMQ that's probably OK. Rabbit is often much faster than we are anyway and the customer has already paid the cost of setting up the infra. There is usually not an additional cost per operation.
  • For Azure Service Bus that's probably not OK. Each operation costs money and we may be publishing events that the customer doesn't even care about. For them, they will upgrade to a new version and their costs will go up. They will have questions about that.

The outcome is that we will introduce a config flag to turn off the publishing of integration events.

• This flag allows those ASB customers to switch off these events if they don't use them.
  • Customers that don't care about any integration events will benefit from this, and we might be able to reduce costs for them
  • There may be a small number of customers that do care about the old integration events but not the new ones. I think we'd like to hear from them before we build anything more complex
• Even non-ASB customers might be interested in this because it takes the pressure off of RavenDB.
  • In high-throughput scenarios where we don't use Integration Events, I would advise turning this feature off.
  • I'd even go so far as to make it off by default, but I'd want to do that in a major with a user experience around turning it back on at runtime

[tmasternak]

Done in https://github.com/Particular/ServiceControl/pull/2465