Understanding the Log Data Collected by Sitch¶

The following sections describe the data for the files found in ‘/data/sitch/log/’.

cells.log¶

{"scan_results": [
  {"cgi_str": "310:260:275:20000",
   "site_name": "sitch-site-testing",
   "bsic": "16",
   "mcc": "310",
   "rla": 0,
   "lac": "275",
   "band": "ALL_BAND",
   "feed_info": {
     "mcc": "310",
     "lon": "-122.464146",
     "lac": "275",
     "range": 325,
     "lat": "37.776641",
     "mnc": "260",
     "cellid": "20082"},
   "scan_location": "sitch-site-testing",
   "mnc": "260",
   "txp": 03,
   "distance": 534.3820159387475,
   "scan_finish": "2017-05-06T06:25:49.837957",
   "rxl": 20.0,
   "cell": 0,
   "scanner_public_ip": "1.1.1.1",
   "rxq": 0.0,
   "ta": 255,
   "cellid": "20082",
   "cgi_int": 31026027520082,
   "arfcn": 684}
   ...],
  "band": "ALL_BAND",
  "site_name": "sitch-site-testing",
  "platform": "Unspecified",
  "scan_start": "",
  "scan_location": "sitch-site-testing",
  "scanner_public_ip": "1.1.1.1",
  "scan_finish": "2017-05-06T06:25:49.837957",
  "scan_program": "gsm_modem"
  "event_timestamp": "2017-05-06T06:25:49.837957"}

<cell>¶

possible values	description
0	The serving cell
1-6	The index of the neighboring cell

<arfcn>¶

