A subsearch is a search within a search. If your main search requires data as a result of another search, then you can use Splunk's subsearch capability to achieve it. Say you want to find statistics about the server that generates the most 500 errors. A 500 error is a general HTTP status code that means that something has gone wrong with the server, but it doesn't know specifically at this particular time what is wrong. Obviously, if you are responsible for running a website, you want to pay close attention to 500 errors and where they are coming from. You can achieve your goal of finding the culprit server with two searches.

The first search, shown next, will return the server address with the most 500 errors. Note you are setting the limit to 1 and giving the instructions (using the + sign) to just include the server_ip field:

SPL> index=main http_status_code=500 | top limit=1 server_ip 
     | fields + server_ip

The result of this code is as follows:

10.2.1.34

In the second search, you can then filter your desired query with the server_ip value from the first result and ask for the top values of the http_uri and client_ip fields, as shown in the subsearch highlighted in the following code. In the subsearch, you are simply asking for the top http_uri and client_ip fields for data that has been piped through to that point, or the data from the indicated server with the top number of 500 codes. This information will be very useful to you as you try to pinpoint the exact problems with the web server.

In the second search, you can then filter your desired query with the server_ip value from the first result:

SPL> index=main server_ip=10.2.1.34 | top http_uri, client_ip

You can combine these two searches into one using a subsearch. Also note that a subsearch appears within brackets. It is important to understand that a subsearch is processed before the search is actually carried out or parsed:

SPL> index=main [ search index=main http_status_code=500 
     | top limit=1 server_ip
     | fields + server_ip ] | top http_uri, client_ip

A subsearch can also be useful if you want to search on data that depends on what you have found in another dataset. For example, consider a case where you have two or more indexes for various application logs. You can set up a search of these logs that will let you know what shared field has a value that is not in another index. An example of how you can do this is shown here:

SPL> sourcetype=a_sourcetype NOT [search sourcetype=b_sourcetype 
     | fields field_val]

The default number of results is set to 100. This is because a subsearch with a large number of results will tend to slow down on performance.

Once you have done a subsearch, you may want to add the results of that subsearch to another set of results. If that is the case, and you are using historical data, use the syntax provided here to append the subsearch:

SPL> . . | append [subsearch]

You can also specify various timing options if you like.

You can also use the join command to join the results of the subsearch to your main search results, but you will likely often opt to use append instead, if you have historical data. Again, the basic syntax is simple:

SPL> . . | join [subsearch]

This will default to an inner join, which includes only events shared in common by the two searches. You can also specify an outer or left join. The outer join contains all the data, whereas the left join contains the data from events fulfilling the left search, as well as the events that are shared in common. You can also specify a field list for the join, instead of including all fields by default.

If you need to create a field based on the data present in an event, you can use the eval command to create a field variable and use if to check for that condition.

The if function takes the form of:

SPL> | eval value=if(condition, field1, field2)

Say you want to create two additional fields during search time to determine whether a destination is in the East Coast or not. Using the code presented next, if a destination URI has NY, MIA, or MCO in it, a new field called East will be added to each of those events. Otherwise, Splunk will add a new field called Others. Once that has been done, this code will list the newly-created Region field and http_uri for all events, and will sort by Region:

SPL> index=main http_uri="/destination/*/details" 
 | eval Region=if(match(http_uri, "NY|MIA|MCO"), "East", "Others") 
 | top 0 Region, http_uri | sort Region

A little regular expression has been used here to do a case statement between the airport codes: NY|MIA|MCO. If the http_uri includes NY, MIA, or MCO, then its Region field value will be East; otherwise it will be Others.

This should now return the data with the new fields:

You can optimize this query by using match instead of if and account for West and Central.

We also introduce the case function here. In the following illustration, you will see that we can set the value of a field by giving it a value of Label1 if Condition1 is true, Label2 if Condition2 is true, and so on:

SPL>| eval Value=case(Condition1, "Label1", Condition2, "Label2", 
          ConditionX, "LabelX")

Let us tweak the previous query to use case instead of if:

SPL> index=main http_uri="/destination/*/details" 
     | eval Region=case(match(http_uri, "NY|MIA|MCO"), 
           "East",  match(http_uri, "WAS|AK|LAX|PML"), "West", 
           match(http_uri, "HOU"), "Central") 
     | top 0 Region, http_uri | sort Region

