Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.

Log Retention

As you may or may not know, your device can only store so many logs. This is quite a popular topic. Some have asked questions about log retention: Where did my logs go? Why am I only seeing two days of logs? Are the older logs gone?

Well, your questions about Log Retention can be answered on LIVEcommunity. Here's how you can find more information:

View of suggested search results for log retention in LIVEcommunity.

Log retention is actually very simple. It all depends on how much you are logging in combination with how much space you have available. If you are logging EVERYTHING and keep all your logs locally on your firewall, then it's likely that you'll only have a couple of days worth of logs available—possibly even less.

If you have an M-100/M-200 or M-500/M-600 Panorama, then you can add more hard drives. If you have a virtual Panorama, you can allocate more log storage. In doing so, you can extend your log retention.

When you run out of space, the Palo Alto Networks firewall will automatically delete the oldest entries in that specific log. When you are limited to store your logs locally, you can adjust the reserved space for each type of log by going to Device > Setup > Management > Logging and Reporting Settings as seen in the screenshot below.

View of Logging and Reporting Settings.

If you see a drastic change in log retention, a common reason might be that there's currently more traffic hitting a rule that is being logged. To retain the same log retention, you will need to adjust your storage allocation. That being said, it might also be a good idea to review what exactly you are logging. Is it really necessary to log at start AND end of a session? Do you really need all those internal (trusted) sessions logged?

In the newer PAN-OS versions, there's a cool feature in ACC that allows you to see how many times a specific rule was hit over time. This makes it easier to troubleshoot a sudden decrease in log retention while searching for the rule that is eating up all your available log space.

View of rule usage by session.

Simply put, certain kind of security logs just need much longer retention than just a couple of days. With that in mind, it might even be a good idea to look into alternative log storage solutions when you are planning for long-term log retention. This is especially true when you have a very high log rate. Your local device will not be able to hold your logs for that long, but an M-100/M-200 or M-500/M-600 Panorama or a log collector might be the solution you need.

How do I check my current log retention?

Very simply by using the following CLI command 'show system logdb-quota'. This will produce the current log retention for each type of log file on your local firewall. It might look something like this:

>show system logdb-quota

....

Disk usage:
traffic: Logs and Indexes: 26G Current Retention: 340 days
threat: Logs and Indexes: 3.0G Current Retention: 829 days
system: Logs and Indexes: 1.2G Current Retention: 731 days
config: Logs and Indexes: 1.2G Current Retention: 1007 days
trsum: Logs and Indexes: 3.7G Current Retention: 998 days
hourlytrsum: Logs and Indexes: 1.2G Current Retention: 998 days
dailytrsum: Logs and Indexes: 160M Current Retention: 998 days
weeklytrsum: Logs and Indexes: 76M Current Retention: 996 days
thsum: Logs and Indexes: 850M Current Retention: 998 days
hourlythsum: Logs and Indexes: 66M Current Retention: 998 days
dailythsum: Logs and Indexes: 21M Current Retention: 998 days
weeklythsum: Logs and Indexes: 7.2M Current Retention: 996 days
appstatdb: Logs and Indexes: 82M Current Retention: 1007 days
userid: Logs and Indexes: 46M Current Retention: 976 days
hipmatch: Logs and Indexes: 132K Current Retention: 916 days
extpcap: Logs and Indexes: 20K Current Retention: 0 days
urlsum: Logs and Indexes: 580M Current Retention: 342 days
hourlyurlsum: Logs and Indexes: 306M Current Retention: 342 days
dailyurlsum: Logs and Indexes: 26M Current Retention: 342 days
weeklyurlsum: Logs and Indexes: 9.1M Current Retention: 282 days
application: Logs and Indexes: 39M Current Retention: 959 days
filters: Logs and Indexes: 28M Current Retention: 621 days
dlp: Logs and Indexes: 20K Current Retention: 175 days
hip_report_base: Logs and Indexes: 1.6M Current Retention: N/A
wildfire: Logs and Indexes: 40K Current Retention: N/A

Cortex Data Lake (previously Logging Service)

Palo Alto Networks Cortex Data Lake (previously called Logging Service) provides cloud-based logging for our security products, including our next-generation firewalls, Prisma Access (previously called GlobalProtect cloud service), and Traps management service. Cortex Data Lake lets you collect ever-expanding volumes of data without needing to plan for local compute and storage, and it is ready to scale from the start. Once you're sending logs to Cortex Data Lake, you can start leveraging Cortex apps that analyze and report on your network, cloud, and endpoint data.

This cloud-based logging infrastructure is available in two regions—the Americas and the European Union. Review the Cortex Data Lake privacy datasheet for details on how network data is captured, processed, and stored.

Cortex Data Lake - Getting Started

Please post any comments, suggestions, or questions you would like answered below!

But before doing that, you might want to check on the LIVEcommunity Blog and discussions,

Your question might have been answered already. Below is just a small set of log retention articles discussions that can help answer your questions as well.

Logs Retention - User Discussion

Log Retention - Second User Discussion

Retention period for traffic logs on Panorama - User Discussion

PA-3020 log retention period - User Discussion

Critical Panorama Alarm - Minimum Retention Period (Days) Violated for Segment

-Kiwi out!