To be a Web professional is to be a lifelong learner. The ever-changing landscape of our industry requires us to continually update and expand our knowledge so that our skills do not become outdated. One of the ways we can continue learning is by attending professional Web conferences. But with so many seemingly excellent events to choose from, how do you decide which is right for you?

During the course of my career, I have had the good fortune to attend a number of conferences, workshops and professional events. I am often asked by Web professionals who are preparing to attend their first conference how they can select the right one for their needs.

In this article, I will share the methods that I have found helpful in choosing high-quality conferences, as well as some tips to help you get the most out of the events you decide to attend.

What Are You Looking For?

The first step to finding a high-quality conference is to decide what you are looking for. Every conference is different. Some focus more on the technical aspects of our profession, while others offer a diverse set of presentations, some that are inspirational or even business-focused that complement ones about code and other technical topics.

Check out a list of Web design events taking place from January to June 2014. (Image credit: opensource.com)

Personally, I have always enjoyed conferences that feature a varied set of topics and speakers, but your needs may be different than mine. Furthermore, your needs may change throughout your career. If you have to learn a new technology, perhaps for a project you are working on, then an event focused on that particular topic might be exactly what you need at that point.

Once you have a general sense of what you are looking for in subject matter, the next step is to do some research.

Research The Sessions And Speakers

Start your research by visiting a conference’s website and reading about the sessions. I typically look for topics that I am already knowledgeable about, as well as areas that I know little to nothing about but would like to be introduced to.

In my experience, finding a conference that reinforces and expands skills that you already have while exposing you to aspects of the industry that you are not as familiar with will give you a more well-rounded experience than simply revisiting topics that you already count among your strengths.

If session titles and descriptions have yet to be posted, then you can get a feel for the topics to be covered by looking at the speakers listed for the event. Most speakers specialize in a particular area, such as CSS, usability or content strategy. A recognized expert in content strategy will likely speak about content strategy in some form, so by reviewing their individual website and learning more about their work and expertise, you will generally get a sense of what their session will be about.

This is important for small events, whose available spots are limited. These events often sell out quickly, before the exact nature of the sessions is even announced, so getting a feel for the content by researching the speakers might be the best way to come to a decision before tickets are all gone.

In addition to sessions, many conferences offer optional full- or half-day workshops, which typically focus on particular topics in much more detail than normal sessions. So, if you are looking to learn more about a topic, consider adding a workshop to your plans.

Cost

The sessions are an important factor in choosing the right conference, but they are not all you must consider. Cost is another critical aspect.

The cost of attending a professional conference can be significant. I have seen tickets range anywhere from a few hundred dollars for a one-day event to a few thousand for a week-long conference. Before you look for an event, determine a budget. Whether you are paying or your company is picking up the bill, knowing what you can afford will help to immediately narrow your options.

If your company is paying, you will likely need to explain the event’s value and justify the expense. Resources such as Smashing Magazine’s “8 Reasons Why You Should Send Your Incredibly Hard-Working, Deserving Employee to the Smashing Conference” can help you make your case. Other conferences offer similar resources to provide to the decision-makers in your organization from whom you will be seeking approval.

Timing

Timing is also important. Finding a conference that works with your schedule, including the timelines of your clients, projects and other obligations, is sometimes tricky. I typically try to book a conference well in advance, when my schedule for that period has yet to be filled. I then work my future appointments and project work around it. I find this easier than booking an event late and then squeezing it into what little free time I have left. Booking in advance also allows you to take advantage of early-bird pricing, as well as to avoid being disappointed by sold-out tickets.

Get Away If You Can

The last consideration is location. Ticket prices can be high, and travel expenses (including transportation, accommodation and meals), if the conference is outside of your area, adds significantly to the cost. Still, getting away can really improve the experience.

Traveling makes a conference more of a special occasion. It’s not a vacation, but it is a break from your normal routine. If you commute from home, then you’re more likely to treat the end of the day as the end of any other work day, skipping after-conference gatherings and activities (more on these shortly) which are the most valuable asset of every conference experience. Being away from home helps you to avoid falling into your normal routine and immerses you more fully in the event.

When figuring out your budget, factor in travel costs so that you can consider events away from home. This is not always practical, and you might be restricted to conferences in your city or nearby (if you are lucky enough to live next to a city that hosts professional Web conferences). But if you can find the budget to travel, seize the opportunity!

Prepare To Be Social

