In all the conversations I read, none ever named the possibility to use the function Log in the extensions.conf
Then I found this minimal description:
https://www.voip-info.org/wiki/view/Asterisk+cmd+Log
What are the downsides of using Log vs NoOp, or using a shell to log some message?
You can use anyone. There is also Verbose with same functionality
Noop do NOTHING, i.e it not change verbose level, just output to console or to log which marked as "all" in logger.conf
Verbose allow control log level, so you can setup in logger file for different levels.
Log do same as verbose, but level is STRING not integer.
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.
console.log("Log") shows up as an Info level log in the firebase functions log.
console.debug("Debug") does not show up at all.
I have the log viewer set to display all log levels.
Is there something I need to do to support different log levels?
This is for the fulfillment for a dialogflow application, if this matters. I would guess it doesn't but it's my only experience with firebase.
console.debug is for internal messages.
You need to use:
console.log() commands have the INFO log level.
console.info() commands have the INFO log level.
console.warn() commands have the ERROR log level.
console.error() commands have the ERROR log level.
Check the documentation.
Where can I configure the log level?
In our Plugin, we've got some logger.Debug("...") and logger.Information("...") but I'm only seeing the Information ones in the Admin site.
I assume the fix is changing the log level to Debug, no?
Yes, by design it's disabled, thus even if you change the log level from Information to Debug it won't make any difference, and you won't able see any log at admin area.
To write debug log you have to enable debug log level at Nop.Services.Logging> IsEnabled rebuild the solution and run it again.
To implement it with plugin, you would need to override IsEnabled method and switch as per user input.
There is an alternate way to write debug log instead:
_logger.InsertLog(Nop.Core.Domain.Logging.LogLevel.Debug, "debug info here");
I am walking through the Ubuntu walk-through for installing OpenStack. I am past the keystone stage and I find that it creates log files in /var/log/keystone which are always zero length. I also get the following message in the response to many commands that otherwise work:
No handlers could be found for logger "keystoneclient.v2_0.client"
-- this may or may not be related. Any advice for a noob appreciated.
This is the Folsom release.
Keystone uses /etc/keystone/logging.conf to control logging levels. By default, the keystone logger will only show WARNING level messages and above:
[logger_root]
level=WARNING
handlers=file
If you change level to something lower (e.g., INFO, DEBUG) then restart the keystone service, you should see log messages appear in /var/log/keystone/keystone.log
I've got a new production computer and installed my BizTalk app on there. The problem is that I don't see any messages in the event log, nor from my BizTalk app or BizTalk Server itself. The only message that appears in the event log is the following:
The following BizTalk host instance has initialized successfully.
BizTalk host name: BizTalkServerApplication
Windows service name: BTSSvc$BizTalkServerApplication
The source of that message is BizTalk Server. And no messages at all, even no logs about errors which I suppose already took place.
Just a quick thought incase you are still having problems.
I tried to write to the event log with a source type that didnt already exist and my BizTalk Host user account didn’t have permissions to create a new source type. This meant I never saw the entry in the event log.
E.g. (from example #Bill Osuch)
System.Diagnostics.EventLog.WriteEntry("MyBiztalkApp", "oh i did something");
Make sure either the MyBiztalkApp source exists or that your user has permissions on the event log to create it.
Also, if you have a lot of messages going through BizTalk you will probably want to implement your own logging so your event log doesn’t fill up. We used Log4Net for our implementation and a database to store messages.
If you're not getting any errors (suspended messages) as the messages process, you're not going to see anything in the app log. You could try adding an Expression shape to your orchestration and manually writing out some debug info:
System.Diagnostics.EventLog.WriteEntry("event type", "whatever...");
Does your application actually use the BiztalkServerApplication host? Check in the Biztalk Administration Console if all the host instances are indeed running. Is your application fully started? Messages are "put on hold" if your receive location is disabled for example.
To check this functionality, write to event log after every operation or shape in BizTalk orchestration.
Scenario-
Suppose you have to assigned a value to xpath of node in a map after transformation so in message assignment shape after you assign some value, you can write eventlog to admin console.
Ex. Suppose we have already initialized - "orderType" as "PO" in our expression shape and now we have to assign the value of "orderType" to the xpath of a node in our map then-
Shape- MessageAssignment(Under constructMessage Shape after transformation of map)
xpath(msgGetOrderReq, "/[local-name()='CustomerOrders' and namespace-uri()='http://example.com/EAI/IEmployee/v1.0']/[local-name()='ordertype' and namespace-uri()='http://example.com/EAI/IEmployee/v1.0']") = ordertype;
Next to this we want to print this information on the admin console so we need to write:-
System.Diagnostics.EventLog.WriteEntry("msgGetOrderReq", ordertype, msgGetOrderReq);
Build the project, Deploy and GAC it. Restart the host instance. Run the orchestration, process something and now you will be able to see the logs in admin console.
Regards
Mayank