Enhancing Log Management in Multi-Node Jira and Confluence Data Center Setups with Last Log

[#1]

Managing logs in enterprise environments, particularly across multiple nodes, is often one of the most frustrating aspects of troubleshooting Jira and Confluence. As administrators, we know how critical log files are in identifying and resolving issues—whether it's a performance bottleneck, plugin conflict, or a configuration issue. With the latest release of Last Log for Jira and Confluence, version 2.1.0, those days of log-related headaches are over. Let’s explore how this release changes the game for admins managing multi-node setups.

Log viewer within Last Log for Jira

Why Log Files Are Key to Effective Troubleshooting

Log files offer a wealth of information crucial for diagnosing issues within Jira and Confluence. They are a historical record of the application's encounters, whether errors, warnings, or performance metrics.

Consider a scenario where user authentication fails unexpectedly. To resolve it, admins typically refer to the application logs, atlassian-jira.log, or atlassian-confluence.log.

Without easy access to these logs across your entire system, identifying root causes can take hours or even days.

Essential Logs to Monitor in Jira and Confluence

Some logs are more revealing than others when pinpointing specific issues. Here’s a list of key logs to keep an eye on:

1. Application Log (atlassian-jira.log or atlassian-confluence.log): Offers insights into everything from user authentication, application errors, database issues, and plugin activities.

2. Slow Queries Log (atlassian-jira-slow-queries.log - Jira-only): Tracks JQL queries and their sources for executions surpassing the default threshold of 400 milliseconds.

3. Profiling Log (atlassian-jira-profiler.log or atlassian-confluence-profiler.log): Lists performance traces to investigate application slow-downs (has to be enabled via Logging & Profiling in the administration - see https://confluence.atlassian.com/adminjiraserver/logging-and-profiling-938847671.html)

4. Synchrony Log (atlassian-synchrony.log - Confluence-only): Crucial for tracking issues related to collaborative editing in Confluence.

When issues arise in these complex environments, multiple logs might hold the clue to a single issue, and navigating between them can be a daunting task.

Extra Tip: Dive Deeper on Apps

If you encounter problems related to a specific app, temporarily increasing its log level might help you or the supporting vendor narrow down the problems. To do so, configure the corresponding app within the Default Loggers sections in the Logging and Profiling administration menu (see https://confluence.atlassian.com/adminjiraserver/logging-and-profiling-938847671.html). The package name of interest is usually the app key found within the UPM.

The Challenges of Managing Multi-Node Setups

In large-scale Jira and Confluence deployments, especially those running in data center environments, organizations typically distribute their workloads across multiple nodes. While this setup enhances scalability and performance, it introduces additional challenges—particularly in log management.

In traditional setups, an admin must log in to each server separately, retrieve log files, and often parse multiple files in parallel to diagnose a single issue. Imagine switching between three or more servers to find the one log entry pointing to a memory leak or plugin crash. That’s a major time sink.

Last Log for Jira and Confluence: The Solution You’ve Been Waiting For

With the latest release of Last Log, you can finally say goodbye to those multi-node challenges. Last Log’s new multi-node support consolidates log files from all your nodes into a single, unified view directly within the Admin UI.

No more manually SSH-ing into different servers, no more downloading logs individually, and no more cross-referencing timestamps across nodes. You can now monitor, filter, and troubleshoot all logs, regardless of the server they’re generated on, from a single location.

This new release is especially helpful for admins who manage large, distributed instances. Whether dealing with a performance issue affecting multiple nodes or troubleshooting a single node's network connection, Last Log has you covered.

In earlier versions, accessing the log files directly from the administration UI was already a more convenient approach than connecting to the actual server(s). However, troubleshooting different nodes required a manual switch that involved updating your cookies within your browser (see https://confluence.atlassian.com/enterprise/jira-data-center-load-balancer-examples-781200827.html) since there’s no way to do so from within the UI yet (see and vote https://jira.atlassian.com/browse/JRASERVER-68430).

What’s New in Version 2.1.0?

Node and log picker within Last Log for Jira

One of the most significant updates in version 2.1.0 is the shift from direct access to local log files to a database-driven model. This revision has completely overhauled the backend, allowing Last Log to synchronize logs from all nodes into a central database.

Here’s what this means for you:

• Faster log retrieval: You no longer need to connect to each node manually; the logs are automatically synchronized to the database and readily available.

• Improved performance: Instead of searching individual log files, queries are run against the database, making it quicker and easier to filter for specific error codes or timestamps.

• Better log retention management: With logs synchronized into a database, managing log retention and archival across nodes is simpler.

By centralizing log management across all nodes, Last Log helps Jira and Confluence administrators significantly reduce the time it takes to troubleshoot issues—especially in multi-node environments.

TL;DR - see Last Log for Jira in action: https://youtu.be/OHLSyF9khNY

---

Conclusion

Troubleshooting across multi-node setups no longer has to be the time-consuming ordeal it once was. With Last Log’s new multi-node support, your log management is faster and more efficient than ever. Whether you're diagnosing a single user issue or investigating a larger system-wide problem, Last Log for Jira and Confluence puts the power back in the hands of admins. Version 2.1.0 marks a new era in log management for enterprise-scale Jira and Confluence instances.

Head over to the Atlassian Marketplace to download the latest version and try it for free:

• Last Log for Jira

• Last Log for Confluence

Stay tuned as we continue to innovate and simplify your admin life with Last Log!

[Heiko Gerlach]

Hi,

please help me to understand why saving logfiles to Database is a good Idea. If there would a separate Database available for this I would agree some how. But blasting all log data into Jira Database is a very poor approach and you only can collect log files with a defined apache log format. Any other format crashes your app, at least with the version we have tested. Have in mind that log files can contain any type of Data, even Base64 encoded attachments. Would you agree to store attachments in the Database?

Cheers

Heiko