We’re pleased to introduce our new support site: Support.GibraltarSoftware.Com. This replaces our previous email-based support system with a new system that provides a central support ticketing system, knowledge base, and forums capability. We’ve placed our old forums site (which we inherited when we acquired VistaDB) in read-only mode so it’s still accessible but new activity will show up on the new site.
A Public Ticket System! Finally!
When we started Gibraltar Software, having a public ticketing system was one of our “pre-launch” check items. That was in 2009. Frankly, I was amazed as time went by how far we got without it. Internally, we’ve used FogBugz for years as our feature, defect, and help desk system. From our side of the table it does a great job as a help desk as long as all your interaction is via email. The minute you step outside of that, well… it just wasn’t workable. So, while we could track support very well we couldn’t provide public visibility into it.
In the last 6 months we’ve seen a real change in our user’s expectations. Almost overnight we started getting emails to support that started with “I couldn’t find a way to submit this on the site so I’m taking a guess and sending you this message” or support tickets entered through the general company contact page. In short, it was clear that people were expecting to find a system and surprised when they didn’t. This is what kicked us into gear to finally get a system selected and in place.
We reviewed a number of help desk systems and selected FreshDesk. We were looking for a system that combined knowledge base, forums, and a ticketing system. We wanted a hosted option so it would work even if our entire platform was lying on its back, feet in the air. We needed to be able to skin it so it would fit our site aesthetic to give you the comfort that this was the official place to be. In the end we went with FreshDesk because they were just more responsive, nimble, and customer focused than the alternatives we looked at. In short, more like us. We really value that.
How’s it All Work?
- Solutions: A set of knowledge base articles covering common questions and problems culled from all of the support tickets we process.
- Forums: Peer to peer community support for Loupe and VistaDB
- Documentation: You can view the full product documentation for going deep into how the products work
- Your Company’s Tickets: Any ticket you or your company has opened with us, complete with history.
If you can’t find the answer to your question, just open a ticket. We work hard to respond to these in less than one business day. Previously you had to use email to open and interact with a support ticket but now you can do it via email or online.
To see your ticket history online or post in the forums you’ll need to log in. We’ve implemented single sign-on with My Gibraltar Software, the central account site we use for all purchases, licensing, and trials. One account gets you access to everything which is a further improvement over the past.
Why Replace the Forums?
Things are very different than they were back when that forum system was started – sites like Stack Overflow now satisfy general developer communication that previously happened within each company’s forums. The key things that remain are very focused on our specific products and we wanted to provide a home that zeroed in on those needs. For example, the new system has specific capabilities for feature requests which we want to take advantage of.
We’ve had users complain because they’ve posted questions in the forums and haven’t gotten a timely, official answer from us. The forums created confusion about whether that was an official support channel or not. Often we’d post on the forums “please open a ticket for this” or end up explaining to an upset customer that while we do monitor the forums we stand back and look for peer to peer communication to happen first and foremost. This new system integrates everything together in a manner that we hope will eliminate that confusion and reduce the friction to getting the right request handled in the right way.
The other issue we’ve been struggling with is that much of the content in the old forums is obsolete. In some cases it doesn’t reflect the current capabilities of VistaDB so the advice will lead people astray. In others it reflects the philosophies and goals of the previous owners which don’t align with ours. So it felt like a good opportunity to start fresh. Naturally over time that’ll happen on this new system as answers change but the integration of Solutions (official, maintained knowledge base articles) and the forums should help us stay on top of it in a way we couldn’t before.
From day one we’ve been focused on driving our development from customer feedback and providing the best customer support possible – even in ways that other companies would consider uneconomical. Our new site makes it even easier for you to get into the loop with us: Let us know what you think of our new support site and how we can make your life easier!
When we created Loupe Server it always supported two modes of operation – a single tenant solution which was available to be installed by anyone (Loupe Server) and the Software-as-a-Service multitenant system which we operated for you (Loupe Service). Our main reason for building multi-tenancy into the code was to reduce our hosting costs so we could offer inexpensive options and healthy trials without having to create a kajillion installations. We hadn’t expected anyone else would really need these capabilities – we focused on ensuring Loupe Server scaled up to large data volumes and had internal data segregation to meet most needs. This worked for a while, but after Loupe 3.5 shipped we started getting customer requests to have some or all of the features unique to our SaaS version deployed within their infrastructure. Working with these folks we saw a few common requests:
- Load Balanced Clustering: Some shops just require everything to be active/active redundant. Others only have certain stock VM configurations so scaling “up” isn’t supportable in their environment. Regardless, they wanted to have two, four, or more servers collaborating to handle their load.
- Strict Data Segregation: Certain companies have regulatory or procedural reasons they want to create hard partitions between the log data from different environments, applications, or teams but want to share common infrastructure to lower operating costs.
- Separation of Roles: Typically for network security reasons a company may want to have distinct endpoints for receiving data, using the Web UI, and data access. Background processing servers may be separated from these for performance or network access reasons.
These capabilities were already present in our SaaS since we needed them for Loupe Service. What was missing were suitable administration tools and some detailed work to meet larger customer expectations on maintenance processes. While working through the beta project for Enterprise we unearthed a few new requirements that our SaaS could benefit from that we might not have taken on just for our own needs.
Segregating Data – Yours, Mine, and Ours
Often, different teams within an organization will want different repositories so they have complete independence to choose details like global notification rules, event handling rules, release types, and other workflow elements. While they want this independence, their organizations want to operate one set of common, high performance infrastructure. Individuals may be members of multiple teams so they should be able to access the data for every team they’re a part of. Enterprise addresses this by letting you create an unlimited number of Repositories. A repository is just like a Tenant in the Loupe Service – so most actions happen on a single repository. When Agents send in data, they send it to a repository. Each repository has its own list of users allowed to access it and their role for that repository. The set of users is common to the entire installation, so if someone in your company has access to your Loupe Server then you can add them to one or more repositories and they can move between them in the same session (without logging in again or having separate accounts). Each repository gets its own SQL Database, file folders, and search index: no data is shared between repositories. This works for organizations that may require strict segregation of where data is stored for regulatory reasons. Data retention rules are also per-repository so each team can make their own decisions about how much data to keep and for how long.
Scale Out with Clustering
There are several scenarios you might have which are addressed by clustering in Enterprise:
- Redundancy: You want to be sure regardless of whether a VM is taken out you’ll still be up and capturing information.
- Separation of Work: You want to separate the high volume data API and the background task processing, typically because you have your own custom Loupe AddIn that is doing extra work and may even need to be in a different network.
- Scalability on Commodity Systems: You may want to handle a large volume of sessions and data using virtual machines with 2GB of RAM and one core instead of scaling up a single system.
Enterprise lets you split your Loupe environment into different roles for the Web UI, API Transport (where agents send their data) and Analysis (all background processing). Each of these roles can be clustered with any number of servers. To cluster the web UI and API you’ll need some form of external load balancer but Loupe makes no requirements on it for sticky session or other advanced configuration steps. Behind these servers, data is stored in SQL Server and on the file system. You can employ multiple SQL Servers and multiple file servers (or SAN/NAS systems) to share the load as needed, provided they are all visible to all the Loupe servers in your environment.
Terabytes of Data at your Fingertips
Lets say you originally went to your storage team and got a 120GB disk for log storage. Down the road you decide you want to keep 512GB. The storage team can give you a new 512GB volume but they can’t change the original’s size. Or, you want to store 5 TB of data but your storage team will only allocate volumes 1TB at a time. These aren’t hypothetical examples – these were real customer situations when we originally gave them Enterprise. Talking with customers, we were clear that provisioning storage is something that needs to be flexible and easy in Enterprise:
- All of your data may not fit on a single volume.
- Adding and removing volumes couldn’t require taking the system down.
- Storage may be pooled for several repositories or a single repository may get its own dedicated storage, depending on the organization’s rules and requirements.
To handle this, Enterprise has Storage Pools. With these you can define multiple storage volumes and Loupe will load balance new data across them. You can even pick the load balancing approach – do you want it to fill the available volumes in order (minimizing the number of volumes used) or distribute the data across them for best performance? This system improves availability too – Loupe probes each volume in the storage pool to confirm it’s accessible and has free space. When a volume fills up or isn’t accessible it will be skipped until it comes back online. Sure, any data previously written to that volume won’t be available but at least new data will be! You can age out old storage by changing the volume to be either read only (no new data will be written to it) so as data is purged it will eventually be emptied. So if you need new storage you can create a new volume, mark the old one as read only and just wait for the old data to age out and then remove that volume completely. All of this can be done without Loupe ever missing a beat.
What’s this like in the Real World?
We’ve been using this software for a long time as our Loupe Service and completed the new features for Enterprise several months ago, at which point we’ve been running them on our extended SaaS infrastructure which processes multiple terabytes of data per day across 9 virtual servers. We’ve chosen to separate all of the roles – API access, web access, and background processing – onto separate servers to optimize web response time. (this is why you use Loupe.GibraltarSoftware.com to access the web app but your agents and Loupe Desktop connect to Hub.GibraltarSoftware.com). We have several corporate customers also using Enterprise edition – we gave them a special internal version (Loupe 3.5.7) which had the new administration tools and improvements. They helped us identify a few new use cases that needed administration tooling changes, documentation, and some other details.
How do I get it?
Loupe Server is now offered in Standard or Enterprise Edition. The only difference is the server licensing – users are the same for either. If you already have Standard and want to upgrade, contact sales and we’ll credit you your existing license to upgrade. Otherwise, we recommend organizations try out Standard edition to determine if Loupe Server is right for you and if so go ahead and purchase Enterprise. Every Gibraltar Software purchase comes with our 45-day satisfaction guarantee so you’re covered!
We’re pleased to announce that we’ve released a new significant update to Loupe, version 3.6. What’s new and great?
- New Issue Management Dashboard: A quick way to find the key issues and events for each phase of your development project. Read Manage Events in Development, QA, and Production with Ease to dive deeper.
- New way to View Massive Logs: When you have a multi-million message log file you still need to be able to view it, now made a lot easier. Check out View Massive Logs for the full scoop.
- Enterprise Edition: You can now supersize your Loupe server installation with clustering and other scale-up features with our new Enterprise edition. For a comparison of features, see Editions Comparison.
- Server Scalability Upgrades: To support our largest customers we’ve made performance enhancements throughout Server including making the web UI snappier and handling massive volumes on a single server.
There are a number of smaller enhancements too all aimed at improving the usability of the system. You can switch between applications within the same product quickly, there are more cross-links for in-place editing of metadata, we’ve revised labels based on user feedback and added HTML optimizations for extra-short displays on modern ultrabooks. Check out the release notes for a comprehensive rundown.
The Story Behind the Release
At the start of this year we did a significant amount of planning for Loupe 4.0 – wireframes, user stories, walkthroughs of key features, etc. We then presented this to our key beta customers and other advisers to get feedback. Meanwhile, we were delivering Loupe 3.5.7 – Enterprise edition to the first external customers. As development was getting underway, we dug deep into metrics for how customers were using Loupe Server – from our SaaS platform and from a random sampling of customers. The data raised a lot of questions from the team – we weren’t seeing some usage patterns we expected, and that meant our customers weren’t getting as much value from Loupe as they should. For example, we think every team should be using the web user interface that came out in Loupe 3.5 and then a subset of their team would use Loupe Desktop to drill in deep but instead we saw relatively light use of the web interface.
We reached out to pretty much every Loupe Server and Service customer and asked if they could spare 30 minutes to talk with us about how they used Loupe. We got a lot of takers and after interviewing them we identified several common reasons why users were sticking just with Loupe Desktop:
- Users assume the Web interface is a subset of Loupe Desktop and don’t ever try it (since that’s nearly always true when you have both a dedicated app and a web interface.
- Users couldn’t identify errors for key recent versions (like just production errors or just development errors) so they were sifting through data by hand in Loupe Desktop
- Users perceived it takes too much effort to manage the review list, particularly once it has thousands of events on it.
- The extra work to create issues in Loupe felt like it duplicated their defect tracking system.
The good news was that we had already identified user stories for Loupe 4.0 that would address some of these items, but we didn’t want to wait until a major release to address these if at all possible.
Instead, we turned what had been a maintenance release (3.5.7) into a major enhancement (3.6) so we could get some improvements out the door as soon as possible to help address this. In particular, we’ve field tested the new Issue Overview page to make sure it squarely addresses #2 and #3 above. We’ve added documentation and some training materials to help address #4 and you’ll see some new communication from us to address #1.
What’s the Upgrade Like?
Loupe 3.6 maintains all of the compatibility characteristics of Loupe 3.x so you can continue to freely mix agent, server, and desktop versions. The Desktop enhancements don’t depend on the updated Server version. The Server upgrade takes a few minutes due to a major index change, somewhat longer for large databases (10GB and up). Thanks to an upgrade to the Lucene search engine on the server full text search isn’t available right away after upgrading until the index is rebuilt (which happens automatically).
While building the roadmap for Loupe we’ve been doing a lot of interviewing – of existing users, customers, prospects, and the community. We got a lot of feedback on how well the Events & Issue features are working for real users in the field. What showed up in many conversations was it took too long for people to get the hang of what they should do, where, and when to really get value out of Loupe Server.
In particular, we’ve zoomed in in some key questions people want to answer quickly in Loupe Server:
- Are we better off shipping our latest build?
- Are we getting better over time?
- What are the main issues in production?
To answer these questions we created a new Issues Overview dashboard. If you were only going to use one page in Loupe Server, this is the one – you can pick your level of concern (production activity down through internal development builds) and then it’ll tell you how you’re doing, which issues (if any) you really should fix if you have the chance, and what are the most interesting runtime events to check out.
We get it, you could have a lot of events going on – sometimes thousands of them. You have time to only look at a few and you need us to find them for you. We identify the most important events you should check out to see if they’re really defects you need to fix or something that you can ignore.
We removed massive lists of issues or events from the overview because when you see a list with more than 10 or 20 items you stop reading them and just think “wow, that’s a big pile of work. How about I go find a better use of my time, like watching YouTube videos..” Instead, we pick the most relevant 20 items and it shouldn’t show you more than 10 of them at a time. We validated the selection process with our own use of Loupe as well as key beta customers to ensure the critical items were always in that top 10.
Multiple Hats Welcome
Many of our users perform multiple roles in their organization – they may be a technical lead for new development, providing production support, managing QA, or overseeing a beta program. After interviewing a number of customers we came to see that while many move between roles at any one time they’re focused on one aspect of their data – production, beta, QA, or development. That’s where we got the idea for how the Issue Overview page needed to work – it needed to start by asking what perspective you wanted then just “do the right thing” to figure out what you wanted to know.
Fortunately, Loupe already has a concept of Release Types to distinguish versions by how far they get in your development process. Let’s say you have a Continuous Integration (CI) environment that does a build every time there’s a check in. Each of those builds gets a unique version – but most of them don’t go anywhere. By default, Loupe considers them all Internal versions, the lowest Release Type.
If a particular version is sent off to a group of external users to try out you would promote that version to Beta – since it left the premises it’s automatically more important than ones that only existed within the development team. If you publish a version to the world then that’d be a Release version. You can customize the release types to your particular organization – perhaps you want to go Development->QA->Certification->Production.
By letting you select a release type to view information from we’ve eliminated noise – things that aren’t interesting to you (at least not right now). For example, if you’re running the beta program of your latest application you probably don’t care about what’s happing with the last production release but you do care about how the next internal version is doing.
Finding the Right Versions
Once you’ve selected the release type you want Loupe picks key versions – the latest version of that type, the previous significant version, and the latest version of the next lower release type (the best candidate to be promoted). Here’s the current view for Loupe Desktop on our CEIP system
You can see that by default it’s picked the current release version (220.127.116.119), the previous release version (18.104.22.1683), and our last beta we published (22.214.171.1241) - which we could choose to ship as a release version. Between the current shipping version and our last beta no new issues were detected and one issue was resolved, so we know we’re better off with this beta than what’s currently shipped.
Interestingly, it skipped the 126.96.36.1993 Release version. Why? Loupe recognizes the case with releases where you have a rapid hotfix and skips over those versions to get back to the next previous significant version. This is done by scanning the version numbers in use for an application and looking for a variation in the first few places (excluding any build number). Click on any of the metrics – new, resolved, open for any of the versions it has selected gives you a list of all of the related issues.
We’re now in a position to answer the key questions raised at the top:
Are we better off shipping our latest build?
This can be answered from the Next Version metrics:
- The Open list lets you know on balance if things are better or not.
- The Resolved list shows you if you’ve really made life better by fixing things users have experienced.
- Be sure that anything in the New group is innocent enough to ship.
Are we getting better over time?
Compare the Open counts of the Previous Version, Current Version, and Next Version. Are the numbers going down or up? If they’re going down, you’re headed in the right direction!
What are the main issues in production?
Look at the Open list on the Current Version. This is the complete list of issues impacting users right now.
I’m Sold, Where is it?
Once you’ve upgraded to Loupe 3.6, just click on any application badge from the All Applications dashboard or click on Issues in the header and you’ll see the Issues Overview for that application. We’ve added some instructional prompts to the page so if there’s something you should be doing to make it more useful (like categorize your releases or use version numbers) it’ll let you know.
Thanks to everyone who gave us feedback – this is one example of new capability that wouldn’t be here without the open input we got from the community.