I''m trying to get log output (Console.WriteLine(..)) in my Docker logs, but I'm getting zero avail.
I've tried:
Console.WriteLine(..)
Trace.WriteLine(..)
Flushing the console, flushing the trace.
I can see these outputs in a VS output window when I'm debugging, so they go somoewhere.
I'm on windows Container, using microsoft/aspnet:4.7.1-windowsservercore-1709 and net4.7
These are the logs I get on container start
docker logs -f exportapi
ERROR ( message:Cannot find requested collection element. )
Applied configuration changes to section "system.applicationHost/applicationPools" for "MACHINE/WEBROOT/APPHOST" at configuration commit path "MACHINE/WEBROOT/APPHOST"
You have many good lateral options, like self-contained/server-contained executables (eg. Dotnet Core using microsoft/dotnet:runtime would proxy Console.WriteLine by default off the dotnet new web scaffold). Zero-configuration STDOUT logging has never been a common approach on IIS, but these modern options adopt it as best practice (logging should be a transparent backing service).
If you want or need a chain of three programs/assemblies to get your web service up (ServiceMonitor, W3SVC, and finally your assembly), then you need something like this: https://blog.sixeyed.com/relay-iis-log-entries-to-read-them-in-docker/
Overriding the entrypoint to tail more logs than the image does by default is unfortunately a common hack (not just in Microsoft land). So, in your case, I believe you need at least a trace listener config to emit Trace.WriteLine, and then the above approach to emit it: https://learn.microsoft.com/en-us/dotnet/framework/debug-trace-profile/how-to-create-and-initialize-trace-listeners
Related
I am trying to align my logging with the best practice of using STDERR.
So, I would like to understand what happens with the logs sent to STDERR.
Symfony official docs (https://symfony.com/doc/current/logging.html):
In the prod environment, logs are written to STDERR PHP stream, which
works best in modern containerized applications deployed to servers
without disk write permissions.
If you prefer to store production logs in a file, set the path of your
log handler(s) to the path of the file to use (e.g. var/log/prod.log).
This time I want to follow the STDERR stream option.
When I was writing to a specific file, I knew exactly where to look for that file, open it and check the logged messages.
But with STDERR, I don't know where to look for my logs.
So, using monolog, I have the configuration:
monolog:
handlers:
main:
type: fingers_crossed
action_level: error
handler: nested
excluded_http_codes: [404, 405]
nested:
type: stream
path: "php://stderr"
level: debug
Suppose next morning I want to check the logs. Where would I look?
Several hours of reading docs later, my understanding is as follows:
First, the usage of STDERR over STDOUT is preferred for errors because it is not buffered (gathering all output waiting for the script to end), thus errors are thrown immediately to the STDERR stream. Also, this way the normal output doesn't get mixed with errors.
Secondly, the immediate intuitive usage is when running a shell script, because in the Terminal one will directly see the STDOUT and STDERR messages (by default, both streams output to the screen).
But then, the non-intuitive usage of STDERR is when logging a website/API. We want to log the errors, and we want to be able to monitor the already occurred errors, that is to come back later and check those errors. Traditional practice stores errors in custom defined log-files. More modern practice recommends sending errors to STDERR. Regarding Symfony, Fabien Potencier (the creator of Symfony), says:
in production, stderr is a better option, especially when using
Docker, SymfonyCloud, lambdas, ... So, I now recommend to use
php://stderr
(https://symfony.com/blog/logging-in-symfony-and-the-cloud).
And he further recommends using STDERR even for development.
Now, what I believe to be missing from the picture (at least for me, as non-expert), is the guidance on HOW to access and check the error logs. Okay, we send the errors to STDERR, and then? Where am I going to check the errors next morning? I get it that containerized platforms (clouds, docker etc) have specific tools to easily and nicely monitor logs (tools that intercept STDERR and parse the messages in order to organize them in specific files/DBs), but that's not the case on a simple server, be it a local server or on a hosting.
Therefore, my understanding is that sending errors to STDERR is a good standardization when:
Resorting to using a third-party tool for log monitoring (like ELK, Grail, Sentry, Rollbar etc.)
When knowing exactly where your web-server is storing the STDERR logs. For instance, if you try (I defined a new STD_ERR constant to avoid any pre-configs):
define('STD_ERR', fopen('php://stderr', 'wb'));
fputs(STD_ERR, "ABC error message.");
you can find the "ABC error message" at:
XAMPP Apache default (Windows):
..\xampp\apache\logs\error.log
Symfony5 server (Windows):
C:\Users\your_user\.symfony5\log\ [in the most recent folder, as the logs rotate]
Symfony server (Linux):
/home/your_user/.symfony/log/ [in the most recent folder, as the logs rotate]
For Symfony server, you can actually see the logs paths when starting the server, or by command "symfony server:log".
One immediate advantage is that these STDERR logs are stored outside of the app folders, and you do not need to maintain extra writable folders or deal with the permissions etc. Of course, when developing/hosting multiple sites/apps, you need to configure the error log (the STDERR storage) location per app (in Apache that would be inside each <VirtualHost> conf ; with Symfony server, I am not sure). Personally, without a third-party tool for monitoring logs, I would stick with custom defined log files (no STDERR), but feel free to contradict me.
I have a need to do automated testing of a configuration of WCF bindings. I wrote a test that, in it setup, picks a random port number and binds to it with a WSHttpBinding. The test runs a ServiceHost for the duration of its execution and then shuts it down. This works, but then when the build agents try to run the test, I get this error:
System.Exception: Unable to set up service host ---> System.ServiceModel.AddressAccessDeniedException: HTTP could not register URL http://+:52361/Test/. Your process does not have access rights to this namespace (see http://go.microsoft.com/fwlink/?LinkId=70353 for details). ---> System.Net.HttpListenerException: Access is denied
Is there any way to work around this? Can this "urlacl" mechanism be disabled??
UPDATE: This was a wild goose chase, as it turns out. This wasn't the error that was happening on the build agents. I flubbed it when gathering that information. Turns out the build agents are running elevated and don't run into the urlacl problem. The actual problem I was encountering was that a NuGet reference somehow hadn't had its corresponding assembly reference added to the .csproj file. How the tests worked locally, I don't know!
The error is "The process does not have permission to access this namespace".
You can try the following methods.
Make Test public
Run the service as administrator
Run the command prompt as administrator, add URL to ACL netsh http add urlacl url=
https://www.codeproject.com/Questions/441371/When-Hosting-the-WCF-service-i-got-exception
WCF ServiceHost access rights
This is sort of a part two of the question here
VisualStudio cloud-based load test socket exception 100% of requests - webtest alone works OK
In short, my loadtest fails all requests with a weird socketexception, but only when it is run as a 'cloud based' test.
So, my load test somehow (dunno how) is no longer a 'team services cloud based' unit test, but a regular one - and I see that it runs fine.
However, when I add a new cloud-based test and then click on the 'location' setting in my old test and pick anything (or not pick, doesn't matter), VS connects to my TeamServices account, the test becomes cloud-based and it is launched in a different looking tab, with 100% request fails.
So, the question is - how do I turn off/toggle the 'cloud-based' mode for an existing loadtest?
Open the testsettings file in your solution/project, you should be able to change the Test run location from VSTS to local computer:
According to the Sonatype Nexus Docs - logging, I can set the logging levels (debug, warnings, errors). But how do I actually clear the logs that sit on my server without SSHing in and deleting them? They're approaching 1Gb.
Seems this should be a scheduled task, like empty the trash.
Typically if you set up Nexus for production usage you would add them into your logrotate setup so they are not getting bigger and bigger.
The Nexus user interface has no feature to purge the log.
A 1GB log file implies you have DEBUG logging enabled. First change back to INFO level logging of the ROOT logger using the Nexus UI, to keep the log file under control.
Automatic Log rotation and size limiting is also possible for Java Service Wrapper and Nexus logs. By default, Nexus ships with sensible log rotation defaults.
First decide which log is the problem. Then use the correct configuration to adjust this.
Java Service Wrapper - wrapper.log
http://wrapper.tanukisoftware.com/doc/english/props-logging.html
Nexus logs configured via logback and logback-nexus.xml/logback-overrides.xml
You may find this reference helpful:
https://support.sonatype.com/entries/25427167-Nexus-Logging-Guide
Having some issues with MSDeploy on a windows server 2008 box, the internal service is throwing a 500 error without putting anything in the server's event logs.
I'm attempting to setup automated deployments using MSBuild/TeamCity/MSDeploy, and this is basically the current halting point, has anyone come across this issue before?
Thanks, Ed
To find out why you are getting this error you should enable logging.
First, enable Failed Request Tracing for the web management service. You can see how to do this by referring to the "Optional: Set Up Tracing" section of this article:
http://learn.iis.net/page.aspx/984/configure-web-deploy/
The "frebs" can be found in:
C:\inetpub\logs\wmsvc\TracingLogFiles\W3SVC1
Open each of the frXXXXXX.xml files with IE and it'll use the freb.xsl transform to generate a nice report.
Don't delete freb.xsl when you're done, it doesn't always get recreated.
Then turn on logging for the web management service:
http://technet.microsoft.com/en-us/library/ff729437(WS.10).aspx
You want to have the following registry entry configured:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IIS Extensions\MSDeploy\1]
"EnabledTraceLevel"=dword:00000002
"EnabledTraceSources"=dword:000001ff
You can fiddle with the tracing levels/sources to increase and decrease the verbosity of the logs.
As per the article the management service logs are written to:
%WINDIR%\ServiceProfiles\LocalService\AppData\Local\Temp\WMSvc.log