Website Check Script - if down, create task

[Timothy Ryner]

Has anyone ever written a script that touches an external (to Jira) webpage every hour or so, and performs some action in Jira based on the response code?

I manage a bunch of web apps, and would love to get Jira issues sent to me when a site responds with something other than a 200?  Create a new issue in a project with details on the site that failed the status check.

Ideally, I would have a bunch of parent issues for the sites, and if there is a problem with a site, a subtask is created under the site’s parent issue. That way, I could add more sites to the checker over time, and let the script loop through all of the main issues. 

We are running Jira Server v9.7, and the latest Scriptrunner & Automation plugins. 

Anyone have experience touching external sites with scriptrunner? Even though I’m not fluent with groovy, I could probably piece together the rest of the script myself using previous community posts and the Adaptivist Library (and ChatGPT…LOL). 

Thanks all!

[Graham Twine · Accepted solution]

Hello @Timothy Ryner

Is Jira the right place to be monitoring health of another system though?

If you have scriptrunner then you  can create a Job that is scheduled.

There are a number of ways to do this but I guess as this is in groovy lets use this.

Have a look at groovyx.net.http.HttpResponseDecorator

import groovyx.net.http.ContentType
import groovyx.net.http.HTTPBuilder
import groovyx.net.http.Method
import groovyx.net.http.HttpResponseDecorator


log.info("Checking if the system is running.")

def host = 'https://host.domain.com'
def http = new HTTPBuilder(host)

