{"id":619,"date":"2017-11-12T18:05:09","date_gmt":"2017-11-12T18:05:09","guid":{"rendered":"https:\/\/projects.lsv.ens-paris-saclay.fr\/orchidsdoc\/?page_id=619"},"modified":"2017-12-08T10:51:05","modified_gmt":"2017-12-08T10:51:05","slug":"the-json-module","status":"publish","type":"page","link":"https:\/\/projects.lsv.ens-paris-saclay.fr\/orchidsdoc\/?page_id=619","title":{"rendered":"The json module"},"content":{"rendered":"

The json<\/code> module is a dissection module<\/a>: its purpose is to take an Orchids event, parse its last field (which should be a text string, of type str<\/code>), which should be in JSON<\/a> format, and return a refined Orchids events, with additional fields.<\/p>\n

JSON means JavaScript Object Notation, and has become a popular alternative to XML for describing objects, possibly nested.\u00a0 The Linux journalctl<\/code> utility, for example, has a native JSON export format.<\/p>\n

The json<\/code> module is still in a preliminary version. Its intended use is to parse data embedded in, say, the .syslog.msg<\/code>\u00a0field of an event already dissected once by the syslog<\/code><\/a> module.\u00a0\u00a0 For example, if you know that messages reported by syslog<\/code><\/a> is in JSON format when the .syslog.prog<\/code> field equals js_reporter<\/code> (that name is merely for the sake of the example), then you would write something like the following in $OCONF\/orchids-inputs.conf<\/code><\/a>, assuming syslog<\/code><\/a> data comes from the textfile<\/code><\/a> module from file blah.log<\/code>:<\/p>\n

INPUT\t\ttextfile\t\"blah.log\"\r\nDISSECT syslog\ttextfile\t\"blah.log\"\r\nDISSECT json    syslog\t\tjs_reporter\r\n<\/pre>\n
Configuration options<\/h3>\n
None (yet).<\/p>\n
Fields<\/h3>\n
The fields provided by the json<\/code> module are of a somewhat peculiar nature.\u00a0 Most other modules document a fixed set of fields.\u00a0 The json<\/code> module has fields that may vary dynamically as events are obtained.\u00a0 To accomodate for this dynamicity, all those run-time fields are collected in one single static field, .json.fields<\/code>, which is an array<\/a> mapping the names of the dynamic fields to their values.\u00a0 This will be clearer with examples, to be given below.\u00a0 We shall also explain the role of the .json.remainder<\/code> field below.<\/p>\n\n\n\n\n\n\n
Field<\/th>\nType<\/a><\/th>\nMono<\/a>?<\/th>\nDescription<\/th>\n<\/tr>\n<\/tbody>\n
.json.remainder<\/code><\/td>\nstr<\/code><\/td>\n<\/td>\nrest of message<\/td>\n<\/tr>\n
.json.fields<\/code><\/td>\n[str<\/code><\/td>\n<\/td>\narray of dynamic fields<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
(The type [str<\/code> means array of strings. An array can be indexed by any basic type. Here the indices will be strings as well.)<\/p>\n
We start with a simple example.\u00a0 Imagine the following text, in JSON format:<\/p>\n
{\"syslog_time\":\"2017-05-03T20:41:14.342405+02:00\",\"syslog_host\":\"darkstar\",\"process_id\":\"237\",\"path\":\"\/tmp\/exploit\"}<\/pre>\n
The json<\/code> module will dissect that by letting .json.fields<\/code> be the array that maps:<\/p>\n