Usually I don’t write posts about this kind of things, but last week I saw an update that makes our life better, especially if we are working with Service Bus or Event Hub.
If you had the opportunity to work with one of this messaging/event system and when to production with them, I’m pretty sure (99.99%) that you had at least one exception from the messaging system that was very vague.
A large system is not using only one Topic or Queue from Service Bus. But in the logs you can end up easily with a super duper generic exception, where you might not have all information about namespace, resource and so on. Because of this you start to write in the logs information from the ‘connection’ class to be able to log all the information that are needed.
Once you get an exception from Service Bus, you usually check the status of the service, look inside the code and try to find our what is the root problem. Sometimes you find the problem and you are able to fix it.
I’m happy in the moment when I’m able to reproduce the issue. In that moment I know that I understood the context and I’ll be able to fix the problem. But not all the time we can find the problem. It’s starting to be like voodoo, sometimes our code works, sometimes we get an exception, without being able to isolate the problem.
In this situations, we go on Azure Portal and open a support ticket, where we need to specify the exception that we had. Once we done this, we will get a reply from the support team that we forgot to specify the namespace and the resource name (topic, queue, event hub, subscription, consumer group, …). We go back to our logs, get this data and send them back.
As we can see, the exceptions that are throw by this service doesn’t contains enough information to be able to track the exception and the source of the error.
Because of this we had to write in the logs additional information and to provide to the support team not only the exception, but also other information about the service. Even if based on the Tracking ID it might be possible to find the exception. This happens not because it is not possible, but imagine to try to search for an ID in storages that are not only big, but also are in a format optimize for storing and persistence with minimal costs and not for searching.
The good news is coming from Service Bus team, that enhanced the current exception message. Starting from now, we will not see only the tracking and timestamp with the exception message, but additional with them information related to namespace and resource name will be in the message exception.
This information is useful, not only for Azure support team, but also for us, making our life easier. Additional to this, there is an URL to a page that provide us more information about this error and how we can fix it. I hope that this URL will be useful, because all the time when I had exception that point also to an URL, the URL was not valid or I was not able to find the information that I looking for – I hope that URLs for Service Bus will be useful.
In conclusion let’s take a look on how an exception looks like.
If you had the opportunity to work with one of this messaging/event system and when to production with them, I’m pretty sure (99.99%) that you had at least one exception from the messaging system that was very vague.
A large system is not using only one Topic or Queue from Service Bus. But in the logs you can end up easily with a super duper generic exception, where you might not have all information about namespace, resource and so on. Because of this you start to write in the logs information from the ‘connection’ class to be able to log all the information that are needed.
Once you get an exception from Service Bus, you usually check the status of the service, look inside the code and try to find our what is the root problem. Sometimes you find the problem and you are able to fix it.
I’m happy in the moment when I’m able to reproduce the issue. In that moment I know that I understood the context and I’ll be able to fix the problem. But not all the time we can find the problem. It’s starting to be like voodoo, sometimes our code works, sometimes we get an exception, without being able to isolate the problem.
In this situations, we go on Azure Portal and open a support ticket, where we need to specify the exception that we had. Once we done this, we will get a reply from the support team that we forgot to specify the namespace and the resource name (topic, queue, event hub, subscription, consumer group, …). We go back to our logs, get this data and send them back.
As we can see, the exceptions that are throw by this service doesn’t contains enough information to be able to track the exception and the source of the error.
Because of this we had to write in the logs additional information and to provide to the support team not only the exception, but also other information about the service. Even if based on the Tracking ID it might be possible to find the exception. This happens not because it is not possible, but imagine to try to search for an ID in storages that are not only big, but also are in a format optimize for storing and persistence with minimal costs and not for searching.
The good news is coming from Service Bus team, that enhanced the current exception message. Starting from now, we will not see only the tracking and timestamp with the exception message, but additional with them information related to namespace and resource name will be in the message exception.
This information is useful, not only for Azure support team, but also for us, making our life easier. Additional to this, there is an URL to a page that provide us more information about this error and how we can fix it. I hope that this URL will be useful, because all the time when I had exception that point also to an URL, the URL was not valid or I was not able to find the information that I looking for – I hope that URLs for Service Bus will be useful.
In conclusion let’s take a look on how an exception looks like.
EventHub: EventHub(rvEventHub)/32
The service was unable to process the request;
please retry the operation. For more information on
exception types and proper exception handling,
please refer to http://go.microsoft.com/fwlink/
?LinkId=761101 Reference:bcac366a-adef-23fb-a342
027f9aw84442, TrackingId:a5e1ab540423560f10001a4b
e4368a43a_G5_B1, SystemTracker:rvEHTest:eventhub:
rvEventHub~10823, Timestamp:6/20/2016 08:43:46 AM
Comments
Post a Comment