Simple & Configurable Logging in Go, with Level, formatters & Writers

go-log

Logging package similar to log4j for the Golang.

  • Support dynamic log level
  • Support customized formatter
    • TextFormatter
    • JSONFormatter
  • Support multiple rolling file writers
    • FixedSizeFileWriter
    • DailyFileWriter
    • AlwaysNewFileWriter

Installation

$ go get github.com/subchen/go-log

Usage

package main

import (
    "os"
    "errors"
    "github.com/subchen/go-log"
)

func main() {
    log.Debugf("app = %s", os.Args[0])
    log.Errorf("error = %v", errors.New("some error"))

    // dynamic set level
    log.Default.Level = log.WARN

    log.Debug("cannot output debug message")
    log.Errorln("can output error message", errors.New("some error"))
}

Output

Default log to console, you can set Logger.Out to set a file writer into log.

import (
    "github.com/subchen/go-log"
    "github.com/subchen/go-log/writers"
)

log.Default.Out = &writers.FixedSizeFileWriter{
    Name:     "/tmp/test.log",
    MaxSize:  10 * 1024 * 1024, // 10m
    MaxCount: 10,
})

Three builtin writers for use

// Create log file if file size large than fixed size (10m)
// files: /tmp/test.log.0 .. test.log.10
&writers.FixedSizeFileWriter{
    Name:     "/tmp/test.log",
    MaxSize:  10 * 1024 * 1024, // 10m
    MaxCount: 10,
}

// Create log file every day.
// files: /tmp/test.log.20160102
&writers.DailyFileWriter{
    Name: "/tmp/test.log",
    MaxCount: 10,
}

// Create log file every process.
// files: /tmp/test.log.20160102_150405
&writers.AlwaysNewFileWriter{
    Name: "/tmp/test.log",
    MaxCount: 10,
}

// Output to multiple writes
io.MultiWriter(
    os.Stdout,
    &writers.DailyFileWriter{
        Name: "/tmp/test.log",
        MaxCount: 10,
    }
    //...
)

Formatter

import (
    "github.com/subchen/go-log"
    "github.com/subchen/go-log/formatters"
)

log.Default.Formatter = new(formatters.TextFormatter)

New Logger instance

import (
    "github.com/subchen/go-log"
)

func main() {
    logger := &log.Logger{
        Level:     log.INFO,
        Formatter: new(formatters.JSONFormatter),
        Out:       os.Stdout,
    }

    logger.Infof("i = %d", 99)
}

Author: Subchen
Source Code: https://github.com/subchen/go-log 
License: Apache-2.0 License

#go #golang #logger #logging 

What is GEEK

Buddha Community

Simple & Configurable Logging in Go, with Level, formatters & Writers

Simple & Configurable Logging in Go, with Level, formatters & Writers

go-log

Logging package similar to log4j for the Golang.

  • Support dynamic log level
  • Support customized formatter
    • TextFormatter
    • JSONFormatter
  • Support multiple rolling file writers
    • FixedSizeFileWriter
    • DailyFileWriter
    • AlwaysNewFileWriter

Installation

$ go get github.com/subchen/go-log

Usage

package main

import (
    "os"
    "errors"
    "github.com/subchen/go-log"
)

func main() {
    log.Debugf("app = %s", os.Args[0])
    log.Errorf("error = %v", errors.New("some error"))

    // dynamic set level
    log.Default.Level = log.WARN

    log.Debug("cannot output debug message")
    log.Errorln("can output error message", errors.New("some error"))
}

Output

Default log to console, you can set Logger.Out to set a file writer into log.

import (
    "github.com/subchen/go-log"
    "github.com/subchen/go-log/writers"
)

log.Default.Out = &writers.FixedSizeFileWriter{
    Name:     "/tmp/test.log",
    MaxSize:  10 * 1024 * 1024, // 10m
    MaxCount: 10,
})

Three builtin writers for use

// Create log file if file size large than fixed size (10m)
// files: /tmp/test.log.0 .. test.log.10
&writers.FixedSizeFileWriter{
    Name:     "/tmp/test.log",
    MaxSize:  10 * 1024 * 1024, // 10m
    MaxCount: 10,
}

// Create log file every day.
// files: /tmp/test.log.20160102
&writers.DailyFileWriter{
    Name: "/tmp/test.log",
    MaxCount: 10,
}

