Also, I haven't tested anything beyond the default settings, I believe you have flexibility here with respect to how message times are set and what date format is used on ingest, according to this. Note that you're free to modify the pattern layout after the date string. If this is left out or is incorrect, then this can result in messages being assigned incorrect message times at ingest which means you won't see them in queries in the expected timeframe(unless you specify "Use Receipt Time"). Per Sumo support, for the logback appender the correct date format is. Make sure your pattern layout begins with the proper date format, otherwise the default behavior of the ingest is to search for dates in your message string. The relevant section in log4j2.xml would look like this "> If your message queue is bigger, it is recommended to increase this setting or else risk loss of data in ingestion MaxQueueSizeBytes is another optional setting set to 1000000 by default for maximum capacity (in bytes) of the message queue. Appender logs may or may not (depending on the version of the Appender) display the following example log message 11:12:21,005 Log4j2-TF-1-AsyncLoggerConfig-1 WARN Evicted 1 messages from buffer Resolution:Įnsure the following settings are configured correctlyįlushAllBeforeStopping - is an optional setting that should be set to true since it will flush all messages before stopping regardless of flushingAccuracyMs and avoid potential loss of data in ingestion. The following query returns the message volume for the Default Index. The data tier can be supplied with a JSON operation to filter results of that tier.We have been losing log messages at the Sumologic collection receivers using hosted HTTP collectors that are serving as the endpoint for log messages (via log4j2.xml config file)Ībsence of configuration of flushAllBeforeStopping can cause current data in the buffer not to be ingested into Sumo Logic if the appender terminates abnormally.Ībsence of configuration for maxQueueSizeBytes would utilize the default 1million bytes for the buffer size and if the size of the data set to be ingested exceeds that, then we have seen data not be ingested into Sumo Logic. | json field=data "field","dataTier","sizeInBytes","count" as sourcehost, dataTier, bytes, count _index=sumologic_volume _sourceCategory = "sourcehost_and_tier_volume" The sourcehost name and data tier can be supplied within a JSON operation to get the data for that sourcehost. The following query returns the message volume for each Source Host. The Collector name and Data tier can be supplied within a JSON operation to get the data for that Collector.
The following query returns the message volume for a specific Collector. | json field=data "field","dataTier","sizeInBytes","count" as source, dataTier, bytes, count _index=sumologic_volume _sourceCategory = "source_and_tier_volume" The Source name and Data tier can be supplied within a JSON operation to get the data for that Source. The following query returns the message volume for a specific Source. | sum(gbytes) as gbytes by collector,dataTier | json field=data "field","dataTier","sizeInBytes","count" as collector, dataTier, bytes, count _index=sumologic_volume _sourceCategory = "collector_and_tier_volume" This example query will return the volume for each Collector. | sum(gbytes) as gbytes by sourceCategory,dataTier | json field=data "field","dataTier","sizeInBytes","count" as sourcecategory, dataTier, bytes, count _index=sumologic_volume _sourceCategory = "sourcecategory_and_tier_volume" This example query will return the volume for each Source Category by data tier. To see the data created within the data volume index, when you search, specify the _index metadata field with a value of sumologic_volume. For more information, see Search Metadata. You can query the data volume index just like any other message using the Sumo Logic search page. Your data volume is calculated based on when your logs were received, in Sumo this timestamp is stored with the _receiptTime metadata field. Each log message includes information based on one of the following index source categories. The messages contain information on how much data (by bytes and messages count) your account is ingesting. The data volume index is populated with a set of log messages every five minutes. Tracing volume for a specific collector.