Code Monkey home page Code Monkey logo

js-sumo-logger's Introduction

Sumo Logic JavaScript Logging SDK

The Sumo Logic JavaScript Logging SDK library enables you to send custom log messages to an HTTP Source without installing a Collector on your server by using a CommonJS module (sumoLogger.js).

You must have created an HTTP source in your Sumo Logic account to use this SDK. To create one, log into Sumo Logic, go to the Collectors page and either create a new Hosted Collector or add a new HTTP source to an existing Hosted Collector. Online help is available on that page with all the relevant details.

Basics:

All logs are sent as JSON objects by default. If you call log() with just a string, the string is included as a field called msg. If you call the function with a JSON object, each field in the object is included as a separate field. Fields called sessionId, url, and timestamp are sent in both cases.

Messages are batched and sent at the configured interval/batch size; default for both is zero, meaning messages are sent to the server on each call. You can force any queued messages to be sent, typically during a shutdown or logout flow.

Module Deprecation Notice
NOTE: Use of the sumologic.logger.js module is deprecated as of v2.0.0. It will be removed entirely in v3.0.0. Starting with v2.0.0 no updates will be made to this module. Please use the sumoLogger.js module instead.

Table of Contents

Installation

Prerequisites

You must have an HTTP source in your Sumo Logic account to use this SDK. To create one:

  • log into Sumo Logic,
  • go to the Manage Collection page, and,
  • either add a new HTTP source to a new or existing Hosted Collector or select an existing HTTP source.

You’ll need the endpoint URL to configure the logger object. You can get it by clicking the Show URL link for the source on the Manage Collection page.

If you don't have a Sumo Logic account yet, you can easily create one by going to https://www.sumologic.com and clicking the Free Trial button--no cost, just enter your email.

You must also have Node.js/npm installed to use the SDK. Node installation

Please review the Security Note at the end of this article before planning your implementation.

Using NPM:

$ npm install --save sumo-logger

From GitHub:

  • Download or clone this repo.
  • Copy the files in the src folder into your app/website source.
  • Add <script src="path/to/sumoLogger.js"></source> to your pages or import or require the module in your app.
  • Add a <script> block with the desired log call to your pages, or use the function as needed in your app, as explained in Usage.

Typescript

A typings file developed by Clement Allen is available at https://github.com/DefinitelyTyped/DefinitelyTyped/tree/d805f985f094cf169a933abb4fa506bcc6784dd8/types/sumo-logger (e.g., "@types/sumo-logger": "^1.0.0").

Usage

Core functions

  • log: Set a log to be sent.
  • flushLogs: Force any pending logs to be sent immediately. This is mainly for use in a logOut/window.onBeforeUnload flow to ensure that any remaining queued messages are sent to Sumo Logic.
  • startLogSending: Start sending batched logs at the preconfigured interval
  • stopLogSending: Stop sending batched logs

Configuration

Before sending any messages your page should set up the SumoLogger object. Of all the configurable attributes, only endpoint is required and all others are optional.

endpoint (Required)

To send your logs, the script must know which HTTP Source to use. Pass this value (which you can get from the Collectors page) in the endpoint parameter.

returnPromise (optional)

Default: TRUE. Causes log() to return a promise and ignore the onSuccess and onError handler options (if passed). ONLY works when logs are sent individually and not batched (interval: 0).

interval (optional)

A number of milliseconds. Messages will be batched and sent at the interval specified. Default value is zero, meaning messages are sent each time log() is called. If both batchSize and interval are configured sending will be triggered when the pending logs' aggregate message length is reached or when the specified interval is hit, and in either case the interval will be reset on send.

useIntervalOnly (optional)

Boolean. If enabled batchSize is ignored and only interval is used to trigger when the pending logs will be sent.

batchSize (optional)

An integer specifying total log length. This can be used by itself or in addition to interval but is ignored when useIntervalOnly is true. For higher volume applications, Sumo Logic recommends using between 100000 and 1000000 to optimize the tradeoff between network calls and load. If both batchSize and interval are configured sending will be triggered when the pending logs' aggregate message length is reached or when the specified interval is hit, and in either case the interval will be reset on send.

onSuccess (optional)

You can provide a function that is executed only when logs are successfully sent. The only information you can be sure of in the callback is that the call succeeded. There is no other response information.

onError (optional)

You can provide a function that is executed if an error occurs when the logs are sent.