// Create log file every process.
// files: /tmp/test.log.20160102_150405
&writers.AlwaysNewFileWriter{
    Name: "/tmp/test.log",
    MaxCount: 10,
}

// Output to multiple writes
io.MultiWriter(
    os.Stdout,
    &writers.DailyFileWriter{
        Name: "/tmp/test.log",
        MaxCount: 10,
    }
    //...
)

Formatter

import (
    "github.com/subchen/go-log"
    "github.com/subchen/go-log/formatters"
)

log.Default.Formatter = new(formatters.TextFormatter)

New Logger instance

import (
    "github.com/subchen/go-log"
)

func main() {
    logger := &log.Logger{
        Level:     log.INFO,
        Formatter: new(formatters.JSONFormatter),
        Out:       os.Stdout,
    }

    logger.Infof("i = %d", 99)
}

Author: Subchen
Source Code: https://github.com/subchen/go-log 
License: Apache-2.0 License

#go #golang #logger #logging 

Background Fetch for React Native Apps

react-native-background-fetch

Background Fetch is a very simple plugin which attempts to awaken an app in the background about every 15 minutes, providing a short period of background running-time. This plugin will execute your provided callbackFn whenever a background-fetch event occurs.

There is no way to increase the rate which a fetch-event occurs and this plugin sets the rate to the most frequent possible — you will never receive an event faster than 15 minutes. The operating-system will automatically throttle the rate the background-fetch events occur based upon usage patterns. Eg: if user hasn't turned on their phone for a long period of time, fetch events will occur less frequently or if an iOS user disables background refresh they may not happen at all.

:new: Background Fetch now provides a scheduleTask method for scheduling arbitrary "one-shot" or periodic tasks.

iOS

  • There is no way to increase the rate which a fetch-event occurs and this plugin sets the rate to the most frequent possible — you will never receive an event faster than 15 minutes. The operating-system will automatically throttle the rate the background-fetch events occur based upon usage patterns. Eg: if user hasn't turned on their phone for a long period of time, fetch events will occur less frequently.
  • scheduleTask seems only to fire when the device is plugged into power.
  • ⚠️ When your app is terminated, iOS no longer fires events — There is no such thing as stopOnTerminate: false for iOS.
  • iOS can take days before Apple's machine-learning algorithm settles in and begins regularly firing events. Do not sit staring at your logs waiting for an event to fire. If your simulated events work, that's all you need to know that everything is correctly configured.
  • If the user doesn't open your iOS app for long periods of time, iOS will stop firing events.

Android

Installing the plugin

⚠️ If you have a previous version of react-native-background-fetch < 2.7.0 installed into react-native >= 0.60, you should first unlink your previous version as react-native link is no longer required.

$ react-native unlink react-native-background-fetch

With yarn

$ yarn add react-native-background-fetch

With npm

$ npm install --save react-native-background-fetch

Setup Guides

iOS Setup

react-native >= 0.60

Android Setup

react-native >= 0.60

Example

ℹ️ This repo contains its own Example App. See /example

import React from 'react';
import {
  SafeAreaView,
  StyleSheet,
  ScrollView,
  View,
  Text,
  FlatList,
  StatusBar,
} from 'react-native';

import {
  Header,
  Colors
} from 'react-native/Libraries/NewAppScreen';

import BackgroundFetch from "react-native-background-fetch";