Web conferences open you to fresh ideas and approaches, while energizing and exciting you for work. Education and inspiration are not the only benefits, though. Socializing with your colleagues in the industry is an important part of the experience, too. And to truly realize this benefit, you must put yourself out there and be social.

Most events that I have attended over the years included meals for attendees — typically, breakfast and lunch. I always get to the venue early on the first day to grab some breakfast. As I enter the eating room, I look for people to join and introduce myself to. After introductions and some conversation, I’ll know a bit about them and have begun to make connections.

I repeat this process at lunch and every day of the event, finding new people to meet each time. Over the years, I have met some incredibly cool people, and I maintain contact with many of them — typically, through email and Twitter. These relationships have become extremely valuable to me, giving me peers to bounce ideas off, share new work with and turn to for help.

I remember a project from a few years ago in which a tricky bit of CSS was giving me problems. I tweeted the issue, asking for help. Within minutes, two fellow front-end developers whom I had met at separate conferences each replied to me with workable solutions. That is powerful, and it was the result of putting myself out there and being willing to meet new people.

In addition to meals, some conferences hold “jam sessions,” which encourage attendees to interact and present their findings to each other. This is another opportunity to be social, so don’t be shy! Get out there, meet new people, ask questions, share your experiences, and begin forming lasting, worthwhile relationships with others in the industry.

Party Time

Every conference I have been to included some kind of after-party. Absolutely take advantage of these opportunities. Sadly, many attendees decide to skip them.

As mentioned, if you are close to home, you’ll be tempted to blow off the after-parties and get back to your normal routine. Doing so, however, will rob you of another chance to meet interesting people and form worthwhile relationships. While I have certainly met great people at mealtime, upbeat after-parties have an even better atmosphere in which to connect with other professionals.

Some people I have met at parties have become not just professional contacts, but friends. I would not have made those connections had I decided to go back home or to my hotel room.

When going to a conference, be ready to socialize. (Image credit: Kris Krug)

Adjust your schedule to arrive early enough to enjoy breakfast and late enough to attend the after-parties. Have business cards on hand, and do not be afraid to ask others for their card or contact information.

This doesn’t mean turning the event into a pure networking session, where all you do is gather cards and email addresses. But if you meet someone whom you enjoy speaking with, ask for their card and reach out to them after the event. Remember, socializing and networking are as important as learning and being inspired, so put yourself out there and make some connections!

Leave Work At Work

To get the most out of a conference, focus on the event itself and put work aside for a bit. This can be challenging, especially if you are a freelancer with no one back at the office to cover for you. But focusing on a presentation or conversation is hard when your attention is on the current work project open on your laptop.

For years, I would bring projects with me to conferences to stay on top of the workload. Even if I wasn’t working on a project, I would have my laptop or tablet ready to reply to all emails and would remain constantly available to clients and colleagues. After a while, I realized that I often focused more on my device than on the presenters. That is a problem, and I realized that I needed to make a change.

For the last few conferences I have attended, I have left my computer in my bag during sessions. No working on projects. No checking email. I just focus on the presentation. I instead use breaks between sessions or time after lunch to quickly respond to any critical emails, leaving less important communication for when I return to the office.

Even doing so, I am careful not to cut into the conference’s social time, and I restrict myself to a few minutes to handle issues that simply cannot wait. In fact, very few emails I get fall into this category, so there really is no need to rush to reply at the expense of the conference experience.

Actually some of the best conferences my colleagues have attended are the ones that have no Wi-Fi at all, using it as a feature rather than a shortcoming. This way attendees are encouraged to be more active at the event and engage into conversations happening during the conference days. The only issue is that if you travel from abroad, you can’t follow conversations on Twitter. But quite often you’ll find out that you’ll need a SIM-card with some data anyway (for the party or finding directions), and that’s perfectly enough for minor tasks anyway.

You decided to attend the conference for a reason, and it was not to catch up on work. Break away from that job for a while, as hard as it is. Even if you think you can juggle work and the conference, put away the computer and concentrate on the presenters. You will find, as I did, that you get so much more out of the presentations and conversations between presentations (which are at least as important).

Take Notes

Taking notes seems obvious, but how you take notes makes a big difference. I used to use my tablet, but now that it’s tucked away during presentations, I can no longer use it to take notes. Instead, I’ve gone low tech and started using good old fashioned paper and pen.

Once I began using a notepad, I found that my notes make more sense to me and that I retain much more. The combination of focusing on the session and writing down notes and my thoughts really help the content sink in. I also find myself taking more notes than before (likely because I’m paying closer attention) and getting more out of each presentation as a whole.

