topic Re: monitoring text based log file on windows in Getting Data In

monitoring text based log file on windows

Conradj — Wed, 16 May 2012 09:31:41 GMT

Hi,

I have following input.conf in an app on my deployment server

[Monitor://%product_home%\logs\stdout.log]
disabled=0
followtail=0
sourcetype=product_stdout
index=product_logs

The app deploys to the target server fine, and i also have a forwarding app which also deploys fine (I am also monitoring windows event logs, and these appear in the index no problem, so I know both this and the forwarding app work correctly)

However, my stdout.log doesn't seem to be making it into the product_logs index (the index does exist)

I have seen mention of accessing

https://localhost:8089/services/admin/inputStatus/TailingProcessor%3AFileStatus

on the target server, but I get prompted with a login box with no idea what credentials to enter in. likewise if i run the equivalent request from the command line, i get prompted to enter a username and password. after it fails i get a 401 unauthorized error.

I have tried various combinations ...

[Monitor://$product_home\logs\stdout.log]
[Monitor://c:\really long path\in here\logs\stdout.log]
[Monitor://%product_home%\logs\stdout.log]

To no avail.

stdout.log does exist and has content, there are no special permissions on the file and the Splunk agent is running as local system

%PRODUCT_HOME% is defined on the target server as a system environment variable, and is in use by other programs, so I know the path is valid.

The splunkd.log doesn't appear to have anything useful to tell me other than the app deployed ok.

I am sure this must be something incredibly simple that I am missing, but I can't see it for the conf.

Halp?

Re: monitoring text based log file on windows

Ayn — Wed, 16 May 2012 12:14:16 GMT

If you didn't change the default credentials to anything else, the ones you should use are "admin" as username and "changeme" as password.

Re: monitoring text based log file on windows

lguinn2 — Wed, 16 May 2012 18:14:46 GMT

Some ideas:

Search for something that you know is in the data over all time. Perhaps there is a timestamp problem, and the data is really in there, but not at the time you expect.
Search index=* for that data. It shouldn't have happened, but what the heck.
Is the data recent? If it is older, or has widely varying timestamps, you may need to set some rules in props.conf. Put them in props.conf on the indexer if you are using the Universal Forwarder. Look at the settings for MAX_DAYS_AGO, MAX_DAYS_HENCE, MAX_DIFF_SECS_AGO and MAX_DIFF_SECS_HENCE in props.conf