Differences

This shows you the differences between two versions of the page.

--- public:fticks [2021/04/28 12:22] – admin
+++ public:fticks [2024/05/16 08:31] (current) – admin
@@ Line 3: / Line 3: @@
 The Jisc NRPS keep a log of successful roams between organisation connected to them. However, about 90% of roams happen within Federations so this data is not visible. To gain a complete picture of roaming Federations need to send their own roaming information to a central point.
-The mechanism for accomplishing this is Syslog, a standard (RFC 5424) approach for logging information to centralised repositories. Jisc uses ELK (Elasticsearch, Logstash and Kibana) to handle, process and display roaming data.
+The mechanism for accomplishing this is Syslog, a standard (RFC 5424) approach for logging information to centralised repositories. Jisc uses a combination of syslog-ng, loki, mysql and grafana to handle, process and display roaming data.
-For doing a similar task within eduroam GEANT devised a standard syslog message body format and called it FTICKS. The requirements relevant here were:
+For doing a similar task within eduroam, GEANT devised a standard syslog message body format and called it FTICKS. The requirements relevant here were:
 . Allow receipt of statistics events in a decentralised manner (i.e. from arbitrary, but legitimate sources).
@@ Line 33: / Line 33: @@
 </code>
-# as a field separate makes sense because it doesn't appear in realms for the Calling-Station-Id.
+# as a field separate makes sense because it doesn't appear in realms or the Calling-Station-Id.
 This format can easily be machine parsed by the aforementioned tools.
-The REALM field contains the realm of the user in the form '@holby.nhs.uk' and the CSI contains the Calling Station ID of the device making the authentication request (the user's device). More on the CSI later.
+The REALM field contains the realm extracted from the username in the form 'holby.nhs.uk' and the CSI contains the Calling Station ID of the device making the authentication request (the user's device). More on the CSI later.
 VISINT is the identity of the organisation sending the authetication request. Ideally this should be the Operator-Name of the site from which the Visitor is making their request. e.g. '1localgp.holby.nhs.uk' but the RFO should insert the originating site's identity if the originating site is unable to do so themselves. The least desirable default option is for the RFO to insert their own Operator-Name as a last resort e.g. '1holby.nhs.uk'.
@@ Line 55: / Line 55: @@
 [[siteadmin:syslog_f-ticks_logging|Configuration fragments for syslog-ng]] are available but other syslog software, such as rsyslog, are just as capable.
-====Windows Syslog====
-Windows doesn't have syslog in-built in the same way as linux so requires extra tools, such as Filebeat. [[siteadmin:filebeat_for_windows_configuration|Filebeat processes windows logs]] and sends data in the form of XML to Logstash which then processes the logs in the same way as the FTICKS above.
 ====FTICKS configuration====
-There a configuration fragments for [[siteadmin:basic_orps_radsecproxy_configuration|RadSecProxy]], [[siteadmin:basic_freeradius_orps_configuration|FreeRADIUS]] and [[siteadmin:fticks_logging_for_radiator|RADIATOR]].
+There are configuration fragments for [[siteadmin:basic_orps_radsecproxy_configuration|RadSecProxy]], [[siteadmin:basic_freeradius_orps_configuration|FreeRADIUS]] and [[siteadmin:fticks_logging_for_radiator|RADIATOR]].