Archive for Product Information
New Features of Gibraltar 3.0 #1 – Live Logging
Posted by: | CommentsJust yesterday the paint on all those new ones and zeros dried and we ushered out the latest version of Gibraltar, (3.0.0.1040 for those of you version geeks out there). More information about the release can be found elsewhere on the blog, and more in depth information about Gibraltar can be found here.
Every day this week I’ll be blogging about a new feature of Gibraltar 3.0, today we’re going to start with the Live Logging feature that lets you remotely view logs of your .NET apps and services in real-time. Now since it’s always easier to “show” rather than “tell”, I’ve prepared a little video describing the feature. Take a look and let me know what you think in the comments. All feedback is welcome, other than, “Hey, you’ve got a really dumb accent”, as it turns out there’s nothing I can do about that. 
Gibraltar 3.0 Released
Posted by: | CommentsWe’re thrilled to announce the release of Gibraltar 3.0! It’s been three betas and a release candidate, along with a number of private betas but finally we’re ready to release the hounds. You can jump strait in and download it now, or read on for what’s new in 3.0.
What’s new since Gibraltar 2.5? A lot:
- Super Sized Session Handling: Edge to edge we’ve focused on long running processes, really large log files, and all the implications of this.
- Real-time Log Viewing: You can see what’s happening within Windows services & web sites in real time, faster than anything else on the market!
- Hub Support for SQL Server: You can store index data for the Hub in SQL Server for better scalability and reporting options.
- Dramatically Smaller Files: We’ve deeply dug into our log file compression and found ways to reduce files by 70%.
- Analyze Session Summaries: The built-in pivot table and chart in Analyst can slice & dice session summary information to spot all kinds of trends across all of your data.
- Categorize Sessions by Environment and Promotion Level: Go beyond Product & Application to separate data based on where it was run or the status of the release.
- Hub Synchronization Options: Save hard disk space on your workstation by downloading sessions on demand.
- NuGet Packages: You’ll find all of the various agents for Gibraltar are now available on NuGet, and it’s a great way to stay current. Any package published under “Gibraltar Software” is official and supported.
- Mono Support: You can now use the Gibraltar Agent with recent versions of Mono.
- 64-bit Analyst: Analyst can now take advantage of all of the memory you can find. We’ve made a number of changes to reduce how much it uses just the same.
That’s the highlights, but there are a hundred changes in the detail. The big thing they add up to is we’ve aggressively tackled issues that prevented data from getting from Agent to Analyst. We’ve combed through our CEIP data to make sure we could deliver on the promise that it all Just Works.
You can read about more of the details in What’s New – Gibraltar 3.0 (from our documentation).
Upgrade Options
If you have active maintenance on your Gibraltar licenses then you’re free and clear, just download it and go. Since it’s a major release it’ll activate, so you’ll want to install it when you’ve got Internet access.
If you don’t have active maintenance, contact us for the right upgrade pricing. Depending on when your maintenance expired you’ll need to purchase the right version upgrade and then you can re-enroll in our upgrade assurance program to get the next 12 months of updates for free. You’ll want that, because we have a lot up our sleeve!
What’s Next?
We’ve bee eagerly waiting to ship 3.0 so we could dig into the next development cycle. We expect to ship Gibraltar 3.5 later this year and another update in the winter. Each of these will build on Gibraltar 3.0 and are designed to help you get a lot more from the data you’re already collecting. So, it’s a great time to upgrade to 3.0!
Gibraltar 3.0 RC – Ready to Rock
Posted by: | CommentsWe’ve shipped Gibraltar 3.0 RC1, the release candidate build of Gibraltar 3.0. This is our last planned build prior to the Release To Web (RTW). Compared to the last beta we’ve incorporated a range of defect fixes from our CEIP data as well as performance improvements just like you’d expect. Beyond that, we’ve incorporated several improvements that our beta community felt were critical enough to warrant making changes late in the development cycle.
We weren't kidding about millions of rows in a single session.
To download the latest build, we recommend you go to the Version History page and pick the top version under Other Version Information. As with previous betas, you can use this with any valid Gibraltar license key (trial or unrestricted). You will need current maintenance on your unrestricted key. If your maintenance has expired, contact us and we’ll get you set up to try out this latest version and discuss your upgrade options.
Working Fluidly with Sessions
Talking with the beta community we’ve seen that people are able to really take advantage of the scalability improvements in 3.0, in particular opening dramatically larger session files and keeping much larger repositories. This created a few new feature requests we’ve managed to slide in for the release candidate:
- Independent Session Display: With larger sessions and repositories it was understandable but annoying when UI updates would pause the entire application. We’ve separated out the user interface threads so each session viewer and the repository viewer have their own, keeping them from interfering with your work.
- Selective Session Download: You can pick individual session(s) to download data for immediately and they’ll copy down right away without blocking you. This is particularly useful if you want to download a large session to complete analysis on it or view later but don’t want to open it right now.
- Parallel Download: When you have Analyst set to download all session data automatically it used to first download summaries then full data. If you had a lot of data that meant you weren’t seeing the latest session headers until it completed downloading the backlog of data. We’ve made these two operations independent and done other optimizations so you can see the latest session information right away, no matter how long it’s been since you ran Analyst.
We also found out from beta users that in the real world they would frequently try to open sessions that didn’t have any local data and the way the system acted (displaying a modal message box) was not very friendly. As part of making the session display independent we’ve improved how it checks and downloads data to work in the background so it doesn’t interrupt your workflow. Instead, you’ll see a warning in the status bar
Fortunately, we’ve also found a number of cases where session data should have been available but wasn’t. We’ve gone through the CEIP data from beta users as well as our own test cases and weeded these cases out. When the session data is available, you’ll see the progress of it opening the session in the status bar instead.
Live View Changes
Earlier betas had two ways of displaying live sessions – there was a tab on the repository viewer and you could double-click a session to open it into a live view like a local session. Displaying the live data in the tab had several problematic side effects – it was easy to open many data streams unintentionally by cycling through the session list with the live data tab active and there was no way to let Analyst know to close them. Additionally, it caused the available space for the list of sessions to be very small.
Talking with a few users that are really taking advantage of live view we determined it was better to provide more space for the list of sessions and make it more explicit when the full stream is opened and closed. With the latest build we’ve changed it so a new live stream is established when the live session view is opened and it’s shut down (all the way back to the original agent) when the live session view is closed.
Faster, Scalable Analysis
With it being easier and easier to get larger sessions through Gibraltar we’ve had to make upgrades across the board. One place we’ve improved for 3.0 is how Analysis is performed. Previously, it would load all of the available data in memory and analyze it together. Conceptually this was the simplest and fastest approach, but it has two problems:
- Sessions have to fit into RAM: If you had a large enough session, it might not actually fit into available memory when loaded all at once.
- Memory was Thrashed: Even when you have a lot of memory it takes real work and can make your application unresponsive if it’s being allocated and freed by the Gigabyte.
Notifications are Back
We use notifications to monitor the hub itself!
Previous 3.0 builds didn’t support Hub notifications, either editing them or processing them. This functionality is back and better than ever in 3.0 thanks to our new session analysis approach that minimizes duplicate analysis when used with a 3.0 Agent.
If you’ve never used notifications, or were discouraged previously because they weren’t fast enough you should give them another look. With the combined changes in Agent and Hub the time between when something happens and when you get the email is a lot shorter, even under load.
As before, it’s still smart enough to group problems together so you won’t get spammed with email yet it focuses on getting events out as quickly as it can. You can choose to get HTML-formatted messages (like the one shown on the right) or plain text.
Ready to Use with the Hub Service
We’ve upgrade our public hub service (hub.gibraltarsoftware.com) to a 3.0-compatible build so you can freely use it with the Release Candidate. We’d encourage you to give it a try because the difference, particularly for web applications and services, is amazing. We’ve been internally using 3.0 for some time- tracking pretty closely to our nightly builds. Some of our largest customers have been using it live in production since Beta 2.
We’re confident enough in this build that we’re providing full production support for it – if you use it in production, we’ll provide you with the same support we do for a full release. So go ahead and use it!
From Here to RTW
What’s left before Release to Web (RTW)? Not much. We’re down to:
- Documentation Upgrades: We’re going through the documentation looking for any content that might be out of date and extending it to cover new features.
- Packager Improvements: To help with .NET 4.0-only deployments we’re creating a new .NET 4.0-only packager. This will have a different file name so it doesn’t conflict with the .NET 2.0 packager.
Other than that, it’s really up to you – let us know your feedback so we can be sure we’re on the mark and ready to go.
Getting to Know Gibraltar – Swapping Trace For Log
Posted by: | CommentsYou’ll recall from the last post that we have the following code:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Diagnostics;
namespace GibraltarGettingStartedApp
{
class Program
{
static int Main(string[] args)
{
Trace.WriteLine("About to Blow up...");
int zero = 0;
try { return 1 / zero; }
catch (DivideByZeroException e)
{
Trace.WriteLine("Error: " + e.Message);
}
Trace.Close();
return 0;
}
}
}
Showing us that we can get Gibraltar working with the Trace code that we already had in our code base. That’s a huge advantage if you are already using the Trace functionality in your code.
However, as you start working with Gibraltar, you’ll find that it supports it’s own logging API that offers several distinct advantages over Trace.WriteLine. There may come a time when you wish to take advantage of our better API. If so, you’ll want to swap out all of your Trace commands or, if you have a very large application, you may decide just to swap out the calls in a particular area. In this post, we are going to examine how easy it is to do that.
In turns out all that’s required is to replace the calls to Trace with calls to Gibraltar’s Log class. There is no need to touch the Gibraltar “plumbing code” at all.
Doing that, it looks like we’ve hit our first little wrinkle. While Log does have it’s own versions of Trace’s TraceInformation, TraceWarning and TraceError, there’s no direct analogue for Trace.Writeline. We used WriteLine because we wanted to do the simplest thing that worked. This means instead of just replacing Trace with Log, we can take this opportunity to move to a more rich method. Also, as there is no analogue for Trace.Close, so we’ll change our code to use Log.EndSession. Having made these changes, our code now looks like this:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Diagnostics;
using Gibraltar.Agent;
namespace GibraltarGettingStartedApp
{
class Program
{
static int Main(string[] args)
{
Log.Verbose("About to blow up...");
int zero = 0;
try { return 1 / zero; }
catch (DivideByZeroException e)
{
Log.Verbose("Error: " + e.Message);
}
Log.EndSession();
return 0;
}
}
}
And as we can see, from Gibraltar Analyst, everything still works as expected:
So, we have successfully swapped out Trace for Log and not broken anything, great!
However, now that we’ve made the swap over to Log, we can take advantage of it’s overloaded methods to provide more information. Instead of just passing a string to Trace.TraceVerbose, when we are using Log, we can pass the exception too, which allows Analyst to capture it:
Of course, once we have successfully moved from Trace to Log we can take advantage of the richer API available with Log. Sticking with the example of logging information we can change our code to capture Category and caption along with our message:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Diagnostics;
using Gibraltar.Agent;
namespace GibraltarGettingStartedApp
{
class Program
{
static int Main(string[] args)
{
Log.Verbose("Examples",
"About to Blow up...",
"Additional details can be provided for each log message");
int zero = 0;
try { return 1 / zero; }
catch (DivideByZeroException e)
{
Log.Verbose(e,
"Examples",
"Error: " + e.Message,
"Exception type: {0}",
e.GetType().Name);
}
Log.EndSession();
return 0;
}
}
}
And, as you can see, Analyst has recorded the category:
And the caption:
And the formatted description:
I mentioned that the Gibraltar API had a couple of advantages over the Trace API, we won’t go into them in detail here but one of them, which I think is very cool, is that the API will fail safe with regard to the format string. If you pass too many objects with regard to placeholders, like so…
using System;
using System.Collections.Generic;
using System.Linq;
using System.Diagnostics;
using Gibraltar.Agent;
namespace GibraltarGettingStartedApp
{
class Program
{
static int Main(string[] args)
{
Log.Verbose("Examples",
"About to Blow up...",
"Additional details can be provided for each log message");
int zero = 0;
try { return 1 / zero; }
catch (DivideByZeroException e)
{
Log.Verbose(e,
"Examples",
"Error: " + e.Message,
"Exception type: {0}",
e.GetType().Name,
"This shouldn't be here!",
"Nor should this!");
}
Log.EndSession();
return 0;
}
}
}
Then Gibraltar won’t throw an exception, but will in fact continue to work as expected, matching the first object to the placeholder and ignoring the rest. Neat, eh?
If you make the inverse mistake, having too many placeholders, then Gibraltar will still work, but will record that error too, like so:
You should also check out these methods: Log.Critical, Log.Error, Log.Warning and Log.Information or see the complete API for the Log class.
Well let’s end this post here. Today we’ve looked at preparing our code to swap from Trace to Log, we’ve swapped to Log, using the analogue of the Trace methods, and then we’ve improved our logging by using the richer API available to us when we use Log.
Next time we’ll look at swapping out Log for a third party logging solution. Until then… happy coding! 