The notes will help you absorb the content and regroup once the conference is finished. (Image credit: chungholeung)

Similarly, I have spoken with a number of fellow designers who enjoy “sketchnoting” at events and who report similar results. By taking down notes on paper — in their case, very creatively — they absorb and retain more from the sessions. So, pack a notepad and pen, and prepare to go old school with your note-taking!

Regroup, Reflect And Share

Feeling overwhelmed by work when you return to the office is normal, especially if you have taken my advice and left work at work during the conference. Getting back in the swing of things can quickly push the conference to the back of your mind, so you need a process to bring it to the forefront.

As soon as I get back to the office, before even checking my backlog of email, I download any session materials that conference presenters have made available. I also schedule a few hours, no later than a week after having returned, to sit down with other members of my team to discuss what I took away from the event.

With the slides and my notes on hand, I teach others in my organization what I learned. Explaining the content to others reinforces what I have learned and ensures that it sticks with me long after.

Be sure to schedule some time to review what you have learned. Even if you do not have colleagues to share with, download the session material and review your notes to make sure that the lessons are not soon forgotten. You could also organize or attend a local meeting with other Web professionals in your area to share what you’ve learned. You can use tools like Meetup to find or initiate meetings in your area.

Take A Break

Look at a handful of Web conferences and you will likely see the same presenters at many of them. Some might even give the same presentation at multiple events. This makes sense. Different events have different audiences, so to reach the most people and get the most mileage from their heavy preparation, speakers will often take their presentation on the road to multiple events.

The problem is that if you attend several events in a short span of time, you will begin to see talks repeated or, at least, sessions that are very similar to ones you have attended. I went through a period of attending four or five conferences a year for about three years. Towards the end of that time, I found that the sessions were getting repetitive. I was seeing the same speakers year after year, and their presentations felt like little more than updates to what I had heard the year prior.

I spoke with other attendees at these conferences and noticed how excited they were by the material, as excited as I was when first introduced to it. The problem was that it was not new to me any longer. I was not getting much out of the conferences because there was too little new information to justify the expense, of both time and money. It was time for a break.

Bringing this back to where we began, first determine what you want to learn at an event. If the sessions offer mere updates to content you already know well, then skip the event, even if you have the time and budget.

Also, consider events that are very different from what you normally look for. Instead of a Web conference, look for something totally different, something that will expand your skill set or knowledge. That really is what it’s all about after all.

In Summary

Attending a professional Web conference can be a wonderful experience. To get the most out of it, remember these points:

• Determine what you want to learn and your budget. This will narrow your options.
• Research sessions and speakers to get a feel for what will be covered.
• If you have the budget, consider traveling to get the most out of the event.
• Prepare to be social and to meet others in your industry. Attend all meetups and after-parties and exchange contact information to form lasting relationships.
• Concentrate on the presenters, not your computer. Leave work at work, and focus on what you came for.
• By taking notes with pen and paper, you will absorb and retain more and get more from your notes.
• Afterwards, schedule time to review what you have learned, and, if possible, share it with others in your organization or area.
• Take a break from conferences if you find them becoming too repetitive. There is no point in attending a conference that you will get little out of.
• Have fun. Conferences are a good time! Get ready to be educated and inspired, but also enjoy yourself!

(al, ea, vf, il)

© Jeremy Girard for Smashing Magazine, 2014.

The Women's Center is excited to announce that the Returning Women Students Scholarships Application for 2014-2015 is now available. The deadline for submission is Friday, April 4, 2014.

This common application enables eligible students to apply for more than one of the Returning Women Students Scholarships using the same application. The three available scholarships are:

-Charlotte W. Newcombe Scholarship & The UMBC Scholarship for Mature Students
-AEGON Scholarship
-The Richard & Roselyn Bryson Neville Memorial Fund for Returning Women Scholarship

All undergraduate students over the age of 25 and with at least 60 credits may be eligible. Each scholarship has additional eligibility requirements which can be found on the common application instructions. 

The application is attached to this announcement. Please be sure to read over the eligibility requirements before applying. 

If you have any questions concerning the application process or the scholars program requirements, please contact Jess at womens.center@umbc.edu. 

We will also be hosting 2 informational sessions related to the application process and scholars program requirements. The information sessions will be held in the Women's Center on Wed., Feb 19th from between 12-1pm and Wed., March 12th between 5:45-6:45pm.

Applications are due Friday, April 5th at 4pm!! 

Lawmakers to introduce bills to bolster cyber security, innovation industry in Maryland

