Send Telemetry Data

Spring task to schedule the task and execute the task.

Job to send data once per day:

• Data fields to send

  tbProduct (ShibUI) (can be changed via ENVAR to avoid junk data)

  tbProductVersion (release version)

  tbMaintainer (Internet2)

  ?features?

  ?container?

  memorySettings (heap, etc)

  authMechanism (default / pac4j)

  numberOfMetadataSources

  numberOfMetadataProviders

  numberOfFilters

  dailyLogins

Technical Spec:
 
Properties:

• Rename shibui.beacon-enabled to shibui.beacon.enabled
• Add property shibui.beacon.url = http://collector.testbed.tier.internet2.edu:5001 (if possible, also handle list value?)
• Add property shibui.beacon.send.cron, but default blank. This should handle a cron format string, but a blank value means a random time between 12am and 4am (Eastern time?)
• Add property shibui.beacon.installationID, but leave it blank.
• Add property shibui.beacon.productName, value is ShibUI (can be set to a different name for isolation of unit testing)

There is an existing package, edu.internet2.tap.beacon, that was set up for the beacon. But the java classes worked using environment variables, which were never defined, so the beacon was probably never used. Nevertheless, we can at least reuse the package name, and any code that might be useful.

The json object can probably be just a pojo, with no need for a telemetry library.

Sample payload:

{

    "msgType": "TIERBEACON",

    "msgName": "TIER",

    "msgVersion": "1.0",

    "tbProduct": "ShibUI (shibui.beacon.productName)",

    "tbProductVersion": "1.17.4 (can we get this from the app?)",

    "tbTIERRelease": Environment variable "TIERVERSION" if defined, otherwise "NON_PACKAGE",

    "tbMaintainer": "Unicon",

    "shibui": {

        "authMechanisms": [

            "pac4j-saml"

        ],

        "databaseType": "postgres",

        "numberOfMetadataSources": 25,

        "numberOfMetadataProviders": 3,

        "numberOfFilters": 0,

        "dailyLogins": 12,

        "numberOfGroups": 15,

        "numberOfRoles": 5,

        "installationID": "4813c762-4a90-40a2-9c01-81bf67647da4"

    }

}   

The installationID will be generated by the first process to connect to the database. There needs to be a table or column to store the installationID in, and if a process sees there is no value, it will put a lock on the table and generate one. The other processes should wait until the lock is released, and then retrieve the value. If there is a configuration value for shibui.beacon.installationID, use that value instead of a random uuid.

Unless shibui.beacon.send.cron is set, the time should be set to a random time between 12am and 4pm. I presume Eastern time until I can confirm. This can also be set at init time, along with generating the installationID.

If there are multiple ShibUI processes hitting the same database, only one of them should be sending the beacon daily.  That probably means a table storing the last send time, so that all processes can check when it was last sent. One process should check whether it was last sent 20-24 hours ago, put a lock if so, then send the beacon and update the timestamp.