String Search on Log Files

The String Search - LOG File tool enables you to fine-tune your monitoring on of LOG files.

Monitoring Studio Express offers a powerful string search capability. You can search for strings that must "be found" or "not be found" in a given source.

•	A must be found string search looks through the specified source and triggers an alert if the specified string is not found.

•	A must not be found string search triggers an alert when the specified string is found.

You can set alert thresholds for the string searches, and make your monitoring more proactive and powerful.

The string search tool is integrated within the LOG File Analysis tool so this enables you to add the string search during creation of a LOG file instance itself. You can also add a string search at any time later.

An instance can have several string searches running on it and alert thresholds can be set for all the string search instances. The string search runs differently on LOG files – where it searches only amongst the new lines appended since the last poll; whereas for flat sources, the entire information source is searched (as per the indications specified: what; where etc).

Specify whether the parsing should be done on the RSM or, on the managed element.
When the parsing is done on the RSM, the impact it has on the network traffic will depend on file size/growth of file. When the parsing is done on the managed element, the amount of CPU usage on the managed element will depend on the file size and growth of file.

3.	Specify what the source must contain or must not contain (a combination of two regular expressions)

4.	Indicate the string’s location i.e. where to look for this string (anywhere in the line, column number, and which lines: all lines, or specific lines)

On creation of the string search instance, Monitoring Studio Express starts the search from the end of the file. Then as new lines are appended, a maximum of 10MB of file content is parsed at each polling, in order prevent network congestion and CPU overuse.

1.	Two files: sen_ms_excerpt.exe and sen_ms_nawk.exe are copied from the RSM to the remote element and placed on %SystemRoot%\SEN_MS\.

2.	The sen_ms_excerpt.exe file is used to extract the file content up to a maximum of 10MB at each polling.

3.	The sen_ms_nawk.exe file performs the parsing on the extracted content on the remote element, and only the last 1000 bytes of the parsed result is temporarily stored in a file on %SystemRoot%\SEN_MS\

4.	This output is then copied to the RSM at: %RSM_HOME%\RSMxx\server\rsm\tmp\deploy\ and the file is deleted from the remote element.

5.	The output is then displayed on the Portal under the parameter: MatchingLine; and it is deleted from the RSM.

1.	Just one file: sen_ms_excerpt.exe is copied from the RSM to the remote element and placed at: %SystemRoot%\SEN_MS\.

2.	The sen_ms_excerpt.exe file is used to extract the file content up to a maximum of 10MB at each polling.

3.	The extracted file content is transferred to the RSM where the sen_ms_nawk.exe file performs the parsing.

4.	Only the last 1000 bytes are displayed in the parameter: Matching Lines.

1.	The commands "tail" and "head" are used to extract the file content up to a maximum of 10MB at each polling.

2.	The command "awk" or "nawk" are used parse the extracted content on the remote element, and only the last 1000 bytes of the parsed result is returned.

3.	The returned output is then displayed on the Portal under the parameter Matching Lines.

1.	The commands "tail" and "head" are used to extract the file content up to a maximum of 10MB at each polling.

2.	The extracted file content is transferred to the RSM where the sen_ms_nawk.exe file performs the parsing on the extracted content.

3.	Only the last 1000 bytes are displayed in the parameter: Matching Lines.

(HB) = "Higher is Better" and (LB) = "Lower is Better". HB and LB parameters will always display the same value since, basically, both represent the same value. The purpose of having two parameters for the same value is to be able to set different alert thresholds depending on the nature of the monitored object.
For instance, an alert can be set to be triggered on the HB parameter when the value dips too low (it breaches the lower threshold of the range) and an alert can be set on the LB parameter to go off when the value rises too high. The setting of alerts is flexible and can be done on either of the two parameters, on both, or on neither; it depends entirely on nature of the monitored object and the user's specific needs.