I've created Node js with express and currently I use the console.log to log message and morgan for expresss...for production use what is recommended approach to use for error handling and logging ,there is recommended modules to use?
Examples will be very useful!
I try with the following
module.exports = function () {
var logger = new winston.Logger({
levels: {
info: 1
},
transports: [
new (winston.transports.File)({
level: 'info',
filename: path.join(process.cwd(), '/logs/log.json'),
})
]
});
}
I have used winston in the past quite effectively. In the below excerpt we are creating a custom log level called info such that we can call logger.info to log messages. I believe there are numerous default levels defined on winston which are well documented.
The second part is to define a transport. In winston this is essentially a storage device for your logs. You can define multiple transports in the array including Console logging, File logging, Rotated file logging, etc... These are all well documented here. Im my example I have created a file transport where the log file is located under log/logs.json within the root of the application. Every time I now call logger.info('blah blah blah') I will see a new log entry in the file.
var winston = require('winston'),
, path = require('path')
// Log to file.
var logger = new winston.Logger({
levels: {
info: 1
},
transports: [
new (winston.transports.File)({
level: 'info',
filename: path.join(process.cwd(), '/log/logs.json'),
})
]
});
// Write to log.
logger.info("something to log");
Related
I am trying to create a deployment or replicaSet with the Kubernetes Javascript client. The Kubernetes javascript client documentation is virtually non-existent.
Is there any way to achieve this?
Assuming that by:
createDeployment()
you are referring to: createNamespacedDeployment()
You can use below code snippet to create a Deployment using Javascript client library:
const k8s = require('#kubernetes/client-node');
const kc = new k8s.KubeConfig();
kc.loadFromDefault();
const k8sApi = kc.makeApiClient(k8s.AppsV1Api); // <-- notice the AppsV1Api
// Definition of the deployment
var amazingDeployment = {
metadata: {
name: 'nginx-deployment'
},
spec: {
selector: {
matchLabels: {
app: 'nginx'
}
},
replicas: 3,
template: {
metadata: {
labels: {
app: 'nginx'
}
},
spec: {
containers: [
{
name: 'nginx',
image: 'nginx'
} ]
}
}
}
};
// Sending the request to the API
k8sApi.createNamespacedDeployment('default', amazingDeployment).then(
(response) => {
console.log('Yay! \nYou spawned: ' + amazingDeployment.metadata.name);
},
(err) => {
console.log('Oh no. Something went wrong :(');
// console.log(err) <-- Get the full output!
}
);
Disclaimer!
This code assumes that you have your ~/.kube/config already configured!
Running this code for the first time with:
$ node deploy.js
should output:
Yay!
You spawned: nginx-deployment
You can check if the Deployment exists by:
$ kubectl get deployment nginx-deployment
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 6m57s
Running this code once again will output (deployment already exists!):
Oh no. Something went wrong :(
Additional resources:
Github.com: Kubernetes-client: Javascript
Be careful when you try to deploy a different kinds of resources such as deployment or service.
You need to correctly specify the API version.
const k8sApi = kc.makeApiClient(k8s.AppsV1Api) or (k8s.CoreV1Api) for namespace and etc.
First, you create a kube config object and then create the associated API type. I.e,
import k8s from '#kubernetes/client-node';
const kubeConfig = new k8s.KubeConfig();
kubeConfig.loadFromCluster(); // Or whatever method you choose
const api = kubeConfig.makeApiClient(k8s.CoreV1Api); // Or whatever API
// you'd like to
// use.
const namespace = 'default';
const manifest = new k8s.V1ConfigMap();
// ... additional manifest setup code...
await api.createNamespacedConfigMap(namespace, manifest);
This is the gist of it. If you'd like, I recently created a library with the intention of simplifying interactions with the kubernetes javascript api and it can be found here:
https://github.com/ThinkDeepTech/k8s
If it doesn't help you directly, perhaps it can serve as an example of how to interact with the API. I hope that helps!
Also, make sure the application executing this code has the necessary permissions (i.e, the K8s Role, RoleBinding and ServiceAccount configs) necessary to perform the actions you're attempting. Otherwise, it'll error out.
I followed a tutorial to set up winston (2.x) default logger in my express app. When updating to the current version of winston (3.0.0) I have a problem with adding the transports. I have followed the latest docs but still I get the notice in console and no log files are created at all:
[winston] Attempt to write logs with no transports
logging.js
const winston = require('winston');
module.exports = function () {
const files = new winston.transports.File({ filename: 'logfile.log' });
const myconsole = new winston.transports.Console();
winston.add(myconsole);
winston.add(files);
}
index.js
const winston = require('winston');
...
require('./logging');
winston.info("Give some info");
[winston] Attempt to write logs with no transports
{"message":"Give some info","level":"info"}
What am I doing wrong?
In winston 3 you need to create a logger object, then add transports to it.
Winston 3 has many examples, but to adapt from the readme, do something like this:
const logger = winston.createLogger({
level: 'info',
format: winston.format.json(),
transports: [
new winston.transports.Console(),
new winston.transports.File({ filename: 'logfile.log' })
]
});
logger.info('it works!!');
If you want to use the default logger in winston v3 then you simply have to add this piece of code in your main file
const winston = require('winston')
winston.add(new winston.transports.File({ filename: 'logfile.log' }))
I also had a similar issue. If I recall correctly, I had to call the requirement as a function in my index.js.
require('./logging')();
My log4js.js file code
'use strict';
var log4js = require('log4js');
var log4jsGen = {
getLogger: function getLogger() {
log4js.loadAppender('file');
log4js.addAppender(log4js.appenders.file('./ApplicationLogs.log'), 'logs');
var logger = log4js.getLogger('logs');
return logger;
}
};
module.exports = log4jsGen;
My conf.js file(specific to appender section only)
"appenders": [{
"type": "log4js-protractor-appender",
"append": 'false',
"maxLogSize": 20480,
"backups": 3,
"category": "relative-logger"
}],
Problem:
1) IS there a way that the logs will get overwritten in each run.
2) Why log4js-protractor-appender is not working, instead log4js is working, the merit of the previous is that it resolves the promises which is passed as an argument.
Thats a great question. Yes log4js-protractor-appender is awesome. It is built specially for Protractor based environments and it places all logger command in Protractor Control flow and resolves Protractor promises before logging.
You were using it incorrectly. The appender options are not part of Protractor config options but can be integrated. The approach you have is a little old one and I have updated by blog post
These are the steps as an answer to your question-2
Step 1: Install log4js npm module
Step 2: Install log4js-protractor-appender module
Step 3: Add the logger object creation logic in protractor beforeLaunch() and assign it onto browser protractor global object
'use strict';
var log4js = require('log4js');
beforeLaunch:function(){
if (fs.existsSync('./logs/ExecutionLog.log')) {
fs.unlink('./logs/ExecutionLog.log')
}
log4js.configure({
appenders: [
{ type: 'log4js-protractor-appender', category: 'protractorLog4js' },
{
type: "file",
filename: './logs/ExecutionLog.log',
category: 'protractorLog4js'
}
]
});
},
onPrepare: function() {
browser.logger = log4js.getLogger('protractorLog4js');
},
Step 4: Use logger object in your tests by accessing through browser.logger
describe('sample test', function(){
it('Sample Check', function(){
browser.get("http://www.protractortest.org/#/");
browser.logger.info("Testing Log4js");
browser.sleep(5000);
browser.logger.info('Displayed text is:', browser.getCurrentUrl());
var elm = element(by.css('.lead'))
browser.logger.info('Displayed text is:', elm.getText());
});
});
But one thing to note is - This appender is just an console appender and will not be able to write to file. The file will still contain unresolved promises
Sample Output:
[21:54:23] I/local - Starting selenium standalone server...
[21:54:23] I/launcher - Running 1 instances of WebDriver
[21:54:25] I/local - Selenium standalone server started at http://192.168.1.5:60454/wd/hub
Started
[2017-02-03 21:54:30.905] [INFO] protractorLog4js - Testing Log4js
[2017-02-03 21:54:35.991] [INFO] protractorLog4js - Displayed text is: http://www.protractortest.org/#/
[2017-02-03 21:54:36.143] [INFO] protractorLog4js - Displayed text is: Protractor is an end-to-end test framework for Angular and AngularJS applications. Protractor runs tests against your application running in a real browser, interacting with it as a user would.
.
Answer to your Question 1: How to overwrite logs each run. I added a simple logic in beforeLaunch() to delete old logs if they exist and its part of the code snippet I pasted above
I have check this issue with and followed the steps mentioned in Answer 1 and it works for me.
Earlier I was getting log output in Console only but now I am getting log in console and file also.
I corrected the file path passing and Set type: "file" in log4js configure in conf file.
Log4js in Conf file
Log appender in file
Please let me know if you face any issue again.
Thanks
I have an electron application which is using node.js. I would like to use Winston for logging in the application. I've added winston to my package.json file, but when I run the build command for webpack I'm getting some warnings from the colors.js dependency in winston.
'...the request of a dependency is an expression...'
It then references winston and colors.js. Ignoring the warnings doesn't work, as the electron application gets an exception trying to load some files from winston.
I did some digging on SO and the github site and they say that colors.js has some dynamic require statements that webpack is having issues with. I've also seen that other sample projects seem to have winston up and running without any issues in their projects. Does anyone know how to correctly include the winston logging package with webpack in an electron app?
There are two sides to this issue:
1) winston directly or indirectly depends on color.js, so that dependency automatically gets included, once winston is there. In some older versions of it, it included a dynamic require statement, which leads to this:
2) a dependency has a dynamic require statement that Webpack cannot handle; you can either configure webpack so it can ignore this specific case, or also upgrade winston to a newer version, so color.js will be picked in a variant without that dynamic require (see https://github.com/winstonjs/winston/issues/984).
To tell Webpack to get along with the dynamic require, you need to tell Webpack that Winston is an external library.
Here's an example from my webpack.config.js:
externals: {
'electron': 'require("electron")',
'net': 'require("net")',
'remote': 'require("remote")',
'shell': 'require("shell")',
'app': 'require("app")',
'ipc': 'require("ipc")',
'fs': 'require("fs")',
'buffer': 'require("buffer")',
'winston': 'require("winston")',
'system': '{}',
'file': '{}'
},
To make the logger available in an angular 2 app using electron, create a logger.js file and then wrap it with a global logging service TypeScript file (i.e. logging.service.ts). The logger.js file creates the logger variable with the desired Winston configuration settings.
logger.js:
var winston = require( 'winston' ),
fs = require( 'fs' ),
logDir = 'log', // Or read from a configuration
env = process.env.NODE_ENV || 'development',
logger;
winston.setLevels( winston.config.npm.levels );
winston.addColors( winston.config.npm.colors );
if ( !fs.existsSync( logDir ) ) {
// Create the directory if it does not exist
fs.mkdirSync( logDir );
}
logger = new( winston.Logger )( {
transports: [
new winston.transports.Console( {
level: 'warn', // Only write logs of warn level or higher
colorize: true
} ),
new winston.transports.File( {
level: env === 'development' ? 'debug' : 'info',
filename: logDir + '/logs.log',
maxsize: 1024 * 1024 * 10 // 10MB
} )
],
exceptionHandlers: [
new winston.transports.File( {
filename: 'log/exceptions.log'
} )
]
} );
module.exports = logger;
logging.service.ts:
export var LoggerService = require('./logger.js');
Now the logging service is available for use throughout the application.
Example:
import {LoggerService} from '<path>';
...
LoggerService.log('info', 'Login successful for user ' + this.user.email);
Hey i am using this winston logger,
kindly explain use of level inside the transports, what will happen if i use logger with info while logging, do i have to use debug while i log my data.
var logger = new (winston.Logger)({
transports: [
new (winston.transports.Console)({
level: 'debug',
json: true
}),
new (winston.transports.File)({
name: 'order_check',
filename: './logs/order_check.log',
level: 'debug'
})
]
});
logger.log("info","request body");
The level inside your transport indiciates the minimum logging level that transport will "listen out for"
From the documentation:
https://github.com/winstonjs/winston#logging-levels
Each level is given a specific integer priority. The higher the priority the more important the message is considered to be
{ error: 0, warn: 1, info: 2, verbose: 3, debug: 4, silly: 5 }
So, in your example, your transports are configured for debug: 4
This means it will log levels
4 (debug)
3 (verbose)
2 (info)
1 (warn)
0 (error)
A good use case for this would be to set one transport (Console, for example) to debug and your other to info.
This would output all debug information to the console, but log only info to file, preventing log file clutter.
the logging level reflects the importance of the logging message
for example, debug is used for non important messages, used for debugging only
info is used for something more important
if you set the logging level to debug then the logs will show debug and info messages (and higher)
if you set the logging level to info then the logs will show only info messages (and higher) - you wont see the debug messages - this helps to avoid clutter in the logs and prevents too much info being shown in the logs in a production environment