What do you need to troubleshoot Azure?

Looking to the future with cloud computing, it is going to become increasingly important to have good information about what is happening with your site in order to properly maintain it.

Keeping development type of issues aside, what types of things do you think you will need in order to be able to properly troubleshoot a problem in your application once it is deployed to the cloud.

For example, when you publish your application, it will be similar to uploading today to a hoster in that:

  • No access to the server
  • Cannot get dumps of any processes
  • Cannot access perfmon logs
  • Cannot access the Event log

So given that type of situation:

  1. What are the possible problem situations that may arise?
  2. What types of information do you think you will require to find out what is going wrong with your application?
  3. Would you try to pull your application onto your development box to try to repro some of the problems that way?

Or are there any other concerns or thoughts you have around this?  I’d love to hear what you have to say.

Comments (6)

  1. I would like to see two key things available:

    – errorlogs

    – tracelogs

    These could be implemented using a simple singleton class that writes to a log that this then download-able or viewable online.

    This should be something that is a built-in listener when hosting the app. also, users should be able to easily add a set of functions to their code to write to the logs for diag purposes.

    It’s not very sexy, but would help a great deal.

  2. Mike,

    I agree that they would help.  What would you want logged?  Where would you want it logged to?  And how would you want to see things organized?  I have my own ideas but want to see what other people think.

  3. Rovastar says:

    I am confused by

    3. Would you try to pull your application onto your development box to try to repro some of the problems that way?

    Surely a dev would have their application on the their dev/test box first before going to staging and production. Why would you not have this? One of the first things you do is to test an app on the test/staging/etc releases to see if it occurs.

    As an IIS admin and not a dev I see the usefulness of the dev wanting the error logs, etc.

    I am sure you want the IIS logs too?

    However often the web admin will/has too filter through all the errors and they pass them to the dev in a more understandable form. A buffer between the case raised from the error occurring to analysing the problem and to identifying where the error occurs (web server tier, load balance node, network, routing, database, application, etc). So I am not sure if the initially having all this information at hand is all that useful. TBH I am not sure you will know what to do with it.

  4. Rovastar,

    So the reason I put that is for the situation where there is some data in the database that is causing some unexpected outcome.  For example, if this blog was hosted in the cloud and someone added a comment that caused a problem, I could pull down the site and hit the cloud database and have the error happen and troubleshoot it that way.

    I completely agree about the web admin, the question is if you have a web site on the cloud, who do you consider to be the web admin?  And what would you, as a developer do if the admin says that your application is hanging or running high in memory?

  5. Rovastar says:

    I still don’t get it. You should always have a local copy on you dev server. If it is a database you will have the connection strings pointing normally to the dev database.

    Now often you will not be able from you dev environment to connect to the live database. Often the infrastructure will restrict the IPs allowed to connect to the live db servers. As an admin I would be very reluctant to let you connect. Often what you have is a backup copy of the database say from the day before that devs can connect too.

    Anyway I purposely avoided you question about cloud computing. 🙂

    Would you be allowed to connect from your dev environment to the cloud computing database?  

    I think there are so many unknowns about this cloud computing? Will it really change that much? Is it just really like a bigger data centre farm with a fancy name?

    Where it will lead for an IIS admin like me I don’t know. I imagine that things will be similar to now.

    In that you have server support personnel (employed by the cloud company) and people to look after the customers applications, the admin (employed by the company owning the applications).

    I cannot imagine a multinational company wanting a 3rd party cloud looking after all their stuff least of all with no control over it. So if there probably be a more virtualization type environment.

    From a business point of view the customers will, I imagine, demand some control. Sorry for going off topic.

    If not then from a dev point of view I cannot see much you can do different. Do more testing (many (well nearly all) don’t do enough)) and hopefully get the stage were you can indict heavily that it is the admin/infrastructures fault.

Skip to main content