Govroam

The Roaming solution for the public sector

User Tools

Site Tools


public:fticks

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
public:fticks [2024/05/15 10:31] – [Windows Syslog] adminpublic: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 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 (ElasticsearchLogstash 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-ngloki, 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 eduroamGEANT devised a standard syslog message body format and called it FTICKS. The requirements relevant here were:
  
 1. Allow receipt of statistics events in a decentralised manner (i.e. from arbitrary, but legitimate sources). 1. Allow receipt of statistics events in a decentralised manner (i.e. from arbitrary, but legitimate sources).
Line 33: Line 33:
 </code> </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. 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'. 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'.
public/fticks.1715769098.txt.gz · Last modified: 2024/05/15 10:31 by admin