VMware Aria Operations for Logs

VMware Aria Operations for Logs

VMware Aria Operations for Logs REST API provides programmatic access to Operations for Logs and to the data it collects. You use the API to insert events into the Operations for Logs data store and to query for those events. Manage the lifecycle of a Operations for Logs cluster, including initial or ongoing configuration and upgrades.

Use HTTPS on port 9543 with JSON payloads for all API requests.

Note: We are rebranding and some text might still contain the former name (vRealize Log Insight).

Ingesting Events

Ingest and index new log events via POST /api/v2/events/ingest/{UUID}. This is a non-authenticated interface designed for use by collection agents. Submit 1-500 events together in a single batch.

For example, we can ingest a single message:

curl -k -X POST https://loginsight.example.com:9543/api/v2/events/ingest/aexample-uuid-4b7a-8b09-fbfac4b46fd9 -d '{"events":[{"text":"Test Event"}]}'
{
  "status":"ok",
  "message":"events ingested",
  "ingested":1
}

Authorization

Most Operations for Logs APIs require authentication. Your application uses /api/v2/sessions to authenticate with Operations for Logs and obtain a session ID. The Session ID is a opaque bearer token valid for a limited time, indicated by the ttl value in the response.

For example, we can authenticate using the Local admin account.

curl -k -X POST https://loginsight.example.com:9543/api/v2/sessions -d '{"username":"admin", "password":"Secret!", "provider":"Local"}'
{
  "userId":"3c1b81cc-418e-44c0-b91a-54e10a87b1d3",
  "sessionId":"1234abcd-opaque-bearer-token-abcdlS7QF2hkqVho==",
  "ttl":1800
}

The Session ID is a opaque bearer token valid for a limited time, indicated by the ttl value in the response.

Your application passes that session ID in the Authorization header of subsequent requests.

curl -k https://loginsight.example.com:9543/api/v2/sessions/current --header "Authorization: Bearer 1234abcd-opaque-bearer-token-abcdlS7QF2hkqVho=="
{
  "userId":"3c1b81cc-418e-44c0-b91a-54e10a87b1d3"
}

In case of using self-signed certificate REST API requests to the 9543 port might fail because the browser doesn’t trust the certificate by default. In order to unblock REST API calls modify the following URL to contain the Operations for Logs hostname: GET /api/v2/sessions/current, open it in a separate tab in the browser and follow the browser instructions to accept the self-signed certificate.

Querying

Log events ingested by Operations for Logs can be searched to return individual events, or can be used to compute aggregations (numeric sequences) from a large collection of events. The two query forms are analogous to the bottom and top halves of the Interactive Analytics user interface.

  • Retrieve raw log messages via GET /api/v2/events.
  • Produce an numeric sequence via GET /api/v2/aggregated-events. Common aggregation functions (COUNT, UCOUNT, AVG, MIN, MAX, SUM, STDDEV, VARIANCE, SAMPLE) can be used on both static and dynamic fields.

Constrain requests for log events to those required for your usecase. Queries can be constrained with static fields and/or extracted fields defined by content packs. Pass constraints within the URL, similar to GET /api/v2/events/constraint1/constraint2/

For example, we can query for events where the text field contains Test in the last 6 minutes. Pass the session ID we got earlier in the Authorization header. We get back a list including the test event we ingested earlier, along with a list of metadata fields.

curl -k https://loginsight.example.com:9543/api/v2/events/text/CONTAINS%20Test/timestamp/LAST%20360000 --header "Authorization: Bearer 1234abcd-opaque-bearer-token-abcdlS7QF2hkqVho=="
{
  "complete":true,
  "duration":11,
  "events":[
    {
      "text":"Test Event",
      "timestamp":1505106771135,
      "fields":[
        {"name":"source","content":"10.11.12.13"},
        {"name":"event_type","content":"v4_d0382720"}
      ]
    }
  ]
}

Defaults

Default values are set for simple & fast queries, but can be altered per-request.

  • Queries are limited to 100 events or bins by default. You can raise that limit up to 20,000 events or 2,000 bins using the limit query parameter.
  • Queries complete execution within 30 seconds by default. If the query cannot complete within that time, partial results are returned. You can raise the timeout to a higher value using the timeout query parameter.
  • Queries are limited to events with a timestamp of one minute ago or newer. You can specify a longer time range with a timestamp constraint.