Confluence Analytics Events Are Not Being Retained As Long As Expected

Still need help?

The Atlassian Community is here for you.

Ask the community


   

Platform Notice: Data Center - This article applies to Atlassian products on the Data Center platform.

Note that this knowledge base article was created for the Data Center version of the product. Data Center knowledge base articles for non-Data Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible

Summary

Confluence Analytics allows you to retain data based on both a date range and a limit on the number of events. Since raising the limit on events over 20 million can cause performance issues, it is not recommended. However, even with this high of a limit in place, you may find that your records do not go back as far as you expect. This is likely due to spikes in event creation. This guide will help you identify where these spikes are coming from.

This guide does not advise manually altering or removing any of the data you identify. It is strictly for informational purposes.

Background Notes

  • Before checking anything below, you should ensure that the Confluence Analytics data retention settings match what you intend them to be.
  • Confluence Analytics events are stored in the AO_7B47A5_EVENT table.
  • For this information to be useful, you should be comfortable looking at your database.

Analysis Steps

  1. List the number of events associated with each space:

    SELECT SPACE_KEY, COUNT(SPACE_KEY) as event_count
    FROM AO_7B47A5_EVENT
    GROUP BY SPACE_KEY
    ORDER BY event_count DESC
  2. List the number of events associated with each user:

    SELECT um.username, COUNT(um.username) as event_count
    FROM AO_7B47A5_EVENT AS ae
    JOIN user_mapping AS um
    ON ae.USER_KEY = um.user_key
    GROUP BY um.username
    ORDER BY event_count DESC 
  3. Use the above information to identify potential high volume spaces or users. It's important to note that being high volume does not necessarily mean there is a problem, but it gives you a starting point for investigation.

  4. Use the following two queries to identify the events for the users and/or spaces you want to investigate:

    SELECT *
    FROM AO_7B47A5_EVENT
    WHERE SPACE_KEY = '<DESIRED_SPACE_KEY>';
    
    SELECT *
    FROM AO_7B47A5_EVENT AS ae
    JOIN user_mapping AS um
    ON ae.USER_KEY = um.user_key
    WHERE username = '<DESIRED_USERNAME>';
  5. Using the contents of the AO_7B47A5_EVENT table, you can identify the types of events being logged, when they were logged, and other specifics that can help you identify the cause of your rentention issue. If you need additional assistance with interpreting these results, please reach out to our support team.



Last modified on Nov 15, 2024

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.