graphite (optional)

Enables graphite metrics sending.

raw (optional)

Enables sending raw text logs exactly as they are passed to the logger.

clientUrl (optional)

You can provide a URL, in the Node version of this SDK only, which will be sent as the url field of the log line. In the vanilla JS version, the URL is detected from the browser's window.location value.

sessionKey (optional)

To identify specific user sessions, set a value for this field.

hostName (optional)

This value identifies the host from which the log is being sent.

sourceCategory (optional)

This value sets the Source Category for the logged message.

sourceName (optional)

This value sets the Source Name for the logged message.

Per Message Options

All variants of the log call take an optional object parameter, which can include any of the following fields:

timestamp:

Defaults to new Date() called when processing the log call. Use this when the event being logged occurred at a different time than when the log was sent.

sessionKey:

Override a session key set in the config call.

url

Override client URL set in the config call. (Node version only)

Usage Examples

Full configuration:

  var opts = {
    endpoint: "https://us2-events.sumologic.com/receiver/v1/http/222loremipsumetc32FG",
    returnPromise: false,
    interval: 20000, // Send messages in batches every 20 seconds
    batchSize: 100000 // Or when total log length reaches 100k characters
    sendErrors: true,
    sessionKey: 'Abc32df34rfg54gui8j098dv13sq5re', // generate a GUID
    sourceName: 'My Custom App',
    sourceCategory: 'My Source Category',
    hostName: 'My Host Name',
    onSuccess: function() {
      // ... handle success ....
    },
    onError: function() {
      // ... handle error ....
    },
    graphite: true // Enable graphite metrics
  };

Logging

const SumoLogger = require('sumo-logger');
const opts = {
    endpoint: 'your HTTP Source endpoint',
    clientUrl: 'http://yourDomain.com/path/to/page' // NODE version only,
    // ... any other options ...
};

// Instantiate the SumoLogger
const sumoLogger = new SumoLogger(opts);

// Push a message to be logged
sumoLogger.log('event message to log', {
  sessionKey: 'your session key value',
  url: 'https://youDomain.com/actual/page/served'
}).then(() => /* handle positive response */)
.catch(() => /* handle error response */);

// Flush any logs, typically this line would be in your shutdown code
sumoLogger.flushLogs();

Metrics

const SumoLogger = require('sumo-logger');
const opts = {
    endpoint: 'your HTTP Source endpoint',
    graphite: true // enable graphite metrics
    // ... any other options ...
};

// Instantiate the SumoLogger
const sumoLogger = new SumoLogger(opts);

// Push a metric
sumoLogger.log({
  path: 'metric.path', // metric path as a dot separated string
  value: 100 // value of the metric
}).then(() => /* handle positive response */)
.catch(() => /* handle error response */);

Field Extraction Rules: fields in Sumo Logic

Security Note

Sumo Logic is always concerned with security but in some instances we must balance risks with value of functionality. Using the vanilla JS version of this library is one such situation.

Hitting an HTTP source endpoint from code running in a web browser exposes the endpoint URL to anyone inspecting the code or running your app with the browser console open to the network tab. There is no means to obfuscate or hide this. The risk is some malicious individual will send additional traffic to the endpoint, potentially using up your ingest or polluting your searches.

If this is a concern for you, we recommend using the the lib from a Node.js app running on your server so your endpoint URL is never exposed.

One method for minimizing the damage from some malicious users, should you choose to use this or other similar code in the browser, is adding an arbitrary string based on a regex to your log message and adding a processing rule to the HTTP source configuration that blocks incoming messages which lack a match for the regex.

Tests

Tests are in the test/ directory and can be run using the following command

$ npm run test

To generate a coverage report which is visible at coverage/lcov-report/index.html, run this command

$ npm run cover

Issues

Please file issues or feature requests on this Github repo.

Credits

Thanks to Clement Allen for his many contributions to this project.

TLS 1.2 Requirement

Sumo Logic only accepts connections from clients using TLS version 1.2 or greater. To utilize the content of this repo, ensure that it's running in an execution environment that is configured to use TLS 1.2 or greater.

License

Copyright 2017-2018, Sumo Logic, Inc. The Sumo Logic JavaScript Logging SDK is published under the Apache Software License, Version 2.0. Please visit http://www.apache.org/licenses/LICENSE-2.0.txt for details.

js-sumo-logger's People