The result will now properly classify the destinations based on the region:

A subsearch is a search within a search. If your main search requires data as a result of another search, then you can use Splunk's subsearch capability to achieve it. Say you want to find statistics about the server that generates the most 500 errors. A 500 error is a general HTTP status code that means that something has gone wrong with the server, but it doesn't know specifically at this particular time what is wrong. Obviously, if you are responsible for running a website, you want to pay close attention to 500 errors and where they are coming from. You can achieve your goal of finding the culprit server with two searches.

The first search, shown next, will return the server address with the most 500 errors. Note you are setting the limit to 1 and giving the instructions (using the + sign) to just include the server_ip field:

SPL> index=main http_status_code=500 | top limit=1 server_ip 
     | fields + server_ip

The result of this code is as follows:

10.2.1.34

In the second search, you can then filter your desired query with the server_ip value from the first result and ask for the top values of the http_uri and client_ip fields, as shown in the subsearch highlighted in the following code. In the subsearch, you are simply asking for the top http_uri and client_ip fields for data that has been piped through to that point, or the data from the indicated server with the top number of 500 codes. This information will be very useful to you as you try to pinpoint the exact problems with the web server.

In the second search, you can then filter your desired query with the server_ip value from the first result:

SPL> index=main server_ip=10.2.1.34 | top http_uri, client_ip

You can combine these two searches into one using a subsearch. Also note that a subsearch appears within brackets. It is important to understand that a subsearch is processed before the search is actually carried out or parsed:

SPL> index=main [ search index=main http_status_code=500 
     | top limit=1 server_ip
     | fields + server_ip ] | top http_uri, client_ip

A subsearch can also be useful if you want to search on data that depends on what you have found in another dataset. For example, consider a case where you have two or more indexes for various application logs. You can set up a search of these logs that will let you know what shared field has a value that is not in another index. An example of how you can do this is shown here:

SPL> sourcetype=a_sourcetype NOT [search sourcetype=b_sourcetype 
     | fields field_val]

The default number of results is set to 100. This is because a subsearch with a large number of results will tend to slow down on performance.

Once you have done a subsearch, you may want to add the results of that subsearch to another set of results. If that is the case, and you are using historical data, use the syntax provided here to append the subsearch:

SPL> . . | append [subsearch]

You can also specify various timing options if you like.

You can also use the join command to join the results of the subsearch to your main search results, but you will likely often opt to use append instead, if you have historical data. Again, the basic syntax is simple:

SPL> . . | join [subsearch]

This will default to an inner join, which includes only events shared in common by the two searches. You can also specify an outer or left join. The outer join contains all the data, whereas the left join contains the data from events fulfilling the left search, as well as the events that are shared in common. You can also specify a field list for the join, instead of including all fields by default.

If you need to create a field based on the data present in an event, you can use the eval command to create a field variable and use if to check for that condition.

The if function takes the form of:

SPL> | eval value=if(condition, field1, field2)

Say you want to create two additional fields during search time to determine whether a destination is in the East Coast or not. Using the code presented next, if a destination URI has NY, MIA, or MCO in it, a new field called East will be added to each of those events. Otherwise, Splunk will add a new field called Others. Once that has been done, this code will list the newly-created Region field and http_uri for all events, and will sort by Region:

SPL> index=main http_uri="/destination/*/details" 
 | eval Region=if(match(http_uri, "NY|MIA|MCO"), "East", "Others") 
 | top 0 Region, http_uri | sort Region

A little regular expression has been used here to do a case statement between the airport codes: NY|MIA|MCO. If the http_uri includes NY, MIA, or MCO, then its Region field value will be East; otherwise it will be Others.

This should now return the data with the new fields:

You can optimize this query by using match instead of if and account for West and Central.

We also introduce the case function here. In the following illustration, you will see that we can set the value of a field by giving it a value of Label1 if Condition1 is true, Label2 if Condition2 is true, and so on:

SPL>| eval Value=case(Condition1, "Label1", Condition2, "Label2", 
          ConditionX, "LabelX")

Let us tweak the previous query to use case instead of if:

SPL> index=main http_uri="/destination/*/details" 
     | eval Region=case(match(http_uri, "NY|MIA|MCO"), 
           "East",  match(http_uri, "WAS|AK|LAX|PML"), "West", 
           match(http_uri, "HOU"), "Central") 
     | top 0 Region, http_uri | sort Region

