ArcGIS Monitor User authentication logs

[Timothy]

Hi,
We have referenced How To: Access and Export ArcGIS Monitor Server Logs and identified our ArcGIS Monitor User authentication logs (at DEBUG level).

Our security team are now trying to have them ingested into Splunk however cannot configure an appropriate connector.

• Is there any avenues to change the logging location to postgres or a file on the system that's not SQL?
• Can the new API for ArcGIS Monitor obtain these logs?
• What is the default connection settings for the sqllite database (user, pw, port) and does it have an active listening connector?

We can install other third party apps and script up file exports but don't believe that this should be the first step when you might have a solution to the above that can easily resolve the issue.

Many thanks
Tim

[GeoJosh]

Hi @Timothy,

Is there any avenues to change the logging location to postgres or a file on the system that's not SQL?

This is not possible at the current release. If you'd like to see this feature, please submit it as an idea.

Can the new API for ArcGIS Monitor obtain these logs?

Yes, but it's important to keep in mind that the API is currently in beta and is not documented. Here's a quick example of how to query logs:

POST /arcgis/admin/logs/query HTTP/1.1
Host: monitorserver.domain.com:30080
Content-Type: application/json
Authorization: Bearer <accessToken>

{
    "where": "1=1"
}

What is the default connection settings for the sqllite database (user, pw, port) and does it have an active listening connector?

ArcGIS Monitor records logs in a SQLite database which is stored on the file system. There is no username, password, or port used to connect.

Josh

[Timothy]

Thanks Josh

POST request to https://server.hostname/arcgis/admin/logs/query with a body of {“where”: “1=1”} is printing the whole log. We appear to be getting "exceededTransferLimit":true at 10,000 events.

We have a way to extract and compare timestamps after ingesting so is there any way to remove this API call limit.

Alternatively a better option would be to send parameters in the body like {“where”: “timestamp > (now(epoch) – 1day)”}  the actual request for example {“where”: “timestamp > 1715833881000”}. Do you know if this is supported for this API?

Cheers