Alerting on JIRA Problems using Nagios

Rodney N.Leave a comment

So I ran into an interesting situation this past Monday. Apparently my Primary DNS had been down for at least a week. I went to go look at my network monitoring tool (LibreNMS) – and THAT was down too – for what I can guess is at least two weeks! Granted I haven’t been doing as much on my Homelab since early March when I went into the hospital, this was still not a good state of affairs.

So I decided to stand up a Nagios instance to monitor and alert when I have critical systems down. After getting it stood up, it didn’t take me long to start thinking about how I could use this with JIRA, which is now the topic we are going to cover today!

A bit of history

As you know, when I started my Atlassian journey, I was in charge of more than just JIRA. Nagios was one of my boxes I inherited as well. So I’m somewhat familiar with the tool already and how to configure it. I’ve had to modify things during that time, but never do a full setup. However, I knew I wanted to do more than monitor if JIRA was listening to web-traffic. So as part of the whole installation, I decided to dive in and see what she can do.

How to select what to Alert on.

Selecting what I want to be alerted for has always been a balancing act for me. You don’t want to have so many emails that they become worthless, but you don’t want to have so few that you won’t be alerted to a real problem.  

The goal of alerting is to clue you into problems so you can be proactive. Fix back end problems before they become a user ticket. So I always try to take the approach “What does a user care about?”

They care that the system is up and accessible, so I always monitor the service ports, including my access port. So that’s three.

A user also cares that their integrations work. If your integrations depend on SSL, and your clock drifts too far out of alignment, those integrations can fail – so I want to check the system is in sync with the NTP Server.

A feature that users love is the ability to attach files to issues. This feature will eventually chew up your disk space, so I’ll also want to monitor the disk JIRA’s home directory lives on. 

Considering I’m using a proxy, I’ll want to be sure the JVM itself is up, so I’ll need to look at that. I’ll also want to be sure that JIRA is performing at it’s best, and isn’t taking too long to respond, so I’ll want an alert for that as well.

Do you see what I’m doing? I’m looking at what can go wrong with JIRA when I’m not looking and setting up alerts for those. The idea here is I care about what my users care about, so I want the Nagios to tell me what is wrong before my users get a chance to.

So…configurations.  

Now comes the fun part. Nagios’ configuration files is a bit much to take in at first. However, I will be isolating the Atlassian specific configurations to make things a bit easier on all of us. First, lets start with some new commands I had to add.

###############################################################################
# atlassian_commands.cfg
#
#
# NOTES: This config file provides you with some commands tailored to monitoring
#        JIRA nodes from Nagios
# AUTHOR: Rodney Nissen <rnissen@thejiraguy.com
#
###############################################################################


define command {
    command_name    check_jira_status
    command_line	$USER1$/check_http -S -H $HOSTADDRESS$ -u /status -s '{"state":"RUNNING"}'
	}
	
define command {
    command_name	check_jira_restapi
	command_line	$USER1$/check_http -S -H $HOSTADDRESS$ -u /rest/api/latest/issue/$ARG3$ -s "$ARG3$" -k 'Authorization: Basic $ARG4$' -w $ARG1$ -c $ARG2$
	}
    
define command {
    command_name    check_jira_disk
    command_line    $USER1$/check_by_ssh -H $HOSTADDRESS$ -l nagios -C "/usr/lib64/nagios/plugins/check_disk -w $ARG2$ -c $ARG3$ -p $ARG1$"
    }
    