The result will now properly classify the destinations based on the region:

Once you have done a subsearch, you may want to add the results of that subsearch to another set of results. If that is the case, and you are using historical data, use the syntax provided here to append the subsearch:

SPL> . . | append [subsearch]

You can also specify various timing options if you like.

You can also use the join command to join the results of the subsearch to your main search results, but you will likely often opt to use append instead, if you have historical data. Again, the basic syntax is simple:

SPL> . . | join [subsearch]

This will default to an inner join, which includes only events shared in common by the two searches. You can also specify an outer or left join. The outer join contains all the data, whereas the left join contains the data from events fulfilling the left search, as well as the events that are shared in common. You can also specify a field list for the join, instead of including all fields by default.

If you need to create a field based on the data present in an event, you can use the eval command to create a field variable and use if to check for that condition.

The if function takes the form of:

SPL> | eval value=if(condition, field1, field2)

Say you want to create two additional fields during search time to determine whether a destination is in the East Coast or not. Using the code presented next, if a destination URI has NY, MIA, or MCO in it, a new field called East will be added to each of those events. Otherwise, Splunk will add a new field called Others. Once that has been done, this code will list the newly-created Region field and http_uri for all events, and will sort by Region:

SPL> index=main http_uri="/destination/*/details" 
 | eval Region=if(match(http_uri, "NY|MIA|MCO"), "East", "Others") 
 | top 0 Region, http_uri | sort Region

A little regular expression has been used here to do a case statement between the airport codes: NY|MIA|MCO. If the http_uri includes NY, MIA, or MCO, then its Region field value will be East; otherwise it will be Others.

This should now return the data with the new fields:

You can optimize this query by using match instead of if and account for West and Central.

We also introduce the case function here. In the following illustration, you will see that we can set the value of a field by giving it a value of Label1 if Condition1 is true, Label2 if Condition2 is true, and so on:

SPL>| eval Value=case(Condition1, "Label1", Condition2, "Label2", 
          ConditionX, "LabelX")

Let us tweak the previous query to use case instead of if:

SPL> index=main http_uri="/destination/*/details" 
     | eval Region=case(match(http_uri, "NY|MIA|MCO"), 
           "East",  match(http_uri, "WAS|AK|LAX|PML"), "West", 
           match(http_uri, "HOU"), "Central") 
     | top 0 Region, http_uri | sort Region

The result will now properly classify the destinations based on the region:

You can also use the join command to join the results of the subsearch to your main search results, but you will likely often opt to use append instead, if you have historical data. Again, the basic syntax is simple:

SPL> . . | join [subsearch]

This will default to an inner join, which includes only events shared in common by the two searches. You can also specify an outer or left join. The outer join contains all the data, whereas the left join contains the data from events fulfilling the left search, as well as the events that are shared in common. You can also specify a field list for the join, instead of including all fields by default.

If you need to create a field based on the data present in an event, you can use the eval command to create a field variable and use if to check for that condition.

The if function takes the form of:

SPL> | eval value=if(condition, field1, field2)

Say you want to create two additional fields during search time to determine whether a destination is in the East Coast or not. Using the code presented next, if a destination URI has NY, MIA, or MCO in it, a new field called East will be added to each of those events. Otherwise, Splunk will add a new field called Others. Once that has been done, this code will list the newly-created Region field and http_uri for all events, and will sort by Region:

SPL> index=main http_uri="/destination/*/details" 
 | eval Region=if(match(http_uri, "NY|MIA|MCO"), "East", "Others") 
 | top 0 Region, http_uri | sort Region

A little regular expression has been used here to do a case statement between the airport codes: NY|MIA|MCO. If the http_uri includes NY, MIA, or MCO, then its Region field value will be East; otherwise it will be Others.

This should now return the data with the new fields:

You can optimize this query by using match instead of if and account for West and Central.

We also introduce the case function here. In the following illustration, you will see that we can set the value of a field by giving it a value of Label1 if Condition1 is true, Label2 if Condition2 is true, and so on:

SPL>| eval Value=case(Condition1, "Label1", Condition2, "Label2", 
          ConditionX, "LabelX")

Let us tweak the previous query to use case instead of if:

SPL> index=main http_uri="/destination/*/details" 
     | eval Region=case(match(http_uri, "NY|MIA|MCO"), 
           "East",  match(http_uri, "WAS|AK|LAX|PML"), "West", 
           match(http_uri, "HOU"), "Central") 
     | top 0 Region, http_uri | sort Region