class App extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      events: []
    };
  }

  componentDidMount() {
    // Initialize BackgroundFetch ONLY ONCE when component mounts.
    this.initBackgroundFetch();
  }

  async initBackgroundFetch() {
    // BackgroundFetch event handler.
    const onEvent = async (taskId) => {
      console.log('[BackgroundFetch] task: ', taskId);
      // Do your background work...
      await this.addEvent(taskId);
      // IMPORTANT:  You must signal to the OS that your task is complete.
      BackgroundFetch.finish(taskId);
    }

    // Timeout callback is executed when your Task has exceeded its allowed running-time.
    // You must stop what you're doing immediately BackgroundFetch.finish(taskId)
    const onTimeout = async (taskId) => {
      console.warn('[BackgroundFetch] TIMEOUT task: ', taskId);
      BackgroundFetch.finish(taskId);
    }

    // Initialize BackgroundFetch only once when component mounts.
    let status = await BackgroundFetch.configure({minimumFetchInterval: 15}, onEvent, onTimeout);

    console.log('[BackgroundFetch] configure status: ', status);
  }

  // Add a BackgroundFetch event to <FlatList>
  addEvent(taskId) {
    // Simulate a possibly long-running asynchronous task with a Promise.
    return new Promise((resolve, reject) => {
      this.setState(state => ({
        events: [...state.events, {
          taskId: taskId,
          timestamp: (new Date()).toString()
        }]
      }));
      resolve();
    });
  }

  render() {
    return (
      <>
        <StatusBar barStyle="dark-content" />
        <SafeAreaView>
          <ScrollView
            contentInsetAdjustmentBehavior="automatic"
            style={styles.scrollView}>
            <Header />

            <View style={styles.body}>
              <View style={styles.sectionContainer}>
                <Text style={styles.sectionTitle}>BackgroundFetch Demo</Text>
              </View>
            </View>
          </ScrollView>
          <View style={styles.sectionContainer}>
            <FlatList
              data={this.state.events}
              renderItem={({item}) => (<Text>[{item.taskId}]: {item.timestamp}</Text>)}
              keyExtractor={item => item.timestamp}
            />
          </View>
        </SafeAreaView>
      </>
    );
  }
}

const styles = StyleSheet.create({
  scrollView: {
    backgroundColor: Colors.lighter,
  },
  body: {
    backgroundColor: Colors.white,
  },
  sectionContainer: {
    marginTop: 32,
    paddingHorizontal: 24,
  },
  sectionTitle: {
    fontSize: 24,
    fontWeight: '600',
    color: Colors.black,
  },
  sectionDescription: {
    marginTop: 8,
    fontSize: 18,
    fontWeight: '400',
    color: Colors.dark,
  },
});

export default App;

Executing Custom Tasks

In addition to the default background-fetch task defined by BackgroundFetch.configure, you may also execute your own arbitrary "oneshot" or periodic tasks (iOS requires additional Setup Instructions). However, all events will be fired into the Callback provided to BackgroundFetch#configure:

⚠️ iOS:

  • scheduleTask on iOS seems only to run when the device is plugged into power.
  • scheduleTask on iOS are designed for low-priority tasks, such as purging cache files — they tend to be unreliable for mission-critical tasks. scheduleTask will never run as frequently as you want.
  • The default fetch event is much more reliable and fires far more often.
  • scheduleTask on iOS stop when the user terminates the app. There is no such thing as stopOnTerminate: false for iOS.
// Step 1:  Configure BackgroundFetch as usual.
let status = await BackgroundFetch.configure({
  minimumFetchInterval: 15
}, async (taskId) => {  // <-- Event callback
  // This is the fetch-event callback.
  console.log("[BackgroundFetch] taskId: ", taskId);

  // Use a switch statement to route task-handling.
  switch (taskId) {
    case 'com.foo.customtask':
      print("Received custom task");
      break;
    default:
      print("Default fetch task");
  }
  // Finish, providing received taskId.
  BackgroundFetch.finish(taskId);
}, async (taskId) => {  // <-- Task timeout callback
  // This task has exceeded its allowed running-time.
  // You must stop what you're doing and immediately .finish(taskId)
  BackgroundFetch.finish(taskId);
});

// Step 2:  Schedule a custom "oneshot" task "com.foo.customtask" to execute 5000ms from now.
BackgroundFetch.scheduleTask({
  taskId: "com.foo.customtask",
  forceAlarmManager: true,
  delay: 5000  // <-- milliseconds
});

API Documentation

Config

Common Options

@param {Integer} minimumFetchInterval [15]

The minimum interval in minutes to execute background fetch events. Defaults to 15 minutes. Note: Background-fetch events will never occur at a frequency higher than every 15 minutes. Apple uses a secret algorithm to adjust the frequency of fetch events, presumably based upon usage patterns of the app. Fetch events can occur less often than your configured minimumFetchInterval.

@param {Integer} delay (milliseconds)

ℹ️ Valid only for BackgroundFetch.scheduleTask. The minimum number of milliseconds in future that task should execute.

@param {Boolean} periodic [false]

ℹ️ Valid only for BackgroundFetch.scheduleTask. Defaults to false. Set true to execute the task repeatedly. When false, the task will execute just once.