Contributors

billsaysthis avatar bpolanczyk avatar clementallen avatar dcheng666666 avatar dependabot[bot] avatar genia123 avatar hlmartin avatar jacob-israel-turner avatar jamesaspence avatar killtheliterate avatar kkruk-sumo avatar nishatbaig avatar ozairp avatar perk-sumo avatar rvmiller89 avatar safaiyeh avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

js-sumo-logger's Issues

is Webworker integrated in JS-sumo-logger

Required some detail about how sumologger calls are not impacting performance of any web application when page is open in browser. Does it use async api calls or web workers?

Multiple messages sending on same line

When calling the .log() method in rapid succession, it appears that multiple messages can end up on the same line which then confuses Sumo into thinking they're part of the same message.

I believe this line in sumoLogger.js (55):

body: currentLogs.concat('\n')

Needs to be:

body: currentLogs.join('\n')

Note the difference between concat and join:

Concat:

The concat() method is used to merge two or more arrays. This method does not change the existing arrays, but instead returns a new array.

Join:

The join() method joins all elements of an array (or an array-like object) into a string and returns this string.

Since we're trying to append a new line char to each item in the array (and not at the end of the entire array) I think it should use join.

Does this sound right, or is there a reason it's currently using concat?

Thanks!

Expose async interface from log method

Do you think it would be reasonable to expose something from the log method, so the caller could (optionally) wait for the result? Our use case is when interval === 0 (the default) where each call to log is associated with one HTTP request. If log could essentially proxy and return the axios promise, this wouldn't be a breaking change.

It might be a bit more fiddly (and a less useful feature) to implement this when interval > 0, so perhaps it would only be enabled for the other case.

What do you think?

Log Level?

In working with Sumo Logic in the past with a different integration, they put emphasis on log levels per https://www.sumologic.com/glossary/log-levels/. Very handy.

How does this library think about this? Doesn't seem to be a way to specify log level, but happy to be corrected!

Change default sending from seconds to seconds or number/size of messages

There was some internal discussion recently about the optimal batching for HTTP endpoints and the recommendation is to send batches of 100KB to 1MB. This is a good balance of network traffic, app load, and use of receiver resources.

Specifically one of the engineers recommended we use both time and amount of logs, for example send everything if no sends on last seconds or send when there are 100 logs or 100KB of logs. Sending resets both counts.

@clementallen Looking for feedback on this change.

sessionKey pre-pending "sumologic.logger.session"

Sorry in advance if this isn't the right place for this - but I was wondering why the session key adds "sumologic.logger.session" to the beginning of every post.

I have my config set up like:

// generate guid using Guid Node package
const sessionID = Guid.raw();

// set options for sumo-logger
var sumoLoggerOpts = {
    endpoint: "MY_SOURCE_ENDPOINT",
    interval: 20000, // Send messages in batches every 20 seconds 
    sendErrors: true,
    sessionKey: sessionID
};

Now I would expect the session ID to equal whatever guid is generated so the message looks like:

{"msg":"session started for user: nwilson with session id: 613dd23b-3422-96b7-3942-c2d08f00bbe2","sessionId":"613dd23b-3422-96b7-3942-c2d08f00bbe2","timestamp":"Thu, 22 Feb 2018 00:19:36 GMT","url":""}

Instead, it looks like:

{"msg":"session started for user: nwilson with session id: 613dd23b-3422-96b7-3942-c2d08f00bbe2","sessionId":"sumologic.logger.session613dd23b-3422-96b7-3942-c2d08f00bbe2","timestamp":"Thu, 22 Feb 2018 00:19:36 GMT","url":""}

I know where to fix it (in sumoLogger.js on line 5, or 28) but I was curious what its purpose is. Thanks!

Logs are missed, if they were logged during axios request performing

Hi!

I faced the issue when some logs were missed using interval-based logs sending. So I added console logs with the pendingLogs length before the request and within then section. Sometimes the log length before this.pendingLogs = [] is bigger than before request.

Could you please help with it?
Thanks!

SumoLogic SDK fails to work

Hi,

We're using Sumologic SDK (https://github.com/SumoLogic/js-logging-sdk) and get the following error:

Failed to load https://endpoint1.collection.us2.sumologic.com/receiver/v1/http/ZaVnC4dhaV3...0SiTUGo7o9dxNm5 (index):1bJHzJr80EcmGJlbSlcdn1GYn8ooa==: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access.