http.request(Method.GET) { req ->

   uri.path = '/rest/api/latest/myself'
   headers.'APIKEY' = 'i-need-a-key'
   response.success = { HttpResponseDecorator resp, data ->
     log.info "System running: ${resp.statusLine}"
   }
   response.failure = { HttpResponseDecorator resp ->
      // create an issue in Jira
      createIssue(
   }
}


def createIssue(String code, String system...) {

}

[Radek Dostál]

HTTP utilities aside, I would focus on the point Graham mentioned - you don't want to turn Jira into a monitoring tool, because it isn't suited for it and it's just a "tool" between monitoring and the target site. Whatever it is you're about to do, there are better apps to do it, rather than creating some inline scripts you have virtually zero control of. What if the jobs stop working? How will you solve logging? What if Jira isn't working, is the monitoring in turn also not working? What if the automation user gets inactivated / loses permissions? This is prone to a lot of chained issues that you would be trying to solve over a long period of time and it still will have a room for error. Jira is not the right tool to do monitoring from, and by using it so you will eventually, most likely, hit some of the guardrails and degrade performance of the instance.

I had my experience with people trying to make their projects work as databases, monitorings, log collectors, and it was always ugly and resulted in them going away using proper tools for the job, rather than pulling the entire instance down because of their rather dull automation (which they found to be failing on several occasions). Guardrails are real, and they do bite if you use Jira for something it wasn't meant to do.

[Timothy Ryner]

Thanks Graham for the start!  I'll fiddle with this over the coming weeks!  

[Timothy Ryner]

Graham,

I'm working through the script, and it's going relatively well.  A great little project to start learning groovy!

Question:  Is there a way to handle timeouts?  

The reponse.success and response.failure handlers are great for when the site actually returns a response of some kind.  But I can't figure out how to handle a no response situation in some way, like simply posting a log message that it was a timeout.

I'm more used to scripts that use if/else statements; easier to read and interpret what is happening.  I'm having trouble understanding the syntax for HTTPBuilder.  I've been nosing around this page: HTTPBuilder (REST Assured 3.2.0 API) (javadoc.io)

Any help is greatly appreciated!  And thanks again for getting me this far.  

http.request(Method.GET) { req -> 

response.success = { 
  HttpResponseDecorator resp, data -> 
    logger.info ("PINGBOT SUCCESS - Issue: ${mutableIssue} Site: ${issueSiteCheckURL} Status: ${resp.getStatusLine().getStatusCode()}");
//for now, just logging
//eventually adding the Jira actions here 

}

response.failure = { 
  HttpResponseDecorator resp ->
    logger.info ("PINGBOT FAILED - Issue: ${mutableIssue} Site: ${issueSiteCheckURL} Status: ${resp.getStatusLine().getStatusCode()}");
//for now, just logging
//eventually adding the Jira actions here  
}

//not sure how to add additional logic to handle timeouts

[Graham Twine]

Hello Timothy,

This should get you started.

import org.apache.http.client.config.RequestConfig

// You may want to consider different timeouts
def TIMEOUT = 10000
def requestCfg = RequestConfig
         .custom()
        .setConnectionRequestTimeout(TIMEOUT)
        .setConnectTimeout(TIMEOUT)
        .setSocketTimeout(TIMEOUT)
        .build()

def http = new HTTPBuilder(host)
http.setClient(
    HttpClients.custom()
   .setDefaultRequestConfig(requestCfg)
   .build()
)

[Graham Twine]

One can do different things for different errors as well.

HTTPBuilder http = new HTTPBuilder(host)

http.request(Method.POST, ContentType.JSON) { req ->

   response.success = { HttpResponseDecorator resp, data ->
      // Alls well that ends well 

   }
   response.'400' = { HttpResponseDecorator resp ->
      // Do something

   }
   response.'404' = { HttpResponseDecorator resp ->
      // Do something else

   }
}

[Emaan Fatima]

Yes, it's possible to achieve this with ScriptRunner in Jira. You can write a script that periodically checks external webpages, creates new Jira issues if the response code is not 200, and organizes them as subtasks under parent issues for each site. While groovy scripting skills are beneficial, you can leverage community posts, Adaptivist Library, and tools like ChatGPT for assistance in piecing together the script. With ScriptRunner and Automation plugins, you can automate this process efficiently on Jira Server v9.7  Like i apply on website.

[Bilal Hussain]

Great idea, Timothy! Monitoring website statuses via Jira and creating tasks for non-200 responses is a smart way to stay on top of issues. Your initiative to utilize Groovy and community resources shows dedication. Keep up the good work

[Sonia]

To monitor websites externally in Jira, leverage ScriptRunner with Automation plugins. Schedule a script to check sites hourly. If the website  response isn't 200, create a new issue in Jira with details. Organize issues with parent tasks for websites and subtasks for issues. Utilize Groovy with Adaptivist Library and community posts for scripting assistance.

[Graham Twine]

Automation plugin is not required as Scriptrunner already has the ability to schedule tasks and even create the issue right there in the same script.

I truly feel like monitoring in Jira is like taking a ferrari off road or competing in F1 with a Jeep  :(

[Nic Brough -Adaptavist-]

Hi Graham, 

That response was from a spam bot.

But yes, I totally agree.

 Jira is not a monitoring, or even alerting tool.  It's the place to create a task to get a team to look at it, and track their response, arguably part of your monitoring system, but not the actual core of the monitoring.

Even the most simple monitoring I do is done with a set of tools suited for monitoring, all set up to raise issues in Jira if they spot certain problems (and usually another system for alerting)

[Timothy Ryner]

I've been hitting nails with my Jira hammer for a while, this is just the latest example.  Non-standard use cases are my jam.  :-)  

Everyone is totally correct.  This is not the proper way to do monitoring & alerting.  There are just some very unique circumstances for why I this is valuable to my organization, but I won't bore Nic the Great with those details now.

I did get a simple version of the monitoring set up, and it ain't half bad, although not something I'd brag about yet.  If I ever get time to polish it, I'll do a whole write up and share it.

Stay classy.

[Graham Twine]

@Timothy Rynerwhat was the solution. You didn't accept any of these proposals ;)

[Timothy Ryner]

How inconsiderate of me!  Again, thanks for helping me down the path!

Here's the gist of what's running now. Again, this isn't polished, but it does do what I need, with some limitations.

• Any user can submit issues to the PING project, they fill in the "URL" field.
• An Automation is scheduled to trigger the PING script every 5 minutes
  
  • The PING script pulls the "URL" field and checks that site.
  • The site responds (or times out).
  • The script writes the http.request reponse code to the "Event" field. 
• Another Automation Rule watches for changes in the "Event" field, and transitions the issue based on the value.
  • Success -> "Pass" status
  • Failure -> "Fail" status
• A Kanban board displays all issues based on Reporter (so teams can only see the site monitoring issues they submit).
  • Columns and colors make is apparent which sites are up and down.
  • Notifications are sent out to the Reporter when their site is in the Fail status.

I needed to pause work about 8 months ago (thanks to uptick in vulnerabilities keeping everyone on their toes), so I don't remember what the odd behaviors were that I wanted to improve.  401 auth redirects were one issue, I think.  I fiddled with passing authentication creds along with the request, or to handle specific response codes...but I can't remember why I couldn't get that to fully work the way I want. 

Anyway, it checks a few dozen simple sites that some teams manage, and works well enough for that.  We're all in Jira all day, so it's nice getting notified there.

When I circle back on this to polish it, I'll do a nice write up. :-) 

try {

    http.request(Method.GET) { req ->
        response.success = { HttpResponseDecorator resp, data ->
            logger.info("Success response for Issue: ${mutableIssue} Site: ${siteCheckURL}")        
            int statusCode = resp.getStatusLine().getStatusCode()
            def fieldConfig = siteEventField.getRelevantConfig(mutableIssue)
            def option = ComponentAccessor.optionsManager.getOptions(fieldConfig).find { it.value == statusCode.toString() }
            mutableIssue.setCustomFieldValue(siteLogsField, statusCode.toString())
            if (option && (currentEventValue == null || !currentEventValue.contains(option))) {
                mutableIssue.setCustomFieldValue(siteEventField, [option])
                issueManager.updateIssue(scriptUser, mutableIssue, com.atlassian.jira.event.type.EventDispatchOption.DO_NOT_DISPATCH, false)
                logger.info("Updated Event field for Issue: ${mutableIssue} with Status Code: ${statusCode}")
            }
        }

        response.failure = { HttpResponseDecorator resp ->
            int statusCode = resp.getStatusLine().getStatusCode()
            def fieldConfig = siteEventField.getRelevantConfig(mutableIssue)
            def option = ComponentAccessor.optionsManager.getOptions(fieldConfig).find { it.value == statusCode.toString() }
            mutableIssue.setCustomFieldValue(siteLogsField, statusCode.toString())
            if (option && (currentEventValue == null || !currentEventValue.contains(option))) {
                mutableIssue.setCustomFieldValue(siteEventField, [option])
                issueManager.updateIssue(scriptUser, mutableIssue, com.atlassian.jira.event.type.EventDispatchOption.DO_NOT_DISPATCH, false)
                logger.info("Updated Event field for Issue: ${mutableIssue} with Status Code: ${statusCode}")
            }
        }
    }

[Aristotle John]

What a fantastic discovery! This tool seems to be a perfect fit for my unique work environment, as it directly addresses many of the challenges mentioned in the marketing materials. Now that I'm aware of its existence, I can reevaluate our processes with a fresh perspective, and I might even consider seeking funding to implement this solution. Click here to see implementation.

[Darrell Knight Knight]

Yes, it is indeed possible to achieve your desired functionality using Jira's ScriptRunner add-on. ScriptRunner allows you to write custom scripts using Groovy, a powerful scripting language running on the Java Virtual Machine (JVM). To periodically check the status of external webpages and create Jira issues based on the response code, you can utilize ScriptRunner in combination with Jira Automation. Here's a high-level overview of the process: Begin by setting up a Jira project dedicated to holding the parent issues for the websites you wish to monitor. Create a script within ScriptRunner that performs regular status checks on the external webpages. Groovy's HTTP client libraries can be employed to send requests and handle responses. Within the script, examine the response code and relevant information. If the code indicates an error (e.g., not 200), leverage the Jira API (via ScriptRunner) to generate a subtask under the corresponding parent issue within your Jira project. Schedule the script to execute at regular intervals using ScriptRunner's provided scheduling mechanisms, such as cron jobs or built-in schedulers. Optionally, you can configure Jira Automation to send you notifications whenever new subtasks are created or trigger additional actions based on the script's output.

[Madeleine Vironda -Adaptavist-]

Hi @Timothy Ryner 

I’m Madeleine, the Product Manager of a new ScriptRunner for integrations app by Adaptavist called Stitch It.

As the others have said, Jira may not be an optimal monitoring tool. If you do however decide to proceed with your implementation Stitch It could facilitate this for you (and any other integrations you might need between your bespoke tools and your Jira On-Premise).

We don’t have a bespoke template (Stitch It equivalent to a ScriptRunner Library script) that does exactly what you need, but we have a template that demonstrated how to hit a URL and inspect the status code and a template to create an issue in Jira on-prem, if you look at these templates hopefully you can stitch together a script and hook them up with our scheduled trigger to run your integration periodically. In case you need to connect to Jira on-prem instance behind the firewall, here are instructions on how to achieve it.

If you want to learn more about Stitch It you can also head over to our website here.

[Timothy Ryner]

This is a neat tool!  I work in an interesting environment with many of the exact issues outlined in the marketing slick.  Now knowing this exists, I'll look at our processes through a different lens, and I might see about getting funding.  Thanks!

[Madeleine Vironda -Adaptavist-]

Great, I'm very glad to hear it! You can test the app for free for a few more months until we come out of Beta, otherwise feel free to contact us via the website or via email directly (mvironda@adaptavist.com) and we'd be happy to arrange a demo!