Today we're going to look at New Relic custom dashboards. Specifically, I will show you three ways that I tend to use custom dashboards:

• creating an overview dashboard from existing charts
• creating your own charts from existing data captured by New Relic
• creating dashboards for your custom metrics

But, before we get into any of that, we must first ask ourselves a question, why should we use custom dashboards at all? New Relic does a pretty good job of presenting your application performance data. Just using the regular UI, you can glean way more information about the performance of your app than you ever could have before you started using New Relic. So, before I show you how to use custom dashboards, I'll explain why I think anyone using New Relic should look at them sooner rather than later.

Why Use Custom Dashboards at All?

It's true, most people happily use New Relic without ever looking at the custom dashboard functionality that it provides. It's not until you're a fairly advanced user that you may decide to look at custom dashboards and see what they have to offer you. I think this is a shame, playing around with custom dashboards can not only allow you to slice and dice your app performance data in different ways, but can also:

• teach you quite a bit about how New Relic captures metrics
• allow you to learn exactly what kind of data gets stored for the metrics that get captured
• teach you about the limitations of New Relic charts

You can learn all those things by reading the documentation, but playing around with custom dashboards, allows us to begin to understand some of these things by example (on a more intuitive level), rather than just knowing it as a bunch of dot points. As is often the case with technology, tinkering with an unrelated area of a tool, will sometimes give you more insight and understanding into how the more commonly used areas of the same tool work. Using custom dashboards will make you a more savvy New Relic user, and if you've read the other New Relic posts that I've written, you'll know how I feel about knowing your tools.

Creating an Overview Dashboard from Existing Charts

The one custom dashboard I always like to build is what I call '24 hours at a glance'. I take a bunch of existing charts that I consider important for a single application, lock the time period to the last 24 hours and put them all together on one dashboard. Whenever I am looking at a specific application in New Relic, this will be the first screen I look at to see if there is anything particularly bad that jumps out at me from the last 24 hours. Let's see how we can build this kind of dashboard.

Firstly, we need to create a new custom dashboard. In the New Relic UI click on Dashboards->Create custom dashboard. On the next screen, we give our dashboard a name (you could use "24 hours at a glance", or your own name) and pick the grid layout. Essentially, grid layout is a collection of charts all the same size and overview layout is one big chart surrounded by a bunch of smaller charts (we will use overview layout in the next section).

Now we need to select the app for which we want to create our dashboard and then find some relevant charts to add. I like to add the following:

• server average response time
• historical server average response time
• browser average response time
• error rate
• throughput
• historical throughput
• application CPU usage by host
• application memory usage by host
• top five web transactions by wall clock time
• downtime
• top countries by throughput
• top five database operations by wall clock time

Depending on your application you may want to add some others, but I find this gives me a fairly good snapshot of what's happening with the application and what to investigate if anything is wrong. Let's find one of these charts and add them to our new dashboard. The server average response time is an easy one, as it's the big chart in the Overview section of the Monitoring tab for an application. Each chart in the New Relic UI has a little New Relic logo in the bottom right corner, when you hover your mouse over this logo it turns into a plus sign, clicking on the plus will allow you to add this chart to a dashboard:

But before we add our chart, we need to change the time window for the New Relic UI to be 24 hours. We need to do this in order to give ourselves the ability to 'lock' the chart to the last 24 hours when we actually add it to the dashboard (this is awkward UX in my opinion, but at least we have a way to do what we need):

We can now go ahead and add the chart:

Don't forget to tick the Lock to span checkbox. When we now visit our new dashboard, the chart we've just added should be there:

We can rinse and repeat the above process until we've added all the charts that we want. In the end, it should look something like this:

You can click the Edit dashboard button in the top right corner which will let you drag the charts around and arrange them in the order you want. The only thing to note is that you can't modify the individual charts in any way (for example, you may have wanted to have a more descriptive chart title, but you can't change it) since they are standard New Relic charts.

The other custom dashboard I always like to build from existing charts is the 'All applications at a glance'. This is only applicable if you have multiple applications you're looking after. Here we pick one or two of the most important charts for every relevant application and put them together. It's usually a safe bet to use the 'Response Time' chart from each application. The actual process of putting the dashboards together is the same as described above, you'll just need to switch applications to get the relevant charts from each. In the end, you should end up with something like this:

This is the screen I'll tend to look at first, when I log in to New Relic. It may be useful to lock the time of each chart to 24 hours just like we did for our '24 hours at a glance' dashboard, but that's up to you. Of course, this is only relevant if you're supporting multiple applications. Having said that, if you have multiple pre-production environments for your application (for staging or load test), you may want to put them all together into a dashboard similar to this one, it may help you catch changes that degrade performance before the code ends up in production.

Creating Your Own Charts from Existing Data

The New Relic UI suffers from some necessary limitations. It needs to be all things to all people, so they can only group together charts and tables that would make sense for all web applications. Most of the time the UI screens will limit you to looking at one transaction at a time and one or two sets of metrics at a time, if you need to access others you have to click around. The good news is, with custom dashboards, this limitation no longer applies. We know which transactions are related within our domain, we also know which metrics are important to us on a per transaction basis. We can build a dashboard that groups together several related transactions with all the important metrics for each and look at it on the one screen.

Let's say we have a particularly important transaction in our application, it might make sense to have a dashboard where we can see most of the important information about this transaction at a glance. Here on Tuts+ we have a concept of articles (obviously) and articles are pretty important to us, let's build a dashboard to keep an eye on them.

Once again we need to create a new dashboard just like before, we'll call it 'Article overview', but this time we'll use an overview layout. We don't have to go hunting for charts as we'll be creating our own custom charts, so click the big button to create the main chart for our dashboard:

It will ask you if you want to add a chart or a table, we will add a table later, for now choose chart. You will see a screen that looks like this:

The main thing to look at here is the metric that you want to display. When you click inside the metrics text-box it will drop down a list of top level metrics that you can select. The metrics in New Relic are named as prefix/category/label. In the case of a Rails app, the prefix might be Controller or ActiveRecord (if you're not using Rails, the prefix for transactions will be WebTransactions). For Controller, the category would be the name of the controller and the label will be the action name. If you explore some of the metrics while you're playing around with your first chart, you will start to have a feel for the kind of metrics you have access to and where to find them. If you don't see the metrics you expect, make sure that you have the right application selected within New Relic, this always trips me up.

Back to our main chart. The metric we're after will be tied to our ArticlesController, so its name is Controller/articles/show. Once we've picked the metric, the contents of the Value drop-down will change to contain all the values that make sense for this metric. It's worth once again exploring all the various values and seeing what the resulting chart actually contains. In our case, "Average response time" seems like a good thing to have as our main chart.

At this point, if we give our chart a title and click the preview button we can see what it looks like:

This looks OK, but I want the Y axis to be in milliseconds and I want the units on the axis as well. So, let's drop down the advanced options for the chart and change the number format to be 'To Milliseconds', we will also set the Y-axis unit label as 'ms':

Our chart now looks good on the preview. The only thing of note that we haven't talked about is the Chart click-through drop-down. This essentially allows your chart to be a link to another custom dashboard, when you click on the chart, that dashboard will be displayed. We don't need this functionality, so we leave the drop-down alone. We'll now go ahead and save our chart.

We can now add the various sub-charts. In our case, I happen to know that Tuts+ has a concept of tutorials (also, obviously) which is closely related to articles, so if I am going to keep an eye on article average response time, it's probably a good idea to have a tutorial average response time close by as a comparison, so I will create a chart for that. We'll follow the same steps as above, in the end our dashboard will look like this:

Hmm, it looks like the average response time for articles is much higher than tutorials, but I happen to know that both of them share a significant amount of code, strange. But it's also an indication that our custom dashboard is already paying dividends and we haven't even finished constructing it yet. I could have found this information by looking it up in the regular New Relic UI, but having the charts side by side like this helps to really bring home the fact that there might be an issue.

It might also be good to see where our ArticlesController sits compared to other controllers, as far as their maximum response time goes, this is a job for a table. We add another chart just like before, but this time pick table instead of chart. To create tables with multiple rows, we need to use wildcards in our metric name. In our case, I will set the metric to be Controller/, this will select all the metrics under the *Controller prefix, I will now set the limit text-box to be 10 which will do exactly as you expect and set the number of rows in our table to ten. In the end, we should have something that looks like this, right before we save:

Our custom dashboard will now be:

It seems that ArticlesController#show has the longest maximum response time out of all the controller actions, including TutorialsController#show, this is very curious and I should probably make a note to look into this.

We can continue adding a bunch of other charts such as end user average response time or calls per minute. However, some things you just can't construct using a custom chart, such as historical throughput or response time. Luckily we can always fall back on finding the charts that we want somewhere else in New Relic and simply adding those ones to our custom dashboard.

The only limitation with using a dashboard which has custom charts is that you have to have the correct app selected within New Relic, otherwise all the custom charts on your dashboard will be blank.

Creating Dashboards for Your Custom Metrics

If you read my last article on custom metrics, you might remember me mentioning that the only way for you to view the custom metric data that you've collected is to create a custom dashboard in New Relic, this is the third reason to use custom dashboards. If you collect a lot of custom metrics, this might be the best reason of all.

On Tuts+ we have a concept of categories (yet again, obviously), I just happen to know that we have a few custom metrics floating around for categories. Let's see if we can put these on a dashboard and actually get an idea of what's happening. We'll create another dashboard and call it 'Categories Custom Metrics'. All custom metrics in New Relic should live under the Custom prefix and this is where we find the metrics we're looking for:

We'll create a couple of charts, one to see how long building presenters in CategoriesController takes and the other to see how long it takes to get a link hash from the presenters. The key thing to know with custom metrics, is what kind of data you're actually sending to New Relic. In this case I happen to know that we're measuring time, so I can pick 'Average value' as my metric value and set the Number format to milliseconds to get a reasonable looking chart. After creating both charts, our custom dashboard looks like this:

It looks like getting the link hash from the presenters is very quick and doesn't fluctuate too much, there is no need to optimize anything here and I can probably stop collecting this metric completely (no need to capture unnecessary data). However, building the presenters takes significantly more time, we can look into this further to see if it can be optimized. We can also keep an eye on the chart (by looking at the custom dashboard occasionally) to make sure the performance doesn't degrade as we continue to work on the application.

Conclusion

Custom dashboards are not a panacea. Aside from creating charts for custom metrics, you can do everything that custom dashboards can do with the regular New Relic UI. However playing with custom dashboards will definitely help you become more of a power user of New Relic, with a deeper understanding of how it works under the hood. In addition, the ability to look at your performance metrics in different ways can be an invaluable tool to help you surface potential performance problems before they have a significant impact on your application.

If you have any questions about New Relic custom dashboards, don't be afraid to leave a comment and I'll do my best to answer. Also, if you've used custom dashboards to good effect in the past, please share any tips you might have, it's always interesting to see how other people use their tools.

Today we’re going to look at New Relic custom dashboards. Specifically, I will show you three ways that I tend to use custom dashboards:

• creating an overview dashboard from existing charts
• creating your own charts from existing data captured by New Relic
• creating dashboards for your custom metrics

But, before we get into any of that, we must first ask ourselves a question, why should we use custom dashboards at all? New Relic does a pretty good job of presenting your application performance data. Just using the regular UI, you can glean way more information about the performance of your app than you ever could have before you started using New Relic. So, before I show you how to use custom dashboards, I’ll explain why I think anyone using New Relic should look at them sooner rather than later.

Why Use Custom Dashboards at All?

It’s true, most people happily use New Relic without ever looking at the custom dashboard functionality that it provides. It’s not until you’re a fairly advanced user that you may decide to look at custom dashboards and see what they have to offer you. I think this is a shame, playing around with custom dashboards can not only allow you to slice and dice your app performance data in different ways, but can also:

• teach you quite a bit about how New Relic captures metrics
• allow you to learn exactly what kind of data gets stored for the metrics that get captured
• teach you about the limitations of New Relic charts

You can learn all those things by reading the documentation, but playing around with custom dashboards, allows us to begin to understand some of these things by example (on a more intuitive level), rather than just knowing it as a bunch of dot points. As is often the case with technology, tinkering with an unrelated area of a tool, will sometimes give you more insight and understanding into how the more commonly used areas of the same tool work. Using custom dashboards will make you a more savvy New Relic user, and if you’ve read the other New Relic posts that I’ve written, you’ll know how I feel about knowing your tools.

Creating an Overview Dashboard from Existing Charts

The one custom dashboard I always like to build is what I call ’24 hours at a glance’. I take a bunch of existing charts that I consider important for a single application, lock the time period to the last 24 hours and put them all together on one dashboard. Whenever I am looking at a specific application in New Relic, this will be the first screen I look at to see if there is anything particularly bad that jumps out at me from the last 24 hours. Let’s see how we can build this kind of dashboard.

Firstly, we need to create a new custom dashboard. In the New Relic UI click on Dashboards->Create custom dashboard. On the next screen, we give our dashboard a name (you could use “24 hours at a glance”, or your own name) and pick the grid layout. Essentially, grid layout is a collection of charts all the same size and overview layout is one big chart surrounded by a bunch of smaller charts (we will use overview layout in the next section).

Now we need to select the app for which we want to create our dashboard and then find some relevant charts to add. I like to add the following:

• server average response time
• historical server average response time
• browser average response time
• error rate
• throughput
• historical throughput
• application CPU usage by host
• application memory usage by host
• top five web transactions by wall clock time
• downtime
• top countries by throughput
• top five database operations by wall clock time

Depending on your application you may want to add some others, but I find this gives me a fairly good snapshot of what’s happening with the application and what to investigate if anything is wrong. Let’s find one of these charts and add them to our new dashboard. The server average response time is an easy one, as it’s the big chart in the Overview section of the Monitoring tab for an application. Each chart in the New Relic UI has a little New Relic logo in the bottom right corner, when you hover your mouse over this logo it turns into a plus sign, clicking on the plus will allow you to add this chart to a dashboard:

But before we add our chart, we need to change the time window for the New Relic UI to be 24 hours. We need to do this in order to give ourselves the ability to ‘lock’ the chart to the last 24 hours when we actually add it to the dashboard (this is awkward UX in my opinion, but at least we have a way to do what we need):

We can now go ahead and add the chart:

Don’t forget to tick the Lock to span checkbox. When we now visit our new dashboard, the chart we’ve just added should be there:

We can rinse and repeat the above process until we’ve added all the charts that we want. In the end, it should look something like this:

You can click the Edit dashboard button in the top right corner which will let you drag the charts around and arrange them in the order you want. The only thing to note is that you can’t modify the individual charts in any way (for example, you may have wanted to have a more descriptive chart title, but you can’t change it) since they are standard New Relic charts.

The other custom dashboard I always like to build from existing charts is the ‘All applications at a glance’. This is only applicable if you have multiple applications you’re looking after. Here we pick one or two of the most important charts for every relevant application and put them together. It’s usually a safe bet to use the ‘Response Time’ chart from each application. The actual process of putting the dashboards together is the same as described above, you’ll just need to switch applications to get the relevant charts from each. In the end, you should end up with something like this:

This is the screen I’ll tend to look at first, when I log in to New Relic. It may be useful to lock the time of each chart to 24 hours just like we did for our ’24 hours at a glance’ dashboard, but that’s up to you. Of course, this is only relevant if you’re supporting multiple applications. Having said that, if you have multiple pre-production environments for your application (for staging or load test), you may want to put them all together into a dashboard similar to this one, it may help you catch changes that degrade performance before the code ends up in production.

Creating Your Own Charts from Existing Data

The New Relic UI suffers from some necessary limitations. It needs to be all things to all people, so they can only group together charts and tables that would make sense for all web applications. Most of the time the UI screens will limit you to looking at one transaction at a time and one or two sets of metrics at a time, if you need to access others you have to click around. The good news is, with custom dashboards, this limitation no longer applies. We know which transactions are related within our domain, we also know which metrics are important to us on a per transaction basis. We can build a dashboard that groups together several related transactions with all the important metrics for each and look at it on the one screen.

Let’s say we have a particularly important transaction in our application, it might make sense to have a dashboard where we can see most of the important information about this transaction at a glance. Here on Tuts+ we have a concept of articles (obviously) and articles are pretty important to us, let’s build a dashboard to keep an eye on them.

Once again we need to create a new dashboard just like before, we’ll call it ‘Article overview’, but this time we’ll use an overview layout. We don’t have to go hunting for charts as we’ll be creating our own custom charts, so click the big button to create the main chart for our dashboard:

It will ask you if you want to add a chart or a table, we will add a table later, for now choose chart. You will see a screen that looks like this:

The main thing to look at here is the metric that you want to display. When you click inside the metrics text-box it will drop down a list of top level metrics that you can select. The metrics in New Relic are named as prefix/category/label. In the case of a Rails app, the prefix might be Controller or ActiveRecord (if you’re not using Rails, the prefix for transactions will be WebTransactions). For Controller, the category would be the name of the controller and the label will be the action name. If you explore some of the metrics while you’re playing around with your first chart, you will start to have a feel for the kind of metrics you have access to and where to find them. If you don’t see the metrics you expect, make sure that you have the right application selected within New Relic, this always trips me up.

Back to our main chart. The metric we’re after will be tied to our ArticlesController, so its name is Controller/articles/show. Once we’ve picked the metric, the contents of the Value drop-down will change to contain all the values that make sense for this metric. It’s worth once again exploring all the various values and seeing what the resulting chart actually contains. In our case, “Average response time” seems like a good thing to have as our main chart.

At this point, if we give our chart a title and click the preview button we can see what it looks like:

This looks OK, but I want the Y axis to be in milliseconds and I want the units on the axis as well. So, let’s drop down the advanced options for the chart and change the number format to be ‘To Milliseconds‘, we will also set the Y-axis unit label as ‘ms‘:

Our chart now looks good on the preview. The only thing of note that we haven’t talked about is the Chart click-through drop-down. This essentially allows your chart to be a link to another custom dashboard, when you click on the chart, that dashboard will be displayed. We don’t need this functionality, so we leave the drop-down alone. We’ll now go ahead and save our chart.

We can now add the various sub-charts. In our case, I happen to know that Tuts+ has a concept of tutorials (also, obviously) which is closely related to articles, so if I am going to keep an eye on article average response time, it’s probably a good idea to have a tutorial average response time close by as a comparison, so I will create a chart for that. We’ll follow the same steps as above, in the end our dashboard will look like this:

Hmm, it looks like the average response time for articles is much higher than tutorials, but I happen to know that both of them share a significant amount of code, strange. But it’s also an indication that our custom dashboard is already paying dividends and we haven’t even finished constructing it yet. I could have found this information by looking it up in the regular New Relic UI, but having the charts side by side like this helps to really bring home the fact that there might be an issue.

It might also be good to see where our ArticlesController sits compared to other controllers, as far as their maximum response time goes, this is a job for a table. We add another chart just like before, but this time pick table instead of chart. To create tables with multiple rows, we need to use wildcards in our metric name. In our case, I will set the metric to be Controller/, this will select all the metrics under the *Controller prefix, I will now set the limit text-box to be 10 which will do exactly as you expect and set the number of rows in our table to ten. In the end, we should have something that looks like this, right before we save:

Our custom dashboard will now be:

It seems that ArticlesController#show has the longest maximum response time out of all the controller actions, including TutorialsController#show, this is very curious and I should probably make a note to look into this.

We can continue adding a bunch of other charts such as end user average response time or calls per minute. However, some things you just can’t construct using a custom chart, such as historical throughput or response time. Luckily we can always fall back on finding the charts that we want somewhere else in New Relic and simply adding those ones to our custom dashboard.

The only limitation with using a dashboard which has custom charts is that you have to have the correct app selected within New Relic, otherwise all the custom charts on your dashboard will be blank.

Creating Dashboards for Your Custom Metrics

If you read my last article on custom metrics, you might remember me mentioning that the only way for you to view the custom metric data that you’ve collected is to create a custom dashboard in New Relic, this is the third reason to use custom dashboards. If you collect a lot of custom metrics, this might be the best reason of all.

On Tuts+ we have a concept of categories (yet again, obviously), I just happen to know that we have a few custom metrics floating around for categories. Let’s see if we can put these on a dashboard and actually get an idea of what’s happening. We’ll create another dashboard and call it ‘Categories Custom Metrics’. All custom metrics in New Relic should live under the Custom prefix and this is where we find the metrics we’re looking for:

We’ll create a couple of charts, one to see how long building presenters in CategoriesController takes and the other to see how long it takes to get a link hash from the presenters. The key thing to know with custom metrics, is what kind of data you’re actually sending to New Relic. In this case I happen to know that we’re measuring time, so I can pick ‘Average value‘ as my metric value and set the Number format to milliseconds to get a reasonable looking chart. After creating both charts, our custom dashboard looks like this:

It looks like getting the link hash from the presenters is very quick and doesn’t fluctuate too much, there is no need to optimize anything here and I can probably stop collecting this metric completely (no need to capture unnecessary data). However, building the presenters takes significantly more time, we can look into this further to see if it can be optimized. We can also keep an eye on the chart (by looking at the custom dashboard occasionally) to make sure the performance doesn’t degrade as we continue to work on the application.

Conclusion

Custom dashboards are not a panacea. Aside from creating charts for custom metrics, you can do everything that custom dashboards can do with the regular New Relic UI. However playing with custom dashboards will definitely help you become more of a power user of New Relic, with a deeper understanding of how it works under the hood. In addition, the ability to look at your performance metrics in different ways can be an invaluable tool to help you surface potential performance problems before they have a significant impact on your application.

If you have any questions about New Relic custom dashboards, don’t be afraid to leave a comment and I’ll do my best to answer. Also, if you’ve used custom dashboards to good effect in the past, please share any tips you might have, it’s always interesting to see how other people use their tools.