[Absolute radio frequency channel number](https://en.wikipedia.org/wiki/Absolute_radio-frequency_channel_number)

<rxl>¶

Receive level

The measured signal level shall be mapped to an RXLEV value between 0 and 63, as follows:

possible values	description
0	less than -110 dBm.
1	-110 dBm to -109 dBm.
2	-109 dBm to -108 dBm.
…
…
62	-49 dBm to -48 dBm.
63	greater than -48 dBm.

<rxq>¶

Receive quality

possible values	description
0…7	as [RXQUAL](https://en.wikipedia.org/wiki/Rxqual) values
99	not known or not detectable

NOTE: In a 7-item line, cellid is not provided. We set it to 0 to prevent barfing elsewhere.

<lac>¶

[Location area code](http://www.telecomabc.com/l/lac.html)

<rla>¶

Receive level access minimum

GUESS: Minimum receiving level permitted to access the system Per: similar AT engineering mode (AT+QENG) command in [M95 AT commands manual](http://eddywireless.com/yahoo_site_admin/assets/docs/M95_AT_Commands_Manual_V12.196112248.pdf)

<txp>¶

Transmit power maximum CCCH

<TA>¶

[Timing Advance](https://en.wikipedia.org/wiki/Timing_advance)

geoip.log¶

{"geometry":
  {"type": "Point",
   "coordinates": [-122, 37]
   },
 "scan_program": "geo_ip",
 "type": "Feature",
 "event_timestamp": "2017-05-06T06:25:49.837957"}

This is in geojson structure, with the addition of an event_timestamp field.

gps.log¶

{"sat_time": "2017-05-02T06:26:08.000Z",
 "geometry": {
   "type": "Point",
   "coordinates":
     [-122, 37]
     },
 "time_drift": 0.006355733333333334,
 "sys_time": "2017-05-02T06:26:08.381344",
 "scan_program": "gpsd",
 "type": "Feature"
 "event_timestamp": "2017-05-06T06:25:49.837957"}

gsm_modem_channel.log¶

{"cgi_str": "310:260:275:20082",
"site_name": "sitch-site-testing",
"bsic": "16",
"mcc": "310",
"rla": 8,
"lac": "275",
"band": "ALL_BAND",
"feed_info": {
    "mcc": "310",
    "lon": "-122.123",
    "lac": "275",
    "range": 325,
    "lat": "37.123",
    "mnc": "260",
    "cellid": "20082"
    },
"scan_location": "sitch-site-testing",
"mnc": "260",
"txp": 3,
"distance": 568.12345,
"scan_finish": "2017-05-16T02:21:23.901298",
"event_timestamp": "2017-05-16T02:21:23.901298",
"rxl": 24.0,
"cell": 0,
"scanner_public_ip": "1.1.1.1",
"rxq": 0.0,
"ta": 255,
"cellid": "20082",
"cgi_int": 31026027520082,
"arfcn": 684}

<cell>¶

possible values	description
0	The serving cell
1-6	The index of the neighboring cell

<arfcn>¶

[Absolute radio frequency channel number](https://en.wikipedia.org/wiki/Absolute_radio-frequency_channel_number)

<rxl>¶

Receive level

The measured signal level shall be mapped to an RXLEV value between 0 and 63, as follows:

possible values	description
0	less than -110 dBm.
1	-110 dBm to -109 dBm.
2	-109 dBm to -108 dBm.
…
…
62	-49 dBm to -48 dBm.
63	greater than -48 dBm.

<rxq>¶

Receive quality

possible values	description
0…7	as [RXQUAL](https://en.wikipedia.org/wiki/Rxqual) values
99	not known or not detectable

<mcc>¶

[Mobile country code](https://en.wikipedia.org/wiki/Mobile_country_code)

<mnc>¶

[Mobile network code](https://en.wikipedia.org/wiki/Mobile_country_code)

<bsic>¶

[Base station identity code](https://en.wikipedia.org/wiki/Base_station_identity_code)

<cellid>¶

[Cell id](https://en.wikipedia.org/wiki/Cell_ID)

NOTE: In a 7-item line, cellid is not provided. We set it to 0 to prevent barfing elsewhere.

<lac>¶

[Location area code](http://www.telecomabc.com/l/lac.html)

<rla>¶

Receive level access minimum

GUESS: Minimum receiving level permitted to access the system Per: similar AT engineering mode (AT+QENG) command in [M95 AT commands manual](http://eddywireless.com/yahoo_site_admin/assets/docs/M95_AT_Commands_Manual_V12.196112248.pdf)

<txp>¶

Transmit power maximum CCCH

<TA>¶

[Timing Advance](https://en.wikipedia.org/wiki/Timing_advance)

health_check.log¶

{"cpu_times":
  {"iowait": 4694.23,
   "idle": 3089452.32,
   "user": 1786751.62,
   "system": 125489.34},
 "data_vol": 5.5,
 "root_vol": 5.5,
 "cpu_percent": [42.0, 53.0, 35.9, 38.0],
 "mem":
   {"swap_percent_used": 0.0,
    "free": 464707584},
 "queue_sizes": {
   "arfcn_correlator": 0,
   "geo_correlator": 0,
   "scan_results": 0,
   "cgi_correlator": 0},
 "application_uptime_seconds": 32461,
 "event_timestamp": "2017-05-07T06:32:09.816725",
 "scan_program": "health_check"}

The frequency with which these events are generated is determined by the HEALTH_CHECK_INTERVAL environment variable.

How is this information useful?

If you notice a trend where a metric under “queue_sizes” is always-increasing, you may have a failed processing thread. Correlate this with the events coming from heartbeat.log. Look for the absence of a heartbeat event for the corresponding thread). If you’ve confirmed that a thread has failed, the fastest fix is to just restart the sensor. If you can get a traceback for the thread failure, please submit it as an issue at https://github.com/sitch-io/sensor/issues/new.

heartbeat.log¶

{"heartbeat_service_name": "MainThread", "event_timestamp": "2017-05-07T06:32:09.815061", "scan_program": "heartbeat"}
{"heartbeat_service_name": "kalibrate_consumer", "event_timestamp": "2017-05-07T06:32:09.815243", "scan_program": "heartbeat"}
{"heartbeat_service_name": "arfcn_correlator", "event_timestamp": "2017-05-07T06:32:09.815323", "scan_program": "heartbeat"}
{"heartbeat_service_name": "decomposer", "event_timestamp": "2017-05-07T06:32:09.815391", "scan_program": "heartbeat"}
{"heartbeat_service_name": "gsm_modem_consumer", "event_timestamp": "2017-05-07T06:32:09.815456", "scan_program": "heartbeat"}
{"heartbeat_service_name": "geoip_consumer", "event_timestamp": "2017-05-07T06:32:09.815520", "scan_program": "heartbeat"}
{"heartbeat_service_name": "writer", "event_timestamp": "2017-05-07T06:32:09.815584", "scan_program": "heartbeat"}
{"heartbeat_service_name": "geo_correlator", "event_timestamp": "2017-05-07T06:32:09.815648", "scan_program": "heartbeat"}
{"heartbeat_service_name": "gps_consumer", "event_timestamp": "2017-05-07T06:32:09.815711", "scan_program": "heartbeat"}
{"heartbeat_service_name": "cgi_correlator", "event_timestamp": "2017-05-07T06:32:09.815780", "scan_program": "heartbeat"}

These events are most useful when chasing down thread failure. It doesn’t happen often, but when it does, you can look at these events as a time-series and see where one ceases to appear. This is most useful when correlated with queue sizes as reflected in health_check.log.

kal_channel.log¶

{"site_name": "sitch-site-testing",
 "power": 854930.16,
 "final_freq": "874979084",
 "band": "GSM-850",
 "scan_finish": "2017-05-07T06:28:38.545421",
 "event_timestamp": "2017-05-07T06:28:38.545421",
 "sample_rate": "270833.002142",
 "gain": "80.0",
 "scanner_public_ip": "1.1.1.1",
 "scan_start": "2017-05-07T06:23:39.482440",
 "scan_program": "kalibrate",
 "arfcn_int": 157,
 "channel": "157"}

scanner.log¶

{"site_name": "sitch-site-testing",
 "scan_results": [
 {"channel_detect_threshold": "105949.217083",
  "power": "854930.16",
  "final_freq": "874979084",
  "mod_freq": 20916.0,
  "band": "GSM-850",
  "sample_rate": "270833.002142",
  "gain": "80.0",
  "base_freq": 875000000.0,
  "device": "0: Generic RTL2832U OEM",
  "modifier": "-",
  "channel": "157"}
  ],
 "platform": "Unspecified",
 "scan_start": "2017-05-07T06:23:39.482440",
 "scan_location": "sitch-site-testing",
 "scanner_public_ip": "1.1.1.1",
 "scan_finish": "2017-05-07T06:28:38.545421",
 "event_timestamp": "2017-05-07T06:28:38.545421",
 "scan_program": "kalibrate",
 "scanner_name": "sitch-site-testing"}

The list of items under scan_results is used by the Decomposer to produce messages that end up in the kal_channel log file.

sitch_alert.log¶

{"details": "Primary BTS was 310:260:275:20082 now 310:260:275:42302. Site: sitch-site-testing",
 "type": "Primary BTS metadata change.",
 "id": 110,
 "device_id": "sitch-site-testing"
 "event_timestamp": "2017-05-07T06:28:38.545421"}

details is a human-readable representation of the event, with details.
type is a human-readable description of the alert type. For a list of supported event types, look in the __init__ section of http://sensor.readthedocs.io/en/test/_modules/sitchlib/alert_manager.html#AlertManager
id is an ID that maps to a specific event type. This is meant to simplify integration with SIEM and log management systems.
device_id is the device ID (see device configuration environment vars)
event_timestamp is generated when the alert is detected.

sitch_init.log¶

{"evt_data": "T-Mobile",
 "evt_type": "registration",
 "evt_cls": "gsm_consumer",
 "event_timestamp": "2017-05-06T06:25:49.837957"}

{"evt_data": "\r\n | OK\r\n | ATV1Q0&V \r\r\n | DEFAULT PROFILE\r\n | S0: 0\r\n | S3: 13\r\n | S4: 10\r\n | S5: 8\r\n | S6: 2\r\n | S7: 60\r\n | S8: 2\r\n | S10: 15\r\n | +CRLP: 61,61,48,6\r\n | V: 1\r\n | E: 1\r\n | Q: 0\r\n | X: 4\r\n | &C: 1\r\n | &D: 1\r\n | +CLTS: 0\r\n| +CREG: 0\r\n | +CGREG: 0\r\n | +CMEE: 0\r\n | +CIURC: 1\r\n | +CFGRI: 2\r\n | +CMTE: 0\r\n | +CANT: 0,0,10\r\n | +STKPCIS: 0\r\n | +CMGF: 0\r\n | +CNMI: 2,1,0,0,0\r\n | +CSCS: \"IRA\"\r\n | +VTD: 1\r\n | +CALS: 1\r\n | +CHF: 0\r\n | +CAAS: 1\r\n | +CBUZZERRING: 0\r\n | +DDET: 0\r\n | +MORING: 0\r\n | +SVR: 16\r\n | +CCPD: 1\r\n | +CSNS: 0\r\n | +CSGS: 1\r\n | +CNETLIGHT: 1\r\n | +SLEDS: 64,64,64,800,3000,300\r\n | +CSDT: 0\r\n | +CSMINS: 0\r\n | +EXUNSOL: 0\r\n | +FSHEX: 0\r\n | +FSEXT: 0\r\n | +IPR: 0\r\n | +IFC: 0,0\r\n | +CSCLK: 0\r\n | \r\n | USER PROFILE\r\n | S0: 0\r\n | S3: 13\r\n | S4: 10\r\n | S5: 8\r\n | S6: 2\r\n | S7: 60\r\n | S8: 2\r\n | S10: 15\r\n | +CRLP: 61,61,48,6\r\n | V: 1\r\n | E: 1\r\n | Q: 0\r\n | X: 4\r\n | &C: 1\r\n | &D: 1\r\n | +CLTS: 0\r\n | +CREG: 0\r\n | +CGREG: 0\r\n | +CMEE: 0\r\n |+CIURC: 1\r\n | +CFGRI: 2\r\n | +CMTE: 0\r\n | +CANT: 0,0,10\r\n | +STKPCIS: 0\r\n | +CMGF: 0\r\n | +CNMI: 2,1,0,0,0\r\n | +CSCS: \"IRA\"\r\n | +VTD: 1\r\n | +CALS: 1\r\n | +CHF: 0\r\n | +CAAS: 1\r\n | +CBUZZERRING: 0\r\n | +DDET: 0\r\n | +MORING: 0\r\n | +SVR: 16\r\n | +CCPD: 1\r\n | +CSNS: 0\r\n | +CSGS: 1\r\n | +CNETLIGHT: 1\r\n | +SLEDS: 64,64,64,800,3000,300\r\n | +CSDT: 0\r\n | +CSMINS: 0\r\n | +EXUNSOL:0\r\n | +FSHEX: 0\r\n | +FSEXT: 0\r\n | +IPR: 0\r\n | +IFC: 0,0\r\n | +CSCLK: 0\r\n | \r\n | ACTIVE PROFILE\r\n | S0: 0\r\n | S3: 13\r\n | S4: 10\r\n | S5: 8\r\n | S6: 2\r\n | S7: 60\r\n | S8: 2\r\n | S10: 15\r\n | +CRLP: 61,61,48,6\r\n | V: 1\r\n | E: 1\r\n | Q: 0\r\n | X: 4\r\n | &C: 1\r\n | &D: 1\r\n | +CLTS: 0\r\n | +CREG: 0\r\n | +CGREG: 0\r\n | +CMEE: 0\r\n | +CIURC: 1\r\n | +CFGRI: 2\r\n | +CMTE: 0\r\n | +CANT: 0,0,10\r\n | +STKPCIS: 0\r\n | +CMGF: 0\r\n | +CNMI: 2,1,0,0,0\r\n | +CSCS: \"IRA\"\r\n | +VTD: 1\r\n | +CALS: 1\r\n | +CHF: 0\r\n | +CAAS: 1\r\n | +CBUZZERRING: 0\r\n | +DDET: 0\r\n | +MORING: 0\r\n | +SVR: 16\r\n | +CCPD: 1\r\n | +CSNS: 0\r\n | +CSGS: 1\r\n | +CNETLIGHT: 1\r\n | +SLEDS: 64,64,64,800,3000,300\r\n | +CSDT: 0\r\n | +CSMINS: 0\r\n | +EXUNSOL: 0\r\n | +FSHEX: 0\r\n | +FSEXT: 0\r\n | +IPR:0\r\n | +IFC: 0,0\r\n | +CSCLK: 0\r\n | \r\n | OK\r\n",
"evt_type": "device_config",
"evt_cls": "gsm_consumer",
"event_timestamp": "2017-05-06T06:25:49.837957"}

{"evt_data": "IMSI_GOES_HERE",
"evt_type": "sim_imsi",
"evt_cls": "gsm_consumer",
"event_timestamp": "2017-05-06T06:25:49.837957"}

These messages are only generated when the application starts.

registration records the cell service provider, according to the GSM modem.
device_config dumps the profiles in use from the GSM modem.
sim_imsi records the IMSI from your cell modem’s SIM card.

Understanding the Log Data Collected by Sitch¶

cells.log¶

<cell>¶

<arfcn>¶

<rxl>¶

<rxq>¶

<mcc>¶

<mnc>¶

<bsic>¶

<cellid>¶

<lac>¶

<rla>¶

<txp>¶

<TA>¶

geoip.log¶

gps.log¶

gsm_modem_channel.log¶

<cell>¶

<arfcn>¶

<rxl>¶

<rxq>¶

<mcc>¶

<mnc>¶

<bsic>¶

<cellid>¶

<lac>¶

<rla>¶

<txp>¶

<TA>¶

health_check.log¶

heartbeat.log¶

kal_channel.log¶

scanner.log¶

sitch_alert.log¶

sitch_init.log¶

Sitch Sensor

Navigation

Related Topics