When I log something with console.warn() it seems to appear in the Stackdriver logs with severity "ERROR". The Stackdriver Error Reporting does not show these errors, so it seems there they are not considered errors. This makes it impossible to filter the logs to only show me errors.
Reading the Stackdriver logging docs I get the impression that I'm not supposed to use the plain javascript console functions but instead use Bunyan. Is that correct? I didn't read anywhere that I shouldn't.
Cloud Functions only distinguishes between stdout & stderr.
The docs on Writing, Viewing, and Responding to Logs say that "Cloud Functions includes simple logging by default. Logs written to stdout or stderr will appear automatically". The logging docs page that you referenced mentions the same thing about stdout & stderr being automatic for Cloud Functions.
My interpretation is that console.warn() is going to stderr, and once there the distinction between warn and error is lost. I suspect you'd see the same for console.debug() showing up as INFO. I have this behavior in VMs when stderr is used, but I think App Engine does not have this problem.
I don't think the logging docs page is suggesting Bunyan specifically. It addresses Winston similarly, as well as a client library (in which case authentication should just work).
Error Reporting has a specific notion of what constitutes an "error" to be captured: https://cloud.google.com/error-reporting/docs/formatting-error-messages
I have since learned from Google support that things changed (at least for cloud functions) since Node 10. Node 8 still logged correctly with console.info getting level info and console.warn getting level warning, and that seems to align with my experience.
In recent versions of firebase-functions there is the logger library which you should use for writing logs. For non-firebase environments you can use #google-cloud/logging which seems essentially the same thing. You then have full control over severity level as well as the ability to log extra JSON payload as the second parameter.
So in other words, don't use the native Javascript console methods.
If your logs are showing up in Stackdriver Logging, then Error Reporting is at least able to see them. From there, there's some more requirements that depend on exactly what you're using (eg if you're just logging JSON, it may need a reportLocation with serviceContext).
This might be useful: https://cloud.google.com/error-reporting/docs/formatting-error-messages
On the other hand, if you're just trying to view severity ERROR logs, just using the advanced filter in Logging for severity=ERROR might do what you're looking for?
Related
When you're developing on localhost, then you've got full access to a terminal that you can log anywhere you want. But, in a project, I work on (and am new to team collaboration as a whole) they use something called weavescope to view logs that developers have created at the time of coding.
Now what the difference between this and logging locally, everytime you'll create a change in the code, you gotta send a pull request, they approve it, and merge it, deploy it and we finally see it in the log. Now, sometimes the state of local and deployed things don't match and it really makes us wanna dynamically log on to the development server without having to go through all these cycles over again. Is there any solution already around that helps us insert some quick log statements without having to go through the routine PR, merge, deploy cycle?
EDIT: I think from discussions I had below, the tool I am looking for is more or less a logging statment code injection tool. A tool that would keep track of the logs I'm inserting into the production code, and on/off them at spin of a command.
This seems like something that logging levels can help with (unless I'm misunderstanding). Something I typically do is leave debug-level log messages on commonly problematic or complex functions, but change the logging level to something higher when I move out of local. Sometimes depending on the app and access these can be configured at the environment rather than in the build.
For example there are Spring libraries that will let you import a static logger, set the level of each message you log out. Then locally you can keep the level at DEBUG, in UAT the level can be INFO, and if you only want ERROR OR WARN messages in prod you can separate that too. At the time of deployment you can set what environment it is and store a separate app.properties or yml file for each environment storing the desired level for each
Of course there is a solution for fast pace code changes.
Maybe this kind of hot reloading is what you're looking for. This way you can insert new calls to a logger or console.log quickly.
Although it does come with a disclaimer from the author.
I honestly haven't looked into whether this method of hot reloading would provide stable production zero-downtime deploys, however my "gut feel" says don't do it. And production deployments are probably one area where we should stick to known, trusted procedures unless we have good reason.
Linkerd's docs explain how to track down failing requests using the tap command, but in some cases the success rate might be very high, with only a single failed request every hour or so. How is it possible to track down those requests that are considered "unsuccessful"? Perhaps a way to log them somewhere?
It sounds like you're looking for a way to configure Linkerd to trap requests that fail and dump the request data somewhere, which is not supported by Linkerd at the moment.
You do have a couple of options with the current functionality to derive some of the info that you're looking for. The Linkerd proxies record error rates as Prometheus metrics which are consumed by Grafana to render the dashboards. When you observe one of these infrequent errors, you can use the time window functionality in Grafana to find the precise time that the error occurred, then refer to the service log to see if there are any corresponding error messages there. If the error is coming from the service itself, then you can add as much logging info about the request that you need to in order to help solve the problem.
Another option, which I haven't tried myself is to integrate linkerd tap into your monitoring system to collect the request info and save the data for the requests that fail. There's a caveat here in that you will want to be careful about leaving a tap command running, because it will continuously collect data from the tap control plane component, which will add load to that service.
Perhaps a more straightforward approach would be to ensure that all the proxy logs and service logs are written to a long-term store like Splunk, an ELK (Elasticsearch, Logstash, and Kibana), or Loki. Then you can set up alerting (Prometheus alert-manager, for example) to send a notification when a request fails, then you can match the time of the failure with the logs that have been collected.
You could also look into adding distributed tracing to your environment. Depending on the implementation that you use (jaeger, zipkin, etc.) I think the interface will allow you to inspect the details of the request for each trace.
One final thought: since Linkerd is an open source project, I'd suggest opening a feature request with specifics on the behavior that you'd like to see and work with the community to get it implemented. I know the roadmap includes plans to be able to see the request bodies using linkerd tap and this sounds like a good use case for having those bodies.
I have an assignment where before I get a message from a server and tweet it, I have to check if an error occurs. If it does, it says that I have to "show with a human task an error message specifying a number and the error received. After that, the process ends".
In another part of the workflow I do check for errors but I'm not required to show anything, and frankly I do not understand how that would work, I believe my mistake is that I might be thinking too literally or too close to code showing errors and such.
Any help or place to look for information?
The answer to this question will vary depending on the edition of Bonita BPM that you are using.
With Community edition:
Note that error management will impact process design.
You can implement the following scenario:
retrieve the error (this can be done by using a custom connector output).
store the error details in a process variable.
have an exclusive gateway with a condition that branches to an optional human task that shows the error in a form.
With Performance edition:
There is a built in error management feature in Bonita BPM Portal. As an administrator you may review stack traces associated to connector execution failures, edit some settings and replay the connectors.
All of this is done without impacting the process design.
I have googled mush, and found nothing, so please bare with a possible silly question. I have my own logging, of events and stats, that logs to the Event Log. I would like to log long and verbose error information to a 30 day rolling text file. How do I do this?
To log with PostSharp you can either use included Diagnostics Pattern Library or create your own custom aspect.
The diagnostics library can log the names of methods being invoked together with parameter/return values. The actual logging messages are sent to one of the supported logging back-ends (Console, System.Diagnostics.Trace, Log4Net, NLog, EnterpriseLibrary).
You can follow the PostSharp docs to add logging with the chosen back-end first, and then you would need to set up that back-end to write messages to a rolling text file. The configuration depends on the specific back-end, there are examples for log4net, NLog, etc.
If you want to write more custom information to the log, then it would be better to create your own logging aspect. You can start with the example in the PostSharp docs. Again it would be better to prepare your message and then just pass it on to the logging library that will handle writing to the rolling text file. That way you get the powerful configuration options provided by the library and don't need to re-implement low-level details.
We have a perl web interface that I am currently working on to slowly convert to using Dancer 2 and PSGI instead of our slow old plain vanilla CGI model.
In our old model, we stored everything in sessions -- the history of what the users did, the call stacks, the data inputs, ........ you get the idea.
We do not want to do it that way anymore so that we can keep the sessions small and efficient. BUT, we'd still like to log just what the users have been doing (that way when an error gets reported we can see what they did to get to the error, what input(s) they put in, etc).
I looked at Logging on Dancer2 documentation, but this doesn't seem to quite get to what we need - this would only record Dancer2 messages + what other messages I put in.
This one that I found Dancer2::Logger doesn't seem to quite cut it either.
What other libraries could I use to do what I need? I seriously doubt that perl does NOT have somethign that does this so...
Just off the top of my head, I can think of Log::log4perl and Log::Dispatch, though there are myriad others.
You can use them to establish your own log files, separate from dancer's log.
As for the best way, most logging interfaces have the same api for logging, but differ in run-time instantiation, and configuration syntax. So read the docs on a few of them and maybe try a couple out on for size.