I've been told that if my Log Decoder hasn't enough space on its packetdb volume, the data won't be available for investigation as well, and will be rolled over as new data comes in.
So, if the Log decoder stores all the raw logs for the purpose of investigation, then I understand that it has to be allocated 1.9TB worth of disk space.
/dev/mapper/VolGroup01-sessiondb
30G 29G 1.8G 95% /var/netwitness/logdecoder/sessiondb
/dev/mapper/VolGroup01-metadb
114G 107G 7.1G 94% /var/netwitness/logdecoder/metadb
/dev/mapper/VolGroup01-logcoll
64G 15G 50G 23% /var/netwitness/logcollector
/dev/mapper/VolGroup01-packetdb
1.9T 1.8T 111G 95% /var/netwitness/logdecoder/packetdb
What I'm unclear about is the purpose of allocating 1.8 TB to the metadb volume on the Concetrator. What exactly is stored within?
/dev/mapper/VolGroup01-sessiondb
180G 171G 9.2G 95% /var/netwitness/concentrator/sessiondb
/dev/mapper/VolGroup01-index
84G 20G 65G 24% /var/netwitness/concentrator/index
/dev/mapper/VolGroup01-metadb
1.8T 1.7T 101G 95% /var/netwitness/concentrator/metadb
Also, which volume is responsible for the availability of data on the investigation console? Is it the packetdb volume on the Log Decoder or the metadb volume on the Concentrator? As per the meta.oldest.file.time value is concerned, it seems like the value for this key found on the Concentrator is the indicator of console availability.
Please clarify.
Visham,
On the concentrator the metadb, sessiondb and index partitions are all important. The data in them combine to create what you see in the Navigate view of Investigation. The metadb and sessiondb are used to store the same data that comes from the log decoder. The metadb specifically contains all the meta generated on the log decoder from the parsers, feeds, and app rules. the sessiondb is used to contain the pointers that connect meta data to session data to log/packet data. The index contains the indexing of the meta data on the concentrator and is the most important for Investigation as it is what Investigation used directly to create the Navigate page. When you want to know how far back you can investigate you need to look at the oldest file time on each of the sessiondb, metadb and index of the concentrator. Once you have the time/dates you take the one that is the closest to current and that will be how far back you will be able to investigate. As mentioned before this is because the three rely on each other.
On log decoders a lot of meta is generated per unit of time compared to a packet decoder. This is why a large metadb on the concentrator is a must when connected to a log decoder. The metadb, and sessiondb on the log decoder itself is just a temporary holding location for this data until the concentrator can consume it from the log decoder. This allows for a buffer in case the concentrator is offline or unable to connect with the log decoder. This is also why these partitions are so much smaller than what is on the concentrator. The index on the log decoder is only there to index what the decoder needs and is not transferred to the concentrator as the concentrator generates its own indexes at time of ingestion of the session and meta data from the log decoder. It uses the index-concentrator.xml and index-concentrator-custom.xml to create the required indexes.
I hope this helps answer your question.