The result will now properly classify the destinations based on the region:

If you need to create a field based on the data present in an event, you can use the eval command to create a field variable and use if to check for that condition.

The if function takes the form of:

SPL> | eval value=if(condition, field1, field2)

Say you want to create two additional fields during search time to determine whether a destination is in the East Coast or not. Using the code presented next, if a destination URI has NY, MIA, or MCO in it, a new field called East will be added to each of those events. Otherwise, Splunk will add a new field called Others. Once that has been done, this code will list the newly-created Region field and http_uri for all events, and will sort by Region:

SPL> index=main http_uri="/destination/*/details" 
 | eval Region=if(match(http_uri, "NY|MIA|MCO"), "East", "Others") 
 | top 0 Region, http_uri | sort Region

A little regular expression has been used here to do a case statement between the airport codes: NY|MIA|MCO. If the http_uri includes NY, MIA, or MCO, then its Region field value will be East; otherwise it will be Others.

This should now return the data with the new fields:

You can optimize this query by using match instead of if and account for West and Central.

We also introduce the case function here. In the following illustration, you will see that we can set the value of a field by giving it a value of Label1 if Condition1 is true, Label2 if Condition2 is true, and so on:

SPL>| eval Value=case(Condition1, "Label1", Condition2, "Label2", 
          ConditionX, "LabelX")

Let us tweak the previous query to use case instead of if:

SPL> index=main http_uri="/destination/*/details" 
     | eval Region=case(match(http_uri, "NY|MIA|MCO"), 
           "East",  match(http_uri, "WAS|AK|LAX|PML"), "West", 
           match(http_uri, "HOU"), "Central") 
     | top 0 Region, http_uri | sort Region

The result will now properly classify the destinations based on the region:

You can optimize this query by using match instead of if and account for West and Central.

We also introduce the case function here. In the following illustration, you will see that we can set the value of a field by giving it a value of Label1 if Condition1 is true, Label2 if Condition2 is true, and so on:

SPL>| eval Value=case(Condition1, "Label1", Condition2, "Label2", 
          ConditionX, "LabelX")

Let us tweak the previous query to use case instead of if:

SPL> index=main http_uri="/destination/*/details" 
     | eval Region=case(match(http_uri, "NY|MIA|MCO"), 
           "East",  match(http_uri, "WAS|AK|LAX|PML"), "West", 
           match(http_uri, "HOU"), "Central") 
     | top 0 Region, http_uri | sort Region

The result will now properly classify the destinations based on the region:

It is important to remember that data should be structured using clear key-value pairs. Doing so will help Splunk carry out automatic field-extraction in the way it is intended to and will do so in a faster and more efficient manner. Remember that we are talking about one of the most useful features of Splunk!

A model for doing this is shown here:

key1=value1, key2=value2, . . . etc. 

As you do this, remember that if it is important to include spaces in the values, in text fields, for example, you should surround the value with quotes:

key1="value1" or user="Matt Nguyen" 

Although you may find this method is lengthier and more verbose, it conveys a real advantage when it comes to field extraction, as it will allow it to occur automatically.

If possible, you should avoid readers having to create lookups to understand the meaning in your data. One way to do this is to use tools that can easily convert binary data to ASCII or text data, and use the same format throughout the file. If, for some reason, you have to use different formats, simply create separate files.

There are many reasons why you should use timestamps for all events. Above all, their use helps determine the sequence in which events occurred, so is invaluable for problem-solving, data analytics, and other uses.

Also remember the following:

This is an obvious rule and is familiar to anyone who has used or studied transactional data, but nonetheless we include it here, just because it is so important.

It is very hard for Splunk to search binary data easily or meaningfully. Therefore, wherever possible, create logs that are in text format. If, for some reason, your data has to be in binary format, be sure and include metadata that is in text format, so that it can be easily searched.

It is important to consider the usefulness of your log format. When setting up logs, include formats that are easy for developers to understand. One especially useful format is JavaScript Object Notation (JSON). Extensible Markup Language or XML can also be used, but JSON is somewhat cleaner to read.

Using the spath command, structured data can now be parsed in Splunk by many programming languages through the browser alone, without even using a server! Using the structured key-value pairs of JSON, you can easily use data with a built-in hierarchy, such as this email data, where recipient has a sub-level:

{ "sender" : "george" "recipient": { "firstname" : "michael", "firstname" : "shannon", "firstname" : "chloe" } subject:"Building my logs" } 

As you look at your data, consider what you think might come in handy for answering business questions at some point. What would be useful for decision-making? What would be useful for problem-solving? What data might you want to use someday for a chart or graph? Be sure that you log in any information you think you might need in the future.

Be sure your categories convey meaning. Especially important are labels such as INFO, WARN, ERROR, and DEBUG, which clearly flag events that you want to pay attention to.

Be sure to include information that conveys where the event came from, be it a file, a function, or a class.

In general, it is good to minimize the number of events that include many lines. Sometimes, you will have to leave them as multi-line, but this can slow down indexing and search speeds. Other times, you may want to turn multi-line events into shorter events.

It is important to remember that data should be structured using clear key-value pairs. Doing so will help Splunk carry out automatic field-extraction in the way it is intended to and will do so in a faster and more efficient manner. Remember that we are talking about one of the most useful features of Splunk!

A model for doing this is shown here:

key1=value1, key2=value2, . . . etc. 

As you do this, remember that if it is important to include spaces in the values, in text fields, for example, you should surround the value with quotes:

key1="value1" or user="Matt Nguyen" 

Although you may find this method is lengthier and more verbose, it conveys a real advantage when it comes to field extraction, as it will allow it to occur automatically.

If possible, you should avoid readers having to create lookups to understand the meaning in your data. One way to do this is to use tools that can easily convert binary data to ASCII or text data, and use the same format throughout the file. If, for some reason, you have to use different formats, simply create separate files.

There are many reasons why you should use timestamps for all events. Above all, their use helps determine the sequence in which events occurred, so is invaluable for problem-solving, data analytics, and other uses.

Also remember the following:

This is an obvious rule and is familiar to anyone who has used or studied transactional data, but nonetheless we include it here, just because it is so important.

It is very hard for Splunk to search binary data easily or meaningfully. Therefore, wherever possible, create logs that are in text format. If, for some reason, your data has to be in binary format, be sure and include metadata that is in text format, so that it can be easily searched.

It is important to consider the usefulness of your log format. When setting up logs, include formats that are easy for developers to understand. One especially useful format is JavaScript Object Notation (JSON). Extensible Markup Language or XML can also be used, but JSON is somewhat cleaner to read.

Using the spath command, structured data can now be parsed in Splunk by many programming languages through the browser alone, without even using a server! Using the structured key-value pairs of JSON, you can easily use data with a built-in hierarchy, such as this email data, where recipient has a sub-level:

{ "sender" : "george" "recipient": { "firstname" : "michael", "firstname" : "shannon", "firstname" : "chloe" } subject:"Building my logs" } 

As you look at your data, consider what you think might come in handy for answering business questions at some point. What would be useful for decision-making? What would be useful for problem-solving? What data might you want to use someday for a chart or graph? Be sure that you log in any information you think you might need in the future.

Be sure your categories convey meaning. Especially important are labels such as INFO, WARN, ERROR, and DEBUG, which clearly flag events that you want to pay attention to.

Be sure to include information that conveys where the event came from, be it a file, a function, or a class.

In general, it is good to minimize the number of events that include many lines. Sometimes, you will have to leave them as multi-line, but this can slow down indexing and search speeds. Other times, you may want to turn multi-line events into shorter events.

If possible, you should avoid readers having to create lookups to understand the meaning in your data. One way to do this is to use tools that can easily convert binary data to ASCII or text data, and use the same format throughout the file. If, for some reason, you have to use different formats, simply create separate files.

There are many reasons why you should use timestamps for all events. Above all, their use helps determine the sequence in which events occurred, so is invaluable for problem-solving, data analytics, and other uses.

Also remember the following:

This is an obvious rule and is familiar to anyone who has used or studied transactional data, but nonetheless we include it here, just because it is so important.

It is very hard for Splunk to search binary data easily or meaningfully. Therefore, wherever possible, create logs that are in text format. If, for some reason, your data has to be in binary format, be sure and include metadata that is in text format, so that it can be easily searched.

It is important to consider the usefulness of your log format. When setting up logs, include formats that are easy for developers to understand. One especially useful format is JavaScript Object Notation (JSON). Extensible Markup Language or XML can also be used, but JSON is somewhat cleaner to read.