Android Options

@config {Boolean} stopOnTerminate [true]

Set false to continue background-fetch events after user terminates the app. Default to true.

@config {Boolean} startOnBoot [false]

Set true to initiate background-fetch events when the device is rebooted. Defaults to false.

NOTE: startOnBoot requires stopOnTerminate: false.

@config {Boolean} forceAlarmManager [false]

By default, the plugin will use Android's JobScheduler when possible. The JobScheduler API prioritizes for battery-life, throttling task-execution based upon device usage and battery level.

Configuring forceAlarmManager: true will bypass JobScheduler to use Android's older AlarmManager API, resulting in more accurate task-execution at the cost of higher battery usage.

let status = await BackgroundFetch.configure({
  minimumFetchInterval: 15,
  forceAlarmManager: true
}, async (taskId) => {  // <-- Event callback
  console.log("[BackgroundFetch] taskId: ", taskId);
  BackgroundFetch.finish(taskId);
}, async (taskId) => {  // <-- Task timeout callback
  // This task has exceeded its allowed running-time.
  // You must stop what you're doing and immediately .finish(taskId)
  BackgroundFetch.finish(taskId);
});
.
.
.
// And with with #scheduleTask
BackgroundFetch.scheduleTask({
  taskId: 'com.foo.customtask',
  delay: 5000,       // milliseconds
  forceAlarmManager: true,
  periodic: false
});

@config {Boolean} enableHeadless [false]

Set true to enable React Native's Headless JS mechanism, for handling fetch events after app termination.

  • 📂 index.js (MUST BE IN index.js):
import BackgroundFetch from "react-native-background-fetch";

let MyHeadlessTask = async (event) => {
  // Get task id from event {}:
  let taskId = event.taskId;
  let isTimeout = event.timeout;  // <-- true when your background-time has expired.
  if (isTimeout) {
    // This task has exceeded its allowed running-time.
    // You must stop what you're doing immediately finish(taskId)
    console.log('[BackgroundFetch] Headless TIMEOUT:', taskId);
    BackgroundFetch.finish(taskId);
    return;
  }
  console.log('[BackgroundFetch HeadlessTask] start: ', taskId);

  // Perform an example HTTP request.
  // Important:  await asychronous tasks when using HeadlessJS.
  let response = await fetch('https://reactnative.dev/movies.json');
  let responseJson = await response.json();
  console.log('[BackgroundFetch HeadlessTask] response: ', responseJson);

  // Required:  Signal to native code that your task is complete.
  // If you don't do this, your app could be terminated and/or assigned
  // battery-blame for consuming too much time in background.
  BackgroundFetch.finish(taskId);
}

// Register your BackgroundFetch HeadlessTask
BackgroundFetch.registerHeadlessTask(MyHeadlessTask);

@config {integer} requiredNetworkType [BackgroundFetch.NETWORK_TYPE_NONE]

Set basic description of the kind of network your job requires.

If your job doesn't need a network connection, you don't need to use this option as the default value is BackgroundFetch.NETWORK_TYPE_NONE.

NetworkTypeDescription
BackgroundFetch.NETWORK_TYPE_NONEThis job doesn't care about network constraints, either any or none.
BackgroundFetch.NETWORK_TYPE_ANYThis job requires network connectivity.
BackgroundFetch.NETWORK_TYPE_CELLULARThis job requires network connectivity that is a cellular network.
BackgroundFetch.NETWORK_TYPE_UNMETEREDThis job requires network connectivity that is unmetered. Most WiFi networks are unmetered, as in "you can upload as much as you like".
BackgroundFetch.NETWORK_TYPE_NOT_ROAMINGThis job requires network connectivity that is not roaming (being outside the country of origin)

@config {Boolean} requiresBatteryNotLow [false]

Specify that to run this job, the device's battery level must not be low.

This defaults to false. If true, the job will only run when the battery level is not low, which is generally the point where the user is given a "low battery" warning.

@config {Boolean} requiresStorageNotLow [false]

Specify that to run this job, the device's available storage must not be low.

This defaults to false. If true, the job will only run when the device is not in a low storage state, which is generally the point where the user is given a "low storage" warning.

@config {Boolean} requiresCharging [false]

