Sitecore 6.6 was deployed on azure using Sitecore Azure 3.0 tool. I'm looking for sitecore logs,because I need to see who changed particular item, but I can't find them. So I'm interested in AUDIT log lines.
I was looking in blob storage, but there are only containers: cacheclusterconfigs, publishtargets, sitecore-auto-deploy, wad-control-container, wad-iis-logfiles.
I was looking in table storage, using azure storage explorer, but there are only tables: WADDiagonsticInfrastructureTable, WADDirectoriesTable, WADLogsTable, WADPerformanceCountersTable, WADWindowsEventLogsTable.
Where are audit logs stored?
Bartłomiej.
You can find Sitecore log entries in the WADLogsTable table into Azure Storage Service that Sitecore Azure module creates during deployment.
Please take a look at the following article for more details:
https://kb.sitecore.net/articles/400950
Best Wishes,
Oleg Burov
With Sitecore Experience Platform 8.2, the location of the log files has been updated: https://kb.sitecore.net/articles/911837
Logs can now be accessed via Application Insights. Find the proper Application Insights object:
Select the object, which will launch a new window:
Open a new tab (query) and enter the following query exactly:
traces
| extend scinstancename=parsejson(customDimensions).InstanceName
| where timestamp > now(-1d)
| summarize count(), any(tostring(scinstancename)) by cloud_RoleInstance
| extend InstanceName=any_scinstancename
| extend CloudRole=cloud_RoleInstance
| project InstanceName, CloudRole
| order by InstanceName asc
Hit 'GO'.
Find the instance you wish to view the logs of, and take note of the CloudRole column:
Lastly, run the following query in a new tab, swap out the 'CloudRole' with the role you found from the previous step:
traces
| where cloud_RoleInstance == 'REPLACE_THIS_ROLE'
| where timestamp > now(-14d)
| project timestamp, message
| sort by timestamp desc
The log file is displayed below:
Results may be exported to CSV if desired:
Sitecore logs, by default, are stored in a folder named "logs" under the folder specified in this setting in the web.config file:
<sc.variable name="dataFolder" value="/data" />
By default, this value is "/data". In a typical non-Azure implementation, this value is usually an absolute path to the "Data" folder that is one level up from the Sitecore "Website" folder.
When using the Sitecore Azure module, this value is transformed to "/App_Data" during deployment. So you would find your logs under "/App_Data/logs" on your Azure instance.
If you don't want to access the logs via file system/remote desktop, you can also view them within the Sitecore desktop interface. Simply log in to the Sitecore desktop, then click the Sitecore button -> Reporting Tools -> Log Viewer. In the Log Viewer application, you will be able to open and view a log file from the Sitecore instance you are logged into.
Related
Is there a clean way to query for the names for all disabled functions in Azure Monitor?
Sure, I can hard-code the names or the functions and check if there has been any logs for the functions, but I imagine there is a smarter way.
Thanks!
You should use Application insights for Azure function. For details, please follow this article. Then you can use the query below to get all the disabled function names.
Note: The query below can be run in Application insights, or Azure Monitor.
traces
//use sdkVersion to ensure it's an anzure function
| where sdkVersion contains "azurefunctions"
//then check if the message contains the word disabled
| where message contains "disabled"
//get the function name from message
| extend functionname=substring(message, 10,indexof(message,"'", 10)-10)
Explain about the query:
1.if the function is disabled, then the message field should contain the information like "function xxx is disabled."
2.to ensure it's an azure function, I check the field sdkVersion to see if it contains word "azurefunctions"
3.at last, fetch the function name from the message field.
The test result:
I tested it with function v3, if you're using azure function v2 or v1, you may(or may not) modify the query a little, but it should be easy.
Loading the site returns the error: site map root node is null, the database is demo data stock
You can run this SQL command against the database to check if the node exists:
SELECT * from sitemap where Title = 'Sitemap Root' and CompanyID > 0;
If it is not there the deployment is corrupted and you will need to re-install the website.
There's not enough information in the question to determine how it was deployed and which data set was used. For SalesDemo data it should be deployed from the wizard.
The Azure documentation for App Insights doesn't appear to have fresh articles relating to Windows 10 UWP Apps specifically. This appears to be endemic throughout all services (Notification Hub, Mobile Apps, Azure AD, etc.). So far I have found only references to Windows 8/8.1 Universal apps. I'm not sure how applicable they are but some code snippets do seem to compile at least.
My problem is that I have just setup a new App Insights instance for a 'WindowsStore App'. This is intended for a Windows 10 UWP app.
In my app, I have done the following:
Ingested the nuget package for App Insights which has created an ApplicationInsights.config file.
Updated the Instrumentation Key with the one from my WindowsStore App Insights Instance in the Azure Portal.
Added Internet (Client) capability in application manifest.
Created a static TelemetryClient that I use throughout all my Views / View Models.
private static TelemetryClient telemetry = new TelemetryClient();
public static TelemetryClient Telemetry
{
get { return telemetry; }
}
Updated the WindowsAppInitializer to include several WindowsCollectors.
Microsoft.ApplicationInsights.WindowsAppInitializer.InitializeAsync(
WindowsCollectors.Metadata |
WindowsCollectors.Session |
WindowsCollectors.PageView |
WindowsCollectors.UnhandledException
);
Added an event handler within App.xaml.cs for Unhandled Exception and call TelemetryClient.TrackException on the exception.
private void App_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
ViewModelDispatcher.Telemetry.TrackException(e.Exception);
}
Added TelemetryClient.TrackPageViews to OnNavigatedTo overrides in my views.
But so far, after doing all that, my App Insights dashboard in the Azure Portal is showing zip, zilch, nada. :\
This makes me think one of two things is going on. Either I am missing some critical piece of this recipe or I'm still within the refresh window for the App Insights Dashboard.
Have you tried to include your instrumentation key to the call of InitializeAsync?
I'm using the following code at the constructor of App class.
Microsoft.ApplicationInsights.WindowsAppInitializer.InitializeAsync(
"YOURINST-RUME-NTAT-IONK-EY012345678",
WindowsCollectors.Metadata |
WindowsCollectors.PageView |
WindowsCollectors.Session |
WindowsCollectors.UnhandledException);
I haven't confirmed the current specs (yes...the documentation of ApplicationInsight is an labyrinth :( ), but from AI v1.0, you have not to include your instrumentation key to your applicationinsight.config. Instead of it, you can specify the key with the call of initializer.
Recently found this (i work on the AI team and it still happened to me!).
If you manually added the applicationinsights.config file, make sure it is set to "Content" and "Copy if newer" in the project settings. If it isn't, then the sdk can't find the instrumentation key at runtime, since the applicationinsights.config file didn't get deployed to the device.
Update 1/11/2016: i just learned of another issue that can cause this: comments in the xml file that look like xml tags.
If your config file has any comments of the form:
<!-- <InstrumentationKey>anything</InstrumentationKey> -->
Or
<!--
Learn more about Application Insights configuration with ApplicationInsights.config here:
http://go.microsoft.com/fwlink/?LinkID=513840
Note: If not present, please add <InstrumentationKey>Your Key</InstrumentationKey> to the top of this file.
-->
(Like is common in examples you might have gotten online, or migrating from a previous version of the AI SDK's)
If those comments appear in your config file before your real key, then the win10 sdk startup code will find those in the comments instead of your real key.
So if you see debug output that says it is using the literal string "YourKey" instead your actual key, that's the reason. (The win10 sdk uses a regex to find your key instead of loading system.xml assemblies to parse the file)
I have a .Net back end mobile service and I would like my System.Diagnostics.Trace statements to go to the same destination as ApiServices.Log (i.e. the portal).
The reason for this is that I don't want to pass ITraceWriter down to my data tier due to the dependencies it adds (System.Web.Http etc).
I started to look at an approach where I would add to the trace listeners collection, similar to as described here:
http://blog.tylerdoerksen.com/2012/04/20/logging-in-azure-part-3-traceevent-logs/
But this adds an instance of DiagnosticMonitorTraceListener which doesn't exist by default in a MobileService as this lives in Microsoft.WindowsAzure.Diagnostics.
Does anyone know how to do this?
Thanks
F
In general, trace messages are written to the logs regardless of where they come from. For example, if I have a custom controller like this:
public string Get()
{
IHubContext hubContext = Services.GetRealtime<ChatHub>();
Trace.WriteLine("something!");
Trace.TraceError("error");
Trace.TraceInformation("info");
hubContext.Clients.All.hello("Hello Chat Hub clients from custom controller!");
return "Hello from custom controller!";
}
then "error" and "info" are written as you would expect. In fact, you can find the logs directly from within VS by using the Service Explorer and then Azure and Mobile Services. Right click on your service and select View Logs.
The only wrinkle is that verbose messages are not written as the default log level is Info. You can work around this by setting the level manually through the Kudu site:
https://.scm.azure-mobile.net
Then under the "Debug Console" drill down to Site/diagnostics and edit the file settings.json. It should look something like this:
"AzureDriveEnabled":true,"AzureDriveTraceLevel":"Information","AzureTableEnabled":false,"AzureTableTraceLevel":"Error","AzureBlobEnabled":false,"AzureBlobTraceLevel":"Error"}
Change the Information value to Verbose and you will get verbose messages as well.
Hope this helps!
Henrik
The migration of the SQL Reporting component of Windows Azure from the old portal to the newer html 5 one has in the process limited the folder hierarchy to 2 levels deep (As indicated in this article).
The article does however state that existing reporting services can still have deeper hierarchies; whilst Business Intelligence Development Studio still allows you to deploy to the sub folder.
We have preserved our hierarchy like so:
Root Level
Client Reports
Internal Reports
Report Category 1
Data Source
Report1.rdl
Report2.rdl
Report Category 2
Due to the number of reports we have it is unfeasible to have every folder at root level and, thus far, the hierarchy has still be functioning correctly.
However we have run into a problem; we can no longer update any data sources or delete reports that are more than 2 levels deep.
Rather than restructure all our reports to suit what feels like an extremely restrictive structure, is there a way of managing our SQL Reporting reports external to the portal, via either an API, BIDS or Powershell?
OK so I've done a bit of research into this; SQL Reporting on Windows Azure exposes the ReportService2010 SOAP interface for administering the reports programmatically.
Using a proxy generated through the WSDL tool we can remotely connect to SQL Reporting using the below C# code:
var reportServiceUrl =
"https://X.reporting.windows.net/reportserver/reportservice2010.asmx?wsdl";
var serviceUsername = "AdminUserName;
var servicePassword = "AdminPassword";
var reportingService = new ReportingService2010
{
Url = reportServiceUrl,
CookieContainer = new CookieContainer()
};
reportingService.LogonUser(serviceUsername, servicePassword, reportServiceUrl);
The reportingService object can then be used to upload, update and delete all items on the SQL Reporting instance. If, for example, I wanted to delete a report in a sub folder that cannot be accessed on the Windows Azure portal, I could use:
reportingService.DeleteItem("Internal Reports/Report Category 1/Report1.rdl");
That stated; it is much easier to refactor the report folders to a 2 level hierarchy instead. The naming convention we ended up using is:
Root Level
Internal Reports - Report Category 1
Data Source
Report1.rdl
Report2.rdl
Internal Reports - Report Category 2