---
updatedAt: 2026-03-01T18:39:00.000Z
agentTools:
  siteIndex: https://techdocs.akamai.com/llms.txt
  projectIndex: https://techdocs.akamai.com/eaa/llms.txt
---

# Use EAA logs with SIEM, API, or Unified Log Streamer (ULS)

# Overview

This guide provides an overview of the different EAA data feeds generated by Enterprise Application Access (EAA) and how to consume them either using API, or with your SIEM.  It also describes the contents from each log field and explain their meanings in a dictionary of data available in the logs.

The Enterprise Application Access application has a full suite of APIs. You need to build scripts to interact with the service. You can either write your own code to interact with the service or use pre-existing tools such as our [Akamai Unified Log Streamer (ULS)](https://github.com/akamai/uls), or [EAA package for Akamai CLI](https://github.com/akamai/cli-eaa).

| EAA Log type                                                 | User Access Logs [definition](https://techdocs.akamai.com/eaa/docs/data-feed-siem#access-logs)                             | Admin Audit Logs [definition](https://techdocs.akamai.com/eaa/docs/data-feed-siem#admin-logs)                             | Connector Health [definition](https://techdocs.akamai.com/eaa/docs/data-feed-siem#connector-health)                   | Device Inventory [definition](https://techdocs.akamai.com/eaa-api/reference/get-device-posture-inventory) |
| ----------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------- |
| ​Akamai​ Log Streamer                                             | ✓                                                                            | ✓                                                                           | ✓                                                                       | ✓                                                                                            |
| CLI EAA                                                                       | ✓  Command line [example](https://github.com/akamai/cli-eaa/#eaa-event-logs) | ✓ Command line [example](https://github.com/akamai/cli-eaa/#eaa-event-logs) | ✓ Command line [example](https://github.com/akamai/cli-eaa/#connectors) | ✓ Command line [example](https://github.com/akamai/cli-eaa/#device-posture-inventory)        |
| EAA [API](https://techdocs.akamai.com/eaa-api/reference/api) |                                                                                           |                                                                                          | ✓                                                                       | ✓                                                                                            |

For using legacy EAA Splunk App for Splunk 7, see [Splunkbase](https://docs.splunk.com/Documentation/Splunk/8.0.2/Installation/Chooseyourplatform).

In case of any issues [contact support](https://www.akamai.com/global-services/support).

# Use Unified Log Streamer to integrate EAA and SIEM

You can integrate Enterprise Application Access (EAA) with any Security and Event Management (SIEM) using the Unified Log Streamer (ULS). The ULS is designed to simplify SIEM integrations for all ​Akamai​  Secure Enterprise Access Products:

* Enterprise Application Access (EAA)

* ​Enterprise Threat Protector​  (ETP)

* ​Akamai​ Multi Factor Authenticator (MFA)

The modular design of ULS allows out-of-the-box integration with many SIEM solutions such as Splunk, Graylog, or Sumologic platform.

![integration scheme](https://techdocs.akamai.com/eaa/img/ULS-v2.gif)

The ULS tool does REST API calls to ​Akamai​  Enterprise APIs and transports the data or security events which can be easily alerted by the customer's SIEM environment.

It is very flexible to deploy and operate the ULS. It can be run as a docker container or hosted standalone in your environment. It also supports the Helm deployment tool for Kubernetes, output Filter, Transformation, and Hooks, including the popular, flat "File" format. ULS can send data into any SIEM that supports either TCP, UDP or HTTP ingestion, both on-premises and cloud. Also, it is easy to get started since no coding or learning of the EAA APIs are required.

In Enterprise Application Access (EAA), we provide different data feeds like:

* EAA access logs

* EAA admin audit logs

* EAA connector health

* EAA Device Posture Inventory

You can choose any or all of these data feeds for your preferred SIEM solution.

You can find more information about the ULS open-source code on github at [ULS repository](https://github.com/akamai/uls).

You can find more information about documentation for any of the SIEM platforms at: [SIEM repository](https://github.com/akamai/uls/tree/main/docs/SIEM).

To use the ULS tool in your SIEM environment:

* You will need to [setup EAA API credentials for ULS](https://github.com/akamai/uls/blob/main/docs/AKAMAI_API_CREDENTIALS.md#eaa-open-api-for-connector-health-feed)

* Clone the binary from [github ULS repository](https://github.com/akamai/uls). Host it either as a Docker container or as a standalone binary on a host machine running Linux, macOS (Intel CPU).

  > 🚧
  >
  > Windows OS is not supported.

* Configure any of the different feeds that you want to observe in your SIEM platform and obtain alerts for.

# EAA Data feed adopted by SIEM solutions

Here you can find examples in RAW and in JSON formats and descriptions of the different log fields for EAA  user access logs, EAA authentication logs, Admin audit logs, and Connector health logs.

# Access logs

In the table below you can find fields of RAW log lines definitions from EAA user access logs, authentication details, limitations, examples, and extraction for Splunk environment.

There are two levels of separators used in these files: blank space and *-* (a hyphen). A hyphen replaces any space in a country name or date (for example in *United-States*). A space separates each field in the log line. For example, `2019-06-24T18:33:08<space>username`.

> 📘 Note
>
> Blank rows like 2, 4, 6, 12, 14, and so on, indicate a space.

> 📘 Note
>
> For  [Edge Transport based tunnel applications](https://techdocs.akamai.com/eaa/docs/edge-transport-based-tunnel-applications), you will see additional rows from 83 through 113 in the access logs.

<br />

<table>
<colgroup>
<col>
<col>
<col>
<col>
<col>
</colgroup>
<thead>
<tr>
<th></th>
<th>Type of content</th>
<th>JSON key</th>
<th>Field description</th>
<th>Example</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>datetime</td>
<td><code>local_datetime</code> </td>
<td>ISO 8601 date and time when the log was fetch, no specified timezone, local to the host fetching the data.</td>
<td><code>2022-09-22T15:15:06.153000</code> </td>
</tr>
<tr>
<td>2</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>3</td>
<td>String or empty</td>
<td><code>username</code> </td>
<td>Username
<strong>Note:</strong>  If this field is empty, it means that no user is authenticated yet.</td>
<td><code>username</code> </td>
</tr>
<tr>
<td>4</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>5</td>
<td>String</td>
<td><code>apphost</code> </td>
<td>Public-facing EAA endpoint hostname that is available in two versions:
- user URL hostname for a web application
- upstream endpoint for a client application
</td>
<td><code>tunnel-app.frankfurt.example.net</code> </td>
</tr>
<tr>
<td>6</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>7</td>
<td>String</td>
<td><code>http_method</code> </td>
<td>HTTP method (also called a verb)</td>
<td><code>GET</code> </td>
</tr>
<tr>
<td>8</td>
<td>- (hyphen)</td>
<td></td>
<td></td>
<td><code>-</code> </td>
</tr>
<tr>
<td>9</td>
<td>String</td>
<td><code>url_path</code> </td>
<td>URL path</td>
<td><code>/</code> </td>
</tr>
<tr>
<td>10</td>
<td>- (hyphen)</td>
<td></td>
<td></td>
<td><code>-</code> </td>
</tr>
<tr>
<td>11</td>
<td>String</td>
<td><code>http_ver</code> </td>
<td>HTTP version</td>
<td><code>HTTP/1.1</code> </td>
</tr>
<tr>
<td>12</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>13</td>
<td>String</td>
<td><code>referer</code> </td>
<td>URL Referrer</td>
<td><code>https://www.example.com/myapp</code> </td>
</tr>
<tr>
<td>14</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>15</td>
<td>Integer 0-999</td>
<td><code>status_code</code> </td>
<td>HTTP Response code</td>
<td><code>101</code></td>
</tr>
<tr>
<td>16</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>17</td>
<td>Code</td>
<td><code>idpinfo</code> </td>
<td>Event category <code>+ | +</code> <strong>Note:</strong>  The authentication status can be empty. See <code>idp.evty</code> and <code>idp.st</code> information in EAA authentication details table.</td>
<td><code>SENTRY|V</code> </td>
</tr>
<tr>
<td>18</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>19</td>
<td>IPAddr</td>
<td><code>clientip</code> </td>
<td>Client IP address</td>
<td><code>213.109.181.6</code> </td>
</tr>
<tr>
<td>20</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>21</td>
<td>HTTP Verb</td>
<td><code>http_verb2</code> </td>
<td>HTTP method (explicit)
<strong>Note:</strong>   Same as field #7.</td>
<td><code>GET, POST</code> </td>
</tr>
<tr>
<td>22</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>23</td>
<td>Float</td>
<td><code>total_resp_time</code> </td>
<td>Total Response Time in seconds</td>
<td><code>0.014</code> </td>
</tr>
<tr>
<td>24</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>25</td>
<td>Float</td>
<td><code>connector_resp_time</code> </td>
<td>EAA Connector Response Time in seconds</td>
<td><code>0.006</code> </td>
</tr>
<tr>
<td>26</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>27</td>
<td>Datetime</td>
<td><code>datetime</code> </td>
<td>Datetime of the log line event</td>
<td><code>2019-06-24T18:33:15+00:00</code> </td>
</tr>
<tr>
<td>28</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>29</td>
<td>Float</td>
<td><code>origin_resp_time</code> </td>
<td>Origin Server Response Time in seconds</td>
<td><code>0.006</code> </td>
</tr>
<tr>
<td>30</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>31</td>
<td>String</td>
<td><code>origin_host</code> </td>
<td>Resolved IP in the datacenter</td>
<td><code>172.31.200.65</code> </td>
</tr>
<tr>
<td>32</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>33</td>
<td>Integer</td>
<td><code>req_size</code> </td>
<td>Request size in bytes</td>
<td></td>
</tr>
<tr>
<td>34</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>35</td>
<td>String</td>
<td><code>content_type</code> </td>
<td>Content-type</td>
<td><code>text/html</code> </td>
</tr>
<tr>
<td>36</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>37</td>
<td>String</td>
<td><code>user_agent</code> </td>
<td>User agent</td>
<td><code>Catchpoint</code> </td>
</tr>
<tr>
<td>38</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>39</td>
<td>String</td>
<td><code>device_type</code> </td>
<td>Device type</td>
<td><code>iPhone</code> </td>
</tr>
<tr>
<td>40</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>41</td>
<td>String</td>
<td><code>device_os</code> </td>
<td>Device operating system</td>
<td><code>iOS</code> </td>
</tr>
<tr>
<td>42</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>43</td>
<td>String</td>
<td><code>geo_city</code> </td>
<td>City name</td>
<td><code>Oakland</code> </td>
</tr>
<tr>
<td>44</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>45</td>
<td>String</td>
<td><code>geo_state</code> </td>
<td>State name (North America), province, region or other sub-division.
<strong>Note:</strong>  Hyphen means not available.</td>
<td><code>California</code> </td>
</tr>
<tr>
<td>46</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>47</td>
<td>String[2]</td>
<td><code>geo_statecode</code> </td>
<td>Two-letter state code (North America)
<strong>Note:</strong>  Hyphen means not available.</td>
<td><code>CA</code> </td>
</tr>
<tr>
<td>48</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>49</td>
<td>String[2]</td>
<td><code>geo_countrycode</code> </td>
<td>Two-letter country code in ISO 3166-2 format</td>
<td><code>GD</code> </td>
</tr>
<tr>
<td>50</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>51</td>
<td>String</td>
<td><code>geo_country</code> </td>
<td>Country name
<strong>Note:</strong>  Spaces in the country names are replaced by a hyphen (-).</td>
<td><code>United-States</code> </td>
</tr>
<tr>
<td>52</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>53</td>
<td>String</td>
<td><code>internal_host</code> </td>
<td>Internal hostname:port</td>
<td><code>clientapp.exampledemo.net:80</code> </td>
</tr>
<tr>
<td>54</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>55</td>
<td>String</td>
<td><code>session_info</code> </td>
<td>

Session information - <code>idp.einfo</code> . This field displays the following request/error messages:

- <strong>valid</strong> . The request information. For example:  
                                            `Cookie
                                            valid<code>, </code> Bearer
                                            valid` and others.
- <strong>error</strong> . The error message. For example: `Method
                                              OPTIONS not supported<code>, </code> No valid
                                              auth token` and others.  
  There is no finite list defining different options.

</td>
<td><code>bearer-valid</code> </td>
</tr>
<tr>
<td>56</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>57</td>
<td>String</td>
<td><code>groups</code> </td>
<td>Group information</td>
<td><code>Domain+Users,IT+Department</code> </td>
</tr>
<tr>
<td>58</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>59</td>
<td>String</td>
<td><code>session_id</code> </td>
<td>User session ID</td>
<td><code>e3fb292d-9e7a-4f1f-cf77-0998ecf8427e</code> </td>
</tr>
<tr>
<td>60</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>61</td>
<td>String</td>
<td><code>client_id</code> </td>
<td>Client UUID - same ID reported in Device Posture reports, or in EAA Client UI > Diagnostic >Troubleshoot your Device</td>
<td><code>5c98021e78e9c393b0714
5e388c20ace7733ca88e
d63ba0790c09e7ed5c58cf7</code> </td>
</tr>
<tr>
<td>62</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>63</td>
<td>String</td>
<td><code>deny_reason</code> </td>
<td>ACL deny reason</td>
<td><code>ClientIP</code> </td>
</tr>
<tr>
<td>64</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>65</td>
<td>Integer</td>
<td><code>bytes_out</code> </td>
<td>Bytes transferred from the connector to the user (via the EAA cloud). Available only for web applications.Value "-" is for Client-based application traffic.</td>
<td><code>1234</code> </td>
</tr>
<tr>
<td>66</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>67</td>
<td>Integer</td>
<td><code>bytes_in</code> </td>
<td>Bytes received from the user (via the EAA cloud) by the connector. Available only for web applications. Value "-" is for Client-based application traffic.</td>
<td><code>1234</code> </td>
</tr>
<tr>
<td>68</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>69</td>
<td>String</td>
<td><code>con_ip</code></td>
<td>Connector IP. <i>Note: This field is only present in classic apps and not client-based apps.</i>
</td>
<td><code>192.168.100.123</code> </td>
</tr>
<tr>
<td>70</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>71</td>
<td>String</td>
<td><code>con_srcport</code></td>
<td>
Connector source port. <i>Note: This field is only present in classic apps and not client-based apps.</i>
</td>
<td><code>:3456</code> </td>
</tr>
<tr>
<td>72</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>73</td>
<td>String</td>
<td><code>conn_uuid</code></td>
<td>
Connector UUID
</td>
<td><code>3bea6515-e122-4a56-8236-6536addd0e6c</code></td>
</tr>
<tr>
<td>74</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>75</td>
<td>String</td>
<td><code>cloud_zone</code></td>
<td>
DPOP name
</td>
<td><code>alpha-west-2-cloudproxy-4</code></td>
</tr>
<tr>
<td>76</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>77</td>
<td>String</td>
<td><code>error_code</code></td>
<td>
Code delivered in the error page.
</td>
<td><code>0</code></td>
</tr>
<tr>
<td>78</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>79</td>
<td>String</td>
<td><code>client_process</code></td>
<td>
Name of the software process consuming the Client-based app (TCP/UDP)
</td>
<td><code>svchost.exe</code></td>
</tr>
<tr>
<td>80</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>81</td>
<td>String</td>
<td><code>client_version</code></td>
<td>
Version of the EAA Client making the request
</td>
<td><code>2.8.1.22090201</code></td>
</tr>
<tr>
<td>82</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>83</td>
<td>String</td>
<td><code>srvty</code></td>
<td>
The type of service. Allowed values are:
L - login proxy
A - access log
</td>
<td><code>A</code></td>
</tr>
<tr>
<td>84</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>85</td>
<td>String</td>
<td><code>idp.app</code></td>
<td>
The name of the application
</td>
<td></td>
</tr>
<tr>
<td>86</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>87</td>
<td>String</td>
<td><code>eaaclient.txid</code></td>
<td>
Transaction ID of the AZT Client or GPA Client
</td>
<td><code>dad00531-d1cd-9a61-69b1-35ab6f3204fd</code></td>
</tr>
<tr>
<td>88</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>89</td>
<td>String</td>
<td><code>eaaclient.os</code></td>
<td>
Operating system of the AZT Client or GPA Client
</td>
<td><code>darwin-amd64</code></td>
</tr>
<tr>
<td>90</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>91</td>
<td>String</td>
<td><code>eaaclient.proto</code></td>
<td>
Type of protocol used for the connection by the AZT Client or GPA Client. Allowed values are TCP-terminated or UDP tunneled.
</td>
<td><code>TCP-terminated</code></td>
</tr>
<tr>
<td>92</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>93</td>
<td>String</td>
<td><code>client_ghost_addr_geo.region_name</code></td>
<td>
AZT Client’s or GPA Client’s Akamai edge network machine  region
</td>
<td><code>New-Jersey</code></td>
</tr>
<tr>
<td>94</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>95</td>
<td>String</td>
<td><code>connector_ghost_addr_geo.region_name</code></td>
<td>
Connector’s Akamai edge network machine region
</td>
<td><code>New-York</code></td>
</tr>
<tr>
<td>96</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>97</td>
<td>Float</td>
<td><code>crtt</code></td>
<td>
Round trip time between AZT/GPA Client and Akamai stitcher node (usec)
</td>
<td><code>27000</code></td>
</tr>
<tr>
<td>98</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>99</td>
<td>Float</td>
<td><code>drtt</code></td>
<td>
Round trip time between the connector and Akamai stitcher node (usec)
</td>
<td><code>15000</code></td>
</tr>
<tr>
<td>100</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>101</td>
<td>Float</td>
<td><code>ortt</code></td>
<td>
Round trip time between the connector and origin (usec)
</td>
<td><code>45</code></td>
</tr>
<tr>
<td>102</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>103</td>
<td>String</td>
<td><code>PE.decision</code></td>
<td>
Policy engine decision. Most of the time it is ALLOW. 
</td>
<td><code>ALLOW</code></td>
</tr>
<tr>
<td>104</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>105</td>
<td>Float</td>
<td><code>PE.start_time</code></td>
<td>
Policy engine transaction start time
</td>
<td><code>2025-11-17T19:23:23.354Z</code></td>
</tr>
<tr>
<td>106</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>107</td>
<td>Float</td>
<td><code>PE.duration</code></td>
<td>
Policy engine duration to make decision (msec)
</td>
<td><code>93</code></td>
</tr>
<tr>
<td>108</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>109</td>
<td>String</td>
<td><code>PE.geoip.region_name</code></td>
<td>
Akamai Policy engine machine region
</td>
<td><code>Virginia</code></td>
</tr>
<tr>
<td>110</td>
<td><space></td>
<td></td><td></td>
<td></td>
</tr>
<tr>
<td>111</td>
<td>String</td>
<td><code>stitcher.geoip.region_name</code></td>
<td>
Akamai stitcher machine region 
</td><td><code>Virginia</code></td>
</tr>
<tr>
<td>112</td>
<td><space></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>113</td>
<td>String</td>
<td><code>log_type</code></td>
<td>
Type of the log. pe-report indicates it is Edge Transport. 
</td>
<td><code>pe-report</code></td>
</tr>

</tbody>
</table>

> 📘 Important Note
>
> For **error code**, EAA gives the main error code, and in some scenarios, it also gives a sub error code. Please refer to [Application response codes, login events, and errors for the sub-error codes](https://techdocs.akamai.com/eaa/docs/app-response-codes-login-events-err).

## Access Log examples for Edge Transport based applications

RAW format:

```
2025-11-17T14:23:38.916000 employee1 sample-app-akamai-com.go.akamai-access.com - - 100 SENTRY| 111.222.3.4 - - - 2025-11-17T19:23:38.916Z - 1.2.3.4:443 5374 - Chrome-142-0 Mac-OS-X-10-15 Mac Cambridge Massachusetts MA US United-States sample.akamai.com:443 - secGroupAUsers,secGroupBUsers f09fc169-38c1-42fb-c2d2-95cca224883b 1294a3c56c1fe1b39fb53a5252fc977a1b707a321f4920716fe0174e4551273e - 5374 12274 - e0c6e815-a56d-4c6f-a03f-309cd2946e92 - 0 Google-Chrome-Helper 7.2.2 A - dad00531-d1cd-9a61-69b1-35ab6f3204fd darwin-amd64 TCP-terminated New-Jersey New-York 27000 15000 45 ALLOW 2025-11-17T19:23:23.354Z 93 Virginia Virginia pe-report

```

JSON format:

```
{
"local_datetime": "2025-11-17T14:23:38.916000", 
"username": "employee1", 
"apphost": "sample-app-akamai-com.go.akamai-access.com", 
"http_method": "", 
"referer": "-", 
"status_code": 100, 
"idpinfo": "SENTRY|", 
"clientip": "111.222.3.4", 
"http_verb2": "-", 
"total_resp_time": "-", 
"connector_resp_time": "-", 
"datetime": "2025-11-17T19:23:38.916Z", 
"origin_resp_time": "-", 
"origin_host": "1.2.3.4:443", 
"req_size": 5374, 
"content_type": "-", 
"user_agent": "Chrome-142-0", 
"device_type": "Mac-OS-X-10-15", 
"device_os": "Mac", 
"geo_city": "Cambridge", 
"geo_state": "Massachusetts", 
"geo_statecode": "MA", 
"geo_countrycode": "US", 
"geo_country": "United-States", 
"internal_host": "sample.akamai.com:443", 
"session_info": "-", 
"groups": "secGroupAUsers,secGroupBUsers", 
"session_id": "f09fc169-38c1-42fb-c2d2-95cca224883b", 
"Client_id": "1294a3c56c1fe1b39fb53a5252fc977a1b707a321f4920716fe0174e4551273e", "deny_reason": "-", 
"bytes_out": 5374, 
"bytes_in": 12274, 
"con_uuid": "e0c6e815-a56d-4c6f-a03f-309cd2946e92", 
"cloud_zone": "-", 
"error_code": 0, 
"client_process": "Google-Chrome-Helper", 
"client_version": "7.2.2", 
"srvty": "A", 
"idp.app": "-", 
"eaaclient.txid": "dad00531-d1cd-9a61-69b1-35ab6f3204fd", 
"eaaclient.os": "darwin-amd64", 
"eaaclientinfo.proto": "TCP-terminated", 
"client_ghost_addr_geo.region_name": "New-Jersey", "connector_ghost_addr_geo.region_name": "New-York", 
"crtt": "27000", 
"drtt": "15000", 
"ortt": "45", 
"PE.decision": "ALLOW", 
"PE.start_time": "2025-11-17T19:23:23.354Z", 
"PE.duration": "93", 
"PE.geoip.region_name": "Virginia", 
"stitcher.geoip.region_name": "Virginia", 
  "log_type": "pe-report"
}

```

## Access log examples

RAW format:

```
2022-09-22T15:28:31.450000 employee3 sjclientyahoo.stage.akamai-access.com GET-/-HTTP/1.1 - 101 SENTRY|V 147.92.90.233 GET 67.736 67.736 2022-09-22T22:28:31+00:00 67.736 66.218.87.15 6017 text/plain Chrome-105-0 Mac-OS-X-10-15 Mac Fremont California CA US United-States geo.yahoo.com:443 bearer-valid - 75cc22e0-fd34-4c85-cce2-8ef8ef6f2c66 ac7da8d27cbd38d3d9b765ba74d0054528c99091e509b44a40f3d2987f5b642d bearer-valid 6017 3000 10.22.2.232 e19afcd5-c12b-4198-8884-4b5b5b2ea2e2 DPOP-Alpha-East-U18 0 Google-Chrome-Helper 2.8.0.22060101

```

JSON format:

```json

{
"local_datetime": "2022-09-22T15:28:31.450000", 
"username": "employee3", 
"apphost": "sjclientyahoo.stage.akamai-access.com", 
"http_method": "GET", "url_path": "/", 
"http_ver": "HTTP/1.1", 
"referer": "-", 
"status_code": 101, 
"idpinfo": "SENTRY|V", 
"clientip": "147.92.90.233", 
"http_verb2": "GET", 
"total_resp_time": 67.872, 
"connector_resp_time": 67.872, 
"datetime": "2022-09-22T22:28:31+00:00", 
"origin_resp_time": 67.872, 
"origin_host": "69.147.92.11", 
"req_size": 1602, 
"content_type": "text/plain", 
"user_agent": "Chrome-105-0", 
"device_type": "Mac-OS-X-10-15", 
"device_os": "Mac", 
"geo_city": "Fremont", 
"geo_state": "California", 
"geo_statecode": "CA", 
"geo_countrycode": "US", 
"geo_country": "United-States", 
"internal_host": "beap-bc.yahoo.com:443", 
"session_info": "bearer-valid", 
"groups": "-", 
"session_id": "75cc22e0-fd34-4c85-cce2-8ef8ef6f2c66", 
"client_id": "ac7da8d27cbd38d3d9b765ba74d0054528c99091e509b44a40f3d2987f5b642d", 
"deny_reason": "bearer-valid", 
"bytes_out": 1602, 
"bytes_in": 2780, 
"con_uuid": "e19afcd5-c12b-4198-8884-4b5b5b2ea2e2", 
"cloud_zone": "DPOP-Alpha-East-U18", 
"error_code": 0, 
"client_process": "Google-Chrome-Helper", 
"client_version": "2.8.0.22060101"
}

```

## EAA authentication details in user access logs

Authentication details can be found in the following log lines: `access proxy`, `login server`, and `directory server`. The latest logs are JSON formatted at the source and composed of key value pairs, where the value is a string or a dictionary of key value pairs.

The following table describes JSON keys relevant for the authentication event logs.

<table>
<caption>
</caption>
<colgroup>
<col>
<col>
</colgroup>

<thead>
<tr>
<th>Key</th>
<th>Purpose</th>
</tr>
</thead>

<tbody>
<tr>

<td><code>srvty</code> </td>
<td>The <code>srvty</code> key distinguishes the type of service that generated the log line. The application proxy, login service and directory services are all implemented in a proxy service.</td>
</tr>
<tr>
<td><code>idp.uid</code> </td>
<td>The user identifier is determined by the authentication method.

- If it has not been set, its value is either a hyphen (-) or a space.

- A special value, <code>anon-user</code> , indicates that access was allowed for the request without authentication.

</td>
</tr>
<tr>
<td><code>idp.grps</code> </td>
<td>The <code>idp.grps</code> key is a comma-separated and URL-encoded list of group memberships. Group names can have commas so URL encoding of group values is required. Other rules include:

- Third-party SAML Identity Providers (IdPs) are set to the user's group membership determined by received SAML claims.

- ​Akamai​ IdPs are set to intersect with the user's real group membership in Active Directory (AD) and the groups configured for sync by the administrator into EAA.

- If the group membership cannot be determined, the value is set to a hyphen (-).

- If the log is generated on the application proxy, the value is always set to a hyphen (-) to reduce the size of the logs. Some older logs may still include group memberships in the log line.

</td>
</tr>
<tr>
<td><code>idp.app</code> </td>
<td>The <code>idp.app</code> event key application context for the request is:

- If the log is generated on the application proxy, the application context is always the application hostname itself.

Since the data for this event is set by the sentry module, in cases where the sentry module does not process the request, the context is not set and default to either a space or hyphen (-).

- If the log is generated on the directory server, the application context is always the directory server hostname.

- If the log is generated on the login server, the application context can be:

- The application server name, if the request was logged while an authentication request from an application is in process.

- The login server name, if the request was logged and there is no application authentication context.

</td>
</tr>
<tr>
<td><code>idp.slogid</code> </td>
<td>The <code>idp.slogid</code> key is a unique session log identifier that binds application sessions to the session identifier in the login server log lines. When present, this can be used to associate an application access event to a specific login event in the IP logs.</td>
</tr>
<tr>
<td><code>idp.evty</code> </td>
<td>You can determine the event category by looking at other properties in the log line such as <code>srvty</code> and <code>URL</code>.See below`idp.evty` key event categories table for details on event categories that appear in the log lines from the various edge services.
</tr>
<tr>
<td><code>idp.st</code> </td>
<td>The <code>idp.st</code> event key displays the authentication or API call status field.See below `idp.st` authentication status table for details on the authentication status results.
</tr>
<tr>

<td><code>idp.cinfo</code> </td>
<td>The <code>idp.cinfo</code> key provides customer visible text descriptions for some conditions. If this key is not set, its value defaults to a hyphen (-) or space. The following text messages appear when the <code>idp.cinfo</code> has been set:

- login success
- mfa complete
- account locked
- invalid user
- invalid creds
- access denied
- mfa failure
- service error
- pwd change ok
- pwd change error
- logout success

</td>
</tr>
<tr>
<td><code>idp.einfo</code> </td>
<td>This is a free-form field primarily used for debugging issues. The text provides detailed descriptions of issues and may include errors raised by upstream services such as Kerberos/LDAP broker.</td>
</tr>
</tbody>
</table>

<table>
  <caption><strong>idp.evty key event categories</strong></caption>
  <colgroup>
    <col>
    <col>
    <col>
  </colgroup>
  <thead>
    <tr>
      <th>Event</th>
      <th>Service</th>
      <th>Purpose</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><code>SENTRY</code></td>
      <td>Application proxy</td>
      <td>Indicates that the request was processed by the sentry module. Almost all requests received at the application proxy is processed by the sentry module, unless the request is rejected before the sentry module gets a chance to look at them.</td>
    </tr>
    <tr>
      <td><code>LOGIN</code></td>
      <td>Login server</td>
      <td>Indicates login-related activity on the login server. Login activity includes:
        <ul>
          <li>Submitting user credentials via login form or using Kerberos negotiation.</li>
          <li>Password change operations.</li>
          <li>Submitting credentials in the SAML ECP flow.</li>
          <li>Submitting credentials by access proxy in some authentication schemes where the authentication prompt is given by the application proxy itself (like, HTTP basic authentication)</li>
          <li>Any inbound authentication requests received via the user agent on the IdP from the application:
            <ul>
              <li>OpenID apps</li>
              <li>SAML apps</li>
              <li>Access apps</li>
              <li>WS Federation apps</li>
            </ul>
          </li>
        </ul>
      </td>
    </tr>
    <tr>
      <td><code>LOGOUT</code></td>
      <td>Login server</td>
      <td>The logout activity on the login server:
        <ul>
          <li>An explicit logout from the IdP using the login UI.</li>
          <li>A single logout request from apps that subscribe to single logout capability.</li>
          <li>A re-authentication request from the application proxy, e.g., if the NTLM credentials are not usable for an active session.</li>
          <li>A back-channel logout request received from the application proxy in case the logout URL was configured for the application and a user clicked logout on the application.</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td><code>QUERY</code></td>
      <td>Login server</td>
      <td>A default event type for requests received over the back-channel interface between the application proxy and the login server. Some of the back-channel requests are relabeled under a different event category based on the nature of the request (see <code>LOGOUT</code> and <code>LOGIN</code> event types). Logs with these event types are for authentication protocol debugging use only.</td>
    </tr>
    <tr>
      <td><code>PORTAL</code></td>
      <td>Login server</td>
      <td>A default event type for API calls from the login server UI:
        <ul>
          <li>auth status checks when switching between UI routes</li>
          <li>pwd policy API</li>
          <li>forget user API</li>
          <li>user apps list fetch API</li>
          <li>app navigation API</li>
          <li>config layout API</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td><code>MFA</code></td>
      <td>Login server</td>
      <td>A default event type for 2-FA API calls from the login UI to the login server:
        <ul>
          <li>Add/delete email address</li>
          <li>Add/delete phone number</li>
          <li>Create/remove TOTP secret</li>
          <li>Register/de-register duo</li>
          <li>Push email token</li>
          <li>Push SMS token</li>
          <li>Push TOTP token</li>
          <li>Verify email token</li>
          <li>Verify SMS token</li>
          <li>Verify TOTP token</li>
          <li>MFA help</li>
          <li>Fetch masked user MFA settings</li>
          <li>Fetch unmasked user MFA settings</li>
          <li>Change preferred MFA scheme</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td><code>CONNECTOR</code></td>
      <td>Directory server</td>
      <td>All log lines generated from the directory server have this event type. The directory server relays the authentication API calls from the login server to the enterprise directory connector.</td>
    </tr>
  </tbody>
</table>

<table>
  <caption><strong>idp.st authentication status</strong></caption>
  <colgroup>
    <col>
    <col>
    <col>
  </colgroup>
  <thead>
    <tr>
      <th>Authentication status</th>
      <th>Service</th>
      <th>Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><code>V</code> (Valid)</td>
      <td>Application and login service</td>
      <td>
        Indicates that session validation succeeded (cookie or bearer token validation):
        <ul>
          <li>For an application proxy, this indicates that the request session is valid. The request may still be denied access to the origin due to other criteria such as application access control rules (ACL).</li>
          <li>For a login service, this status shows up in case of API calls received with a valid IdP session cookie.</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td><code>I</code> (Invalid)</td>
      <td>Application and login service</td>
      <td>Indicates that session validation failed. Either an expired cookie or token was presented to the service.</td>
    </tr>
    <tr>
      <td><code>-</code> (Undefined)</td>
      <td>Application, login, and directory service</td>
      <td>A cookie or token was not validated for the request. This can happen if the processing of a request exits before cookie or token validation, or intentionally in the case of some API calls that do not require user validation, e.g., config layout API on the login server or for the directory service case which receives requests only from the login service.</td>
    </tr>
    <tr>
      <td><code>S</code> (Success)</td>
      <td>Login service</td>
      <td>
        Indicates that the result of an authentication attempt was successful. MFA is not counted as an authentication attempt in the logs, so an <code>S</code> does not automatically imply that the logged-in user can access the application.
        <br>A successful authentication results in a new session creation. A new session log identifier should be seen in the log lines.
      </td>
    </tr>
    <tr>
      <td><code>F</code> (Failure)</td>
      <td>Login service</td>
      <td>
        Indicates that the result of an authentication attempt was a failure. Authentication can fail under multiple scenarios:
        <ul>
          <li>A user was not found in the synced user database in the &lt;&lt;PRODUCT_NICKNAME&gt;&gt; cloud</li>
          <li>Invalid user credentials</li>
          <li>Account locked</li>
          <li>Service failures:
            <ul>
              <li>&lt;&lt;PRODUCT_NICKNAME&gt;&gt; cloud is not reachable</li>
              <li>&lt;&lt;PRODUCT_NICKNAME&gt;&gt; cloud sent unexpected response</li>
              <li>Directory is not reachable</li>
              <li>Directory connector sent unexpected response</li>
              <li>New session could not be recorded in session database</li>
              <li>Misconfiguration</li>
              <li>Received invalid protocol response from upstream Identification Provider</li>
              <li>Protocol processing micro service failure</li>
            </ul>
          </li>
        </ul>
        Generally, the service failures are also accompanied with free form information in the <code>idp.einfo</code> field to aid in troubleshooting.
      </td>
    </tr>
    <tr>
      <td><code>X</code> (Expired)</td>
      <td>Login service</td>
      <td>A current session has been marked as expired. The session gets marked for expiry when there is an explicit logout from the user of an app that participates in a single logout. The session is retained in cache to complete the logout, but the creation of a new SSO session is disabled by marking it as expired.</td>
    </tr>
    <tr>
      <td><code>E</code> (Error)</td>
      <td>Login service</td>
      <td>
        An error occurred during authentication protocol processing or there was a service failure.
        This was introduced along with SAML Identity Provider functionality. The goal is to identify cases where the peer entity in the authentication protocol is not behaving in accordance with the specification.
        You can move some of the authentication failure scenarios under this error code to simplify interpretation of the failure codes for customer logs.
      </td>
    </tr>
    <tr>
      <td><code>R</code> (Rejected)</td>
      <td>Login service</td>
      <td>A user has a valid authentication session, however, request for access to a target application is rejected because the user does not have access to the app or the app is no longer available.</td>
    </tr>
    <tr>
      <td><code>D</code> (Disabled)</td>
      <td>Application</td>
      <td>The authentication is disabled for the request. The user is set as <code>anon-user</code>.</td>
    </tr>
    <tr>
      <td><code>MC</code> (MFA Challenge)</td>
      <td>Login service</td>
      <td>
        The MFA event API calls concerned with rendering of the MFA challenge page. This indicates that the user is prompted for an MFA challenge:
        <ul>
          <li>Email token pushed.</li>
          <li>Phone token pushed.</li>
          <li>Masked token settings delivered to UI.</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td><code>MR</code> (MFA Register)</td>
      <td>Login service</td>
      <td>The MFA event API calls concerned with rendering of the MFA registration pages. This indicates the user is registering or modifying MFA settings.</td>
    </tr>
    <tr>
      <td><code>MF</code> (MFA Failure)</td>
      <td>Login service</td>
      <td>
        The MFA validation failed. This results in denial of access to applications that require MFA, or denial of security-sensitive operations on the portal such as modifying the MFA settings itself or modifying users credentials.
        <br>Multiple failed attempts also result in account lockout. For more information, see <em>Set a temporary lockout for multiple failed login attempts</em>.
      </td>
    </tr>
    <tr>
      <td><code>MD</code> (MFA Done)</td>
      <td>Login service</td>
      <td>
        The MFA validation succeeded or is not required. MFA validation can succeed if the user presented a valid MFA token in response to the MFA challenge, or if the user's device was trusted (for example, the user clicked <code>Remember Me</code>).
      </td>
    </tr>
    <tr>
      <td><code>MI</code> (MFA Invalid)</td>
      <td>Login service</td>
      <td>
        The MFA invalid is logged in case of a PCI DSS MFA scheme. The goal of PCI DSS MFA is to avoid disclosing user credentials or MFA failures to the user. To achieve this, the service declares user credentials as valid to the UI even when they are invalid.
        <br>The response to the fake MFA challenge is ignored and instead of declaring it as MFA failure, it is declared as MFA invalid in the log lines.
      </td>
    </tr>
    <tr>
      <td><code>PCS</code> (Password Change Success)</td>
      <td>Login service</td>
      <td>A user successfully changed the password using the change password API call.</td>
    </tr>
    <tr>
      <td><code>PCF</code> (Password Change Failure)</td>
      <td>Login service</td>
      <td>A user failed to change the password. Password change can fail for many reasons such as poor password quality, violation of password history, etc. These reasons are displayed to the user on the UI and included as free form text in the <code>idp.einfo</code> field.</td>
    </tr>
  </tbody>
</table>

## User authentication examples

RAW format:

```
2021-07-23T09:40:05.575000 - login.akamaidemo.net GET-/oidc/oauth?client_id=3cd24...-HTTP/1.1 - 302 LOGIN|I 123.123.123.123 GET 0.002 - 2021-07-23T16:40:05+00:00 - - 827 text/html My-User-Agent Other Other Ashburn Virginia VA US United-States - sso-cookie-no-cookie-value - -

```

JSON format:

```json
{
    "username": "-",
    "apphost": "login.akamaidemo.net",
    "http_method": "GET",
    "url_path": "/oidc/oauth?client_id=3cd24...",
    "http_ver": "HTTP/1.1",
    "referer": "-",
    "status_code": 302,
    "idpinfo": "LOGIN|I",
    "clientip": "123.123.123.123",
    "http_verb2": "GET",
    "total_resp_time": 0.002,
    "connector_resp_time": "-",
    "datetime": "2021-07-23T16:40:05+00:00",
    "origin_resp_time": "-",
    "origin_host": "-",
    "req_size": 827,
    "content_type": "text/html",
    "user_agent": "My-User-Agent",
    "device_os": "Other",
    "device_type": "Other",
    "geo_city": "Ashburn",
    "geo_state": "Virginia",
    "geo_statecode": "VA",
    "geo_countrycode": "US",
    "geo_country": "United-States",
    "internal_host": "-",
    "session_info": "sso-cookie-no-cookie-value",
    "groups": "-",
    "session_id": "-"
}

```

## Limitations

There are some limitations related to the use of IP Application Accelerator. If you are using the IPA acceleration service, the Client IP and related geo information (lines 43-51 in the above table) represents the closest IPA gateway, not the actual user location.

Go to [IP Application Accelerator](https://www.akamai.com/products/api-acceleration) to learn more about the acceleration service.

> 👍
>
> The data retention policy is 365 days.

## Extract EAA Access Log fields

Set up RAW log field extraction with Splunk. EAA  API delivers the access log event in a space separated text line (RAW format) and both CLI-EAA and ULS can deliver the same event also in a structured JSON format.\
Most SIEM support extraction using regular expression. Please check your SIEM documentation for more details, or choose the JSON format instead. This is EAA extract regular expression for EAA log lines:

```
^([^\s]*)\s(?P<username>[\w\-]*)\s(?P<apphost>[\w\.\-]+)\s(?P<http_method>[A-Z]+)-(?P<url_path>.*)\-(?P<http_ver>HTTP/[0-9\.]*)\s(?P<referer>[^\s]*)\s(?P<status_code>[0-9]*)\s(?P<idpinfo>[^\s]*)\s(?P<clientip>[^\s]*)\s(?P<http_verb2>[^\s]*)\s(?P<total_resp_time>[^\s]*)\s(?P<connector_resp_time>[^\s]*)\s(?P<datetime>[^\s]*)\s(?P<origin_resp_time>[^\s]*)\s(?P<origin_host>[^\s]*)\s(?P<req_size>[^\s]*)\s(?P<content_type>[^\s]*)\s(?P<user_agent>[^\s]*)\s(?P<device_os>[^\s]*)\s(?P<device_type>[^\s]*)\s(?P<geo_city>[^\s]*)\s(?P<geo_state>[^\s]*)\s(?P<geo_statecode>[^\s]*)\s(?P<geo_countrycode>[^\s]*)\s(?P<geo_country>[^\s]*)\s(?P<internal_host>[^\s]*)\s(?P<session_info>[^\s]*)\s(?P<groups>[^\s]*)\s(?P<session_id>.*)[\s.*|]
```

Prerequisite:\
An  account in Splunk. To download Splunk, go to [Splunk page](https://www.splunk.com/en_us/download/splunk-enterprise.html). For more details on downloading and installation, see [Splunk installation manual](https://docs.splunk.com/Documentation/Splunk/latest/Installation/Whatsinthismanual).

1. In your Splunk account, select **Settings** > **Fields** > **Field Extractions**.

2. Click **New** to create a new field extraction.\
   The **Add new** window appears.

3. In **Extraction/Transform** paste the extract.

4. Click **Save**.\
   After you save the changes, you can see how you can use the extracted regular expression in Splunk SIEM.

# Admin logs

Fields definition and examples of Admin logs:

<table>
<caption>
</caption>
<colgroup>
<col>
<col>
<col>
</colgroup>
<thead>
<tr>
<th>Field</th>
<th>JSON key</th>
<th>Description</th>
</tr>
</thead>

<tbody>
<tr>
<td>Date</td>
<td><code>datetime</code> </td>
<td>Date and time of the event formatted in ISO 8601, including timezone suffix</td>
</tr>
<tr>
<td>Username</td>
<td><code>username</code> </td>
<td>Email address of the admin user performing the action.If the action is trigger by a condition of the tenant the user is <code>system</code></td>
</tr>
<tr>
<td>ResourceType</td>
<td><code>resource_type</code> </td>
<td>Type of the resource being audited</td>
</tr>
<tr>
<td>Resource</td>
<td><code>resource</code> </td>
<td>Name of the resource</td>
</tr>
<tr>
<td>Event</td>
<td><code>event</code> </td>
<td>Name of the event</td>
</tr>
<tr>
<td>EventType</td>
<td><code>event_type</code> </td>
<td>Type of the event</td>
</tr>
</tbody>

</table>

RAW format:

```
% akamai eaa log admin --start $(( $(date +%s) - 30000 ))
#DatetimeUTC,AdminID,ResourceType,Resource,Event,EventType
2023-09-01T15:42:09+00:00,user1@akamai.com,users, user1@akamai.com,login,login
2023-09-01T09:17:29+00:00, user2@akamai.com,users, user2@akamai.com,login,login
2023-09-01T08:31:09+00:00, user3@akamai.com,users, user3@akamai.com,login,login
2023-09-01T07:43:03+00:00, user3@akamai.com,users, user3@akamai.com,login,login
# Start: 09/01/2023 07:39:14 UTC (EPOCH 1693553954)
# End: 09/01/2023 15:49:14 UTC (EPOCH 1693583354)
# Total: 4 event(s), 0 error(s), 395 bytes written
```

JSON format:

```json
% akamai eaa --section akamaidemo log admin --start $(( $(date +%s) - 30000 )) --json
#DatetimeUTC,AdminID,ResourceType,Resource,Event,EventType
{
      "datetime": "2023-09-01T15:42:09+00:00", 
      "username": user1@akamai.com, 
      "resource_type": "users", 
      "resource": user1@akamai.com, 
      "event": "login", 
      "event_type": "login"
}

```

# Connector health

Fields definition and examples illustrating the health of the connector:

<table>
<caption>
</caption>
<colgroup>
<col>
<col>
<col>
</colgroup>
<thead>
<tr>
<th>Field</th>
<th>JSON key</th>
<th>Description</th>
</tr>
</thead>

<tbody>
<tr>
<td>Connector ID</td>
<td><code>connector_uuid</code> </td>
<td>ID of the connector</td>
</tr>
<tr>
<td>Connector Name</td>
<td><code>name</code> </td>
<td>name of the connector</td>
</tr>
<tr>
<td>Reachable</td>
<td><code>reachable</code> </td>
<td>1 indicates connector is reachable, 0 otherwise see API definition</td>
</tr>
<tr>
<td>Status</td>
<td><code>status</code> </td>
<td>Status of the connector</td>
</tr>
<tr>
<td>Version</td>
<td><code>version</code> </td>
<td>Version of the connector software</td>
</tr>
<tr>
<td>Private IP</td>
<td><code>privateip</code> </td>
<td>IP address attached to the connector in the datacenter. If the connector is publicly exposed (not recommended) the field contains a public IP</td>
</tr>
<tr>
<td>Public IP</td>
<td><code>publicip</code> </td>
<td>Public IP of the connector seen by EAA platform (NAT public IP)</td>
</tr>
<tr>
<td>Debug mode</td>
<td><code>debugchan</code> </td>
<td>Debug mode 1 for enabled, 0 for disabled.</td>
</tr>
<tr>
<td>Last update</td>
<td><code>ts</code> </td>
<td>Last time connector sent the performance metrics</td>
</tr>
<tr>
<td>CPU%</td>
<td><code>cpu</code> </td>
<td>CPU utilization in %</td>
</tr>
<tr>
<td>Disk%</td>
<td><code>disk</code> </td>
<td>Disk utilization in %</td>
</tr>
<tr>
<td>Memory %</td>
<td><code>mem</code> </td>
<td>Memory utilization in %</td>
</tr>
<tr>
<td>Network traffic</td>
<td><code>network</code> </td>
<td>Network usage in Mbps</td>
</tr>
<tr>
<td>Total Dialout Count</td>
<td><code>dialout_total</code> </td>
<td>Number of dialout the connector is handling</td>
</tr>
<tr>
<td>Idle Dialout Count</td>
<td><code>dialout_idle</code> </td>
<td>Number of idle dialout</td>
</tr>
<tr>
<td>Active Dialout Count</td>
<td><code>dialout_active</code> </td>
<td>Number of actively used dialout</td>
</tr>
</tbody>
</table>

RAW format:

```
% akamai eaa connector list --perf
#Connector-id,name,reachable,status,version,privateip,publicip,debug,last_upd,CPU%,Mem%,Disk%,NetworkMbps,do_total,do_idle,do_active
con://cht3_GEjQWyMW9LEk7KQfg,demo-v2-con-1-amer,1,1,21.01.0-152,10.1.4.206,123.123.123.123,Y,2021-07-23T18:06:35.676Z,1.3,32.4,34.4,0.06,1304,1302,1

```

JSON format:

```
% akamai eaa connector list --perf --json | jq
{
    "connector_uuid": "cht3_GEjQWyMW9LEk7KQfg",
    "name": "demo-v2-con-1-amer",
    "reachable": 1,
    "status": 1,
    "version": "21.01.0-152",
    "privateip": "10.1.4.206",
    "publicip": "123.123.123.123",
    "debugchan": "Y",
    "ts": "2021-07-23T18:06:35.676Z",
    "cpu": 1.3,
    "disk": 34.4,
    "mem": 32.4,
    "network": 0.06,
    "dialout_total": 1304,
    "dialout_idle": 1302,
    "dialout_active": 1
}

```

# SIEM support with Unified Log Streamer

It's common for organizations with mature security environment to have a Security Operations Center (SOC) that leverages security information and event management (SIEM) tools. SIEM provides a centralized view for security teams to access and analyze security information from a large number of sources, and prioritize mitigation efforts based on risk profiles.

EAA  Unified Log Streamer allows you to stream EAA  data feeds into your SIEM, no need to learn the API, it immediately gets you started.

Key features:

* Continuous streaming to SIEM using TCP, UDP, HTTP, or flat File

* Highly customizable

  * Choose between different EAA feeds

  * Filter any data you want to discard before sending it to SIEM

* Operate as standalone script, service, Docker Container Image, or Kubernetes/Helm

* No extra charge

The [ULS GitHub project](https://github.com/akamai/uls) contains the [detailed instructions](https://github.com/akamai/uls/blob/main/README.md) to setup and operate ULS with your SIEM.

# Sibling pages

* [Real-time Connector Metrics using Datadog, TrafficPeak, and Amazon CloudWatch SIEM providers](https://techdocs.akamai.com/eaa/docs/real-time-connector-metrics-using-siem-providers.md)
* [Real-time Connector Metrics using Splunk SIEM provider](https://techdocs.akamai.com/eaa/docs/real-time-connector-metrics-using-splunk-siem-provider.md)
* [Real-time Connector Metrics using Dynatrace SIEM provider](https://techdocs.akamai.com/eaa/docs/real-time-connector-metrics-using-dynatrace-siem-provider.md)
* [Send Access Logs to Datadog, TrafficPeak, Splunk, and CloudWatch SIEM](https://techdocs.akamai.com/eaa/docs/send-access-logs-to-datadog-trafficpeak-splunk-and-amazon-cloudwatch-siem.md)
* [Send Access logs to Elasticsearch SIEM](https://techdocs.akamai.com/eaa/docs/send-access-logs-to-elasticsearch-siem.md)