Specify that to run this job, the device must be charging (or be a non-battery-powered device connected to permanent power, such as Android TV devices). This defaults to false.

@config {Boolean} requiresDeviceIdle [false]

When set true, ensure that this job will not run if the device is in active use.

The default state is false: that is, the for the job to be runnable even when someone is interacting with the device.

This state is a loose definition provided by the system. In general, it means that the device is not currently being used interactively, and has not been in use for some time. As such, it is a good time to perform resource heavy jobs. Bear in mind that battery usage will still be attributed to your application, and shown to the user in battery stats.


Methods

Method NameArgumentsReturnsNotes
configure{FetchConfig}, callbackFn, timeoutFnPromise<BackgroundFetchStatus>Configures the plugin's callbackFn and timeoutFn. This callback will fire each time a background-fetch event occurs in addition to events from #scheduleTask. The timeoutFn will be called when the OS reports your task is nearing the end of its allowed background-time.
scheduleTask{TaskConfig}Promise<boolean>Executes a custom task. The task will be executed in the same Callback function provided to #configure.
statuscallbackFnPromise<BackgroundFetchStatus>Your callback will be executed with the current status (Integer) 0: Restricted, 1: Denied, 2: Available. These constants are defined as BackgroundFetch.STATUS_RESTRICTED, BackgroundFetch.STATUS_DENIED, BackgroundFetch.STATUS_AVAILABLE (NOTE: Android will always return STATUS_AVAILABLE)
finishString taskIdVoidYou MUST call this method in your callbackFn provided to #configure in order to signal to the OS that your task is complete. iOS provides only 30s of background-time for a fetch-event -- if you exceed this 30s, iOS will kill your app.
startnonePromise<BackgroundFetchStatus>Start the background-fetch API. Your callbackFn provided to #configure will be executed each time a background-fetch event occurs. NOTE the #configure method automatically calls #start. You do not have to call this method after you #configure the plugin
stop[taskId:String]Promise<boolean>Stop the background-fetch API and all #scheduleTask from firing events. Your callbackFn provided to #configure will no longer be executed. If you provide an optional taskId, only that #scheduleTask will be stopped.

Debugging

iOS

🆕 BGTaskScheduler API for iOS 13+

  • ⚠️ At the time of writing, the new task simulator does not yet work in Simulator; Only real devices.
  • See Apple docs Starting and Terminating Tasks During Development
  • After running your app in XCode, Click the [||] button to initiate a Breakpoint.
  • In the console (lldb), paste the following command (Note: use cursor up/down keys to cycle through previously run commands):
e -l objc -- (void)[[BGTaskScheduler sharedScheduler] _simulateLaunchForTaskWithIdentifier:@"com.transistorsoft.fetch"]
  • Click the [ > ] button to continue. The task will execute and the Callback function provided to BackgroundFetch.configure will receive the event.

Simulating task-timeout events

  • Only the new BGTaskScheduler api supports simulated task-timeout events. To simulate a task-timeout, your fetchCallback must not call BackgroundFetch.finish(taskId):
let status = await BackgroundFetch.configure({
  minimumFetchInterval: 15
}, async (taskId) => {  // <-- Event callback.
  // This is the task callback.
  console.log("[BackgroundFetch] taskId", taskId);
  //BackgroundFetch.finish(taskId); // <-- Disable .finish(taskId) when simulating an iOS task timeout
}, async (taskId) => {  // <-- Event timeout callback
  // This task has exceeded its allowed running-time.
  // You must stop what you're doing and immediately .finish(taskId)
  print("[BackgroundFetch] TIMEOUT taskId:", taskId);
  BackgroundFetch.finish(taskId);
});
  • Now simulate an iOS task timeout as follows, in the same manner as simulating an event above:
e -l objc -- (void)[[BGTaskScheduler sharedScheduler] _simulateExpirationForTaskWithIdentifier:@"com.transistorsoft.fetch"]

Old BackgroundFetch API

  • Simulate background fetch events in XCode using Debug->Simulate Background Fetch
  • iOS can take some hours or even days to start a consistently scheduling background-fetch events since iOS schedules fetch events based upon the user's patterns of activity. If Simulate Background Fetch works, your can be sure that everything is working fine. You just need to wait.

Android

  • Observe plugin logs in $ adb logcat:
