When downloading, it appears in host\date\audit\informixauditlogs

To answer your other question, yes, we have them turned up and tuned to what we 
think works best with our Uplinx deployment.

We’ve been running fine for about a year now. All other nodes are less than 30% 
utilization. Something happened that made this host go nuts some time before 
5pm. And then stop. Great.

The host in question is a subscriber, there should not be that many db changes 
initiated from this guy.

---
Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1
519-824-4120 Ext. 56354 | [email protected]<mailto:[email protected]>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, 
Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

From: [email protected] [mailto:[email protected]] On Behalf Of Brian Meade
Sent: Thursday, February 1, 2018 3:46 PM
To: Lelio Fulgenzi <[email protected]>
Cc: voyp list, cisco-voip ([email protected]) 
<[email protected]>
Subject: Re: [cisco-voip] anyone see audit log files fill up with a bunch of 
dbipphone entries?

Which audit log was it in?

Only bugs I'm seeing are these 2:
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCtx70811
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCty20409


On Thu, Feb 1, 2018 at 3:24 PM, Lelio Fulgenzi 
<[email protected]<mailto:[email protected]>> wrote:

We ran into a condition where the audit log files on one of our nodes was 
filling up the log partition. Built in systems were deleting files 
appropriately, but the disk would just fill up again. Alerts started around 
5:30 yesterday but I suspect the issue started before that since it needed time 
to go from about 30% full (the norm) to 95% full. Files would be purged to 
about 80% full and need about 45 minutes to fill up.

Turns out the logs were full of entries like this:

ONLN|2018-02-01 
09:11:45.000|nodeXYZ|28945|nodeXYZ_ccm9_1_2_11900_12|dbuser|0:RDRW:ccm9_1_2_11900_12:590:7342272:2244099
ONLN|2018-02-01 
09:11:45.000|nodeXYZ|28945|nodeXYZ_ccm9_1_2_11900_12|dbuser|0:RDRW:ccm9_1_2_11900_12:590:7342272:2244353
ONLN|2018-02-01 
09:11:45.000|nodeXYZ|28945|nodeXYZ_ccm9_1_2_11900_12|dbuser|0:RDRW:ccm9_1_2_11900_12:590:7342272:2244354
ONLN|2018-02-01 
09:11:45.000|nodeXYZ|28945|nodeXYZ_ccm9_1_2_11900_12|dbuser|0:RDRW:ccm9_1_2_11900_12:590:7342272:2244355
ONLN|2018-02-01 
09:11:45.000|nodeXYZ|28945|nodeXYZ_ccm9_1_2_11900_12|dbuser|0:RDRW:ccm9_1_2_11900_12:590:7342272:2244609

Anyone seen anything like this before?

It took a while to convince TAC that I wasn't looking to delete the files as my 
primary focus, but what was causing the files to be created. By that time, it 
stopped. Magically. At around 10:30.

We're collecting logs, but just thought I'd ask.


---
Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1
519-824-4120 Ext. 56354 | 
[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs><http://www.uoguelph.ca/ccs> | 
@UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]


_______________________________________________
cisco-voip mailing list
[email protected]<mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip

Reply via email to