Enable log rules to log data that is not currently being logged. Enabling logging functionality. In addition, the database stores statistical data for use in third-party reporting tools such that an InputAccel Server would not be required to load batches to retrieve the data for the reporting tools.
Log rules define the types of logs created, where they are written, and how they are formatted. When an event occurs that matches a log rule, the rules are used to prepare the log and send it to the defined sink. The sink then prepares the data and sends it to its destination. If the event does not match a log rule, the log is ignored. Not all aspects of System log rules can be changed, although you can make a copy of a system log rule and modify the copy. All logs created can be viewed through the Logs pane in Captiva Administrator.
Jun 01 11:23:14 AgentDevice=WindowsLog AgentLogFile=Security Source=Microsoft-Windows-Security-Auditing ….. EventID=4776 EventIDCode=4776 EventType=16 EventCategory=14336 RecordNumber=312593 TimeGenerated=1473965593963 TimeWritten=1473965593963
So the syslog timestamp is showing Jun 01, but the Epoch time log is showing Thursday, September 15, 2016 6:53:13.963 PM GMT. So if I understand this correctly, the syslog timestamp is stamped by the system that is forwarding the log to the event collector. The event collector takes the log and doesn’t modify the raw, but puts the log in the system with a start time and a storage time, but those times are not stamped on the actual log itself. So the three times we see in the raw log (syslog timestamp, timegenerated, and timewritten) are completely generated and stamped by the system that the event happened on. Correct?
Just asking this as a side question in case anyone has seen this before, do you know why this might be happening? Is it because the system was shutdown before being able to sync the logs or is the system not able to see that it sent these logs before so it is trying to catch up and it is sending old logs?
Event ID 6000 — Private Channel Configuration
Updated: August 5, 2011
Applies To: Windows Server 2008 R2
Each event channel has configuration settings, such as the maximum size of the log and the custom security descriptor specified by the administrator for the log. The events that refer to the maximum size of the log serve as indicators for how the service dealt with the log when it reached its maximum size. The operation of the service is not affected, but an event can indicate to the administrator the configuration setting that might require a change.
Events that report problems with an event log security descriptor are more significant. They can indicate that the desired security settings are not be set correctly and the channel is more or less accessible than intended by the administrator.
Event Details
| Product: | Windows Operating System |
| ID: | 6000 |
| Source: | Microsoft-Windows-Eventlog |
| Version: | 6.1 |
| Symbolic Name: | EVENT_LOG_FULL |
| Message: | The %1 log file is full. |
Resolve
Update settings to handle the log full condition
Event 6000 indicates that the maximum capacity for an event log has been reached. The configuration settings for an event log include a setting that indicates how the Event Log service automatically handles the full log. This configuration setting can be found by right-clicking the log in the Event Viewer and selecting Properties.
1. If the property is set to Overwrite events as required (retention is set to false on the command line), the log automatically recovers from the log full condition by overwriting oldest events with new events.
2. If the log is set to Archive the log when full, do not overwrite events (retention is set to true, autoBackup is set to true from the command line), the log automatically recovers from the log full condition by copying the full log into a new file with a name based on the date that the copy was made, and a new empty log file is started.
3. If the log is set to Do not overwrite events (retention is set to true, autoBackup is set to false from the command line), the log must be manually cleared. This can be done by right-clicking the log entry in the Event Viewer and selecting Clear Log , or by running the following command from an elevated command prompt with logName replaced with the name specified in the event 6000:
wevtutil cl logName
Verify
To verify that the log full condition (event 6000) is cleared, use the Event Viewer to read the System log of the local computer and look for the latest event 6000. This event must be followed by events 105 or 104 to indicate that the condition is cleared and that the log is accepting events.
In order to verify that the bad SDDL condition (event 21) is cleared, use the Event Viewer to read the System log of the local computer after the computer has been restarted and verify that event 21 did not appear in the System log after the system was restarted.
Related Management Information
Event ID 1133 — IIS W3SVC Logging
Updated: March 24, 2009
Applies To: Windows Server 2008 R2
An Internet Information Services (IIS) Web server can be configured for Site, Central Binary, or Central W3C logging. In Central W3C logging, all client requests for all sites are logged to a single log file in W3C centralized format on the server. Central Binary logging also logs all sites centrally to a single file, but does so in centralized binary format. In Site logging, all client requests are logged at the site level, not centrally at the server level. These logging types depend on the World Wide Web Publishing Service for their configuration.
Event Details
| Product: | Internet Information Services |
| ID: | 1133 |
| Source: | Microsoft-Windows-IIS-W3SVC |
| Version: | 7.5 |
| Symbolic Name: | W3SVC_WS03_EVENT_CENTRALIZED_AND_W3C_LOGGING_ENABLED |
| Message: | The World Wide Web Publishing Service (WWW Service) has both centralized binary logging and centralized W3C logging enabled. Only one type of logging can be enabled at a time, so the system will default to central W3C logging. |
Resolve
Configure the central logging format
Both centralized binary logging and centralized W3C logging are enabled. Because only one type of logging can be enabled at a time, the system has defaulted to central W3C logging. Use the following procedure to configure either W3C or binary logging.
Note: If you want to use binary logging, you must perform this procedure.
To perform this procedure, you must have membership in Administrators, or you must have been delegated the appropriate authority.
To configure centralized logging by using IIS Manager:
Verify
To verify that logging is working, follow these steps:
To perform these procedures, you must have membership in Administrators, or you must have been delegated the appropriate authority.
Note the Site ID and Test Browse the site
To note the Site ID and Test Browse the site:
Check the log file directory
To check the log file directory:
Note: There might be a short delay between the time of the test browse and the time that the test browse is logged.
Related Management Information
Internet Information Services (IIS) 7.5
We are installing the Datapower agent and other agents (IIB,MQ) on an IIB Server.
While configuring the IBM Datapower agent, the Datapower syslog is merged with IIB syslog.
Our Admins want to separate the Datapower Agent syslog from IIB syslogs.
We need help to configure Datapower agent and syslog daemon to receive the
data power syslogs at alternative path location for Datapower agent.
***
This link refers to 1) Red Hat and 2) Suse Linux
http://www.ibm.com/support/knowledgecenter/en/SS3JRN_7.2.0/com.ibm.itcama.doc_7.1/datapower/fac_config_enable_syslog.html
I but could not find any information on AIX.
In the section **Enabling syslog** it states:
If you want the DataPower® agent to monitor the system logs of the DataPower Appliance, in addition to setting up the syslog on the appliance, you must also enable syslog on the computer that hosts the
DataPower agent.
**Before you begin**
If the DataPower agent is installed on a Windows operating system, you must first install a system log daemon on the computer to collect the system logs. Alternatively, you can save the system log files on a
shared disk and ensure that the agent has the authority to read the system log files on that disk.
**Procedure**
To enable syslog, depending on the operating system that hosts the DataPower agent, complete one of the following procedures:
**On Red Hat Enterprise Linux 6, to open the syslog.conf file, run the vi /etc/syslog.conf command.**
a. Append the Syslog_fac.* /var/log/filename command to the end of the syslog.conf file and save it. Syslog_fac is the syslog facility and file name is the name of the file where you save the syslog.
b. To open the syslog.conf file, run the vi /etc/syslog.conf command.
c. Change the value of the SYSLOGD_OPTIONS parameter to the following value: SYSLOGD_OPTIONS = “-m 0 -r”
Note: Depending on the Linux distribution, this variable might also be named SYSLOGD_PARAMS.
d. To restart the syslog server, run the service syslog restart command.
**On SUSE Linux Enterprise Server 11, to enable syslog-ng, complete the following steps:**
a. To open the syslog file, run the vi /etc/sysconfig/syslog command.
b. Verify that the value of the SYSLOG_DAEMON parameter is syslog-ng.
c. In the syslog-ng.conf file, append the following line to the definition of the src source:
tcp(ip(“ip_address”) port(port_number) keep-alive(yes));
Where ip_address is the IP address of the computer that hosts the DataPower agent and port_number is the port number that is used for receiving syslog-ng messages.
d. To filter messages from the DataPower appliances, in the syslog-ng.conf file, create a filter. For example,
the filter f_dp {level(debug..emerg) and facility(user);};
filter statement defines a filter that accepts messages from the debug level to the emergency level that specify the user as the syslog facility.
e. In the syslog-ng.conf file, use a destination statement to define where the messages are written as shown in the following example:
destination dplog {file(“/var/log/dpsyslog.log”);};
This destination statement specifies that messages are written to the
dpsyslog.log file in the /var/log directory.
f. In the syslog-ng.conf file, use a log statement to connect sources and destinations. For example,
the log {source(src);filter(f_dp);destination(dplog);};
log statement connects the src source and the dplog destination.
g. Save the syslog-ng.conf file.
h. To restart the syslog server, run the /etc/init.d/syslog restart command.
***
In the Configure Log Target pane it shows Syslog-ng (deprecated)
Please confirm that Syslog-ng will work on AIX.
Event ID 27 — Channel Initialization
Updated: August 5, 2011
Applies To: Windows Server 2008 R2
Event logs are normally initialized when the Event Log service starts. This initialization can also happen during installation of a component that creates a new log. When the initialization fails, the log is not available to receive events and the diagnostic and troubleshooting capabilities of administrators, support personnel, developers, and automated utilities can be compromised.
The application-defined logs are specific to the event provider that created them and will only affect events published by that provider. The operations that remain for the Event Log service and all other event providers are not affected when there is a problem with one of the event logs being initialized.
Event Details
| Product: | Windows Operating System |
| ID: | 27 |
| Source: | Microsoft-Windows-Eventlog |
| Version: | 6.1 |
| Symbolic Name: | INIT_CHANNEL_LOGFILE_WARNING |
| Message: | The event logging service encountered an error (res=%1) while opening log file for channel %2. Trying again using default log file path %3. |
Resolve
Reconfigure the location to the log file
To change the path to a log file, open Event Viewer, right-click on the log to update, and select Properties. Change the value of the Log path field and click Apply.
Verify
Use the Event Viewer to read the affected log on the local computer after the computer has been restarted, and verify that events 20, 23, 25, 26, or 40 did not appear in the event log after the system was restarted.
Related Management Information
If we are use log4j in the application for separating the logs what is the best way to do this?