$ adb logcat *:S ReactNative:V ReactNativeJS:V TSBackgroundFetch:V
  • Simulate a background-fetch event on a device (insert <your.application.id>) (only works for sdk 21+:
$ adb shell cmd jobscheduler run -f <your.application.id> 999
  • For devices with sdk <21, simulate a "Headless JS" event with (insert <your.application.id>)
$ adb shell am broadcast -a <your.application.id>.event.BACKGROUND_FETCH

Download Details:
Author: transistorsoft
Source Code: https://github.com/transistorsoft/react-native-background-fetch
License: MIT license

#react  #reactnative  #mobileapp  #javascript 

Fannie  Zemlak

Fannie Zemlak

1599854400

What's new in the go 1.15

Go announced Go 1.15 version on 11 Aug 2020. Highlighted updates and features include Substantial improvements to the Go linker, Improved allocation for small objects at high core counts, X.509 CommonName deprecation, GOPROXY supports skipping proxies that return errors, New embedded tzdata package, Several Core Library improvements and more.

As Go promise for maintaining backward compatibility. After upgrading to the latest Go 1.15 version, almost all existing Golang applications or programs continue to compile and run as older Golang version.

#go #golang #go 1.15 #go features #go improvement #go package #go new features

Log: Simple, Configurable and Scalable Structured Logging for Go

log

Log is a simple, highly configurable, Structured Logging library

Why another logging library?

There's allot of great stuff out there, but also thought a log library could be made more configurable using per handler log levels.

Features

  •  Logger is simple, only logic to create the log entry and send it off to the handlers and they take it from there.
  •  Ability to specify which log levels get sent to each handler
  •  Built-in console, syslog, http, HipChat, json and email handlers
  •  Handlers are simple to write + easy to register + easy to remove
  •  Default logger for quick prototyping and cli applications. It is automatically removed when you register one of your own.
  •  Logger is a singleton ( one of the few instances a singleton is desired ) so the root package registers which handlers are used and any libraries just follow suit.
  •  Convenient context helpers GetContext & SetContext
  •  Works with go-playground/errors extracting types and tags when used with WithError, is the default
  •  Works with pkg/errors when used with WithError, must set using SetWithErrFn
  •  Works with segmentio/errors-go extracting types and tags when used with WithError, must set using SetWithErrFn

Installation

Use go get

go get -u github.com/go-playground/log/v7

Usage

import the log package, it is recommended to set up at least one handler, but there is a default console logger.

package main

import (
    "errors"

    "github.com/go-playground/log/v7"
    "github.com/go-playground/log/v7/handlers/console"
)

func main() {
    // There is a default logger with the same settings
    // once any other logger is registered the default logger is removed.
    cLog := console.New(true)
    log.AddHandler(cLog, log.AllLevels...)

    // Trace
    defer log.WithTrace().Info("time to run")

    log.Debug("debug")
    log.Info("info")
    log.Notice("notice")
    log.Warn("warn")
    log.Error("error")
    // log.Panic("panic") // this will panic
    log.Alert("alert")
    // log.Fatal("fatal") // this will call os.Exit(1)

    err := errors.New("the is an error")
    // logging with fields can be used with any of the above
    log.WithError(err).WithFields(log.F("key", "value")).Info("test info")

    // predefined global fields
    log.WithDefaultFields(log.Fields{
        {"program", "test"},
        {"version", "0.1.3"},
    }...)

    log.WithField("key", "value").Info("testing default fields")

    // or request scoped default fields
    logger := log.WithFields(
        log.F("request", "req"),
        log.F("scoped", "sco"),
    )

    logger.WithField("key", "value").Info("test")
}

Adding your own Handler

package main

import (
    "bytes"
    "fmt"

    "github.com/go-playground/log/v7"
)

// CustomHandler is your custom handler
type CustomHandler struct {
    // whatever properties you need
}

// Log accepts log entries to be processed
func (c *CustomHandler) Log(e log.Entry) {

    // below prints to os.Stderr but could marshal to JSON
    // and send to central logging server
    //                                                                                               ---------
    //                                                                                  |----------> | console |
    //                                                                               |             ---------
    // i.e. -----------------               -----------------     Unmarshal    -------------       --------
    //     | app log handler | -- json --> | central log app | --    to    -> | log handler | --> | syslog |
    //      -----------------               -----------------       Entry      -------------       --------
    //                                                                               |             ---------
    //                                                                               |----------> | DataDog |
    //                                                                                             ---------
    b := new(bytes.Buffer)
    b.Reset()
    b.WriteString(e.Message)

    for _, f := range e.Fields {
        fmt.Fprintf(b, " %s=%v", f.Key, f.Value)
    }
    fmt.Println(b.String())
}

func main() {

    cLog := new(CustomHandler)

    log.AddHandler(cLog, log.AllLevels...)

    // Trace
    defer log.WithTrace().Info("took this long")

    log.Debug("debug")
    log.Info("info")
    log.Notice("notice")
    log.Warn("warn")
    log.Error("error")
    // log.Panic("panic") // this will panic
    log.Alert("alert")
    // log.Fatal("fatal") // this will call os.Exit(1)

    // logging with fields can be used with any of the above
    log.WithField("key", "value").Info("test info")
}

Log Level Definitions

DebugLevel - Info useful to developers for debugging the application, not useful during operations.

InfoLevel - Normal operational messages - may be harvested for reporting, measuring throughput, etc. - no action required.

NoticeLevel - Normal but significant condition. Events that are unusual but not error conditions - might be summarized in an email to developers or admins to spot potential problems - no immediate action required.

WarnLevel - Warning messages, not an error, but indication that an error will occur if action is not taken, e.g. file system 85% full - each item must be resolved within a given time.

ErrorLevel - Non-urgent failures, these should be relayed to developers or admins; each item must be resolved within a given time.

PanicLevel - A "panic" condition usually affecting multiple apps/servers/sites. At this level it would usually notify all tech staff on call.

AlertLevel - Action must be taken immediately. Should be corrected immediately, therefore notify staff who can fix the problem. An example would be the loss of a primary ISP connection.

FatalLevel - Should be corrected immediately, but indicates failure in a primary system, an example is a loss of a backup ISP connection. ( same as SYSLOG CRITICAL )

Handlers

Pull requests for new handlers are welcome, please provide test coverage is all I ask.

HandlerDescriptionDocs
consoleAllows for log messages to be sent to a any writer, default os.StderrGoDoc
syslogAllows for log messages to be sent via syslog, includes TLS support.GoDoc
httpAllows for log messages to be sent via http. Can use the HTTP handler as a base for creating other handlers requiring http transmission.GoDoc
emailAllows for log messages to be sent via email.GoDoc
hipchatAllows for log messages to be sent to a hipchat room.GoDoc
jsonAllows for log messages to be sent to any wrtier in json format.GoDoc

Package Versioning

I'm jumping on the vendoring bandwagon, you should vendor this package as I will not be creating different version with gopkg.in like allot of my other libraries.

Why? because my time is spread pretty thin maintaining all of the libraries I have + LIFE, it is so freeing not to worry about it and will help me keep pouring out bigger and better things for you the community.

Benchmarks

Run on Macbook Pro 15-inch 2017 using go version go1.9.4 darwin/amd64

NOTE: only putting benchmarks at others request, by no means does the number of allocations make one log library better than another!

go test --bench=. -benchmem=true
goos: darwin
goarch: amd64
pkg: github.com/go-playground/log/benchmarks
BenchmarkLogConsoleTenFieldsParallel-8           2000000               946 ns/op            1376 B/op         16 allocs/op
BenchmarkLogConsoleSimpleParallel-8              5000000               296 ns/op             200 B/op          4 allocs/op

Special Thanks

Special thanks to the following libraries that inspired

  • logrus - Structured, pluggable logging for Go.
  • apex log - Structured logging package for Go.

Author: Go-playground
Source Code: https://github.com/go-playground/log 
License: MIT License

#go #golang #logger #logging 

Go-log: A Golang Log Lib Supports Level and Multi Handlers

go-log

a golang log lib supports level and multi handlers

Use

import "github.com/siddontang/go-log/log"

//log with different level
log.Info("hello world")
log.Error("hello world")

//create a logger with specified handler
h := NewStreamHandler(os.Stdout)
l := log.NewDefault(h)
l.Info("hello world")

go-doc

GoDoc

Author: Siddontang
Source Code: https://github.com/siddontang/go-log 
License: MIT License

#go #golang #logger #logging