Real-time Logs

Background

To help minigame developers quickly troubleshoot bugs and locate issues, we have launched the real-time log feature. Developers can print logs through the provided interfaces; the logs are aggregated and reported to the minigame backend in real time. Developers can enter the minigame-side log query page from the minigame management backend via "WE Analytics -> Performance Quality -> Real-time Logs," or enter the plugin-side log query page via "Minigame Plugins -> Real-time Logs," to view the log information printed by the developer.

How to Use

Minigame Side

1. Call the relevant interface. The interface for printing logs is sud.getRealtimeLogManager. To be compatible with older versions, it is recommended to wrap it with the following code, for example in a log.js file:

var log = sud.getRealtimeLogManager ? sud.getRealtimeLogManager() : null

module.exports = {
  debug() {
    if (!log) return
    log.debug.apply(log, arguments)
  },
  info() {
    if (!log) return
    log.info.apply(log, arguments)
  },
  warn() {
    if (!log) return
    log.warn.apply(log, arguments)
  },
  error() {
    if (!log) return
    log.error.apply(log, arguments)
  },
  setFilterMsg(msg) { 
    if (!log || !log.setFilterMsg) return
    if (typeof msg !== 'string') return
    log.setFilterMsg(msg)
  },
  addFilterMsg(msg) { 
    if (!log || !log.addFilterMsg) return
    if (typeof msg !== 'string') return
    log.addFilterMsg(msg)
  }
}

1. Print logs at specific locations on the page:

var log = require('./log.js') // Reference the log.js file above
log.info('hellopink test ') // Logs are associated with the currently open page; it is recommended to print them in lifecycle hooks such as the page's onHide and onShow
log.warn('warn')
log.error('error')
log.setFilterMsg('filterkeyword')
log.addFilterMsg('addfilterkeyword')

Plugin Side

To make logs more structured for more complex analysis later, the plugin side adopts a newly designed format.

1. Call the relevant interface sud.getRealtimeLogManager to get a real-time log manager instance:

const logManager = sud.getRealtimeLogManager()

1. In the logic where you need to print logs, get a log instance:

// The tag name can be any string; one tag name corresponds to a group of logs. The same tag name can be reused; logs with the same tag name are aggregated under one tag in the backend
// Tags can classify logs, so it is recommended that developers divide tags according to logic
const logger = logManager.tag('plugin-onUserTapSth')

1. Print logs at appropriate locations:

logger.info('key1', 'value1') // Each log is a key-value pair; the key must be a string, and the value can be a serializable type such as a string/number/object/array
logger.error('key2', {str: 'value2'})
logger.warn('key3', 'value3')
logger.setFilterMsg('filterkeyword') // Consistent with the minigame-side interface
logger.setFilterMsg('addfilterkeyword') // Consistent with the minigame-side interface

How to View Logs

Log in to the OpenPaaS management backend and enter the log query page via "Development - Minigame Plugins -> Real-time Logs." Developers can query the log information of specific users by setting filter conditions such as time, OpenID, page URL, and FilterMsg content (if it is a real-time log reported by a plugin).

Notes

Due to backend resource limitations, the "Real-time Logs" usage rules are as follows:

1. To facilitate issue location, logs are divided by page. Logs printed within a certain period of time on a page (as short as 5 seconds, as long as the interval from when the page is shown to when it is hidden) are aggregated into a single log for reporting, and this log can be searched by page path in the minigame management backend.
2. Each minigame account is limited to 10 million logs per day, and logs are retained for 7 days. It is recommended to locate issues promptly when they occur.
3. The upper limit of a single log is 5KB, containing at most 200 log-printing function calls (info, warn, and error calls all count), so print logs cautiously. Avoid calling the log-printing interface inside loops, and avoid printing logs by directly overriding console.log.
4. For logs in feedback, you can search logs by OpenID.
5. setFilterMsg and addFilterMsg can set filter fields similar to log tags. To add multiple keywords, it is recommended to use addFilterMsg. For example addFilterMsg('scene1'), addFilterMsg('scene2'), addFilterMsg('scene3'). After setting them, you can freely combine the three keywords for retrieval in the OpenPaaS management backend, such as "scene1 scene2 scene3", "scene1 scene2", "scene1 scene3", or "scene2" (separated by spaces, so addFilterMsg cannot contain spaces). All of these retrieval methods can find this log; the more conditions, the more precise.
6. Currently, to facilitate log analysis, plugin-side real-time logs only support the key-value format.
7. Real-time logs are currently only supported for testing on mobile devices. The interfaces on the tool side can be called but will not be reported to the backend.