You can try this to enable debug level log at Hibernate.
<logger name="org.hibernate" level=”debug”>
rollingHibernateLog –must be also defined in logback.xml
Tridion uses the Hibernate framework for it's database persistence, so Hibernate's logging is what needs to be set up.
In logback.xml define the following:
1) Define an appender to put the DB log statements into a separate file. Simply paste this into your logback.xml:
<appender name="rollingHibernateLog" class="ch.qos.logback.core.rolling....
Here are the logs which are helpful during publish and their configuration:
Tridion Content Manager
Logfiles on CM/Publisher Servers:
LogFiles on Deployers:
Configuring logging level and their locations:
Modify the logback.xml under %...
No. Unfortunately it is not possible to retrieve info which user edited (or deleted) smarttarget promotions. The issue with them is that they are not stored in tridion but in Fredhopper in business.xml file. SmartTarget is extention which allows you to edit them in Tridion easily.
The default logback configuration for Tridion does make use of automatic reloading, so any changes in logback.xml will not be picked up until the application restarts. In other words, you'd have to replace logback.xml and then restart IIS.
UPDATE: I was wrong. The default logback.xml has scan="true" - without a scan period this will default to a minute.
You can turn off verbose logging from templates by following the steps in this article
On your publisher server, open /bin/TcmPublisher.exe.config
Find the loggingConfiguration/specialSources/allEvents element and change the
switchValue from Information to Warning or Error
Save the file and restart the publisher service
No need to change the log level on log4j.properties and logging.properties.
As @Eric mentioned, you need to update log level on logback.xml
Sample Logback file looks like,
<?xml version="1.0" encoding="UTF-8"?>
<!-- Properties -->
<property name="log.folder" value="c:/tridion/log"/>
These events are recorded by the Tridion code calling the Windows logging APIs. Once that's happened, you can't prevent the log entry being created. The only way you could have filtering would be if Tridion had made the logging of certain events configurable. I am not aware of any such configuration possibilities.
Having said that, all is not lost, as ...
In addition to Tridion's own logging (which is configured through the logback.xml, see other answers) DD4T has its own logging mechanism. Or actually two: one based on Log4Net and the other based on Microsoft's Enterprise Library.
You can tell which logging framework you're using by looking at the appSetting with key DD4T.LoggerClass. For Log4Net, for ...
ON is not a valid logback log level, although IIRC, using an invalid value for level will result in DEBUG logging, so I don't think this will cause you not to see any output.
You are right to check the file permissions assigned to the application pool account. I would suggest taking this line of enquiry further using Sysinternals procmon to check for any ...
Even though the Tridion.Logging namespace is officially not part of the public API, I still would recommend using it from your event handlers. It allows you for a clean and easy way of adding messages to the Tridion event log on Windows, and you don't need to write additional code or add an additional logging framework.
Now important to note is that since ...
This error means the windows event log source Content Delivery.Net is either not present or configured to not allow the application pool user write access.
The SDL Tridion 2013 SP1 installation sources (subfolder Content Delivery\roles\deployer\dotNet\x86_64) come with an EventLogCreator.exe tool which is designed to create the windows event log source; try ...
Tridion Montoring is available for 2011. There is a monitoing endpoint which you can hit to ensure that Tridion is Healthy or you can setup as a service.
You have to setup and install monitoring agent before you can do this. Refer this section and install per you needs
Tridion Monitoring Documentation
Alternatively, you can also monitor individual Tridion ...
I note that the logging defaults to false and I wonder if this is the reason. I don't see anywhere that you can control the size of the log (or to have a larger set of data broken across multiple files) as you would in say, Log4Net.
I think the answer is "manage this by the process in DevOps" ... if you must log then someone should be monitoring the ...
Indeed, Publish Transactions get removed as soon as a new one for the same item/target gets in a "final" state (Succes/Warning/Error); the Publish Queue is intended as a queue, not an audit trail.
Audit trail functionality in general can be relatively easily added in an implementation using event handlers. You could use (Global) Application Data to store ...
Seems like you are referring to the wrong version of Tridion.Logging dll (Tridion 2011 instead of the one from Tridion 2013).
Please check the Tridion.Logging.dll versions for Tridion 2013 they should be 7.x and for Tridion 2011 they should be 6.x
The information about root causes is to be found in various log files. Depending where something goes wrong, you will need to look either in the Windows event logs on the publisher server, the transport log, or in the logs of your upload application, such as the deployer log.
So actually, checking logs is what you'll need to do. The information will most ...
Once root logging in enabled on trace level, you can confirm the hibernate trace is working by looking for statements such as this:
2014-03-14 05:29:50,977 DEBUG ConnectionManager - opening JDBC connection
2014-03-14 05:29:50,977 DEBUG SQL - select custommeta0_.PUBLICATION_ID as PUBLICAT8_1_,
custommeta0_.ITEM_ID as ITEM4_1_, custommeta0_....
Chances are that you have a logger configured to log in Debug, and perhaps you're just changing the top log level? Individual logger configurations for specific classes will override the main log level.
Also, you can configure logback to reload its configuration without restarting by adding a scanPeriod attribute to the configuration:
I would suggest to use NLog.dll. When I configured my custom events to use NLog, it was really handy and I can set my own file naming format. You can also extend the NLog.
You have to add the nlog.config and NLog.dll in the same location of Dll.
If you are trying to logging for the Dll which is in GAC then you should use log4net.
You're not actually supposed to use Tridion.Logging in your implementation code - partially due to the whole configuration hassle, partially because that particular class is not designed for other uses than internal Tridion.
My recommendation? Use log4net.
We had similar needs not just for audit trail but from a business user perspective where the user wanted to know when an item is published by whom and to which targets etc.
We wrote event system code to subscribe to the
EventSystem.SubscribeAsync<PublishTransaction, SaveEventArgs>(OnPublishStatus_Initiated, EventPhases.Initiated);
to capture the ...
First of all - are ure sure, that your event system code is hit? (try to write the same text with streamwriter to check).
Secondly - for using Tridion.Logging you need specify logging configuration...examples of configuration you can find in web.cfg or tcmSereviceHost.exe.cfg (section - loggingConfiguration).
For your situation you must have something like ...
The transport log logs events that occur during transportation by the transport service itself. By having the transport service stopped, there is simply nothing running to update the log. Your transport packages will probably just wait to be picked up when a transport service comes back up again or may fail with a timeout after a while.
If you're trying to ...
Apart from the info given in the other answers, you can also disable linking logging completely by adding the following logger in logback.xml:
<logger name="com.tridion.linking" level="OFF">
Turning logging completely off is of course not very handy, in case errors occur when links are ...
I think you'll struggle to get Tridion itself to log everything to a file on the CM side, and even more so to the same single file as all logs. Maintaining any event system code and configuration that you write could be a pain and you might one day miss some information because you missed out that particular event in the code (or the info was not attributed ...
There are no bench mark times listed for any of the actions anywhere, since performance is related to a large set of parameters which include implementation specifics, hardware, etc.
However what I noted in the past 14 years of working with SDL Tridion is that bad performance on a CM server is generally releated to poor database performance, which is ...