Hi Aengus
I was and remain using the Auto Log Format that is set in the original
CFG file that comes with Analog.
Being a low level user this was the easy option, however following this
problem I have been through the CFG file and substituted the LOGFORMAT
for all of the options that are listed within the CFG file in turn and
the result is always the same and I got an identical type of failure
report.
I eventually set the Debug to C and reran the program in AUTO FORMAT
and received the indicator * that the end hyphen was the corrupt
element in the line.
Having discovered this, following my own visual comparison with good
and bad files I have pursued the provider regarding the added character
in the log file as this appeared out of the blue following more than 4
years of normal Combined Log Format files being provided.
As I posted earlier I have tried stripping out the hyphen with little
success and considering the number and size of the daily log files
(usually between 1mb and 2.5mb in size) this is a rather tedious task
with several sites to keep under control, far easier to set a wild card
file name and drop the folder into Analog and click go! Thats what
makes Analog so good, its quick and easy!
What I am looking to achieve is a set of readable log files, primarily
I have tried to establish if the format is different and either corrupt
Combined format or a valid other standard format which can be
accommodated by applying a new LOGFORMAT in Analog.
As the change has taken place at the providers end I am pressing them
to tell me if they have a problem or have changed the format, that is
an issue that needs to be answered as it is a service problem that
probably affects many other users. Public service responsibility over,
I am disappointed that I cannot get my own site and other managed sites
logs analyzed due to such a problem, particularly with a major league
player such as BT as the provider.
To date I have not received an answer!
Given that I may not get a resolve with BT, I still need to consider
the analysis of these corrupt files and those I may continue to receive
until I move all my accounts to an alternative provide!
So to this end I have been considering if there was a way of adapting
or creating a LOGFORMAT that will accommodate this element, such as
adding an ignore instruction, although an amateur attempt at this did
not provide the answer!
If you can offer a way to alter or create a workable Format that will
handle this problem I would be interested to try it
Regards
David
On 3 Jan 2006, at 21:39, Aengus wrote:
On Tuesday, January 03, 2006 4:04 PM [EDT],
David Batten <[EMAIL PROTECTED]> wrote:
Having used Analog for the past 5 years wit a BT Connect account(s)
with excellent results, a problem has occurred that results in a
failure to analyze the latest log files I am receiving from the BT
server (Unix / Solaris) outputs.
My question is, am I and is Analog correct in the belief that the log
files are incorrect and corrupt or is there a way of analyzing these
files.
A "corrupt" logfile is one that doesn't match the LOGFORMAT that
Analog is
currently using - that doesn't mean that Analog can't read it, or
interpret
it, it just means that the logfile doesn't match whatever format you
told
Analog to use. It might not match because the lofile really is
corrupt, and
total garbage, but it might also be because Analog finds data that it
doesn't expect to find in a specific field in the logfile.
Information below is sampled from the report and some log file
extracts.
......................................................................
..
...................................................................
analog: Warning L: Large number of corrupt lines in logfile
20051109.log: turn debugging on or try different LOGFORMAT
So, what different LOGFORMATs did you try? Better yet, what LOGFORMAT
were
you using to start with?
......................................................................
..
....................................................................
The following Debug+C reports for all corrupt lines and the * is under
the final ( " - ) hyphen at the end of the line
C: 62.253.96.44 - - [09/Nov/2005:23:38:41 +0000] "GET
/hooklinks/pike/articles/artindex.html HTTP/1.1" 200 4819 "FROM
http://www.hooklinks.co.uk/pike/navigation2/homenav2.html";
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR
1.1.4322; Hotbar
4.6.1)" -
Previously received log file extract that was successfully analysed
ok.No '-' at the end of the line.
62.252.192.10 - - [01/Jan/2005:13:39:20 +0000] "GET
/hooklinks/pike/gallery/largeimages/paulmusialek1.jpg HTTP/1.1" 200
31046 "FROM
http://www.hooklinks.co.uk/pike/gallery/pics/paulmus1.html";
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; FunWebProducts;
AskBar 3.00)"
If you aren't specifying a LOGFORMAT already, then you can find the
Combined
format in the Analog documentation, and modify it to take account of
the new
field. (I'm sort of assuming that you already have a LOGFORMAT to fix
that
FROM entry in the Referrer field - Analog won't complain about it, but
the
links in your Referrer report won't work properly if you don't already
have
a custom LOGFORMAT).
http://analog.cx/docs/logfmt.html
Aengus
+----------------------------------------------------------------------
--
| TO UNSUBSCRIBE from this list:
| http://lists.meer.net/mailman/listinfo/analog-help
|
| Analog Documentation: http://analog.cx/docs/Readme.html
| List archives: http://www.analog.cx/docs/mailing.html#listarchives
| Usenet version: news://news.gmane.org/gmane.comp.web.analog.general
+----------------------------------------------------------------------
--
+------------------------------------------------------------------------
| TO UNSUBSCRIBE from this list:
| http://lists.meer.net/mailman/listinfo/analog-help
|
| Analog Documentation: http://analog.cx/docs/Readme.html
| List archives: http://www.analog.cx/docs/mailing.html#listarchives
| Usenet version: news://news.gmane.org/gmane.comp.web.analog.general
+------------------------------------------------------------------------