Please help us fix this.

Request for httpOnly / Secure Cookie

When we connect using this API, the browser session for our application sets a cookie named sumologic.logger.session that is not secure not httpOnly.

We are under a strict security requirement that demands having all cookies with those conditions.

Is there a possible solution to this issue? We've contacted support and they suggested us to raise a ticket here.

Thanks!

Logs aren't sending at all (in commit 33ee127)

Ok now that I've upgraded to the latest version :) I realized in commit 33ee127 that the logs are no longer sending to Sumo. Line 58:

body: currentLogs.concat('\n')

Should be using the logsToSend var instead:

body: logsToSend.concat('\n')

Just want to check here to make sure that's what was intended before opening a PR. Thanks!

BUG? request body is array with last item containing '\n'

Description
The body sent via request to Sumo Logic is an array with the last item being a string containing just \n

Expected
I'm presuming the contents was intended to be a string with each array item separated by \n?
If so logsToSend.concat('\n') should be replaced with logsToSend.join('\n')

Code to replicate

const SumoLogger = require('sumo-logger');

const logger = new SumoLogger({
    endpoint: 'https://example.com'
});

logger.log({
    path: 'pathvalue',
    value: 15
});

Body contents

[ '{"sessionId":"d17b3b67-59c3-4a06-9093-1786dc40c3f2","timestamp":"Thu, 01 Mar 2018 16:38:12 GMT","url":"","path":"pathvalue","value":15}', '\n' ]

Second call to log() doesn't work...

Hi. I'm not sure if this is a bug, intended behavior, or a result of me not configuring my SumoLogger instance appropriately. It seems like I can call the log method on a SumoLogger instance one time. Subsequent calls to log seem to do nothing. I've resorted to creating a new SumoLogger instance per log msg in my wrapper, but this doesn't seem correct. Here's how I'm configuring the SumoLogger. Am I missing something?

        const sumo_opts = {
            endpoint: '<my endpoint>',
            returnPromise: false,
            interval: 0,
            sourceName: '<my source name>',
            onSuccess: Logger.onLogSucceeded,
            onError: Logger.onLogFailed,
            sourceCategory: '<my log level>',
            sessionKey: `<my uuid>`
          };
        
        const sumo_logger = new SumoLogger(sumo_opts);

"You must also have Node.js/npm installed to use the SDK. "

What does this line in the readme mean? "You must also have Node.js/npm installed to use the SDK." The readme gives the impression that I do not need node and can run the library through a variety of means, including just in the browser.

Duplicate log messages sent after 2.2.0

Hi, I think an issue was introduced in #64 which can cause duplicate log messages to be sent to sumo. If I revert to version 2.1.1, the issue no longer occurs.

The problem seems to be caused by the addition of this.startLogSending(); to:

            return axios
                .post(this.config.endpoint, this.pendingLogs.join('\n'), {
                    headers
                })
                .then(() => {
                    this.pendingLogs = [];
                    // Reset interval if needed:
                    this.startLogSending();
                    this.config.onSuccess();
                })
                .catch((error) => {
                    this.config.onError(error);
                });

I think the problem is with startLogSending itself - it calls setInterval without first calling clearInterval and so ends up with duplicate timers executing...

Lodash security vulnerability

Known low severity security vulnerability detected in lodash < 4.17.11 defined in package-lock.json.

package-lock.json update suggested: lodash ~> 4.17.11.

Error when determining timezone

In the formateDate function there's an error when determining the timezone.

It uses the following method:

var timezone = JSON.stringify(date).split('GMT')[1] || '+000';

However, the output of JSON.stringify(date) is an ISO formatted time:

2019-07-12T04:21:17.821Z

This means the timezone is always being set to +000 as there is no GMT substring found.

In this case, the timezone should be set to +1000.

Snippet in Head

We are utilizing web components and would like them to use the same SumoLogic telemetry provider. Do you offer instead of an npm package, a script snippet we can include in the HEAD of our html?

Logs are lost while request is pending.

this.sendLogs() method has a flaw that the assurance of data being successfully sent to the given endpoint is depending on combination of:

  1. Particular internet connection.
  2. sendLogs() execution timing from the client.

This particular flag - this.logSending is being reset within the this._postSuccess() method which is only being executed when the http promise is being resolved.

