Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing log file with Meteor Up deployment #17

Open
shiami opened this issue Jun 29, 2020 · 4 comments
Open

Missing log file with Meteor Up deployment #17

shiami opened this issue Jun 29, 2020 · 4 comments

Comments

@shiami
Copy link

shiami commented Jun 29, 2020

My setup:

import { Logger }     from 'meteor/ostrio:logger';
import { LoggerFile } from 'meteor/ostrio:loggerfile';
import { LoggerConsole } from 'meteor/ostrio:loggerconsole';

const log = new Logger();
new LoggerConsole(log).enable();
new LoggerFile(log, {
    path: './logs/'
  }).enable({
    enable: true,
    filter: ['*'], // Filters: 'ERROR', 'FATAL', 'WARN', 'DEBUG', 'INFO', 'TRACE', '*'
    client: false, // Set to `false` to avoid Client to Server logs transfer
    server: true  // Allow logging on server
  });

It works at local meteor.
After mup deploy, the folder appears at /built_app/programs/server/logs,
but the log file never show up.

@dr-dimitru
Copy link
Member

Hey 👋 @shiami
Two possible reasons:

  1. Path not writable;
  2. Directory got gleaned up.

To solve it I suggest creating and using /data/logs directory. Better if configured with mup as storage

@ensemblebd
Copy link

ensemblebd commented Aug 17, 2021

FYI this also occurs if you are not properly calling upon your log methods.

log.warn("message", {my: 'object'), userId);  // where userId comes from meteor or etc.

if you do not use the built in methods as per base class: https://github.com/veliovgroup/Meteor-logger
Then the folder exists and no files or output whatsoever.

I had presumed, not sure why, that using console.log() would redirect to it. It does not.
Also tried tag teaming ostrio:logger-console on the same Logger base class. But to no avail.

Here's my helper class which completely ignores meteor's user. I imagine this would be considered an anti-pattern.
But I don't use Meteor sessions, and I value a global common logging system far more than importing a logger constant everywhere. so. yea.

let self = null;

class Console {
    constructor(log) {
        self = this;
        this._log = log;

        this.hooked = {
            warn: console.warn,
            error: console.error,
            info: console.info,
            log: console.log,
            debug: console.debug,
            dir: console.dir
        };
        // apply hooks...
        console.warn = this.warn;
        console.error = this.error;
        console.info = this.info;
        console.log = this.log;
        console.debug = this.debug;
        console.dir = this.dir;
    }

    warn() {
        let details = self.common_getDetails.apply(self, arguments);
        self._log.warn(details.msg, details.data, 0);
        return self.hooked.warn.apply(this, arguments);
    }
    error() {
        let details = self.common_getDetails.apply(self, arguments);
        self._log.error(details.msg, details.data, 0);
        return self.hooked.error.apply(this, arguments);
    }
    info() {
        let details = self.common_getDetails.apply(self, arguments);
        self._log.info(details.msg, details.data, 0);
        return self.hooked.info.apply(this, arguments);
    }
    log() {
        let details = self.common_getDetails.apply(self, arguments);
        self._log.info(details.msg, details.data, 0);
        return self.hooked.log.apply(this, arguments);
    }
    debug() {
        let details = self.common_getDetails.apply(self, arguments);
        self._log.debug(details.msg, details.data, 0);
        return self.hooked.debug.apply(this, arguments);
    }

    
    dir() {
        return self.hooked.dir.apply(this, arguments);
    }

    common_getDetails() {
        let msg = '';
        let data = null;
        if (typeof(arguments[0])=='string') {
            msg = arguments[0];
            if (arguments.length>1 && typeof(arguments[1])!=='string') {
                data = arguments[1]; // todo: consider a clone and splice? actually slice would be smarter.
            }
        }
        else {
            data = arguments;
        }
        return {
            msg: msg,
            data: data
        };
    }

}
export default Console;

// then wherever you initialize your logger globally (singleton):

import { Logger } from 'meteor/ostrio:logger';
import { LoggerConsole } from 'meteor/ostrio:loggerconsole';
import { LoggerFile } from 'meteor/ostrio:loggerfile';
import Console from './console';

const log = new Logger();
// formatting, config, etc, goes here, for logger and loggerfile/loggerconsole.
const _console = new Console(log);

common_getDetails needs help, considering all the possible variations of arguments. But it does the job at a simple level.

Meaning you can call "console.log" naturally like you always do, and it goes both to console output (natural), and to your ostrio logger file.

@dr-dimitru
Copy link
Member

I had presumed, not sure why, that using console.log() would redirect to it. It does not.

This is never a case, you got to use Logger methods

dr-dimitru added a commit to veliovgroup/Meteor-logger that referenced this issue May 31, 2022
- 👨‍💻 Minor codebase refactoring
- 👨‍🔧 Properly sanitize and process `data` log argument; *Potentially* fixing [logger-file #17](veliovgroup/Meteor-logger-file#17)
- 📔 Minor documentation improvements
- 🤝 Compatibility with latest `[email protected]`
@dr-dimitru
Copy link
Member

Please see and upgrade to the latest v2.1.0

Feel free to close it in case if the issue is solved on your end.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants