Add userAgent for Alerts

[joe-lipson]

Requests from the aws-alerts-prod-2022 instance are coming up with a UA of Java/11.0.24

Alerts should identify itself like our other services as service/version e.g. ozcam-hub/7.1.0

[nickdos]

Added to code with config override (customUserAgent) and tested by watching the access_log for lists-test:

140.253.238.151 - - [03/Oct/2024:09:24:29 +1000] "GET /ws/speciesListInternal/dr22803 HTTP/1.1" 200 415 "-" "alerts/4.3.0-SNAPSHOT" "-" request_time=0.006 upstream_response_time=0.008 upstream_connect_time=0.004 upstream_header_time=0.008 upstream_cache_status=-

@joe-lipson - would it help to also include "ALA" in the string, so you could check for any ALA services without specifying the app names? E.g. ala-alerts/4.3.0. Or we could use qualified name au.org.ala.alerts/4.3.0.

[joe-lipson]

Added to code with config override (customUserAgent) and tested by watching the access_log for lists-test:

140.253.238.151 - - [03/Oct/2024:09:24:29 +1000] "GET /ws/speciesListInternal/dr22803 HTTP/1.1" 200 415 "-" "alerts/4.3.0-SNAPSHOT" "-" request_time=0.006 upstream_response_time=0.008 upstream_connect_time=0.004 upstream_header_time=0.008 upstream_cache_status=-

@joe-lipson - would it help to also include "ALA" in the string, so you could check for any ALA services without specifying the app names? E.g. ala-alerts/4.3.0. Or we could use qualified name au.org.ala.alerts/4.3.0.

Nice! I'm totally fine with just the alerts/[version] format which is in line with other products. ala-alerts fine too but as these are our internal services making requests just to other internal services not sure it's needed, or would there be cross LA requests where this would be useful to know it's coming from ALA alerts?

[nickdos]

@joe-lipson - I'm not sure how you'll be using these values but I thought/guessed you might want to filter all the access_logs for internal requests (or exclude them), when trying to "find stuff". So having the "ala" string might be useful??? As opposed to needing to do an ORed search for alerts OR biocache OR bie OR dashboard. I.e. setting up a filter in Elastic Search. Using the qualified name would be better, as it would avoid false positive hits - "au.org.ala" is more distinct than just "ala".

[joe-lipson]

hmm yeah that would be useful, but it's not a big hassle to OR the UAs in a query if needed, we'd need to update all our services to be ala-[service] before it would work too. I'm happy to just keep it as [service]/[version]

[nickdos]

NW. I've made this a config value, so in the future it could easily be updated, if needed. Although it would require the use of a YAML config to be able to reference the version number (properties files can't do this, AFAIK).