Using the spath command, structured data can now be parsed in Splunk by many programming languages through the browser alone, without even using a server! Using the structured key-value pairs of JSON, you can easily use data with a built-in hierarchy, such as this email data, where recipient has a sub-level:

{ "sender" : "george" "recipient": { "firstname" : "michael", "firstname" : "shannon", "firstname" : "chloe" } subject:"Building my logs" } 

As you look at your data, consider what you think might come in handy for answering business questions at some point. What would be useful for decision-making? What would be useful for problem-solving? What data might you want to use someday for a chart or graph? Be sure that you log in any information you think you might need in the future.

Be sure your categories convey meaning. Especially important are labels such as INFO, WARN, ERROR, and DEBUG, which clearly flag events that you want to pay attention to.

Be sure to include information that conveys where the event came from, be it a file, a function, or a class.

In general, it is good to minimize the number of events that include many lines. Sometimes, you will have to leave them as multi-line, but this can slow down indexing and search speeds. Other times, you may want to turn multi-line events into shorter events.

There are many reasons why you should use timestamps for all events. Above all, their use helps determine the sequence in which events occurred, so is invaluable for problem-solving, data analytics, and other uses.

Also remember the following:

This is an obvious rule and is familiar to anyone who has used or studied transactional data, but nonetheless we include it here, just because it is so important.

It is very hard for Splunk to search binary data easily or meaningfully. Therefore, wherever possible, create logs that are in text format. If, for some reason, your data has to be in binary format, be sure and include metadata that is in text format, so that it can be easily searched.

It is important to consider the usefulness of your log format. When setting up logs, include formats that are easy for developers to understand. One especially useful format is JavaScript Object Notation (JSON). Extensible Markup Language or XML can also be used, but JSON is somewhat cleaner to read.

Using the spath command, structured data can now be parsed in Splunk by many programming languages through the browser alone, without even using a server! Using the structured key-value pairs of JSON, you can easily use data with a built-in hierarchy, such as this email data, where recipient has a sub-level:

{ "sender" : "george" "recipient": { "firstname" : "michael", "firstname" : "shannon", "firstname" : "chloe" } subject:"Building my logs" } 

As you look at your data, consider what you think might come in handy for answering business questions at some point. What would be useful for decision-making? What would be useful for problem-solving? What data might you want to use someday for a chart or graph? Be sure that you log in any information you think you might need in the future.

Be sure your categories convey meaning. Especially important are labels such as INFO, WARN, ERROR, and DEBUG, which clearly flag events that you want to pay attention to.

Be sure to include information that conveys where the event came from, be it a file, a function, or a class.

In general, it is good to minimize the number of events that include many lines. Sometimes, you will have to leave them as multi-line, but this can slow down indexing and search speeds. Other times, you may want to turn multi-line events into shorter events.

This is an obvious rule and is familiar to anyone who has used or studied transactional data, but nonetheless we include it here, just because it is so important.

It is very hard for Splunk to search binary data easily or meaningfully. Therefore, wherever possible, create logs that are in text format. If, for some reason, your data has to be in binary format, be sure and include metadata that is in text format, so that it can be easily searched.

It is important to consider the usefulness of your log format. When setting up logs, include formats that are easy for developers to understand. One especially useful format is JavaScript Object Notation (JSON). Extensible Markup Language or XML can also be used, but JSON is somewhat cleaner to read.

Using the spath command, structured data can now be parsed in Splunk by many programming languages through the browser alone, without even using a server! Using the structured key-value pairs of JSON, you can easily use data with a built-in hierarchy, such as this email data, where recipient has a sub-level:

{ "sender" : "george" "recipient": { "firstname" : "michael", "firstname" : "shannon", "firstname" : "chloe" } subject:"Building my logs" } 

As you look at your data, consider what you think might come in handy for answering business questions at some point. What would be useful for decision-making? What would be useful for problem-solving? What data might you want to use someday for a chart or graph? Be sure that you log in any information you think you might need in the future.

Be sure your categories convey meaning. Especially important are labels such as INFO, WARN, ERROR, and DEBUG, which clearly flag events that you want to pay attention to.

Be sure to include information that conveys where the event came from, be it a file, a function, or a class.

