nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How are you monitoring your Atlassian stack?

Nic Brough -Adaptavist-

I've been doing this for years and run into all sorts of ways of monitoring at many levels. Most of it was good and useful, some less so. I do not know a lot about it beyond "you should monitor" and "there are good tools out there to do it"

So I'm interested to see how everyone here does it (or not). Some starter questions:

What tools are you using for it?
Has the recent addition of JMX stuff in Jira been useful?
Barring the obvious "it responds to standard requests", what do you look for in general?
When you can quantify, what metrics do you use?

Comments

Aron Gombas _Midori_

This is definitely a question of high importance.

I had a discussion with a friend company some months ago when I vaguely recommended them New Relic to monitor their Confluence instance.

They told me they already tried, but New Relic has slowed down their Confluence to a degree where end-users actually noticed that (which means: significantly). I can't confirm or reject it, this is just something I heard.

They also told me they have a periodic "health check" procedure that they execute on their Atlassian applications instances every week. This is a collection of home-grown scripts, SQLs and so. Not strictly related to monitoring, but it improves their applications' health and uptimes.

Seshadri Kothandaraman

Timely question !

I would first like to know the parameters we should monitor. IMHO, there are many metrics that can be monitored using system-level utilities (like disk space, memory/swap usage, cpu, etc.), but they would mostly symptomatic of a deeper problem with the stack.

Anyone tried sending custom metrics to Datadog?

Ed Bukoski

My team monitors everything we can. We real time collect 100+ metrics and render them on dashboards. When Bitbucket is having an issue (its slow, users reporting errors, etc) the metrics enable us to quickly focus it on what the problem is and possible remediations.

Some metrics that have proven to be critical:

SCM hosting tickets
SSH sessions active
SSH sessions errors
DB connection pool in-use / max
Requests/sec
Response latency
Network incoming/outgoing connections
Network TCP errors
Network throughput

We also monitor the usual CPU, system memory, JVM memory, JVM GC, disk I/O etc but historically haven't figured into health or scaling issues.

The list above is also useful when load testing -- you can determine bottlenecks and tune it to squeeze out more performance.

For data collection we use a custom java agent that sends metrics directly to our internal home-grown data collection datastore.

Whatever tool you use it is some effort to set it up but worth the effort. Its a true force multiplier for ops support and scaling/tuning.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence

jira

bitbucket