define command {
    command_name    check_jira_load
    command_line    $USER1$/check_by_ssh -H $HOSTADDRESS$ -C "/usr/lib64/nagios/plugins/check_load -w $ARG1$ -c $ARG2$" -l nagios

The first two commands here are VERY tailored to JIRA. The first one checks that the JVM is running, all with a handy HTTP request. If you go to your JIRA instance and go to the /status directory, the JVM will respond with a simple JSON telling you the state of the node. You use this feature in JIRA Data Center, so your load balancer can determine which nodes are up and ready for traffic. Buuut…it’s on JIRA Server too, and we can use it for active monitoring. So I did. If JIRA returns anything other than {“state”:”RUNNING”}, the check will fail and you will get an alert.

The second is a check on the rest API. This one will exercise your JIRA instance to make sure it’s working without too much load time for users. The idea here will search for a known issue key, and see if it returns valid information within a reasonable time. $ARG1$ is how long JIRA has before Nagios will issue a warning that it’s too slow (in seconds), and $ARG2$ is how long JIRA has before Nagios considers it a critical problem. $ARG3$ is your known good Issuekey. $ARG4$ is a set of credentials for JIRA encoded in Base64. If you are not comfortable just leaving your actual credentials encoded as such, I’d suggest you check out the API Token Authentication App for JIRA. Using the App will allow you to use a token for authentication and not expose your password.

The third commands here are for checking JIRA’s home directory ($ARG1). $ARG2$ and $ARG3$ are percentages for the warning and critical thresholds, respectively.

The fourth is for checking the system load. This one is relatively straight forward. $ARG1$ is the system load that will trigger a warning, and $ARG2$ is the system load that shows you have a problem.

Now for the JIRA host configuration:

###############################################################################
# jira.CFG - SAMPLE OBJECT CONFIG FILE FOR MONITORING THIS MACHINE
#
#
# NOTE: This config file is intended to serve as an *extremely* simple
#       example of how you can create configuration entries to monitor
#       the local (Linux) machine.
#
###############################################################################



###############################################################################
#
# HOST DEFINITION
#
###############################################################################

# Define a host for the local machine

define host {

    use                     linux-server            ; Name of host template to use
                                                    ; This host definition will inherit all variables that are defined
                                                    ; in (or inherited by) the linux-server host template definition.
    host_name               jira
    alias                   JIRA
    address                 192.168.XXX.XXX
}


###############################################################################
#
# SERVICE DEFINITIONS
#
###############################################################################

# Define a service to "ping" the local machine

define service {

    use                     generic-service           ; Name of service template to use
    host_name               jira
    service_description     PING
    check_command           check_ping!100.0,20%!500.0,60%
}


# Define a service to check SSH on the local machine.
# Disable notifications for this service by default, as not all users may have SSH enabled.

define service {

    use                     generic-service           ; Name of service template to use
    host_name               jira
    service_description     SSH
    check_command           check_ssh
}



# Define a service to check HTTP on the local machine.
# Disable notifications for this service by default, as not all users may have HTTP enabled.

define service {

    use                     generic-service           ; Name of service template to use
    host_name               jira
    service_description     HTTP
    check_command           check_http
}

define service {

    use                     generic-service
    host_name               jira.folden-nissen.com
    service_description     HTTPS
    check_command           check_https
}


define service {
    use                     generic-service
    host_name               jira
    service_description     NTP
    check_command           check_ntp!0.5!1
}

define service {
	use				generic-service
	host_name			jira
	service_description		JIRA Status
	check_command			check_jira_status
	}
	
define service {
	use				generic-service
	host_name			jira
	service_description		JIRA API Time
	check_command			check_jira_restapi!2!3!HL-1!<Base64 Credentials>
	}
    
define service {
	use				generic-service
	host_name			jira
	service_description		JIRA System Load
	check_command			check_jira_load!5.0,4.0,3.0!10.0,6.0,4.0
	}
    
define service {
	use				generic-service
	host_name			jira
	service_description		JIRA Home Directory Free Space
	check_command			check_jira_disk!<JIRA Home>!75%!85%
	}

So, first, we define the host. This section is information specific to JIRA. Then we start setting services for JIRA. Within Nagios, a Service is a particular check you want to run.

The next four options are pretty standard. These are checking Ping, the two service ports (HTTP and HTTPS), and the SSH port. The SSH Port and HTTP/S port checks will also check that those services are responding as expected.

The next check is for NTP. I have this setup to warn me if the clock is a half-second off and give me a critical error if the clock is off by one second. These settings might be too strict, but it has yet to alert, so I think I have dialed it in well enough.

The next is the JIRA Status check. This service will check /status, as we mentioned earlier. It’s either the string we are expecting, or it’s not, so no arguments needed.

After that is my JIRA API Check, which I set up to check the HL-1 issue. If the API Call takes longer to 2 seconds, issue a warning, and if it takes longer than 3 seconds, Nagios issues a critical problem. This alert won’t tell me exactly what’s wrong, but it will tell me if there is a problem anywhere in the system, so I think it’s a good check.

The last two services are systems check – checking the System Load and JIRA home directory disk, respectively. The Load I haven’t had a chance to dial in yet, so I might have it set too high, but I’m going to leave it for now. As for the Disk check, I like to have plenty of warning I am approaching a full disk to give me time to resolve it, so these numbers are good.

The last step is to add these to the nagios.cfg file so that they get loaded into memory. However, this is as easy as adding the following lines into the cfg file.

# Definitions for JIRA Monitoring
# Commands:
cfg_file=/usr/local/nagios/etc/objects/atlassian_command.cfg

# JIRA Nodes:
cfg_file=/usr/local/nagios/etc/objects/jira.cfg

And that’s it! Restart Nagios and you will see your new host and service checks come up!

Nagios in action.

So I’ve had this configuration in place for about a day now, and it appears to be working. The API Time check did go off once, but I did restart the JIRA Server to adjust some specs on the VM, so I expected the delay. So I hope this helps you as you are setting up alerts for your JIRA system!

And that’s it for this week!

We did get a bit of bad news about Summit 2021 last week. Out of an abundance of caution, Atlassian decided to go ahead and make all in-person events of 2020 and Summit 2021 virtual events. However, they have almost a year to prepare for a virtual Summit – as opposed to the 28 days they had this year. So I am excited to see what ideas Atlassian has to make this a fantastic event!

Don’t forget our poll! I’m going to let it run another week!

Don’t forget you can check me out on Twitter! I’ll be posting news, events, and thoughts there, and would love to interact with everyone! If you found this article helpful or insightful, please leave a comment and let me know! A comment and like on this post in LinkedIn will also help spread the word and help others discover the blog! Also, If you like this content and would like it delivered directly to your inbox, sign up below!

But until next time, my name is Rodney, asking “Have you updated your JIRA Issues today?”

Dragon Slayer Part 2: The Revamp

Rodney N.2 Comments

Well, I’ve finished the revamp! It took me a little longer than expected, but here we are.

Of course, you guys enjoyed last week’s article on Automation for JIRA. While I would not like it to be the sole focus of the blog, if you guys bring me good ideas for potential Automations, I would love to do more of those kinds of pieces. But that’s not why we are here today.

So in total, I reworked all nine pages, each about as long as a typical blog post. Today I’d like to go into some thoughts, tricks, and pitfalls to be aware of if you try to do it from my instructions.

Time is not on your side.

So, to be clear, the last five modules all depend on a Mercurial Repo hosted on Bitbucket Cloud. It’s something that works well in this situation – except for the following complication. 

Atlassian has announced they are ending support in Bitbucket Cloud for Mercurial, with all existing Mercurial Repos disappearing on July 1st, which leaves the Dragon Slayer Challenge in a bit of a pickle.

As of right now, I intend to monitor it to see if they update their instructions with a git repository. If that does not happen, I’ll be taking down my instructions on July 1st as well. It only seems right, honestly. I would not like to be answering comments for the next few years that everything past Stage 5 isn’t working.

So if you are looking to try this yourself – do it now!

Fish eye gadgets are still…off.

So, I spent half a day debugging this – only to get nowhere. There are a few answers out there for the problem, but they are six years old. To further complicate things, my testing proved that their problem back then was not my problem today.

What problem is that? Simple, I could not get a Fisheye Gadget to return a valid Repository no matter what I tried. Every time I’d get the same, “The specified FishEye repository is not configured” – which was malarkey. The Repositories would work correctly within the JIRA Development Panel – just not the gadgets. Upping the logging on the FishEye plugin revealed nothing of usefulness in the logs either.

At a certain point, I just had to decide I wasn’t the one to fix this issue. However, if you do have a fix, please PLEASE let me know!

A few last notes

I tried to go through and click every link, touch every instruction, and redo every screenshot. But there may be parts I missed. If you notice something that isn’t working, please let me know so I can update it!

There are points where things weren’t working as described, and I had to find out why and fix it. Every time this did happen, though, I did go back to the appropriate place and update the instructions. I feel this is an improvement on the old instructions from Atlassian and is something I am happy to put out.

That being said, this is Atlassian’s work originally. If they ask that I take it down, I will do so without warning to you guys. I don’t want to bite the hand that feeds me. I honestly don’t think it will come to that, but I figured I’d give you fair warning.

So, Get on with it!

You can find the start of the journey here. If you’ve never messed with the system side of running the Atlassian Stack yourself, it’s a great place to get started.

I’ve spent a good bit of time on this update, so if you appreciate it, please give it a like and cI’ve spent a good bit of time on this update, so if you appreciate it, please give it a like or comment on LinkedIn or a retweet on Twitter. That’s all it takes to help others discover this blog! You can also subscribe to the blog using the form below to get new posts directly to your inbox. Don’t forget to follow me on Twitter at @theJIRAguy.

Also, a discussion at work got me curious. How do you spell it: Subtask or Sub-task? Answer below!

But until next time, my name is Rodney, asking “Have you updated your JIRA issues today?”

Automation for JIRA

Rodney N.Leave a comment

So, I can already hear you, readers. You’re saying, “Aren’t we supposed to have a part 2 to the Dragonslayer post where you modernize the instructions?” And you are correct. However, that turns out to be a more significant task than I first imagined. 

However, I want you to have something to read this week. That was when I had a request from a client this week. Upon reviewing the solution to the request, I felt it would be perfect for posting about this week.

Automation for JIRA

One question users always ask me is how they can automate actions in JIRA. For example, when they move a story into the sprint, how can they automatically have the subtasks moved too. And for the longest time, I didn’t have a useful answer.  

Sure, you can make it work in Scriptrunner, but the amount of work it would take would make it not worth it. Then I discovered Automation for JIRA. This one allows me to tailor automations to specific projects, and so so using no programming. 

So for this post, I thought I’d go into the request I was given and how I approached solving it using Automation for JIRA. Let us begin.

The Request

So, my first recommendation is to understand the request entirely. Figure out not only what the users are asking you to do but also why they are asking it in the first place. 

In this case, the client asked me if there was a way to automatically create sub-tasks on an issue based on what components are on the parent issue. That’s great, but that doesn’t solve the “why.” However, I was fortunate that the client already explained their thinking here.

It turns out that the client has the components in their project broken down by functional teams, and for each task, they want to add Components to the issue based on who has an active role in it. They then want to create a sub-task for each component so that the individual teams involved can track their work.

The reason for the requests tells me a good bit about the request that the initial ask did not. For example, Components may not only be added at issue creation but at any time during the Issue’s lifecycle. This fact comes into play soon. It also tells me that I need to be able to support any combination of components. This requirement can make things tricky, but I don’t think impossible.

Getting started

The Trigger

The first thing I think about when I start building an automation is, well, the starting point. What kicks it off. Let me explain. For every automation rule you have, you need some event to kick it off. Some marble that is falling to set off your Rube-Goldberg machine.

In Automation for JIRA, this is called the Trigger. There are a number of these available within the tool.

That is quite the list, no? While it may be something to go through, I think it’s a natural choice here. Remember when I mentioned that we discerned from the request that we would need this to happen at any point during the Issue’s active life cycle? That means we can rule out anything that doesn’t have to do with the Issue. We can also rule out anything that takes place during specific events of the lifecycle, such as a transition or creation.

Furthermore, we have a trigger that can focus specifically on when a field is changed.

So when we select this option, we are presented with several settings. Because we are focusing on the Components, we choose that for the field setting, and leave the “For” setting to it’d default “All issue operations.” Once done, we click “Save.”

Conditions

So, now we need to think about when we don’t want this rule to run. We can specify when an automation rule runs by using “Conditions.” Here is a view of what our rule looks like after saving the Trigger.

We know we only want this rule to run when the parent issue is active. So lets put a condition on here to check that the Resolution field is empty.

Having this immediately after the Trigger keeps it from executing when this condition isn’t true (in our example, when the Issue is resolved). There are many conditions available, and we can use a few of them here in a moment.

The “Component Block” – More Conditions and Actions

Now comes the tricky part. We need to be able to split off actions based on the components. We also need to check – per Component – that it’s appropriate sub-task doesn’t already exist. This requirement stumped me for a second until I settled on the “If/Else” block. Using this condition creates a situation where you can have actions run if the condition is true, but if it’s false, it won’t stop the entire chain from running.

Here we have the If block with two conditions. The first checks for a specific Component – in this case, “Ducks.” The second checks all sub-tasks to make sure we don’t already have the one we want. If any have the summary “Test Ducks,” this Trigger fails, and any actions we have on this branch don’t run.

What do I mean by branch? I mean this If block, once saved, creates a branch in our rule flow.

Here is where we will add our actions. In this case, we will want to create an issue within the current project with issue type “Sub-Task”. This will allow us to specify the responsible user, description, and most importantly summary. For this to work properly, you need to make sure you summary you are creating matches the check you have in the If Statement.

Click Save, and that’s the block done for this Component. Rinse and Repeat for each Component you desire to automate, and you should be good to go.

Branches

So, we didn’t end up using them for this request, but I still wanted to touch on Branches. We used the If/Else Block for some rudimentary branches, but what happens when you want to run an Automation Rule against all the Issue’s Sub-Tasks?

In this situation, you want to use a Branch rule. This rule allows you to execute a set of actions on issues based on their relation to the Issue that triggered the rule.

Something handy to keep in mind, but as I’ve stated, not always something you need.

And that’s it!

I am sorry for not having the second Dragonslayer post – but I do hope to have that available for next week. But this request struck me as an interesting problem and a great example of how to develop and use an Automation Rule. 

If you like the content you find here, don’t hesitate to sign up below to receive emails when I post new content. And you can also check me out on twitter at this link. But until next time, my name is Rodney, asking “Have you updated your JIRA Issue today?”

Dragon Slayer 2020 – Pt. 1

Rodney N.Leave a comment

What’s up, everyone? It’s been a busy week for me. However, in the “excellent things” department, I passed my exam!

So shiny…

That means I’m exactly one Cert away from Atlassian Certified Master status. And I think we all know that my next certification exam is the ACP-200.

Revenge is needed….

However, that is going to have to wait. I am not losing to that exam, so study time is needed. No, this week is going to be a bit of a throw-back. I’m going to be attempting the Atlassian Dragon Slayer challenge to see how it holds up. This challenge is to set up a fully integrated development suite using JIRA, Confluence, Fisheye, Crucible, and Bamboo. Considering I already have a test JIRA instance, I’m going to follow the directions linked.

Next week for part 2, I’m going to re-write it with modern JIRA, Confluence, Bamboo, and Bitbucket in mind so that if you want to follow this old quest with modern tools, you can. So, let’s not dally any longer.

Dragons with JIRA Stage 1 – Set Up Environment and JIRA

As my JIRA Instance is already running and relatively up to date, I can skip steps 1-4 and go directly to Step 5.

Anyone else remember when Atlassian version numbers would get that high? Needless to say, I think we’re over the required version.

All told, Step 5 is mostly setting up users and groups for the other system. Step 6 is setting up the project and Dashboard. The only question I ran into here is the project type. The instructions ask for a “Software Development’ Project,” however, this was before JIRA 7, where JIRA Agile became JIRA Software (with three different types of Software Projects). I opted considering the criteria to go with a “Basic software development” project – as I felt that most closely followed the instructions so far. That may come to bite me in a moment, as it’s time to move onto the next Stage.

Dragons Stage 2 – JIRA Add-Ons

Well, that whole JIRA Agile/Software thing ended up not being a problem, as the first step on the next page asks me to set up a new project and board. That is one thing I’ll give Atlassian – this kind of deal is A LOT easier than it used to be. The instructions have you create the project, then the board. You can now do this all in one go in JIRA Software. So, create the Scrum project, create the bugs they specify, create/start a sprint, and I get this.

The next section for this Stage involves setting up Capture for JIRA by Zephyr Smartbear. This App lets you capture screenshots of web pages (among other things). This tool is great for capturing more information on bugs, which is how the challenge has us use it

Dragons Stage 3 – Install Confluence

So, Stage 3 is installing Confluence. And well…

…I already have a Confluence.

I still needed to do some basic configuration and setup work here. I added JIRA as a directory in Confluence (honestly, it’s easier than the OpenLDAP config I had going), and created the DRA Space and started modifying its home page. And this was where I ran into trouble.

This…this innocuous looking line from my Apache config cost me 2 hours worth of time to fThis innocuous-looking line from my Apache config cost me 2 hours worth of time to figure out. This setting would unset the authentication every time Confluence tried to talk to JIRA, which meant the JIRA Issues/Filters Gadget would not work. The most infuriating part – there was no error in either Confluence’s or JIRA’s log. I only figured it out as I happened upon the right KB Article on it…

However, with that fixed, I finally got everything up and running normally, and was able to finish Stage 3.

Dragons Stage 4 – Install Team Calendars in Confluence

Team Calendars – now this one I know just works. I install it per the usual method (I am certainly burning through the free trials today). Honestly, this one just worked pretty straight forward – follow the instructions here.

Dragons Stage 5 – Install FishEye and Crucible

Stage 5 is installing Fisheye – and honestly, this has not been something I’ve done since early in my Atlassian Administrator career. However, the instructions included seemed a bit dated. So I instead popped over to the Atlassian KB and found this article on Installing Fisheye on Linux and Mac. You have to love it when you find the article you need. Then it was a matter of connecting my internal bitbucket server instance (for thoroughness), as well as the remote Bitbucket repo mentioned in the Stage 5 instructions, and we’re off to the races!

Dragons Stage 6 – Get JIRA and FishEye Talking

So Step one is setting the link between the Repo from Stage 5 and the DRA project in JIRA. It’s relatively simple to set up. It was at this point that I had to figure out why the “Source” tab they mentioned wasn’t showing up. Then I remembered that JIRA had moved this to the Development Panel some time ago.

“It’s fantastic when stuff just works,” is what I’d be saying if not for Step 3. No matter what I did, I could not get the gadget to work. The gadget would keep saying, “The Repo was not configured.” I knew the Repo had been configured properly. Other Fisheye Gadgets worked with the Repo, just not this one. I need to move on with this one.

Dragons Stage 7 – Get JIRA and Crucible Talking

This one was fairly straight forward. I linked a Crucible Project to the DRA JIRA Project and went through the process of creating a review, finding a defect, creating a JIRA issue from it, and resolving it. The only problem I had was when I couldn’t find the “Create Issue” link – but that one was purely an ID-10T error on my part. Another one down!


Dragons Stage 8 – Install Bamboo

I can see the light at the end of the tunnel – but this one is another install challenge. I I can see the light at the end of the tunnel – but this one is another install challenge. I overbuilt the Fisheye server also to host Bamboo as both are temporary in my setup. This one also needed some updating, so I followed the more up-to-date KB Article Installing Bamboo on Linux. Afterward, I set up Bamboo to use JIRA for Authentication and double-checked that the groups were set up. 

Now it was time to get all the application links in place. With five applications now, this process is getting a bit long, but not painful.

Now it was time to configure the actual build. This one took me a second as I had to figure out where the tools directory was on the host system ( /usr/share/maven/ if you are wondering), but I got it set up, debugged, and a successful build, which completed the next to the last Stage!

Dragons Stage 9 – Bamboo Gadgets and JIRA Victory

So last stage – looks like it’s more gadgets time. And…there’s a problem. When I go to add So last Stage – looks like it’s more gadgets time. And there’s a problem. When I go to add the gadgets they request, I can see and add them to the Dashboard. But then they don’t load their settings panel at all.

It turns out – it was my browser. Because I’m not bothering to put these behind an SSL proxy, Firefox did not like that. Disable the protection (temporarily), and they work!

Final thoughts

So, here’s the deal. These guides were last updated in 2017, and based on the repo data, written much earlier. May and June may be our last chance to run this for a bit, as Atlassian is removing Mercurial Ropes from Bitbucket Cloud.

However, this was a fun little run-through of all the various bits of the Atlassian Development Stack. I got to touch several products that I haven’t looked at in years and got some practical experience in installing them from scratch. It’d be interesting to do a speed run of these to see how long it would take.

So now comes the fun part – updating this with new instructions and getting it all working on the modern versions of the tools! If you want to check that out, be sure to sign up to receive emails from the blog. You can also follow me on Twitter at @theJIRAguy. But until next time, my name is Rodney, asking, “Have you updated your JIRA Issues today?”

What is a Consultant?

Rodney N.Leave a comment

Well, here we are, another month down. At let me say, you guys killed it last month!

We got well over 1,000 views last month! That almost doubles the previous month and is easily the biggest month the blog has had to date. Thank you all for commenting, liking, and sharing the blog with your friends and colleagues! You guys are what makes this all possible!

Today’s topic is a bit different. This item was suggested to me by a colleague. In a nutshell, he wanted me to look at the difference between being an Atlassian Admin and an Atlassian Consultant.

As you may now, I was a JIRA Admin before starting my current job. But seeing as I have only been a consultant for six months, I decided to call in some help. So welcome to the blog David Higdon, Olena McMurtrey, and Neil Taylor. They will be lending their thoughts onto the topic and answering some questions I posed to them!

How did you get started with Atlassian Components?

Neil: So, the first job I had out of college – they were running a helpdesk – and this was before JIRA Service Desk was around. But they were like, “Hey, We’re using this new product called JIRA.” And that was when JIRA was on version 4. So I got to adapt that to run a Service Desk for about ten thousand Dialysis Facilities. It was an interesting use case for the product, and I don’t know if they chose the right product for that, but it got me in the door with working on Atlassian.

Olena: Coyote Creek had both Microsoft and Atlassian teams; I started in the Microsoft division, and with time transferred to Atlassian team. I got passionate about Atlassian  products, and enjoy helping clients to tune their systems with best practice approach.

David:

So, one of my good friends leaves the company I’m working for and joins a software company. And their Engineering Team at this software company was looking for somebody to help manage their middleware space from a Unix SysAdmin perspective. At the time, I had 27 years of experience as a Systems Administrator – of which I had spent six managing the middleware space, and they felt I would be a great addition to their team.

As this company was coming out of the startup phase, they were looking to get a little more structure in place and a bit more formality in their processes, and for someone to help them standardize and automate things of that nature. And being an Engineering Department, they are big on Atlassian Products. They had two instances of JIRA – one external for Professional Services and their Customers, and then an internal system for their Software Developers. They were using two instances of Fisheye/Crucible. The Professional Services instance looking at SVN and Engineering instance was looking at GIT.

So, my first day on the job, they sat me down, and they said, “Here you go, here are two instances of JIRA and Fisheye, and here are the hostnames.” I had to learn Jira ASAP and prepare to upgrade the system. So, I’ve never heard of Atlassian at that time, so this is how I got introduced to Atlassian – literally diving into the deep end.

Rodney: I was working as a consultant for First Responder Dispatch systems at the time – that being the systems the operator is typing into when you dial the emergency number.  

However, that job required a lot of travel, which was not a good situation. Looking around my company, I noticed an open position for a Linux Administrator. Now this company prided itself on being a Microsoft shop – so of course, I was the one dumb enough to raise my hand and say, “Yes, I know Linux!” I applied and interviewed, and was honest about my experience, and got the position of managing some Linux based development systems.  

So day one, I go in, and I’m getting the grand tour. We go over my server closet, the perforce server, our backup process, and finally, JIRA and Confluence. I’m given admin rights to the systems and told, “Congratulations. You have a day before you start getting tickets, and by the way, we want to upgrade the systems this quarter.” At that point, nothing left to do but start learning one ticket and google search at a time.

How did you become a consultant?

Neil: So, I put JIRA on my LinkedIn, and a consultant company contacted me and said, “Hey, we want you to come be an Atlassian consultant for us,” because they had a client that was using Atlassian products. I interviewed for the position, and they offered me a job, and I thought, “Well, hey, let’s give this a try and see some other Atlassian environments out there.”

I have to admit that Atlassian wasn’t on my radar when I was in college. I also didn’t see my career going from Atlassian Admin to Atlassian Consultant, but I’m happy with the way it worked out.

David: Over my years, I had quite a few opportunities presented to me before I joined Coyote Creek. I had offers for Backend Sales or Consulting but never took the opportunities. Before I joined Coyote Creek, however, I had two separate Engagements with them and enjoyed the experience and the expertise they provided. It was a combination of being a little older in my career. After twenty years of being on the front line supporting mission-critical applications, I was ready for a new role.

My introduction to I.T was as a Computer Operator working graveyard at Oracle. And about a year into the job, I met some Senior SysAdmins that worked in the Development Datacenter, and they had all the latest cool toys. As I built a relationship with these guys, and they told me more about what they did day today, there was one aspect of their job that stood out. There were never on call. I quickly discovered that being an Engineer for Developers and supporting their systems was the dream scenario. You get all the cool toys, do the same kind of work, but nobody cares if a system is down Saturday at 10 PM.

That job at the software company was my first opportunity for that kind of work – only supporting Engineers and Developers, and there is nothing mission-critical about code deploys because it was all about the next release. So that was my first dip into that situation I always wanted since starting I.T. Consulting is kind of a natural progression there, so when the opportunity came up, I made a move.

Rodney: Honestly, I avoided becoming an Atlassian Consultant for a long while. My previous experience with it left a bad taste in my mouth, and I worried about a repeat of that experience. However, when I was in the job market last year, it got the point where I had multiple offers. I was clear during the interview with Coyote Creek that I didn’t want to return to a scenario where I was traveling more than 25% in any given month ever again. They agreed, and all told they had the better offer, so I signed on with them. And it has been a much better experience than with my previous time as a consultant.

What do you feel is the biggest difference between being an Admin and a Consultant?

Neil:  I think the most significant difference is that the consultant has the space to look at the bigger picture and to make the recommendations towards best practices. When you’re an admin in the trenches, you get so busy with the day-to-day “Hey, I need this workflow” and “I need this project” that you can lose sight of that. That’s where a consultant can come in and lead you away from some nasty rabbit holes.

David: You do not own the system or application. For where I am at in my career now, I am not looking to support environments 7x24x356, so this works out great. It can be challenging, though, if you want to make updates or correct areas you were not requested. That is still the old Admin in me. However, I still really enjoy Architecting solutions and problem-solving. I spent many years in the service industry, so it’s also the customer service aspect, and being able to provide solutions to people is what drives me today. 

Rodney: That when we come in, we are there to solve problems. If these were easy problems to solve, the company wouldn’t have hired us. But, it’s not a “You vs. Us” kind of deal. We are ultimately there to help you, so don’t be afraid to ask questions and figure out what’s going on. After all, when everyone is on the same page, it will lead to a better outcome.

What do you wish more Admins knew about being a Consultant?

Neil: That our role is to make everyone’s lives easier – including yours. We’re not there to try and complicate anything, but instead to make everything easier. And a lot of times that includes making the Admin’s lives easier, because we don’t want the interface to be messy and there to be a bunch of overhead either. 

At times I feel admins think, “Oh, they’re bringing in a consultant, they are going to try to to over-complicate this project.” But that’s not the case, we want to make everything easy too.

Olena: I think a lot of Admins don’t know how exciting it can be, how there is this non-stop race to learn new technology. It takes a very hungry approach where you want to learn new things and take on new problems all the time.

David: You do not come right out of school into a consulting role – spend time as an Admin or an Engineer to develop the technical skills to take on such a role. Additionally, develop the soft skills for communicating with your clients.

Rodney: That when we come in, we are there to solve problems. If these were easy problems to solve, the company wouldn’t have hired us. But, it’s never a “You vs. Us” kind of deal. We are ultimately there to help you, so don’t be afraid to ask questions and figure out what’s going on. After all, when everyone is on the same page, it will lead to a better outcome.

Final Thoughts

Neil: Being a consultant is unique because you are jumping from one thing to another. At times, it can be fast-paced and intense, but it keeps you from getting stuck in a rut. You are always learning something new, so you never feel you are getting stale.
Also, no one’s setup is the same, everyone is doing a slightly different thing, so it’s always an adventure.

Olena: To be a good consultant, you have to be a good Admin first, as you have to learn first-hand the pain-points of someone using the products daily. It’s like learning colors before you start the whole painting. It provides a background on how better to support clients to close the gap between the business and technical sides.

David: The best and worst aspect of JIRA is you can do anything 10,000 different ways, and as a consultant, you have to peel that back. It may or may not be the best way. But there have also been times I’ve discovered that the way I did it wasn’t the best, and the way that someone else implemented it was better than mine, so I can learn from that way.

Someone told me this a long time ago, “There is nothing more permanent than temporary!”. After all my years supporting everything from mission-critical environments to lab systems, I found this to be true. Countless times someone told me they would need access for X amount of time, or they rack some computer here for a week or need root for the day or need to run their app on my system until the budget is approved to buy new hardware.

Rodney: I feel that being a Consultant and being an Admin are two sides of the same coin. Each one emphasizes different skill sets, but you both build off of the same necessary base skills. But at the end of the day, it’s still up to all of us to learn and grow.

And that’s it for this week!

So, I’m trying something new with this interview format here – and honestly, I’m nervous about how it will play out. So if you enjoyed this post, please do take the time to like it and leave a comment!  

Don’t forget you can also subscribe below to the blog to get it delivered each week directly to your inbox. You can also follow theJIRAguy on Twitter!

But until next week, this is Rodney, asking, “Have you updated your JIRA issues today?”

Acing your ACP Exam

Rodney N.Leave a comment

So, this is a reader requested topic, but considering I have my exam scheduled for the end of next week, it’s somewhat topical. I’m not going to lie to you – the ACP exams are challenging – some of the most challenging exams you can take. But the benefits of being Atlassian certified are well worth the price of entry. Plus, we have jackets!

Image Courtesy Neil Taylor

Also, if you get four of the first five in the series, you also get a fancy shirt and title too. My goal is to be an Atlassian Certified Master by year’s end!

I want one! Image Courtesy Neil Taylor

So, to be clear, I’m not going to be giving you any answers in this blog. My goal here is to provide you with some strategies for both preparation and during the test to help you maximize your chances. Let’s get into this.

Prep Work

So, let’s begin with this. Proper Preparation Prevents Poor Performance. That’s it for this week. Until next time, my name is Rodney, asking, “Have you updated your JIRA issues this week?”

Okay, for real this time. You do need to prepare yourself for the exam. Even if you have managed these tools for years, the ACP Exam will question you on EVERY part of the relevant topics. What this means that if you are not as strong in any area – it will show.

Give yourself a Sandbox

So my first recommendation is to own a test instance to study. Since the Atlassian exams are updated regularly to test against the latest Enterprise Release of JIRA and Confluence, a cloud instance won’t suffice for studying. However, you can use VirtualBox to set up a VM on your workstation. I’ve already given you instructions on how to setup JIRA on a VM! Confluence isn’t that different, so you can also use the guide to help you with that install.

The goal here is to allow you to play with anything in Confluence or JIRA without impacting any users or coworkers. So take advantage of it!

Review the Exam Topics

Here’s the scoop – Atlassian will tell you precisely what is on each Exam. No, I am serious! On the page for every Exam – under the Exam Details – you can find a link to the Exam Topics, which is a breakdown of all topics covered.

The Exam Topics document is your detailed guide to passing the Exam. I like to print out this document and use it as a checklist of topics to study. As I find details on each item and read through it, I’ll check it off the guide, so I know what I have reviewed and what’s left. That way, I can be sure I’ve studied everything before walking into the Exam.

Exam Topic Documents

Time to take a test

So, you’ve studied all the topics, and you feel you are ready for this thing. How do you make sure you maximize your chances while taking the Exam? That is what we are going to look at now!

Question Structure

Atlassian loves a particular type of question, and they are devilishly tricky. What they will ask is for you to give the “Most Correct” response to a problem. Then they will have the following answers:

  • One that is Entirely correct
  • Two that are almost correct, save for one minor error
  • One or two that is entirely wrong

So you have to figure out what answer is entirely correct. Not easy when the details are so close. However, one trick is to read each answer in its entirety. Cross out mentally which ones you know to be wrong. If it comes down to two you think are the right answer, you have at least increased your odds from one-in-five to one-in-two.

Also, be wary of questions that ask you for two or three correct answers. These complicate things to a higher degree, but I usually end up taking a similar approach. Reach each answer thoroughly and markdown which ones you think are correct and which ones you think are wrong. Whittle down the list until you get the appropriate number you feel are correct, then double-check them for any details. This method has been the only way I’ve found to deal with these questions successfully.

Time Management

The ACP Exam is a timed test, so you must keep an eye on the clock. One strategy I take is to read the question first. If it is a question I’m confident with, I will put down my answer and move on. If it’s one I’m unsure of, mark it and move on. This way, I don’t spend so much time on questions I might get right that I miss the chance to answer questions I will get right. I will then go back and answer any question I had marked, paying particular attention to the answers to give myself the best chance. 

Occasionally, the Test will help you!

So, this doesn’t happen with every question or even every ACP Exam. But occasionally, Atlassian will like to reuse a chart, query, or some part of a problem in a later issue. When this happens, you can use the new problem to get clues to help you answer the earlier one.

It’s difficult to explain what I mean here without actually giving away an answer, though, so you will have to bear with me on that. I just wanted you to be aware that if you are lucky enough, this is a possibility.

Don’t Panic

So, I cannot stress this one enough. Don’t panic. If you stress out while taking a test, it does impact how well you do. The whole point of studying the Exam topics so to make sure that no matter what they ask for, you’ve at least read something on the subject.

And let us be honest with ourselves, what is the worst that can happen, you fail the Exam? That does suck. Trust me, the ACP-200 has a reckoning coming.

Probably the biggest reason I’m not the “Confluence Guy”

Yep, I’ve failed an ACP before. It was only by a few points (and fun fact, I’d have passed using the current standard), but that did not end my career. Atlassian will even let you know what areas you did well on and what you need to study, so you know what to focus on for your retake, which, for my next attempt at the ACP-200, is pretty much everything!

There you have it. It is an important test, and even I will get nervous going into it. I won’t even go into the panic attack you have when you click that final submit. But I know that no matter what happens, it will be alright, so I don’t panic.

And Now you are Ready!

Do you have an ACP Exam coming up? Which one would you like to take? I’m not quite ready for my next Exam, but the whole point of going ahead and scheduling it is to give me the incentive to finish up my studies. I’ll be taking the ACP-300 on Friday, May 8th.

What to be the first to find out how I did? Follow the JIRA Guy on twitter at https://twitter.com/theJIRAguy. You can also subscribe to the blog to get new posts delivered directly to your inbox! Just use the form below!

So for real this time: My name is Rodney, asking, “Have you updated your JIRA Issues today?”

JQL – How have we not talked about this already?

Rodney N.1 Comment

Hello everyone! How has your week been going? This week we are going to talk about JQL – and honestly, I’m not entirely sure how this hasn’t come up already. I know I’ve provided a few queries here and there to help you in other topics, but today I’ll be talking about some of my favorite tips and tricks to get the most out of your queries. So without any more delays, let’s get into it.

Always about the Docs

So it’s been a while since I’ve included this section – but I feel this subject could be helped with some further reading. So for this, I am referencing two documents:

I should note that the function reference is for JIRA Cloud – so it does have some new functions that have not made it to server. However, the options I’m covering here will work for JIRA Cloud, JIRA Server, and JIRA Data Center.

Currentuser()

So, this first trick is one of my favorites, as it allows you to customize a query to be specific for whoever is viewing it. In your query, you can set a user field equal to currentuser(), and the function will return whoever is logged in and viewing the query. For example, let’s take the query:

assignee = currentuser()

And let us take a look at what that looks like when running from the Admin account, and my account:

Each one returns whatever is assigned to the specific user. What’s more, this would carry over to any dashboard that uses this query – allowing you to customize a single dashboard to whoever views it.

This also works with any user field: reporter, assignee, watcher – and even custom fields. This is a handy trick to have if you don’t like to spend your day making queries and dashboards…I mean, who would enjoy that, am I right…

Working with time

So, when I’m giving some training for JQL, the most common problem people have is working with time. “How do I search for stuff in the past?” “How do I work with time?”…it seems to be a challenge.

Here’s a trick that’s always helped me. Most databases store time in the Unix Epoch time format – which is simply counting the seconds between midnight of 1 Jan 1970 and today. This means that any time in the past will be less than the current time, and any time greater than now will be in the future. Same for JQL. The past is “less than” the timestamp you are looking at, and the future is “greater than”.

However, JIRA also gives us some handy functions so we are not having to spell out particular date. First off is now(), which simply returns the current timestamp whenever it’s run. Handy when just trying to find out what’s past due, such as in this example (courtesy Atlassian):

duedate < now() and status not in (closed, resolved)

In the above query, duedate < now() returns everything that has a duedate in the past, and status not in (closed, resolved) returns everything that is currently open – giving you an idea what is past-due.

DayWeekMonthYear
startingstartOfDay()startofWeek()startaOfMonth()startOfYear()
endingendOfDay()endOfWeek()endOfMonth()endOfYear()

These are great for establishing a time frame. The really powerful thing about the functions on this table is they take parameters, meaning you can adjust them forward and backward – to say find all the issues resolved last month:

resolutiondate > startOfMonth(-1)  AND resolutiondate < endOfMonth(-1)

In this query, we shift both startOfMonth() and endOfMonth() by -1. The minus (-) tells us it’s a previous time, and the one (1) tells us to shift one whole month, meaning both of these times return values for the previous calendar month. This gives us a handy time-box for our queries – which is great for a report.

Sprints and Versions

So, this section is for my JIRA Software teams out there.

When I’m a part of Agile teams, I like to have a dashboard we can all view that tells us what’s going on in the current sprint. For this, we can use the opensprints() function. I like to pair this with a project key query so that I only get the open sprint for my project, such as:

Project = "Project Name" and Sprint in openSprints()
Pardon the blur…I actually don’t have any open Sprints in my test instance, so I had to use my work instance.

A note on openSprints() is that it only supports the operators IN and NOT IN. Using an equal sign will cause the query to return an error.

There is also the operators futureSprints() and closedSprints(). However, these return ALL future and closed sprints, respectively, so further filtering will be needed to focus on any particular sprint (such as Sprint = “Name”)

So, let us say you are in a situation where you care more about what has and hasn’t been released than what is in any particular sprint. Then you’ll be interested in the functions latestReleasedVersions() and earliestUnreleasedVersions(). These operate on the fields AffectedVersion, FixVersion, as well as any custom fields with type Version. Let’s say you want to know what bug-fixes have gone out the door:

issuetype = Bug and fixVersion = latestReleasedVersion()

The neat trick about this query is that it will automatically update if your team releases a new version, meaning if you use it in a dashboard, it will always show the bugs fixed in the last released version.

Filtering out sub-tasks

So this one comes up often. A manager wants a dashboard, but they don’t want to get bogged down in the minutia of the sub-tasks. This a handy trick I use to filter out all sub-tasks from a query. I simply and the existing query with this clause:

issuetype not in subtaskIssueTypes()
  • Before filtering out Sub-tasks
  • After filtering out Sub-tasks

It’s a simple thing to add but is an easy way to filter out all sub-tasks. Because of how it works, if you add any new sub-task types to the project in the future, the filter will still work without needing to be updated.

Cleaning up watched issues

So, JIRA in its current form sends out A LOT of emails.

Just a *few* emails…

Atlassian has heard our cries, and they are working on it, but in the meantime – this is where we are. And as an Admin, you will be touching a lot of issues – which will put you on their watchers list automatically. So I find it helpful to run this JQL and clean things up every few months.

watcher = currentuser() and project not in ("Home Project A", "Home Project B", ...)

This gives me a list of all issues I’m watching on an instance that is outside of what I consider to be my “Home Projects” I use to organize my work. From there you can run a bulk change on the list, and on Step 2, choose the “Stop Watching Issues” operation. I don’t know if this honestly counts as a JQL trick, but it has helped keep me sane many a time.

And that’s all for this time!

Did you learn anything new? What are some of your favorite JQL tricks that I didn’t cover? If I get enough I’ll do a part 2 to this!

So it’s been a busy time for me. I decided to take advantage of the current time I have to study for my next ACP exam. It’s scheduled for May 8th, which doesn’t give me too much study time left. But hopefully, I’ll be sending out good news the following week!

My Wife and I also have been working on 3D printing face-shields for first responders – you can read about our efforts (okay, mostly her efforts) on her blog here: https://cadstories.com/2020/04/17/engineering-and-covid-19/

I also have a twitter account for the blog now! If that’s your preferred source of Social Media, give me a follow! I’ll be posting blog posts there, as well as anything else Atlassian related I find interesting! https://twitter.com/theJIRAguy You can also sign up here to get an email every time I publish a new blog post! Simply use the sign-up form at the bottom of this post!

Until next time though, this is Rodney, asking “Have you updated your JIRA Issues today?”