In general, it is good to minimize the number of events that include many lines. Sometimes, you will have to leave them as multi-line, but this can slow down indexing and search speeds. Other times, you may want to turn multi-line events into shorter events.

It is very hard for Splunk to search binary data easily or meaningfully. Therefore, wherever possible, create logs that are in text format. If, for some reason, your data has to be in binary format, be sure and include metadata that is in text format, so that it can be easily searched.

It is important to consider the usefulness of your log format. When setting up logs, include formats that are easy for developers to understand. One especially useful format is JavaScript Object Notation (JSON). Extensible Markup Language or XML can also be used, but JSON is somewhat cleaner to read.

Using the spath command, structured data can now be parsed in Splunk by many programming languages through the browser alone, without even using a server! Using the structured key-value pairs of JSON, you can easily use data with a built-in hierarchy, such as this email data, where recipient has a sub-level:

{ "sender" : "george" "recipient": { "firstname" : "michael", "firstname" : "shannon", "firstname" : "chloe" } subject:"Building my logs" } 

As you look at your data, consider what you think might come in handy for answering business questions at some point. What would be useful for decision-making? What would be useful for problem-solving? What data might you want to use someday for a chart or graph? Be sure that you log in any information you think you might need in the future.

Be sure your categories convey meaning. Especially important are labels such as INFO, WARN, ERROR, and DEBUG, which clearly flag events that you want to pay attention to.

Be sure to include information that conveys where the event came from, be it a file, a function, or a class.

In general, it is good to minimize the number of events that include many lines. Sometimes, you will have to leave them as multi-line, but this can slow down indexing and search speeds. Other times, you may want to turn multi-line events into shorter events.

It is important to consider the usefulness of your log format. When setting up logs, include formats that are easy for developers to understand. One especially useful format is JavaScript Object Notation (JSON). Extensible Markup Language or XML can also be used, but JSON is somewhat cleaner to read.

Using the spath command, structured data can now be parsed in Splunk by many programming languages through the browser alone, without even using a server! Using the structured key-value pairs of JSON, you can easily use data with a built-in hierarchy, such as this email data, where recipient has a sub-level:

{ "sender" : "george" "recipient": { "firstname" : "michael", "firstname" : "shannon", "firstname" : "chloe" } subject:"Building my logs" } 

As you look at your data, consider what you think might come in handy for answering business questions at some point. What would be useful for decision-making? What would be useful for problem-solving? What data might you want to use someday for a chart or graph? Be sure that you log in any information you think you might need in the future.

Be sure your categories convey meaning. Especially important are labels such as INFO, WARN, ERROR, and DEBUG, which clearly flag events that you want to pay attention to.

Be sure to include information that conveys where the event came from, be it a file, a function, or a class.

In general, it is good to minimize the number of events that include many lines. Sometimes, you will have to leave them as multi-line, but this can slow down indexing and search speeds. Other times, you may want to turn multi-line events into shorter events.

As you look at your data, consider what you think might come in handy for answering business questions at some point. What would be useful for decision-making? What would be useful for problem-solving? What data might you want to use someday for a chart or graph? Be sure that you log in any information you think you might need in the future.

Be sure your categories convey meaning. Especially important are labels such as INFO, WARN, ERROR, and DEBUG, which clearly flag events that you want to pay attention to.

Be sure to include information that conveys where the event came from, be it a file, a function, or a class.

In general, it is good to minimize the number of events that include many lines. Sometimes, you will have to leave them as multi-line, but this can slow down indexing and search speeds. Other times, you may want to turn multi-line events into shorter events.

Be sure your categories convey meaning. Especially important are labels such as INFO, WARN, ERROR, and DEBUG, which clearly flag events that you want to pay attention to.

Be sure to include information that conveys where the event came from, be it a file, a function, or a class.

In general, it is good to minimize the number of events that include many lines. Sometimes, you will have to leave them as multi-line, but this can slow down indexing and search speeds. Other times, you may want to turn multi-line events into shorter events.

Be sure to include information that conveys where the event came from, be it a file, a function, or a class.

In general, it is good to minimize the number of events that include many lines. Sometimes, you will have to leave them as multi-line, but this can slow down indexing and search speeds. Other times, you may want to turn multi-line events into shorter events.

In general, it is good to minimize the number of events that include many lines. Sometimes, you will have to leave them as multi-line, but this can slow down indexing and search speeds. Other times, you may want to turn multi-line events into shorter events.