Which means that all logs which will be sent during the pending request time, will be dropped and forever lost here:
if (this.logSending || this.pendingLogs.length === 0) { return false; }

This should work and no logs must be silently dropped without an interval/batch/flushLogs involvement.

client library shouldn't assume window

We would like to use the client library for a isomorphic (server side rendered) React App, in addition use it within a React Native App. Since this library assumes window and document are global, this will cause issues with the above two cases.

It would be nice if this library exported the function instead of making them available as part of global window object.

instead of

  window.SLLogger = logger; // default global logger
  window.SumoLogger = SumoLogger; // To instantiate additional loggers

use:

export {SLLogger, SumoLogger}

The consumers could import the library as:

import { SLLogger, SumoLogger} from "sumo-logger";

Falsey evaluation can have unintended side effect.

if (this.config.graphite && (!testEl.path || !testEl.value)) {

The falsey style evaluation (!testEl.path || !testEl.value) of the property value has some unintended side effects. A value of 0 will cause the function to report an error although 0 is absolutely an acceptable value for the value property.

My suggestion is to check for existence of the property and/or type. Something like this:
(typeof testEl.path !== 'string' || typeof testEl.value !== 'number')
or
(!('path' in testEl) || !('value' in testEl))

//EDIT: This is version 2.0.4 of library.

Single log messages sent forever when interval set and returnPromise in default state

Because the return promise code path through sendLogs does not remove the logs from the pending logs, if you configure to use batching (interval > 0) and do not explicitly set returnPromise to false (it defaults to true), then single logs will get caught and continually sent at the interval frequency.
Ideally, the log should only be send once regardless of what returnPromise is set to

Remove axios from dependencies due to reported security vulnerability causing false alert

Vulnerability CVE-2019-10742 in npm package axios has been identified in the National Vulnerability Database.

Axios up to and including 0.18.0 allows attackers to cause a denial of service (application crash) by continuing to accepting content after maxContentLength is exceeded.

Because axios is still listed in dependencies of js-sumo-logger, code depending on js-sumo-logger is getting flagged as having a security vulnerability.

This issue is thus for tracking removing axios from the dependency.

For more information from the axios side:

superagent version is way out of date

I get the following message when installing this library:

warning sumo-logger > [email protected]: Please upgrade to v7.0.2+ of superagent.  We have fixed numerous issues with streams, form-data, attach(), filesystem errors not bubbling up (ENOENT on attach()), and all tests are now passing.  See the releases tab for more information at <https://github.com/visionmedia/superagent/releases>. Thanks to @shadowgate15, @spence-s, and @niftylettuce. Superagent is sponsored by Forward Email at <https://forwardemail.net>.
warning sumo-logger > superagent > [email protected]: Please upgrade to latest, formidable@v2 or formidable@v3! Check these notes: https://bit.ly/2ZEqIau

For security alone, the superagent version should be updated or at least use a >= for the version.

Metric logging does not work as per the docs

When I attempt to send metrics as per the docs, it attempts to JSON parse the graphite string.

in your code:

   const messages = message.map((item) => {
      if (this.config.graphite) {
        return `${item.path} ${item.value} ${Math.round(ts.getTime() / 1000)}`;
      }

conflicts with

batchReadyToSend() {
    if (this.config.batchSize === 0) {
      return this.config.interval === 0;
    } else {
      const pendingMessages = this.pendingLogs.reduce((acc, curr) => {
        const log = JSON.parse(curr);
        return acc + log.msg + '\n';
      }, '');

the code i'm calling with

const sumoLogger = new SumoLogger({
  endpoint: ENV_VARS.SumologicMetricsCollectorEndpoint,
  graphite: true,
  hostName: `WMS-${process.env.COMMIT_HASH}`,
  batchSize: 10000,
  interval: 5000,
});

sumoLogger.log({
  path: 'metric.path', // metric path as a dot separated string
  value: 100, // value of the metric
});

results in

SyntaxError: Unexpected token m in JSON at position 0
    at JSON.parse (<anonymous>)
    at /Users/[redacted]/api/node_modules/sumo-logger/lib/sumoLogger.js:129:26
    at Array.reduce (<anonymous>)
    at SumoLogger.batchReadyToSend (/Users/[redacted]/api/node_modules/sumo-logger/lib/sumoLogger.js:126:48)
    at SumoLogger.log (/Users/[redacted]/api/node_modules/sumo-logger/lib/sumoLogger.js:355:48)
    at Object.<anonymous> (/Users/[redacted]/api/build/config/sumoLogger.js:22:12)
    at Module._compile (node:internal/modules/cjs/loader:1196:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1250:10)
    at Module.load (node:internal/modules/cjs/loader:1074:32)
    at Function.Module._load (node:internal/modules/cjs/loader:909:12)

Logging throws exception and goes into infinite send loop when in buffered send mode

When it sends the data, and formats the response in "marshalHttpResponse" -function, response.statusText is undefined and response.res is undefined so it throws exception.

  • If it's running in buffered send mode (interval option !== 0), the exception causes it to never remove sent element from buffer and it will send it again after interval.

statusText: response.statusText || response.res.statusMessage,
https://github.com/SumoLogic/js-sumo-logger/blob/master/src/sumoLogger.js#L28

Not sure why the response is missing, has something been changed on the collector endpoint?

Log messages get duplicated when not using batching

When interval is 0 (batching not used), if multiple log messages are send in rapid succession, then some of those messages get sent to sumo multiple times. This happens because of how the pendingLogs are being used in the code.

SumoLogger not sending unhandled errors when `sendErrors` is set to `true`

Example

import SumoLogger from 'sumo-logger';

const opts = {
  endpoint: 'https://endpoint1.collection.eu.sumologic.com/receiver/v1/http/xxx',
  sendErrors: true,
  sourceName: 'xxx',
  sourceCategory: 'xxx',
  hostName: 'xxx',
};

const sumo = new SumoLogger(opts);
throw 'Dummy error!';

If I understand correctly the library should "catch" the unhandled error and send it as a log message. Unfortunately, it's not happening and I don't know why. What am I missing?

Duplicate messages being sent to SumoLogic

The observed result is sumo logic collector is really slow.
AND when SLLogger interval is configured to be long enough which is > collector response time,
then duplicated messages will be sent.
Workflow:
Interval 5000 ms -> send logs -> Another interval loop runs -> send logs twice -> ....(many times) -> Collector responds OK -> logs are finally cleared, but too late.

Broken link in README.md

A link given in /README.md to some additional documentation returns a 404.

The link is, at the time of this writing, on line 213. Search "field extraction".

New release?

Hi - is it possible to estimate when a new release might be cut (so that latest features are available to install via NPM)?

The feature I'm most interested in is Carbon2 support #117 (required for sending metrics)

Question: Offline Mode

I am building an Electron app, and want to log to SumoLogic using this SDK. As it is a desktop app, it will definitely be used offline, so I don't want to lose those logs, I want to batch them somewhere until the app is online again, and I can push those to SumoLogic.

Does this library provide any method out of the box to be able to handle being offline, and then pushing later when online? My thoughts are perhaps using startLogSending and stopLogSending, so when I go offline, I invoke the stop method, and then upon getting connection again, invoke the start method.

As a side note, are these batched logs persisted to a file? Or simply in memory?

Using Metrics and Standard logging

Hi,

I'm trying to use this sdk for standard logging. sumoLogger.log()
However, I also want to use it for metrics. sumoLogger.log({path, value})

enabling the graphite: true throws an error when trying to use it for standard logging. It looks like the path and value fields are mandatory as soon as you enable graphite.

Sumo Logic requires both \'path\' and \'value\' properties to be provided in the message object

Is there a way around this?

Have multiple loggers (as shown below) does not seem to solve the issue either.

 const logger1 = new SumoLogger(opts1)
 const logger2 = new SumoLogger(opts2)

Request: Allow logs to be sent without url

I am working on application where we are logging the path and an object of pathParams to Sumo Logic because it makes filtering by these fields much easier. We would prefer not to send the url as this is redundant information for us and unnecessarily takes up extra disk space.

I did not see an option in the documentation for opting out of sending the url, timestamp, and/or sessionId. For my use case I would only want to opt out of sending the url.

Crashed NodeJS API If Load Is Full.

I had my credits for the day full.
It crashed our API.

We have all our sumologger.log calls in a try catch as well and it still crashes.
Same on frontend but at least it only shows the errors on the console.

I think it is throwing an exception when it can't connect, not even when it is trying to log something.
Is there a way for it to just fail silently?

For now we just disabled SumoLogger for our NextJS site and api, as it is an ecom site and we are losing money if SumoLogger does this.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.